Card Present Connect | Mass Transit Developer Guide
This section describes how to use this guide and where to find further information.
Audience and Purpose
This guide is written for application developers who want to integrate payment processing
for mass transit fare collection systems. These services are available using only the REST
API.
Implementing these services requires software development skills and knowledge and
understanding of the card scheme mass transit rules. You must write code that uses the REST
API request and response fields to integrate the payment services into your existing mass
transit fare collection system.
Conventions
This statement is used in this document:
IMPORTANT
An
Important
statement contains information essential to successfully completing
a task or learning a concept.
Customer Support
For support information about any service, visit the Support Center:
Introduction to Card Present Connect | Mass Transit
Card Present Connect | Mass Transit is the
Cybersource
solution for
processing transactions using card scheme mass transit models.
Cybersource
mass transit processing is based on the global standards established by the card schemes for a reliable, scalable, and secure EMV contactless fare collection system.
Supported card types:
China UnionPay International
Rider Benefits
Mass transit riders should experience these benefits:
Retail-like experience where the contactless device and the reader communicate over
the contactless interface to perform a contactless transaction.
Fast, contactless tap to enter and exit.
Payment card data protection.
Single, combined payment for multiple trips during a set period, usually at the end
of the day.
Ability to request journey history and corresponding receipt.
Travel fare total on payment card statements.
Similar fare collection experience on multiple transit systems in other cities and countries.
Transit System Benefits
Mass transit systems will benefit in these ways:
Lower ticketing overhead without ticket booths or paper tickets.
Ability to track riders when they tap to enter and exit.
Flexible fare management
Riders pay as they go.
Fares are aggregated for one payment transaction each travel period.
Merchant protection.
Encrypted payment data.
First Ride Risk in supported regions.
Debt Recovery.
Mass Transit Terminology
Aggregated
Transaction in which you calculate the fare based on multiple contactless
card taps for trips during a predetermined time period, usually 24 hours,
processed as a single transaction.
Back office
A component within your transit systems that processes the taps received
from transit readers, and that performs any or all journey construction,
fare calculation, risk management, and payment processing.
Card hash
One-way hash token ID of the payment card data that is used to maintain the deny
list.
Combined data authentication (CDA)
Authentication technique that uses a combination of card and transaction data.
Deferred authorization
Combined authorization and capture request, also known as a sale, for aggregated fare payments.
Deny list
List of cards that failed ODA because of an unsuccessful AVR or transit
payment. It is used for blocking cards that have not been accepted for
travel within your transit system when you are processing aggregated
payments, such as the Mastercard PAYG and Visa MTT models.
Deny list manager
Manages the deny list and distributes it to the validators.
First ride risk debt recovery
Under specific and limited conditions established by the card schemes, you
can recover the cost of the first ride by capturing a declined
authorization. For details, refer to each of the card scheme's rules for
mass transit chargeback thresholds and protection.
The process of analyzing individual taps received from transit readers and forming logical journeys performed by cardholders.
Mobility and Transport Transaction (MTT)
Visa model for contactless mass transit payments for single or multiple
modes of transportation, which includes fixed, distance-based, and time-based
fares.
Offline data authentication (ODA)
EMV security feature in which payment cards are authenticated offline. ODA
is necessary so that cardholders can quickly tap and enter the transit
system. It is used for aggregated transactions, such as Mastercard PAYG and
Visa MTT.
Pay As You Go (PAYG) for Mastercard
Mastercard model in which the fare is not known when the cardholder taps
their card for travel. All cardholder taps are recorded to calculate the
fare and process an aggregated payment.
Payment instrument token
Token Management Service
token that stores the instrument identifier token,
card expiration date, and billing address.
Retail
Transaction in which you process the payment as a standard contactless
retail payment.
Tap
Refers to the act of presenting a contactless card at a validator.
Ticket inspection
Process in which ticket inspectors verify compliance with fare policies by checking paper tickets or using a portable terminal to read the payment card.
Ticket inspectors
Transit employees who travel on the transit system to verify passenger
travel status.
Transient token
Unique, time-limited token ID that is associated with the tokens created by TMS. The validator forwards this ID to your back office to use for payment transactions and to manage tokens.
Cybersource
automatically deletes this token after seven days.
Travel period
Period of time during which a traveler can make multiple taps in and out of
the transit system, before you submit the final payment transaction for the
aggregated amount.
Validator
EMV contactless card-present terminal located at an automated turnstile
device where cardholders tap their card to enter, and optionally exit from,
the transit system. Before allowing the cardholder to enter the transit
system, the validator checks the deny list to ensure that the card has not
failed ODA.
Mass Transit Prerequisites
Before integrating
Cybersource
services for mass transit, you must have
these systems in place:
Merchant account with an acquirer that is enabled for mass transit transactions on
Visa Platform Connect
.
Cybersource
account for payment services.
Payment technology provider (PTP) that is integrated with
Cybersource
and can perform message-level validation (MLV).
EMV Level 1 certified transit terminals and EMV Level 2 certified software in
preparation for EMV Level 3 Certification.
Mass Transit Transactions
Cybersource
offers these types of transactions for mass transit fare
collection and management.
This type of transaction uses a contactless terminal at points of access to the
transit service. The single fare model functions on a "pay as you go" basis, where each
journey's fare is individually processed after every trip. Since the fare might not be
known at the time of tapping, both tap-in and tap-out data are collected and sent to the
transit system.
Figure:
Single Fare Transaction Flow
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. Each
fare is calculated at the end of a trip. The fares are then aggregated together and
charged to the customer at the end of a travel period or when the aggregated fare limit
is breaches.
The travel period is also called as Maximal Travel Time (MTT) which should not exceed
beyond 14 days. The aggregated total fare limit is called as Cumulative Spend Limit
(CSL). The Cumulative Spend Limit (CSL) is decided by the merchant.
Figure:
Aggregated Fare 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
Stand Alone Credit
A
stand-alone credit
is a credit that is not linked to a capture. There is no time
limit for requesting a stand-alone credit.
When a request for a credit is successful, the issuing bank for the payment card takes
money out of your merchant bank account and returns it to the customer. It usually takes
two to four days for your acquiring bank to transfer funds from your merchant bank
account.
Carefully control access to the credit service. Do not request this service directly from
your customer interface. Instead, incorporate this service as part of your customer
service process.
First Ride Risk
First Ride Risk (FRR) refers to the liability for the first use of a payment credential
that fails pre-authorization and might result in a refusal for travel. With FRR,
Cybersource
allows you to capture a pre-authorization that fails.
The merchant or acquirer bears responsibility for FRR.
First Ride Risk Eligibility Reason Codes
When a failed pre-authorization returns one of these response codes in the
processorInformation.responseCode
field, the transaction is
eligible for FRR and capture:
01
: Refer to card issuers.
04
: Pick-up.
05
: ID certification fails.
12
: Invalid related transaction.
13
: Invalid amount.
14
: Invalid card number (no such account).
21
: Card not initialized.
22
: Suspected malfunction, related transaction error.
34
: Fraud.
38
: PIN try limit exceeded.
40
: Function requested not supported.
41
: Lost card.
43
: Stolen card.
57
: Transaction not allowed to be processed by cardholder.
58
: Transaction not allowed to be processed by terminal.
59
: Suspected fraud.
62
: Restricted card.
68
: Issuer response timeout.
75
: Allowable number of PIN tries exceeded.
90
: Cutoff is in progress.
91
: Issuer cannot process.
97
: ATM/POS terminal number cannot be located.
98
: Issuer response not received.
99
: PIN block error.
1A
: The transaction needs additional customer
authentication.
A0
: MAC failed.
N1
: Items not on Bankbook beyond limit, declined.
P1
: Contact phone number of cardholder cannot be found in the
issuer’s system.
Test Cards
You can request these payment services for mass transit with EMV and card data:
Authorization and capture for aggregate fares and debt recovery
The single fare workflow begins when the rider taps a payment card at the fare collection
terminal. It is a
pay as you go
model, where each trip's fare is processed
individually after each trip.
Figure:
Single Fare Transaction Flow
The cardholder taps the card to enter the transit system.
The gate validates the card using offline data authentication (ODA), the card
expiration date, and the deny list.
When the card is valid, the gate allows the passenger to enter the transit
system.
When the ODA fails, the card is added to the deny list, and the debt recovery
process begins. See Debt Recovery Workflows.
You send an authorization request for a nominal amount.
When the authorization is successful, you calculate the fare for the travel
period.
You submit a purchase request via
Cybersource
.
Aggregated Fare Workflow
This type of transaction occurs at a contactless terminal at a point of access to the
transit service. The final fare charged is not always available 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
The cardholder taps the card at a terminal to enter the transit system.
The gate validates the card using offline data authentication (ODA), the card
expiration date, and the deny list.
You send an authorization request for a nominal amount.
You calculate and aggregate subsequent trip fares for the customer until the
Cumulative Spend Limit (CSL) or Maximum Travel Time (MTT) is reached.
If the CSL or MTT is exceeded, you request an additional authorization
request.
You submit a purchase request for the cumulative trip fares to
A debt recovery transaction is required so that you can retrieve outstanding debt if the
end-of-day transaction is declined. A debt recovery transaction is also required in
order to remove a card from a deny list. You must remove the card from the deny list
within one hour of receiving the authorization approval. These are the ways to recover
debt:
Scheduled transaction, resubmitted using the card number.
Tap-initiated transaction using the EMV track 2 equivalent and EMV tags created
when the cardholder returns to enter the transit system.
Cardholder-initiated transaction through an e-commerce website.
When the debt recovery transaction is declined, you can request payment using the first
ride risk liability model. See the card scheme rules for mass transit transaction
chargebacks.
Scheduled Debt Recovery
A scheduled debt recovery is a system-generated transaction that originates from your
back office. This transaction typically references the original declined end-of-day
transaction and uses the card number. Multiple authorization resubmissions might be
triggered within 14 days.
Figure:
Scheduled Debt Recovery Flow
You set up a scheduled debt recovery authorization request process within your
operating system.
The scheduled authorization(s) attempt debt recovery submissions within 14 days
of the initial transaction.
When the amount exceeds the debt recovery amount limit, the card remains on the
deny list.
When the amount is below the debt recovery amount limit, send a sale
request.
When the transaction is declined, keep the card on the deny list.
When the transaction is successful, remove the card from the deny list.
Tap-Initiated Debt Recovery
Tap-initiated debt recovery occurs when the cardholder returns to the transit gate,
and the validator recognizes a new contactless tap.
You can deny the rider entrance unless the tap-initiated debt recovery is attempted
in real time while the cardholder is at the gate. The authorization request uses the
EMV track 2 equivalent and EMV tags from the new tap and includes a future capture
date.
Figure:
Tap-Initiated Debt Recovery Flow
The cardholder taps their card to enter the transit system.
You submit a new authorization request using the EMV track 2 equivalent and
EMV tags created by the validator and a capture date in the future.
When the transaction is declined, keep the card on the deny list.
When the transaction is successful, remove the card from the deny list.
Cardholder-Initiated Debt Recovery
Cardholder-initiated debt recovery occurs when the cardholder contacts you for debt
recovery.
Cardholder contacts you through your website or by phone call.
You process a card-not-present authorization.
When the request is successful, remove the card from the deny list.
When the request fails, leave the card on the deny list.
Mass Transit Payment Services Using TMS Tokens
You can use TMS tokens to request these mass transit payment services:
Authorization and capture for aggregate fares and debt recovery
Sale for single fares and debt recovery
First ride risk
Stand-alone credit
In the card-present EMV contactless request, include the transient token ID in the
tokenInformation.jti
field in place of track 2 data.
When submitting a tap token creation request, you can include EMV tag-length-value (TLV)
tags in the
paymentInformation.fluidData.value
field or as part of
the payment transaction request within the
pointOfSaleInformation.emv.tags
field.
If you send EMV tags in the tap token create request, do not send EMV tags in the
payment transaction request.
When EMV TLV tags are present in both the payment transaction and the token vault,
Cybersource
reads the value provided in the payment transaction
rather than the values stored in the vault.
Mastercard EMV transactions include three field values that can be handled automatically:
paymentInformation.card.initiationChannel
pointOfSaleInformation.emv.cardSequenceNumber
pointOfSaleInformation.serviceCode
Your account can be configured to read these values automatically from the EMV TLV
tags and track 2 equivalent. When that option is enabled, do not include those three
fields in EMV payment requests.
If any of these values are present in both the separate fields and the EMV
TLV and track 2 equivalent,
Cybersource
reads the value provided in the
separate fields rather than the values present in the EMV TLV and track 2
equivalent.
Merchant initiated card-not-present payment requests use the
paymentInformation.instrumentIdentifier.id
field instead of the
card number.
Figure:
Payment Processing with a Token
Pre-Authorization with a Token
This section describes how to process a pre-authorization.
Endpoint
Production:
POST
https://api.cybersource.com
/pts/v2/payments
Test:
POST
https://apitest.cybersource.com
/pts/v2/payments
Required Fields for a Pre-Authorization with a Token Using the REST API
Mass Transit Tap-Initiated Sale for Debt Recovery with a Token
This section describes how to process a tap-initiated sale for debt recovery with a token.
A sale transaction is a bundled authorization and capture. When a cardholder attempts to
use a blocked card at the transit reader, create a fresh debt recovery sale request
using the chip data from the new tap, along with the fare amount of the previous
declined authorization.
Endpoint
Test:
POST
https://apitest.cybersource.com
/pts/v2/payments
Production:
POST
https://api.cybersource.com
/pts/v2/payments
Required Fields for a Tap-Initiated Sale for Debt Recovery with a Token Using the REST
API
This section describes how to process a refund. A refund is linked to a capture or sale.
You must request a refund within 180 days of the authorization.
For
China UnionPay
, use the refund service to reverse pre-authorization completions and sales.
Endpoint
Production:
POST
https://api.cybersource.com
/pts/v2/payments/
{id}
/refunds
Test:
POST
https://apitest.cybersource.com
/pts/v2/payments/
{id}
/refunds
The
{id}
is the transaction ID
returned in the capture or sale response.
Response to a Failed Request for Refund When a Refund is Not Allowed for First Ride
Risk
{
"id": "7078037920207111957011",
"submitTimeUtc": "2024-02-13T05:56:33Z",
"status": "INVALID_REQUEST",
"reason": "INVALID_DATA",
"message": "Decline - The referenced request id is invalid for all follow-on transactions."
}
Voiding a Capture
This section describes how to void a capture that was submitted but not yet processed by the
processor.
Endpoint
Production:
POST
https://api.cybersource.com
/pts/v2/captures/
{id}
/voids
Test:
POST
https://apitest.cybersource.com
/pts/v2/captures/
{id}
/voids
The
{id}
is the transaction ID returned in the
capture response.