Fraud detection · layered

Fraud detection tools wired into routing, vault and disputes — all in one stack.

The platform layers deterministic rules, partner ML engines and selective 3DS2 on the same authorisation path. Fraud signals feed the routing engine; disputes feed back into the rules. One stack across every connected acquirer — without forcing the merchant onto a single fraud vendor.

Book a fraud-tooling review Read the API docs
Enrichment Partner ML Platform rules 3DS2 / SCA Vault
Five concentric layers · one auth-path budget.
Pre-auth
score every authorisation before capture
Partner ML
best-of-breed engine connectors per vertical
Post-event
unified dispute queue with evidence templates

Key benefits

Why merchants pick a layered approach to payment fraud detection

Four pillars that show up the moment fraud stops being a single-vendor black box and starts being a layered surface integrated into routing and disputes.

  • Layered, not single-vendor

    Fraud isn't one shape, and one engine never wins on every vertical. The platform combines its own scoring with connectors to partner engines (Riskified, Sift, Forter, Kount, Signifyd and others) so the merchant picks the engine that fits the vertical, not the one shipped by default.

  • Wired into routing, not bolted-on

    Fraud signals feed the same routing engine that picks the acquirer. A high-risk score can step up to 3DS2, route to a cascade-tolerant acquirer, or hold for manual review — without leaving the authorisation.

  • One queue across providers

    Chargebacks, retrievals and dispute notifications from every connected acquirer normalise into one queue. Evidence-pack templates per vertical and per scheme reason-code; automated representment for select scheme types.

  • Scheme-programme aware

    Per-acquirer position vs Visa's VDMP / VAMP / VFMP and Mastercard's ECP / EFMP surfaced in the dashboard. Routing weights can rotate around at-risk lanes before a programme breach turns into a fee event.

How fraud detection in payment gateway flows runs

From auth request to one decision in six layered steps

Six layers run inside the authorisation timeout window. Each can short-circuit the chain — a clean clear, a step-up, a hold for review, or a hard decline.

  1. 01

    Capture & enrich

    Authorisation request enriches with device fingerprint, IP geolocation, BIN intelligence, velocity counters and prior token history. No PII leaves the platform vault.

  2. 02

    Platform-side scoring

    Rules-based velocity, list management (allow / deny / review), per-BIN ratio guards and per-customer behavioural heuristics run synchronously on the auth path.

  3. 03

    Partner ML engine (optional)

    When a partner ML engine is wired in, the enriched payload is scored by it inside the authorisation timeout window — score and decision return to the platform for the routing decision.

  4. 04

    Selective 3DS2 / SCA step-up

    Borderline scores can step up to EMV 3DS2; below the threshold, frictionless flows pass through; PSD2-exemption logic applies in Europe.

  5. 05

    Route, capture or hold

    Cleared transactions route across the connected acquirer panel; held transactions surface in the operator's review queue; hard-declined attempts log without leaking signals to the buyer.

  6. 06

    Post-event: dispute & feedback

    Chargebacks and refund-fraud signals feed back into the rules engine and partner ML training set, closing the feedback loop.

Main use cases

Where payment fraud detection software earns its keep across verticals

Six recurring merchant shapes and the dominant attack vectors against each — DTC, SaaS, travel, marketplaces, licensed gaming and B2B.

  • DTC

    DTC defending against card-testing

    Card-testing attacks against checkout forms get throttled by per-IP and per-BIN velocity rules; partner ML adds device-graph heuristics; routing rotates away from the targeted BIN range.

  • SaaS

    SaaS defending recurring on stored credentials

    Stored-credential transactions on recurring SaaS billing run network tokens; ATO attempts on the customer portal get scored on device fingerprint and behavioural signals before any stored-credential charge fires.

  • Travel

    Travel and ticketing on high tickets

    Higher ticket sizes attract refund / triangulation fraud. Per-ticket-band rules plus partner ML insurance-style scoring keep fraud off without killing legitimate bookings.

  • Plat

    Marketplaces with cross-seller patterns

    Cross-seller velocity (same buyer, many sellers) and refund-rate guards catch triangulation. Per-seller risk profiles route high-risk sellers to cascade-tolerant acquirers.

  • Gaming

    Licensed gaming where licensed

    Licensed gaming verticals get tighter velocity rules, KYC re-checks on high-velocity deposits and partner-engine connectors tuned for gaming-specific fraud taxonomies.

  • B2B

    B2B invoicing & wire-style payouts

    Account-takeover on B2B accounts is the dominant vector. Step-up authentication on high-value B2B authorisations plus operator-side approval workflows on payouts above configurable thresholds.

Platform features

Capabilities behind the platform-side fraud surface

