Menu
Talk with sales

Integration questions? [email protected]

Payment fraud on the merchant side and how BazPay's platform handles it.

Payment fraud is a broad domain — card testing, chargeback fraud, account takeover, refund abuse — plus consumer-side scams (authorised push payment fraud) that sit at the bank layer. BazPay's platform addresses the merchant-side card and regional APM part with inline decisioning, 3-D Secure 2.2 orchestration and dispute defence. This page is the taxonomy view of the domain and where each control applies.

Built for merchants across the EU, UK, Australia, Canada and New Zealand: e-commerce sellers, subscription software firms and professional-services businesses. The payment fraud prevention page covers the rule engine and dispute tooling in depth.

Talk with sales See the fraud product

What a working payment fraud posture actually looks like

Payment fraud is not defeated by one product. Four properties keep the fraud posture honest, measurable and reversible on a mature regional acquiring platform.

  • Fraud posture, not a single fraud product

    Payment fraud risk management works only as a system — device signals, velocity counters, 3-D Secure 2 orchestration, dispute evidence and reporting all pulling in the same direction. BazPay bundles those primitives into one integration.

  • Inline decisioning on every charge

    The fraud engine scores every order before authorisation, not on a batch review after the fact. Card testing, BIN attacks and burst velocity fail closed; clean orders stay frictionless.

  • Honest scope: card + APM fraud on the merchant side

    BazPay's controls focus on the card and regional APM fraud you can influence as a merchant. Consumer-side scams (authorised push payment fraud) sit with the shopper's bank; that boundary is called out plainly on this page rather than papered over.

  • Real-time analytics that show what a rule change did

    Every decision the engine takes lands in real-time analytics within seconds. Payment fraud analytics on BazPay show approvals, declines and verdicts per rule so you tune against evidence, not against last quarter's dashboard.

The four kinds of merchant-side payment fraud we address

Four fraud types cover most of what a regional merchant will encounter on card and regional APM traffic. Each has its own signals and its own control mix on BazPay.

  • Card testing

    Card testing and BIN attacks

    Fraudsters test stolen or generated PANs against a merchant's checkout to see which authorise. BazPay's velocity counters and device fingerprint block these bursts inline — often before the loss ratio moves. This is the most common form of card payment fraud a merchant faces.

    • Velocity
    • Device fingerprint
    • BIN block

  • Chargeback fraud

    Chargeback ("friendly") fraud

    A genuine cardholder disputes a legitimate charge to their issuer. Dispute defence packets that include the 3-D Secure result, delivery proof and charge metadata shift the win rate on defensible cases.

    • 3DS evidence
    • Delivery proof
    • Metadata

  • Account takeover

    Account takeover on the merchant side

    A fraudster gains access to a legitimate merchant customer's account and abuses stored credentials. Device-fingerprint deltas, dunning-aware retry limits and named-payer allow lists narrow the exposure.

    • Device drift
    • IP reputation
    • MFA hooks

  • Refund / return abuse

    Refund and return abuse

    A shopper receives goods and later triggers refund or return workflows dishonestly. BazPay's per-SKU metadata and payer-history features feed your existing refund policy so trusted payers stay easy and repeat offenders do not.

    • Payer history
    • SKU metadata

Product page for the rule engine and dispute tooling on payment fraud prevention. Security architecture around it on secure online payment systems.

Every fraud decision, end to end

Six stages describe the path a payment takes through the fraud controls. Every stage is instrumented and visible in real-time analytics — decisioning is a system you can audit, not a black box.

  1. Collect

    Hosted fields and the checkout script gather device, session and network signals before the payment reaches the acquirer.

  2. Enrich

    BIN metadata, IP geo and your merchant reputation on the payer are attached to the request before scoring.

  3. Score

    Your rule set runs against the enriched request. Every hit is logged with the rule ID and weight it fired at.

  4. Decide

    One of four verdicts is returned: allow, step up to 3-D Secure 2, send to review or block outright.

  5. Authorise

    The charge posts to the acquirer with the authentication result bound to it for issuer scoring. Signed webhooks fire on every state change.

  6. Feed back

    Refunds, chargebacks and manual reviews feed the payer history so tomorrow's decisions are sharper — a live loop, not a monthly report.

Inline decisioning vs batch review

Merchant fraud reviews used to be a batch job — analysts pulling a daily list of suspicious orders. Digital payment fraud prevention only works if it runs on every charge, at the moment of the charge. The comparison shows where each model earns its keep.

BazPay inline rule engine compared with batch review workflow
Dimension BazPay inline engine Batch review
Decision latency Inline, sub-second Batch review, hours
Coverage Every charge Sampled or above-threshold only
Verdicts Allow / step-up / review / block Allow / hold
Rule changes Dashboard, effective on next order Ticket to the reseller
3-D Secure link Fires exactly when the rule earns it Blanket or off
Dispute evidence 3-D Secure + charge metadata auto-assembled Manual packet, missed deadlines
Analytics Real-time per rule and per decision Blended weekly summary

Fees and settlement on the pricing page. Analytics surface on real-time analytics.

Features that make up the fraud management stack

