Card and APM processing across five regulated markets.

We underwrite a defined list of MCCs: physical e-commerce retail, subscription SaaS, digital goods with immediate fulfilment, and professional services billed on completion. We decline adult, gambling, CBD and nutraceuticals, forex, CFD and crypto exchange, debt collection, multi-level marketing, and any model built on long forward-delivery windows.

The basis is acquirer risk appetite plus scheme brand-protection rules — Visa's Integrity Risk Program and Mastercard's BRAM — layered with chargeback-ratio monitoring. Where a business model sits outside that appetite we decline at application rather than onboard it and terminate ninety days later.

Borderline models — marketplaces, ticketing, high-ticket B2B — receive a written risk position before contracts are signed, not after the first monitoring letter.

BazPay underwrites merchants in the European Union, the United Kingdom, Australia, Canada and New Zealand — Germany, France, the Netherlands, Spain, Poland and Ireland on the EU side, plus the UK, Australia, Canada and New Zealand. Those are the markets where we hold acquiring relationships and local settlement accounts, and where a merchant contract is signed.

The reach is wider than the licensing. On the pay-in side a Visa, Mastercard, American Express or Cartes Bancaires credential issued anywhere authorises against the same acquiring contract as a domestic one and settles into the same balance; inter-regional interchange is simply itemised at its own rate rather than the intra-EEA cap. Local methods are the exception, not the rule: iDEAL, Bancontact, BLIK and EPS are national schemes and only clear in their own market.

On the pay-out side domestic rails cover each market — SEPA Credit Transfer and SEPA Instant across the euro area, Faster Payments and BACS in the UK, the New Payments Platform and Osko in Australia, Interac e-Transfer in Canada, and bank transfer in New Zealand. Beneficiaries elsewhere are reached over SWIFT, and push-to-card lands on any Visa or Mastercard credential the scheme permits. Corridors are approved per merchant at underwriting rather than switched on by default, because the sanctions and correspondent-banking checks differ by route.

Pay-in

Cards worldwide · local methods per market

Pay-out

SEPA · FPS · NPP · Interac · SWIFT

Corridor approval

Per merchant, at underwriting

SWIFT timing depends on the correspondent banks on the route, so a corridor is quoted rather than a settlement date promised. Coverage and settlement currency are confirmed in writing before onboarding.

Interchange++ is the default and the only model we quote to a new merchant. Each settled transaction itemises three components: the interchange the issuing bank keeps, the scheme fee, and the BazPay margin. Blended pricing conceals the first two, so a rate that looks flat drifts silently with your card mix.

Consumer debit, intra-EEA

0.20% interchange cap

Consumer credit, intra-EEA

0.30% interchange cap

Commercial & inter-regional

Uncapped — itemised in full

Caps are set by Regulation (EU) 2015/751 in the EU, by the onshored Interchange Fee Regulation in the UK, and by the RBA's interchange standards in Australia — and they bind interchange only. Scheme fees and gateway margin are separate lines in the settlement file and we report them as such.

It does not. Card entry uses hosted fields served from a BazPay origin inside an iframe: the PAN is typed into our document, posted to our vault and returned to you as a token. Your application, your logs and your database hold that token and nothing else.

Vaulting happens inside BazPay's cardholder data environment, hosted in-region in Dublin and Sydney. Tokens are registered with the schemes' network tokenisation services, so a reissued or expired card keeps billing without sending the customer back to a card form.

Tokens are portable. If you leave, we export the vault to your next provider under a scheme-approved migration — commercial lock-in is not part of our security model.

One condition: every element of the payment page that captures cardholder data must be delivered by the validated provider rather than by your site. Hosted fields and hosted checkout both satisfy it. Direct-post, or our script collecting card data inside your own DOM, moves you to SAQ A-EP — a self-assessment several times longer plus quarterly ASV scanning.

PCI DSS v4.0.1 moved the script-integrity requirements, 6.4.3 and 11.6.1, out of SAQ A and replaced them with an eligibility criterion; SAQ A-EP still carries both in full. Choosing hosted fields is therefore a scope decision, not a checkout-styling preference.

Hosted fields · hosted checkout

SAQ A

Direct-post · merchant-DOM capture

SAQ A-EP + ASV scanning

We will state our scope position in writing for your QSA, naming the integration pattern you actually deployed rather than the one you were sold.

Authorisation, vaulting and settlement reporting run in two in-region estates — Dublin for EU and UK traffic, Sydney for Australian and New Zealand traffic — so an EU merchant's data stays under the GDPR and a UK merchant's under the UK GDPR and the Data Protection Act 2018, rather than crossing an ocean to be processed. Canadian traffic is handled under PIPEDA and Australian traffic under the Privacy Act 1988.

BazPay is your processor under GDPR Article 28 for merchant-instructed processing, and an independent controller for the fraud, sanctions and anti-money-laundering checks we are legally obliged to perform. The DPA sets out which role applies to which data category instead of labelling us a processor throughout.

Card schemes are global networks, so an authorisation message leaves the region when the issuer sits outside it. That transfer runs on the safeguards each regime recognises — Standard Contractual Clauses in the EU, the ICO's International Data Transfer Addendum in the UK — and is disclosed in the sub-processor register, which is versioned and dated.

Processing & vault regions

Dublin · Sydney

Regimes

GDPR · UK GDPR · Privacy Act · PIPEDA

AML record retention

5 years (5AMLD · MLR 2017)

Sub-processor changes are notified thirty days before they take effect, with a documented right to object.

Every EEA-to-EEA and UK e-commerce authorisation is in scope for strong customer authentication under the PSD2 RTS and the FCA's Payment Services Regulations, so the question is never whether to challenge but who carries the exemption. We request it in the 3-D Secure 2 message with the full data set — device, prior transaction history, delivery-address match — and fall back to a challenge only once the issuer refuses. Australian, Canadian and New Zealand issuers are not bound by SCA, but the same risk data still lifts their approval rates.

Low value · Art. 16

≤ €30, counter-limited

Transaction risk analysis · Art. 18

€100–€500 by acquirer fraud rate

Fixed recurring · Art. 14

Exempt after the initial SCA

Trusted beneficiary · Art. 13

Issuer-held allow list

Issuer decline reasons are surfaced verbatim in the dashboard, with soft declines, do-not-honour and 3-D Secure abandonment separated — the fix for each one is different.