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.
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.
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. 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. Journey History Service
Card schemes might require transit operators to provide cardholders with a journey
history service that enables the cardholder to view their journey history and receipt
information. Refer to card scheme documentation for more information about each card
scheme's requirements for journey history.
Payment Account Reference
Cybersource
supports the use of the payment account reference (PAR)
by providing the PAR value in authorization responses when a PAR is available from
the card issuer. The PAR response field is
processorInformation.paymentAccountReferenceNumber
. Using the
PAR enables you to track card accounts when digital devices, such as smart phones
and smart watches, have a network token or device PAN (DPAN) that the card issuer
provided to the device. You can use the PAR to provide journey history to
cardholders and to match the card account funding PAN (FPAN) and device PAN (DPAN)
values.Merchant Descriptor
You can use the merchant descriptor feature to produce a transaction-specific reference
that cardholders can see on their card account statement. To use the merchant
descriptor feature, include the
merchantInformation.merchantDescriptor.name
field in your
authorization, credit, and capture requests. The value for the field must consist
solely of English characters.Before implementing transit journey history functionality, confirm with your acquirer and card schemes that the PAR and merchant descriptor features are supported.
For documentation regarding
Cybersource
card-not-present services that you can use 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 |