A direct credit card processor built for EU, UK and Commonwealth merchants.


BazPay is a credit card processor and regional acquirer in one direct contract. Cards authorise on our own acquiring licence, settle into your local settlement account and report on interchange++ line detail — with no third-party reseller between you and the card schemes.

Built for merchants across the EU, UK, Australia, Canada and New Zealand: e-commerce sellers, subscription software firms and professional-services businesses. Named MID, one dashboard, one signed event stream.

Why direct wins over third-party for most regional credit card acceptance

Third-party credit card processing gets you live in hours. A direct regional credit card processor takes a few more days at boarding and pays back on every axis that matters after go-live. Four properties explain the delta.

  • Direct processor, not a reseller

    BazPay is the credit card processor and the acquirer for its regional book. No third-party reseller sits between you and the schemes; the credentials that authorise your traffic and the ones that settle your funds belong to the same entity.

  • Named MID per merchant

    Every merchant receives its own merchant identifier with the schemes. Chargeback ratios, decline data and settlement reporting are attributed to your entity, not diluted across an aggregator's pool of shared MIDs.

  • Interchange++ transparency on every transaction

    Interchange fees flowing to the issuer, scheme fees flowing to Visa or Mastercard, and BazPay's processor margin all appear as separate lines on every settled transaction. Finance reconciles against the source, not against a blended monthly summary.

  • One integration, one dashboard, one webhook stream

    Card processing sits inside the wider platform. Fraud rules, refunds, disputes and payouts all fire from the same signed event stream, so a credit-card-processor migration does not fragment your operational surface.

What a credit card processor is responsible for

Four responsibilities sit with the credit card processor across the life of a transaction. On BazPay the same entity owns all four, so no vendor hand-off breaks attribution between authorisation and settlement.

  • Authorise

    Present authorisation to the scheme

    The credit card processor takes the charge from your checkout and posts it to the card scheme with the correct MCC, region, MID and 3-D Secure result. BazPay presents the request on our own regional acquiring licence.

    • Visa
    • Mastercard
    • Cartes Bancaires
    • eftpos
  • Authenticate

    Orchestrate 3-D Secure 2.2

    Authentication is requested by the processor and executed by the shopper's issuing bank. BazPay's exemption engine claims TRA, low-value, trusted-beneficiary and MIT flags where the rules allow.

    • 3-D Secure 2.2
    • Exemption logic
  • Settle

    Reconcile funds to the merchant

    Once the scheme clears the transaction, the credit card processor pays the merchant. Funds land in your local settlement account per scheme cycle with interchange++ line detail on every row.

    • local settlement account
    • Per-scheme cycle
  • Support

    Handle refunds, disputes and reporting

    The processor also owns the post-authorisation surface: full and partial refunds, chargeback lifecycle, dispute evidence and merchant reporting. All from the same dashboard.

    • Refunds
    • Disputes
    • Reporting

Full method depth on card and APM processing. The two-sides explainer on issuing and acquiring. The software layer on network payment gateway.

The life of one credit card charge

Six stages sit between the checkout button and the settled dollar. Each stage is visible in the dashboard and each stage change fires a signed webhook keyed to the same charge ID.

  1. Collect

    Hosted fields render the card entry inside our PCI environment so raw PAN never touches your servers. Mobile SDKs offer the same shape natively.

  2. Score

    The inline fraud engine grades every order against your rule set before the request touches the scheme network.

  3. Authenticate

    3-D Secure 2.2 runs only when the risk earns it; PSD2 exemption logic claims the rest so most credit card checkouts stay frictionless.

  4. Authorise

    The credit card processor presents the transaction to the scheme; the issuer authorises or declines and the response returns via the scheme.

  5. Capture

    Capture at once or later. Partial captures and partial refunds both post cleanly on the same charge object.

  6. Settle

    Funds reconcile per scheme cycle into your local settlement account. Every line ties back to its own transaction ID and interchange++ breakdown.

Direct credit card processor vs third-party reseller

The clearest way to evaluate a credit card processor is by MID structure, reporting granularity and settlement predictability. The comparison below shows where each model earns its keep — third-party models suit merchants that need to go live in hours; a direct processor suits merchants that will care about the reporting later.

BazPay direct regional credit card processor compared with third-party credit card processing model
Dimension BazPay (direct) Third-party reseller
Contract holder You contract directly with BazPay Reseller in front of a downstream acquirer
MID structure Named MID per merchant Shared MID across the reseller's pool
Chargeback attribution Attributed to your entity Diluted across the pool
Reporting granularity Interchange++ per transaction Blended-rate monthly summary
Underwriting Direct with a named onboarding manager Passed through the reseller
Settlement Per scheme cycle to your local settlement account Aggregated payout, common delay
Rate changes Announced in the changelog, versioned Silent within the reseller's tier

Rate structure on the pricing page. Boarding on merchant acquiring. Buyer's shortlist on payment processors.

Features engineered into the credit card processing platform

