Under the hood: The Merchant Payment Process

A detailed look into how merchant payments work
Reading Time: 11 Mins

A month or so ago (although who can really keep track of time nowadays) I drew up some diagrams showing a basic merchant payments process. I also overlaid a Pick ‘n’ Mix of vendors which could be used to build a challenger bank in a modular way.

When I posted the images I wasn’t ready for the amount of great feedback and appreciation I received. For anyone who has seen it, here you go: Payment Process Diagram

The intention of posting the images was to give transparency and clarity to what is a complicated process. And it seemed to work as I received over 50 requests for high res versions of the images. The one thing I felt was missing from the diagram, was more detail at each stage of this complicated process, which is what the following article will address.

So grab your reading glasses, get some bank cards at the ready (for reference, not to pay for anything), open up the diagram for reference and get ready to find out exactly what happens why you use your card to make a payment…

“Whilst newer banking propositions with their instant notifications will have you believe that money changes hands instantly, the truth is that it can it take a good few days for a merchant payment to be complete”

The Payment Process: Step by Step

Step 1 – Payment Initiation

This is the logical starting point of the merchant payments process. To start the process, there needs to be an exchange of goods or services for payment. In this article, I’ll be focusing on the predominant in-store payment method which is via a card.

Back in the olden’ days, there was one way to take a card payment and that was via a Card Imprinter or ‘Click and Clack machine’ (see below). Remember those!!!

No alt text provided for this image

Nowadays there are multiple methods aside from the more traditional magstripe swipe or ‘dip’ plus signature which is still quite prominent in the US. Most notably Chip & Pin, contactless and online card entry. These more modern methods are what I’ll focus on in detail but the basic payment principle remains the same: Prove that you are the cardholder. Then prove that you have the funds to carry out the transaction.

The next step outlines the first part of the above: Prove that you are the cardholder

Key Players: Merchants and companies with payment facilities

Step 2 – Payment method verification and routing via Merchant Acquirer

At this point in the process, the device or portal checks the details of the card and ensures that the payment method is valid and belongs to the customer. This is the initial verification that occurs BEFORE any payment request is routed to the customer’s bank for authorisation and to check for available funds.

NOTE: The only exception to this is contactless payments where risk is limited to a maximum payment amount which often differs by country and currently up to £45 in the UK. Possession of the card is all the verification required to initiate the process

Physical Payment Verification (Chip and Pin) 💳

Valid card with the correct PIN ✅

  1. Customer inserts card is prompted to enter their PIN (Terminal Messaging: ‘Enter PIN‘)
  2. The device verifies that the PIN entered matches the PIN on the card (many card issuers perform the PIN check directly with the chip on the card which is why if you get your PIN wrong you get instant feedback)
  3. The card is valid, active and the current date is before the expiry date
  4. Payment request gets sent to the card network to continue the process and the terminal waits for a response back (Terminal Messaging: ‘Processing‘/’Authorising‘/‘Please Wait‘)

NOTE: The term Card Network and Card Scheme are sometimes used interchangeably but for the purposes of this I’ll use network

Other scenarios ❌

  • The PIN is entered incorrectly 3 times, payment is rejected then the card is usually blocked (Terminal Messaging: ‘PIN Failed’)
  • Expiry Date has passed and payment is rejected after PIN check is performed
  • The card hasn’t been activated and payment doesn’t get initiated

Online Payment 💻

  1. Customer hits Checkout and selects Card as their payment method
  2. Customer is prompted to enter their:
  • Name (if not already entered)
  • Full Card number (length varies depending on the network i.e. Visa, American Express)
  • Expiry Month and Year
  • Card Verification Code (CVC)/Card Verification Value (CVV)
  • Billing Postcode/Address (linked to the account)

No alt text provided for this image

3. The online payment portal will instantly check the validity of the card number using the Luhn algorithm and can also verify & display the network the card has been issued under. The first digit of the card denotes the network and the following are the key networks:

  • 3 – American Express/DinersClub/JCB
  • 4 – Visa
  • 5 – MasterCard/Maestro
  • 6 – Discover/Maestro UK

If you have more than one debit or credit card, go check out the differences now

4. As well as the validation of the card number, the Expiry and CVV/CVC will also have basic length and format validation (CVV/CVC being 3 or 4 digits and the expiry of the card being in the future)

5. Once the card details have had basic validation performed, and a valid postcode/address has been provided, the portal will attempt to request authorisation and process the payment.

6. More and more merchants are using 3D Secure, which is available with Visa and Mastercard, as an additional layer of security and to shift any liability in failed or fraudulent transactions from the merchant, to the customer’s bank.

Merchants that show the ‘Verified by Visa‘ or ‘Mastercard Securecode‘ logos will have a final verification screen. This screen will summarise the transaction details and depending on the implementation, either ask for a passcode that was set by the customer, or, more likely, send a one-time passcode to the customer’s bank registered phone number. The customer then enters that code to verify themselves and proceed with the payment.

3D Secure Screen

