Fraud prevention & detection

Fraud prevention and detection — five layers, one authorisation path.

topropay's fraud-controls layer sits inside the same authorisation path as the routing engine. Velocity rules, list management, 3DS2 orchestration, partner fraud-engine connectors and scheme-programme tracking evaluate inline — in under 200ms — feeding a composite risk score that informs clear, challenge and decline.

Book a fraud-controls review Read the API docs
VELOCITY LISTS RULES ENGINE 3DS cleared 5 controls evaluate inline in <200ms
Five layers, one decision per authorisation.
5 layers
of fraud controls in the path
<200ms
decision per authorisation
BYO
partner fraud engine support
1 queue
for dispute and chargeback evidence

Key benefits

Why payments fraud prevention belongs in the same path as routing

Four outcomes that show up consistently once the fraud-controls layer sits inline with the routing engine rather than as a bolted-on, post-authorisation check.

  1. 01

    Fraud prevention and detection in the same path as routing

    Velocity rules, list management, 3DS2 / SCA orchestration, partner fraud-engine signals and scheme-programme tracking all sit inside the same authorisation path as the routing engine. The merchant doesn't bolt on a separate fraud stack — controls evaluate inline, in under 200ms.

  2. 02

    Bring your own fraud engine — or use the platform's

    topropay supports a partner-agnostic fraud-engine connector model: bring your own provider (Riskified, Forter, Signifyd, in-house) and feed its score into the routing engine, or ride the platform's built-in rules and velocity controls. Both compose; the merchant doesn't pick one over the other.

  3. 03

    Chargeback-aware routing as a fraud signal

    Chargeback ratio is a routing input, not a passive outcome. Segments most likely to dispute can route to acquirers with tighter chargeback bands, while clean segments route for cost. The fraud-controls layer feeds back into the routing engine on a continuous basis.

  4. 04

    One dispute and chargeback queue across acquirers

    Every dispute, regardless of which acquirer handled the original authorisation, lands in one queue with evidence-pack templates per vertical. Representment is automated for select scheme types; manual responses share a normalised UI; everything logs to the audit trail.

Five fraud-controls layers

The fraud prevention software layers that evaluate every authorisation

Each layer is configurable independently and composes into the composite risk score. Layer order in the path: velocity / lists run cheapest-first; partner-engine connectors and 3DS challenges run only when earlier layers leave it open.

  1. 01

    Velocity & rules

    Per-card, per-IP, per-device, per-email and per-billing-address velocity caps, plus declarative rules (BIN block, country block, MCC-specific patterns). Configurable from the dashboard; evaluated in under 10ms per authorisation.

  2. 02

    List management

    Block / allow / monitor lists across cards, BINs, IPs, devices, emails and shipping addresses. Lists sync into the authorisation path automatically; bulk import, expiry windows and per-list audit logs are first-class.

  3. 03

    3DS2 & SCA orchestration

    Selective 3DS2 / SCA challenges per transaction based on amount, BIN, country, merchant policy and risk score. PSD2-compliant in Europe without sending every shopper through a step-up; useful as a friction-injection tool outside Europe too.

  4. 04

    Partner fraud engines

    Connector model for Riskified, Forter, Signifyd, Sift, ClearSale and other partner fraud engines — scores feed into the routing engine and inform the cascade-vs-fail decision. Bring-your-own is supported; in-house scoring models slot into the same connector shape.

  5. 05

    Scheme programme tracking

    Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP thresholds tracked per acquirer relationship; the dashboard surfaces position vs limit with alerts before the merchant hits programme entry.

How it works

From authorisation arrival to a post-authorisation feedback loop

