TRANSIT SOLUTION

Mass Transit Transactions (MTT)

MTT is a fare collection model whereby the presentation of fare media results in a value-based transaction drawing upon a source of funds as opposed to the validation of a pre-purchased ticket product (whether physical or electronic). With bankcards contactless only is supported. The bank card should be presented for authentication onboard or at the gate. The card is checked against the deny list synchronized to all the terminals. The payment card itself is a ticket (‘credential’ for travel). The ticket inspection would check the presented card against the successfully validated card list on-board the vehicle or later in the back office.

Authentication: Authentication is the process of identifying and verifying that the card presented is genuine and not counterfeit. In transit payment context card authentication is required by the Visa MTT schema when the card is first seen. The transaction amount is zero.

Authorization: Authorization is the process of checking the credentials and details of the transaction. In the transit payment context, it includes checking that the card is valid, there are sufficient funds for the card, and the transaction is allowed to the cardholder and the limits are not exceeded. The authorization is required by the Mastercard and Maestro aggregated transit transaction rules when the card is seen the first time or the last authorization of the card was more than 14 days ago.

Debt recovery: A Transit “Debt recovery” transaction arises when transit fare spend has been incurred but – as a result of the issuer declining the authorization or authentication request – the transit merchant is initially unable to collect payment for the fare spent. When this situation occurs, the card is added to the deny list thereby blocking that card from access to travel until the money owed has been recovered.

A mechanism is therefore required by which a cardholder’s debt may be cleared so that that they may be removed from the deny list and allowed to resume travel. There are three debt recovery methods implemented in the PG:

• Automatic debt recovery – happens during the transit EOD process when the corresponding number of debt recovery days is reached.
• Merchant initiated debt recovery – happens when the cardholder requests to perform debt recovery through the customer support service, ticketing office, or the self-service channels.
• Tap-driven debt recovery – happens when terminal sends a tap initiated debt recovery request.

EOD processing: TPS will calculate the actual price charged from the card during the EOD processing.

Following transactionData.transactionType values can be used:


- TRANSIT_VALIDATION - Used for sending ticket validation transactions. The transaction should contain a ticket price. The AFC can provide the ticket price later via its backend too. At the end of the transit day, the sum of all ticket prices will be sent for the clearing.
- TRANSIT_VERIFICATION - Used for registering ticket verification transactions. No actual payment transaction will be made.
- TRANSIT_INSPECTION - Used for registering ticket inspection transactions. No actual payment transaction will be made.
- TRANSIT_REFUND - Used for refunding existing transit validation transaction
- TRANSIT_DEBT_RECOVERY_TAP - Used for performing tap initiated debt recovery
- TRANSIT_DEBT_RECOVERY_MERCHANT - Used for performing merchant initiated debt recovery

Tap initiated debt recovery

If card is in the deny list, then terminals can send a tap initiated debt recovery request to the TPS. This transaction type is realtime and terminals can make this request already before showing the tap result to the cardholder.

If tap initiated debt recovery is used then the following processing logic in the terminal side is recommended:

1. Terminal performs usual ticket validation tap (zero-amount transaction) with the card
2. If the card is expired or ODA wasn't successful, show negative response to the cardholder and stop processing
3. If the card is in deny list then:
   1. Send tap initiated debt recovery transaction to the TPS
   2. If tap initiated debt recovery request returns negative response then show negative response to the cardholder and stop processing
4. Show positive response to the cardholder
5. Store validation transaction in the terminal and send it later during the periodic data exchange to the TPS

---

MTT Check-In & Check-Out Transactions

MTT check-in & check-out solution is similar to the normal MTT solution. However, the cardholder has to present the bank card two times - once when entering and once when exiting the vehicle.

Check-in:

• transactionData.transactionType value TRANSIT_CHECK_IN
• Amount: initital amount to be pre-authorised

Check-out:

• transactionData.transactionType value TRANSIT_CHECK_OUT
• transactionData.initialTransactionUuid corresponsding to the initial check-in transaction UUID
• Amount: final amount

