viaBanking

Payment Initiation Services

Payment initiation services for any bank account

Use payment initiation services to initiate secure bank payments through one open banking API, with provider routing, banking-grade payments orchestration and a single set of webhooks, for any customer, any bank, any account.

Free sandbox · Pay out from any consented bank account.

  • 1One open API
  • Aggregated providers
  • 2.5k+Banks & EMIs
  • AIS+ PIS coverage
  • SCASecure consent
  • SDKDeveloper-ready

Definition

What is a payment initiation service?

In business terms, a payment initiation service lets a customer pay direct from their bank account, with no card, no wallet, no intermediate balance. The customer approves the payment in their bank's open banking app, and the money moves bank-to-bank to the merchant. Settlement is fast, fees are low, and chargebacks do not apply the way they do on cards.

Technically, it is the open banking PIS API layer. viaBanking exposes one open endpoint that handles consent capture, SCA, payment initiation, status handling and webhooks across any bank in the network. Your code calls one URL; viaBanking routes the payment to the right provider and the right bank. Read how this maps to industries on the solutions overview.

The problem

Pay-by-bank should be simple. Bank APIs make it hard.

Every bank ships its own open API. Most are technically compliant, operationally different, and any team trying to pay out across borders feels it on day one.

  • Integration fatigue

    Any open banking integration looks easy. Twenty in a row do not. Each bank ships its own quirks; your team owns the patchwork.

  • Provider fragmentation

    Use one PIS provider in Germany, another in France, a third for EMIs. Different open banking contracts. Different ops teams handle payments differently.

  • Compliance overhead

    Open PSD2 licences, audit obligations, SCA exemption handling. Any single market adds work, and the bill scales.

  • Maintenance cost

    Status fields drift on every bank release. Your code branches on payments quirks bank by bank. Any change costs engineering time.

One open API
Universal PIS aggregator

Providers, banks and EMIs behind a single normalised payment contract.

Auth flows

1

Payment model

1

EU banks

2,500+

Markets

30+

Uptime

99.99%

The viaBanking solution

One open API routes every bank payment

viaBanking is the universal open banking aggregator. We integrate providers, banks and EMIs, normalise the payment model, and expose one open API any team can pay out through. Routing partners keep the bank connections live; your customer keeps a familiar open banking flow on their own bank.

Out of the box, you get one auth flow, one payments contract, one set of webhooks. Your engineers ship features. Your customer pays direct from their bank. Your finance team reconciles every payment back to the right open banking ledger entry. The whole payments service stays auditable.

Core capabilities

Everything the payment API ships

  • PIS

    Payment initiation

    Start single, bulk and recurring payments from any consented bank account.

  • AIS

    Account data

    Use the same open API to pull balances and transactions for any linked customer bank account.

  • VFY

    Account verification

    Confirm account ownership and real settlement on your bank account before you pay out.

  • DATA

    Transaction retrieval

    Pull statement data within bank-permitted windows. One schema across any open banking bank.

  • FSM

    Status handling

    One unified payments state machine across every bank: Pending, Authorised, Settled, Failed. Clean for any open banking payment.

  • EVT

    Webhooks

    Signed callbacks on any consent, payments or account state change. Your application reacts in real time.

  • SBX

    Sandbox & testing

    A free, no-card sandbox simulates any open banking flow before you pay any real money out.

  • DOCS

    API documentation

    Code-first reference with payment examples in five languages. Read the API reference.

Use cases

Where teams put open banking payments to work

  1. 01

    Merchant payments

    Use pay-by-bank at checkout. The customer pays direct from their bank account. Open banking payments settle in seconds, skip card fees.

  2. 02

    Pay-outs & refunds

    Pay out wages, refunds or marketplace splits direct to any customer bank account, on one open payment API.

  3. 03

    Account funding

    Let any customer top up a wallet or trading account from their own bank in one open banking session.

  4. 04

    Reconciliation

    Match incoming payments data to invoices automatically across every linked bank account, with no manual export.

  5. 05

    Regional expansion

    Open new markets by switching banks on, not by rebuilding code. See coverage on the pricing page.

Integration flow

From API access to live payment monitoring

  1. 01

    Request API access

    Sign the developer terms, get sandbox keys the same day. No procurement gate.

  2. 02

    Consent & SCA

    Your application redirects the customer to their bank. The bank handles SCA. viaBanking stores the consent.

  3. 03

    Payment request

    Call /payments with amount, currency, payee. One contract for any bank in the open banking network.

  4. 04

    Response handling

    Use the unified status model. Listen for webhooks. Render the payment outcome back to the customer.

  5. 05

    Production monitoring

    Promote your code, point at live banks and watch any payment from one dashboard. Runbooks in the developer docs.

Security & compliance

Explicit consent. SCA on the bank. Data minimisation by default.

Any payment requires explicit, revocable consent. Strong Customer Authentication (SCA) runs on the bank side, so viaBanking never sees credentials. Customer data minimisation means only the fields in scope are stored, only for the period your application needs them.

The open banking platform operates within the PSD2 framework and tracks PSD3 guidance. Specific licence and authorisation details vary by market; review the current regulatory scope on our about page before going live.

  • Consent capture & revocation on any bank, audit-logged
  • SCA orchestration: customer credentials stay with their bank
  • Data minimisation per scope, per application
  • TLS in transit, encryption at rest across the open banking layer

FAQ

Common questions before you go live

How long does it take to ship a payment initiation flow?

Any team can pay out from sandbox in under a day. Production rollouts typically take two to four weeks across the banks any customer needs.

Which banks and account types are covered?

Over 2,500 EU bank connections plus major EMIs. Any open banking account that supports PIS will let the customer pay direct from their account.

Do you cover both account data and payment initiation?

Yes. Use the same open API for AIS (account data) and PIS (payment initiation). One contract, one set of webhooks, one auth flow.

Who handles consent and SCA?

The bank does. The customer authenticates with their own bank, approves the payment, and viaBanking surfaces a clean status back to your code.

When can my application start paying out from a bank account?

As soon as production keys are issued and the routing for the banks you need is enabled. There is no procurement gate.

Is the payment initiation service suitable for high-volume merchants?

Yes. Any merchant can pay out, settle in and reconcile with dedicated SLAs, audit logs and routing controls across every bank and account they use.

Free sandbox · No card needed

Ready to pay direct from any bank? Start building today.

Get sandbox access, browse the open banking API documentation and pay out your first open banking payments in a day. Find out about enterprise routing, dedicated SLAs or country rollout, all on one open service.