How Do Online Payments Work?

There are two subjects I feel I have a decent amount of knowledge about — product management and payments — and both of them seem to confuse the hell out of people who don’t work in those areas. One is all about trying to simplify things. The other is payments.

It can be quite bewildering trying to unpick the basic details of how payments work, so I thought it might be worth pulling together a simple guide to online payments for any product managers (or anyone else, for that matter) who find themselves working in this space. I’m also going to grossly over-simplify it, so for any of the payments experts in my network, look away now!

Photo by rupixen.com on Unsplash

Online vs In-person payments

For most of this article, I’ll be talking about credit and debit card payments, which were all originally built on rails intended to be used to pay for goods in a physical store, at a physical till and with a physical card. These are called “cardholder present” transactions — i.e. where the merchant taking the payment has access to the physical card (it can be swiped, tapped, put into the Pin Entry Device on a till, etc). I’m not going to talk about those!

The other main type of transactions, unsurprisingly, are called “cardholder not present” (CNP) transactions — i.e. the merchant doesn’t have access to the physical card. These are roughly split into two buckets:-

• Payments taken over the phone (MOTO = Mail Order / Telephone Order) — I’m not going to talk about those either!
• Payments taken online (eComm). These are the ones I’m going to talk about :-)

Different rules apply to payments taken in each of these cases, around whether the customer is required to “authenticate” and how (e.g. enter a PIN number, complete 3DS checks, etc) and around who is liable for any fraud that occurs (usually the merchant or the card issuer).

As a general rule, merchants and customers are not liable for fraudulent transactions online where all the rules are followed. Some exceptions apply!

What are Merchant Initiated Transactions (MIT)?

I’m going to spend most of this article talking about customer initiated transactions (CIT), but there are also merchant initiated transactions (MIT). This is where the customer has allowed the merchant to store their card details (called “Card on file”), and the merchant can use them to take payments without the customer’s involvement — e.g. subscription payments, for services like Netflix or Spotify.

What happens when I make a payment online?

There are a number of different parties involved in taking a payment online.

• You, the customer
• The merchant: Whoever the legal entity is that’s taking the payment on the website in question
• The payment service provider (PSP): They capture the card details and send the payment request onto the respective acquirer
• The acquirer: This is the merchant’s bank, who accept the payment on behalf of the merchant, through the card network, and manage the merchants account
• The card network: Visa, Mastercard, American Express, etc
• The issuer: Whichever bank or financial institution issued the credit or debit card that the customer is using

Simple flow of how a payment request flows through the relevant parties

There are also numerous steps in the process. Terminology can vary depending on whether you are looking at this from the perspective of the merchant, acquirer or issuer, but is largely as follows. You’ll often hear the term APACS (Association for Payment Clearing Services) used to describe this type of flow, where an authorisation occurs before the actual payment is taken (captured), and sent for settlement.

• Entering card details: Typically the customer types in their card number, expiry date and CVV code on the merchant’s website. The customer may choose to let the merchant store these card details (aka “Card on File”) for future usage. In most cases, it will actually be the PSP capturing these card details (e.g. within an iframe), in order to reduce the amount of exposure the merchant has to actual credit/debit card data — see “What is PCI Compliance?” section
• Authentication: We’ll come back to this later (see “What is Strong Customer Authentication?”), but essentially a validation step to check that the customer is who they say they are (and how much they agreed to pay), which returns an authentication token.
• Authorisation: When the customer has entered their card details, and confirmed that they want to make the payment, the PSP will send a request (via the acquirer and card network) to the issuing bank to check that the customer has the funds, and it is possible to take the payment. This will include the authentication code (where applicable) to prove that authentication occurred, as well as customer and transaction details . The PSP will then be given an authorisation code that is sent back to the merchant, and can be used to capture that payment, along with the transaction reference. This transaction reference is what is used to refer to that transaction going forward (for the purposes of capture, tracking and refunds, etc).
• Capture: Once the authorisation has happened, and the merchant knows they will be able to get the payment from the customer, they will go ahead and create the order (which in the case of digital goods could mean fulfilling the order immediately). Assuming that the order is successfully created, the merchant will then send a request (with the auth code) to the PSP (that will get passed down the line to the issuer) to request the actual capture of the payment from the customer.
• Settlement: After the payment has been captured, the issuing bank will settle the funds with the acquiring bank, to be paid into the merhants account (minus fees).

APACS type payment flow

How are merchants identified across the card network?

Merchants need to have a Merchant ID (MID) set up for each acquirer and card network that they want to take payments through, that are tied to the merchant’s legal entity (the Seller of Record = SOR). They will also likely have different MIDs for each currency they want to support. The acquirer will typically provide these MIDs that then have to be configured with the PSP before the merchant is able to take payments.

What is a TID?

A Terminal ID (TID) is effectively the equivalent of specific terminal (so in a physical retail environment, this would be a till). You can can have multiple TIDs associated with a MID, and a TID can only process one transaction at a time.