Every capability below ships on the standard integration. Turn features on with a request flag or a dashboard toggle — no premium tier gates hosted fields, network tokens or the webhook contract.

  • Hosted fields

    Card, expiry and CVC inputs served from our PCI environment inside your existing checkout — the credit card entry never touches your DOM in the clear.

  • Gateway-side vault

    Stored credentials sit inside our PCI DSS Level 1 scope, keyed to your merchant. Portable if you ever migrate off the platform.

  • Network tokens

    Visa and Mastercard network tokens replace the PAN at storage time and refresh automatically when a card is reissued.

  • 3-D Secure 2.2 engine

    Authentication orchestrated by the processor, executed by the issuer; automatic exemption logic covers TRA, low-value, trusted-beneficiary and MIT.

  • Idempotent API

    Retry-safe writes across create, capture, refund and payout. A network blip on a credit card charge never becomes a double charge.

  • Signed webhooks

    HMAC-signed, replay-protected events for every state change on the charge — approval, decline, capture, refund, dispute and settlement.

  • Interchange++ reporting

    Interchange (to the issuer), scheme fees and processor margin split per settled charge for line-level reconciliation.

  • Storefront plugins

    Maintained plugins for WooCommerce, Magento 2, PrestaShop and Shopware expose the credit card processor to your existing storefront.

One REST call to charge a credit card

The charge object is the unit of work. One versioned REST endpoint authorises, captures and refunds. Idempotency headers make retries safe. Signed webhooks confirm every state change asynchronously.

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

The response returns a canonical charge object with the authorisation code, the MID it posted against, the interchange bucket and any exemption applied. Full schema in the API reference and handler samples in the developer docs.

Who runs credit card processing on BazPay

Four merchant profiles fit BazPay's regional underwriting. Each uses the same API surface and the same signed event stream for card charges.

  • E-commerce sellers

    DTC brands and multi-country storefronts using cards as the primary acceptance rail. Named MID, interchange++ reporting and plugin-friendly integration.

  • Subscription software

    SaaS teams billing card-on-file with network tokens, MIT exemptions and dunning-aware retries so credit-card renewals stay warm through reissue waves.

  • Professional services

    Higher-ticket B2B invoicing with named-payer trust lists and enforced 3-D Secure 2 over a threshold you set — protection where it matters most.

  • Digital publishers

    Membership and paywall businesses processing small-ticket card charges at high volume with per-SKU reconciliation on the same MID.

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 on the credit-card side

The credit card processing environment runs inside a PCI DSS Level 1 assessment renewed each year. Hosted fields and gateway-side vaulting keep your annual return at merchant SAQ A. Authentication runs on every card charge through 3-D Secure 2.2 with automatic exemption logic; In-region data residency is default under GDPR.

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 card charge
GDPR
In-region data residency; DPA on request
Scheme registrations
Visa VIRP and Mastercard SPoC/PCI-CP registered where required

Questions merchants ask about credit card processors

What does a credit card processor actually do?

A credit card processor takes a payment request from the merchant's checkout, presents it to the card scheme, orchestrates 3-D Secure 2 authentication where required, receives the issuer's authorisation response and reconciles settlement back to the merchant. On BazPay the processor is also the direct regional acquirer, so one entity owns the merchant contract, the technical processing and the settlement.

Is BazPay a third-party credit card processor?

No. A third-party credit card processor (sometimes called a reseller or aggregated PSP) sits in front of a separate downstream acquiring bank on a shared MID. BazPay is a direct regional acquirer processing on its own licence for its merchant book, so there is no third party between you and the card schemes. Merchants specifically shopping for a third-party model — where they land on a shared MID for the fastest possible boarding — will typically be looking at a different type of provider.

What is third-party credit card processing, and when does it fit?

Third-party credit card processing is a model where an aggregator holds the acquiring relationship and boards many merchants onto shared MIDs. Boarding is fast, but reporting is blended, chargebacks affect the whole pool and settlement typically arrives on the aggregator's schedule. It fits merchants that need to go live in hours and do not need interchange++ reporting; it stops fitting once volume, reporting granularity or chargeback attribution start to matter.

How does 3rd party credit card processing compare with a direct processor like BazPay?

3rd party credit card processing trades reporting granularity and MID isolation for boarding speed. A direct credit card processor (BazPay) takes a few more days at boarding and pays back in interchange++ line detail, named-MID chargeback attribution and predictable per-scheme-cycle settlement to your own local settlement account. Both models are legitimate; the choice depends on the business's stage and reporting expectations.

How does BazPay handle 3-D Secure 2 as the credit card processor?

The processor requests 3-D Secure under PSD2 on every card charge. The shopper's issuing bank actually runs the challenge — through their banking app or an SMS-backed flow. BazPay's exemption engine claims TRA, low-value, trusted-beneficiary and MIT exemptions where the rules allow, so most credit card checkouts stay frictionless and the challenges that do fire shift liability to the issuer on qualifying flows.

Which currencies does the credit card processor support?

Authorisation runs in EUR and more than twenty presentment currencies. Settlement lands in EUR into a regional settlement account by default; named settlement currencies are available for approved corridors. Interchange fees flowing to the issuer are shown on the interchange++ statement in the transaction's presentment currency.

Which merchant profiles can board on BazPay's credit card processing?

Merchants across the EU, UK, Australia, Canada and New Zealand: e-commerce sellers, subscription software firms, professional-services businesses and digital publishers. BazPay does not board adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection or MLM merchants, and does not act as a marketplace of third-party PSPs or a merchant of record.

Can I migrate my card vault from another credit card processor to BazPay?

Yes, under a scheme-approved migration. Stored credentials and existing network tokens can be imported from an incumbent processor, subject to the receiving bank's consent letters. Old and new webhook streams typically run in parallel until traffic is proven on the new stack, so card-on-file renewals do not miss a cycle.

Contract directly with a regional credit card processor

Share your business model, monthly card volume and current processor. A named engineer will confirm boarding fit and map the migration inside one working day. See also merchant acquiring, payment processors and issuing and acquiring.