Fraud detection tools built into a direct payment gateway.
BazPay ships the fraud detection tools your risk analyst actually uses — a rule builder, velocity counters, device fingerprinting, allow/deny lists and a review queue — inline inside the payment gateway. Every order is scored before the acquirer sees it, and every verdict is inspectable end to end.
Built for merchants across the EU, UK, Australia, Canada and New Zealand: e-commerce sellers, subscription software firms and professional-services businesses. No extra decision-per-request fee, no vendor round trip and no black-box scoring your analysts cannot trace.
Why gateway-native detection tools outperform a bolt-on vendor
Standalone fraud vendors go deep on analyst polish; gateway-native detection wins on latency, cost and the dispute-evidence loop. Four properties make the difference for merchants across the EU, UK, Australia, Canada and New Zealand.
-
Inline detection, not a batch job
Every order is scored before the acquirer sees the request. Bad orders never touch the network, so scheme ratios stay clean and the recovery loop is fast rather than post-mortem.
-
Tools, not a black box
The detection stack ships as inspectable tools — a rule builder, velocity counters, device fingerprinting, allow/deny lists and a review queue. Analysts see which rule fired on any order, not just a score.
-
Signals travel with the payment
The rule IDs that fired, the 3-D Secure result and the fraud verdict are stamped on the charge object and re-used as dispute evidence when a chargeback lands.
-
Bundled with the acquirer, not bolted on
Detection runs inside the same platform that authorises and settles the payment. There is no separate vendor to reconcile against, no per-decision API cost and no time-outs between fraud and acquiring.
The four families of detection tools
Four signal families feed the scorer. None decides alone. Together they separate a card tester from a first-time buyer, and a returning payer from an account-takeover attempt.
-
Device
Device fingerprinting and session tools
Each checkout carries a stable device hash, session age, browser traits and network posture — proxy, headless UA and data-centre IP signals included. Reused devices across many cards stand out fast, which is what card testing looks like from the gateway side.
- Device hash
- Session age
- Proxy flag
- Headless UA
-
Velocity
Velocity counters
Windowed counts on card, IP, email, device and BIN. Card-testing bursts and BIN-attack sweeps trip a counter and roll onto the auto-deny list without human intervention.
- Per card
- Per IP
- Per email
- Per BIN
-
Geography
BIN + country match tools
Card issuing country compared with billing country and IP geolocation. A mismatch raises the score; geography never blocks alone but earns a step-up in most rule sets.
- BIN
- Billing
- IP geo
-
History
Payer-history scoring
Past approvals, refunds and dispute outcomes on the same payer feed the score. Trusted repeat buyers walk through unchallenged; bad-actor cohorts are auto-marked for review.
- Repeat
- Refunds
- Disputes
Detection sits inside the wider payment fraud prevention module; the compliance-and-encryption floor lives on secure online payment systems.
The online payment fraud detection loop
Six stages describe how a payment is scored, decided and fed back into the platform's memory. Every stage is visible in the dashboard and every stage change fires a signed webhook.
-
Ingest signals
Hosted fields and the checkout script gather device, session and network signals inside our PCI environment before any network hop.
-
Enrich
BIN metadata, IP geo, network-token status and your merchant reputation on the payer are attached to the request before it hits the scorer.
-
Score inline
Your rule set runs against the enriched request. Every hit is logged with its own rule ID and weight — analysts see exactly why the score landed where it did.
-
Decide
One of four verdicts is returned inline: allow, step up to 3-D Secure 2, send to review or block outright.
-
Stamp the record
Final verdict, fired rule IDs and 3-D Secure outcome are written to the charge object and to the signed webhook stream.
-
Feed back
Refunds, chargebacks and analyst reviews update the payer-history score, so tomorrow's decisions on the same cohort are sharper.
Gateway-native tools vs standalone fraud vendors
Both approaches work. The trade-off shows up on six axes fraud teams evaluate during procurement — latency, cost, signals, dispute loop, tuning speed and integration surface.
| Dimension | BazPay (gateway-native) | Standalone fraud vendor |
|---|---|---|
| Position | Inside the payment gateway | Standalone vendor bolted on |
| Decision latency | Inline, sub-second | Extra API hop per decision |
| Cost model | Included on the standard integration | Per-decision fee on top |
| Signals | Enriched with acquiring-side data (BIN, network-token status) | Whatever the merchant forwards |
| Dispute-evidence loop | 3-D Secure + fired rules auto-attached | Manual evidence packet assembly |
| Rule changes | Dashboard, effective on next order | Vendor ticket or portal round-trip |
Pricing on the pricing page. Analyst-side reporting on real-time analytics. Direct-processor context on merchant acquiring.
Detection tools shipped on the standard integration
The eight tools below are the primitives fraud analysts spend the day inside. None are gated to an enterprise plan; the primitives are the platform.
-
Rule builder
Compose triggers on 30+ enriched fields from the dashboard. Publish rule changes without an engineering release — effective on the next order.
-
Velocity counters
Windowed counts on card, IP, email, device and BIN. Configurable windows and thresholds per merchant, per market.
-
Device fingerprinting
Stable device hash tracks a shopper across sessions without cookies, so trusted repeat buyers keep the frictionless path.
-
Allow / deny lists
Curated lists of payer IDs, emails, BINs, IP ranges and shipping addresses. Bulk import from CSV and export the full history.
-
Review queue
Borderline orders park with the full signal breakdown, the fired rule IDs and the risk score. Analysts approve, deny or refund in one click.
-
3-D Secure 2.2 engine
Authentication on card charges with automatic exemption logic. Liability shift on qualifying flows without adding shopper friction elsewhere.
-
Dispute defence
Early scheme alerts (RDR/Ethoca/CDRN where enrolled), evidence templates and one-click submission with 3-D Secure proof pre-attached.
-
Signed webhooks
HMAC-signed, replay-protected events per verdict and dispute state change; one signature scheme across every rail.
Read the verdict from the API and the signed webhook
The charge response and the signed webhook carry the risk verdict, the rules that fired and the 3-D Secure outcome. Wire that into your order router, your dunning system or your CRM — the payment fraud detection 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": "..." }
}State-change events on the same signed stream fire when the platform blocks, sends to review or resolves a dispute. Full catalogue in the API reference.
Where the detection tools earn their place
Four merchant profiles already rely on BazPay's gateway-native detection tools in production. Each configures the same primitives against a different attack surface.
-
E-commerce card testing
Sub-second velocity counters and device fingerprinting catch card-testing bursts and BIN attacks before they hit the acquiring rail.
-
Subscription ATO defence
Account-takeover heuristics on membership renewals — shared credentials across cohorts, sudden device change on a paying account, mismatched issuer country.
-
Higher-ticket B2B
Named-payer allow lists and enforced 3-D Secure 2 over a ceiling you set; the review queue takes anything that looks off before it settles.
-
Digital publishers
Paywall unlocks under card-testing pressure use per-BIN velocity counters and IP-network detection to keep small-ticket losses out of the loss ratio.
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.
Compliance signals around the detection layer
The detection layer 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 card charge with 3-D Secure 2.2 and automatic exemption logic; the exemption decisions are traceable back to the fired rule IDs.
- 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
- Audit trail
- Actor, timestamp and payload delta on every dashboard rule change
Questions fraud analysts ask about the tooling
How is this different from the payment fraud prevention page?
The payment fraud prevention page is the product landing for the whole fraud module — how it fits your business and why you would enable it. This page is the shortlist of specific detection tools that ship inside that module, aimed at fraud analysts and risk leads who need to know what primitives are actually available: rule builder, velocity counters, device fingerprinting, review queue, and so on.
Does BazPay use payment fraud detection machine learning?
The detection stack is primarily rule-based scoring on enriched signals — inspectable, explainable and tuneable from the dashboard. Statistical scoring is applied on top of the rule engine where it helps (for example, payer-history reputation and velocity thresholds), but there is no opaque black-box ML model that decides orders without your rules seeing them. Analysts can always trace a verdict back to the fired rule IDs.
What is fraud detection in a payment gateway, in practical terms?
Fraud detection in a payment gateway is the inline scoring and decision layer that runs before the acquirer sees the authorisation request. It combines device signals, velocity counters, geography checks and payer history to grade each order — allow, step up to 3-D Secure 2, send to a review queue or block. On BazPay it is part of the standard integration; nothing extra to install.
How do BazPay's tools compare with standalone payment fraud detection companies?
Standalone vendors are usually deep on ML and analyst tooling but bolt onto your gateway through an extra API hop and a per-decision fee. Gateway-native detection loses some of the analyst polish but gains inline latency, acquiring-side signals (BIN metadata, network-token status), zero decision fees and a tight dispute-evidence loop. Most merchants in the EU, UK, Australia, Canada and New Zealand find the gateway-native option enough; higher-risk verticals often layer both.
Is underwriting fraud detection part of the same tooling?
No — underwriting fraud detection is a merchant-onboarding concern (KYC, beneficial-ownership checks, business-model review), not a transaction-scoring one. BazPay's underwriting is document-based and manual during boarding rather than a self-serve tooling product. The detection tools on this page cover transaction fraud once a merchant is boarded.
Can I export detection outcomes for my own analytics stack?
Yes. Every verdict, review outcome, refund and dispute event fires a signed webhook on the same HMAC scheme as payments. CSV export covers batch analysis for finance and risk teams. Push whichever stream your analysts use into your existing observability or data-warehouse pipeline.
Do the detection tools slow down checkout?
No. Scoring runs inline and returns sub-second. Only step-up verdicts trigger an additional issuer prompt through 3-D Secure 2 — which for most orders is frictionless because the risk data has already been shared with the issuer through the scheme.
Which merchant types are these detection tools tuned for?
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. Merchants in those categories usually require a specialist vendor with its own tooling.
Test the detection tools on sandbox data
Replay approvals, declines, step-ups and disputed charges before a single live order. A named engineer will help wire the review queue and the rule set inside one working day. See also hosted checkout products, payment network gateway and pricing.