Payments Academy
Timeout: decision point PAYMENT OPERATIONS STARTED LIVE 01 Timeout - not just a delay ACTIVE 02 Duplicate prevention - starts at the point of entry QUEUED 03 Idempotency - built on a unique key carried with every QUEUED 04 Timeout coordination across the chain - Timeouts must be coordinated across QUEUED 05 Layer knows its own deadline - Each layer knows its own deadline and stops QUEUED 06 Scheme - If the scheme shows no record QUEUED A timeout is a decision point, not just a delay, because it forces the system to choose a next step when an answer does not arrive. Step 1 of 6 Timeout: decision point STARTED Timeout not just a delay ACTIVE Duplicate prevention starts at the point of entry QUEUED Idempotency built on a unique key carried with every QUEUED Timeout coordination across the chain Timeouts must be coordinated across QUEUED Layer knows its own deadline Each layer knows its own deadline and stops QUEUED Scheme If the scheme shows no record QUEUED A timeout is a decision point, not just a delay, because it forces the system to choose a next step when an answer does not arrive.
Duplicate prevention PAYMENT OPERATIONS IN PROGRESS LIVE 01 Timeout - not just a delay DONE 02 Duplicate prevention - starts at the point of entry ACTIVE 03 Idempotency - built on a unique key carried with every QUEUED 04 Timeout coordination across the chain - Timeouts must be coordinated across QUEUED 05 Layer knows its own deadline - Each layer knows its own deadline and stops QUEUED 06 Scheme - If the scheme shows no record QUEUED Duplicate prevention starts at the point of entry, where the system checks whether an instruction has been seen before. Step 2 of 6 Duplicate prevention IN PROGRESS Timeout not just a delay DONE Duplicate prevention starts at the point of entry ACTIVE Idempotency built on a unique key carried with every QUEUED Timeout coordination across the chain Timeouts must be coordinated across QUEUED Layer knows its own deadline Each layer knows its own deadline and stops QUEUED Scheme If the scheme shows no record QUEUED Duplicate prevention starts at the point of entry, where the system checks whether an instruction has been seen before.
Idempotency: property makes retries safe PAYMENT OPERATIONS IN PROGRESS LIVE 01 Timeout - not just a delay DONE 02 Duplicate prevention - starts at the point of entry DONE 03 Idempotency - built on a unique key carried with every ACTIVE 04 Timeout coordination across the chain - Timeouts must be coordinated across QUEUED 05 Layer knows its own deadline - Each layer knows its own deadline and stops QUEUED 06 Scheme - If the scheme shows no record QUEUED Idempotency is the property that makes retries safe, and it is built on a unique key carried with every payment instruction. Step 3 of 6 Idempotency: property makes retries safe IN PROGRESS Timeout not just a delay DONE Duplicate prevention starts at the point of entry DONE Idempotency built on a unique key carried with every ACTIVE Timeout coordination across the chain Timeouts must be coordinated across QUEUED Layer knows its own deadline Each layer knows its own deadline and stops QUEUED Scheme If the scheme shows no record QUEUED Idempotency is the property that makes retries safe, and it is built on a unique key carried with every payment instruction.
Timeout coordination across the chain PAYMENT OPERATIONS IN PROGRESS LIVE 01 Timeout - not just a delay DONE 02 Duplicate prevention - starts at the point of entry DONE 03 Idempotency - built on a unique key carried with every DONE 04 Timeout coordination across the chain - Timeouts must be coordinated across ACTIVE 05 Layer knows its own deadline - Each layer knows its own deadline and stops QUEUED 06 Scheme - If the scheme shows no record QUEUED Timeouts must be coordinated across the whole chain, because a short timeout at one end can create a duplicate at the other. Step 4 of 6 Timeout coordination across the chain IN PROGRESS Timeout not just a delay DONE Duplicate prevention starts at the point of entry DONE Idempotency built on a unique key carried with every DONE Timeout coordination across the chain Timeouts must be coordinated across ACTIVE Layer knows its own deadline Each layer knows its own deadline and stops QUEUED Scheme If the scheme shows no record QUEUED Timeouts must be coordinated across the whole chain, because a short timeout at one end can create a duplicate at the other.
Layer knows its own deadline PAYMENT OPERATIONS IN PROGRESS LIVE 01 Timeout - not just a delay DONE 02 Duplicate prevention - starts at the point of entry DONE 03 Idempotency - built on a unique key carried with every DONE 04 Timeout coordination across the chain - Timeouts must be coordinated across DONE 05 Layer knows its own deadline - Each layer knows its own deadline and stops ACTIVE 06 Scheme - If the scheme shows no record QUEUED Each layer knows its own deadline and stops work cleanly when it passes. Step 5 of 6 Layer knows its own deadline IN PROGRESS Timeout not just a delay DONE Duplicate prevention starts at the point of entry DONE Idempotency built on a unique key carried with every DONE Timeout coordination across the chain Timeouts must be coordinated across DONE Layer knows its own deadline Each layer knows its own deadline and stops ACTIVE Scheme If the scheme shows no record QUEUED Each layer knows its own deadline and stops work cleanly when it passes.
Scheme shows no record PAYMENT OPERATIONS COMPLETE LIVE 01 Timeout - not just a delay DONE 02 Duplicate prevention - starts at the point of entry DONE 03 Idempotency - built on a unique key carried with every DONE 04 Timeout coordination across the chain - Timeouts must be coordinated across DONE 05 Layer knows its own deadline - Each layer knows its own deadline and stops DONE 06 Scheme - If the scheme shows no record ACTIVE If the scheme shows no record, the bank reverses the debit and tells the customer the payment did not go through. Step 6 of 6 Scheme shows no record COMPLETE Timeout not just a delay DONE Duplicate prevention starts at the point of entry DONE Idempotency built on a unique key carried with every DONE Timeout coordination across the chain Timeouts must be coordinated across DONE Layer knows its own deadline Each layer knows its own deadline and stops DONE Scheme If the scheme shows no record ACTIVE If the scheme shows no record, the bank reverses the debit and tells the customer the payment did not go through.

