Layered defence · one platform

Payment fraud protection — four layers inside one authorisation.

Pre-auth scoring, selective 3DS2, PCI L1 vault tokens and dispute-side representment don't sit next to each other on topropay — they sit on top of each other on the same authorisation path. Four layers, one integration, one reconciliation feed.

4-layer
defence-in-depth across the auth path
PCI L1
vault inherited by every merchant
3DS2
selective step-up on the auth path
1 queue
for disputes across every acquirer

Key benefits

Why fraud protection tools work better inside the auth path

Four properties that show up the moment fraud defence stops being a separate stack bolted onto the payment platform.

  1. Defence in depth, not one silver bullet

    Fraud vectors don't all look alike. Card-not-present fraud, account takeover, refund abuse and synthetic identity each need a different layer of the stack. topropay layers pre-auth scoring, SCA orchestration, vault tokenisation and dispute-side representment so the merchant doesn't stitch four tools together.

  2. Fraud controls per merchant, not one policy

    Velocity rules, list management, geographic gates and step-up thresholds are configurable per merchant and per BIN range. A SaaS billing merchant runs a different profile from a travel merchant; both share the same underlying platform without the profiles bleeding into each other.

  3. Partner-agnostic fraud engine connectors

    Bring your existing fraud engine (Kount, Sift, Signifyd, Riskified) or use the platform's default signals. Either way the score feeds into the routing engine, which cascades on soft decline and holds high-risk traffic for step-up authentication.

  4. Dispute-side representment tied to the vault

    Every chargeback lands in a unified dispute queue with evidence-pack templates per vertical. Vault-token-based receipts, 3DS2 authentication logs, delivery evidence and buyer identity all bundle into the representment automatically.

How payment fraud protection software runs

Four stages inside a single authorisation call

What happens between the buyer hitting pay and finance seeing a settled row — with each fraud layer in its actual position on the path.

  1. 01

    Signals collected pre-auth

    Device fingerprint, BIN metadata, geo, velocity across the merchant and — where consented — across the wider platform inform a score before the authorisation is sent to any acquirer.

  2. 02

    Routing decides who takes it

    The routing engine ranks connected acquirers on BIN, currency, country pair, risk score and dispute-programme position. Trusted traffic clears fast; risky traffic is held or step-up-authenticated.

  3. 03

    3DS2 step-up where warranted

    Selective EMV 3DS2 fires per PSD2 exemption logic and per-issuer behaviour. Frictionless flows pass through; high-risk authorisations get challenged.

  4. 04

    Post-auth: vault, refund controls, disputes

    PCI L1 vault holds only tokens, not PANs. Operator-side refund controls require justification. Chargebacks land in one dispute queue with evidence-pack automation.

Fraud vectors

Six vectors, one payment fraud protection platform

Six recurring fraud vectors and how each layer of the stack addresses them. Fraud isn't one shape; the defences shouldn't be either.

Card-not-present (CNP) fraud
Stolen credentials used in an online transaction. Vault + selective 3DS2 + per-BIN velocity rules + list management defend across the stack.
Friendly / first-party fraud
Cardholder disputes a legitimate charge. Unified dispute queue + evidence-pack templates + vault-token-based receipts drive representment.
Account takeover (ATO)
Attacker takes over a customer's account. Device fingerprinting + step-up authentication + velocity anomalies catch it.
Refund / triangulation fraud
Refund flow abused as a money-out channel. Operator-side refund controls + justification + audit log limit exposure.
Synthetic-identity fraud
Fabricated identity used to onboard. KYB / KYC + sanctions screening at platform level filter at onboarding.
Chargeback ratio abuse
Excess chargebacks pushing scheme-programme thresholds. Per-acquirer position dashboard + routing rotation + Ethoca / Verifi alerts.

Main use cases

Where online payment fraud protection earns its keep

