Mass Transit

Card Present Connect | Mass Transit is the solution for processing transactions using card scheme mass transit models. This solution follows global card scheme standards for contactless EMV transit transactions.

Supported Card Types

The Mass Transit solution supports these card types. For more information, see Mass Transit Models and Workflows.

• American Express

• Discover (US only)
• Mastercard
• Visa

Transit Rider Benefits

These are some transit rider benefits:

• Retail-like contactless payment experience.
• Fast, contactless tap to enter and exit.
• Payment card data protection.
• Single, combined payment for multiple trips during a set period.
• Ability to request journey history and corresponding receipt.
• Travel fare total on payment card statements.
• Consistent fare collection experience across transit systems in various cities and countries.

Transit System Benefits

These are some mass transit systems benefits:

• Lower ticketing overhead that can reduce the need for ticket booths or paper tickets.
• Ability to track riders when they tap to enter and exit.
• Flexible fare management, including:
  • Riders pay as they go.
  • Fares are aggregated for one payment transaction each travel period.
• Merchant protection such as:
  • Encrypted payment data.
  • First Ride Risk support in some regions. For eligibility details, see First Ride Risk.
  • Debt recovery support.

Mass Transit Validation and Certification

You must complete validation and certification activities before your system moves to production. Work with your payment technology provider (PTP) to complete message-level validation (MLV) and EMV Level 3 certification of your transit fare processing system. You must pass MLV before beginning EMV Level 3 certification.

Message-Level Validation

Message-level validation (MLV) is a script-based, field-level validation against specifications.

Your PTP uses amount-based test triggers to send transactions into a test environment and the Visa Certification Management System for decryption. The test results are XML or RESTful output, test transactions, and log prints.

These activities are used to validate the results:

• Cross edit checks
• Data element validation
• Interchange compliance
• Data mapping validation

EMV Level 3 Certification

This section describes the Level 3 certification process used by and . The certification processes and support for Global Card Present Connect projects and for direct merchant and acquirer projects differ from what is described here, but the timelines are basically the same.

Certification is a formal process used to validate that the device and application are compliance with card scheme acceptance regulations. The certification team uses a brand test tool and simulator during the certification process, which includes these elements:

• A payment card simulation tool such as UL, ICC, or Fime.
• Failed case analysis and resolution.
• For Mastercard certification, your PTP submits results to Mastercard and pays the costs for approved partners that Mastercard uses.
• For Visa certification, submits results to Visa.
• Waivers from the card schemes for exceptions.
• Card schemes responses or Letter of Approval (LOA) to signify acceptance and Level 3 certification.

For information about how to design an EMV Level 3 certified payment application, see EMV Book 3 Application Specification.

Mass Transit Models and Workflows

The Mass Transit solution supports a variety of payment models and workflows for transit fare collection and management.

This section describes card-specific mass transit models and workflows. Each card type has a distinct mass transit model and transaction workflow that defines how fares are authorized, processed, and settled. Common workflows that are not card specific are also discussed.

American Express Mass Transit Model

The American Express mass transit model is American Express Pay As You Go (PAYG). It is a delayed authorization model that uses the Expresspay transit policy workflow.

American Express Pay As You Go Model Capabilities and Features

This section describes the capabilities and features of the American Express PAYG model.

This table lists the required (M) and optional (O) capabilities of this mass transit model:

These are the key features of the American Express PAYG model:

• Journeys are multimodal.
• Fares are based on distance.
• Points of entry are contactless.
• Accounts are verified with an authorization for a nominal amount or the maximum fare amount.
• The deny list is checked so that cardholders with previously declined transactions can be blocked.
• Data can be authenticated offline to confirm that the card is valid.
• Multiple card taps and fares can be aggregated into a single payment.
• The deny list is automatically updated every 20 minutes.
• The back office records all trips and fares to reconstruct journeys and calculate the final fare.
• When the nominal amount authorization is declined, debt recovery can be performed.
• Standard follow-on payment services can be used to capture, reverse, or void transactions.

American Express Pay As You Go Workflow

American Express PAYG is a delayed authorization model that uses the Expresspay transit policy workflow. It begins when the rider taps a payment card at the fare collection terminal.

1. The cardholder taps the card to enter the transit system.
2. The gate validates the card using offline data authentication (ODA), the card expiration date, and the deny list.
3. When the card is valid, the gate allows the passenger to enter the transit system.
4. When the ODA fails, the card is added to the deny list, and the debt recovery process begins (see Debt Recovery Workflows).
5. You send an authorization request for a nominal amount. For authorization and capture options, see American Express Authorization and Capture Options.
6. When the authorization is successful, you calculate the fare for the travel period.
7. At the last tap of the day, submit a follow-on capture request for the day's aggregated fare amount.

American Express Authorization and Capture Options

American Express Pay As You Go supports two options for handling authorizations and captures. Implement the option that suits your business model.

The process begins with an authorization request for a nominal amount. During the travel period, the merchant collects the rider's tap data to calculate the aggregated fare, and then chooses one of these options:

• Option 1: When the floor limit is reached, send a capture request to collect the accumulated amount.
• Option 2: When the number of trips exceeds the floor limit, send a delayed online authorization request.

After receiving a successful response, this process repeats to handle subsequent trips and journeys.

Discover Pay As You Go Model

The Discover transaction model is Discover Pay As You Go (PAYG).

Discover Pay As You Go Model Features

These are the key features of the Discover PAYG model:

• Journeys are multimodal.
• Fares are based on distance.
• Points of entry are contactless.
• Accounts are verified with an authorization for a nominal amount or the maximum fare amount.
• The deny list is checked so that cardholders with previously declined transactions can be blocked.
• Data can be authenticated offline to confirm that the card is valid.
• Token Management Service (TMS) option for managing sensitive authentication data (SAD).
• Multiple card taps and fares can be aggregated into a single payment.
• The deny list is automatically updated every 20 minutes.
• The back office records all trips and fares to reconstruct journeys and calculate the final fare.
• When the nominal amount authorization is declined, debt recovery can be performed.
• Standard follow-on payment services can be used to capture, reverse, or void transactions.

Discover Pay As You Go Model Workflow

The Discover PAYG workflow begins when the rider taps a payment card at the fare collection terminal.

1. The cardholder taps the card to enter the transit system.
2. The gate validates the card using offline data authentication (ODA), the card expiration date, and the deny list.
3. When the card is valid, the gate allows the passenger to enter the transit system.
4. When the ODA fails, the card is added to the deny list, and the debt recovery process begins (see Debt Recovery Workflows).
5. You send a Discover Authorization request for a nominal amount.
6. When the authorization is successful, you calculate the fare for the travel period.
7. When the fare is more than 15.00 USD, a Discover Authorization or Discover Sale request for the higher amount is sent.
8. At the last tap of the day, a follow-on capture request for the day's aggregated fare amount is sent.

Discover Pay As You Go Aggregated Transactions

When the cardholder taps their Discover card in a transit system, initiate an aggregated transaction by requesting an authorization for 1.00 USD that includes the processingInformation.authorizationOptions.aggregatedAuthIndicator field set to true.

If the issuer approves the authorization, subsequent taps do not require an authorization. The capture amount must not exceed 15.00 USD in the US, and the capture date must not exceed the aggregation duration of up to 14 days from the first tap transaction.

If the aggregate total nears the maximum aggregation amount, and the next tap will cause the aggregation amount to exceed 15.00 USD, capture the existing aggregate total. Then, authorize the current tap for 1.00 USD to begin a new aggregation cycle, and include the processingInformation.authorizationOptions.aggregatedAuthIndicator field set to true.

For more information about Discover aggregated transactions, see the Discover Global Network Contactless D-PAS: Open Loop Transit Implementation Guide.

Mastercard Pay As You Go Model

The Mastercard transit transaction model is Mastercard Pay As You Go (PAYG).

Mastercard Pay As You Go Model Features

These are the key features of the Mastercard PAYG model:

• Journeys are multimodal.
• Fares are based on distance.
• Points of entry are contactless.
• Accounts are verified with an authorization for a nominal amount or the maximum fare amount.
• The deny list is checked so that cardholders with previously declined transactions can be blocked.
• Data can be authenticated offline to confirm that the card is valid.
• TMS option for managing sensitive authentication data (SAD).
• Multiple card taps and fares can be aggregated into a single payment.
• The deny list is automatically updated every 20 minutes.
• The back office records all trips and fares to reconstruct journeys and calculate the final fare.
• When the nominal amount authorization is declined, debt recovery can be performed.
• Standard follow-on payment services can be used to capture, reverse, or void transactions.

Mastercard Pay As You Go Workflow

The Mastercard PAYG workflow begins when the rider taps a payment card at the fare collection terminal.

1. The cardholder taps the card to enter the transit system.
2. The gate validates the card using Mastercard combined data authentication (CDA), card expiration date, and the deny list.
3. When the card is valid, the gate allows the passenger to enter the transit system.
4. When the CDA fails, the card is added to the deny list, and the debt recovery process begins (see Debt Recovery Workflows).
5. You send a Mastercard Authorization request for a nominal amount.
6. When the authorization is successful, you calculate the fare for the travel period and submit a sale request at the end of the travel period.

Visa Mass Transit Model

The Visa transit transaction model is Visa Mobility and Transport Transactions (MTT).

Visa Mobility and Transport Transaction Model Capabilities and Features

This section describes the capabilities and features of the Visa MTT model.

This table lists the capabilities of this mass transit model:

These are the key features of the Visa MTT model:

• Journeys are multimodal.
• Fares are based on distance.
• Points of entry are contactless.
• Accounts are verified with an account verification request (AVR) authorization for a nominal amount or the maximum fare amount.
• The deny list is checked so that cardholders with previously declined transactions can be blocked.
• Data can be authenticated offline to confirm the card is valid.
• TMS option for managing sensitive authentication data (SAD).
• Multiple card taps can be aggregated into a single payment.
• The back office manages the deny list and distributes them to terminals.
• The back office records all trips and fares to perform journey reconstruction to calculate the final fare.
• Standard follow-on payment services can be used to capture, reverse, or void transactions.
• First ride risk protection when the first authorization fails.
• When the AVR authorization is declined, debt recovery can be performed.

Visa Mobility and Transport Transaction Workflow

The Visa MTT workflow begins when the rider taps a payment card at the fare collection terminal.

1. The cardholder taps the card to enter the transit system.
2. The validator checks the deny list to determine card validity, and allows the rider to enter the transit system.
3. The back office submits a Visa Account Verification Request (AVR) to .
4. When the authorization fails, the card is added to the deny list, and the debt recovery process begins (see Debt Recovery Workflows).
5. During the travel period, the back office collects the rider's tap data to calculate the fare.
6. At the end of the travel period, the back office submits a deferred authorization and capture request (see Fare Calculation and Submission Workflow).

Common Mass Transit Workflows

This section describes mass transit transaction workflows and features that are common across supported card schemes.

Aggregated Fare Transaction Workflow

This section describes the Aggregated Fare transactions workflow. In this workflow, the final transit fare is not always known at the time of travel. It is calculated at the end of a travel period, typically 24 hours, based on the journeys made during that period and any applicable fare limits. An aggregated transaction is used on contactless terminals at transit system access points to support fare calculation after the travel period has ended.

Aggregated Model with the Token Management Service

Using tokens can reduce the amount of cardholder information that your systems store, process, or transmit. This approach can simplify your Payment Card Industry Data Security Standard (PCI DSS) compliance efforts for maintaining a secure payment processing environment.

When you integrate aggregated acceptance models with the Token Management Service (TMS), TMS tokenizes, stores, and manages customer and payment data. You store these tokens in your environment instead of customer payment details.

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.

Aggregated Model with the Token Management Service Workflow