Key points of this lesson, in order.

0:00 / 3:16 Step 1 of 6

Timeouts, Duplicate Prevention and Idempotency

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

ReconciliationIdempotencyException

What you will learn

Your objective. By the end of this lesson, you will be able to explain timeouts, duplicate prevention and idempotency. A timeout is a decision point, not just a delay, because it forces the system to choose a next step when an answer does not arrive.

Why it matters. The bank must therefore query the scheme for the status of that specific payment before deciding whether to retry, reverse, or mark it as unknown.

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

  • Timeout: decision point
  • Duplicate prevention
  • Idempotency: property makes retries safe
  • Timeout coordination across the chain
  • Layer knows its own deadline
  • Scheme shows no record

Key terms

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

Idempotency: The property that repeating the same request has the same effect as sending it once. In payments, an idempotency key lets a client safely retry a request after a timeout without creating a duplicate...

Exception: A payment that cannot be processed normally and needs manual handling, investigation or repair. Exceptions arise from missing data, failed screening, account errors or system faults.

Banking architecture diagram showing Timeouts, Duplicate Prevention and Idempotency.

Practise this lesson

Exercise

Write the request and the expected response for the API call described in this lesson.

Use the API resources, operations and fields named in this lesson.

  1. What to do. Write the JSON request with the required fields, the success response, and one error response with its error code.

Correct result. A correct request has all mandatory fields, a valid idempotency key, and the right resource and operation. The success response confirms acceptance, and the error response names the field or rule that failed.

Why. An API contract is a promise between two systems. If the request is wrong, the API must reject it cleanly, not fail silently.

Check your understanding

Practice question

An instant payment is sent at 11pm on a Saturday. The beneficiary bank systems are down for maintenance. What should happen to the payment?

Takeaway and next step

What to remember

The key might combine the customer identifier, the channel, and a universally unique identifier generated at initiation.

Follow EUR 150 through every stage, from instruction to beneficiary credit, and note where it can stop.

Open the Payment Lifecycle Simulator →

Builds on "Designing for 24/7 Availability and Low Latency".

Transcript and full text

Show transcript