Twelve capabilities the platform ships out of the box — from pre-auth velocity and list management through to evidence-pack templates and scheme-programme posture.

  • Pre-auth velocity rules

    Per-IP, per-BIN, per-card-fingerprint and per-customer velocity counters scoped to time windows.

  • List management

    Allow / deny / review lists per attribute (email, IP, BIN range, country, device) with operator audit log.

  • Device fingerprinting

    Browser-collected fingerprint feeds the score; per-device velocity counters built from it.

  • Selective 3DS2 / SCA

    Frictionless by default; step-up triggered by score or PSD2-exemption rules; same auth path.

  • Partner ML connectors

    Riskified, Sift, Forter, Kount, Signifyd and others can be wired into the same auth-path timeout window.

  • Routing integration

    Fraud scores feed the routing engine; cascade weights rotate around at-risk acquirers automatically.

  • Operator review queue

    Held authorisations surface with full enrichment payload; approve / decline / refund actions logged.

  • Unified dispute queue

    Chargebacks, retrievals and dispute notifications from every connected acquirer in one queue.

  • Evidence-pack templates

    Per-vertical and per-scheme reason-code templates speed representment; vault tokens drive receipt assembly.

  • Automated representment

    Where evidence is deterministic and scheme rules permit, representment fires automatically.

  • Scheme-programme posture

    Per-acquirer position vs VDMP / VAMP / VFMP / ECP / EFMP surfaced in real time on the dashboard.

  • Operator-side refund controls

    Refunds require justification and log every event with actor identity, reason code and timestamp.

Onboarding side

underwriting fraud detection at sign-up, not just at checkout

The hardest fraud to stop at checkout is the fraud that should never have been onboarded. topropay runs structured KYB document collection, sanctions and PEP screening, adverse-media checks and same-email / same-IP / same-device velocity counters across new-merchant applications — flagged submissions surface in the underwriting review queue for human decision rather than auto-approval.

That cleaner merchant base means the checkout-side fraud layer is doing less work chasing patterns that should never have made it to production traffic.

Industry relevance

How topropay relates to payment fraud detection companies

Standalone payment fraud detection companies ship a single-vendor ML stack — Sift, Forter, Signifyd, Kount, Riskified, Ravelin and others. topropay sits one layer up: it lets merchants combine the platform's own deterministic rules with the partner engine that fits their vertical, then wires that score directly into routing, vault, dispute and reconciliation flows. The merchant keeps the engine choice and loses the integration burden.

  • Sift · marketplaces and account-takeover
  • Forter · retail with chargeback guarantee
  • Signifyd · DTC commerce
  • Kount · travel and ticketing
  • Riskified · cross-border ecommerce
  • Ravelin · ride-hailing and gig
  • + platform-native rules engine
  • + EMV 3DS2 / Visa Secure / Mastercard Identity Check

Trust & compliance

Compliance posture wrapping the fraud-detection layer

One audited environment plus scheme-programme positions surfaced per connected acquirer. Sub-merchants inherit the relevant posture without carrying separate certifications themselves.

PCI DSS Level 1
Annual on-site assessment plus quarterly ASV scans; sub-merchants inherit the posture across every connected provider.
PSD2 / SCA
Selective 3DS2 on the authorisation path keeps approval high in Europe without skipping the SCA bar.
Scheme programmes
VDMP / VAMP / VFMP (Visa) and ECP / EFMP (Mastercard) positions surfaced per acquirer; routing weights rotate around at-risk lanes.
AML & sanctions alignment
Sanctions screening on onboarding and rolling refresh; AML monitoring tuned per merchant vertical, volume and channel mix.
Operator audit logging
Every operator action — refund, dispute response, rule change — logged with actor identity, timestamp and reason.
Licensed verticals only
Licensed gaming, regulated financial services and other compliance-bound verticals supported only where current operating licences exist. Grey and black-market verticals are out of scope regardless of fraud-engine connector.

Ready to layer the defences

Wire fraud detection into routing, vault and disputes — on one platform.

A 30-minute fraud-tooling review covers the platform's deterministic rules relevant to your vertical, the partner ML engines worth wiring in, your scheme-programme posture, and a sandbox you can test against before any commercial commitment.

Book a fraud-tooling review Read the API docs

Frequently asked

Buyer questions about fraud detection tools on topropay

