The useful way to handle open banking errors and payment statuses is not to memorise codes but to group them: what you show the customer, and whether you can safely retry. A payment moves through statuses such as accepted, completed or rejected, and in v4.0.1 those status codesets were split by payment type. This page is about handling outcomes robustly.
Errors, grouped by what to do
Banks return error information, and the detailed reason codes draw on standards such as ISO 20022. Rather than reproduce a long table, the practical approach is to map errors onto two questions: what does the customer need to see, and can you retry? Grouped that way, most situations fall into a handful of buckets:
| Situation | Show the customer | Retry? |
|---|---|---|
| Temporary / technical failure | Something went wrong, please try again | Yes, with backoff |
| Consent expired or revoked | Please reconnect to continue | Re-consent, not a blind retry |
| Insufficient funds (payment) | The payment could not be taken | No, not without a change |
| Customer abandoned authorisation | Prompt to complete, or offer another method | Restart the journey |
| Rate limited | Nothing; handle silently | Yes, after the limit window |
The detailed reason code tells your provider exactly which case you are in; what you build is the response for each group.
Payment statuses
A payment reports a status you track to a conclusion: initiated, accepted, completed, or rejected, depending on the type. The important v4.0.1 change is that the status codesets were split by payment type, so scheduled, domestic and international, file, and domestic VRP payments each have their own codeset. In practice, build your reconciliation per payment type rather than assuming one shared set of values. See the payment initiation API and what changed in v4.
Consent statuses
Consents also have statuses: awaiting authorisation, authorised, rejected, revoked or expired. Many apparent errors are really a consent that has lapsed or been withdrawn, which is a recoverable situation, you prompt the customer to reconnect, not a failure to retry. Treating consent-state separately from payment-state keeps your error handling clear, and ties directly to the 90-day reconfirmation.
Rate-limit headers
v4.0.1 added optional rate-limit headers, which tell a caller how close it is to a bank's request limits. Respecting them is good practice: it lets a well-behaved integration slow down before it is throttled, rather than hitting a hard limit and failing. Your provider should honour these automatically, but it is worth confirming they do, because ignoring rate limits is a common cause of avoidable failures at volume.
What to retry, and what not to
- Retry: temporary technical errors and rate-limit responses, with exponential backoff and a sensible cap.
- Re-consent, don't retry: expired or revoked consent, where the fix is reconnecting the customer.
- Do not retry: definitive rejections such as insufficient funds, which will simply fail again and may confuse the customer.
The cost of getting this wrong is real: blind retries annoy customers, can look like duplicate attempts, and waste capacity. Robust status and error handling is one of the quiet markers of a good integration.
From the data consumer's side
You consume your provider's handling of this, but you own the customer experience on top. Decide the message and next step for each error group, keep consent errors distinct from payment errors, and make sure your provider respects rate limits and surfaces a clear reason you can act on. The goal is that a failure becomes a helpful prompt, not a dead end.
How Credit Canary does it
Credit Canary normalises bank errors and statuses into clear outcomes you can act on, handles retries and rate limits correctly, and distinguishes consent issues from payment failures, so your journeys recover gracefully rather than dead-ending.
Common questions
What are open banking error codes?
They are the codes a bank returns when a request cannot be completed, covering things like an expired consent, a payment rejection or a temporary failure. The useful way to handle them is by what you should show the customer and whether you can retry.
What payment statuses does open banking use?
A payment moves through statuses such as accepted, completed or rejected. In v4.0.1 the status codesets were split by payment type, so you handle the codeset for each type you use rather than one shared set.
What are rate-limit headers in open banking?
v4.0.1 added optional rate-limit headers that tell a caller how close it is to a bank's request limits. Respecting them helps avoid being throttled and keeps your integration reliable.
Should you retry a failed open banking payment?
It depends on the reason. Temporary or technical failures can often be retried, while a rejection for insufficient funds or a cancelled consent should not be retried blindly. Group errors by whether retry is safe.
Related pages
Primary sources
- Read/Write API v4.0.1 version control (status codesets, rate-limit headers) (checked 14 Oct 2026).
- Read/Write API v4.0.1 payment initiation profile (checked 14 Oct 2026).
Credit Canary provides open banking through fumopay limited, an FCA-authorised account information and payment initiation service provider (FRN 925689), of which Credit Canary is an agent. Underlying bank connectivity is also provided by fumopay limited. This page is an evergreen reference and is reviewed and dated; it is not regulatory, legal or financial advice.