Open banking API providers in the UK: run several through one integration
One integration reaches several licensed UK open banking providers at once, paired freely with the EMI or bank holding your business C2B account and confirmed by read-only API connectivity.
Software layer only
No funds held, no payment initiated by us, no payment service licence
Licensed partners
Initiation runs through licensed UK third-party providers
C2B credit check
Read-only API connectivity confirms the credit on your business account
One data model
Uniform statuses for open banking payments across every provider
Six things the layer does
The overview at UK open banking providers covers the same ground for teams that want the sales-first read.
-
Routing across providers
Each payment initiation request is routed to the licensed open banking provider you nominate for that bank, currency or traffic split. Those rules stay open to change in configuration, so a change needs no release.
-
One API contract
Third-party providers differ in field names, error codes and callback shapes. viaBanking presents one request and response format for every open banking service, so your integration for payments happens once and holds as providers are added.
-
C2B account credit confirmation
Read-only API connectivity to the merchant C2B account establishes whether the pay by bank transfer was credited. That account side fact, rather than the provider callback, drives the final payment status your systems receive.
-
Provider and account pairing
Any integrated third-party provider can be combined with any integrated EMI or bank account. A UK business is no longer tied to the single EMI that one payment service provider happens to support.
-
Records in one place
Requests, provider responses, account side confirmations and status transitions are stored against one payment reference. Finance and customer service teams in your business read one record instead of reconciling two dashboards by hand.
-
Callbacks and logs
Your endpoint receives an intermediate status when the open banking provider reports authorisation and a final payment status once the credit is confirmed. Delivery attempts for payments, payloads and response codes are logged and searchable.
Five stages, two statuses
The account side of stage five is documented on the bank connectivity page.
- 01
Request arrives
Your platform sends one payment initiation request to the viaBanking service with the amount, the payer's bank or a pay by bank selection screen reference, the target C2B account and your own order identifier.
- 02
Provider selected
Routing rules pick the licensed open banking provider for that payment, bank and market. viaBanking maps your request into that third-party service provider's format and hands it over. Nothing about the choice reaches your code.
- 03
Payer authorises at the bank
The customer's own bank presents its authentication screens and applies strong customer authentication. At that point the payer's consent to pay for this payment is given on the bank side, with no credentials passing through viaBanking.
- 04
Intermediate status
A provider callback saying the transfer was authorised tells you the payer completed the mandate at their bank. viaBanking passes it on as an intermediate payment status, marked as authorisation rather than arrival.
- 05
Final status from the account
Read-only API connectivity to the merchant C2B account is polled for the matching credit while the payment stays open. Once the amount is seen there, viaBanking sends the final status and your business can release the order.
Five roles, one payment
| Who | What they do |
|---|---|
| The merchant | Holds the C2B account contract, calls the API service for each payment and releases goods once customers pay and the final status arrives. |
| The licensed open banking provider | A third-party provider that initiates the payment to the customer's bank under its own payment service licence. |
| 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 | Credits the incoming transfer to your business account and returns the account credit information over its API service. |
| viaBanking | Routes payments, normalises statuses, confirms the account credit read-only and delivers callbacks and logs as a software service. |
Four consequences that pay it back
The general pay-in and pay-out case for the same pattern is on the merchants page.
-
No single dependency
When one open banking provider degrades or a bank connection on its side stops responding, traffic moves to another integrated provider by configuration. Your checkout stays open and keeps taking payments while that provider issue is resolved.
-
Better provider terms
Running two or more third-party providers keeps pricing and coverage open to a live comparison. Volume of payments can be shifted to whichever payment service offers better terms, without a new integration project.
-
Release decisions on facts
Goods and services are released against a confirmed credit on the C2B account rather than an authorisation message, which protects the business. Customer service teams stop guessing which authorised payments will actually land.
-
Engineering time back
Provider integrations, format changes and callback quirks are absorbed by the viaBanking service. Your developers maintain one contract, and adding a UK open banking provider becomes a commercial task rather than a sprint.
Six mechanics engineers ask about
| Operational area | What multi provider working means in practice |
|---|---|
| Status model | Requested, authorised at the payer's bank, credited on the C2B account. Third-party service provider codes map into those three. |
| Callback delivery | Intermediate and final payment callbacks are signed and retried on a backoff schedule. Failed deliveries stay queued, open and visible. |
| Idempotency | Your order identifier travels with payments across providers. A repeated request returns the existing payment, never a second one. |
| Reconciliation | Each confirmed credit carries the payment reference, the provider reference, the bank reference and the amount seen on the business account. |
| Sandbox | Authorisation success with no credit can be reproduced for open banking payments before production credentials are issued. |
| Coverage upkeep | Bank connection changes at each third-party provider are absorbed in the mapping service, leaving your integration untouched. |
Four kinds of UK operation
Recurring subscribers should read the VRP page for the mandate side.
-
UK e-commerce checkout
Higher value payments where card costs bite and the business releases the order only once the pay by bank transfer is on the C2B account. Bank selection happens in the provider's service flow.
-
Marketplaces and platforms
Several C2B accounts across trading entities, each paired with whichever provider suits that market. One API contract keeps the platform's records for open banking payments consistent across all of them.
-
B2B invoice collection
Finance teams collecting large one off business payments need the credit on the account before releasing a shipment. Customers pay invoices by bank and the invoice references travel with the payment and come back on the credit.
-
Recurring collections
Subscription businesses that already hold a mandate with a licensed third-party service provider gain a uniform view of which payment cycles produced an actual credit, split by provider and by C2B account.
Three prerequisites
- 01
An agreement with viaBanking
A software service agreement covering the orchestration layer, API credentials, your payment callback endpoints and your dashboard users. This is the only contract you hold with viaBanking.
- 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 credentials
An account at an EMI or bank receiving the incoming transfers for your business, with API access for read-only account credit information. You open that account directly with the institution.
Straight answers on multi-provider UK routing
-
What exactly does viaBanking supply on this page?
One integration reaching several licensed open banking providers in the UK, a uniform payment status and data model, read-only confirmation that a credit landed on your C2B account, plus callbacks, logs and a dashboard. Initiation stays with the third-party providers.
-
Which UK banks can my customers pay from?
Bank reach comes from the licensed service providers accessed through viaBanking, and each keeps its own list. Because more than one third-party provider can sit behind the same integration, a gap in one provider's reach can often be covered by another, so customers can still pay by bank.
-
Who holds the licence in this arrangement?
The open banking provider holds the payment initiation licence as an authorised third-party provider. Separately, the EMI or bank holding the C2B account operates under its own authorisation. viaBanking holds neither and supplies a software service: routing, mapping, account credit confirmation, records and callbacks.
-
Does a successful provider response mean I have the money?
No. That response means the payer agreed to pay at their own bank, which is a separate event from money arriving. viaBanking keeps it open as intermediate and sends a final status only after read-only connectivity shows the credit.
-
How long does it take to go live with two providers?
The integration work is one API contract, so a second provider for payments adds configuration rather than development. Timing depends on provider activation through viaBanking and on the EMI or bank agreeing to open API access to the C2B account.
-
Which businesses get the most from a multi provider setup?
Merchants and platforms in the UK running enough volume of open banking payments that a single payment provider's coverage gap, pricing change or outage carries a visible cost. Below that, one provider through the same integration still gives account side confirmation.
-
Who counts as a third-party provider in UK open banking?
A third-party provider, or TPP, is a firm authorised to use open banking APIs: a payment initiation service provider that starts payments, or an account information service provider that reads account data with the customer's consent. viaBanking is not a third-party provider; it is the software service that connects your business to them.
-
Is pay by bank cheaper for a UK business than card payments?
Usually. Open banking payments move from account to account, so your business avoids card scheme and interchange fees and the card chargeback process. Each payment service provider sets its own price per payment, which is why running two providers keeps pricing honest.
-
Can customers pay by bank on mobile?
Yes. On mobile the customer approves the payment in their own bank app, which the provider opens directly; on desktop they usually scan a QR code or log in to their bank online. The payment status reaches your business the same way in both cases.
-
How does a business switch open banking providers without downtime?
Add the new third-party provider in configuration, send a share of payments through it, and move the rest once the payment status and account credit confirmation look right. Your API calls, webhooks and account records stay unchanged throughout.
Send us your provider list and UK markets
Tell us the banks your customers pay from, your third-party provider list and the EMI holding your C2B account. We will map your payments to routing rules, confirm the integration scope and open sandbox access.
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: