Card Payments 101: How it works

Have you ever wondered how you make a transaction using your payment card such as buying a cup of coffee and then a day later it appears on your bank statement?
Working in the payments industry for several years, I am happy to walk you through the card payments basics.
Imagine you came to your favourite coffee shop with no cash and ordered a cup of coffee with the intention to pay by card. You would get a POS (point of sale) terminal with a price on it and you would pay for your coffee by tapping your card or inserting it to an EMV reader and entering your PIN (Payment identification number). This process is called authorisation. During this process there are at least three parties interacting to each other:

The coffee shop, also known as the merchant
You, the cardholder
The bank that issued your card

The coffee shop is wondering if they get the money from your bank before they serve you the coffee. You are wondering if the transaction is OK and you are going to get that coffee. The bank is wondering if this is really you making this transaction or this is someone else pretending to be you and also if you have enough cash or credit in your account.

During authorisation the coffee shop sends an authorisation request to your bank and receives an authorisation response with the indicator if the transaction is approved. If it is so you a going to get your coffee!

Payment Authorisation

The aim of the payment authorisation in retail transactions, such as buying coffee in a coffee shop, is to read the card data and send it through to an issuing bank.

There are different ways of reading the card data, such as:

Swiping a card through a POS system
Inserting a card into an EMV (chip) reader
Tapping a card onto a contactless card reader

Regadless of the way used, the information is being read into a merchant system and sent in an authorisation request.

Data stored on a card

Even though there are different brands of payments cards they have standard data elements stored on them:

PAN - Primary account number (aka card number).
BIN - Bank identification number. This is the first six digits of the PAN.
CVV2/CAV2/CID/CCV2 - different abbreviations about the same. This a card verification value or a security code used to identify your card is genuine. Only you and the issuing bank should know this code. This code is to be used in e-commerce transactions as opposed to CVV code being read and used in retail transactions.
Magnetic stripe - contains Track 1 and 2 of the data required for authorisation in retail transactions. It includes the same PAN, cardholder's name, expiration date, service code, CVV. It's being read by card readers and sent during authorisation.

This data is being used for payment transactions including payment authorisation.

The authorisation process

During the authorisation process a merchant sends an authorisation request and receives a response with the status: approved or declined.
The authorisation request typically includes:

PAN,
Expiration date
Cardholder name
Security code (e.g. CVV)
Amount
Currency

You can see the transaction participants in the diagram below:

In addition to Cardholder, Merchant, and Issuing Bank, there are at least two more players in the process:

Acquiring bank (Acquirer). They are responsible for receiving payment authorisation requests from merchants and sending them to issuing banks through the appropriate communication channels. They help to abstract the complexity for the merchants to deal with a lot of issuing banks.
Credit card network (scheme). They process credit card payments worldwide and govern interchange fees. Examples of credit card networks are Visa, Mastercard, Discover and American Express. It connects all the acquiring banks and all the issuing banks setting the market rules.

As part of the authorisation process there is a step called authentication being executed by an issuing bank. The bank validates card data, including security code, and the funds available. If all is good, the bank approves the request.

E-commerce payment authorisations

In additional to retail payments, there is another "world" of payments executed on the Internet. They are also called CNP (Customer Not Present) or online payments. They are similar to the retail ones using POS systems with some differences:

The data sent in the authorisation request is slightly different. For example, CVV2 is being sent instead of CVV and there is additional data providing more context about the transaction, such as cardholder's billing address, shipping address, phone, payment reference etc. This data is used for authentication and fraud detection.
In addition to the authorisation, there is an extra payment step called capture happening after the authorisation. It reflects the differences in business models of e-commerce merchants. During this step a capture payment request is being sent by the merchants similar to the authorisation one. When it's approved the authorised amount starts getting moved from a cardholder's account to a merchant's account via the process called clearing and settlement. Typically, e-commerce merchants use authorisation to accept an order and then they capture the payment when they have shipped goods or services. For capture requests only PAN and the payment id (scheme transaction Id) is typically required.
There are additional players in e-commerce transactions: Payment service providers (PSPs) or payment facilitators (PFs) Their main role is to abstract the merchants from the complexity dealing with integrations with different acquiring platforms and card networks. Merchants integrate with one or two PSPs and leverage their integrations with many card networks and acquiring platforms. PCI and security burden lies on PSPs and not on the merchants. PSPs also provide a number of useful products, such as acquiring routing, various payment methods support, e-wallet integrations, market places and more. It all makes small merchants life easier and opens the doors to the e-commerce market. Examples of PSPs are Checkout.com or Stripe

It's worth noting, there are more exotic types of e-commerce authorisations reflecting new emerging business models and making the payment more flexible for customers' and merchants' needs:

Estimated authorisations. When a merchant does not know what would be the final cost of goods or services they can use an estimated authorisation feature. And later they can increase or decrease the authorised amount. For example, the taxi service Uber can authorise an estimated cost of a ride based on initial estimate. When the order is completed they would adjust the final amount and capture the payment.
Incremental authorisations. They are designed to increase the original estimated amount. (Note, for decreasing the amount there is a payment action called partial voids)

Getting money paid

Now in order for a merchant (the coffee shop from our example) to receive their money in their bank account the clearing and settlement steps are required:

At the end of a business day the merchant sends a list of successful authorisations to their acquiring bank electronically.
The acquiring bank groups all the transactions by a card scheme and sends the batches to the corresponding card schemes.
The schemes group all the transactions by the issuing banks and send them to each issuing bank for settlement.
The issuing banks then transfer money back to the appropriate card schemes within 24-48 hours.
The card schemes then transfer the funds to acquiring banks.
Acquiring banks then transfer them to the merchant's account.

When this is done the customer and the merchant see the money debited and credited in their bank statements. Typically it takes minimum a day or two to complete.
It's worth noting that every party in this chain receives different fees for their services. The merchant (or/and a customer) are the payers of these fees. The fees are out of the scope of this article.

Undo a transaction: refunds and chargebacks

What happens if something goes wrong: a cardholder has changed their mind or the quality of goods or services was not OK? In this case the payment can be undone via a refund or a chargeback.

Refund is a type of a payment transaction when a merchant wants to return customer's money back due to any reason. For instance, the customer didn't receive the goods or services. The refund transaction is similar to the authorisation transaction: there is a request sent by the merchant an a response received back from the issuing bank. Refund transactions do not require sensitive data, such as CVV. Typically, the request includes PAN, expiration date and a cardholder's name. For e-commerce payments, the payment refund requires even less: PSP payment identifier and a reference.

Chargeback is a type of a payment transaction initiated by a customer. Customers reserve the right to dispute a charge on their credit card billing statement within 60+ days (depending on the card scheme) of the statement date. Typically a customer submits a chargeback request to their issuing bank and fills a form with the details about the reason of the chargeback. The issuing bank sends a chargeback request to a merchant's acquiring bank via a card scheme. If the merchant agrees with the chargeback, the transaction is undone. If not, a dispute process starts. The dispute process is being handled by the card schemes.

Summary

Now you understand what happens under the hood of the card payments and what steps are involved before you see the payment in your bank statement. As you can see this process is very customer-focused:

you get the service and goods without any cash just based on an "approval"
your money are being taken a day or more after the transaction is completed
you are well protected and can question this transaction many days later

It's important to have the knowledge about different types of payment transactions and stages involved in them to understand what happens with your funds as well as your customer's rights.

It brings the benefits for the merchants as well giving them an opportunity to lift their business to the next level. Isn't it the future of the payments?

If you have any questions, feel free to leave them in your comments.