United Kingdom · Regional page
The United Kingdom has the most practised open banking payers in Europe. They know the redirect, they approve inside their own banking app, and they expect it to work. viaBanking gives your product one API in front of the UK bank list, licensed providers initiate each payment on the customer's approval, and we confirm in read-only mode that the amount reached the C2B account your company holds.
Definition
Three plain facts about the UK arrangement, before any product argument.
A UK bank operates a dedicated open interface that a licensed third party may call on a customer's instruction. Nothing about open banking payments depends on holding the customer's login on your side, which is what separates open banking from the screen reading tools that came before it.
Someone using open banking to pay by bank in the United Kingdom is taken into their own banking app, where they see the amount, the destination and the reference, and approve it. That approval is the user's payment consent, and it is given to their bank rather than to your website.
Payment initiation is performed by a licensed provider. The bank authenticates its customer and moves the money. viaBanking supplies the API, the routing and the open banking payment data model around those two, and performs no regulated act itself. That division is the same on every open banking route we operate.
Capabilities
| Capability | On the API | Owned by |
|---|---|---|
| Create a payment | One POST, no bank specific fields | Your application |
| Bank selection | The list of UK banks reachable on the routed provider | The customer |
| Payment initiation | Started on the approval the customer gave | Licensed provider |
| Authentication | Handled in the customer's banking app | The customer's bank |
| Status data | One normalised status vocabulary, all providers | viaBanking |
| Account credit confirmation | Read-only check that the amount reached your account | viaBanking, via a licensed partner |
The same split, described from the licensing side, is on the PIS provider page.
UK market context
Neutral background on why open banking in the United Kingdom behaves the way it does. None of it is a statement about viaBanking's own status.
The Open Banking Implementation Entity published one open API specification that the largest UK banks build to. It covers the shape of a payment request, the consent object and the status responses. Because those banks answer in a comparable format, open banking United Kingdom projects start from a firmer base than integrations written across several separate national markets, where no common specification exists at all.
A bank payment approved in a UK banking app normally travels on the Faster Payments Service, which the payer's bank uses to send the funds. This is background about how UK bank transfers work, and it is operated by the banks and the scheme rather than by viaBanking.
Millions of open banking payments are made every month in the United Kingdom. Customers recognise the redirect into their banking app and complete it without hesitating, so a UK checkout adding open banking spends its effort on where the button sits and how it is worded, rather than on explaining what open banking is. New payment methods rarely arrive with that advantage already in place.
The largest institutions are broadly reachable through open banking and the long tail of smaller banks and building societies is not uniform. We map your customer base against what the licensed providers behind the route reach today, before anyone writes code. Coverage data of that kind ages quickly, so we quote what is live rather than what was published last year.
viaBanking is not a member of the Open Banking Implementation Entity, is not registered with the Financial Conduct Authority and makes no claim to a UK regulatory status of any kind. The permissions used on this route belong to the licensed providers we connect to.
The problem
Nobody in the United Kingdom needs convincing that open banking payments are possible. The work has moved to the edges of the flow, where a payment either resolves cleanly or turns into a customer service problem. Open banking projects in the UK fail on those edges far more often than they fail on the happy path, and the failures show up in your support data before they show up anywhere else.
When customers already use open banking payments elsewhere, a slow or broken redirect is read as your fault rather than as a new technology behaving oddly. The UK bar for open banking is set by the best implementation the customer has already seen, which is usually a large retailer or a trading app.
The interesting cases are the ones where the customer abandons the app, the bank returns an ambiguous answer, or the payment lands minutes after the session ended. Each of those needs a defined outcome in your product, and each provider names them differently.
Every licensed open banking provider reaches a particular set of UK institutions with a particular reliability. Building against one of them makes that list your list, and changing it later means touching the integration you already shipped, along with the payment data mapping that came with it.
An accepted instruction tells you the bank took the request. Your finance team needs to know the amount arrived on the account they reconcile. On a busy day the distance between those two facts is where support tickets are born.
The platform
Your application calls one open banking API and viaBanking selects the licensed provider that reaches the customer's bank. If a route degrades, the selection changes on our side without a new release on yours, and your customers see nothing.
Provider specific status names are mapped into one set your code handles. New provider, same payment status data, same branches in your payment logic. Teams that use several providers today usually carry two or three of these mappings, and they can drop them.
Through a licensed partner in read-only mode, we confirm that the expected amount reached your own C2B account and raise one event per payment. That is the event worth releasing an order against, and it is the one your finance data reconciles to at the end of the day.
When a provider adds a UK bank or changes an endpoint, the work happens in our open banking connectivity layer. Your integration is unchanged, and the new bank simply appears in the selection list your customers use.
Wider platform capabilities sit on the open banking platform page, and the European picture on the Europe page.
Integration
You get keys and call the payment endpoint against simulated UK banks. Every status your code will meet in production can be triggered on demand.
Your team wires the outcomes: approved, abandoned, rejected, pending and credited. This is the part that decides how the payment feels to a UK customer.
Your company opens the account with the bank or EMI that will receive the funds. That onboarding is direct between you and that institution, and it usually sets the calendar.
The United Kingdom goes live first, and adding another market later is a configuration change rather than a new API integration.
Use cases
Furniture, electronics and travel baskets where a customer is already used to open banking payments. The redirect into the banking app is familiar, so conversion does not depend on teaching anybody a new habit.
Trading, savings and insurance platforms use open banking payments to fund customer accounts. The confirmed account credit is what unlocks the balance, and nothing is released on an acknowledgement alone.
A payment link that opens the payer's own banking app with the amount and the reference already filled in removes the retyping that makes manual bank transfers go wrong, and it gives your ledger clean payment data.
Money in from buyers is reconciled per payment reference, and the seller ledger is updated on a credited amount rather than on an accepted instruction. Marketplaces use that distinction to decide when a seller balance becomes available.
One off donations and annual memberships work well as open banking payments, and the donor never has to hand over card details to a new website.
A payment request sent to a customer by message opens their banking app on their own device, so no card number is ever read aloud to a member of your staff. New starters can use it on their first day without a payment card terminal.
Security and consent
Your customer authenticates in the banking app they already use every day. Nothing they type there passes through viaBanking, and no credential is stored on our side or on yours.
The consent covers a specific amount to a specific account with a specific reference. It gives nobody a standing permission over that customer's account and it ends with the payment it authorised.
Payment data created by the platform: the amount, the currency, the reference, the routed provider, the status history and the credit event on your own account. That payment data is what your systems use for reconciliation and support. It does not include the customer's balances, their statement or their transaction history, none of which is part of this product or available on any open banking route we sell.
FAQ
The United Kingdom runs its own regime with its own regulator and its own API specification, developed around the largest UK banks. The commercial mechanics are similar in that a licensed provider initiates on a customer approval, and the standards, the supervisory body and the underlying payment rails are separate from the EU arrangements described on the Europe page.
The largest current account providers are broadly reachable through the licensed open banking providers behind our routes, and coverage of smaller institutions varies by provider. We check your actual customer base against the live bank list before you build, rather than quoting a headline number, because published coverage data goes stale faster than anyone updates it.
The licensed provider performing the payment initiation. viaBanking is a software company: we route the request, normalise the payment data and confirm the credit on your account. We hold no UK authorisation and do not present ourselves as a regulated firm.
They approve one payment in their own banking app, seeing the amount, the destination account and the reference. That is the user's payment consent. It is given to their bank, it covers that payment only, and it is not a permission for anybody to read their account afterwards.
Sandbox access is same day and most teams need one to two weeks of engineering, mainly to handle the payment status branches properly. The date that moves is usually the C2B account opening with the receiving institution, which your company arranges directly with them.
Higher value baskets, account funding, invoice collection and any flow where the amount arriving matters more than a fast acknowledgement. Open banking payments are a weaker fit for small repeat charges, where card and direct debit arrangements already do the job well. The developer view of the open banking API, including payload and status data, is on the developers page, and the wider regional picture on the Europe page.
Tell us which United Kingdom institutions your customers actually bank with. We come back with what the licensed providers behind our routes reach today, and what the C2B account setup looks like for your company. If open banking payments are not the right method for the flow you have in mind, we will tell you that in the same conversation.
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 move funds.