Definitions, partner-engine questions, ML vs deterministic rules, underwriting-side checks and the practicalities of running a layered fraud surface across the connected acquirer panel.

  1. 01

    What fraud detection tools come with topropay out of the box?

    Fraud detection tools that come with topropay out of the box include rules-based velocity, list management (allow / deny / review), per-BIN ratio guards, behavioural heuristics, device fingerprinting, selective EMV 3DS2 / SCA orchestration and a unified dispute queue. These run synchronously on the authorisation path without any extra integration.

  2. 02

    How does payment fraud detection work in the unified API?

    Payment fraud detection on the unified API runs in two layers. Pre-auth: every authorisation is enriched with device, IP, BIN and velocity signals and scored by the platform's rules engine plus any wired-in partner ML engine. Post-event: chargebacks and refund-fraud signals feed back into the rules and partner-engine training sets, closing the loop.

  3. 03

    Is online payment fraud detection on topropay synchronous or async?

    Online payment fraud detection is synchronous — it runs inside the authorisation timeout window so a high-risk score can step up to 3DS2, route to a cascade-tolerant acquirer, or hold for review without dropping the customer's checkout flow. Async post-event analysis is layered on top for dispute work and training-set updates.

  4. 04

    What does the platform recommend for serious online payment fraud detection beyond the defaults?

    For serious online payment fraud detection beyond the defaults, the platform recommends wiring a partner ML engine for the vertical (e.g. Signifyd or Forter for retail, Sift for marketplaces, Kount for travel) and tuning velocity rules per BIN range and per-product. The platform's own engine + partner engine + 3DS2 layered together is meaningfully stronger than any single engine alone.

  5. 05

    Is topropay a piece of payment fraud detection software in itself?

    topropay isn't sold as standalone payment fraud detection software — fraud detection is one layer of the wider orchestration platform. Merchants wanting a single-purpose fraud product typically integrate one of the partner engines through topropay rather than the other way round; the platform's job is to keep the fraud layer wired into routing, vault and reconciliation.

  6. 06

    Where does fraud detection in payment gateway flows fit on the platform?

    Fraud detection in payment gateway flows fits on the synchronous authorisation path. The gateway receives the auth, enriches it, scores it (platform + optional partner ML), applies 3DS2 / SCA where appropriate, then routes across the connected acquirer panel. The merchant integrates the gateway once; the fraud-detection plumbing is configured server-side.

  7. 07

    Does the platform use payment fraud detection machine learning under the hood?

    The platform's own rules engine is deterministic — velocity, lists, ratio guards and behavioural heuristics. Payment fraud detection machine learning is delivered through partner engines (Sift, Forter, Signifyd, Kount, Riskified and others) wired into the same auth-path timeout window. The merchant picks the engine; the platform handles the integration plumbing.

  8. 08

    How does topropay compare to standalone payment fraud detection companies?

    Standalone payment fraud detection companies (Sift, Forter, Signifyd, Kount, Riskified, Ravelin and others) ship a single-vendor ML stack. topropay sits one layer up: it lets merchants combine the platform's deterministic rules with one of those engines, then wire the score directly into routing, vault, dispute and reconciliation. Fewer integration seams; same fraud-engine choice.

  9. 09

    What about underwriting fraud detection on new-merchant applications?

    Underwriting fraud detection runs on the onboarding side: KYB document collection, sanctions and PEP screening on directors and beneficial owners, adverse-media checks, plus same-email / same-IP / same-device velocity counters across new applications to catch synthetic-identity submissions. Flagged applications surface in the underwriting review queue for human decision.

  10. 10

    Can fraud rules be tuned per merchant rather than globally?

    Yes. Every rule, list, velocity counter and partner-engine connector is scoped per-merchant. A platform-wide baseline ships by default; merchants tune above the baseline for their vertical and volume. Operators with cross-merchant visibility (PSPs, marketplaces) can layer policy at the parent level too.

  11. 11

    What attack patterns are the deterministic rules best at catching?

    The deterministic rules are best at high-volume mechanical attacks — card-testing, BIN-attack runs, refund-fraud loops and ATO probes. Per-IP and per-BIN velocity, list management and behavioural-anomaly rules catch these patterns inside the authorisation window. Subtle attack patterns benefit more from partner ML.

  12. 12

    How does the platform handle false positives?

    False-positive management is two-sided. Operators can review held authorisations in the queue and override the decision (with an audit log); cleared overrides feed back into the rules engine and partner-engine training set. Per-merchant dashboards expose false-positive rate alongside fraud-loss rate so tuning is observable.

  13. 13

    Are the dispute and chargeback flows part of the fraud-detection stack?

    Yes. The unified dispute queue, evidence-pack templates per vertical / per scheme reason-code, and automated representment for select scheme types are part of the same fraud-detection stack. Disputes that are won feed back as positive labels; lost disputes drive rule-tightening for the same pattern.

  14. 14

    Does the platform expose its fraud signals to the merchant?

    Yes — the fraud score, contributing signals (velocity buckets, list hits, partner-engine score, device signal, 3DS2 outcome) and the routing decision are exposed per transaction in the dashboard and via the reporting API. Merchants can build their own dashboards on top or pipe events to their data warehouse.

  15. 15

    What's the fastest way to add a partner fraud engine?

    The fastest way to add a partner fraud engine is to use one of the platform's existing connectors — partner credentials get added in the dashboard, traffic flows through the partner inside the auth-path timeout window, and the partner's score becomes available to platform-side rules. No code change on the merchant's side for already-wired connectors.

Related

Related on the topropay platform