Sandbox service
Free API keys, full verification API access, every bank API fixture. A self-serve developer service for prototyping verification API before you commit to a paid service.
Bank account verification API: C2B credit verification scope
viaBanking verifies incoming credits on the merchant-owned C2B account in read-only mode. Payer account ownership, balances, statements and transaction history are not part of this product.
Free sandbox · Run a verification API call in any market in under a day.
- 1One verification API
- ∞Aggregated providers
- 2,500+Banks & EMIs
- AIS+ PIS coverage
- SCASecure consent
- SDKDeveloper-ready API
What does account verification mean here?
Bank account verification can refer to ownership and name checks offered by other services. viaBanking’s current AIS scope is read-only confirmation of incoming funds on a merchant-owned C2B account. It does not establish payer account ownership.
The verification is carried out in a secure manner, in compliance with the financial, security and data privacy laws. See industry maps on the solutions overview.
Stitching a verification API per bank does not scale
Every bank publishes its own open banking API. Most are technically compliant, operationally different, and any team trying to run a verification API check across borders feels it on the first API integration. These are the technical challenges viaBanking is built to absorb.
-
Integration fatigue
Any API integration looks easy in isolation. Twenty bank API integrations do not. Each verification API has its own quirks; your team owns the patchwork.
-
Provider fragmentation
Use one verification API provider for Germany, another for France, a third for EMIs. Different API contracts. Different verification API rules per API.
-
Inconsistent bank APIs
One bank API returns the holder name flat; the next nests it. One verification API gives an account number, the next only an IBAN. Your code branches per API.
-
Compliance & maintenance
PSD2 licences, SCA exemptions, audit logs. Any verification API change costs engineering time. Maintenance scales with every bank, every API, every market.
Who owns and services the account?
The merchant/business owns the C2B account. Its selected EMI, bank or C2B Account Provider opens and services it. viaBanking connects to the account to verify incoming funds; it does not hold or move customer funds.
Credit verification and its limits
A payment initiation status is separate from confirmation of an incoming credit. Generic account aggregation, name matching, balance reads and statement retrieval are outside the current viaBanking scope.
Use the documented API contract
Consult the API reference for documented operations and fields. Obtain the applicable C2B credit-verification contract before implementing matching. Do not assume an account ownership or balance endpoint exists.
Pick the right verification API service
Every tier is the same verification API. The service level, support service and SLA scale with the number of verifications you run.
Production service
Pay-as-you-go verification API service. The number of API calls scales with traffic; the service-level target stays the same on every bank API.
Enterprise service
A managed verification API service with dedicated SLAs, a named support service team, custom routing controls and a high call number ceiling per second on every bank API.
Receiving payments and reconciliation
Use incoming-credit confirmation in your merchant fulfilment and reconciliation workflow. Confirm how partial, delayed and unmatched credits are handled before releasing goods or marking invoices paid. No universal matching algorithm or settlement-finality guarantee is established here.
From sandbox to production
A first sandbox call can be made in under one day when prerequisites are met. Typical integration is 1–2 weeks end-to-end and 2–4 weeks to production, subject to provider and account arrangements. Confirm the production prerequisites and supported credit evidence before launch.
Explicit consent. SCA on the bank. Data minimisation by default.
Any verification API call requires explicit, revocable consent from the account holder. Strong Customer Authentication (SCA) runs on the bank side, so the verification API never sees credentials. Data minimisation means the API only stores the account fields in scope, only for the period your application needs them.
The bank account verification API operates within the PSD2 framework and tracks emerging PSD3 guidance. Specific licence and authorisation details vary by market; review the current regulatory scope on our about page before going live with the verification API.
- Explicit verification API consent capture & revocation per account, audit-logged
- SCA orchestration: account holder credentials stay on the bank, never on the API
- Data minimisation per verification API scope, per application, per account
- TLS in transit, encryption at rest across every verification API call
- Secure API access via signed bank account verification API keys
Common questions before you ship the verification API
How fast can I integrate the bank account verification API?
A first sandbox call can take under one day when prerequisites are met. Typical integration is 1–2 weeks end-to-end and 2–4 weeks to production; timing depends on the provider, bank and integration requirements.
Which banks and account types does the verification API cover?
2,500+ — banks & EMIs Service availability depends on the selected provider and bank.
Does initiating a payment establish that the C2B account was credited?
Treat payment initiation and confirmation of a receiving-account credit as separate checks. Before designing fulfilment rules, confirm which credit evidence your integration exposes, how it is matched to a payment, and how pending or unmatched credits should be handled.
Who handles consent and SCA when the verification API runs?
The bank does. The account holder authenticates with their bank, approves the verification API scope, and the bank releases the account data the API needs. viaBanking never sees credentials; the verification API only sees the consented scope.
When can my application start running verification API calls in production?
Confirm the permitted account-data scope, receiving account, provider access and supported banks before requesting production access. Start with the production checklist; completing sandbox tests alone does not confirm live availability.
Is the bank account verification API suitable for high-volume risk checks?
Current scope is read-only C2B credit verification. It does not include payer ownership, name matching or balance checks. Confirm processing limits and supported workflows with the integration owner.
Ready to verify any bank account? Ship the verification API today.
Get sandbox API access, browse the bank account verification API documentation and run your first verification API call in a day. Use one verification API for every bank, every account API check, every name match, every account number validation, across every market.
Updated: