UK banking API for product teams
A UK product team gets one status model, one clear customer flow and a final status backed by the credit that actually landed on the C2B account.
Two separate events
Authorisation at the bank, then account credit confirmed
Licence sits elsewhere
Regulated initiation is performed by licensed providers
Read-only checking
We read your C2B account and nothing else
One status contract
The same states behind every provider you use
Six pieces to build against
The wire-level API is on the API reference; provider setup on UK open banking providers.
Customer redirect handling
We return the link that takes your customer into their own bank app or web banking. SCA and the user's payment consent happen there, under the customer's bank rules, never inside your interface.
Two statuses you can trust
An intermediate status when the customer's bank reports authorisation, and a final status when credit is confirmed on the C2B account. Your screens map to those two facts.
Return and pending screens
Customers often come back before credit is confirmed. The API returns what that screen needs: a reference, the amount the customer authorised, and whether confirmation from the account is still outstanding.
Support view
Support staff see the same records your backend does: the request, the provider callback and the confirmation, each with a timestamp. Most customer questions about a missing payment end there.
Webhook delivery
Status changes reach your services on a signed endpoint with retries. Nothing in the customer flow depends on your team watching a dashboard or polling us for an answer.
Sandbox with awkward cases
Test the paths that hurt: a customer who authorises then closes the tab, a bank that times out, a payment authorised at the bank that is never credited to the account.
Five stages, five decisions
- 01
Choose a bank payment
The customer picks a bank payment at checkout and selects their UK bank. Your decision here is which banks to show, driven by the coverage your licensed provider actually supports.
- 02
Send the customer to their bank
We hand back the authorisation link. Your decision is redirect or new tab, and what to keep on screen for the customers who leave their bank app without finishing the order.
- 03
Read the intermediate status
The provider reports that the customer authorised the payment at their bank. Your decision is whether that is enough to reserve stock, hold a seat or begin a slow fulfilment step.
- 04
Wait for account credit confirmation
We match the incoming credit on your C2B account against the reference. Your decision is what the customer sees while confirmation is outstanding, and how long an order stays open.
- 05
Act on the final status
Confirmed credit releases the order. A payment that stays unconfirmed needs a written rule: retry, cancel, or move the customer to another payment method while the original reference is retained.
Who does what
| Party | Responsibility |
|---|---|
| Merchant | Runs the checkout, decides what each status means for an order and owns the relationship with the customer. |
| Licensed payment initiation provider | Holds the licence and asks the customer's bank to make the payment. Bank coverage comes from this party. |
| 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. |
| EMI or bank holding the C2B account | Receives the incoming payment and reports credit through its API. Onboarding here is direct with that institution. |
| viaBanking | Routes requests, normalises statuses, confirms account credits read-only and delivers callbacks. No customer money passes through us. |
Four reasons product owners pick this
Fintech-shaped teams should also read open banking for fintech in the UK.
Fewer false completions
Treating authorisation as completion releases orders against money that never arrived. A separate confirmation event removes that class of loss without adding a manual check for your operations staff.
Roadmap independence
Switching provider or adding a receiving account does not reach your product code. Coverage and banking decisions stay commercial choices instead of engineering tickets competing with everything else you planned.
Lower support cost
A customer asking where their payment went is answered from one record showing what the bank reported and whether credit arrived. Support stops relaying questions to a provider.
Predictable status handling
One status model across providers means your states, customer emails and refund rules are written once. Adding coverage later reuses the handling your team has already tested.
Six states, six product decisions
| Status or case | What your product should do |
|---|---|
| Awaiting authorisation | Keep the order open and show the customer the amount and reference. No fulfilment action belongs here. |
| Authorised at the bank | Safe to reserve stock or prepare an order. Not safe to hand over goods or credit a balance. |
| Account credit confirmed | Money is on your C2B account against your reference. Release the order and close the payment record. |
| Authorised, no credit | Keep the record open on a timer you define. Decide in advance who reviews that queue and how often. |
| Abandoned at the bank | The customer never authorised. Offer payment again with a fresh request rather than reusing the old one. |
| Unmatched credit | Money arrived without a reference we can match. It is listed for manual review and no order is released automatically. |
Four product shapes
Account top-ups
Crediting a balance only on confirmed money removes the risk of a user spending a top-up that was authorised at their bank and never reached the account.
Ecommerce checkout
A bank payment option beside existing methods, with order release tied to confirmation rather than to the customer returning to your success page.
Customer account funding
First funding of a new account, where activation should follow confirmed money instead of an authorisation message relayed from the customer's bank.
Invoice and B2B collections
Business customers paying by transfer get one request per invoice, and your ledger closes that invoice on the confirmation event instead of on a daily statement review.
Three prerequisites
- 01
Software agreement with us
An agreement with viaBanking covers API access, routing configuration, dashboard accounts and support. It does not make us a party to any payment your customers make.
- 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
C2B account and read-only credentials
A C2B account at an EMI or bank, plus read-only API credentials so we can confirm credit. Onboarding with the EMI is direct between you and that institution.
Straight answers for a UK product team
What is in the banking API UK package for a product team?
Request creation, the customer authorisation link, an intermediate status from the provider, a confirmed-credit final status from your C2B account, webhooks, a dashboard and a sandbox covering the awkward cases. Regulated initiation belongs to your provider.
Do we have to show customers a list of banks?
Your interface decides. The list your provider supports is available through the API, so you can show all of it, show only the banks your customers actually use, or let the provider's own screen handle that choice.
Which party in this flow is regulated?
The licensed payment initiation provider accessed through viaBanking, and the customer's bank that executes the payment. Your C2B account is held at an EMI or bank regulated for that purpose. viaBanking supplies software and holds no licence.
What event tells our backend the money is really there?
The final status, sent after we match an incoming credit on your C2B account over read-only API connectivity. Authorisation at the customer's bank arrives earlier and means only that the customer approved the transfer, not that money has landed.
How much work is a first payment through the flow?
One request call, one redirect and a webhook handler, plus your rules for each status. Most of the calendar time goes on provider activation arranged by viaBanking and the C2B account credentials you obtain directly from your EMI or bank.
Which teams get the most out of this?
Product and payments teams in the UK who need one status model, defensible rules for releasing an order, and the freedom to change provider or receiving account without touching a customer flow they have already shipped.
Bring us your checkout states
Bring the checkout states you run today and the rules attached to them. We will show which map to authorisation and which need confirmed credit, then issue sandbox credentials so your team can run the flow end to end. The engineering-first read sits at UK digital banking integration API.
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.
Updated: