Card payments for dummies💳
Understanding the card payments dynamics
Hi all,
today we are bringing to you another “intro” article, this time about card payments. Payment is a very complex subject with many subsets, and we will touch on only the most basic terms here. Later, we will write/host more payment articles dealing with specifics, but this will be the article to which you can always go back if you don’t understand more “depth” payment articles.
At least, that is the idea😅
We must shout out to Sophia Goldberg and her book “The Field Guide to Global Payments” because this text is a short sample of the part of her book. If you are a beginner and want to learn more about payments, we recommend buying her book👇
The Field Guide to Global Payments
Unlike other books, this one is really “user-friendly” for beginners.
In case you stumbled upon this article by chance and still haven’t subscribed to our newsletter:
Let’s start from the…start?
The earliest use of the term “credit card” dates back to 1887. Edward Bellamy, the author of the utopian novel “Looking Backward” described the concept of using a card for purchases. Funny thing, he used the term “credit card” 11 times in his novel!
In case you want to buy the book, we got you covered👇
The first bank card was introduced in 1946 (it was called Charge-It), but the first cards that could be used among broader merchants came to life in the 1950s, and the companies responsible for them were Diners Club and American Express.
Fun fact 1
The Diners Club card could initially be used at 14 restaurants in New York…within a year, 330 merchants joined.
Fun fact 2
Bank of America started licensing BankAmerica cards to other banks in other states and countries in 1958. To launch it, Bank of America mailed 60.000 BankAmerica cards to residents in Fresno, California. This marketing experiment became known as “Fresno Drop”.
Understanding the players
To understand how card payment functions, you must understand its basic terminology. There are 5 main terms you should know to understand how payments work:
The Merchant
A company that sells goods or services and wants to accept payments from customers
A Cardholder
The customer is attempting to purchase from the Merchant. This can be an individual or an entity (in the case of B2B transactions)
The Issuing Bank
The bank that issues a customer's card. The Issuer is responsible for allowing or denying a transaction, extending cred, and collecting the balance at the month's end
An Acquirer
The Merchants' bank partner processes payments on their behalf and is a licensed member of the card networks.
An Acquirer can be a bank, processor, gateway, or independent sales organization (ISO).
The Acquirer is responsible for four key aspects of payments: authorization, clearing, settlement, and reversals (refunds and chargebacks)
The Networks
The Network provides infrastructure and the rules for how parties interact and aggregate funds so not every Issuer has to talk to every Acquirer.
Examples of global Networks
The most significant value of Networks is that they can connect thousands of Issuers to thousands of Acquirers globally. Without the Networks, there would be an infinite number of individual connections and fund flows. Just imagine the world where each Acquirer would have to collect funds from each Issuer. If this were the case, there would be no global payments; it would be too complicated.
An easier way to understand dynamics between the players is to think of it as a game. If the players in the game are Merchants, Cardholders, Issuing Banks, and Acquirers, then the Network is the board on which the game is played.
Simple transaction breakdown
To better understand the players' terminology we discussed above, here is a very basic transaction breakdown:
Authorization request
Merchant asks “Can I take $ from XY account”?
Authorization response
Issuer response “Of course, I will put $ on hold”
Capture/Clearing
Merchant “Great, send me the money then”
Settlement
Issuer “Of course, here is your money”. This final agreement sets off a flow of funds from Issuer👉Network👉Acquiring Bank, who then settles with the Merchant.
But of course, the modern card payment experience is more complicated than this simple example, even though in essence it’s the same thing.
Let’s go into more details (it’s not scary, I promise)
Imagine you have an e-commerce business, and you are selling…whatever you want, it’s e-commerce after all😍 Your marketing team did a great job (users came to the site), your IT team did a great job (the site didn’t crash), and your design team also did a great job because users managed to find their way to a checkout page, and now what?
First step
Most likely, the customer will have to type in PAN (payment account number, the 16-digit number on their card), card expiry date, and CVV/CVC (three or four-digit security code). Here comes the first question: who is responsible for securing these data? Merchant or?
The checkout page can be fully owned and hosted by the Merchant as long as that Merchant is PCI compliant (it means you are allowed to hold and transmit PAN data). If the Merchant is not PCI compliant and doesn’t want to touch sensitive card data (smart move), the Payment services provider (PSP) will support the Merchant in the following way:
drop-in UI components
HPP (hosted payment page)
The bottom line is that both can look like your checkout page but are controlled by merchant payment providers.
If you want to know more👉 PCI explained
PCI or PCI DSS (Payment Card Industry Data Security Standard) is the information security standard for any organization that handles card data. The major card networks mandate this standard to standardize protections around the storage and usage of card details and reduce the instances of data breaches of sensitive cardholder data.
Before 2006 when PCI DDS was created, each card network had its rules for how card data needed to be managed.
Taking on PCI compliance is a large decision and above all complicated process. There are more than 1800 pages of documentation and more than 300 security controls + yearly audits. Because of the complexity, 99,999% of the merchants are not PCI compliant and use PSP services.
Second step
After the customer fills in their card information and clicks on the “Pay” button, you, as the e-commerce business, must decide whether you accept this payment or not. Now, of course, you don’t have to accept every payment manually, this is more from a risk assessment side; do you believe that the person who typed in card details is a legitimate customer or a fraudster?
The whole process is done “automatically”, and users don’t see this. Many PSD providers offer built-in risk systems, and there are a lot of 3rd party solutions for managing fraud.
Let’s say that in our example, as the second step merchants accept the payment.
Third step
After the e-commerce shop accepts the payment, PSP that in handling the payment sends that transaction to the relevant card network (Visa, Mastercard, etc). As a side note, the 16-digit PAN number on your card is not really random, for instance, all Visa cards start with the number 4, so the PSP provider knows from the card number to which card network it needs to send the transaction.
After the Network receives the transaction, it routes that transaction to the Issuing bank.
Fourth step
The Issuing bank approves the request (it looks like this is their customer, and they have the necessary funds to cover the amount), and the Issuing bank place something that is called an “authorization hold” on that shopper’s account for the amount the merchant requested.
I don’t want to go into too much detail, but for some merchants (restaurants, taxis, etc), Issuing bank approves changing the authorized amount to support tips, etc.
Authorization hold can be anywhere from 1 all up to 30 days. That means the Merchant may get the funds 30 days after the customer made the purchase. That is an extreme example, the usual delay is 2-4 days.
Fifth step
Once the Issuing bank did an authorization hold, the Merchant (e-commerce business in our example) sends a request to their PSP provider to capture the funds that were approved. After that, the PSP provider sends the capture “command” to the Network (this is generally a batch file sent out a few times a day).
Clearing/Capturing is the key function of the Network because if there is no Network, the Merchant would have to collect funds from each bank individually.
Final step
The final step is also known as settlement. In the case of the card payments, once the PSP provider sends a capture/clearing “command” the funds flow from the Issuer👉Network👉Acquirer (in this case PSP provider)👉Merchant.
The amount that the Merchant gets on its account is usually net settled. What does that mean?
It means that the acquirer (PSP provider in our case) deducts all relevant fees. In some cases, Acquirers may gross settle where the Merchant needs to pay an invoice at the end of the month for the fees incurred. In reality, payment providers have a mix of both; they use net settlement for the scheme, interchange, and processing fees, but other services like tokenization or risk are charged at the end of the month.
Conclusion
This is just a simple overview of today's card payment mechanics. There are many more areas connected with the payments (not just card payments) we will cover in Fintech Wave, so stay tuned!
Good write up. Another good book is Anatomy of the Swipe.