Mass Transit Transactions

Cybersource
 offers two types of transactions for mass transit fare collection and management, aggregated and debt recovery.

Aggregated

This type of transaction uses a contactless terminal at points of access to the transit service. The final fare charged is not always known at the time of travel. It is calculated at the end of a travel period (typically 24 hours) based on journeys made during that period.

Figure:

Aggregated Transaction Flow
Diagram that illustrates an aggregated transit transaction.
Mass Transit Transactions

Debt Recovery

This type of transaction retrieves outstanding debt in the event of a decline of the aggregated, end-of-day transaction. A debt recovery transaction is also required in order to remove a card from a deny list. Card schemes require you to process merchant-initiated debt recovery. You can also offer tap-initiated debt recovery at the transit entry point or cardholder-initiated debt recovery online.

Figure:

Merchant-Initiated Debt Recovery Flow
Diagram that illustrates a merchant-initiated debt recovery.
Mass Transit Transactions

Card Types and Transaction Models

These card types, transaction types, and acceptance models are supported.

American Express

  • Aggregated
    • Pay As You Go (PAYG) delayed authorization with the Expresspay transit policy

Mastercard

  • Aggregated
    • Pay As You Go (PAYG)

Visa

  • Aggregated
    • Mobility and Transport Transaction (MTT)

All Card Types

  • Debt Recovery
    • First ride risk
    • Merchant Initiated
    • Tap Initiated
    • Cardholder Initiated
Mass Transit Transactions

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.
Mass Transit Transactions

Multiple Accounts for Processing Functions

Mass transit systems can have multiple accounts for each processing function.
Account 1
: Processes tap token create only. For this option, the validators communicate directly with
Cybersource
. Using a separate account allows you to deploy a separate security key to the validator system.
Account 2
: Processes payment requests using tokens. You can also choose to further separate debt recovery transactions from standard payment transactions. In that case,
account 2a
 is dedicated to standard payment transactions, and
account 2b
 is dedicated to debt recovery transactions.
Account 3
: Processes card hash retrieval requests only. The responses include the full unmasked card hash value. Using a separate account allows you to deploy a separate security key to the validator system.
Account 4
: Operates a customer service web portal where riders make journey history enquiries. The riders provide the card number to a hosted payment service (such as
Cybersource
 Secure Acceptance) where they register themselves. Registration produces the
TMS
 instrument identifier token and the card scheme PAR value. These values can be used by your back office system to look up journey and billing information.

Figure:

Journey History Request with Token Creation
Process diagram of the process journey history service using tokens.
Mass Transit Transactions

Journey History Service

Transit models include journey history services, in which cardholders can request information about their journeys and billing. Standard systems use the card number and payment account reference number (PAR) to find the information requested by the cardholder. When you integrate the
Token Management Service
, the instrument identifier token or payment account reference number (PAR) is used to retrieve journey history.
For documentation regarding
Cybersource
 card-not-present services that might be deployed to support a transit system journey history service, see the
Payments Developer Guide
 .
Mass Transit Transactions

American Express Mass Transit Model

The American Express mass transit transaction model that is American Express PAYG with delayed authorization using Expresspay transit policy. See American Express Pay As You Go.
Characteristics of the American Express PAYG Model
Characteristic
PAYG with Delayed Authorizations
Dedicated transit merchant category code (MCC) values
M
Population of transit access terminal indicator
M
Decline expired cards
M
Decline expired cards
M
Deny list capability
M
Transaction aggregation
O
Account status check
M
Enhanced risk mitigation
O
Application transaction counter (ATC) synchronization
O
PAN translation
O
Mass Transit Transactions

Mastercard Mass Transit Model

The Mastercard mass transit transaction model is Mastercard Pay As You Go. See Mastercard Pay As You Go.
Mass Transit Transactions

Visa Mass Transit Model

The Visa mass transit transaction model is Visa Mobility and Transport Transactions (MTT). See Visa Mobility and Transport Transaction.
Characteristics of the Visa MTT Model
Characteristics
MTT
Designed for very high customer throughput.
Yes
Fare amount always known at the time the journey is started.
No
Transit reader accepts contactless payments only.
Yes
Intended for complex fares, including “capping” or multimodal.
Yes
Allows accumulation of multiple journeys into a single transaction.
Yes
Account verification requests (AVRs) performed on card’s first use.
Yes
Special liability model included (chargeback threshold).
Yes
Requires declined cards to be blocked using deny lists.
Yes
Requires merchant back office for fare calculation.
Yes
Intended authorization model.
Deferred
Authorization resubmissions for debt recovery.
Yes
Mass Transit Transactions