Refund:

• transactionData.transactionType value TRANSIT_REFUND
• transactionData.initialTransactionUuid corresponding to the initial check-in transaction UUID
• Amount: refund amount, not exceeding the total paid amount

Deny list

If a check-in authorisation fails, the card's PAN token will be immediately added to the deny list. It is the terminal provider's responsibility to ensure that check-out transactions are still allowed, even if the token appears on the deny list.

Two different check-in & check-out implementations can be used:

1. Biggest possible ticket price charged from the cardholder during check-in - lower risks but less comfortable for the traveller

2. Most possible ticket price charged from the cardholder during check-in - higher risks but more comfortable for the traveller

If the check-out amount is smaller than the check-in amount then a reversal will be done and the exceeding money will be returned to the cardholder.

💬 What happens if the cardholder forgets to do a check-out tap or it fails?

During EoD Sfey TPS will create a clearing for the check-in amount.

If TPS receives a check-out transaction after EoD, it adds the difference between the final amount and the initial amount to the card's currently open accumulated amount.

If MTT check-out transaction is the first transaction on a new transit day, then a new active card record is created and usual new tap processing is performed (nominal authorization or authentication).

Following transactionData.transactionType values can be used:

- TRANSIT_CHECK_IN - Used for registering check-in transaction. This amount is charged from the card if no check-out transaction is received (e.g. cardholder forgets to perform a check-out).
- TRANSIT_CHECK_OUT - Used for registering check-out transaction. The transaction should contain a ticket price for this  trip. The AFC can provide the ticket price later via its backend. At the end of the transit day the sum of all ticket prices will be sent for the clearing.
- TRANSIT_VERIFICATION - Used for registering ticket verification transactions. No actual payment transaction will be made.
- TRANSIT_INSPECTION - Used for registering ticket inspection transactions. No actual payment transaction will be made.
- TRANSIT_REFUND - Used for refunding existing transit validation transaction
- TRANSIT_DEBT_RECOVERY_TAP - Used for performing tap initiated debt recovery
- TRANSIT_DEBT_RECOVERY_MERCHANT - Used for performing merchant initiated debt recovery

---

Known Fare Transactions (KFT)

The Known Fare Transaction (KFT) model is a “pay as you go” model where the fare for each journey or ticket is known at the time the payment card is presented to the transit reader. It is also called retail-like payment.

The key characteristics of this model are:

• Transit readers accept contactless payments only (no chip & PIN or magnetic stripe) and must be capable of completing online Authorizations (in real-time or deferred).
• The amount of the fare charged is always known before the card is tapped.
• Transactions can be Authorized online or handled offline at the terminal according to Authorization rules and where market-specific floor limits allow.
• Transaction amounts are likely to be restricted to the market specific contactless Cardholder Verification Limit (CVL), since the reader has no PIN entry possibility.
• There is no special liability framework available like there is with the MTT model. All transactions must be Authorized before they may be submitted to Clearing.

KFT transactions can be sent also as realtime transactions. Then terminal should show the transaction status to the cardholder based by the response returned by the TPS. Transaction should be treated as successful only if TPS returns a response with the HTTP status code 200 and if the response field transactionResultData.actionCode value is 0XX (where X can be any digit). In all other cases, the transaction was not successful. If realtime KFT transaction is used then TPS doesn't do the deny list check (terminal is responsible for performing deny list check), and if the transaction fails, then the card will not be inserted to the deny list.

Following transactionData.transactionType values can be used:
      
- TRANSIT_KFT - User for registering deferred KFT transaction. The transaction should contain a ticket price for this trip.
- TRANSIT_KFT_REALTIME - User for registering realtime KFT transaction. The transaction should contain a ticket price for this trip.
- TRANSIT_VERIFICATION - Used for registering ticket verification transactions. No actual payment transaction will be made.
- TRANSIT_INSPECTION - Used for registering ticket inspection transactions. No actual payment transaction will be made.
- TRANSIT_REFUND - Used for refunding existing transit validation transaction
- TRANSIT_DEBT_RECOVERY_TAP - Used for performing tap initiated debt recovery
- TRANSIT_DEBT_RECOVERY_MERCHANT - Used for performing merchant initiated debt recovery

