Exploring card payments in Europe

How money moves across Europe’s card rails

Written by
Jas Shah

Editor’s note

Card mechanisms work more or less in the same way around the world, depending on the switch or national clearing houses. They’ve worked in more or less the same way since they first gained traction, save the recent addition of some new security measures and the influx of PSPs in the process. With the advent of new payments technologies that leverage card rails without requiring a physical card—such as mobile wallets, biometric or pay by face technology, etc.—will card maintain its dominance, or is the space ripe for disruption?

Share this article

Despite the rise of new payment methods like FedNow in the US, Faster Payments in the UK (instant bank payments), crypto payments and open banking, card payments still dominate the payments space across Europe and most western markets.

In Europe, card payments accounted for 48% of all transactions, while credit transfers accounted for 23% and direct debits for 22%.”

While it’s not that important for consumers to understand in-depth how card payments work, the opposite is true for founders, fintechs and enterprises building card propositions for those consumers.

Understanding the end-to-end process is crucial to building customer-centric products, creating robust and thorough customer support models and finding the right providers to help build, grow and scale the product. 

Having clarity over the whole process also highlights areas of improvement and differentiation vs other products on the market, and generally more knowledge and understanding helps build better products.

“Whilst newer banking propositions with their real-time 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 complete”

The payments process: step by step

Step 1

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. I’m 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!

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, there’s chip & pin, contactless payments and online card entry. I’ll focus on these more modern methods in detail, but the basic payments 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. It also checks 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 (currently £100 in the UK). Possession of the card is the only verification required to initiate the process.

Here’s how verification works across different card payment methods:

Physical payment verification (chip and pin)

This requires a valid card with the correct PIN:

  1. The customer inserts card and 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 confirmed valid, active and not yet expired
  4. The 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 terms Card Network and Card Scheme are sometimes used interchangeably, but for the purposes of this I’ll use Card Network.

Other scenarios might occur, such as:

Online payments

This requires the customer to enter valid details:

  1. Customer initiates a card payment flow by hitting checkout and selecting card as their payment method
  2. Customer is prompted to enter their:
  1. The online payment portal will instantly check the validity of the card number using the Luhn algorithm and can also verify and display the network the card has been issued under. The first digit of the card denotes the network. The key networks are:
  1. In addition to the card number, the expiry and CVV/CVC will also have basic length and format validation (CVV/CVC being three or four digits, and the expiry of the card being in the future).
  1. 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.
  1. More and more merchants are using 3D Secure, which is available through Visa and Mastercard, as an additional layer of security. It also shifts any liability for 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.
  1. Once all the details have been verified on-screen and 3DS has been 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 that in-store or online portals know where to route requests 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, etc) which will be used by the customer's bank to decide 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 six 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 (PP)

Often at the stage between the network and the issuing bank will sit a payment processor (PP). 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. 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 inaccessible (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 before forwarding 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 might be configured, for example, to ensure the PP rejects payments from gambling institutes) then the PP will forward the authorisation to the customer's bank for a decision on the request.

Key players: GPS (now Thredd), Marqeta, Galileo, Visa DPS

Step 5: Authorisation decision within core banking

This is the pivotal point of the process. It's where authorisation for the payment is given or denied and then flows back to the merchant. If denied, it may pop up on the merchant terminal with the dreaded message '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 and checks that the core banking platform will go through before providing authorisation for the payment request:

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 where you'll get a notification on your phone that the transaction has been successful. This sometimes happens BEFORE the authorisation response even gets to the merchant’s 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

The 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

Finally, the merchant will display the authorisation response, sometimes with an auth code and sometimes just with an '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'/'Failed' message on the terminal or online, it's usually because one of the checks outlined in Step 5 failed OR it’s 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. This is known as tipping off.

Steps 10,11,12 & 13: Presentment and settlement

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


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, 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 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.


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 two days after the initial transaction, barring any disputes or errors, the flow is now complete. Money has left the customer’s 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)

Although some areas of this process have remained largely unchanged, for example, the settlement process, 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 a customer’s 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. Transaction authorisation speeds have improved along with technological advancements, and banking platforms are much more capable of providing an authorisation response within milliseconds.

Contactless payments

This is the one area that has significantly improved the speed of completing a transaction and removed friction for lower risk and value transactions. 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 a Manger (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 this payment process has evolved, there are some changes that are more revolutionary than evolutionary.

Biometric payments

Biometric security is already being added to most of the devices we use day-to-day (i.e. laptops, phones), so rather than carrying a physical card around that’s connected to a bank account or credit limit, why wouldn't centralised biometric verification be embedded into payment acquirers so than rather than using a chip and pin, you need only your finger and your eye? And with tokenised/virtual cards linked to Apple/Google/Samsung Pay, biometric verification is already part of many people’s payment routines.

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 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.


Another potential disruptor to the existing card process is crypto innovation. Crypto has had a lot of press over the past few years, both good and bad. But it does offer a clear alternative to the existing card process and circumvent networks, and by definition, the costs that come with using the networks. Once there's more widespread adoption of crypto, especially on the merchant acquiring side to enable merchants to accept crypto, it could prove to be more of a competitor to the traditional card payment process.


Although there has been a lot of change in the payments space as a whole, the card payments process remains largely the same. It still accounts for the majority of merchant transactions and doesn’t show clear signs of slowing down. Current figures show that transactions via the traditional card networks like Visa, MasterCard and American Express make up around 624.86 billion in 2022, up 7.5% from 2021.

That doesn’t mean that card will always be an ever-flowing gravy train, as crypto, open banking and others (including Apple) could disrupt the space in the long term. 

In the short to medium term, cards will remain a dominant figure in the payments space - not least because consumers have a long-established affinity with using cards for payments, and that doesn’t look like it’ll change anytime soon. 

A deeper understanding of the underlying card process is vital for those building card-based propositions or looking to have cards as a key part of their offering in order to build a robust, disruptive and customer-centric product. Without that core understanding, it’s difficult to solve problems for customers, pick the right partners and develop disruptive and forward-thinking products.

About the author

Jas Shah

Jas Shah is a career Fintech and Product expert. He uses his extensive & hands on expertise, honed at the likes of Citi, Fidelity and Schroders, to shape Product Development, define Digital & Product Strategy, speed up time to market and scale products for FS companies, Fintechs and early stage startups. He also shares his Product + Fintech insights in his fortnightly newsletter. Connect with him on Twitter and LinkedIn and check out his website for more info.