Card and Mobile Payments Flow 101

Know what exactly happens behind the scenes when a customer uses a physical Card (credit or debit) OR uses the Mobile device to make a purchase either online or at a store ???

Not many understand how these payments work end to end, so thought would explain the high-level flows in very simple terms for the benefit of others. But, before we get started, wanted to make sure we are all on the same page with respect to some terminology related to the card payments.

The following are the list of all the commonly used terminologies in the card payments:

Merchant is a business entity that provides good and services to a customer.
Acquirer (or Acquiring Bank) is the financial institution (or bank) that collects and processes card transactions on behalf of a Merchant.
Merchant Bank is the financial institution that manages the bank account(s) on behalf of the Merchant. In most cases, the Acquirer would also be the Merchant Bank.
Line of Credit (or LOC for short) is the personal loan issued to a customer.
Issuer (or Issuing Bank) is the financial institution (or bank) that provides the LOC and supplies a card to a customer.
Card Holder is the customer with a card that is provided by the Issuer .
Point of Sale (or POS for short) is the physical device at the Merchant where a card can be used by the Card Holder to make a purchase.
Network (or Card Network) is the financial intermediary between the Acquirer and the Issuer. The major players are Visa, Mastercard, Amex, and Discover.
Primary Account Number (or PAN for short) is the full 16 digit card number.
Bank Identification Number (or BIN for short) is the first 6 to 8 digits of the card number that identifies the Issuer. For Visa, the BIN starts with a 4, for Mastercard the BIN starts with a 2 OR a 5, etc. Every financial institution (or bank), be it an Acquirer or an Issuer, has its associated BIN.
Card Security Code (or CSC for short, also referred to as Card Verification Value or CVV for short) is the 3 to 5 digit numeric code on the back of the card.
Token is a 16-digit alias corresponding to a card PAN.
Tokenization is the process of replacing the 16-digit card PAN with an alias Token.
Wallet is the mobile app that stores the 16-digit alias token corresponding to a card.
Token Service Provider is another name for the Network.
Token Key is the cryptographic key used to encrypt data.
Cryptogram is the encryption of the transaction date, the transaction amount, etc. by the Wallet.

We will first focus on the card payments flow as it is foundational for the overall understanding.

At a high level, the following illustration depicts the involved entities in the card payment flow:

Figure.1

The card payments flow goes through the following 3-steps before everything gets settled:

Authorization
Batching
Clearing and Settlement

In the following paragraphs, we will unpack each of the 3-steps.

Step-1 => Authorization

A Card Holder wants to buy some goods from a Merchant who is having a great sale at their stores.

The following illustration depicts the card payment flow for the Authorization step:

Figure.2

Let us unpack each of the numbered arrows from the illustration in Figure.2 as follows:

(A) :: The Card Holder uses the card at the Merchant's POS terminal
(1) :: The Merchant's POS terminal sends an Authorization request containing a unique transaction id, the 16 digit card number, the card expiry, the CVV code, the merchant id, and the transaction amount to the Acquirer
(2) :: The Acquirer looks at the card BIN and routes the request to the appropriate Network
(3) :: The Network looks at the card BIN and routes the request to the appropriate card Issuer
(4) :: The card Issuer performs various checks, such as is the card inactive, has the card expired, does the Card Holder have enough of remaining credit to fund the purchase, is the card transaction a fraud, etc. Based on the outcome of the checks, the Issuer may approve or deny the request and send a response back to the Network. If approved, the Issuer places a hold for the transaction amount on the Card Holder's credit account
(5) :: The Network looks at the Acquirer BIN and routes the response to the appropriate Acquirer
(6) :: The Acquirer looks at the merchant id and routes the response to the appropriate Merchant POS

At the end of the business day, the Merchant needs to be paid for all the sale transactions.

The following illustration depicts the card payment flow for the Batching step:

Figure.3

Let us unpack each of the numbered arrows from the illustration in Figure.3 as follows:

