Frequently asked questions

viaBanking is a software-only open banking aggregator with fund settlement verification. We provide a single integration with multiple open banking providers and confirm the actual settlement of funds into your own C2B account, not just that the payment was initiated.

viaBanking is for payment companies, fintechs, e-commerce and trading platforms. It fits any business that accepts bank payments through open banking and needs to know that funds have actually arrived, not just that the payment was initiated.

viaBanking is a software-only Technical Service Provider. You do not need a banking, EMI or payment licence to use viaBanking itself. Payment initiation is performed through licensed open banking providers (AISs and PISs), and your C2B account is opened directly with a C2B Account Provider. Any licensing related to your own business activity remains your responsibility, and our team will confirm what applies during onboarding.

Reach out through the contact form and we open a workspace with sandbox keys. You can build against realistic fixtures without a card and without production data.

Most teams reach a successful sandbox call the same day and complete a first end-to-end flow within one to two weeks, depending on scope.

Coverage focuses on the European Economic Area and the United Kingdom. The exact list of institutions per country is available to workspace users in the dashboard and evolves as we add connections.

Coverage includes 2,500+ banks and EMIs in Europe. Because the list changes, we do not publish a static roster; the current, per-country list is available inside the dashboard.

Account Information Services (AIS) let you read balances and transactions with the end user's consent. Payment Initiation Services (PIS) let you initiate an account-to-account payment on behalf of the end user. viaBanking gives you access to both because it cooperates with licensed third-party AIS and PIS providers.

Support depends on what each bank provides under PSD2. Where a bank supports scheduled or recurring payment initiation, viaBanking passes those capabilities through in the standard data model.

In the current phase, AIS is not used for the merchant to read an end user's account statement. It is used for C2B account credit verification: through the licensed AIS provider, viaBanking checks in read-only mode that a specific payment has actually been credited to your C2B account. Reading arbitrary details of the end user's own bank account is out of scope for now.

No. viaBanking is focused on open banking (AIS and PIS). Card acquiring, card issuing and card networks are not part of the product.

The user's payment consent flow is orchestrated by our licensed PIS provider partner, not by viaBanking. The end user authenticates directly with their account-issuing bank through that bank's own strong customer authentication flow. viaBanking never sees or stores banking credentials. The bank returns a consent that the end user can review and revoke at any time.

Under PSD2, the maximum lifespan of an AIS consent is 180 days, and it can be renewed by the end user. That 180-day ceiling is most relevant to long-lived or recurring AIS use cases (for example ongoing C2B account credit verification against a merchant account). PIS consent is different: it is granted per-payment and authorises exactly one payment initiation, so in practice there is no 180-day window for one-off payments; each new payment requires a fresh user's payment consent.

Data is hosted in the European Union with reputable cloud infrastructure providers. Encryption in transit and at rest is applied by default.

Yes. We process personal data as a processor on behalf of our customers, in line with the GDPR and applicable national laws. Full details of how we collect, use, store and protect personal data are set out in our Privacy Policy.

No. Strong customer authentication happens on the user's account-issuing bank's own domain: the end user logs in with the bank's own credentials and completes SCA (second factor) directly with that bank. viaBanking never sees the login, the password or any other credential, only the access token the bank returns after the user authorises the connection.

We run regular internal reviews and engage third-party specialists for penetration testing. Details on our security posture are shared with customers under NDA during procurement.

The API is REST + JSON, so any HTTP client works. Reference examples for common languages are provided in the documentation.

You register a URL and receive signed events for consent and payment lifecycle changes. Verify the signature, respond quickly, and use the event as a trigger to read the definitive state from the API.

Send an Idempotency-Key header on every payment initiation so a network retry never creates a duplicate. Respect the Retry-After header on 429 responses instead of a fixed sleep.

The service targets 99.99% API availability, measured over rolling 90-day windows. Downstream bank availability varies and is exposed through our status endpoints so you can route around degraded connections.

The sandbox simulates consent expiry, payment rejection, connection timeouts and rate-limit responses so you can exercise error paths without touching production data.

Swap sandbox keys for live keys in your deployment, register production webhook URLs and enable idempotency on all writes. The go-live checklist in the docs walks through each item.

Pricing is usage-based, with plans that scale by request volume and product mix (AIS, PIS, or both). The pricing page has current tiers, and larger volumes are quoted individually.

Yes. Sandbox access is free while you evaluate and build. No card is required to start.

Production traffic is billed under the selected plan from the first live call. Trial arrangements for enterprise procurement can be discussed with our team.

Usage is metered and invoiced monthly. Enterprise customers can arrange annual commitments through a signed order form.

The contact page lists the channels available for your workspace. Enterprise plans include a named contact and defined response-time targets.

Send incident reports or responsible-disclosure findings to the security contact listed on the contact page. We acknowledge reports quickly and coordinate on remediation.