Payments Training Hub
Start with the scenario PAYMENT OPERATIONS STARTED LIVE 01 Start with the scenario - actors, because a design without a scenario ACTIVE 02 Draw the happy path first - put a time budget on every step. QUEUED 03 Timeout to every external - Add a timeout to every external call QUEUED 04 Retry and duplicate rules - Design the retry and duplicate rules next QUEUED 05 Finish with the failure cases - reconciliation that catches what the flow QUEUED 06 Present your flow as a diagram - one-page table of timeouts QUEUED Start with the scenario and the actors, because a design without a scenario is only a diagram. Step 1 of 6 Start with the scenario STARTED Start with the scenario actors, because a design without a scenario ACTIVE Draw the happy path first put a time budget on every step. QUEUED Timeout to every external Add a timeout to every external call QUEUED Retry and duplicate rules Design the retry and duplicate rules next QUEUED Finish with the failure cases reconciliation that catches what the flow QUEUED Present your flow as a diagram one-page table of timeouts QUEUED Start with the scenario and the actors, because a design without a scenario is only a diagram.
Draw the happy path first PAYMENT OPERATIONS IN PROGRESS LIVE 01 Start with the scenario - actors, because a design without a scenario DONE 02 Draw the happy path first - put a time budget on every step. ACTIVE 03 Timeout to every external - Add a timeout to every external call QUEUED 04 Retry and duplicate rules - Design the retry and duplicate rules next QUEUED 05 Finish with the failure cases - reconciliation that catches what the flow QUEUED 06 Present your flow as a diagram - one-page table of timeouts QUEUED Draw the happy path first, and put a time budget on every step. Step 2 of 6 Draw the happy path first IN PROGRESS Start with the scenario actors, because a design without a scenario DONE Draw the happy path first put a time budget on every step. ACTIVE Timeout to every external Add a timeout to every external call QUEUED Retry and duplicate rules Design the retry and duplicate rules next QUEUED Finish with the failure cases reconciliation that catches what the flow QUEUED Present your flow as a diagram one-page table of timeouts QUEUED Draw the happy path first, and put a time budget on every step.
Timeout to every external PAYMENT OPERATIONS IN PROGRESS LIVE 01 Start with the scenario - actors, because a design without a scenario DONE 02 Draw the happy path first - put a time budget on every step. DONE 03 Timeout to every external - Add a timeout to every external call ACTIVE 04 Retry and duplicate rules - Design the retry and duplicate rules next QUEUED 05 Finish with the failure cases - reconciliation that catches what the flow QUEUED 06 Present your flow as a diagram - one-page table of timeouts QUEUED Add a timeout to every external call, and define what happens when each one fires. Step 3 of 6 Timeout to every external IN PROGRESS Start with the scenario actors, because a design without a scenario DONE Draw the happy path first put a time budget on every step. DONE Timeout to every external Add a timeout to every external call ACTIVE Retry and duplicate rules Design the retry and duplicate rules next QUEUED Finish with the failure cases reconciliation that catches what the flow QUEUED Present your flow as a diagram one-page table of timeouts QUEUED Add a timeout to every external call, and define what happens when each one fires.
Retry and duplicate rules PAYMENT OPERATIONS IN PROGRESS LIVE 01 Start with the scenario - actors, because a design without a scenario DONE 02 Draw the happy path first - put a time budget on every step. DONE 03 Timeout to every external - Add a timeout to every external call DONE 04 Retry and duplicate rules - Design the retry and duplicate rules next ACTIVE 05 Finish with the failure cases - reconciliation that catches what the flow QUEUED 06 Present your flow as a diagram - one-page table of timeouts QUEUED Design the retry and duplicate rules next, and make them explicit enough for a developer to build. Step 4 of 6 Retry and duplicate rules IN PROGRESS Start with the scenario actors, because a design without a scenario DONE Draw the happy path first put a time budget on every step. DONE Timeout to every external Add a timeout to every external call DONE Retry and duplicate rules Design the retry and duplicate rules next ACTIVE Finish with the failure cases reconciliation that catches what the flow QUEUED Present your flow as a diagram one-page table of timeouts QUEUED Design the retry and duplicate rules next, and make them explicit enough for a developer to build.
Finish with the failure cases PAYMENT OPERATIONS IN PROGRESS LIVE 01 Start with the scenario - actors, because a design without a scenario DONE 02 Draw the happy path first - put a time budget on every step. DONE 03 Timeout to every external - Add a timeout to every external call DONE 04 Retry and duplicate rules - Design the retry and duplicate rules next DONE 05 Finish with the failure cases - reconciliation that catches what the flow ACTIVE 06 Present your flow as a diagram - one-page table of timeouts QUEUED Finish with the failure cases and the reconciliation that catches what the flow misses. Step 5 of 6 Finish with the failure cases IN PROGRESS Start with the scenario actors, because a design without a scenario DONE Draw the happy path first put a time budget on every step. DONE Timeout to every external Add a timeout to every external call DONE Retry and duplicate rules Design the retry and duplicate rules next DONE Finish with the failure cases reconciliation that catches what the flow ACTIVE Present your flow as a diagram one-page table of timeouts QUEUED Finish with the failure cases and the reconciliation that catches what the flow misses.
Present your flow as a diagram plus PAYMENT OPERATIONS COMPLETE LIVE 01 Start with the scenario - actors, because a design without a scenario DONE 02 Draw the happy path first - put a time budget on every step. DONE 03 Timeout to every external - Add a timeout to every external call DONE 04 Retry and duplicate rules - Design the retry and duplicate rules next DONE 05 Finish with the failure cases - reconciliation that catches what the flow DONE 06 Present your flow as a diagram - one-page table of timeouts ACTIVE Present your flow as a diagram plus a one-page table of timeouts, retries, and failure actions, and ask a colleague to break it. Step 6 of 6 Present your flow as a diagram plus COMPLETE Start with the scenario actors, because a design without a scenario DONE Draw the happy path first put a time budget on every step. DONE Timeout to every external Add a timeout to every external call DONE Retry and duplicate rules Design the retry and duplicate rules next DONE Finish with the failure cases reconciliation that catches what the flow DONE Present your flow as a diagram one-page table of timeouts ACTIVE Present your flow as a diagram plus a one-page table of timeouts, retries, and failure actions, and ask a colleague to break it.

