Bank account API in Europe: the one read-only check viaBanking performs
Account information services in Europe belong to licensed AIS providers; the only account connectivity here is a read-only look at your own C2B account, used to confirm each incoming credit and nothing else.
No account data product
viaBanking does not sell account information
Licensed AIS scope
Account information services belong to licensed providers
One read-only check
Did the credit reach the C2B account
Software layer
No funds held, no bank payment executed
Six honest lines
The broader account-side plumbing sits on the bank connectivity page.
-
Account information defined
An account information API gives a licensed AIS provider read access to a bank account that its user has authorised. Balances, statements and transaction history sit inside that regulated service.
-
What viaBanking uses
Read-only API connectivity to the merchant C2B account, nothing wider. The question asked of that account is narrow: has the expected amount been credited against this payment reference.
-
Account credit information only
The data point returned to the merchant is information about the transaction being credited to the C2B account. End user account details, spending history and income are never returned.
-
Status and callback model
Two events are reported separately: authorisation by the payer at their own bank, then the credit seen on the C2B account. Each arrives as a separate callback with your reference.
-
Choice of C2B account
Any integrated EMI or bank account can be used with any integrated licensed provider. A business in Europe keeps its banking relationships and still reaches the providers it wants.
-
Records and audit trail
Every payment reference carries the request, the provider response, the account side account credit information and the times each was seen. Support and finance teams work from one searchable record.
Five stages, one narrow read
The regulated context around stages two and three lives on the PSD2 briefing.
- 01
Payment request
Your system calls the viaBanking API with the amount, the currency, the payer's chosen bank and your reference. Nothing about the end user's account is requested at this point or stored.
- 02
Initiation by a licensed provider
A licensed payment initiation provider receives the mapped request and initiates the transfer under its own authorisation. viaBanking is not a party to the payment and touches no funds at any stage.
- 03
Authorisation at the user's bank
Strong customer authentication and the user's payment consent happen on the customer's own bank side. Login details and second factors stay between the user and that bank, never reaching the merchant.
- 04
Intermediate report
An authorisation callback from the provider is passed to you marked as such. It records the user agreeing the transfer, which is a different fact from money on your account.
- 05
Account credit confirmation and final status
Read-only API connectivity to the C2B account is checked for a matching credit. When the EMI or bank reports the amount against your reference, the final status is issued. No other field is read.
Who does what
| Who | What they do |
|---|---|
| The merchant | Contracts the C2B account, calls the API and acts once a credit is confirmed. |
| The licensed provider | Holds the payment initiation or account information licence and performs the regulated action under it. |
| 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 and returns account credit information over its API, read-only. |
| viaBanking | Orchestrates the request, maps statuses, reads only the account credit confirmation and stores the record. |
Four reasons less is more
-
Narrow data footprint
Buying account credit confirmation instead of an account data feed keeps end user information out of your systems. Fewer categories of personal data narrow what your security review has to cover.
-
Honest final status
Order release, shipping and account crediting on your side can be tied to the credit event rather than an authorisation message. Cases where a user pulls back beforehand stay visible.
-
One European contract
A single software agreement covers the layer across the markets you collect in. Provider access runs through viaBanking and your account relationship stays direct, so either side can change without a new integration.
-
Clear boundaries in diligence
Partners and auditors ask who performs each regulated action. Naming the licensed provider, the account holding institution and the software layer separately keeps that answer short and accurate.
Six questions with plain answers
| Question | Answer in the product |
|---|---|
| What is read | Whether a credit matching the payment reference and amount is present on the merchant C2B account. |
| What is not read | Balances as a product, statements, transaction history, income, end user account details, name or IBAN checks. |
| Who authorises access | The merchant, for its own account, by issuing API credentials at the EMI or bank holding it. |
| Where the user authenticates | On the customer's own bank domain, under that bank's strong customer authentication. |
| Retention | Payment references, amounts, statuses, timestamps and provider identifiers, on the terms in your software agreement. |
| Sandbox behaviour | Authorised with no credit can be simulated, so your code meets that case before live traffic. |
Four buyer profiles
Teams routing across several providers per market should also read the aggregator overview.
-
European e-commerce
Merchants collecting account to account payments across several markets who need the money on the C2B account before dispatch. No end user account data is required for that decision.
-
Wallet top ups
Platforms that credit a user balance as soon as a payment is confirmed rely on the account side event, which keeps the wallet in step with the bank.
-
Software platforms
Companies embedding account to account payments for their own customers pass through one status model and one record format, without taking on account information services or that licence.
-
Finance and reconciliation teams
Teams matching incoming credits to orders read confirmations that already carry the bank reference and the amount as the account saw it, removing a manual step between two dashboards.
Three prerequisites
- 01
Software agreement with viaBanking
Terms for the orchestration layer, API keys for your environments, callback endpoints and dashboard access. That agreement covers software and access to integrated licensed payment initiation providers.
- 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 with API access
An account at an EMI or bank that receives the incoming transfers and provides read-only account credit information. Onboarding for that account is direct with the institution.
Straight answers on the account read
-
Can I buy account aggregation or transaction history from viaBanking?
No. Account information services, including aggregation, balances, statements and transaction history, are performed by licensed AIS providers. viaBanking does not hold that licence, does not resell those feeds and returns no end user account data to merchants.
-
So what is the account connectivity in the product for?
One purpose: read-only confirmation that an incoming credit reached the merchant C2B account. The check compares the payment reference and amount against what the EMI or bank reports. Nothing beyond that account credit information is requested or kept.
-
Do you check that an account belongs to the person paying?
viaBanking runs no checks on the payer or on the payer's own account. The customer's bank authenticates the payer at the moment the transfer is authorised. The only account connectivity viaBanking uses is the read-only confirmation that a credit reached the merchant C2B account.
-
Which European markets does this work in?
Reach depends on the licensed providers accessed through viaBanking and on the EMI or bank holding your C2B account. viaBanking manages provider access; your account relationship stays direct, and viaBanking adds new integrations on the same API contract as markets are added.
-
What does the go live sequence look like?
Sandbox integration against the single API contract first, then provider activation through viaBanking, then API access to the C2B account from the EMI or bank. Elapsed time is usually set by those two institutions rather than the software work.
-
Which teams should be reading this?
Product and payments teams in Europe who want account to account collection with a dependable final status, and who do not want an account data product. Compliance reviewers also use it to see which party performs which regulated action.
Bring your markets, EMI and licensed provider
We will show the account credit confirmation call, the status model and a sandbox reproducing authorised without credit. The account verification page covers the sister check when you need one before a pay-out.
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: