Payments Training Hub

FLOW-03: Deliver a Card Payment from Authorisation to Dispute

Flow. Card payment

A customer pays with a card in a shop or online, and the money must move through authorisation, clearing, settlement, and reconciliation, with refunds and disputes handled fairly when things go wrong. The shop needs a fast answer at the till, the cardholder needs a clear statement, the merchant needs to be paid on time, and the bank needs to match every transaction to its ledger. You will also learn how the bank proves each transaction was authorised, cleared, and settled correctly. In this lab you act as the business analyst for the full card payment flow. You will define the authorisation checks, the clearing file exchange, the settlement timing, the fee and interchange rules, and the reconciliation checks. You will also define the refund flow, the chargeback flow, and the evidence each party must provide in a dispute. By the end you will have a complete pack that the cards team, operations, finance, risk, and technology can build, test, and run.

0 of 6 steps done. Tick each step as you finish it, your progress is saved in this browser.

  1. Interview the cards product owner, two merchants, and the operations manager to agree what the service must do. Record the pain: slow authorisation, late merchant settlement, and reconciliation breaks that take days to clear. Define the card types, the channels, and the customer segments in scope, and set measurable objectives, for example authorisation within two seconds for 95 percent of transactions, same day merchant settlement, and a 50 percent fall in reconciliation breaks. Get the sponsor to confirm the objectives before you write any requirement.

  2. List every stakeholder, from the cardholder and the merchant to the acquirer, the issuer, the card scheme, operations, finance, risk, and technology. Build a RACI for the key decisions, naming who is responsible, accountable, consulted, and informed. Walk the current card process with operations and draw the as-is diagram, showing every step, system, handoff, and wait. Record the most common failure reasons, such as declined authorisation, missing clearing records, and late settlement, with the time each step takes.

  3. Define the authorisation checks in order: card status, expiry date, available funds or credit limit, fraud checks, and merchant category rules. State the maximum response time and the message the merchant receives for each outcome. Define the decline codes and the customer message for each code. Define the offline authorisation rule for low value transactions when the network is unavailable, with the floor limit and the risk owner. Walk the design through with risk and technology using an approved case and a declined case.

  4. Define how authorised transactions are batched into a clearing file, how the file is exchanged with the scheme, and how the settlement amount is calculated after interchange and scheme fees. State the clearing cutoff, the settlement timing for the merchant, and the value date applied to the cardholder account. Define the fee rules for domestic and cross-border transactions, and the statement entry the cardholder sees. Agree the timing and the fee rules with finance, so the merchant and the cardholder are never surprised.

  5. Write the functional requirements as testable statements, each with a unique identifier, a priority, and an acceptance test in mind. Cover authorisation, clearing, settlement, statement reporting, refunds, chargebacks, and dispute evidence. Then write the non-functional requirements: authorisation within two seconds, 99.9 percent availability, peak volume handling on busy shopping days, audit logging of every state change, and data protection for card details. Review the full set with the product owner and the test lead, and trace every requirement to a business objective.

  6. Define the refund flow, including who can initiate it, the time limit, and the value date applied to the cardholder. Define the chargeback flow, including the reason codes, the evidence each party must provide, the time limits, and the liability when evidence is missing. Define the daily reconciliation checks that match each authorisation to its clearing record, its settlement record, and its ledger entry, with a clear owner for every break. Present the full pack to cards, operations, finance, risk, and technology for sign off.

Artefacts you produce.

Worked example. Copperfield Bank, a fictional bank in Leeds, issues a debit card to a customer, James Patel. On a Saturday morning James buys groceries for 86.40 pounds at a supermarket, with card transaction reference CPD-2026-3318. The terminal sends an authorisation request, the bank checks the card status, the available balance, and the fraud rules, and approves the payment in under two seconds. James sees the approval on the terminal and the balance updates in his mobile app. That evening the supermarket batches the day transactions into a clearing file, the scheme exchanges the file, and Copperfield Bank settles the merchant amount the next business day after deducting the agreed interchange fee. The transaction reconciles to the ledger the same evening with no break. Three days later James returns faulty goods worth 42.00 pounds, and the merchant processes a refund with reference CPD-2026-3341. The refund is authorised, cleared, and credited to James within two business days. In a separate case a customer disputes a 120.00 pound online charge she does not recognise. The bank raises a chargeback, the merchant provides the delivery evidence within the time limit, and the dispute team reviews the evidence and closes the case in favour of the merchant, with the full trail recorded.