Menu
Talk with sales

Integration questions? [email protected]

Debit card payment processing on one direct acquiring contract.

BazPay processes debit-card payments on the same direct regional acquiring contract as credit — one merchant identifier, one API, one signed webhook stream. The domestic debit schemes plus Visa and Mastercard debit variants share the surface, least-cost routing picks the cheaper leg on co-badged cards, and interchange++ reporting breaks debit lines out separately so finance sees the real fee mix.

Built for merchants across the EU, UK, Australia, Canada and New Zealand: e-commerce sellers, subscription software firms, professional-services businesses and digital publishers whose customers pay heavily on debit as well as credit.

Talk with sales Read the API reference

Why merchants run debit alongside credit on one contract

Splitting debit and credit across two vendors doubles reconciliation and hides the fee mix. Four properties keep BazPay's debit-card processing on the same rail as credit while surfacing what actually differs.

  • Debit and credit on one MID

    Debit-card charges post to the same named merchant identifier as credit-card charges. One acquiring contract covers both, and interchange++ reporting breaks out the debit and credit lines separately so finance sees the real fee mix.

  • Native regional debit scheme coverage

    Domestic debit schemes plus Visa and Mastercard debit variants clear on BazPay's own regional acquiring licence. Debit cards issued outside the region that carry a supported scheme mark authorise on the same contract — the acquiring is local, the schemes are global.

  • 3-D Secure that doesn't punish debit

    3-D Secure 2.2 with PSD2 exemption logic runs on debit charges the same way it runs on credit — low-value, risk analysis and merchant-initiated exemptions keep most debit checkouts frictionless. Debit shoppers see friction only when the risk earns it.

  • Recurring on debit where the scheme allows

    Merchant-initiated debit renewals run under MIT rules with stored credentials and network-token refresh. Where a scheme restricts recurring on a specific debit product, the platform surfaces the constraint at boarding rather than after the first failed rebill.

The debit brands the platform accepts

Four brand families cover regional debit acceptance under one merchant contract. Every one uses the same charge object as credit; the reporting keys the transaction by product type so debit and credit reconcile separately.

  • Domestic debit

    Domestic debit acceptance

    Most debit volume in these markets rides a domestic scheme co-badged onto an international one: Cartes Bancaires in France, eftpos in Australia, Interac Debit in Canada, Dankort in Denmark. BazPay processes all of them alongside consumer credit cards under one merchant identifier, and routes the co-badged leg to whichever network costs less on that transaction.

    • Regional coverage
    • Same charge object
    • Same webhook

  • Visa debit

    Visa debit variants

    Visa Debit and Visa Electron cards route through the Visa scheme rails on our acquiring licence. Interchange behaves per Visa regulations, distinct from consumer credit but reported line-by-line on the interchange++ statement.

    • Visa Debit
    • Visa Electron

  • Mastercard debit

    Mastercard debit variants

    Consumer and prepaid debit variants on the Mastercard scheme process alongside credit charges. Reporting keys each transaction by product type so debit and credit revenue reconcile separately in your ledger.

    • Debit Mastercard
    • Prepaid

  • Wallets on debit

    Apple Pay and Google Pay on debit cards

    Device wallets ride the same debit-card rail with a wallet-supplied network token. A shopper paying via Apple Pay from a linked debit card authorises through the same acquiring contract and the same signed webhook fires.

    • Apple Pay
    • Google Pay

Broader payment-method landing on card and APM processing. Boarding side on merchant acquiring.

How a debit-card charge moves through the platform

Six stages describe a debit charge from checkout to settled EUR. The BIN lookup at stage 02 is where debit and credit start behaving differently downstream.

  1. Collect

    The shopper enters card details on hosted fields, a hosted checkout page or a plugin. Debit and credit share the same input surface.

  2. Identify

    BIN lookup identifies the card as debit and returns issuing country, product code and network-token eligibility to the risk engine.

  3. Authenticate

    3-D Secure 2.2 runs when the rule earns it. Debit charges follow the same PSD2 exemption logic as credit, not a stricter one.

  4. Authorise

    The processor posts to the acquirer; the issuer confirms the balance is available and returns an authorisation code.

  5. Capture

    Debit funds are typically deducted from the shopper's account on authorisation. Partial and full captures behave the same as on credit.

  6. Settle

    Funds reconcile per scheme cycle into your local settlement account, with debit interchange broken out separately from credit on the statement.

Debit vs credit — what actually differs

At checkout the two look almost identical. On the back end the differences show up in interchange, recurring rules and issuer behaviour on borderline authorisations.

Debit card processing compared with credit card processing
Dimension Debit Credit
Balance check Issuer confirms available funds at authorisation Issuer confirms available credit at authorisation
Regional interchange Regulated cap on regional consumer debit Regulated cap on regional consumer credit
3-D Secure 2 Same rules under PSD2, exemptions apply Same rules under PSD2, exemptions apply
Recurring on card-on-file Supported under MIT rules; scheme rules vary per debit product Broadly supported; card-on-file well established
Chargeback exposure Cardholder dispute rights apply Cardholder dispute rights apply
Typical shopper choice Everyday spending, lower ticket Larger tickets, cross-border, rewards

Recurring depth on recurring billing. Fraud posture on payment fraud prevention.

Features engineered for debit acceptance

