Checkout fraud, payment abuse, and bot defenses in Magento 2

Part 6 of the Magento 2 security series — implementation-focused, drawn from real incident response (project names withheld). The overview is at /blog/magento2-security.

The revenue path is the target

Everything upstream — CSP, 2FA, dependencies, APIs — protects the store. This post protects the money: the checkout and the traffic around it. Fraud here is not theoretical; card-testing bots and scrapers hit every public store daily, and the cost shows up as chargebacks, processor fees, and wasted fulfillment.

Card testing and stolen-card orders

Attackers rent botnets to test stolen card numbers against your checkout in high volume. Signs: a spike in failed authorizations, many orders from one IP/range, mismatched AVS/CVV where the order still "succeeds" at the gateway but fails later.

Defenses that actually work:

• Enable CVV and AVS in the payment method. Reject on mismatch rather than shipping first and discovering later.
• Velocity limits. Cap attempts per IP and per account; legitimate buyers do not try twenty cards in a minute.
• Risk scoring / 3DS. Step-up authentication (3-D Secure) for suspicious sessions stops most card testing without blocking good customers.
• Order hold rules. Auto-hold orders from new accounts with high-value, ship-fast items until reviewed.

The pattern from incidents: stores that added velocity limits + 3DS saw card-testing traffic drop to near zero within a day, because the bots moved on to softer targets.

Scraping and inventory bots

Public endpoints — product pages, price, and availability — are scraped for competitor pricing and stock levels, and sometimes to hoard limited inventory. This is not a data breach but it costs bandwidth and distorts analytics.

• Edge rate limiting on catalog and search routes, tuned so real shoppers are unaffected.
• Bot management / WAF rules for known bad ASN and aggressive user agents.
• Cache aggressively so scrapers hit cached HTML, not the app server.

Layering, not a single tool

No single control is enough. The stores that stay clean combine:

1. Built-in: CVV/AVS, admin order holds, Magento's own throttling.
2. Edge: WAF + rate limiting + bot rules at the CDN.
3. Processor-side: 3DS and the gateway's own fraud scoring.

Each layer catches what the others miss. The goal is not zero fraud (impossible) but predictable, low fraud cost.

A fraud-defense checklist

• CVV and AVS enforced; mismatches rejected, not shipped.
• Velocity limits on checkout attempts per IP/account.
• 3DS step-up for high-risk sessions.
• Edge rate limiting on catalog/search and checkout.
• Monitoring alert on authorization-failure spikes.

Closing the series

This series moved from the browser surface (CSP) to the people (2FA), the code (dependencies), the interfaces (API), and finally the money (fraud). Security in Magento is not one control but a stack of them, each covering the gap the last one leaves. Start with the overview, then harden in the order of risk: admin access first, then dependencies, then the edges.

This was the final post in the Magento 2 security series.