Five stages between an authorisation entering the platform and its outcome feeding back into the fraud-controls layer. The merchant configures policy; the platform handles the rest.

  1. 01

    Authorisation arrives

    Every card authorisation enters the platform with shopper, device, BIN, scheme, currency, country and amount context. The routing engine and the fraud-controls layer evaluate in parallel.

  2. 02

    Velocity, list, rule and partner-engine checks

    Velocity caps, lists, declarative rules and partner fraud-engine scores all evaluate inside the same authorisation path. Each control produces a verdict; the engine combines them into a composite risk score.

  3. 03

    Decision — clear, challenge, decline

    Based on the composite score and the merchant's policy thresholds, the engine clears the authorisation, requests a 3DS2 / SCA challenge, or declines outright. Borderline cases can route via the partner-engine connector for a final score.

  4. 04

    Authorise, cascade or decline

    Cleared authorisations run through the routing engine. Soft declines cascade to the next ranked acquirer inside the same request. Hard fraud declines do not cascade — they stop.

  5. 05

    Post-authorisation feedback loop

    Dispute outcomes, chargebacks and fraud signals feed back into the routing engine and the velocity / rules layer. The merchant's fraud posture improves on real outcomes, not vendor-supplied benchmarks.

Main use cases

Where merchant fraud prevention earns its keep

Six merchant shapes that stress the fraud-controls layer differently — DTC, subscriptions, marketplaces, travel, high-risk verticals and PSPs.

  • DTC

    Online retail with seasonal fraud spikes

    Black Friday and gift-card-redemption windows attract elevated card-testing and BIN-attack traffic. Velocity caps, BIN blocks and partner fraud-engine scoring absorb the spike without throttling legitimate traffic.

  • SaaS

    Subscriptions and SaaS with stolen-card risk

    Free-trial and first-charge flows are common targets for stolen-card testing. List management plus rule-based velocity caps on first-charge attempts cuts the noise without breaking conversion on legitimate sign-ups.

  • Mkt

    Marketplaces and digital-goods platforms

    Buyer-on-buyer fraud and reseller patterns appear in marketplace traffic. Per-tenant rules, behavioural-pattern detection and chargeback-evidence templates per seller help platforms hold the line without per-seller engineering.

  • Travel

    Travel and high-ticket bookings

    High-ticket bookings concentrate fraud risk. Selective 3DS2 challenges, partner-engine scoring and chargeback-aware routing tighten the policy for travel-specific patterns (large amounts, unfamiliar destinations, fast-turnaround tickets).

  • Risk

    Licensed high-risk verticals

    Verticals where chargeback bands are tighter (subscriptions, nutraceuticals, ticketing) benefit most from chargeback-aware routing fed by fraud signals. The fraud-controls layer and the routing engine work as one feedback loop.

  • Plat

    PSPs and ISVs managing many merchants

    PSPs need per-tenant fraud policies without rebuilding the rules engine per merchant. topropay's connector model lets a PSP define platform-wide defaults and per-tenant overrides, with per-tenant analytics in the operator portal.

Platform features

Capabilities behind the payment gateway fraud management surface

What the platform actually ships for the fraud-controls layer — the API contract, the engine primitives, the dispute queue and the operator portal.

  • Velocity & declarative rules

    Per-card, IP, device, email, address velocity caps; BIN / country / MCC rules; declarative DSL evaluated inline.

  • List management

    Block / allow / monitor lists across all the relevant identifiers, with bulk import, expiry and per-list audit logs.

  • 3DS2 & SCA orchestration

    Selective challenges per transaction; PSD2-compliant in Europe; tunable thresholds and exemptions per merchant policy.

  • Partner fraud-engine connector

    Riskified, Forter, Signifyd, Sift, ClearSale and other partner-engine connectors; in-house models slot into the same shape.

  • Composite scoring

    Velocity, lists, rules and partner-engine scores combine into a composite risk score that informs clear / challenge / decline.

  • Chargeback-aware routing

    Chargeback ratio feeds back into the routing engine; high-dispute segments route to acquirers with tighter chargeback bands.

  • Unified dispute queue

    Every dispute, regardless of acquirer, lands in one queue; evidence-pack templates per vertical; automated representment for select scheme types.

  • Scheme-programme tracking

    VDMP / VAMP / VFMP / ECP / EFMP thresholds tracked per acquirer with dashboard alerts before programme entry.

  • Tokenisation by default

    PCI DSS Level 1 vault keeps PAN out of merchant origin; vault tokens drive refunds, retries and recurring.

  • Signed event stream

    Signed, replay-safe webhooks for every state change — into your SIEM, warehouse or in-house tooling.

  • Operator portal

    One dashboard for fraud alerts, dispute queue, chargeback queue and post-authorisation analytics.

  • Sandbox parity

    Per-environment sandbox that mirrors production — including 3DS challenge / frictionless paths, declined-fraud scenarios and chargeback simulation.

