Additional Workflows

This section describes additional workflows that are not card-specific.

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.

Figure:

Near Real-Time Workflow
Diagram illustrating the deny list flow.
  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 the 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
    Cybersource
    .
  6. When the AVR fails, the card is added to the deny list and might be eligible for the first ride risk debt recovery.
  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.
Additional Workflows

Fare Calculation and Submission Workflow

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

Figure:

Visa Fare Calculation and Submission Flow
Flow diagram illustrating the process of calculating and submitting transit fares
  1. The back office calculates the fare of all rides taken during the travel period.
  2. You request a sale transaction for the accumulated fare. See Visa Deferred Sale with EMV Data.
  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.
Additional Workflows

Debt Recovery Workflows

A debt recovery transaction is required in order to retrieve outstanding debt in the event of a decline of the end-of-day transaction. 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:
  • Merchant-initiated 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 or by a phone call.
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.

Merchant-Initiated Transaction (MIT) Resubmission

An MIT resubmission is a deferred authorization that originates from your back office. This transaction typically references the original declined end-of-day transaction and uses the card number. Visa allows up to six authorization resubmissions within 14 days.

Figure:

Merchant-Initiated Visa Debt Recovery Flow
Flow diagram illustrating the merchant-initiated Visa debt recovery process.
  1. When the amount exceeds the debt recovery amount limit, the card remains on the deny list.
  2. When the amount is below the debt recovery amount limit, send a sale request. See Merchant-Initiated Sale for Debt Recovery with Stored Card Data.
  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.

Tap-Initiated

Tap-initiated debt recovery occurs when the cardholder returns to the transit gate and the validator recognizes a new contactless tap.
You may 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:

Cardholder-Initiated Debt Recovery Flow
Flow diagram illustrating the tap-initiated debt recovery process.
  1. 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

These are the scenarios for a cardholder-initiated debt recovery:
  • E-commerce, at your website.
  • Mail order or telephone order (MOTO), on a phone call.
For e-commerce and MOTO payment services, see the
Payments Developer Guide
 .

Figure:

Cardholder-Initiated Debt Recovery Flow
Flow diagram illustrating the tap-initiated debt recovery process.
  1. Cardholder contacts you through your website or by phone call.
  2. You process a card-not-present 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.
Additional Workflows