Additional Workflows

This section describes additional workflows.

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.

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.

Debt Recovery Workflows

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
Flow diagram illustrating the merchant-initiated Visa debt recovery process.
  1. You set up a scheduled debt recovery authorization request process within your operating system.
  2. The scheduled authorization(s) attempt debt recovery submissions within 14 days of the initial transaction.
  3. When the amount exceeds the debt recovery amount limit, the card remains 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

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
Flow diagram illustrating the tap-initiated debt recovery process.
  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

Cardholder-initiated debt recovery occurs when the cardholder contacts you for debt recovery.
For e-commerce 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.