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 (TMSinstrument 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. Figure:
Transit Transactions with
TMS
The aggregated model with
TMS
begins with the first tap of the
card.First Tap Process with TMS
TMS
This process begins when the rider taps their card at the validator.
- Rider taps card at the validator.
- The terminal uses the Level 3 payment application to generate a card hash and checks the deny list for the card hash.
- When the card hash is on the deny list, the card is not approved for travel and the terminal does not open the gate.
- 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.
- The rider performs additional taps as required by the transit system during the travel period.
AVR Process with TMS
TMS
This process begins when the validator sends the transient token data to the back
office.
- The validator sends this tap data toTMSto tokenize the data:
- Transient token, in the ID field
- Card hash
- Fluid data descriptor, encoding, and value
- TMScreates tokens of the tap data and stores the card hash with the tokens.
- The back office performs a verification request as required by the card scheme transit model.
- 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
TMS
This process begins at the end of the travel period.
- 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.
- If the authorization fails, the back office retrieves the card hash fromTMS, adds the card hash to the deny list, and begins the debt recovery process.
Debt Recovery Process with TMS
TMS
This process begins when your back office requests debt recovery.
- 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.
- When debt recovery is successful, the back office uses the card hash token to retrieve the full card hash value.
- The back office removes the card hashes from the deny list.
- When the debt recovery fails, the associated card hashes stay on the deny list.