BazPay scores every order in real time before the acquirer sees it. Device, velocity and geography signals collapse into one decision. You set the thresholds, we run the engine, and 3-D Secure 2.2 steps in only when the risk earns it.
Built for regional sellers: shops, subscription software firms and professional services. Blunt blocking costs good revenue. Tuned rules do not.
The scoring engine, the acquirer and the dispute tooling belong to the same platform. That removes the middle layer between the signals and the settlement — the part where most payment gateway fraud management falls apart.
Signals collect at checkout and resolve into a single decision before the acquirer sees the request. Bad orders never reach the network, so scheme ratios stay clean.
Rule outcomes carry four verdicts, not two. Step-up and review keep borderline orders in play, so payments fraud prevention does not silently cost conversion.
Low-value, risk analysis, trusted-beneficiary and merchant-initiated flags are claimed where PSD2 permits. Fewer challenges, same liability shift on the ones that do fire.
The final decision, the rules it hit and the 3-D Secure result are stamped on the charge object and re-used as dispute evidence when a chargeback lands.
Five signal families feed the score. None of them decides alone. Together they separate a card tester from a first-time buyer without a rules war.
01Device
Each checkout carries a device fingerprint, session age, browser traits and network posture. Reused devices across many cards stand out fast, which is what card testing looks like from the gateway side.
02Velocity
Count attempts by card, email, IP, device or BIN over a window you pick. Card testing shows up as a burst. The burst gets blocked before your loss ratio moves.
03Geography
The card issuing country is compared with billing country and IP geolocation. A mismatch raises the score. It never blocks on its own — geography is a signal, not a verdict.
04Basket
Ticket size, item count, SKU mix and first-order status all feed the score. A first order at ten times your average is worth a second look, which is what a review queue is for.
05History
Past approvals, refunds and dispute outcomes on the same payer feed back in. Good repeat buyers get a clear path through checkout. Bad-actor cohorts are marked automatically.
Scores land beside approval data in real-time analytics, so you can see what a rule change did within minutes. See also the platform-security view on secure online payment systems and the 3-D Secure detail on secure payment services.
Eight stages sit between the checkout button and the settled payment. Each one is visible in the dashboard and each one emits a signed webhook.
Hosted fields and the checkout script gather device, session and network signals in the same request.
BIN data, IP geo and your merchant reputation on the payer are attached to the request before scoring.
Your rule set runs against the enriched request. Every hit is logged with its own rule ID and weight.
One of four verdicts is returned: allow, step up to 3-D Secure 2, send to review or block outright.
If a step-up is required, the shopper is redirected to their issuer's 3-D Secure 2.2 challenge.
The charge posts to the acquirer with the authentication result and CAVV bound to it for issuer scoring.
Final decision, rule IDs and 3-D Secure outcome are written to the payment and to the signed webhook.
Refunds, chargebacks and manual reviews feed the payer history so tomorrow's decisions are sharper.
A rule ends in one of four outcomes: allow, step up, review or block. Thresholds are yours to move. Edits apply to the next order, with no release and no ticket.
The table shows example rules, not defaults you are stuck with. Start with ours. Tune them once you have your own order history and dispute reason-code data.
| Trigger | Outcome | Type |
|---|---|---|
| Velocity — 4+ cards on one device in 10 minutes | Block | card testing |
| Issuing country differs from billing country | Score + | soft signal |
| Order value above your set ceiling | Force 3-D Secure 2 | step-up |
| Payer has a settled dispute on file | Review queue | manual |
| IP flagged as data centre or open proxy | Score + | network |
| Repeat payer, three clean settled orders | Allow | trusted list |
| SCA exemption available (risk analysis, low value, MIT) | Frictionless | Open-finance regulation |
Every capability below is on the standard integration. Turn features on with a request flag or a dashboard toggle. No enterprise-tier gate on the primitives.
Compose triggers on 30+ enriched fields. Publish rule changes from the dashboard — no engineering release required.
Windowed counts on card, IP, email, device and BIN. Card-testing bursts and BIN-attack sweeps are caught inline.
Stable device hash tracks a shopper across sessions without cookies, so trusted repeat buyers keep frictionless paths.
Curate lists of payer IDs, emails, BINs, IP ranges and shipping addresses. Bulk import from CSV.
Borderline orders park in a queue with the full signal breakdown. Analysts approve, deny or refund with one click.
Frictionless flow first, challenge only when your rules or the issuer require it. Exemption logic runs automatically.
Early scheme alerts, evidence templates and one-click submission. The 3-D Secure proof is attached automatically.
HMAC-signed, replay-protected events for every decision, step-up outcome and dispute state change.
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 gateway 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": "..." }
}
Every state change fires a signed webhook — charge.reviewed,
charge.blocked, dispute.opened. The complete event catalogue
lives in the API reference and the developer docs.
Strong customer authentication is an PSD2 duty. It is also a common place to lose sales, because every prompt adds friction. We ask for one only when the rules say the risk earns it — and when we do, the issuer already has the enriched risk data, so most challenges resolve frictionlessly.
Low-value, risk analysis, trusted-beneficiary and merchant-initiated exemptions are requested where PSD2 allows. When a challenge does fire, liability for that order shifts to the issuer. The result is stored with the payment and re-used as dispute evidence.
Cards are one rail among several. Open banking carries bank-side authentication of its own, with no card number in the flow at all — a useful addition to your online payment fraud prevention posture for higher-ticket orders.
More on the rails: card and APM processing and recurring billing for saved-card renewals.
The default rule set already reflects these four merchant profiles. Turn the ones you need on from the dashboard and adjust the thresholds against your own order history.
Card-testing burst detection, BIN attack blocking and address-mismatch scoring for DTC and multi-country storefronts.
Merchant-initiated exemptions on renewals, dunning-aware velocity rules and dispute reason-code webhooks.
Higher-ticket B2B invoicing with named-payer allow lists and enforced 3-D Secure 2 over your chosen ceiling.
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.
Digital payment fraud prevention only works if it runs on every charge, at the moment of the charge. The comparison below explains why a batch-review process leaves losses on the table that an inline decision would not.
| Dimension | BazPay inline engine | Batch review workflow |
|---|---|---|
| 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 | Code deploy or PSP ticket |
| 3-D Secure link | Fires exactly when the rule earns it | Blanket or off |
| Dispute evidence | 3-D Secure + signals auto-attached | Manual packet assembly |
Fees and settlement details on the pricing page. Plugin coverage on the integrations page. For the outbound side of the flow, see payouts. The rule engine sits inside the wider payments solutions bundle, boarded under merchant acquiring, and runs on the same payment infrastructure — with dispute defence tuned for intangibles on the digital-goods gateway.
Screening cuts the volume. It never gets it to zero. So the case flow is built in.
Schemes send pre-dispute alerts (RDR, Ethoca, CDRN where enrolled). We surface them in the dashboard and by signed webhook.
Refund early and the case often stops before a chargeback opens. Choose to defend and we open a slot for your evidence.
Upload delivery proof, session logs and the 3-D Secure 2 result. The packet is formatted to the scheme's current template.
Every state change is stamped in the dashboard. Export the case list as CSV for your finance team's reconciliation.
The rule engine, 3-D Secure 2.2 and dispute tooling ship inside the same payment gateway that clears the transaction. That removes a hop and gives the score every enriched field the acquirer has — BIN metadata, network-token status, issuer response history — that a bolt-on fraud prevention solution cannot see.
No. Sensible defaults for card testing, velocity, geo mismatch and step-up ceilings run from day one. You can then tune each threshold from the dashboard, with no code change and no release. Rule versions are logged, so you can revert a change if it moves the wrong metric.
Scoring runs inline, before the authorisation call. Shoppers see one flow. 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.
No PAN reaches your servers. Hosted fields and gateway-side vaulting keep card data inside our PCI DSS Level 1 scope, so your annual return stays at SAQ A. The scoring engine works on tokens and enriched signals, never on the card number in the clear.
Every settled order carries its 3-D Secure 2 result, the signals that fed the decision and the delivery log if you push shipping events to the API. When a chargeback opens, the evidence packet is pre-assembled to the scheme's current template — you review, add anything specific and submit.
Velocity counters run on card, IP, email, device and BIN over configurable windows. A burst of attempts against sequential card numbers on one device triggers an automatic block, and the source device is added to a rolling deny list without human intervention.
Yes. Merchant-initiated transaction exemptions run on renewals with a stored mandate, so trusted repeat charges stay frictionless. Dunning-aware velocity rules distinguish a genuine card-update flow from an account-takeover attempt.
BazPay is a regional acquirer. Merchant fraud prevention here is tuned for e-commerce sellers, subscription software firms, professional services and digital publishers. BazPay does not board adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection or MLM merchants.
Replay approvals, declines, step-ups and disputed charges before a single live order. Sandbox keys are self-service and the hosted checkout products are wired in by default.