Germany · Regional page
Open banking Germany: PSD2 bank connectivity through one API
German buyers judge a payment method on whether it behaves the same way every time. That makes connection quality the product, not a footnote to it. viaBanking gives your company one API to connect to German banks through licensed providers, monitors every route separately, and confirms in read-only mode that the expected amount was credited to the C2B account your business holds.
Definition
Three facts about a German open banking payment
- 01
A regulated interface, operated by the bank
A German bank runs an open access interface that a licensed institution may use when a customer instructs it. Your company does not connect to that bank API directly and does not need permission to do so, because the permission belongs to the licensed provider making the call. This is what open banking in Germany rests on, and it applies to every financial institution covered by the rules.
- 02
The customer authorises inside their bank
The payer selects their German bank, authenticates there and approves the amount and the beneficiary. That is the user's payment consent. Nothing the payer enters is visible to your systems or to ours at any point in the flow.
- 03
The confirmation happens on your account
Separately from the payment itself, a licensed AIS partner reads your own C2B account in read-only mode. When the expected amount is credited, we raise an event. The account being read is your business account, never the payer's.
The reliability problem
Not every German bank connection behaves alike
The obligation to provide an open interface is uniform across German financial institutions. The quality of what is provided is not, and that gap is where an open banking rollout in Germany either earns trust or loses it. Support volume follows the same curve as connection quality, which is why we treat the two as one problem.
German bank interfaces vary in quality
Some German banks run a stable, well documented open banking API. Others answer slowly at month end, or return an error class that means three different things. A payment route built on the assumption that every bank API behaves alike will fail unevenly and unpredictably, and open banking solutions sold as a single uniform product tend to hide that.
One provider does not connect to everything
Coverage of the German market differs by licensed provider, and the differences are largest exactly where you would rather they were not: cooperative banks, savings institutions and the smaller regional financial names your customers actually use.
Degradation is quiet until it is loud
A connection that has slowed down does not announce itself. It shows up as a drop in completed payments that nobody attributes correctly for a week, by which time the support queue has already absorbed the difference.
Nobody owns the question of arrival
A provider confirms the instruction, and the finance team confirms the money, and between those two facts sits an interval that most integrations leave undefined. In a market that expects precision, undefined is the wrong answer.
- Per routeEvery German bank connection monitored on its own
- Read-onlyAccount credit confirmed on your own C2B account, nothing more
- LicensedPartner institutions carry the initiation permission
- OneAPI to connect, whatever happens behind it
The platform
Predictability built on top of unpredictable connections
- 1
One API to connect
Your systems connect once, to one open banking API. Behind that connection, viaBanking routes each payment to the licensed provider that reaches the customer's German bank, and translates both directions of the exchange. The API surface your engineers use does not move when a bank moves.
- 2
Route level monitoring
Each German bank connection is watched separately. A degraded route is visible as a degraded route, so a payment that should be sent elsewhere is sent elsewhere rather than failing in your checkout. Open banking payments fail silently far more often than they fail loudly.
- 3
Support that can answer
When a payment does not resolve, our support team can say which provider carried it, which bank answered and what the bank said. That is a shorter support conversation than the one where three parties each hold a third of the picture, and it is the reason German customers rate support above feature count.
- 4
A defined arrival signal
The credit confirmation removes the undefined interval. One event per payment, raised when the expected amount reaches your own C2B account, and your order logic can depend on it.
The connectivity layer itself is described on the bank connectivity page, and the wider set of open banking solutions built on it on the open banking solutions page. None of these solutions gives viaBanking any financial permission it does not have: the open banking API is software, and every regulated action around it belongs to a licensed institution.
Capabilities
Seven rows, including the one we do not do
| Capability | What it means | Performed by |
|---|---|---|
| Connect to German banks | Through licensed providers, on one API connection | viaBanking routes |
| Start the payment | On the user's payment consent, inside the bank | Licensed PIS provider |
| Authenticate the payer | Strong customer authentication at the account servicing bank | The customer's bank |
| Move the funds | On European bank rails, between the payer's bank and your account | Banks and EMIs |
| Normalise status | One vocabulary across every German route and provider | viaBanking |
| Confirm the account credit | Read-only check on your own C2B account | viaBanking, via a licensed AIS partner |
| Read the payer's account | Not offered, not sold, not technically enabled | Nobody, on this route |
Regulatory context
PSD2, described rather than claimed
Germany is the market where this question comes up first and most often, and open banking solutions are frequently sold there with a licence implied that the vendor does not hold, so it is answered here at length. Everything below is a description of what the directive requires of banks and of licensed institutions. None of it is a statement about viaBanking.
- What the directive requires
Banks must operate a dedicated access interface
The second Payment Services Directive obliges banks across the European Economic Area, Germany included, to provide a dedicated interface through which an authorised third party can reach an account on the customer's instruction. Before PSD2 that access was a matter of individual bank policy. After it, the interface is an obligation and the bank cannot refuse an authorised request that meets the rules.
- Who may use it
Authorisation belongs to the institution
PSD2 defines two relevant permissions. A payment initiation service provider may start a payment on a customer's instruction. An account information service provider may read account data with the account holder's consent. Both are held by supervised institutions. Software vendors that orchestrate calls around those institutions do not acquire the permissions by doing so.
- How the customer is protected
Strong customer authentication stays at the bank
PSD2 requires strong customer authentication for electronic payments, performed by the account servicing institution. In practice a German payer confirms the payment inside their own bank's app or web environment. No third party in the chain, viaBanking included, sees or holds the authentication factors.
- What comes next
The framework continues to develop
A successor package is under discussion at European level, which will adjust the rules around access and liability over time. This page describes the current arrangement in Germany as it stands. We do not offer regulatory advice, and any company planning around future rules should take its own legal counsel.
To state it once more without ambiguity: PSD2 is a directive, not a licence. The permissions it defines, payment initiation and account information, are granted and supervised by the national regulator of the market an institution is established in, and viaBanking holds neither. The PIS and AIS authorisations used on this route belong to the licensed institutions we connect to.
Security and consent
A narrow permission, stated precisely
Authentication factors stay where they belong
The payer's credentials, codes and device confirmations exist only between them and their German bank. viaBanking cannot see them, cannot store them and has no mechanism through which they could arrive.
The consent is bounded
One amount, one beneficiary account, one reference, and it ends when the payment resolves. It is not a standing permission and it does not survive into a second payment.
Our read-only view is deliberately narrow
The only account observed is the C2B account your company holds with a bank or EMI. viaBanking can recognise that an expected amount was credited to it. viaBanking cannot manage the account, cannot send money from it, and does not hold your funds.
Integration
Connect once, then five steps per payment
- 1
Connect once
One set of credentials and one endpoint. Your engineers do not use bank specific parameters at any stage.
- 2
Create the payment
Amount, currency, reference and the destination C2B account go out in a single call.
- 3
The payer authorises
Bank selection, then authentication and approval inside the German bank the customer already uses.
- 4
Status returns
The licensed provider reports, we normalise, and the meaning reaches your systems unchanged.
- 5
Account credit confirmed
The read-only check raises one event when the money is on your account. Your order release hangs off this.
- 1API connection your engineers use and maintain
- 2Independent signals per payment on your account
- 0Payer account data used, stored or offered
Use cases
Where German companies connect this first
Ecommerce with high average orders
German shoppers are comfortable authorising a transfer in their own bank, and the route suits baskets where a card is an awkward fit. The confirmed credit tells fulfilment when to act.
B2B and wholesale invoicing
Invoices paid from a company account, where the reference has to survive the journey so that accounts receivable can match it without a person reading a bank statement.
Account funding on financial platforms
Brokerages and savings products that must not credit a customer balance before the money is genuinely on the company account. Financial platforms are the strictest users of the confirmation signal, and they are usually the first in a German market to ask for it.
Subscription and membership renewals
Annual renewals and large upgrades handled as bank payments while cards continue to carry the smaller recurring charges.
Marketplaces with many incoming payments
One payment shape and one reference structure per transfer, whichever German bank the buyer used, which keeps the platform ledger simple.
Companies operating several markets
Germany connected on the same API that carries other European markets, with no second integration and no second reconciliation model.
FAQ
Six questions German teams ask us
-
How does PSD2 apply to a payment made in Germany?
PSD2 obliges German banks to operate a dedicated access interface and requires strong customer authentication for electronic payments. It also defines which institutions may use that interface: a licensed payment initiation provider may start a payment on the customer's instruction. Those obligations sit with banks and licensed institutions, and this page describes them as market background rather than as our own status.
-
Does viaBanking hold a licence of its own?
No. viaBanking is a software and technology company. We do not hold an AIS or PIS authorisation in Germany or in any other market, we do not execute bank payments and we do not hold or move funds. The regulated services on this route are delivered by licensed partner institutions, and we do not describe our platform as licensed, supervised or authorised.
-
How many German banks can customers pay from?
Reach comes from the licensed providers behind the route. The large German banking groups are broadly reachable, and coverage across cooperative and savings institutions varies by provider. We check the specific banks your customers use against live coverage before you connect, and we do not publish a German coverage figure the product has not confirmed.
-
What exactly is checked on an account?
Only that an expected amount was credited to your own C2B account, checked in read-only mode through a licensed AIS partner. There is no check of the payer's account, no reading of balances, statements or transaction history, and no verification of account ownership. Those things are not part of this product and are not sold as an option.
-
What does connecting actually involve?
Sandbox credentials on the first day, then the work of handling the payment statuses and the credit event, which most teams complete in one to two weeks. Your company separately opens the C2B account with a licensed bank or EMI, directly with that institution. Our support team stays with you through both.
-
Which German businesses is this suited to?
Companies collecting larger amounts, companies whose finance function needs a defined arrival signal, and companies already selling into several European markets. The wider regional view is on the Europe page, and the directive itself on the PSD2 open banking page.
Ask us about the German banks that matter to you
Send the list. We come back with what the licensed providers behind our routes reach today, how those connections have been behaving, and what the C2B account arrangement would look like for your company. If open banking is not the right method for your German volume, we will say so rather than sell you an open banking integration you do not need. Our support team is part of that conversation from the start.
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.