So, from an online retail point of view, the main consideration for how many TIDs are required (for each MID) is how many concurrent transactions you are likely to take. And don’t base that on your average usage, or you’ll hit problems when it comes to promotional events like Black Friday. Some PSPs will handle this directly for you, especially if you are happy to use their choice of acquirer. In fact, lots of things can be easier if you work with a PSP that has it’s own preferred acquirers (PCI accreditation, better acceptance rate, etc), but it might not be the lowest cost.

What is PCI Compliance

The Payment Card Industry (PCI) governs the use of all electronic forms of payment, and the PCI Security Standards Council (PCI SSC) is a standards council that was created in 2007 by American Express, VISA, Discover, Mastercard and the Japan Credit Bureau (JCB) to set the rules that need to be followed by any body involved in taking of credit and debit card payments.

Any merchant wanting to take credit and debit card payments has to prove they are compliant with the rules set out by the PCI SSC (which are regularly updated), and the most stringent rules apply to the capture and storage of PCI data (e.g. actual card numbers, or PANs — Primary Account Numbers). A merchant has to be assessed and certified to be compliant (this process is called “accreditation”). Most payment gateways will handle the capture and storage of payment card details on behalf of the merchant, so that the merchant handles very little PCI data, so that the merchant only has to do a very lightweight accreditation.

This lightweight accreditation is known as SAQ (Self-Assessment Questionnaire) A, and is intended for merchants that do not handle actual cardholder data, and it includes around 14 questions. By comparison, for merchants that are handling actual cardholder data, they are required to complete SAQ D, which includes over 300 questions, and a considerably more extensive set of responsibilities.

What is 3DS2 / PSD2?

Many years ago, the EU implemented the Payment Service Directive (PSD) to try and put tighter rules around payments within the EU. A new version of this legislation came into force in 2016, generally referred to as the Payment Services Directive Two (aka PSD2).

The two main components of this new legislation were:-

1. To introduce more open banking practices, through the creation of open banking standards that all consumer banks (in the EU) would have to adhere to, to make it easier for customers to make direct bank payments (via PISPs — Payment Initiation Service Providers) and share their account information (via AISPs — Account Information Service Providers). I’m not going to talk about this, but it’s a very interesting and evolving area that you can find out more about on the Open Banking Standards website.
2. To set rules around Strong Customer Authentication (SCA) that all electronic payments have to adhere to.

What is Strong Customer Authentication?

In a nutshell, for most electronic payments, some form of customer authentication has to be performed to prove that the customer is who they say they are, by providing at least two of the following:-

1. Knowledge — something only the customer knows (e.g. a PIN or password)
2. Possession — something only the user possesses (e.g. the physical credit/debit card or a specific device, such as a phone or watch)
3. Inherence — something the user is (i.e. biometric authentication)

The way that the main card networks (Visa, Mastercard, Amex, etc) agreed to support this new legal requirement for eCommerce payments was to implement a new standard of the 3D Secure checks that have been used online since the original Payment Service Directive. That standard is 3DSecure version 2 (3DS2), and as I write this, 3DS 2.2 is about to be mandated and 3DS 2.3 is the new standard being worked on.

So, what does this mean?

This means that every time a customer wants to make an electronic payment with their credit or debit card online, they could be asked to authenticate. How they authenticate is up to the card issuer. Some issuing banks will send you a code by email or SMS that has to be entered into the 3DS2 challenge window (i.e. knowledge). Some issuing banks will ask you to open your banking app and confirm the payment in there instead, which may require biometric authentication, such as Touch ID or Face ID (i.e. inherence). It is up to the issuer how they implement this, as long as it meets the legal SCA standards set out in PSD2.

Does SCA apply to all Cardholder Not Present (CNP) payments?

Actually, no. There are a number of exemptions, such as:-

• MOTO Payments
• Merchant Initiated Transactions (MIT) — e.g. subscriptions
• “One leg out” — where either the merchant or the card issuer is based outside of the EU (and not legally obliged to meet the SCA requirements)

What are Digital Wallet Payments?

When people talk about digital wallets, that covers a number of different types of payment methods. However, I’m going to lump these into two general buckets:-

1. Virtual credit/debit card wallets (e.g. Apple Pay and Google Pay)
2. Digital Payment Wallets

Both have the benefit of simplifying the payment flow for customers, as the customer can add a payment method once to their wallet, and then use it with many different merchants.

Virtual credit/debit card wallets

This type of wallet is used to store your credit card details in a tokenised (encrypted) format, and typically on a specific device (e.g. a mobile phone). When it comes to taking the payment, that is actually processed using the same mechanism as any other credit or debit card, and via the merchant’s PSP.

Transaction flow for Apple Pay or Google Pay payments

This is how Apple Pay and Google Pay work, but there are other wallets that work in a similar way. Some of you may remember the brief appearance made in the payments landscape by Visa Checkout and Masterpass (Visa and Mastercard’s respective attempts to launch their own payment wallet). Both have since been replaced by a new payment wallet (developed jointly between Visa, Mastercard and American Express) initially called Secure Remote Commerce (SRC), but now more sensibly branded as Click To Pay. This works in a similar way to Apple Pay and Google Pay, by storing tokenised (encrypted) card details, and using those to take the payment (via the merchant’s PSP), but in this case using network tokens (tokens that can be used across all supported issuing banks). In contrast, both Apple and Google use their own proprietary tokenisation.

