Regional cluster · Europe
Europe shares one set of banking rules and runs on dozens of separate technical realities. viaBanking puts a single API contract in front of them. Licensed providers initiate each payment on the payer's consent, banks move the funds on European rails, and our layer confirms in read-only mode that the transfer reached the C2B account your company holds.
The scale problem
A company that decides to accept bank payments across Europe rarely finds one project. It finds a series of them, spread out over years, each with its own bank list and its own failure modes.
A payment request that a German bank accepts without comment can come back from a Portuguese bank with a different consent step, a different reference format and a different status vocabulary. Europe is one regulatory space, and it is not one technical one.
Some European banks have run a stable open banking interface for years. Others rebuilt theirs last quarter. A company integrating market by market pays for that spread twice, once in build time and once in the support queue afterwards.
A licensed provider that reaches almost every bank in one country may reach a handful in the next. Companies discover this after they have already written code against that provider, which turns a routing decision into a rewrite.
A provider tells you it accepted the payment instruction. That message is about the instruction. Whether the transfer actually landed on the account your finance team reconciles against is a separate question, and many integrations leave it unanswered. Teams then fill the gap with manual bank statement checks, which is exactly the manual work the payment automation was supposed to remove.
Definition
Three parties, three distinct jobs. The framework is set out in detail on the PSD2 open banking page.
Under PSD2, banks throughout the European Economic Area must operate a dedicated access interface alongside their consumer online banking. It carries a payment instruction in, and payment status data back out. That obligation is the whole reason open banking exists as a European category rather than a per-bank favour.
Nothing moves without the user's payment consent. The payer approves a specific payment, for a specific amount, to a specific account. Strong customer authentication happens inside the payer's own bank, on the bank's own screens.
Only an institution holding a payment initiation authorisation may use that bank channel to start a payment. A software company can orchestrate the calls around it, and the regulated action itself belongs to the licensed provider throughout Europe.
The platform
Your product calls one API. viaBanking works out which licensed provider reaches the payer's bank in that European market, translates the request into the shape that provider expects, and maps the answer back into a single payment model. The provider carries the licence and performs the initiation.
Amounts, currencies, references, payer bank identifiers and status names come back identically whether the payment started in Italy or in Estonia. Reconciliation logic is written once, without a per-country transformation file quietly rotting in your repository.
Alongside the provider status, viaBanking watches your own C2B account in read-only mode through a licensed partner and raises a confirmation event when the funds arrive. Your systems act on that event, and your treasury management process gets a transfer level fact rather than an acknowledgement. It is a check on your account, and it is never a check on the payer's account.
Nothing in this arrangement asks your company to manage a payment licence, and nothing asks your engineers to learn how many banks sit behind a given payer's selection. Your team manages one payment contract with viaBanking and one account relationship with the EMI or bank holding the C2B account. The wider product surface behind this is described on the open banking platform page, and the licensing boundary on the PIS provider page.
Capabilities
| Capability | What happens | Performed by |
|---|---|---|
| Payment routing | Request goes out to the licensed provider that reaches the payer's bank | viaBanking routes |
| Payment initiation | The instruction is started on the payer's consent | Licensed PIS provider |
| Authentication | Strong customer authentication on the payer's own bank screens | The payer's bank |
| Funds movement | The transfer travels on European bank rails | Banks and EMIs |
| Status normalisation | One vocabulary for every provider and every market | viaBanking |
| Account credit confirmation | Read-only check that the amount reached your C2B account | viaBanking, via a licensed AIS partner |
Coverage map
Companies rarely switch on one country. They switch on a region, because their customers are already spread across it. These groupings reflect how European expansion tends to run, and each market has its own page with the local detail. A payer in one of these markets never sees the grouping, of course. It only shapes how many payment routes your company switches on at once, and in which order.
The largest volume markets in Europe, where card habits and bank transfer habits sit side by side and a business usually wants both. Bank API quality is generally high and the operational work is about breadth rather than novelty.
Portugal and Spain are usually switched on together, because a company expanding into one is normally selling into the other within the same year. One integration covers the pair without a second country project.
Bank transfer is the default habit rather than the alternative here. Payers already know what approving a payment inside a banking app looks like, so the work is coverage and status handling rather than user education.
A dense cluster of banks and electronic money institutions serving a payments industry far larger than the population suggests. Companies routinely run all three markets from one integration and one account structure.
Outside the European Union and inside the same payment habits, with its own standard and its own regulator. The mechanics on our side are the same, and the market context is described separately.
Mechanics
Most European businesses already run card acceptance and are adding a bank transfer method beside it. A card payment and an open banking transfer behave differently at every stage, and knowing exactly where they diverge is what makes the checkout design straightforward for the payer. Card remains a card product, managed by your acquirer under its own contract. The transfer route runs on the bank rails the payer already uses.
| Stage | Card rails | Open banking rails |
|---|---|---|
| Who authorises the payer | The card scheme and the issuer, on the card credentials | The payer's own bank, on the user's payment consent |
| What the payer supplies | Card number, expiry and verification value | A login to their own bank, and an approval of the amount |
| Where the amount is fixed | At authorisation, adjustable at capture | In the payment consent the payer approves |
| What the business receives | An authorisation message from the acquirer | A provider status, plus a confirmed credit on the C2B account |
| Credential storage | Card data lives inside a compliance perimeter | No banking credential reaches viaBanking at all |
| Reach | Wherever the card brand is accepted | Wherever a licensed provider reaches the payer's bank |
This table describes mechanics. It makes no claim about cost, speed or the legal treatment of a card payment against a bank transfer, and neither route is presented here as a substitute for the other.
Who uses it
A marketplace collecting from buyers in eight European countries writes one payout reconciliation path rather than eight. Each transfer carries the same reference structure back, whichever bank the buyer used.
Invoices above card limits move as bank transfers anyway. Putting them through open banking turns a manual copy of an IBAN into a pre-filled payment the payer approves in their own banking app.
Funding accounts is where a company most wants to know that money genuinely arrived. The confirmed account credit event is what releases the balance, not the provider acknowledgement that came before it.
Card remains in place for recurring charges, and a bank transfer is offered for annual plans and larger upgrades. Both live behind the same checkout without a second reconciliation stack, and the finance team manages one transfer report rather than many.
A multi passenger booking regularly exceeds the card limit the payer's issuer allows in a single transaction. Offering a bank transfer next to the card field gives that payer a way to complete the purchase without splitting it across several cards.
A company that has accumulated one contract per market can route those markets through one payment layer and keep the provider relationships it wants. The contracts are managed centrally and the payment data model stops varying by country.
Integration
Your backend posts an amount, a currency, a reference and the destination C2B account to one endpoint. No bank-specific fields.
The payer selects their bank from the list of institutions the routed provider reaches in that European market.
The payer approves the payment and authenticates inside their own bank. viaBanking never sees the credentials.
The licensed provider reports what the bank told it about the instruction. This status is relayed, not interpreted.
When the transfer reaches your C2B account, a read-only check raises the confirmation event your systems act on.
Engineering detail, sandbox keys and the payload reference sit on the open banking for developers page.
Security and consent
The payer authenticates on the bank's own pages. No password, no code and no banking credential passes through viaBanking infrastructure at any point in the transaction. The payer is managing their payment inside the banking app they already trust, which is also why the approval step needs no explanation in your checkout.
The user's payment consent covers one amount to one destination. It is not a standing permission to read anything, and it does not survive the payment it was given for. A second transfer from the same payer means a second consent, approved the same way.
The account watched for the credit is your own C2B account, held with a bank or EMI in your company name. viaBanking cannot manage that account, cannot move the funds sitting on it and cannot start an outgoing transfer from it. The read-only permission covers one thing, which is recognising that an expected payment has been credited.
FAQ
It means banks throughout the European Economic Area operate a regulated access interface that licensed providers can use on a customer's instruction. Open banking in Europe is a legal framework first and a set of bank APIs second, which is why coverage differs country by country even though the rules do not.
One integration is what your team builds and maintains. Actual reach in any given European country depends on which banks the licensed providers behind that route have connected. Adding a market is a configuration change on our side rather than a new project on yours, and we map real coverage against your target list before you commit.
Payment initiation is carried out by a licensed PIS provider on the user's payment consent. Authentication and the funds movement belong to the payer's bank. viaBanking builds the routing, the normalised payment data model and the confirmation layer, and holds no licence of its own.
A read-only check on your own C2B account, performed through a licensed AIS partner, which raises an event when the expected amount is credited. It is a signal about your account and your incoming transfer. It is not a look at the payer's account, their balances or their transaction history.
Sandbox access is usually the same working day, and a first European market typically goes live in weeks rather than quarters. The commercial timeline is normally set by opening the C2B account with the EMI or bank, since that onboarding is direct between your company and that institution.
Businesses collecting bank transfers from payers in more than one European country, and companies whose finance operations care about the amount landing rather than about an acknowledgement. Marketplaces, brokers, travel companies and B2B platforms are the usual profile, and so are payment teams tired of maintaining a payment integration per market. If your payers are concentrated in a single country and your payment volume is small, a direct provider contract may serve you better, and we will say so. Country detail lives on the Germany, France and Netherlands pages.
Send us the markets and the bank names that matter first. We come back with what the licensed providers behind our routes actually reach today, and what the C2B account structure would look like for your company.
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.
