Ever wondered what happens under the hood when you pay for things online? In this article we’ll take a look at the behind-the-scenes of card payments, its drawbacks, the future, and a little bit of history. We’ll begin by defining a monetary transaction, the part where the actual money changes hands.

Transactions

All payments boil down to a transaction between a buyer / consumer and a seller / merchant. The goal of a transaction is to increase the amount of money in the merchant’s account, and at the same time decrease the amount in the consumer’s account. It seems simple, however, when it comes to online transactions it turns out to be a fundamentally hard problem. It’s hard for two reasons:

1. The transaction must be communicated over a network. This is actually a physically impossible problem to solve in general (see the problem with the two generals https://en.wikipedia.org/wiki/Two_Generals%27_Problem). In practice there are several solutions, as we’ll see.
2. The transaction is done between two parties that can’t necessarily trust each other. In most payment schemes the solution to this is to involve some sort of third party that both parties can trust.

The risk introduced by these issues is that an attempted transaction ends up in an incomplete state, where for example the merchant thinks it has received money, but hasn’t. All good payment schemes have elaborate mechanisms that ensure this will never happen in practice. 

Side note about cryptocurrencies‍

We’ll not go into cryptocurrencies in this article, but it’s worth noting that they also offer solutions to the problems mentioned above. In bitcoin for example, a distributed ledger with a proof-of-work system is what provides trust in a transaction. However, even in this system it boils down to trust in the system itself, and its participants.

Card payments

There is an abundance of different payment systems out there, but most of them use some form of card payment under the hood, or at least use some sort of clearing system (one exception is cryptocurrencies). Therefore we’ll take a closer look at how card payments work.

In essence, a payment card is just a number, an API key of sorts. The card is “issued” by the consumer’s bank, which is why we call it an issuing bank. The card number gives you access to a bank account in the issuing bank. If it’s a debit card, it gives direct access to your own bank account. If it’s a credit card, it gives you access to someone else’s bank account, along with a promise that you will pay them back in the future.

A payment card can often be co-branded so that it works with multiple types of card brands / networks. For online payments it’s most likely the Visa / Master card networks that are used, but for in-store payments there is usually more variation. In Norway, for example, BankAxept handles almost all in-store payments. A typical Norwegian debit card supports both Visa and BankAxept.

A typical card transaction

Authorization

After a consumer has been issued a payment card by their issuing bank, what actually happens when they enter the card number into a merchant website? As opposed to modern access delegation mechanisms such as oauth, card payments are actually quite straightforward. The card number is simply sent to the merchant’s bank, also called the acquiring bank. It’s akin to giving someone the password to your bank account, and trusting them to make the correct withdrawal (More on the security implications of this later).

By looking at the first few digits of the card number, the acquirer can extract what’s called a bank identification number (BIN). This number identifies both the card network and the issuing bank. The acquiring bank then uses this information to forward the request to the corresponding card network (e.g. Visa), which in turn forwards the request to the issuing bank. Here the request is accepted or declined, for example if the bank account doesn’t have enough money in it. If the initial request is accepted, the payment has been authorized.

The payment authorization response is returned to the merchant through the card network and acquiring bank. If the authorization is successful, the merchant knows that the payment is legitimate, and can ship the purchased goods. The acquiring bank, the card network, and the issuer, are also now informed about the pending transaction, and they all agree that it seems legitimate.

Note that at this point, no money has changed hands. For that to happen, the merchant must initiate a capture request. 

Capture and clearing

Given a successfully authorized payment, the merchant can request a “capture” of the payment. The capture request is sent to the merchant’s acquiring bank, which enters the payment data into a list of payments to be “cleared”. To understand clearing, it can be helpful to look at the history of the system, which at this point is over 200 years old. It started out in the UK, quite simply by having bank representatives meet on a street corner or in a pub. They would bring cheques and money orders, round them up, and settle them in cash. Here’s an account of how the clearing system started out in Norway in the 1800s:‍

Representatives of the participating banks met at the clearing house with ready-sorted cheques and claims in packages for each participating bank that had been drawn on, and then exchanged the packages for a statement of the respective sums. These sums were transferred to an account in Norges Bank, and each bank was then given the final result of the day’s clearing. Net receivables were credited to the respective bank’s account with Norges Bank, while debts were debited.‍

Source: “Clearing and settlement at Norges Bank - a historical review” by Harald Haare (https://norges-bank.brage.unit.no/norges-bank-xmlui/bitstream/handle/11250/2504201/clearing-and-settlement.pdf?sequence=1)

The main purpose of the system was, and still is, to have a third party that both the acquirer and issuer can trust. It effectively reduces the number of entities a bank has to communicate with. In addition to this, the clearing system will batch up transactions into just a couple of larger transactions, which makes settlement easier.

Of course, the modern clearing system is a bit more sophisticated than meeting in a pub. What happens nowadays is fully automated, and begins with the clearing system (e.g. Visa) polling each of its member banks for pending transactions. The acquirer will make the captured transactions available during such a poll request. After the clearing system is done polling all of its member banks, it reconciles and batches up all the payments for that period, one batch per member bank. The member banks each get a file with a list of all cleared or disputed transactions for the period. The captured transactions are now ready to be settled.

Settlement

Everything up to this point has just been preparations for setting up a legitimate monetary transaction. We’ve authorized the payment, making sure that the card is legitimate, and that there exists an issuing bank with a promise to pay. Then the merchant promised to deliver the goods, and asked for the money to be captured. The clearing system then reconciled the information it got in the authorization with the acquirer’s request for clearing. It also notified the issuing bank about the pending transaction. 

At the start of the article, we noted that there are two challenges to overcome when doing monetary transactions: trust and reliable communications. We can say that everything up to this point has been about establishing trust, but what about communication? Interestingly, the final transfer of money is not so distributed. Each member bank must have an account with the settlement system. Based on the clearing data, the settlement system will transfer money in and out of the member bank’s account in the settlement bank. In other words, the actual monetary transaction happens entirely within one bank. In the case of Norwegian BankAxept, the bank used for settlement is the Norwegian central bank (Norges Bank). For the card networks (e.g. Visa), they cooperate with a small number of banks for this purpose.

The final step

When the transaction is settled through the settlement system, the transaction is complete. At least in the sense that the issuing bank has transferred money to the acquiring bank. However, the money is still not in the hands of the merchant. For this to happen, the acquirer must first note that the settlement bank account contains the settled transaction. Then it will usually wait a day or two before crediting the merchant’s account. The reason for this is that the transaction may later be disputed by the consumer (e.g. chargebacks). To mitigate the risk, the acquirer withholds the money for a while. For the merchant, this means that it can take a couple of days before the money actually arrives in their bank account.

Security

The astute reader might have noticed that card payments as described have some security problems. It all boils down to this: The card number is the key to the kingdom, so to speak. It is written in clear text on a physical card, and it is passed along to random merchants across the web. Then, to make it worse, it’s actually the merchant that performs the payment using credentials given to it by the consumer. Contrast this with oauth (e.g. login with google/facebook), where the user logs directly into a service it trusts, and grants limited access to some third party. With the new PSD2 directive in the EU, this type of oauth flow could be used for payments in the future. In the meantime, let’s examine the security mechanisms of card payments.

Security codes

Even though the system that handles the card numbers is secure, we’re still left with the problem that a card number can easily be stolen. For this reason, we have the security code on the back of the card. There used to be two such security codes. The first was collected in physical stores, using magnetic stripe, to prove that the merchant was presented with the card (card-present transactions), but is now more or less replaced with chip and PIN. The second remains, and is used in online payments to prove that the consumer is in possession of the card (card-not-present transactions). The reason this can be considered a proof is that no-one is allowed by PCI-DSS to ever store the security code beyond the authorization of a transaction. Of course, it’s still possible to steal the entire card.

3D secure

Since it’s possible to steal cards, in the end it doesn’t help very much to have a secure payment system or security codes. That’s why it’s now mandatory in the EU to perform 3D secure as well (actually it’s mandatory to perform SCA - “strong customer authentication”, but in practice this means 3D secure). 3D secure stands for 3 domains secure, meaning the acquirer, the card network, and the issuer. The primary goal of 3D secure is to authenticate the consumer, but it also lets the consumer make sure the correct amount is authorized. 

The 3D secure auth request is sent through the card network using the same routing mechanisms as for a transaction authorization. It ends up at the issuer, which then can initiate their own preferred authentication mechanism. In Norway, this would usually be BankID authentication. When the user is authenticated, it’s highly likely that the payment is legitimate. The downside is of course that 3D secure is time consuming and annoying. Therefore, there are various shortcuts and exemptions for transactions with low risk (low amount, user is using the same browser as the last time, etc.). In fact, several new shortcuts and user experience improvements were made in 3D secure version 2 in response to the EU mandate.

It’s interesting to note that 3D secure effectively achieves what oauth would have achieved as well. The consumer is back in control of the payment, and losing a card number is not so bad anymore. So given this added security, why don’t we just get rid of security codes, or PCI compliance for that matter? This is probably partly because of historical inertia, but more importantly, it’s because the 3D secure mandate is only for the EU. It will be interesting to see what the future holds here.

The future

Even though card payments are still the king, it’s becoming increasingly more common to use various mobile payment systems as well. Many of these are still backed by cards under the hood. For example, Google Pay and Apple Pay are backed by tokenized payment cards.

However, many national mobile payment schemes have popped up in recent years, and those are often backed by national payment systems. For example, in Norway we have Vipps, which is backed by all Norwegian banks (though commercial payments in Vipps are still card-based). In 2021 Vipps merged with Norwegian BankAxept and BankID, Danish MobilePay, and Finish Pivo.

In addition, similar mobile payment solutions from all over Europe have started collaborating on interoperability through the European Mobile Payment System Association (EMPSA). On top of this, the fairly recent PSD2 directive from the EU mandates open banking APIs in order to increase competition. We can’t see the future, but it’s probably fair to say that we haven’t seen the final form of payment systems quite yet.