The shopper pays from their own bank app.
Open banking moves money straight between two accounts. No card, no token, no interchange. The shopper approves in the app they already trust. Funds settle on SEPA Instant rails, usually within seconds.
It runs on the same BazPay key as your card traffic. One API contract, one dashboard, one webhook stream.
How a payment moves
Four steps, start to finish. Your server only has to handle the last one.
-
Shopper picks pay by bank
At checkout they choose their own bank. We show only the methods live in their country.
-
They approve in the bank app
The bank handles login and strong authentication. You never see a credential.
-
Funds move on SEPA Instant
Money leaves their account and lands in yours. Most transfers clear in seconds.
-
A webhook confirms it
We post the final status to your endpoint. Release the order on that event, not on the redirect.
Local methods, one contract
Each EU market has its own habit. Dutch shoppers reach for iDEAL. Polish shoppers reach for BLIK. We keep them all behind one set of endpoints.
Turn a method on per country. The checkout then shows only what that shopper can actually use. See the full platform list on our integrations page.
| Method | Market | Flow | Note |
|---|---|---|---|
| iDEAL | Netherlands | Bank redirect | Dominant local method |
| BLIK | Poland | Code or app push | Mobile-first |
| Bancontact | Belgium | Bank redirect | App or card mode |
| EPS | Austria | Bank redirect | Bank-issued flow |
| Przelewy24 | Poland | Bank redirect | Broad bank list |
| SEPA credit transfer | Euro area | Account to account | Also used for payouts |
Bank rails next to card rails
Neither one wins outright. They fail in different places, so most sellers run both. Here is the honest split.
| Open banking | Card acquiring | |
|---|---|---|
| What the shopper uses | Their banking app | A card number |
| Card data in your scope | None | None — hosted fields keep you at SAQ A |
| Interchange | Not applicable | Scheme interchange applies |
| Chargeback rights | No scheme chargeback | Scheme chargeback rules apply |
| Typical settlement | SEPA Instant, seconds | Scheme settlement cycle |
| Recurring support | Mandate based | Stored credential based |
Running both? Compare the full scheme setup on card and APM processing.
Where sellers switch it on first
Three patterns come up again and again across our low-risk book.
-
E-commerce
High-value baskets
Big orders attract card risk checks. Pay by bank skips the scheme rails, so the decline reasons that hurt large baskets never fire.
-
SaaS
Annual plan renewals
Charge the yearly plan by bank and the card renewal problem goes away. No expiry, no reissue, no dunning cycle for that invoice.
-
Services
Invoices and deposits
Send a pay-by-bank link with the invoice. The client approves in their bank app. You see the funds land the same day.
Billing on a schedule too? See how mandates work under recurring billing.
Questions we get asked
Short answers from the team that runs the rail.
Do I still need card acquiring?
Most sellers run both. Pay by bank suits home markets and large baskets. Cards still cover cross-border and wallet shoppers.
Can I refund an open banking payment?
Yes. We send the money back over SEPA to the account that paid. It is a transfer, not a scheme reversal.
Is my PCI scope affected?
No card data touches the flow at all. Your gateway scope stays at SAQ A, the smallest return a seller can file.
How fast can I turn it on?
It runs on the same key and the same API as your card traffic. Sandbox first, then one call to go live.
Test a pay-by-bank flow today
Sandbox keys are self-service. Fire a test iDEAL payment, catch the webhook, and see the settled event in your dashboard. No demo call required.