BazPay Puts iDEAL, BLIK, PayTo and Interac Behind a Single API Call

A shopper reaches for what their country reaches for. A Dutch customer expects iDEAL, a Pole expects BLIK, an Australian expects PayTo, a Canadian expects Interac. Present a card form instead and a measurable share of the basket walks away — the shopper was asked to pay in a way they do not normally pay.

The usual fix is expensive: each local method arrives with its own SDK, contract, settlement cycle and reconciliation quirk, so four methods mean four integrations. BazPay removes that arithmetic by treating a local method as a property of the charge object rather than a separate product: on BazPay every method is a dashboard toggle behind the same API call as a card charge, on one contract and one settlement file.

The method each market already reaches for

Thirty-seven methods run on one BazPay integration:

• Benelux — iDEAL in the Netherlands, Bancontact in Belgium.

• Poland — BLIK, with Przelewy24 in the sandbox simulators.

• Nordics and UK — Swish, Vipps, and pay by bank settled over Faster Payments.

• Australia and Canada — PayTo and least-cost-routed eftpos; Interac Debit and e-Transfer.

• New Zealand, wallets and BNPL — account-to-account collection, device-tokenised Apple Pay, Klarna.

The BazPay sequence is short: a payment order is created through payment initiation, the shopper approves it in their banking app, SEPA Instant or the local equivalent releases the credit in seconds, and a settlement webhook lands on the endpoint the merchant already listens to for card traffic. There is no second event stream and no second dashboard, because the open banking rails and the card rails are the same API, sandbox keys and reporting layer.

What changes when a bank credit replaces a card

BazPay is direct about the consequence vendors leave in the footnotes: a bank credit carries no card-scheme chargeback right, so disputes run under the payer bank’s rules instead of a reason-coded scheme case. For high-value, low-fraud merchants that trade is usually favourable — the payment is pushed by the customer and authenticated by their bank; for others it is a reason to keep cards primary and local methods as the conversion lever. Two further points decide the build:

1. No per-method contract. Enabling iDEAL or PayTo in BazPay triggers no new underwriting cycle and no second settlement account.

2. National scope is real, and BazPay says so. iDEAL, Bancontact, BLIK and EPS clear only in their home markets: a method toggled on for the wrong market will not convert.

Cards remain the BazPay fallback everywhere and run on the same call: hosted fields keep the PAN inside its PCI DSS scope, 3-D Secure 2.2 is requested with the full data set so exemptions carry most European traffic frictionlessly, and every decline returns the verbatim issuer reason. For a product team the test is how fast a method the market already wants can be switched on — on BazPay, a toggle and an existing webhook. The rest of the BazPay range, including payouts, recurring billing and analytics, is documented here.