The Payment Initiation API lets a regulated provider start a payment from a customer's account with their consent. It covers domestic, scheduled, standing order, international and file payments, and variable recurring payments, each moving through a consent, authorise, initiate, status lifecycle. You act on the reported status rather than assuming a payment succeeded.
The consent to status lifecycle
A payment is not a single call; it moves through states. The provider creates a payment consent, the customer authorises it at their bank with strong customer authentication, the provider initiates the payment, and the bank reports a status that you track to completion or failure.
The point of the lifecycle is that you never assume success: you reconcile against the final status, which is why status handling is the core of a robust integration.
Payment types
- Domestic single: an immediate one-off payment, the common pay by bank case.
- Scheduled: a single payment set for a future date.
- Standing order: a recurring fixed payment set up through the API.
- International: a cross-border payment, where supported.
- File (bulk/batch): many payments submitted together, for payouts.
- Multi-authorisation: where a business account needs more than one approver.
Not every bank supports every type, so coverage matters; confirm the types you need against your customers' banks.
VRP consent parameters
A variable recurring payment uses a richer consent that sets the limits within which future payments can be taken: a maximum per individual payment, a maximum per period (such as per month), and usually a valid date range. Within those parameters the business can collect varying amounts without re-prompting the customer each time, while the customer keeps enforceable caps. This is what makes VRP a flexible alternative to Direct Debit and card-on-file. See open banking payments.
Status codes in v4.0.1
A significant v4.0.1 change is that the payment transaction status codesets were split by payment type, so scheduled, domestic and international, file, and domestic VRP payments each use their own status codeset rather than sharing one. In practice this means your status handling is per payment type, and a value for one type is not guaranteed to exist for another. Build your reconciliation to the codeset for each type you use, and watch the release notes when versions change. See what changed in v4 and error codes and payment status.
Refunds
Open banking payments do not have a card-style chargeback or reversal. A refund is a separate outbound payment back to the customer. This keeps the flow of funds explicit and auditable, but it means you design a refund process, hold the information needed to pay the customer back, and treat disputes differently from cards. For many businesses this is a feature, cleaner reconciliation, as long as the process is built deliberately.
From the data consumer's side
Your provider implements the API; your job is to design around status and refunds. Decide which payment types you need, make sure your provider and your customers' banks support them, and build reconciliation around the per-type status codesets rather than assuming a payment completed. For VRP, set consent parameters that give you flexibility while keeping the customer's caps clear. Credit Canary handles the lifecycle and gives you a clean status to act on.
How Credit Canary does it
Credit Canary initiates payments through a regulated provider, across the types you need including VRP, tracks the per-type status to completion, and reconciles them in one place alongside Direct Debit and card, with income and affordability from the same platform.
Common questions
What is the Payment Initiation API?
It is the UK open banking profile that lets a regulated provider start a payment from a customer's account with their consent. It covers domestic, scheduled, standing order, international and file payments, and reports a status you can act on.
What is the payment lifecycle in open banking?
A payment moves through consent, customer authorisation at their bank, initiation, and then a status such as accepted, completed or rejected. You act on the status rather than assuming success.
Did v4.0.1 change payment status codes?
Yes. v4.0.1 split the payment transaction status codesets by payment type, so scheduled, domestic and international, file and domestic VRP payments use their own status codesets rather than a single shared one.
How do refunds work in open banking payments?
A refund is a separate outbound payment rather than a card-style reversal. This keeps the flow of funds explicit, but means you design a refund process rather than relying on a chargeback mechanism.
Related pages
Primary sources
- Read/Write API v4.0.1 payment initiation profile (checked 14 Oct 2026).
- Read/Write API v4.0.1 version control (status codeset changes) (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.