Six recurring merchant shapes and the fraud pressure they face — SaaS friendly fraud, travel chargebacks, DTC CNP, marketplace ATO, high-risk verticals under scheme pressure, and B2B refund abuse.

  • Sub

    SaaS subscriptions defending against friendly fraud

    Recurring SaaS is the vertical hardest hit by 'friendly fraud' — cardholders disputing legitimate renewals. Evidence-pack templates surface the T&Cs acknowledgement, prior successful renewals and account activity logs for representment.

  • Trvl

    Travel and ticketing under chargeback pressure

    Travel merchants face high dispute volumes tied to booking issues and delivery timing. Chargeback ratios must stay under scheme-programme thresholds; per-acquirer position surfaces in the dashboard for routing weight rotation.

  • DTC

    DTC e-commerce filtering CNP fraud

    DTC brands need CNP fraud filtering that doesn't kill approval. Pre-auth velocity rules and list management filter obvious attacks; selective 3DS2 catches suspicious traffic; the rest passes through frictionless.

  • Plat

    Marketplaces detecting account takeover

    Marketplaces are a frequent target for account takeover (ATO). Device-fingerprinting signals feed the routing engine; step-up authentication intercepts high-risk authorisations on hijacked accounts.

  • HiRk

    Licensed high-risk verticals with scheme pressure

    Licensed high-risk merchants (subscriptions, travel, ticketing, licensed gaming) run against Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP programme thresholds. Position vs limit surfaces per acquirer so routing weights can rotate.

  • B2B

    B2B merchants defending against refund abuse

    B2B refund abuse — refund flows used as money-out channels — is caught by operator-side refund controls requiring justification, reason codes, actor ID and timestamp on every refund event.

Platform features

Capabilities behind this payment fraud protection platform

Twelve capabilities the platform ships once and reuses across every merchant — the primitives every layer of the stack draws on.

  • Pre-auth risk scoring

    Device, BIN, geo, velocity, list hits and issuer patterns rolled into a score before any acquirer sees the auth.

  • Velocity rules

    Per-BIN, per-IP, per-device and per-email velocity caps configurable per merchant.

  • List management

    Allow / deny lists on card BINs, emails, devices and IP ranges — merchant-side and platform-side layered.

  • 3DS2 / SCA orchestration

    Selective EMV 3DS2 challenges per authorisation; PSD2 exemption logic; Visa Secure / Mastercard Identity Check flows.

  • Network tokens & updaters

    Network tokens (VTS, MDES) reduce PAN exposure; scheme updaters keep saved credentials alive without reissuance friction.

  • PCI DSS Level 1 vault

    Card data captures into the platform vault; PAN never lands in merchant systems; refunds and recurring run on the vault token.

  • Partner fraud-engine connectors

    Bring Kount, Sift, Signifyd, Riskified or others; the score feeds into the routing engine as another signal.

  • Operator-side refund controls

    Refunds require justification; every refund event logged with actor identity, reason code, IP and timestamp.

  • Unified dispute queue

    One queue across every connected acquirer; evidence-pack templates per vertical; automated representment for select scheme types.

  • Scheme-programme posture

    Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP positions surfaced per acquirer for routing-weight rotation.

  • Chargeback alerts (Ethoca / Verifi)

    Where merchants opt in, chargeback-alert programmes intercept disputes before they become chargebacks and offer refund resolution.

  • Audit-grade event log

    Every fraud-relevant event — score changes, step-up decisions, refunds, dispute state transitions — logged with actor, timestamp and reason for audit.

Trust & compliance

Compliance posture behind the fraud-defence stack

One audited environment; scheme programmes surfaced per connected acquirer; sub-merchants inherit posture without carrying separate certifications.

PCI DSS Level 1
Annual on-site assessment and quarterly ASV scans; sub-merchants inherit the posture across every connected provider.
SCA & PSD2
Selective EMV 3DS2 on the authorisation path keeps European approval high without skipping the SCA bar.
Scheme programmes
Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP positions surfaced per connected acquirer; routing weights can rotate around at-risk lanes.
Sanctions & AML alignment
Sanctions screening on onboarding; AML monitoring tuned per merchant vertical, volume and country mix.
Audit-grade evidence retention
Fraud-relevant events retained per merchant and per scheme rules to support disputes and regulator queries.
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 posture.

Ready to tighten the stack

Bring fraud defence inside the auth path.

A 30-minute fraud-posture review covers the vectors relevant to your vertical, the layers configured for your current traffic, and a sandbox to test against before any commercial commitment.

Frequently asked

Buyer questions about payment fraud protection on topropay

