Common Mass Transit Transaction Workflows and Features {#um-models-flows-common-intro} ====================================================================================== This section describes mass transit transaction workflows and features that are common across supported card schemes. Aggregated Fare Transaction Workflow {#um-transit-models-flows-aggregated} ========================================================================== 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. #### Figure: {#um-transit-models-flows-aggregated_fig_q2r_wmd_j3c} Aggregated Fare Transaction Workflow ![Diagram showing aggregated fare transaction workflow](/content/dam/documentation/cybs/en-us/topics/payments-processing/card-processing/mass-transit/images/aggregated-transaction-flow-480x520.svg/jcr:content/renditions/original) Aggregated Model with the `Token Management Service` {#um-models-flows-aggregated-tms-ctv-intro} ================================================================================================ 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 {#um-models-flows-aggregated-tms-ctv-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. #### Figure: Transit Transactions with `TMS` Workflow ![Diagram of transit transactions with the Token Management Service](/content/dam/documentation/cybs/en-us/topics/payments-processing/card-processing/mass-transit/images/mtt-emv-data-tokenization-685x340.svg/jcr:content/renditions/original) 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 {#um-models-flows-common-denylist} ========================================================== 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 showing Near Real-Time workflow](/content/dam/documentation/cybs/en-us/topics/payments-processing/card-processing/mass-transit/images/near-real-time-workflow-550x415.svg/jcr:content/renditions/original) 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](/docs/cybs/en-us/urban-mobility/developer/ctv/rest/mass-transit/um-transit-models-flows-intro/um-models-flows-common-intro/um-models-flows-common-debt-recovery.md ""). 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 {#um-models-flows-common-fare-calc} ============================================================================ The fare calculation workflow begins at the end of the travel period. #### Figure: Visa Fare Calculation and Submission Workflow ![Diagram showing Visa Fare Calculation and Submission Workflow](/content/dam/documentation/cybs/en-us/topics/payments-processing/card-processing/mass-transit/images/fare-calculation-submision-workflow-430x600.svg/jcr:content/renditions/original) 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](/docs/cybs/en-us/urban-mobility/developer/ctv/rest/mass-transit/um-processing-emv-vpc/um-processing-sale-deferred-intro.md ""). 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](/docs/cybs/en-us/urban-mobility/developer/ctv/rest/mass-transit/um-transit-models-flows-intro/um-models-flows-common-intro/um-models-flows-common-debt-recovery.md ""). 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. {#um-models-flows-common-fare-calc_ol_cvj_rjw_7tb} Debt Recovery Workflows {#um-models-flows-common-debt-recovery} =============================================================== 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. IMPORTANT Use a debt recovery transaction to remove a card from a deny list. This action must be completed within one hour of receiving the authorization approval. These debt recovery transactions are supported: * A merchant-initiated 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. {#um-models-flows-common-debt-recovery_ul_kxv_bsd_xhc} When a debt recovery transaction is declined, you can request payment using the First Ride Risk liability model. For more information, 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. #### Figure: {#um-models-flows-common-debt-recovery_fig_glc_2d2_j3c} Visa Merchant-Initiated Debt Recovery Workflow ![Diagram showing Visa's Merchant-Initiated Debt Recovery workflow](/content/dam/documentation/cybs/en-us/topics/payments-processing/card-processing/mass-transit/images/merchant-init-debt-recovery-flow-475x345.svg/jcr:content/renditions/original) 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 sale request. See [Merchant-Initiated Sale for Visa Debt Recovery with Stored Card Data](/docs/cybs/en-us/urban-mobility/developer/ctv/rest/mass-transit/um-processing-emv-vpc/um-processing-sale-mit-intro.md ""). 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. #### Figure: {#um-models-flows-common-debt-recovery_fig_ibv_nh1_zhc} Scheduled Debt Recovery Workflow ![Workflow diagram showing Scheduled Debt Recovery workflow](/content/dam/documentation/cybs/en-us/topics/payments-processing/card-processing/mass-transit/images/system-gen-debt-recovery-flow-600x345.svg/jcr:content/renditions/original) 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. #### Figure: {#um-models-flows-common-debt-recovery_fig_xpp_lr3_k3c} Tap-Initiated Debt Recovery Workflow ![Diagram showing Tap-Initiated Debt Recovery Workflow](/content/dam/documentation/cybs/en-us/topics/payments-processing/card-processing/mass-transit/images/tap-initiated-debt-recovery-flow-260x425.svg/jcr:content/renditions/original) 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*](https://developer.cybersource.com/docs/cybs/en-us/payments/developer/ctv/rest/payments/payments-intro.md ""). #### Figure: {#um-models-flows-common-debt-recovery_fig_ltd_wr3_k3c} Cardholder-Initiated Debt Recovery Flow ![Diagram showing Cardholder-Initiated Debt Recovery Flow](/content/dam/documentation/cybs/en-us/topics/payments-processing/card-processing/mass-transit/images/cardholder-init-debt-recov-flow-240x410.svg/jcr:content/renditions/original) 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 {#um-models-flows-mult-accts} ============================================================================== 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 `Cybersource`. 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 `Cybersource` 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 {#um-models-flows-journey-hist-intro} ============================================================= 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 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. > IMPORTANT > Before implementing transit journey history functionality, confirm with your acquirer and card schemes that the PAR and merchant descriptor features are supported. Additional Information ---------------------- For information about the `Cybersource` card-not-present services that support a transit system's journey history service, see the [*Payments Developer Guide*](https://developer.cybersource.com/docs/cybs/en-us/payments/developer/ctv/rest/payments/payments-intro.md ""). Journey History Service Workflow {#um-models-flows-journey-hist-flow} ===================================================================== The Journey History Service workflow begins when 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. #### Figure: Journey History Request with Token Creation Workflow ![Workflow diagram showing journey history service using tokens process.](/content/dam/documentation/cybs/en-us/topics/payments-processing/card-processing/mass-transit/images/mtt-journey-history-390x375.svg/jcr:content/renditions/original)