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
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
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
-
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.
Additional Documentation
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
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
.
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.
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
|
Mastercard Mass Transit Model
The Mastercard mass transit transaction model is Mastercard Pay As You Go. See Mastercard Pay As You Go.
Visa Mass Transit Model
The Visa mass transit transaction model is Visa Mobility and Transport Transactions (MTT). See Visa Mobility and Transport Transaction.
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
|