A timeout is a decision point, not just a delay, because it forces the system to choose a next step when an answer does not arrive. If a sender bank sends a pacs.008 message to the scheme and receives no pacs.002 response within five seconds, it cannot simply assume the payment failed. The money may already have been credited to the beneficiary, and a retry would send it twice. The bank must therefore query the scheme for the status of that specific payment before deciding whether to retry, reverse, or mark it as unknown. This status query uses the original instruction reference, so the scheme can answer definitively from its own records. Duplicate prevention starts at the point of entry, where the system checks whether an instruction has been seen before. A customer who taps the pay button twice on a mobile app can generate two identical requests for the same EUR 150 payment within a second. The channel layer assigns a unique request identifier to the first tap and recognises the second tap as a repeat of the same request. The system returns the result of the first payment instead of processing a second one. This check must happen before any balance is debited, because once the debit is made, unwinding a duplicate becomes an exception case that needs manual work. Idempotency is the property that makes retries safe, and it is built on a unique key carried with every payment instruction. The key might combine the customer identifier, the channel, and a universally unique identifier generated at initiation. When a service receives a request with a key it has already processed, it returns the stored result instead of executing the business logic again. A payment of INR 10,000 retried three times because of a network fault therefore moves money only once. The idempotency record must be stored durably before the payment executes, so that a crash during processing does not lose the proof that it happened. Timeouts must be coordinated across the whole chain, because a short timeout at one end can create a duplicate at the other. If the channel times out after three seconds but the payment service needs five seconds to complete, the channel may retry while the first attempt is still running. Architects therefore set timeouts from the outside in, giving each inner service a shorter budget than the outer caller. A scheme that allows twenty seconds end to end might give the sender bank fifteen seconds, which gives its internal services ten seconds, which gives the database five seconds. Each layer knows its own deadline and stops work cleanly when it passes. When a payment ends in an unknown state, the system must reconcile it rather than guess. An unknown payment is one where the debit may have happened but the confirmation was lost, and it appears in a reconciliation queue with its full message trail. Operations teams compare the sender ledger, the scheme record, and the receiver confirmation, usually by matching the end-to-end identifier and the UETR. If the scheme shows the payment as settled, the bank marks it complete and sends the confirmation late. If the scheme shows no record, the bank reverses the debit and tells the customer the payment did not go through. Speed matters here too, because the customer is waiting for an answer.

A timeout is a decision point, not just a delay, because it forces the system to choose a next step when an answer does not arrive. If a sender bank sends a pacs.008 message to the scheme and receives no pacs.002 response within five seconds, it cannot simply assume the payment failed. The money may already have been credited to the beneficiary, and a retry would send it twice. The bank must therefore query the scheme for the status of that specific payment before deciding whether to retry, reverse, or mark it as unknown. This status query uses the original instruction reference, so the scheme can answer definitively from its own records.

Duplicate prevention starts at the point of entry, where the system checks whether an instruction has been seen before. A customer who taps the pay button twice on a mobile app can generate two identical requests for the same EUR 150 payment within a second. The channel layer assigns a unique request identifier to the first tap and recognises the second tap as a repeat of the same request. The system returns the result of the first payment instead of processing a second one. This check must happen before any balance is debited, because once the debit is made, unwinding a duplicate becomes an exception case that needs manual work.

Idempotency is the property that makes retries safe, and it is built on a unique key carried with every payment instruction. The key might combine the customer identifier, the channel, and a universally unique identifier generated at initiation. When a service receives a request with a key it has already processed, it returns the stored result instead of executing the business logic again. A payment of INR 10,000 retried three times because of a network fault therefore moves money only once. The idempotency record must be stored durably before the payment executes, so that a crash during processing does not lose the proof that it happened.

Timeouts must be coordinated across the whole chain, because a short timeout at one end can create a duplicate at the other. If the channel times out after three seconds but the payment service needs five seconds to complete, the channel may retry while the first attempt is still running. Architects therefore set timeouts from the outside in, giving each inner service a shorter budget than the outer caller. A scheme that allows twenty seconds end to end might give the sender bank fifteen seconds, which gives its internal services ten seconds, which gives the database five seconds. Each layer knows its own deadline and stops work cleanly when it passes.

When a payment ends in an unknown state, the system must reconcile it rather than guess. An unknown payment is one where the debit may have happened but the confirmation was lost, and it appears in a reconciliation queue with its full message trail. Operations teams compare the sender ledger, the scheme record, and the receiver confirmation, usually by matching the end-to-end identifier and the UETR. If the scheme shows the payment as settled, the bank marks it complete and sends the confirmation late. If the scheme shows no record, the bank reverses the debit and tells the customer the payment did not go through. Speed matters here too, because the customer is waiting for an answer.

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.