A customer returns from their bank and sees a confirmation screen. Your payment API has returned '201 Created'. An order service is waiting to release goods, a ledger is waiting to post cash and a support team needs an answer if the customer calls.
Those systems should not infer the same outcome from one API response. The current Open Banking Standard separates the HTTP result, consent status and payment-order status because they describe different events. It also provides status retrieval and event-notification mechanisms for later changes.¹²
The integration therefore needs its own payment state machine. It should translate provider and bank events into a small set of business states, retain the underlying evidence and give every downstream system a precise answer to the question it is asking.
Separate transport, consent, payment and business state
The first design decision is to keep four kinds of state separate.
Transport state describes an API operation. A '201' response confirms that a resource was created. A timeout means the caller lacks a confirmed response. Neither result establishes that the customer's bank account has been debited or the beneficiary has been credited.
Consent state describes the customer's authority for a payment. The Open Banking payment flow creates a consent resource, sends the customer to their account provider for authorisation and then uses the authorised consent to create a payment order. A consent can be awaiting authorisation, authorised, rejected or consumed without saying that the resulting payment has completed.²
Payment-order state describes initiation and execution. The standard distinguishes the status field on the payment-order resource from the HTTP status of the API call. It also gives a Payment Initiation Service Provider (PISP) a 'GET' path to retrieve consent, payment-order or payment-detail status after submission.²
Business state describes what your platform is prepared to do. An ecommerce order may need a defined settlement signal before fulfilment. A marketplace may hold a seller balance until reconciliation completes. An enterprise resource planning system may post a receivable when submission succeeds and clear it only after stronger evidence arrives.
Keep these states in separate fields or resources. A single 'payment_status' column tends to accumulate conflicting meanings as more banks, rails and product journeys are added.
Define a small internal state machine
Provider and bank status codes belong at the integration boundary. Downstream systems need a stable internal model that remains consistent across providers and API versions.
A useful internal state set for an immediate payment can include:
- 'created, when your platform has stored the customer's intended payment;
- 'awaiting_customer', while bank selection and customer authorisation remain incomplete;
- 'authorised', when the consent has been authorised;
- 'submitted', when a payment-order resource has been created;
- 'processing', while the payment is progressing through bank or scheme checks;
- 'debtor_account_settled', when the available evidence says the payer's account has been debited;
- 'creditor_account_confirmed', when the available evidence says the beneficiary account has been credited;
- 'failed', 'cancelled' or 'blocked', for terminal exception outcomes; and
- 'reconciliation_required', when the platform cannot yet establish a safe business outcome.
These names are an internal design recommendation. They are not a replacement for the standard's codes. Store the raw provider and account-servicing payment service provider (ASPSP) status, reason code, response payload and timestamp beside every mapped transition.
The distinction between payer-side and beneficiary-side evidence deserves particular attention. The Open Banking payment-status guidance describes 'ACSC' as settlement completed on the debtor account and 'ACCC' as the beneficiary account credited. It also describes intermediate and exception states such as pending, rejected, blocked and accepted without posting. Availability can vary with payment type, rail and ASPSP implementation.³
Your commercial state should therefore be linked to an explicit evidence policy. Name the external states that permit fulfilment, ledger posting, customer confirmation and exception handling. Review that policy whenever a provider, bank, payment type or API version changes.
A timeout creates an unknown state
The most dangerous retry begins with a simple sequence: your platform submits a payment, the bank creates it, and the network connection fails before the response reaches you. Treating the timeout as a failed payment can create a second instruction when the customer tries again.
Open Banking 4.0.1 uses idempotency keys on the relevant 'POST' endpoints to guard against duplicate resources. When idempotency applies, the request body must remain unchanged for the same key, and the ASPSP must treat a matching request from the same third party as idempotent when received within the preceding 24 hours. The standard also says a third party should use the `GET` endpoint to check payment status before submitting a duplicate whenever possible.¹
Design retry behaviour around the uncertainty:
- generate one stable idempotency key for each intended payment attempt;
- persist the key and request body before the first network call;
- place a timed-out attempt in `reconciliation_required`;
- query the existing resource when an identifier is available;
- repeat the same request with the same key only within the applicable contract and standard rules;
- create a new attempt only after a controlled decision establishes that a new instruction is safe.
The customer interface should reflect the same state. A neutral message such as “We are confirming your payment” preserves accuracy while recovery runs. Declaring failure too early encourages duplicate action. Declaring success too early can release value without the required evidence.
Use callbacks for speed and retrieval for recovery
Event-driven updates reduce delay and unnecessary polling. Open Banking 4.0.1 allows an ASPSP to send a signed real-time event notification to a registered callback URL, identifying the affected resource. The third party can then retrieve the resource. The Event Notification API also supports aggregated polling.⁴
A dependable callback path should acknowledge receipt after the event has been stored durably, then process it asynchronously. Its core responsibilities are:
- authenticate and validate the event under the provider's current specification;
- store the original event with its received time and correlation data;
- recognise duplicate delivery without repeating the business action;
- retrieve the latest payment resource when the event is a notification rather than the complete state;
- apply only a permitted state transition;
- publish the resulting internal event to downstream systems; and
- retain processing and rejection reasons for investigation.
Callbacks improve speed. Retrieval and reconciliation provide recovery when a callback is delayed, duplicated, delivered out of order or exhausted after retries. Run a scheduled job over payments that have remained in a transitional state longer than the expected service window. Query the provider, compare the returned state with the local record and route unresolved differences to an owned queue.
This two-path design also supports deployments and incidents. A callback received while a consumer is unavailable can be replayed from durable storage. A missed event can be repaired through retrieval. Both paths converge on the same transition rules.
Make every transition auditable
A current status answers an operational question. A transition history explains how the payment reached that status and gives finance, support, risk and engineering teams a shared record.
For every transition, retain:
- the internal payment and attempt identifiers;
- the consent, provider, ASPSP and end-to-end references available at that point;
- the idempotency key and a hash of the submitted request;
- the previous and new internal states;
- the raw external status and reason code;
- the source, such as API response, callback, status retrieval or manual resolution;
- the event, provider and local timestamps;
- the policy or mapper version that approved the transition; and
- any downstream action triggered by it.
Append transitions rather than replacing the only copy of the prior state. The resulting event history makes support investigations faster and allows a changed mapping rule to be assessed against real records.
This evidence model extends the control boundary described in our article on agentic payments architecture. Whether a payment begins with a customer journey, scheduled workflow or AI-assisted orchestration, execution still needs stable identifiers, deterministic transition rules and a reconcilable result.
Measure the states customers actually experience
An aggregate API-availability figure cannot show how long payments spend between authorisation and a usable business outcome. Instrument the state machine itself.
Useful operational measures include transition latency by bank and payment type, the number and age of payments in each transitional state, callback delivery lag, reconciliation break rate, duplicate attempts suppressed, rejection reasons, recovery time and the proportion of payments reaching each evidence level.
Segment these measures by provider, ASPSP, API version, customer journey and deployment version. A rising count in `reconciliation_required` may reveal callback loss, a bank-specific status change, a mapper defect or a downstream backlog while headline availability remains healthy.
Our earlier analysis of Open Banking API quality explains the value of performance data across the bank journey. The state machine turns that external performance into service-level evidence for your own product.
Set alerts on age and invalid transitions as well as error rate. A payment that remains in `processing` beyond its expected window needs attention even when every API call returned successfully.
Test failure sequences before launch
Happy-path testing confirms that the integration can make a payment. Production readiness depends on what happens around incomplete and conflicting evidence.
Include these sequences in sandbox, provider and operational testing:
- customer authorisation succeeds and the return redirect is lost;
- payment submission succeeds at the bank and your request times out;
- the same callback arrives more than once;
- callbacks arrive out of order;
- a payment remains pending beyond the expected window;
- the provider returns a new or unmapped status code;
- the callback endpoint is unavailable during a deployment;
- status retrieval is rate-limited during recovery;
- settlement evidence conflicts with the local ledger; and
- a later return or exception appears after an earlier completion signal.
For each sequence, verify the customer message, internal state, retry decision, downstream actions, alert, reconciliation route and evidence record. Releasing an integration should require these outcomes to be deterministic and observable.
The same test pack belongs in ongoing resilience exercises. Our enterprise operational-resilience playbook sets out the wider service mapping and recovery discipline around these transaction-level controls.
Evaluate providers through the state model
A provider demonstration often concentrates on the customer journey and successful callback. Procurement should examine the complete operating contract.
Ask prospective providers to show:
- the payment and consent states exposed through their API;
- how bank-specific statuses and reason codes are normalised;
- the exact evidence behind any 'paid', 'complete' or 'settled' label;
- idempotency scope, retention and retry behaviour;
- callback signing, retry, replay and delivery-history controls;
- status-retrieval and bulk-reconciliation capabilities;
- expected transition times and bank-level visibility;
- API versioning and notification for mapping changes;
- support ownership for payments left in an uncertain state; and
- exportable evidence for finance, audit and incident review.
Use those answers to complete the integration and resilience sections of the enterprise Open Banking checklist. A useful proof of concept should deliberately trigger uncertainty, duplication and delayed status as well as demonstrating a successful payment.
Asima's Payment Initiation Service says it handles error and status callbacks and provides a settlement signal for integrating merchants and platforms.⁵ The technical discovery should define the exact signal your use case receives, the states it represents and the business actions it can safely support.
Turn payment status into an operating contract
The strongest state model is agreed across product, engineering, finance, operations, support and risk before the integration goes live. Each team should know which evidence authorises its action, how long it will wait, which exceptions it owns and how recovery is recorded.
That shared contract keeps customer messages accurate, prevents duplicate instructions, gives finance a reconcilable ledger and makes provider performance measurable. It also lets the payment layer change without forcing every downstream system to learn a new bank or provider vocabulary.
A dependable Open Banking integration can answer three questions for every payment: what has happened, which evidence proves it and what the platform is allowed to do next.
Footnotes
- Open Banking Limited, Open Banking Read-Write API Profile v4.0.1: idempotency, accessed 6 August 2026.
- Open Banking Limited, Payment Initiation API Profile v4.0.1, accessed 6 August 2026.
- Open Banking Limited, Information flow: payment status, accessed 6 August 2026.
- Open Banking Limited, Event Notification API Profile v4.0.1, accessed 6 August 2026.
- Asima, Open banking infrastructure, accessed 6 August 2026.