On This Page
FILTER BY TAG

Aggregated Model with the
Token Management Service
 Workflow

The Aggregated Model with
TMS
 workflow begins when the rider taps a payment card at a fare collection reader (terminal) in the transit system.

Figure:

Transit Transactions with
TMS
 Workflow
Diagram of transit transactions with the Token Management Service

First Tap Process with
TMS

This process begins when the rider taps their card at the validator.
  1. Rider taps card at the validator.
  2. The terminal uses the Level 3 payment application to generate a card hash and checks the deny list for the card hash.
  3. When the card hash is on the deny list, the card is not approved for travel and the terminal does not open the gate.
  4. When the card hash is not on the deny list, the card is approved for travel and the terminal opens the gate and begins the account verification request (AVR) process.
  5. The rider performs additional taps as required by the transit system during the travel period.

Account Verification Request Process with
TMS

The account verification request (AVR) process begins when the validator sends the transient token data to the back office.
  1. The validator sends this tap data to
    TMS
     to tokenize the data:
    • Transient token, in the ID field
    • Card hash
    • Fluid data descriptor, encoding, and value
  2. TMS
     creates tokens of the tap data and stores the card hash with the tokens.
  3. The back office performs an AVR as required by the card-scheme transit model.
  4. The back office uses the transient token ID to process these requests:
    • Perform EMV payments as required by the card-scheme transit model.
    • Retrieve the instrument identifier token so that the instrument identifier (masked PAN) can be retrieved, enabling card-not-present (CNP) transactions to be performed. Merchant-initiated debt recovery is an example of this type of CNP transaction.
    • Retrieve the payment instrument token so that the payment instrument (full unmasked card hash) can be retrieved. This data might be required when updating the deny list.

End of Travel Period Process with
TMS

This process begins at the end of the travel period.
  1. At the end of the travel period, the back office calculates the fare and sends a deferred authorization, which can be a combined authorization and capture, using the transient token ID in place of the card data.
  2. If the authorization fails, the back office retrieves the card hash from
    TMS
    , adds the card hash to the deny list, and begins the debt recovery process.

Debt Recovery Process with
TMS

This process begins when your back office requests debt recovery.
  1. In accordance with the relevant card scheme rule set, the back office requests a merchant-initiated debt recovery using the instrument identifier token ID in place of a card number.
  2. When debt recovery is successful, the back office uses the card hash token to retrieve the full card hash value.
  3. The back office removes the card hashes from the deny list.
  4. When the debt recovery fails, the associated card hashes stay on the deny list.
RELATED TO THIS PAGE