Give every retry the same idempotency key
Persist the idempotency key before the first POST. Reuse that exact key and payload for every retry of the same consent or payment order.
The Open Banking v4.0.1 Payment Initiation API profile shows the resource server recognising the repeated request and preserving the ConsentId or PaymentOrderId. The current resource status may have advanced between attempts.
After a timeout, reconcile the resource state before starting another business attempt. Keep the idempotency key with the operation record so every worker follows the same retry path.
19.17 million reported user connections
Run consent as a service lifecycle
A consent record has to connect the customer's instruction, the bank's authorisation and the access or payment activity that follows. That relationship needs an auditable state model across creation, authorisation, use, reconfirmation, revocation and expiry.
The strongest architecture keeps customer-facing truth, bank state and processing state distinct, then reconciles them through events and scheduled checks. Support teams gain a reliable explanation for every access decision, while engineers gain clear recovery paths when callbacks arrive late or status changes race each other.
Two response deadlines arrive first
11 September 2026: responses close for the Retail Payments Infrastructure Board consultation on the UK's next generation core retail payments infrastructure.
6 October 2026: HM Treasury's consultation on modernising payment services regulation closes. Give each response an owner, evidence base and internal sign-off date.
Three more worth reading
Open Banking API version migration: a practical runbook
Plan discovery, compatibility testing, dual running and rollback around evidence from each account provider.
Read article →
How to design an Open Banking payment state machine
Turn asynchronous bank responses into explicit states, transitions and recovery actions your teams can operate.
Read article →
Critical third parties: what Open Banking firms still own
Map regulatory accountability across providers, dependencies, incident evidence and exit planning.
Read article →