Tap initiated debt recovery

If card is in the deny list, then terminals can send a tap initiated debt recovery request to the TPS.

If tap initiated debt recovery is used, then the following processing logic in the terminal side is recommended:

1. The terminal performs the usual KFT tap (with the current ticket price) with the card
2. If the card is expired or ODA wasn't successful, show a negative response to the cardholder and stop processing
3. If the card is in deny list then:
   1. Show negative response to the cardholder
   2. Ask if the cardholder likes to recover the debt. If not then stop processing.
   3. Make a MTT zero-amount transaction with the card
   4. Send tap initiated debt recovery transaction to the TPS
   5. If tap initiated debt recovery request returns negative response, then show a negative response to the cardholder and stop processing
   6. Show positive response to the cardholder
   7. Remove the card from the local deny list and start KFT processing again from the beginning
4. If deferred KFT transaciton is used, then store validation transaction in the terminal and send it later during the periodic data exchange to the TPS
5. If realitme KFT transaction is used, then send realtime KFT transaction to the TPS and show a response to the cardholder based by the response from the TPS

---

RETAIL SOLUTION

Retail Transactions

The retail transaction model is an "online" model where processing is done immediately after the validation of the card. If validation fails then entry/ticket purchase for the cardholder is denied. If validation is successful then entry/ticket purchase for the cardholder is allowed.

    Following transactionData.transactionType values can be used:

   - RETAIL_PAYMENT
   - RETAIL_REFUND

Sfey internal processing:

• For every successful authorization corresponding message is added to the clearing.
• If authorization is cancelled with a reversal request (partially or fully) then corresponding reversal message is added to the clearing.

Retail Check-In & Check-Out Transactions

The retail check-in & check-out model is similar to the simple Retail model. However, the cardholder has to validate the payment card two times - when starting the travel period & when ending the travel period.

Check-in:

• transactionData.transactionType value RETAIL_CHECK_IN
• Amount: initital amount to be pre-authorised

Check-out:

• transactionData.transactionType value RETAIL_CHECK_OUT
• transactionData.initialTransactionUuid corresponsding to the initial check-in transaction UUID
• Amount: final amount

Two different check-in & check-out implementations can be used:

1. Biggest possible ticket price charged from the cardholder during check-in - lower risks but less comfortable for the traveller

2. Most possible ticket price charged from the cardholder during check-in - higher risks but more comfortable for the traveller

If the check-out amount is smaller than the check-in amount then a reversal will be done and the exceeding money will be returned to the cardholder.

Sfey internal processing:

• For all pre-authorizations made with the same card, TPS sends one clearing message for the total amount.
• If for some reason a successful pre-authorization was canceled with a reversal (either partially or fully), this will affect the total amount of the message given in the previous point. No separate reversal messages will be sent to clearing.
• If a successful pre-authorization is fully canceled with the reversal then TPS will not add reversal messages to the clearing.

Sfey internal processing:

• For all pre-authorizations made with the same card, TPS sends one clearing message for the total amount.
• If for some reason a successful pre-authorization was canceled with a reversal (either partially or fully), this will affect the total amount of the message given in the previous point. No separate reversal messages will be sent to clearing.
• If a successful pre-authorization is fully canceled with the reversal then TPS will not add reversal messages to the clearing.

💬 What happens if the cardholder forgets to do a check-out tap or it fails?

There are two possibilities if TPS does not receive the check-out tap (e.g. the cardholder forgets to make a check-out tap). Configurable on the TPS side for every organization:

1. TPS will automatically charge the maximum price specified in the check-in request.

2. TPS will refund the whole check-in amount. .

          Following transactionData.transactionType values can be used:
   
      - RETAIL_CHECK_IN
      - RETAIL_CHECK_OUT
      - RETAIL_REFUND