Definitions, integration mechanics, fraud-vector coverage, chargeback-alert programmes and the practicalities of running defence in depth on one platform.

  1. 01

    What does payment fraud protection cover on topropay?

    Payment fraud protection on topropay is a layered defence-in-depth stack: pre-auth scoring, selective EMV 3DS2 / SCA orchestration, PCI DSS Level 1 vault tokenisation, operator-side refund controls, and unified dispute-side representment. The layers work together on the same authorisation path rather than as separate tools stitched together.

  2. 02

    What fraud protection tools does the platform ship out of the box?

    Fraud protection tools shipped out of the box include pre-auth risk scoring, velocity rules, list management (allow / deny), selective 3DS2 orchestration, network-token tokenisation (VTS, MDES), operator-side refund controls with justification and audit log, and a unified dispute queue with evidence-pack templates per vertical. Additional partner fraud-engine connectors (Kount, Sift, Signifyd, Riskified) can be added as extra signals.

  3. 03

    How does payment fraud protection software on the platform differ from a standalone fraud engine?

    Payment fraud protection software on the platform is embedded in the authorisation path rather than sitting alongside it. A standalone fraud engine typically returns a score to the merchant's back-end and lets the merchant decide what to do. topropay ingests the score as another routing-engine signal, cascades on soft decline, and step-up-authenticates high-risk authorisations — all inside the same authorisation call to the buyer.

  4. 04

    Is topropay a full payment fraud protection platform or just a payments platform with fraud features?

    topropay is a payments orchestration platform with fraud defence integrated into every layer — that's the honest framing. Merchants who want a full standalone fraud protection platform typically layer one on top; the platform's partner-agnostic fraud-engine connectors make that easy. Most mainstream merchants find the built-in layers sufficient; high-risk merchants often add a partner engine for scoring depth.

  5. 05

    What online payment fraud protection is available on the checkout side specifically?

    Online payment fraud protection on the checkout side covers device fingerprinting at the surface, selective EMV 3DS2 on the authorisation path, per-BIN velocity rules, IP and email list checks, and the PCI L1 vault that ensures PAN data never lands in the merchant's own systems. The routing engine cascades on soft decline so the buyer sees one decision, not a retry-and-fail-twice loop.

  6. 06

    Does the platform defend against friendly / first-party fraud?

    Yes. Friendly fraud (cardholders disputing legitimate charges) is defended on the dispute side. The unified dispute queue exposes evidence-pack templates per vertical that pre-fill vault-token-based receipts, 3DS2 authentication logs, delivery evidence and buyer identity, so representment is a routine step rather than a per-case research project.

  7. 07

    How does the platform defend against account takeover (ATO)?

    Account takeover defence combines device-fingerprinting signals in the routing engine, step-up authentication (selective 3DS2) on high-risk authorisations, and velocity anomaly detection at the platform level. Merchants who bring a partner fraud engine layer additional identity signals on top.

  8. 08

    What about refund fraud on the operator side?

    Operator-side refund fraud (refund flows used as money-out channels) is defended by requiring justification, reason codes, actor identity and timestamp on every refund event. The audit-grade event log surfaces refund patterns per operator, per merchant and per counterparty for review.

  9. 09

    Can the merchant configure velocity rules and lists themselves?

    Yes. Velocity rules (per-BIN, per-IP, per-device, per-email) and list management (allow / deny lists on BINs, emails, devices, IPs) are dashboard-configurable per merchant. Changes take effect on the next authorisation; no code changes needed.

  10. 10

    How does chargeback ratio management work?

    Chargeback ratio management surfaces the merchant's position vs Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP programme thresholds per connected acquirer in the dashboard. If a specific acquirer's position approaches a threshold, routing weights can be rotated to shift volume to a healthier lane while the underlying dispute drivers are addressed.

  11. 11

    Does the platform support chargeback-alert programmes (Ethoca, Verifi)?

    Yes. Where the merchant opts in, chargeback-alert programmes (Ethoca / CDRN via Verifi) intercept disputes before they become chargebacks, offering the merchant a chance to refund resolution and keep the chargeback off the ratio. Alerts flow into the same dispute queue as native scheme chargebacks.

  12. 12

    How does the platform handle 3DS2 step-up decisions?

    3DS2 step-up decisions run selectively based on PSD2 exemption logic (low-value, TRA, MIT, one-leg-out), per-issuer behaviour and the pre-auth risk score. Frictionless flows pass through; step-up fires only where scheme rules require it or where the risk score justifies it — keeping approval rates high while satisfying the SCA bar.

  13. 13

    Is fraud protection different for high-risk merchants?

    Fraud protection posture for licensed high-risk merchants is tuned differently. Velocity caps are typically tighter, list management is more active, per-BIN scoring is more aggressive, and chargeback-alert programmes are recommended. The underlying platform is the same; the configuration is tuned per merchant profile.

  14. 14

    What happens when a partner fraud engine returns a hard decline?

    When a partner fraud engine (Kount, Sift, Signifyd, Riskified) returns a hard decline, the authorisation is blocked pre-acquirer — no scheme messages are sent. The event is logged with the engine's score and reason code. Soft declines from the fraud engine feed into the routing engine as another ranking signal and can trigger step-up authentication.

  15. 15

    Where is payment fraud protection available?

    Payment fraud protection is available across every geography topropay's connected acquirer panel supports — EU, UK, APAC and LATAM as a baseline. Some layers (like 3DS2 / SCA) are region-specific by scheme rule; others (like vault tokenisation and dispute queue) are global.