For developers · Open banking
Open banking for developers: build on one API
One integration, not one per bank. Your app calls a single open banking API, viaBanking resolves which licensed provider reaches the customer's bank, normalises what comes back, and confirms the credit on your own C2B account. A developer can get a sandbox on day one and writes against the same contract that runs in production.
viaBanking is the software layer. Payment initiation runs on a licensed PIS provider's authorisation, and no endpoint here reads a customer's bank statement.
Day one
Get to your first call
No card, no contract and no sales call standing between a developer and the sandbox.
- 01
Get access
Ask for a workspace and a developer gets sandbox keys the same day. Access is scoped per key, so the sandbox and production never share credentials.
- 02
Read two pages
The docs walk the payment flow end to end; the API reference lists every field, status and error code. Both are open to read before you sign anything.
- 03
Make the first call
Post a payment against a simulated bank and get a reference back. Your app now has something concrete to build the checkout around.
- 04
Wire the webhook
Register an endpoint, get the status callback data, and your app stops polling. The sandbox replays the same events production sends.
Scope
What you can build
The honest list, so a developer knows the scope before the first sprint. Four things are live on the API today.
-
Payment initiation orchestration
Your app posts one payment and the platform routes it to a licensed PIS provider that reaches the customer's bank. No per-bank branch anywhere in your app code.
-
C2B account credit verification
The platform confirms the credit landed on your own C2B account, so your app releases an order against money that arrived. That credit event is what your financial ops team reconciles against.
-
Transaction status and history
Read the status of one payment, or list the payment transactions your app initiated across a date range. That is your own financial record, in one shape.
-
Webhooks your app can trust
Signed callbacks on every state change, with a stable error taxonomy. Your app will get the same event shape whichever bank sat behind the payment.
What is not here: no endpoint reads a customer's bank statement, balance or spending history. On this API, transactions means the payment transactions your app initiated, and account means your own C2B account. Account information services are a separate licensed AIS product, and this API does not stand in for one. Early-stage teams sizing the scope usually start on open banking for startups.
Connectivity
One API, every bank
Every bank publishes its own interface. Bank APIs differ in auth sequence, field names and error semantics, and provider APIs add another layer of difference on top. All of that work sits inside the connectivity layer.
A developer builds against one open banking contract and one financial data model instead. When a licensed provider adds a bank, it appears on the integration you already shipped: no new mapping, no release, no new bank APIs to learn.
The bank connectivity side is covered on the open banking for banks page.
The boundary
Where the regulated part runs
Short enough for a developer to paste into a security review. Larger rollouts, with procurement and audit attached, are described on open banking for enterprise.
- Licensed PIS
Initiation
The payment is initiated by a licensed PIS provider on the customer's instruction. viaBanking routes the request and never initiates on its own account.
- The bank
Authentication and funds
Strong customer authentication happens inside the customer's own banking app, and the bank moves the money. No banking credential reaches your app or ours.
- viaBanking
Software only
We orchestrate, normalise and confirm. We do not hold funds, do not move them, and hold no AIS or PIS licence of our own.
FAQ
Before you open an editor
-
Do we need a licence to build on this?
No. The AIS and PIS authorisations belong to the licensed partner institutions. Your app contracts for software and for access to them, and your business keeps its own merchant obligations.
-
Can we read a customer's bank transactions?
Not on this API. The payment transactions you can list are the ones your own app initiated. Reading a customer's account history is an account information service, performed by a licensed AIS provider, and it is not what this API exposes.
-
How long until the first call?
Sandbox access the same day, and in practice the first call lands within an hour after you get keys. Production opens later, once the licensed provider finishes onboarding and your C2B account is live.
-
What does a bank outage look like in the API?
A status on that bank's route rather than a silent failure. Your app will get an error code it can branch on, the payment transactions stay readable, and the rest of the bank list is unaffected.
Get a workspace and make the first call
Tell us what financial product you are building and which markets matter first. We open the sandbox, hand over the docs, and start provider onboarding in parallel. A worked checkout example sits on pay-by-bank for eCommerce.
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.