Aggregated Model with the Token Management Service

When you integrate aggregated acceptance models with the
Token Management Service
 (
TMS
), customer and payment data is tokenized, securely stored, and managed by
TMS
, which simplifies your Payment Card Industry Data Security Standard (PCI DSS) compliance for storing, processing, or transmitting cardholder information. PCI DSS compliance requirements are for establishing and maintaining a reliable and secure payment processing environment.
You can use
TMS
 to store these types of data:
  • EMV track 2 equivalent
  • EMV tag-length-value (TLV) string of tags for use during payment authorization
  • Card number (
    TMS
     instrument identifier)
  • Card hash value (used within deny list management systems)
TMS
 uses a cryptographic base derivation key (BDK) to create tokens that represent the customer and payment data. You store these tokens in your environment and databases instead of customer payment details.
The aggregated model with
TMS
 begins with the first tap of the card.

Figure:

Transit Transactions with
TMS
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.

AVR Process with
TMS

This 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 a verification request as required by the card scheme transit model.
  4. The back office uses the transient token ID for these requests:
    • Retrieving the token IDs for debt recovery and BIN lookup requests
    • Performing an AVR, deferred authorization, and follow-on transactions

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.