Payment methods, one API — cards, wallets, bank rails and SEPA Instant

How to read this

A payment method is only useful when three things line up: the shopper recognises it at checkout, the merchant's contract and dashboard have it switched on, and the rail behind it accepts the currency being charged. This page groups every payment method BazPay supports by the rail the money actually travels on, not by how the button looks at checkout. That grouping is the one that predicts behaviour: everything on a card rail shares chargeback exposure and settlement timing, and everything on a bank rail does not. If you would rather read the same catalogue market by market, the payment methods by country matrix lists every method we settle inside each country tab.

Every method below is enabled with a toggle in the dashboard and reaches you through the same request shape and the same signed webhook. Adding a new payment method online is a configuration change, not an integration project — which is the whole reason to run them from a single gateway rather than collect providers per market. The rest of the page covers the library in detail, then the operational parts merchants actually ask about: declines, 3-D Secure, refunds and SEPA Instant for recurring billing.

Cards

Scheme rails. Highest reach, chargeback exposure, and the only family with a full dispute process.

Wallets

Card rails behind a device token. Authentication is delegated to the handset, so authorisation rates run high.

Bank rails

The shopper authorises inside their own banking app. No chargebacks, so no dispute exposure either.

Buy now, pay later

The provider pays you in full and carries the credit risk. Highest basket lift, highest headline fee, and the dispute runs under consumer-credit rules rather than scheme ones.

Direct debit

You pull the money on a mandate. Cheapest per transaction, slowest to clear, reversible for eight weeks.

What to enable, by market

Enable by where the shopper is, not by where you are. The lead method is the one that should appear first at checkout; the rest are there so nobody is stuck on an unfamiliar option. The most expensive mistake in this table is offering a full alphabetical list to every visitor — the second most expensive is offering only cards in a market that expects a bank rail.

When a payment method is declined

"Your payment method was declined" is the single most-searched phrase in this topic, and it is also the checkout copy most likely to lose an otherwise willing buyer. A decline is not one thing — it is at least six things wearing the same label, and the response the shopper sees should depend on which one just happened. Every BazPay decline carries a stable code, a human-readable reason and, where the network exposes it, the raw issuer reason.

The one anti-pattern to avoid is silent retry on the same card. Networks record every attempt and repeated identical retries push the issuer's risk score up rather than down. If a card is declined twice, the productive move is to show the shopper a different way payment can be completed — a wallet button, SEPA Instant or BLIK in the local markets, or a manual retry of a different card. The API returns a retryable hint on every declined attempt so the checkout can make that decision without hard-coding a code list.

For subscription renewals, the decline handling is different again: an issuer decline on a merchant-initiated charge should trigger dunning against the stored credential rather than a checkout redirect. The payments guide covers the parameters, and account updater plus retry cadence usually recovers a large share of soft declines without shopper contact.

3-D Secure 2 and SCA exemptions

Strong customer authentication is an PSD2 obligation, not a BazPay policy. What differs between gateways is how much of it a shopper actually experiences, because the regulation allows exemptions and applying them is a technical decision. BazPay runs 3-D Secure 2.2 on every eligible card payment, submits the browser and device data required for a frictionless outcome, and requests every exemption the transaction qualifies for.

• Card payments run 3-D Secure 2.2 with the issuer. Device data and risk signals are submitted so the issuer can approve without a challenge where the profile allows.
• Wallet payments (Apple Pay, Google Pay) are pre-authenticated on the device, so the shopper meets no extra step and liability usually shifts to the issuer.
• Bank rails authenticate inside the shopper's own banking app, which satisfies the 3-D Secure requirement by construction.
• Merchant-initiated renewals sit outside the scope of 3-D Secure entirely — the shopper is not present and the stored credential carries the original authentication.
• Low-value, trusted-beneficiary and transaction-risk-analysis exemptions are requested automatically where your traffic qualifies.

An exemption is a request, not an instruction: the issuer can still challenge, and some routinely do. Where a challenge fails, the response carries an authentication_failed code so your checkout can distinguish an authentication problem from an ordinary decline — the two need different shopper copy. The detail of which exemptions apply and what happens when one is refused is on fraud and 3-D Secure, and the API-level parameters are in the payments guide.

Refunds and how money comes back

Refunds behave the same everywhere at the API level: full or partial, up to the captured total, initiated by you, idempotent on the reference you supply. Where they differ is operationally — which rail the money travels back on, how long the shopper waits, and whether the shopper can force a reversal without you.

A refund to original payment method is the default and, on every method BazPay supports, the only option. Card and wallet refunds return to the same card or token that was charged; BACS Direct Debit refunds return to the debited settlement account; bank-rail refunds return to the account that initiated the payment. That constraint is a network and regulator rule, not a BazPay preference, and it is the reason a shopper who wants their refund somewhere else has to close the original method and take the credit through their bank.

This is the practical case for leading with a bank method in the markets that have one: the transaction costs less, settles a day sooner and cannot be reversed against you. Cards remain necessary for reach and for anything sold cross-border — they simply should not be the only thing a German or British shopper is offered.

SEPA and SEPA Instant for recurring