The Aggregated Model with TMS workflow begins when the rider taps a payment card at a fare collection reader (terminal) in the transit system.

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.

Near Real-Time Workflow

The near real-time workflow begins when the cardholder taps a payment card at the validator to enter the transit system.

1. The validator checks the deny list for the payment card.
2. When the card is on the deny list due to a previous failed payment, the validator does not open the gate, and the payment is processed through a debt recovery workflow (see Debt Recovery Workflows).
3. When the card is not on the deny list, the validator opens the transit gate for the cardholder to travel.
4. A new transient token is generated for processing the account verification request (AVR).
5. The back office sends an account verification request (AVR) to .
6. When the AVR fails, the card is added to the deny list and might be eligible for the first ride risk debt recovery. For eligibility details, see First Ride Risk.
7. When the AVR is successful, the card data is used to track subsequent taps, calculate fares for the day, and capture the deferred authorization.

Fare Calculation and Submission Workflow

The fare calculation workflow begins at the end of the travel period.

1. The back office calculates the fare of all rides taken during the travel period.
2. You request a Visa Deferred Sale transaction for the accumulated fare.
3. When the sale is successful, the process is complete.
4. When the sale is declined, the card hash is added to the deny list.
5. When the declined sale amount is above the chargeback threshold, the transaction is moved to debt recovery (see Debt Recovery Workflows).
6. When the declined sale amount is for a first ride and below the chargeback threshold, you can request the payment using the First Ride Risk chargeback rules as defined by each card scheme. For eligibility details, see First Ride Risk.

Debt Recovery Workflows

Debt recovery workflows show how to use debt recovery transactions to collect outstanding debt when an aggregated end-of-day transaction is declined.

Card schemes require merchants to support merchant-initiated debt recovery. This type of transaction can also be required to remove a card from a deny list. Each card scheme has its own transaction-processing rules for debt recovery retry attempts, transaction time limits, and related mass transit transactions. For more information, see each card scheme's rules for transit debt recovery retry attempts and transaction time limits.

These debt recovery transactions are supported:

• A merchant-initiated transaction that uses the card number.
• A scheduled transaction that uses the card number.
• A tap-initiated transaction that uses the EMV track 2 equivalent and EMV tags created when the cardholder re-enters the transit system.
• A cardholder-initiated transaction that the customer requests by contacting you.

When a debt recovery transaction is declined, you can request payment using the First Ride Risk liability model. For eligibility details, see First Ride Risk. For more information about chargebacks, see each card scheme's rules for mass transit transaction chargebacks.

Merchant-Initiated Debt Recovery

A merchant-initiated (MIT) debt recovery transaction is a deferred authorization that originates from your back office. This type of transaction is also called auto-debt recovery. The authorization resubmission typically uses the card number and references the original, end-of-day transaction that was declined. Visa allows up to six authorization resubmissions within 14 days.

1. When the number of retry attempts for the MIT debt recovery transaction exceeds the card scheme's limit, stop further processing and keep the card on the deny list.
2. When the amount is below the debt recovery amount limit, send a Merchant-Initiated Sale for Visa Debt Recovery request.
3. When the transaction is declined, keep the card on the deny list.
4. When the transaction is successful, remove the card from the deny list.

Scheduled Debt Recovery Transaction Resubmission

A scheduled debt recovery transaction is a system-generated transaction that originates from your back office. This transaction typically uses the card number and references the original, end-of-day transaction that was declined. Multiple authorization resubmissions might be triggered within 14 days.

1. You configure your payment system to generate scheduled debt recovery authorization requests.
2. The scheduled authorizations attempt debt recovery submissions within 14 days of the initial transaction.
3. When the number of retry attempts for the scheduled debt transaction exceeds the card scheme's limit, stop further processing and keep the card on the deny list.
4. When the amount is below the debt recovery amount limit, send a sale request.
5. When the transaction is declined, keep the card on the deny list.
6. When the transaction is successful, remove the card from the deny list.

Tap-Initiated Debt Recovery

