All the data modification commands given during the session are automatically cancelled if the final authentication fails, or is not successfully carried out.
Thus, the session mechanism ensures that either the modification made during the session is correctly carried out completely, or no change takes place. If the session is not successfully closed (because of a bad signature, a card error, an unexpected shut down, etc.), then all the modifications carried out during the session are cancelled.

Moreover, a special feature, called the “Ratification”, allows the ground terminal to handle gracefully a final communication link problem.
During any communication, a break in the link may occur unexpectedly.
This is particularly true in contactless communication, where the card may be taken out of the terminal radio field during a normal use, and before completion of the transaction.

The secure session is a very efficient means of solving this problem, as an interruption before the session closing will cancel all the modifications made to the card, leaving it in the same state it was in before the session.

For example, if a counter must be decreased and a “allow” entrance event must be recorded at the same time in the card, the session mechanism will ensure that either both are completed or that neither is executed.

However, after the end of the session, and the validation of the changes by the card, the acknowledgement (including the card signature) must still reach the terminal.
If the communication link is broken between the session closing, and the good reception of its acknowledgement, the terminal has no proof that the card is legitimate and that the transaction has succeeded.
In this case, the customer might have paid, or have his rights decreased, and not be allowed access.
The usual solution to this problem involves a complex mechanism in the terminal, which must remember the cards that might fall into this case, and handle them properly if they are presented again soon after.

The problem is even more complex in transport networks, where many validators may control the same network entrance gate, and where the user might be tempted to try another validator if the previous one failed to open the gate. To allow the user to enter without paying twice, while avoiding this very complex and costly management in the entrance terminal, a new mechanism was designed: the Ratification.
The Ratification works as follows:

• Step 1: On session closing, the PO records the session as “not ratified”. The PO then sends the session closing acknowledge to the terminal.
• Step 2: On receipt of the acknowledge, the terminal decides to grant access to the transit network, and sends a new message to the PO, acting also as a session closing acknowledge.
• Step 3: On receipt of this new message, the PO changes the state of the recorded session to “ratified”.

When a session is opened, the PO sends back the state of the previous session.

The session remains in the “not ratified” state only if the communication is broken after the PO records the session as “not ratified” and before it changes the sate of the recorded session to “ratified”. The probability of occurrence is small, because the corresponding duration is very short.

The mechanism with ratification allows a second terminal to take the following actions:

• If the previous transaction was at another entrance or is too old, the terminal assumes that it is a new transaction and debits the Calypso application to grant the network access.
• If the previous transaction was at the same entrance and is recent, according to the ratification state:
  • Ratified: The terminal forbids the access, without any risk to reject a legitimate user, as it knows that the previous terminal completely processed the transaction.
  • Not ratified: The terminal grant the access, without debiting the PO again, letting all legitimate users enter the network.