Trust & compliance

Compliance posture for the fraud-controls layer

Fraud controls run through the same audited environment as the rest of the platform. Merchants inherit posture rather than carrying separate certifications per connected provider or per fraud engine.

PCI DSS Level 1
Annual on-site assessment plus quarterly ASV scans; sub-merchants inherit the posture for both authorisation and dispute-handling traffic.
SCA & PSD2
Selective 3DS2 on the authorisation path; PSD2-compliant in Europe without sending every shopper through a step-up.
Sanctions & AML alignment
Sanctions screening on onboarding; AML monitoring tuned per merchant vertical, volume and geography mix.
Scheme programme alignment
Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP thresholds tracked per merchant; dashboard alerts before programme entry.
Audit log
Operator actions, rule changes, list updates and dispute responses logged with actor identity, reason code and timestamp.
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 integration shape.

Ready to tighten controls

Run fraud prevention and detection inline with routing.

A 45-minute fraud-controls review walks through the rules and velocity policy that fit your traffic, the partner-engine connector that complements them, the 3DS / SCA thresholds for your markets, and a sandbox to test against.

Book a fraud-controls review Read the API docs

Frequently asked

Buyer questions about fraud prevention on topropay

Questions buyers ask before committing — the five-layer model, partner-engine integration, PSD2 SCA, payment gateway fraud-management surface and the dispute feedback loop.

  1. 01

    What does topropay mean by fraud prevention and detection?

    Fraud prevention and detection on topropay is the set of in-path controls that evaluate every card authorisation alongside the routing engine: velocity caps, list management, declarative rules, partner fraud-engine scores, 3DS2 / SCA challenges, scheme-programme tracking and the chargeback feedback loop. The merchant configures policy; the platform enforces it.

  2. 02

    What fraud prevention solutions does the platform expose?

    Fraud prevention solutions on the platform include the built-in rules and velocity engine, a partner-engine connector model (Riskified, Forter, Signifyd, Sift, ClearSale and others), 3DS2 / SCA orchestration, list management, scheme-programme tracking and the unified dispute / chargeback queue. They compose — most merchants use a combination.

  3. 03

    Is there fraud prevention software built into the orchestration layer?

    Yes — the fraud prevention software primitives (velocity engine, declarative rules DSL, list management, 3DS2 orchestration, partner-engine connector, composite scoring) are built into the orchestration layer rather than a separate product. The merchant doesn't buy a second tool; the controls evaluate in the same authorisation path as the routing engine.

  4. 04

    What fraud prevention tools are available out of the box?

    Fraud prevention tools include velocity caps (per-card, IP, device, email, address), list management (block / allow / monitor), declarative rules (BIN block, country block, MCC patterns), 3DS2 / SCA orchestration, partner fraud-engine connectors, composite scoring, scheme-programme tracking and a unified dispute / chargeback queue.

  5. 05

    How is payments fraud prevention different from generic fraud detection?

    Payments fraud prevention focuses on the authorisation path — preventing the bad transaction from clearing in the first place — and the post-authorisation dispute response that follows when one slips through. Generic fraud detection often runs after the fact. topropay's controls sit in the authorisation path so they affect the routing and clear / decline decision in real time.

  6. 06

    What payment fraud prevention solutions are typical for high-volume merchants?

    Payment fraud prevention solutions for high-volume merchants usually combine velocity caps and lists for cheap card-testing defence, a partner fraud engine (Riskified / Forter / Signifyd) for high-value approval decisions, selective 3DS2 for PSD2 markets, and chargeback-aware routing on the back-end. topropay supports all of those inside one configuration plane.

  7. 07

    How does online payment fraud surface in the authorisation flow?

    Online payment fraud surfaces as elevated velocity (many cards from one IP, many IPs against one card), BIN attacks (low-value tests against a BIN range), stolen-card use, friendly fraud (legitimate-looking transaction followed by a chargeback) and account-takeover. Each pattern has a distinct control profile inside the platform's fraud-controls layer.

  8. 08

    What's the platform's posture on payment gateway fraud specifically?

    Payment gateway fraud — fraud targeting the gateway authorisation path — is the primary thing topropay's controls layer addresses. The unified API, the vault and the routing engine all wrap the gateway surface; controls evaluate inside the same path the gateway runs on, before the authorisation reaches the connected acquirer.

  9. 09

    How does payment gateway fraud detection work in practice?

    Payment gateway fraud detection runs inline on every authorisation: velocity caps and lists check first (~10ms), declarative rules and partner-engine scores follow, the engine composes a risk score, and the merchant's policy thresholds decide between clear, challenge and decline. The decision lands inside the same authorisation request — no extra round-trip.

  10. 10

    What does payment gateway fraud prevention cover beyond detection?

    Payment gateway fraud prevention covers the policy side — what to do about the detected risk. That includes selective 3DS2 / SCA challenges, cascade-vs-fail decisions on soft declines, list updates from confirmed-fraud transactions, scheme-programme threshold tracking and the dispute / chargeback workflow that handles transactions that still slip through.

  11. 11

    Is payment gateway fraud management exposed in the dashboard?

    Yes. Payment gateway fraud management surfaces in the operator portal — per-rule analytics, per-list activity, partner-engine score distributions, 3DS challenge / frictionless rates, chargeback ratios per acquirer and per merchant segment. Operators tune the policy without needing a release.

  12. 12

    What does fraud prevention online payment look like for PSD2 markets specifically?

    Fraud prevention online payment in PSD2 markets means selective 3DS2 / SCA on the authorisation path. The merchant doesn't choose between 'always challenge' and 'never challenge' — the orchestrator applies the regulation's exemption logic per transaction (low-value, trusted-beneficiary, secure-corporate, transaction-risk-analysis) to challenge only when needed.

  13. 13

    How does online payment fraud prevention compose with the routing engine?

    Online payment fraud prevention composes with the routing engine through the composite risk score. The score informs whether to route, whether to challenge, whether to decline, and which acquirer to route to. High-risk segments route to acquirers with tighter chargeback bands; low-risk segments route for cost.

  14. 14

    What about digital payment fraud prevention for non-card rails?

    Digital payment fraud prevention extends beyond cards to bank rails (ACH, SEPA Direct Debit), wallets and (via partner gateways) crypto. Each rail has its own control profile — ACH R-code patterns, SEPA mandate-revocation rates, wallet-token anomalies, crypto-address screening. The platform exposes the controls in the same dashboard as card fraud.

  15. 15

    How does merchant fraud prevention differ from buyer fraud prevention?

    Merchant fraud prevention is the platform-side controls that protect against merchants who would misuse the platform (sanctions screening, MCC compliance, transaction-pattern monitoring). Buyer fraud prevention is the merchant-side controls (velocity, lists, partner engines, 3DS) that protect against buyers using stolen cards or running attacks. topropay handles both — the platform side as part of onboarding and ongoing AML, the merchant side as part of the in-path controls layer.

Related

Related on the topropay platform