Every capability below is on the standard integration. Turning on debit acceptance uses features you already have — no premium tier gates hosted fields, network tokens or the webhook contract for debit charges.

  • Debit-aware BIN routing

    The routing engine reads the BIN metadata and treats debit and credit distinctly for retry logic and exemption decisions.

  • Hosted fields

    Card, expiry and CVC inputs served from our PCI environment inside your checkout — debit numbers never touch your servers.

  • Network tokens

    Visa and Mastercard network tokens replace the PAN at storage time and refresh automatically after a debit reissue.

  • 3-D Secure 2.2 + exemptions

    Authentication runs on every debit charge with automatic exemption logic — risk analysis, low-value, MIT and trusted-beneficiary where allowed.

  • Signed webhooks

    HMAC-signed, replay-protected events cover approve, decline, refund, dispute and settlement — one handler for debit and credit.

  • Refunds to original card

    Full and partial refunds return to the original debit card via the scheme refund flow, matching the interchange++ reporting line.

  • Dispute defence

    Chargebacks from a debit issuer surface as signed events with the reason code and evidence-due deadline; 3DS + charge metadata are pre-attached.

  • Interchange++ per line

    Debit and credit interchange break out separately per settled transaction, so finance sees the actual fee mix rather than a blended average.

One REST call accepts a debit charge

The same charge endpoint that accepts credit accepts debit. The BIN lookup returns the funding field so your reporting keys the row correctly; nothing about the request shape differs by card type. 

POST /v1/charges
Idempotency-Key: 8f1c-2b3a-9e4d
{
  "amount": 4990,
  "currency": "EUR",
  "payment_method": "card",
  "capture": "auto",
  "three_d_secure": "required_if_needed",
  "metadata": { "order_id": "ORD-10842" }
}

The response returns a canonical charge object with funding: "debit", the network the issuer sits on and any exemption applied. Full schema in the API reference.

Where debit acceptance earns its place

Four merchant profiles run heavy debit volume alongside credit on BazPay. Each uses the same integration and gets debit lines broken out on the interchange++ statement.

  • E-commerce sellers

    DTC brands whose regional customers pay heavily on debit. Debit and credit charges land on one MID with clean per-product reporting for finance.

  • Subscription software

    SaaS teams renewing debit-card-on-file plans with MIT exemptions and dunning-aware retries, tuned to debit-scheme rules where they differ from credit.

  • Digital publishers

    Membership and paywall businesses processing small-ticket debit charges at high volume, with interchange++ breakouts for reconciliation.

  • Professional services

    B2B service firms invoicing debit-preferred markets, with enforced 3-D Secure 2 over a ticket threshold you set.

Out of scope for BazPay: adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection and MLM. BazPay is not a merchant of record and not a marketplace of third-party PSPs.

Security and compliance signals for debit processing

Card handling — debit or credit — runs inside a PCI DSS Level 1 environment assessed each year. Hosted fields and gateway-side vaulting keep your annual return at merchant SAQ A. Authentication runs on every debit charge with 3-D Secure 2.2 and automatic exemption logic. In-region data residency is default.

PCI DSS Level 1
Annual assessment on the acquiring and gateway environment
Merchant SAQ A
Hosted fields and gateway vault keep card data out of your stack
Authentication
3-D Secure 2.2 with automatic exemption logic on every debit charge
GDPR
In-region data residency; DPA on request
Scheme registrations
Visa VIRP and Mastercard SPoC/PCI-CP where required

Questions merchants ask about accepting debit cards

Does BazPay handle debit card payment processing separately from credit?

No — debit and credit run through the same charge object on the same merchant identifier. What is separate is the reporting: debit interchange and credit interchange break out as different lines on your interchange++ statement, so finance can reconcile per product type.

Which debit brands are supported in the debit card payment gateway?

Domestic debit schemes (the local debit brand under Mastercard), plus Visa debit variants (Visa Debit, Visa Electron) and Mastercard debit variants (Debit Mastercard, prepaid). Apple Pay and Google Pay backed by a linked debit card ride the same scheme rails.

Can I run a debit card recurring payment (rebill) on BazPay?

Yes, under Merchant-Initiated Transaction rules. The initial charge is authenticated with the cardholder (typically under 3-D Secure 2); subsequent rebills run as MITs against the stored credential with network-token refresh. Scheme rules vary by debit product, so a boarding review confirms which recurring patterns are supported for your specific merchant profile.

How does online payment debit card processing differ from credit at checkout?

From the shopper's perspective, very little — the card entry flow, 3-D Secure 2 challenge and success confirmation look the same. From the merchant's perspective the differences are on the back end: interchange behaves per regional debit regulation, chargeback reason codes overlap but not exactly, and recurring rules on some debit products are stricter than on consumer credit.

Where does the credit debit card payment system offered by BazPay actually sit?

BazPay is a direct regional acquirer and payment gateway for card acceptance — both credit and debit. It is not a card issuer, not a merchant of record and not a marketplace of third-party PSPs. Merchants contract directly with BazPay for acceptance on their own named MID.

What debit card payment network information does the platform surface?

The BIN lookup returns issuing country, product code (consumer/business/prepaid), debit-vs-credit classification and network-token eligibility. These fields appear on the charge object and travel through the signed webhook stream, so your risk engine and reporting can key on them.

Are debit card payment solutions available to smaller merchants, or gated behind volume tiers?

Debit acceptance is available on the standard integration to every merchant BazPay boards, regardless of monthly volume. Underwriting scope is unchanged — EU, UK and Commonwealth e-commerce, subscription software, professional services and digital publishers.

Which industries are out of scope for debit acceptance on BazPay?

BazPay does not board adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection or MLM merchants for card acceptance — debit or credit. BazPay is not a merchant of record and does not act as a marketplace of third-party PSPs.

Accept debit and credit on one direct regional acquiring contract

Share your business model, monthly volume and debit-vs-credit mix. A named engineer will confirm boarding fit and map the reporting split inside one working day. See also payment acceptance, pricing and the wider card and APM processing landing.

Talk with sales Read the developer docs