7. Once all the details have been verified on-screen and 3DS has completed, the payment request is sent to the corresponding card and routed to the customer’s bank to continue the authorisation process

Key Players: SumUp, Square, WorldPay (from FIS), Stripe

Step 3 – Authorisation Routing via Network

Once the merchant acquirer has provided initial validation checks, the authorisation request is handed over to the network specified in the card. As mentioned earlier, each network is identified on each card and has connectivity with the different merchant acquiring services so in-store or online portals know where to route requests to once details have been validated and submitted.

The network receives the authorisation request containing the customer’s card information as well the details about the payment itself (Merchant name, Payment Amount, Currency) which will be used by the customer’s bank to give the decision as to whether to authorise the payment or not.

After the request is received from the merchant acquiring service, the network will route the request to the customer’s bank for authorisation and use the first 6 digits of the card (the Bank Identification Number AKA BIN) to ensure they route the request to the correct issuing bank.

Key Players: Visa, MasterCard, American Express, Discover, JCB, DinersClub

Step 4 – Authorisation Routing and Stand in via Payment Processor

Often at the stage between the network and the issuing bank, there will sit a payment processor. This is becoming more and more popular especially with challenger banks who want to get to market and prove a proposition but don’t have the time to go through the process of building connections and pathways with the network or any of the various payment methods saving time and effort. A payment processor can also make the experience more robust for the customer by providing initial fraud checks on merchants and providing authorisation on behalf of the bank in case the bank’s systems are unaccessible (this is called ‘stand-in’).

When a payment processor is part of the customer’s bank flow, the network will be configured to send authorisation messages here first and the PP will perform some initial checks, then forward the message to the Core Banking system of the customer’s bank.

As long as there are no red flags on the merchant at this stage (some accounts will be configured so the PP would reject payments from gambling institutes for example) then the PP will forward the authorisation to the customer’s bank for a decision on the request.

Key Players: GPS, Marqeta, Galileo, Visa DPS

Step 5 – Authorisation Decision within Core Banking

This is the pivot point of the process (that was a mouthful). It’s where authorisation for the payment is given or denied and then flows back to the merchant where it’ll pop up on the merchant terminal where we all dread the message of ‘DECLINED!’. The core banking platform is what banks use to hold the source of truth for accounts and balances. Therefore, it’s also the place that will process the authorisation, and if successful, put a block on funds.

There are several due diligence steps that the core banking platform will go through before providing authorisation for the payment request:

  • Account Status – While most accounts will be ‘active’ there are occasions where the account status may be ‘temporarily locked’, ‘under review’, or have ‘suspicion of fraud’. Under some of these states, the account will be blocked from making any new transactions so this is usually one of the first checks
  • Available Balance – Probably the thing most people will be aware of is, to check if the customer has enough available funds in their account. It worth noting that it’s the ‘available’ balance also takes into account any other payment holds that have been put on the account. For example, if a customer has £300 in their account and uses their card to reserve a room in a hotel, the hotel will put a hold of around £200 on the customers account for the duration of the stay (as a small deposit in case the customer goes all Rock’n’Roll in their room). Often this money doesn’t leave the account but it means the customer only has £100 left available to spend until the hold is removed
  • Risky Merchant – Customers banks maintain lists of merchants that are blacklisted and also merchants that they may distrust or suspect of fraudulent activity. Core banking platforms will cross check the merchant against these lists before giving a decision on the payment
  • Suspicious Amount – Banks continuously monitor transactions so they can detect anomalies in spending habits, identify odd habits, and prevent fraud. If the customer’s spending is outside normal behaviour then the transaction might be declined straight away or the customer might require additional verification. This is where your bank might call you directly to confirm you attempted the payment and then allow the authorisation to go through. And newer digital banks may ask you to verify in the app that it is in fact you making the transaction

Once the key checks come back clear, the bank will provide authorisation via a code that the merchant terminal will receive. Often these codes are displayed on the terminal itself as well as printed on physical receipts. They are also kept by the merchant as a record of authorisations given for previous transactions.

NOTE: In the majority of challenger propositions, this is the point at where you'll get a notification on your phone that the transaction has been successful and sometimes BEFORE the authorisation response even gets to the merchants terminal

Key Players: Mambu, Thought Machine, Temenos, Finacle,

Step 6 – Core Banking routes decision back to PP

Again, IF a payment processor is part of the bank’s process then the authorisation response code will be sent here first and the PP will then route this back via the network.

Step 7 – PP routes decision to the relevant Network

PP will continue to raise the message back up the chain by sending the authorisation response to the network

Step 8 – Network routes decision to the Merchant acquirer

The network then sends the response back to the merchant acquiring service

Step 9 – Merchant terminal displays authorisation response message

And finally, the merchant will display the authorisation response, sometimes with an auth code and sometimes just the ‘Approved’ 😃 or ‘Declined’/’Failed’ ☹️ message. Once the ‘Approved’ message is received, the merchant knows that the customer has the means to pay, and the customer’s bank has put a block (of the purchase amount) on money in the account.

