UK open banking providers, combined behind one API
One agreement with viaBanking gives access to integrated UK open banking providers through one API, paired freely with the C2B account you already run and confirmed by read-only API connectivity.
Software layer only
Licensed institutions perform every regulated service
Your own C2B account
Open banking provider choice and account choice stay separate
Account credit confirmed by API
Read-only API connectivity to the merchant C2B account
One contract, many providers
Add a UK open banking provider without new merchant-side code
Six pieces the orchestration layer runs
The same routing engine underpins every country covered on the aggregator overview — the UK is one row on that map, not a special stack.
-
Provider routing
Each payment initiation request is passed to the licensed open banking provider you select for that transaction. Routing rules can use bank coverage, currency or merchant account data, and they change without redeployment.
-
C2B account credit confirmation
Read-only API connectivity to the merchant C2B account at the EMI or bank tells viaBanking when the open banking transfer actually credited, using account data. That information becomes the final status your systems act on.
-
One status model
Every UK open banking provider names its states differently. The viaBanking service maps them onto a single set of statuses, so your reconciliation logic is written once and survives any change to your provider mix.
-
Account pairing
Any integrated provider can be combined with any integrated EMI or bank account. A provider that suits one UK bank segment does not force you onto the EMI that provider happens to support.
-
Operations dashboard
One view covers requests, provider responses and credit confirmations across the whole provider set. Support teams stop switching between provider portals and banking portals to help a single customer.
-
Callbacks and logs
Your endpoint receives an intermediate status when the open banking provider reports authorisation and a final status after account credit confirmation. Every call is logged with its payload, so queries are answered from recorded data.
Five stages across the provider set
The wire-level shape of stage one lives on the payment initiation API page.
- 01
Request
The merchant sends one open banking payment initiation request to viaBanking with amount, currency, reference and the destination C2B account. No provider-specific data fields are needed, because routing is handled inside the service.
- 02
Provider selection
viaBanking applies your routing rules and forwards the request to the licensed open banking provider chosen for that payer bank. The provider builds the initiation and returns the redirect the payer follows.
- 03
Authorisation at the bank
The payer authenticates on their own bank's domain and gives the user's payment consent there. Strong customer authentication is hosted and verified by that bank. No credentials pass through the merchant or viaBanking.
- 04
Intermediate status
Provider callbacks report that the payer authorised the transfer. The service normalises the callback and sends your systems an intermediate status. Goods are not released on this signal, because the funds may still not arrive.
- 05
Final status
Read-only API connectivity to the C2B account at your EMI or bank shows the account credit information against the reference. viaBanking then sends the final status, which is the point your order system treats the open banking payment as complete.
Five parties, five duties
| Who | What they do |
|---|---|
| The merchant | Sends the open banking initiation request, holds the C2B account at an EMI or bank, releases goods on the final status. |
| The licensed open banking provider | Holds the payment initiation licence and submits the instruction to the customer's bank, which authenticates the payer and executes the transfer. |
| End user’s account issuing bank | Captures the end user’s payment consent, performs strong customer authentication and sends the authorised payment from the end user’s account. |
| The EMI or bank holding the C2B account | Receives the incoming transfer and provides read-only API access to the account credit information used to confirm it. |
| viaBanking | Routes requests, normalises statuses, confirms account credits read-only and delivers callbacks as a software service. Performs no regulated payment activity. |
Four consequences worth budgeting for
Merchants running the same pattern for pay-in and pay-out will find the wider case set out on the merchants page.
-
Free choice of banking partner
Adding a UK open banking provider normally means adopting the EMI that provider supports. viaBanking separates the two decisions, so treasury keeps its banking relationship and payments keeps the open banking coverage it needs.
-
Cover the gaps
Bank coverage differs by provider and moves over time. Accessing two or three providers through viaBanking and switching by rule helps protect conversion when one connection degrades for a given bank.
-
Fewer false completions
Acting on an open banking provider authorisation alone releases orders against money that never arrived. Waiting for the account credit confirmation removes that class of loss without manual checks, which helps finance.
-
One engineering budget
Every direct provider integration carries its own build, test cycle and maintenance. A single service contract helps turn later provider changes into configuration rather than another development project.
Six mechanics under the API
| Area | How it works |
|---|---|
| Provider access through viaBanking | Your contract is with viaBanking, which manages access and any required merchant onboarding to integrated licensed open banking providers. Provider access through viaBanking are managed for your traffic through this arrangement. |
| Routing rules | Rules are set per payer bank, currency and destination C2B account, and reordered by your team without a merchant-side release. |
| Status mapping | Provider states map onto a fixed set: created, redirected, authorised at bank, credited, failed, expired. Unmapped states appear in the log as raw codes. |
| Callback retries | Failed deliveries are retried on a schedule, with an idempotency key per payment, so repeated calls cannot double-count a credit. |
| Reconciliation reference | Each open banking initiation carries a reference written into the transfer. The read-only C2B data lookup matches against that reference when confirming the credit. |
| Sandbox | A test environment mirrors the production data model and status flow, provider failure cases included, so integration starts before provider activation is complete. |
Four contexts that pay it back
The end-to-end merchant view of the same UK service sits at open banking payments UK.
-
High-value goods
Orders where releasing stock against a false completion is expensive. The account credit confirmation helps dispatch with a status that reflects money on the C2B account.
-
Digital delivery
Accounts credited within seconds of an open banking purchase leave no window to correct a wrong status. The confirmed credit becomes the trigger for release.
-
Marketplaces
Payouts to sellers depend on incoming money being real. One status model gives platform ledgers consistent information, whatever provider handled a given payer bank.
-
Regulated sectors
Merchants whose banking partner was selected for compliance reasons rather than provider convenience. The account stays put and the UK open banking provider set is chosen separately.
Prerequisites
- 01
An agreement with viaBanking
A commercial service agreement and API credentials for the orchestration layer. This covers routing, status normalisation, callbacks, the dashboard and read-only account credit confirmation on your C2B account.
- 02
Provider access through viaBanking
Your agreement with viaBanking gives access to integrated licensed open banking providers without separate merchant contracts with them. We handle any required provider onboarding for your business; the providers retain responsibility for regulated payment initiation.
- 03
A C2B account with API access
A merchant account at an EMI or bank that can receive incoming transfers and provides read-only API credentials. Onboarding for that account is arranged directly with the EMI or bank.
Straight answers on the UK provider layer
-
What does the viaBanking agreement include for UK open banking?
Routing across your open banking provider set, one API contract, a single status model, callbacks with retries, a dashboard and logs, plus account credit confirmation through read-only API connectivity to your C2B account. Regulated payment initiation services stay with the licensed provider.
-
How is UK bank coverage handled?
Coverage comes from the licensed open banking providers available through viaBanking, and viaBanking publishes no counts on their behalf. Routing rules use coverage data to send a payer bank to whichever of your providers serves it best, and the mapping is updated as provider coverage moves.
-
Which party holds the licence in this arrangement?
The open banking provider holds the payment initiation licence and the customer's bank executes the transfer. Your C2B account is held at a licensed EMI or bank. viaBanking supplies a software service and holds no payment licence of its own.
-
What makes a payment final for the merchant?
A credit on the C2B account, seen through read-only API connectivity and matched to the payment reference. Provider authorisation means the payer approved the transfer at their bank, which is an earlier event with its own separate outcome.
-
How long does a UK launch usually take?
Merchant-side work is one integration against the sandbox service, and our engineers help most teams finish inside a few days. Live traffic starts once viaBanking has arranged provider access and your EMI or bank has issued the C2B account credentials, subject to their respective reviews.
-
Which UK businesses benefit most?
Merchants taking open banking payments at volume, especially those whose banking partner was chosen for reasons other than provider compatibility, and those where releasing goods against an unconfirmed payment carries real cost. Single-provider setups gain less from orchestration services.
-
How does an open banking provider help a UK merchant?
An open banking provider is the licensed firm that starts a payment from the customer's bank, which helps you take payments without cards. viaBanking helps on top of that: it puts several providers behind one API and adds the account credit information from your own account, so your team does not have to stitch provider data together.
-
What data does viaBanking hold about our customers?
Only the payment data needed to route and confirm each open banking payment: amount, reference, status history and the account credit information from your C2B account. viaBanking offers no account information services and never reads a customer's balances or statements; that data stays with licensed AIS providers.
-
Can our support team use the dashboard to help customers?
Yes. Support staff use one view of requests, open banking provider responses and account credit information to help a customer who asks where a payment went. Role-based access means support can help without seeing financial data they do not need.
-
Which open banking services does viaBanking not provide?
Payment initiation services and account information services, which are regulated and delivered by licensed open banking providers. viaBanking provides the software service around them: routing, status data, account credit confirmation and logs to help your team run open banking at scale.
Send us your current provider set
Tell us your C2B account arrangement, your open banking providers and the payer banks you care about in the UK. We will help map what routing would look like, what the status flow returns to your systems, and what has to be signed before live traffic.
viaBanking is a software and technology provider. Regulated payment initiation and account information services are delivered by licensed partner institutions. viaBanking does not hold an AIS or PIS licence, does not execute bank payments and does not hold or move funds.
Updated: