Service · United Kingdom
UK payment initiation services, VRP and the account credit confirmation
Licensed open banking providers run every initiation on the UK rail, the customer bank authenticates the payer, VRP covers your recurring charges, and viaBanking confirms each credit read-only on your own C2B account.
Licensed PIS
Each payment is initiated by a licensed provider
VRP mandates
Recurring charges without any fresh customer step
Account credit confirmed
Read-only API connectivity to your C2B account
One data model
Statuses, not provider jargon, across every call
What a UK merchant buys
Six pieces of the UK PIS service
The initiation shape sits on the payment initiation API; the recurring-only view on variable recurring payments.
Single-shot initiation
A one-off payment is created with a single POST: amount, currency, reference and the customer bank identifier. The licensed provider carries the request through to the UK rail, the customer authenticates on their own bank, and your service runs no authentication of its own and stores no bank credentials.
VRP for recurring charges
VRP lets a customer set a mandate once at their bank and then pay on a schedule without any further step. Your billing system calls the viaBanking API with the mandate reference and the amount, VRP routing picks the right licensed provider for that bank, and the collection runs out of the customer bank rail at the agreed time.
Account credit confirmed on your account
Read-only API connectivity to your C2B account turns a provider callback into a final status your finance team can use. The check matches each credit to the reference, so a payment authorised at the bank but not credited stays visible as unconfirmed and never slips off the ledger.
One API, two shapes
One-off initiation and VRP collection share the same request, the same identifiers and the same callback contract. Your handler is written once, and recurring volume uses the same data model as the single payments running beside it.
Dashboard information
Operations staff see every UK request, the provider that handled it, the raw payloads, status transitions with timestamps, and the matched account credit information on the C2B account. Any customer question about a UK banking payment is answered from one record in real time, not from a provider portal.
Sandbox parity
A sandbox reproduces UK provider behaviour across one-off and VRP flows, including customer abandonment, mandate refusal above any agreed VRP limit, and payments authorised at the bank that never arrive on the account.
How one payment runs end to end
Five stages, two events
The account-side plumbing lives on bank connectivity.
- 01
Create the request
Your service posts the payment with an idempotency key, the customer bank identifier, your own reference and, for VRP, the mandate identifier. The response carries a viaBanking payment identifier and, for a one-off payment, the authorisation link your checkout redirects to.
- 02
Authorise or draw against a mandate
A one-off payment sends the customer to their bank for strong customer authentication. A VRP collection runs out of an existing mandate the customer already set at their bank, so no fresh customer step is needed inside the agreed limits.
- 03
Provider callback
The licensed provider reports whether the payer bank accepted the instruction. viaBanking normalises the response and emits an intermediate event. Acceptance at the bank is not the same fact as money on your C2B account.
- 04
Credit observation
Read-only API connectivity to your C2B account surfaces the incoming credit. viaBanking pairs it with the open payment by reference and amount in near real time, so reconciliation stops being a manual join between two exports.
- 05
Final event
A second webhook carries the final status. Your handler keys on the payment identifier and the event identifier, so any retried delivery is safe to process. The order is released or the VRP cycle is marked collected at this point.
Where each duty sits
Who does what
| Who | What they do |
|---|---|
| Merchant | Creates payments, stores the customer mandate reference, handles webhooks idempotently and releases goods or VRP cycles on the final status. |
| Licensed PIS provider | Holds the UK authorisation, runs the initiation and the VRP mandate at the customer bank, and reports what the bank accepted. |
| 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 with C2B account | Runs the UK banking relationship on the receiving side, credits the account on receipt and provides the read-only API connectivity viaBanking reads for each account credit confirmation. |
| viaBanking | Normalises requests and responses, emits events, matches credits and keeps the VRP collection history per mandate queryable with timestamps. |
Reasons UK finance teams pick this model
Four commercial arguments
Teams running the same pattern across markets will find the pan-UK provider view on UK open banking providers.
One contract for one-off and recurring
Adding VRP later does not require a second integration. The request shape, the status set and the callback contract carry across both. Your team keeps one data model as recurring volume grows.
No single-provider lock-in
Routing rules are configuration, not code. Switching the licensed provider for a given bank, or running two in parallel to cover any coverage gaps, does not reach your product and does not need a release.
Order release on evidence
Releasing goods on an authorisation message trusts a signal about the customer bank, not about your account. The observed credit closes that gap for a one-off payment and for any VRP cycle alike.
Fewer failed card renewals
Card subscriptions break on expiry, reissue and blocked ranges. A VRP mandate carries none of those renewal events, and the customer keeps paying without any involuntary churn or time-out that cards invite.
Operational specifics
Six behaviours worth building against
| Topic | Position |
|---|---|
| Status model | Intermediate reports what the customer bank accepted. Final reports the credit observed on your C2B account, with timestamps for each transition. |
| Idempotency | A repeated creation with the same key returns the same payment and the same identifier, not a second one. Your reference is the matching anchor. |
| Webhook signing | HMAC on the raw body plus a timestamp, so replay windows are enforceable and callbacks cannot be spoofed. |
| VRP limits | Each VRP mandate carries the maximum per collection, the period cap and the validity window set by the customer at their bank. Requests above any limit are refused there, not inside your service. |
| Revocation | A customer can stop a VRP mandate at their bank at any time. viaBanking reports no credit for the next collection, so your dunning path can run without delay. |
| Reference information | Your reference travels with every request and appears on the account credit information returned from the account, so matching is deterministic rather than fuzzy by amount and date. |
UK sectors this fits
Four buyer profiles
Online retail
UK merchants selling higher value goods, who release each order on the credit rather than on the authorisation callback. Dispatch runs out of the C2B account record, not out of a provider screen.
Subscription commerce
Firms taking recurring consumer money, where VRP keeps involuntary churn out of the ledger that card renewals otherwise invite in. Any customer whose UK bank supports VRP keeps paying without a card step.
B2B invoice collection
Finance teams collecting one-off bank payments against invoices, needing the credit on the account before releasing goods or services.
Fintech and wallets
Products funding a user balance where VRP tops up on a schedule the customer set once, with each top-up confirmed before the balance information moves.
Conditions for going live
Three prerequisites
- 01
viaBanking agreement
A software agreement for the orchestration layer, with API credentials per environment, callback endpoints and dashboard users. It includes access to payment initiation through licensed providers; viaBanking itself supplies the software layer.
- 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. For recurring collections, the provider must support mandates at the relevant end user banks.
- 03
C2B account with API access
An account at an EMI or bank with read-only API credentials, so the account credit information check can run on time without a human in the loop.
FAQ
Straight answers on UK PIS and VRP
Which services are included, and who performs them?
Your viaBanking agreement includes access to payment initiation by integrated licensed providers, together with routing, callbacks and read-only account credit confirmation. viaBanking onboards your business and handles any required merchant onboarding with those providers. Licensed providers perform payment screening and transaction monitoring within their service scope. viaBanking does not hold or transfer funds, onboard end users to bank accounts or perform regulated checks itself. The end user’s account issuing bank captures payment consent, authenticates the end user and sends the authorised payment. The read-only limit applies to viaBanking’s C2B account check, not to the licensed providers’ payment services.
What does the UK payment initiation service include?
Routing to licensed open banking providers for one-off payments and VRP collections, one API contract, a normalised status model, signed callbacks, read-only account credit confirmation on the C2B account, plus a dashboard with full logs. Any regulated step stays with the licensed party.
Does VRP need a different integration?
No. VRP uses the same request shape, the same identifiers and the same callback contract as a one-off payment. Your service is written once, and both flows run through it without any branching in your data model.
Who holds the licence here?
The licensed payment initiation provider accessed through viaBanking, under its UK authorisation. The receiving C2B account belongs to an EMI or bank holding its own banking licence. viaBanking is a software supplier and does not hold any payment licence.
What tells our systems the money is really there?
The final status, after the read-only account check matches an incoming credit to the reference you set at request time. Acceptance at the customer bank is reported earlier and does not prove money has landed.
How long does a UK launch take?
A first integration against sandbox is usually a few days. Live timing follows the provider's commercial review and the EMI opening the C2B account, with viaBanking handling required provider onboarding and you arranging the C2B account directly with its institution.
Which businesses get the most out of VRP in the UK?
Subscription merchants, fintech wallets, lenders and any customer-funding product where card renewal failures or a missed collection carry real cost. VRP keeps every customer on a bank rail, not on a card network that times credentials out of the loop.
Scope your UK PIS and VRP integration
Tell us the UK bank footprint you collect from, whether VRP matters for your billing information model, and where your C2B account sits. We open sandbox credentials, show the status flow for a one-off payment and a VRP collection, and set out a plan for 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: