Payments Training Hub

FLOW-02: Deliver an Instant Payment with Timeout and Duplicate Controls

Flow. Instant payment

A retail customer sends money from a mobile app and expects it to arrive in seconds, at any hour, with a clear confirmation on screen. Behind that simple tap sits a tight chain: real time validation of the account, the limits, and the funds, sanctions screening in seconds, a liquidity check, settlement with the clearing system, and a confirmation back to the sender. If any link is slow, the payment must time out safely, and if the customer taps twice, the payment must never be sent twice. In this lab you act as the business analyst for the full instant payment flow. You will define the validation rules, the timeout limits, the duplicate prevention controls, the settlement steps, and the confirmation and failure messages. You will also define the liquidity, reconciliation, and 24 hour support requirements. By the end you will have a complete pack that the product team, technology, operations, and risk 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 product owner, two retail customers, and the operations manager to agree what instant means for this bank. Record the pain: slow transfers, unclear status, and payments that fail without explanation. Define the rails, the currencies, and the customer segments in scope, and set measurable service levels, for example 95 percent of payments complete within 10 seconds, 99.9 percent availability, and a clear confirmation for every payment. Get the sponsor to confirm the service levels before you write any requirement.

  2. List every stakeholder, from the retail customer and the product team to operations, risk, compliance, technology, and the clearing system. Build a RACI for the key decisions, naming who is responsible, accountable, consulted, and informed. Walk the current payment process with operations and draw the as-is diagram, showing every step, system, handoff, and wait. Record the most common failure reasons and the average time each step takes, so the redesign is based on evidence and not on guesswork.

  3. Define the real time checks in order: account validation, daily and per payment limits, available funds, sanctions screening, and fraud checks. State the maximum time allowed for each check and the total time budget for the whole payment. Define the liquidity check that confirms the bank can settle before the payment is accepted, and the queue or rejection rule when liquidity is short. Walk the design through with risk and technology using a clean payment and a payment that fails screening, and correct any step the examples prove wrong.

  4. Set the timeout for each system call and for the whole payment, and define what happens when a timeout occurs: the payment is marked as unknown, the customer sees a clear message, and an investigation starts automatically. Define the idempotency key rule, so that a retried request with the same key returns the original result and never creates a second payment. Define the duplicate check on amount, account, and reference within a short window, and the rule for a customer who taps the send button twice.

  5. Write the functional requirements as testable statements, each with a unique identifier, a priority, and an acceptance test in mind. Cover initiation, validation, screening, settlement, confirmation, timeout handling, duplicate prevention, returns, and status reporting. Then write the non-functional requirements: completion within 10 seconds for 95 percent of payments, 24 hour availability, peak volume handling, audit logging of every state change, and data protection. Review the full set with the product owner and the test lead, and trace every requirement to a business objective.

  6. Define how the payment settles with the clearing system, how the sender and the beneficiary are confirmed, and what message each party sees when a payment succeeds, times out, or fails. Define the daily reconciliation checks that match each instant payment to its settlement record and its ledger entry, with a clear owner for every break. Define the 24 hour support model, the incident triggers, and the rollback or pause rule if success rates fall. Present the full pack to business, operations, risk, and technology for sign off.

Artefacts you produce.

Worked example. Bluewater Bank, a fictional bank in Manchester, offers instant payments through its mobile app. A customer, Sarah Collins, sends 750 pounds to her brother, with reference SBC-2026-0821, at 21:14 on a Saturday. The app validates the account and the daily limit, checks the available funds, and screens the payment in under three seconds. The liquidity check passes, the payment settles through the clearing system in six seconds, and Sarah sees a confirmation screen at 21:14 with the payment reference and the beneficiary name. Her brother receives the money and a notification within seconds. Two minutes later Sarah taps the send button again by mistake on the same payment screen. The app sends the same idempotency key, so the bank returns the original confirmation instead of creating a second payment, and no money moves twice. Later that evening a second customer sends 2,400 pounds, but the clearing system does not respond within the 15 second timeout. The payment is marked as unknown, the customer sees a clear message that the bank is checking the payment, and the investigation team confirms within 20 minutes that the payment did not settle, so the funds are released back to the customer the same evening.