If the merchant receives a ‘Declined’/’Error’ message on the terminal or online, it’s usually because one of the checks outlined in Step 5 failed OR due to a timeout/connection issue. In either case, the customer will usually retry the transaction.

Newer retail banking propositions like Monzo and Starling can give immediate notifications to the customer as to why the transaction has not gone through whether it’s because the account isn’t active or there aren’t enough funds. There are cases, like a suspected fraudulent transaction, where the customer is not allowed to know the reason the transaction has been declined and this is known as tipping off.

Step 10,11,12 & 13 – Presentment and Settlement

Whilst newer banking propositions with their instant notifications will have you believe that money changes hands instantly, the truth is that it can it takes a good few days for a merchant payment to be complete, the money to leave a customer’s account and be deposited into a merchants bank account.

Presentment

At a predefined time, usually the end of the day, the merchant acquiring service (see Step 2) is programmed to send the list of authorised transactions, within a defined period, to the relevant networks. The networks will pull this data together, group it by the various issuing banks of the customers, and create something called a ‘Presentment’ file for each bank.

The Presentment file containing transaction information is then sent to the relevant issuing bank where the customer who made the transaction has their account. The bank will then take the relevant amounts from the customer’s account according to the Presentment file and prepare a bulk payment (aggregation of all the individual payments in the file) to be sent back to the network. During this process, the bank will also perform a reconciliation to ensure that the amount the network is requesting aligns with the authorisations on various accounts and payments the core banking platform has given.

Settlement

Once reconciled with the Presentment file, the issuing bank makes the bulk payment to the network’s account. The network will receive multiple bulk payments from the issuing banks based on the Presentment files sent out. Once payment is received, the network will then work out how much is required to be paid to the merchant’s bank based on the initial set of transactions sent from merchant acquirers.

After having worked out how much to pay each merchant’s bank, the network then pays them the aggregate amount owed, and once received, the merchant’s bank deposits the appropriate amount directly into the merchant’s account.

So around 2 days after the initial transaction, barring any disputes or errors, the flow is now complete. Money has left the customers account and arrived in the merchant’s account

Key Players (issuing banks): HSBC, Barclays Bank, Natwest, RBS, Lloyds, Monzo Bank, Starling Bank

Evolution, not Revolution (for the most part)

No alt text provided for this image

Although some areas of this process have remained largely unchanged, like the settlement process, for example, some change has occurred over the years:

  • Real-Time Notifications and balance updates – Whilst feedback when making a payment in-store or online seems instant, changes to customers account (the balance and transaction) used to appear days later once the transaction had settled. Banks now make balance and transaction information available as soon as the authorisation is processed rather than once the transaction has settled
  • Transaction Speed – As with many things in recent years, technological advances have made things faster. Cars, phones, computers. And making a transaction is no different. Transaction authorisation speeds have improved along with technology advances and banking platforms are much more capable of providing an authorisation response within milliseconds
  • Contactless This is the one area that has significantly improved our speed to complete a transaction. Removing the need to enter a PIN has sped up the end to end transaction flow and significantly improved queueing times at places like Pret (which when you’re in a hurry to grab lunch is a great thing)

Whilst over the past 20 or so years there have been incremental changes in the way that this payment process has evolved there are some changes that are more revolution than evolution:

  • Open Banking – In the next few years, this could be the one thing that shakes up the whole process. Performing a secure, direct, account to account transfer as payment has many upsides but the number of merchants using Open Banking payments is fractional at the moment. This will definitely change in the next couple of years eliminating the need for networks and settlement processes as payments are transferred instantly.
  • Paypal – In my eyes, Paypal are the OGs of FinTech even though they aren’t widely considered as such. They were one of the first companies to allow people to open an account online and use it to transfer money. Most people of my generation would have used to buy something on eBay who them out in 2002 but they are now the biggest online payment gateway
  • Stripe – The PayPal challenger. You need competition to be successful and to push forwards. Messi had Ronaldo. Edison had Tesla. Coke had Pepsi. And now PayPal has Stripe. Looking to dominate the world of payment processing, Stripe has started with eCommerce, making it easier to integrate payments services online. Whilst not a household name like PayPal, Stripe is very much eating away at their 55% market coverage and will no doubt be a household name in the years to come
  • Biometric payments – Biometric security is already being added to most of the devices we use day to day (Laptops, Phones) so rather than carrying a card around connected to a bank account, why wouldn’t centralised biometric verification be embedded into payment acquirers meaning that rather than a Chip and PIN, you just need your finger and your eye…

In Summary

Although it seems like there has been some progress in the payments space, the process is still largely the same, and card payments still account for the majority of merchant transactions. Visa cardholders alone accounted for 185 billion transactions in 2019.

As you can see from the first diagram, there are a lot of pieces in the process which means lots of opportunity for change and consolidation. And with initiatives like Open Banking ready for full-scale adoption as well as companies like Stripe making payment solutions a lot more accessible, change is coming…and it’s coming fast.

Let me know where you think this process will be in the next few years by dropping something in the comments 💬💬💬