Key points of this lesson, in order.

0:00 / 3:26 Step 1 of 6

Exercise: Design an Instant Payment Flow (initiation to confirmation with timeouts, retries and failure handling)

Real-Time Payments Architecture, Lesson 7 of 7, Narration 3:26, D05 Domestic payment systems

Sanctions screeningReconciliationFraud scoring

What you will learn

Your objective. By the end of this lesson, you will be able to explain exercise: design an instant payment flow (initiation to confirmation with timeouts, retries and failure handling). Start with the scenario and the actors, because a design without a scenario is only a diagram.

Why it matters. This matters because the next payment product you work on may use one of these technologies. Knowing what is real and what is still a proposal is what separates a good analyst from a confused one.

Chapter objective: Learner designs real-time payments architecture, covering 24 by 7 availability, instant clearing, liquidity, and failure handling, and explains how it differs from batch systems. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.

Key learning points

  • Start with the scenario
  • Draw the happy path first
  • Timeout to every external
  • Retry and duplicate rules
  • Finish with the failure cases
  • Present your flow as a diagram plus

Key terms

Sanctions screening: Checking payment parties, countries and references against sanctions lists published by governments and international bodies.

Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.

Fraud scoring: A risk score assigned to a payment based on factors such as amount, location, device, velocity and customer history.

Banking architecture diagram showing Exercise: Design an Instant Payment Flow (initiation to confirmation with timeouts, retries and failure handling).

Practise this lesson

Exercise

Apply the concept in this lesson to a real banking scenario.

Use the definition, the example and the key points in this lesson.

  1. What to do. Explain the concept in your own words, give a banking example with an amount, and state what goes wrong if it is misunderstood.

Correct result. A correct answer names the concept accurately, uses a realistic banking example with a concrete amount, and identifies the consequence of getting it wrong.

Why. Understanding is not memorising a definition. It is being able to explain it, apply it, and spot the failure it prevents.

Check your understanding

Practice question

Which of the following best describes exercise: design an instant payment flow (initiation to confirmation with timeouts, retries and failure handling)?

Takeaway and next step

What to remember

Never retry a payment blindly after a timeout, because the first attempt may have succeeded.

Follow GBP 4,800 through every stage, from instruction to beneficiary credit, and note where it can stop.

Open the Payment Lifecycle Simulator →

Builds on "How UPI, FedNow, Faster Payments and SEPA Instant Do It Differently".

Transcript and full text

Show transcript