(7) :: The POS terminal at the Merchant batches all the approved card transactions at the end of the business day and sends them to the Acquirer for settlement
(8) :: The Acquirer forwards each of the approved card transactions to the appropriate Network based on the card BIN for clearing and settlement

Step-3 => Clearing and Settlement

The Merchant's account needs to be credited, while the Card Holder's LOC needs to be debited.

The following illustration depicts the card payment flow for the Clearing and Settlement step:

Figure.4

Let us unpack each of the numbered arrows from the illustration in Figure.4 as follows:

(9) :: The Network batches all the transactions pertaining to an Issuer and dispatches them in bulk to the Issuer for clearing and settlement
(10) :: The Issuer validates all the approved Card Holder transactions to ensure they match, accumulates the amount related to the Acquirer, and finally transfers the netted funds to the Acquirer
(11) :: The Acquirer deposits all the funds related to the particular Merchant to the corresponding Merchant Bank
(B) :: The Card Holder makes a payment at the end of the billing cycle to the Issuer clearing the balance

This in essence outlines the end-to-end card payment flow when a customer makes an online purchase OR swipes/taps the card at any store.

Shifting gears, we will first focus on the mobile payments flow as it builds on the card payment flows.

For mobile payments, one needs to first provision a card into a Wallet on the mobile device. The following illustration depicts the card provisioning flow:

Figure.5

Let us unpack each of the numbered arrows from the illustration in Figure.5 as follows:

(1) :: When a Card Holder adds a card to the Wallet, the mobile device sends the card details (the 16-digit PAN, the card expiration, etc) to the Token Gateway Server (referred to as the Apple Pay Server in the case of Apple)
(2) :: The Token Gateway Server looks at the card BIN and routes the request to the appropriate Network (referred to as the Token Service Provider)
(3) :: The Network looks at the card BIN and routes the request to the appropriate card Issuer for further verification
(4) :: The card Issuer performs various checks, such as is the card inactive, has the card expired, etc. Based on the outcome of the checks, the Issuer may approve or deny the request and send a response back to the Network. For approved requests, the Issuer adds an encrypted CVV and sends a response back to the Network
(5) :: On approval response, the Network generates a Token AND a cryptographic Token Key for the corresponding card PAN and sends them to the Issuer
(6) :: For approved requests, the Network also sends the same Token, the Token Key, and the encrypted CVV to the Token Gateway Server
(7) :: The Token Gateway Server sends the same Token, the Token Key, and the encrypted CVV to the Wallet for safe storage in a secure area. The Wallet does not store the card PAN

In the case of mobile payment, when a Card Holder uses the mobile device to buy some goods from a Merchant, there are minor tweaks to the Authorization step.

The following illustration depicts the mobile payment flow for the Authorization step:

Figure.6

Let us unpack each of the numbered arrows from the illustration in Figure.6 as follows:

(A) :: The Card Holder uses the mobile device at the Merchant's POS terminal, which causes the mobile device to generate a Cryptogram based on a unique transaction id, the transaction date, the transaction amount, etc. and send to the Merchant's POS terminal
(1) :: The Merchant's POS terminal sends an Authorization request containing the Cryptogram, the 16 digit Token, the encrypted CVV, and the merchant id to the Acquirer
(2) :: The Acquirer looks at the Token BIN and routes the request to the appropriate Network
(3) :: The Network looks up the card PAN corresponding to the Token, looks at the card BIN and routes the request (with the card PAN) to the appropriate card Issuer
(4) :: The card Issuer decrypts the Cryptogram and performs various checks, such as is the card inactive, has the card expired, does the Card Holder have enough of remaining credit to fund the purchase, is the card transaction a fraud, etc. Based on the outcome of the checks, the Issuer may approve or deny the request and send a response back to the Network. If approved, the Issuer places a hold for the transaction amount on the Card Holder's credit account
(5) :: The Network looks at the Acquirer BIN and routes the response to the appropriate Acquirer
(6) :: The Acquirer looks at the merchant id and routes the response to the appropriate Merchant POS

The remaining two steps (Batching and Clearing and Settlement) in the payment process for the mobile payments are the same as the card payments.