Connectivity · Software layer
Bank API gateway
One connectivity contract in front of many banks and licensed open banking providers. The bank API gateway is a technical routing layer for developer teams and financial services teams that want to manage the open banking connection through one API, one data model and one set of webhooks.
API gateway, not a payment gateway. The gateway does not accept, process or settle payments. Payment initiation is conducted by a licensed PIS provider; funds move between the user's bank and the merchant's C2B account.
Definition
What a bank API gateway is
A bank API gateway is a software layer that sits between a merchant application and the licensed open banking providers behind every bank. It absorbs the differences across banks and providers into one open banking API contract, so a developer team works against one surface instead of one integration per bank.
viaBanking's bank API gateway is a technical connectivity product. It manages the request routing, the response normalisation and the status model across the open banking network. Regulated actions, such as payment initiation and account access, are conducted by licensed AIS and PIS providers; the gateway routes the requests and returns a normalised response.
What the gateway does
Six things a bank API gateway handles for you
Each item is a software behaviour on top of the licensed provider APIs. No regulated action lives in the gateway.
-
Provider routing
The gateway routes each open banking API call to the licensed provider that reaches the target bank in that market. Routing is a software decision, not a regulated action.
-
Response normalisation
Every bank and every licensed provider returns data in its own shape. The gateway normalises the responses into one data model so the developer reads one contract across the whole open banking network.
-
Status model
The gateway maintains a consistent status model across every open banking payment. Intermediate provider states, terminal states and merchant-visible statuses are mapped once, not per bank.
-
Signed webhooks
Each state change surfaces as a signed webhook event on one contract. The merchant application subscribes once and receives the same event shape from every licensed provider behind the gateway.
-
Structured logs
Every request, every callback and every retry attempt is logged with a stable request id. Financial services teams and developer teams get audit-ready logs on the same integration.
-
Retries and idempotency
The gateway manages retries against the licensed provider APIs and enforces idempotency keys on writes, so a network hiccup never doubles an open banking payment request.
Boundary
What the bank API gateway does not do
The gateway is a software layer. Every regulated open banking action stays with the licensed provider and the user's bank.
- Hold or move funds. Funds flow between the user's bank and the merchant's C2B account.
- Initiate payments on its own account. Payment initiation is conducted by a licensed PIS provider.
- Replace the licensed provider dashboard. The provider remains the regulated interface for its own operations.
- Hold an AIS or PIS licence. The gateway is a software product, not a licensed institution.
- Manage KYC or KYB. User onboarding stays with the merchant and the account provider.
Request flow
How a request flows through the gateway
The gateway does not close the loop on its own. A successful provider response is one intermediate signal; the final status is the credit into the merchant's C2B account.
- 01Merchant application posts one open banking API call to the gateway.
- 02Gateway routes the request to the licensed provider that reaches the target bank.
- 03Licensed PIS provider conducts the payment initiation with the user's bank.
- 04The user's bank hosts SCA and moves the funds to the recipient's C2B account.
- 05Provider callback arrives; the gateway normalises it and stores the transaction.
- 06C2B account credit verification is done via the account provider's API in read-only mode.
- 07Final status is surfaced to the merchant application through the same webhook contract.
Direct vs gateway
Direct provider integrations vs one gateway contract
Mechanical differences per dimension. Compliance and regulated activity are not on this axis; they stay with the licensed provider in both models.
| Dimension | Direct integrations | One gateway contract |
|---|---|---|
| Contract per bank | One integration per bank, per licensed provider | One gateway contract across every supported bank |
| Response shape | Each provider returns its own data model | One normalised data model per open banking API call |
| Status semantics | Maps status per bank inside the merchant application | One status model, mapped once inside the gateway |
| Webhook contract | Per-provider webhook payloads | One signed webhook event shape across providers |
| Retry and idempotency | Written per integration on the merchant side | Managed by the gateway per open banking API call |
| New market | New integration project per bank list | Configuration change on the gateway side |
Management surface
Gateway management for financial services platforms
For a financial services platform, gateway management is where scale is won or lost. The viaBanking bank API gateway ships a platform-level management surface that a developer team uses to manage every open banking API contract, every open banking service and every open banking product from one place. Financial services teams manage bank coverage, manage provider routing rules and manage the open banking API status model through the same platform, without a separate management tool per bank.
-
Integration management
The developer team can manage the open banking API endpoints, manage the version pin per open banking product and manage the sandbox-to-live promotion of each new open banking service on the same platform.
-
Provider management
Routing and failover rules across the licensed provider APIs are configured through the platform's management console, so a business does not manage a dozen provider dashboards on its own.
-
Event management
The platform normalises every open banking API webhook into one shape, so the merchant application manages one webhook stream per open banking product across all the underlying open banking APIs.
-
Data management
The gateway persists structured request and callback data on one contract, so finance and support teams manage reconciliation and investigations from the same open banking data set.
Together, these management solutions turn a set of separate open banking APIs into one platform-managed layer. Where a business ships multiple open banking products on the same platform, it reuses the same open banking API contract, the same data model and the same solution boundaries across every product. New solutions and new open banking services are added on the same management platform, not on a parallel one, so the operational footprint stays flat as the open banking product portfolio grows. The management platform is a software surface; regulated open banking services stay with the licensed AIS and PIS providers behind the gateway.
FAQ
Frequently asked questions
-
Is this a payment gateway?
No. This is a bank API gateway, a technical connectivity layer that routes open banking API calls to licensed providers. It is not a payment gateway; it does not accept, process or settle payments and does not hold merchant funds.
-
Who is licensed here?
The licensed parties are the third-party PIS providers that conduct payment initiation and the user's account-issuing bank that hosts SCA and moves the funds. The gateway itself is a software product operated by viaBanking, without an AIS or PIS licence.
-
Does the gateway replace my licensed provider?
No. The gateway sits above the licensed provider APIs. The provider remains regulated and remains the party that conducts payment initiation. The gateway gives the developer team one contract to reach many providers on the same code path.
-
What data does the gateway persist?
The gateway persists API request metadata, callback payloads and status transitions in structured logs. It does not read the user's bank statement or store banking credentials; SCA and credentials remain on the user's bank.
-
How does a new bank reach my application?
When viaBanking adds a licensed provider or a new bank behind an existing provider, the new coverage becomes available on the same open banking API contract. Reaching a new market is a configuration change on the gateway side, not a rewrite on the merchant side.
One connectivity contract. Every supported bank behind it.
Talk to sales about a European coverage plan, or head to the developers page for the endpoint-level view. For the wider platform picture, see the open banking platform page.
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.