Every capability below ships on the standard integration. Turn features on with a dashboard toggle — no premium tier for the rule engine, the review queue or dispute defence.

  • Inline rule engine

    Compose triggers on 30+ enriched fields. Publish rule changes from the dashboard with no engineering release.

  • Velocity counters

    Windowed counts on card, IP, email, device and BIN catch card-testing bursts and BIN-attack sweeps inline.

  • Device fingerprinting

    Stable device hash tracks a shopper across sessions without cookies; account-takeover deltas surface fast.

  • Review queue

    Borderline orders park in a queue with the full signal breakdown. Analysts approve, deny or refund with one click.

  • 3-D Secure 2.2

    Authentication with automatic exemption logic — TRA, low-value, trusted-beneficiary, MIT — so most checkouts stay frictionless.

  • Dispute defence

    Chargebacks arrive as signed events; the evidence packet is pre-assembled with authentication result and charge metadata for one-click submission.

  • Real-time analytics

    Approval, decline, fraud verdict and dispute outcome data visible within seconds — measure what a rule change did before the next scheme cycle.

  • Signed webhooks

    HMAC-signed, replay-protected events on every decision, step-up and dispute state change — payment fraud management works out of one event stream.

Read the fraud verdict from the API and webhook

The charge response and the signed webhook carry the fraud verdict, the rules that fired and the 3-D Secure outcome. Wire that into your order router, your dunning system or your CRM — the fraud surface is a first-class part of the API. 

{
  "id": "ch_02H9F...",
  "status": "requires_action",
  "amount": 12900,
  "currency": "EUR",
  "risk": {
    "verdict": "step_up",
    "score": 46,
    "rules_fired": ["velocity.ip.5min", "geo.mismatch"],
    "sca": { "type": "3ds2", "exemption": null }
  },
  "next_action": { "type": "3ds_redirect", "url": "..." }
}

Every state change fires a signed webhook — charge.reviewed, charge.blocked, dispute.opened. Read the full event catalogue in the API reference.

Where the fraud posture earns its place

The four merchant profiles below already rely on BazPay's fraud stack to keep their approval quality high and their chargeback ratios low.

  • E-commerce sellers

    Card-testing burst detection, BIN-attack blocking and address-mismatch scoring for DTC and multi-country storefronts. Anti fraud solutions tuned to a lean risk team.

  • Subscription software

    Merchant-initiated exemptions on renewals, dunning-aware velocity rules and dispute reason-code webhooks — payment fraud solutions native to the recurring flow.

  • Professional services

    Higher-ticket B2B invoicing with named-payer allow lists and enforced 3-D Secure 2 over a ceiling you set.

  • Digital publishers

    Account-takeover heuristics on membership renewals and shared-credential detection across paywall unlocks.

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

Compliance signals that back the fraud posture

The floor for credible payment fraud solutions is PCI DSS Level 1 on the provider's environment, merchant SAQ A on the integrator's side, authentication via 3-D Secure 2.2 with automatic exemption logic and adherence to Visa and Mastercard dispute rulebooks. GDPR-compliant In-region data residency rounds out the checklist reviewers actually run.

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 dispute rules
Adherence to Visa and Mastercard dispute rulebooks

Questions merchants ask about payment fraud

What kinds of payment fraud does BazPay actually address?

BazPay's controls address merchant-side card and regional APM fraud: card testing, BIN attacks, chargeback ("friendly") fraud, refund and return abuse, and account takeover on saved credentials. The payment fraud prevention page covers the rule engine and dispute tooling in depth; this page is the taxonomy view around it.

Does BazPay handle authorised push payment fraud?

Authorised push payment fraud (APP fraud, sometimes written authorized push payment fraud) is a consumer-side scam where a shopper is tricked into sending a bank transfer to a fraudster. The controls that address APP fraud sit with the shopper's own bank under evolving PSD2 and national-scheme rules — not with a merchant-side payment gateway. BazPay is a merchant-facing platform, so APP-fraud controls are outside its scope. Merchants seeing suspicious push-payment behaviour should raise it with their acquiring team; the BazPay platform will surface the event, but the reimbursement flow runs at the bank layer.

What about ACH payment fraud?

ACH is a US bank rail. BazPay operates in-region on SEPA and SEPA Instant, so ACH payment fraud is out of scope by geography — BazPay does not process ACH. Regional equivalents (BACS Direct Debit disputes, SEPA Instant misdirected payments) fall under the local scheme rulebooks and are handled inside the platform where BazPay is the acquirer.

How is credit card payment fraud detected in practice?

Every charge is scored inline before authorisation. Device fingerprint, velocity counters, BIN metadata, IP reputation and your own payer history feed the decision. Card testing looks like a burst; the burst fails closed. Suspicious first-time high-ticket orders park in a review queue instead of auto-blocking, so legitimate customers get a human check rather than a silent decline.

What do payment fraud analytics show a merchant?

Approvals, declines and fraud verdicts per rule, per method, per country, per shopper cohort — refreshed within seconds of the underlying event. You measure the impact of a rule change on the next order, not on next month's report. Chargeback rates, dispute win rates and step-up 3-D Secure outcomes join the same view.

How do you prevent payment fraud without hurting conversion?

Rule outcomes are four-valued, not two: allow, step up to 3-D Secure 2, send to review, or block. Step-up and review keep borderline orders in play instead of silently blocking them, and 3-D Secure 2 runs with SCA exemptions where the rules allow, so most checkouts stay frictionless. That balance is what payment fraud management looks like on a mature platform.

How does dispute defence work on chargebacks?

Chargebacks arrive from the issuer through the scheme to the acquirer. BazPay surfaces them in the dashboard and by signed webhook, pre-assembles an evidence packet with the 3-D Secure 2 authentication result and your charge metadata (delivery, licence, buyer identifier), and submits the defence to the scheme on your behalf. You review, add anything specific and submit in one click.

Which merchant profiles can use these fraud management solutions?

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 merchant of record.

Bring your fraud posture on to a direct regional acquirer

Share your business model, monthly volumes and current fraud losses; a named engineer will confirm boarding fit and map the rule rollout inside one working day. See also payment fraud prevention, merchant acquiring and payment processors.

Talk with sales Read the developer docs