Start with the scenario and the actors, because a design without a scenario is only a diagram. Your customer is a small business owner in Manchester who needs to pay a supplier GBP 4,800 before a five o clock deadline. She opens her mobile banking app, enters the supplier sort code and account number, and sees a confirmation of payee match. She taps pay, and the app shows a spinner while the payment is processed. Your flow must cover the app, the channel layer, the payment hub, the fraud and sanctions checks, the core banking debit, the scheme, and the receiver bank, and it must end with a confirmation screen that she can trust. Draw the happy path first, and put a time budget on every step. The app sends a payment instruction to the channel layer with a unique idempotency key. The channel layer turns that instruction into a pain.001 XML message, which is the format the instruction takes when it travels as a message or a file, and forwards it to the hub within one second. The channel validates the format and forwards the payment to the hub within one second. The hub runs account validation, sanctions screening, and fraud scoring in parallel, completing all three within one second. The core banking system debits GBP 4,800 and returns a success response within two seconds. The hub sends a pacs.008 message to the Faster Payments scheme, which forwards it to the receiver bank. The receiver credits the supplier and returns a pacs.002 acceptance, which travels back to the app as a confirmation within ten seconds of the tap. Add a timeout to every external call, and define what happens when each one fires. Give the core banking call a three-second timeout, the scheme call a five-second timeout, and the whole end-to-end journey a ten-second limit. If the core banking call times out, the hub must query the core system for the status of that debit before doing anything else. If the scheme call times out, the hub must query the scheme using the original end-to-end identifier. Never retry a payment blindly after a timeout, because the first attempt may have succeeded. Write the timeout values into your diagram, and check that each inner timeout is shorter than the outer timeout that contains it. Design the retry and duplicate rules next, and make them explicit enough for a developer to build. The mobile app must disable the pay button after the first tap and show a processing state, so a double tap cannot create a second instruction. The channel layer must store the idempotency key before forwarding the payment, and return the stored result if the same key arrives again. If the scheme returns a technical rejection, the hub may retry once with the same key and the same reference. If the scheme returns a business rejection, such as an invalid account, the hub must not retry, but must reverse the debit and tell the customer the exact reason. Finish with the failure cases and the reconciliation that catches what the flow misses. Test your design against three failures, a lost pacs.002 confirmation, a settlement account that runs dry at midday, and a fraud hold that needs a human decision. For the lost confirmation, define a status query and a reconciliation job that runs every five minutes. For the empty settlement account, define a queue and a treasury alert that triggers an automatic top-up. For the fraud hold, define a pending state, a workbench case, and a customer message that explains the delay. Present your flow as a diagram plus a one-page table of timeouts, retries, and failure actions, and ask a colleague to break it.

Start with the scenario and the actors, because a design without a scenario is only a diagram. Your customer is a small business owner in Manchester who needs to pay a supplier GBP 4,800 before a five o clock deadline. She opens her mobile banking app, enters the supplier sort code and account number, and sees a confirmation of payee match. She taps pay, and the app shows a spinner while the payment is processed. Your flow must cover the app, the channel layer, the payment hub, the fraud and sanctions checks, the core banking debit, the scheme, and the receiver bank, and it must end with a confirmation screen that she can trust.

Draw the happy path first, and put a time budget on every step. The app sends a payment instruction to the channel layer with a unique idempotency key. The channel layer turns that instruction into a pain.001 XML message, which is the format the instruction takes when it travels as a message or a file, and forwards it to the hub within one second. The channel validates the format and forwards the payment to the hub within one second. The hub runs account validation, sanctions screening, and fraud scoring in parallel, completing all three within one second. The core banking system debits GBP 4,800 and returns a success response within two seconds. The hub sends a pacs.008 message to the Faster Payments scheme, which forwards it to the receiver bank. The receiver credits the supplier and returns a pacs.002 acceptance, which travels back to the app as a confirmation within ten seconds of the tap.

Add a timeout to every external call, and define what happens when each one fires. Give the core banking call a three-second timeout, the scheme call a five-second timeout, and the whole end-to-end journey a ten-second limit. If the core banking call times out, the hub must query the core system for the status of that debit before doing anything else. If the scheme call times out, the hub must query the scheme using the original end-to-end identifier. Never retry a payment blindly after a timeout, because the first attempt may have succeeded. Write the timeout values into your diagram, and check that each inner timeout is shorter than the outer timeout that contains it.

Design the retry and duplicate rules next, and make them explicit enough for a developer to build. The mobile app must disable the pay button after the first tap and show a processing state, so a double tap cannot create a second instruction. The channel layer must store the idempotency key before forwarding the payment, and return the stored result if the same key arrives again. If the scheme returns a technical rejection, the hub may retry once with the same key and the same reference. If the scheme returns a business rejection, such as an invalid account, the hub must not retry, but must reverse the debit and tell the customer the exact reason.

Finish with the failure cases and the reconciliation that catches what the flow misses. Test your design against three failures, a lost pacs.002 confirmation, a settlement account that runs dry at midday, and a fraud hold that needs a human decision. For the lost confirmation, define a status query and a reconciliation job that runs every five minutes. For the empty settlement account, define a queue and a treasury alert that triggers an automatic top-up. For the fraud hold, define a pending state, a workbench case, and a customer message that explains the delay. Present your flow as a diagram plus a one-page table of timeouts, retries, and failure actions, and ask a colleague to break it.

Full lesson text (all scenes)

Completing a lesson updates your progress dashboard on the homepage.

Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.