A tap-initiated debt recovery transaction 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 transaction is attempted in real time while the cardholder is at the gate. The authorization request includes the EMV track 2 equivalent and EMV tags from the new tap, and a future capture date.

1. The cardholder taps their card to enter the transit system.
2. 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.
3. When the transaction is declined, keep the card on the deny list.
4. When the transaction is successful, remove the card from the deny list.

Cardholder-Initiated Debt Recovery

A cardholder-initiated debt recovery transaction occurs when the cardholder contacts you. The method of contact depends on where the transaction occurred such as on your e-commerce website or by phone or email for a mail order or telephone order (MOTO) transaction.

For information about e-commerce or MOTO payment services, see the Payments Developer Guide.

1. The cardholder contacts you through your website or by phone or email for a MOTO transaction.
2. You process a card-not-present (CNP) authorization.
3. When the request is successful, remove the card from the deny list.
4. When the request fails, leave the card on the deny list.

Using Multiple Accounts for Processing Functions

Mass transit systems can use multiple accounts to support a variety of processing functions. Processing functions include these types of tasks:

• Creating tap tokens
• Processing payment requests
• Retrieving card hash values
• Supporting customer journey history inquiries

Each processing function is handled by a separate account to improve security, isolation, and operational clarity. These accounts are available in the Mass Transit solution:

Account 1 — This account processes tap token create requests only. For this option, the validators communicate directly with . Using a separate account enables you to deploy a separate security key to the validator system.

Account 2 — This account 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 — This account processes card hash retrieval requests only. The responses include the full, unmasked card hash value. Using a separate account enables you to deploy a separate security key to the validator system.

Account 4 — This account operates a customer service web portal where riders can make journey history inquiries. The riders provide the card number to a hosted payment service (such as Secure Acceptance) where they register as a user. 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

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 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 FPAN and 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.

Additional Information

For information about the card-not-present services that support a transit system's journey history service, see the Payments Developer Guide.

Journey History Service Workflow

The Journey History Service workflow begins when the rider taps a payment card at a fare collection terminal. This service enables the cardholder to view their journey history and receipt information. See card scheme documentation for more information about each scheme's journey history requirements.

Mass Transit Payment Services Using EMV and Card Data

You can request these payment services for mass transit with EMV and card data:

• Authorization for account verification and debt recovery.
• Sale for aggregated fares and debt recovery.
• Stand-alone credit.

The EMV Data Elements and Tags table lists details about EMV tags that are required (M), prohibited (P), optional (O), or conditional (C) for the processor. Send a conditional tag when it is present in the card and terminal.

This table lists the EMV data elements and tags for mass transit transactions by card network:

*Contactless American Express transactions: If the Form Factor Indicator data is available on the card, then the merchant, acquirer, or processor must forward this information to the issuer.

For the authorization, sale, and debt recovery use cases that apply these EMV data elements, see Authorizations with EMV Data, Sales with EMV Data, and Debt Recovery with EMV Data in the API Reference section.

Mass Transit Payment Services Using TMS Tokens

Use TMS tokens to request these mass transit payment services:

For American Express, Discover, Mastercard, and Visa:

• Authorization for account verification and debt recovery
• Sale for aggregated fares and debt recovery
• Stand-alone credit

In card-present EMV contactless requests, 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, reads the value provided in the payment transaction rather than the values stored in the vault.

Mastercard EMV transactions include these three field values, which 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, reads the value provided in the separate fields rather than the values present in the EMV TLV and track 2 equivalent.

For the authorization, sale, and debt recovery use cases that use TMS tokens, see Payments with a Token in the API Reference section.

Mass Transit Follow-On Payment Services

The Mass Transit solution supports these follow-on transactions:

• Capture
• Authorization reversal

For American Express, Discover, Mastercard, and Visa:

• Timeout reversal
• Timeout void

For the follow-on use cases, see Follow-On Transactions in the API Reference section.

Mass Transit Token Management Services

Use the Token Management Service to create, retrieve, and delete tokens for mass transit. For the token management use cases, see Token Management Services in the API Reference section.