The Four-Party Scheme Flow Step by Step

The flow starts when the cardholder at Meridian Bank London buys goods worth EUR 120 from an online merchant and enters the card number, expiry date and security code at checkout. The merchant website sends the transaction to its payment gateway, which forwards it to the acquirer, Harbour Bank Manchester, together with the merchant details and the amount. Harbour Bank checks that the merchant is active and that the transaction format is correct, then sends an authorisation request through the scheme network to Meridian Bank, the issuer. The request carries the PAN, the amount EUR 120, the currency, the merchant details, the card-not-present indicator and the authentication result. Meridian Bank receives the authorisation request and runs its checks in a fixed order. It first checks that the card is active, not reported lost or stolen, and not expired. It then checks the cardholder account, confirming that the EUR 120 is within the credit limit or the available balance, and it checks the security code and the authentication result. It also runs fraud checks, looking at the merchant, the country, the amount and the cardholder spending pattern, and it may ask for extra authentication if the risk is high. If all checks pass, Meridian Bank approves the transaction, reserves EUR 120 on the cardholder account so it cannot be spent twice, and records the authorisation with a unique authorisation code. The approval travels back along the same path, from Meridian Bank through the scheme to Harbour Bank, and then to the merchant gateway and the checkout page, usually in less than two seconds. The merchant sees an approval code and shows the cardholder a confirmation that the order is accepted, and the merchant can now ship the goods. The approval is not yet a payment, because no money has moved between banks at this stage. The cardholder account shows EUR 120 as reserved or pending, and the merchant account shows nothing yet, because the funds will only move when the transaction is cleared and settled, usually later the same day or the next day. If any check fails, the flow stops with a decline, and the reason must be clear enough for the cardholder and the merchant to act on it. A decline for insufficient funds tells the cardholder to use another payment method, while a decline for a suspected fraud tells the cardholder to contact the issuer. A timeout, where the issuer does not answer in time, is handled by a reversal, which cancels the reservation so the cardholder is not left with EUR 120 held for a purchase that never happened. A business analyst must define the decline codes, the reversal rules and the customer messages, and a product owner should consider how the checkout explains a decline without revealing fraud logic that criminals could exploit. Testing must cover approvals, declines, timeouts and reversals, because each path changes the ledger and the customer experience. Worked example with numbers: the cardholder at Meridian Bank London buys EUR 120 of goods from an online merchant, and the authorisation request travels from the merchant gateway to Harbour Bank, then to the scheme, then to Meridian Bank. Meridian Bank checks that the card is active, not lost or stolen, and not expired, then checks that EUR 120 is within the credit limit and that the transaction does not breach a velocity rule, such as five purchases in ten minutes. The bank approves, and the approval travels back in under two seconds. At the end of the day the acquirer sends the clearing file, the scheme calculates that Harbour Bank owes Meridian Bank EUR 120 less the interchange of EUR 0.36, and the banks settle the net amount through their settlement accounts. Failure and recovery: the flow fails when a check fails, and the decline reason must be clear enough for the cardholder and the merchant to act on it. A decline for insufficient funds tells the cardholder to use another payment method, while a decline for suspected fraud tells the cardholder to call the bank, and a decline for a wrong security code tells the cardholder to check the card. If the authorisation succeeds but the clearing file is wrong, the merchant may be paid the wrong amount, and the recovery is a reconciliation that matches each authorisation to its clearing record. A merchant who does not reconcile daily will discover the error a month later, when the customer complains. For a business analyst, product owner or subject matter expert, the flow requirement must state the checks in order, card status, account status, limit, velocity and fraud, and must state the decline reason for each failure, because a decline with no reason cannot be fixed. The requirement must also state the timing, authorisation in under two seconds, clearing at the end of the day, and settlement the next business day, and must state that the merchant is not paid until settlement. The test pack must include a successful authorisation, a decline for insufficient funds, a decline for fraud, and a clearing file that does not match its authorisations. Source: Visa and Mastercard scheme rules; last reviewed 7 November 2026.