So, how does the issuing bank know what to do with Apple and Google’s card tokens?

In short, each issuing bank needs to have a direct integration with Apple or Google. When they are sent a payment request, they receive the tokenised card number (DPAN) and call Apple (or Google) to retrieve the card number (PAN) in order to process the payment request. Without this direct integration , a customer can’t even add their debit/credit card to their wallet. All of the major banks have these integrations in place, but there are still some that don’t (yet), and so these won’t support Apple Pay (or Google Pay).

Digital Payment Wallets

I’m defining digital payment wallets (unlike Apple Pay and Google Pay) as wallets where the payment is processed by the wallet provider, and not the merchant’s PSP. This is how wallets like PayPal and AliPay work. How the transaction is actually funded is handled by the wallet provider, and can be a combination of stored value or on-demand funding from another payment method (credit/debit card, bank account, etc).

Wallet payment flow via direct integration

A merchant needs to be integrated with the wallet provider in order to take wallet payments, but this can either be directly, or many PSPs will offer this as an add-on service.

Wallet payment flow via PSP integration

What about Fraud?

I’ve completely bypassed the topic of fraud so far, but there are some very key considerations that need to be factored in, as you think about how you want to handle payments.

1. How do merchants protect themselves against fraud?
2. Who is liable for fraud, when it happens?

How do merchants protect themselves against fraud?

Simple answer, by having a fraud protection solution in place. Most merchants will have a solution in place to screen any payment attempts for the likelihood of them being fraudulent. It’s becoming increasingly common to actually track the behaviour of the user throughout their interactions with a merchant (e.g. when browsing, at login, etc) and not just at the point of payment, but this requires multiple levels of integration, often with multiple 3rd parties, so I’ll just talk through the most common approach.

It’s most common for merchants to have a fraud screening solution that is integrated with the PSP, so that the fraud decisioning has full access to the card details provided by the customer (remember that most merchants won’t capture the actual card details, for PCI compliance reasons). Some PSPs have. their own fraud screening solution, but many will have integrations with the more common fraud screening solutions.

Typical fraud protection integration

A very common approach is to send the details of the transaction to the fraud protection solution at the point of authorising the payment. The authorisation may fail for reasons outside of the merchant’s control (e.g. customer has insufficient funds or the issuer thinks the transaction may be fraudulent), in which case the merchant has no decision to make. However, if the authorisation is successful, then the fraud protection solution will have done it’s own assessment of the risk, and will either accept the transaction or reject it (if there is a high probability it is fraudulent). In many cases, fraud protection solutions will support a manual review — i.e. if it’s in that grey area between definitely fraudulent and not likely to be fraud, the order will be put on hold until the merchant’s fraud team have reviewed it, to decide if it should be accepted or rejected. This requires some additional levels of integration into the merchants own systems to ensure that orders do not get fulfilled if they are fraudulent.

So why do merchant’s need to do their own fraud screening if issuers are already doing this?

Issuers will have visibility of how a specific card is being used across multiple merchants, and should be well placed to spot repeated abuse of a specific card (e.g. unusual transactions, not typical of the customer’s normal behaviour). However, fraudsters are wise to this, and will often attempt to use a variety of different cards to target specific merchants — this is where the merchant is more able to spot the fraudulent behaviour.

Who is liable for fraud, when it happens?

For most electronic payments, provided the customer hasn’t done anything to breach the terms of use (e.g. shared their PIN number, given someone their password, etc), the customer is usually not liable.

For a lot of payment methods, provided customer authentication is successful, merchants are not liable for any fraud on eCommerce transactions, however, there are lots of exceptions — in fact too many to cover here — but here are some examples:-

• If a customer fails (or does not complete) authentication, but the merchant goes ahead with the transaction (in theory no longer possible in the world of 3DS2, but was absolutely the case for 3DS1 transactions)
• For virtual wallet payments (e.g. Apple Pay) where 3DS2 is not used (Apple Pay uses other SCA compliant methods of authentication) some card networks (e.g. Visa) will not pass liability for those transactions to the issuer, so it instead sits with the acquirer (and therefore the merchant).
• Merchants are liable for all MOTO transactions

In the days of 3DS1, a lot of merchants used to rely on 3DS1 checks to avoid liability, and made limited efforts to stop fraud. The risk of this approach is that it impacts the merchants “acceptance rate” — i.e. issuers are more likely to decline payment requests, due to the merchant’s track record. In the worst case, this can actually lead to acquirers not being prepared to work with certain merchants. So, it is something to be taken seriously.

So that’s my 101 guide to online payments. Like I said, greatly over-simplified, and lots of payment methods I haven’t (or have barely) talked about (e.g. payment in instalments, bank payments, etc), but it hopefully gives you a sense of the basics.