SEPA payment methods matter twice over: BACS Direct Debit is the cheapest way to renew a recurring subscription in Germany, and SEPA Instant is the fastest way to move a one-off payment through the same rail. Both settle into the same balance as cards and both appear on the same reconciliation file, tagged with the method so finance teams can separate them without a parallel report.

• BACS Direct Debit runs against a mandate. The mandate can be collected inside the BazPay checkout, seeded from a first SEPA Instant or BLIK payment, or imported from an existing system. The mandate reference and the signed timestamp travel with every subsequent collection.
• SEPA Instant carries a one-off push payment in seconds. It is useful for high-value baskets where the merchant wants irrevocable settlement without a card fee, and for pay-in flows where the shopper triggers the payment from their own bank app.
• Refunds on either variant return to the debited settlement account and appear on the shopper's statement with your descriptor.
• Payouts to shopper bank accounts, where the merchant needs to send money out (refunds, splits, payouts for approved corridors), run through SEPA Instant on the same balance.

Per-method pricing, including the interchange++ breakdown for cards and the flat fee model for bank rails, is on the pricing page. For how these methods reach a specific storefront, go back to the integrations hub — the cart plugins wire the whole library in with no per-method code.

Common questions

What does 'your payment method was declined' actually mean?

It means the transaction stopped somewhere between the checkout and the issuing bank. The decline can come from the network, the issuer, our fraud engine, or 3-D Secure. Every decline BazPay returns carries a machine-readable code and a plain-English reason, so the checkout can tell the shopper whether to retry, try a different card, or switch to another payment method online — rather than showing a generic error.

Why does the same card work one day and fail the next with 'this payment method has been declined'?

The most common cause is issuer risk scoring: the same card can pass at one merchant, one time of day or one basket size and fail at another. Reissued cards, expired stored credentials and address mismatches are the next tier. The real-time decline data BazPay returns includes the raw issuer reason where the network exposes it, which is the only reliable way to distinguish these.

How do I handle 'transaction declined — invalid payment method' at the API level?

Check three things in order: the method is enabled for the payer's billing country in the dashboard, the currency you are charging is supported for that method, and your MCC is not on the method's exclusion list. If all three pass and the code still returns, the issuer is refusing the specific card — treat it as a decline and offer the shopper a fallback method rather than retrying the same one.

Does enabling a new e payment method mean a new contract?

No. Every method on this page is covered by your existing agreement and switched on with a toggle in the dashboard. There is no separate onboarding, no second set of keys and no per-method integration work — the request shape and the webhook do not change. If a method is not listed here, it is not currently in the BazPay library, and adding it would be a product decision rather than a contract one.

Do you support Paysafecard payment or other prepaid vouchers?

Not today. BazPay's method library is domestic cards, wallets, bank rails (iDEAL, BLIK, Bancontact, Przelewy24, EPS, pay by bank) and BACS Direct Debit. Voucher and cash-in networks such as Paysafecard sit outside the EU, UK and Commonwealth e-commerce scope BazPay is built for, so we do not act as a paysafecard payment method provider. Merchants who need voucher acceptance typically pair BazPay with a specialist provider on the same checkout.

What about Klarna and OXXO-style cash vouchers outside Germany?

Klarna wallet acceptance and cash-voucher networks outside Germany are not currently in the BazPay library. Shoppers in those markets can pay by card (including locally co-badged issuers where present), Apple Pay, Google Pay and pay by bank via open banking where their bank is supported. If one of those methods is critical to your business, tell us before onboarding — we prioritise roadmap methods against real merchant demand, not speculative coverage.

Do bank methods have chargebacks?

Not in the card sense. A confirmed SEPA Instant, Bancontact, EPS or Przelewy24 payment is irrevocable, so there is no dispute process to lose. A shopper who wants their money back has to ask you directly, which makes those methods cheaper to run and materially lower risk than card payments.

Which methods can carry a subscription?

Cards and wallets through a stored credential in the gateway-side vault, BACS Direct Debit through a mandate, and pay by bank where the bank supports variable recurring payments. BLIK and SEPA Instant can seed a debit-order mandate on the first payment, which is the usual way payment on a German or Australian subscription starts.

How does 3DS payment processing work in the BazPay flow?

Every eligible card payment runs 3-D Secure 2.2 with the issuer. The device data is collected from the browser, the risk score is submitted, and the issuer decides between frictionless approval and a challenge. Exemptions (low-value, transaction risk analysis, merchant-initiated) are requested automatically where the traffic qualifies. The exemption is a request, not an instruction — the issuer can still challenge.

Can a refund go to the original payment method automatically?

Yes. A refund on any card, wallet or bank-rail payment routes to the original payment method by default — that is how the networks and the bank rails are designed. For BACS Direct Debit, refunds return to the debited settlement account. The API accepts a partial or full amount up to the captured total, is idempotent on the reference you supply, and settles through the same daily payout file as new charges.

Do I settle each method separately?

No. Every method settles into the same balance and the same daily file, whatever rail it arrived on. The file names the method per transaction so reconciliation can still break it down, but you receive one payout in EUR (or the balance currency), not one per method.

Can I show different methods to different shoppers?

Yes, and you should. Methods can be filtered by billing country, currency, cart value and customer group. Showing a British shopper eight irrelevant bank logos is worse than showing them Bancontact and a card field, and the same principle applies to every market.