During the work on digital bank (neobank) projects, we with the client always go through the stage of designing the conceptual architecture of the digital platform. We determine which modules to take from a fintech partner (according to the Saas model or on client bare metal servers) and which ones we will develop on our own.

We decided to draw up typical diagrams of modern digital bank components and completed them with the entire payment process description using materials from Jas Shah’s article.

Digital bank (neobank) components

Merchant Payment Process

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.

So let’s breakdown all online card payment process. To start the process, there needs to be an exchange of goods or services for payment.


Step 1 - Payment Initiation

The basic payment principle: 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


Step 2 - Payment method verification and routing via Merchant Acquirer

At this point in the process, the 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.

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)

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:

• American Express/DinersClub/JCB
• Visa
• MasterCard/Maestro
• Discover/Maestro UK

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

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.


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.


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 neobanks 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 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 authorization messages here first and the processor will perform some initial checks, then forward the message to the Core Banking System (CBS) 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 processor would reject payments from gambling institutes for example) then the processor will forward the authorisation to the customer's bank for a decision on the request.


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 is worth noting that 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 customer's account for the duration of the stay (as a small deposit). 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 behavior 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.


Step 6 - Core Banking routes decision back to processor

If a payment processor is part of the bank's process then the authorisation response code will be sent here first and the processor will then route this back via the network.


Step 7 - Processor routes decision to the relevant Network

Processor will continue to raise the message back up the chain by sending the authorization 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 authorization response message

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

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)