Adobe Commerce development
Storefront design
Performance & SEO
AI & agentic commerce
Release tracker
Ecommerce fraud prevention works best as layers, not a single tool. Match each fraud type to the controls that actually stop it: bot defenses and rate limits for card testing, strong login security for account takeover, and clear return rules plus data for refund abuse. Then let your payment provider's risk engine do the scoring, and review its decisions every week.
This guide is for merchants and ecommerce managers who want a practical plan. It covers the main fraud types, a control table you can work through, what to set up in Adobe Commerce or Magento Open Source, and how to measure whether it is working.
The fraud types that matter most for online stores
Most losses come from a small number of patterns. Knowing which one you are facing tells you which control to reach for.
- Card testing: criminals use scripts to check whether stolen card numbers work, usually with many small payments or card-save attempts. Stripe's documentation lists the signs: a spike in failed or blocked payments and a spike in low-value payments with nonsense names and emails.
- Stolen-card purchases (true fraud): a real order paid with someone else's card. It ends in a chargeback weeks later, after the goods have shipped.
- Account takeover (ATO): an attacker logs in to a real customer's account with leaked or guessed credentials, then uses saved addresses, store credit, loyalty points or saved payment methods.
- Refund and return abuse: returning used, swapped or counterfeit items, claiming "item not received" for delivered parcels, or asking for refunds to a different card.
- Friendly fraud: a genuine customer disputes a purchase they made, sometimes by mistake (they do not recognize the billing descriptor) and sometimes on purpose.
- Promotion abuse: creating many accounts to reuse first-order coupons, or brute-forcing coupon codes.
Fraud type x control table
Use this table as a working checklist. The "first control" column is where most stores should start. The "signals" column tells you what to watch in your order and payment data.
| Fraud type | Signals to watch | First controls | Next layer |
|---|---|---|---|
| Card testing | Bursts of declines, many low-value orders, generic decline codes, odd names and emails, repeated attempts from one IP or device | CAPTCHA on checkout and place-order, rate limits per IP and session, provider's hosted payment fields | Velocity rules in your fraud tool, limits on cards per account, refund any suspicious payments that got through |
| Stolen-card purchases | Billing and shipping mismatch, freight forwarders, rush shipping on high-resale items, new account plus high order value | Provider risk scoring, AVS and CVV checks, 3D Secure where available | Manual review queue for high-risk orders, hold shipment until review |
| Account takeover | Logins from new devices or countries, password reset followed by address change, failed-login spikes | CAPTCHA on login and password reset, rate limiting, breached-password checks, alerts on email or address change | Step-up verification (one-time code) for sensitive changes, optional MFA or passkeys for customers |
| Refund and return abuse | Same customer with many refunds, refunds requested to a different card, "not received" claims on tracked deliveries | Refund only to the original payment method, signature or photo proof for high-value deliveries, clear written return policy | Customer-level refund history in the admin, inspection before refund for returned items |
| Friendly fraud and chargebacks | Disputes on delivered orders, unrecognized descriptor complaints | Clear billing descriptor, order confirmation and tracking emails, easy-to-find contact options | Store evidence (delivery proof, logs, emails) so you can respond to disputes quickly |
| Promotion abuse | Many new accounts sharing an address or device, coupon brute-force attempts | CAPTCHA on coupon entry and account creation, one-use or customer-bound codes | Limits per address or payment method, review of top coupon users |
No single line in this table is enough on its own. Stripe's guidance makes the same point: simple filters based on one signal, such as IP address, rarely stop card testing alone, so combine CAPTCHA, rate limits and provider rules.
Card testing: the attack most stores see first
Card testing hurts even when you never ship a thing. Successful test payments turn into disputes, a burst of declines can make issuers treat your store as riskier, and the extra traffic slows checkout for real shoppers. If an attack is happening right now, work through this short list:
- Confirm the pattern in your payment dashboard (declines, low amounts, odd customer details).
- Turn on or tighten CAPTCHA for checkout and order placement.
- Add rate limits at your CDN, web application firewall or load balancer for the payment and cart endpoints.
- Refund suspicious payments that succeeded, to reduce later disputes.
- Ask your payment provider which of their card testing protections are active on your integration. Many protections only work with their current hosted fields or payment elements.
- Keep watching for a week. Attackers often return after a pause.
Payment provider protections depend on the data you send them. Stripe notes that IP address, email, name and billing address all improve its models, so a custom or outdated payment integration can weaken protection without anyone noticing.
What to set up in Adobe Commerce and Magento Open Source
Adobe Commerce and Magento Open Source include Google reCAPTCHA support that you can enable per storefront location. According to Adobe's documentation, those locations include customer login, forgot password, account creation, checkout and placing an order, coupon codes, newsletter sign-up, contact forms and the Admin sign-in page. It supports reCAPTCHA v3 Invisible, v2 Invisible and the v2 checkbox.
A practical baseline for a Magento store:
- reCAPTCHA on login, account creation, password reset, checkout and coupon codes. Use the invisible variants where conversion matters and the checkbox where abuse is heavy.
- Hosted or embedded payment fields from your payment provider, so card data never touches your server and the provider's risk tools see the full session.
- Admin security: two-factor authentication for every Admin user, a non-default Admin URL, and removal of unused Admin accounts. A compromised Admin account is a fraud tool in itself.
- Edge protection: rate limits and bot rules at the CDN or WAF for login, cart, checkout and GraphQL or REST endpoints used by checkout.
- Order review workflow: an order status for "suspected fraud" or "on hold", plus a short internal rule for who reviews it and how fast.
- Patching: keep up with security patches. Our explainer on Magento security patches covers how they are released.
Fraud and security overlap. If you find unknown JavaScript on your checkout, unexpected Admin users or card data appearing in the wrong place, treat it as a breach, not a fraud problem. Our guide on what to do if your Magento store is hacked walks through the first 24 hours.
Protecting the payment page itself
Some fraud starts with stolen card data skimmed from a store's own checkout by malicious scripts. PCI DSS v4.x includes requirements 6.4.3 (managing scripts on payment pages) and 11.6.1 (detecting unauthorized changes to payment pages). PCI SSC later removed these two requirements from SAQ A, the shortest self-assessment questionnaire, and replaced them with an eligibility criterion: merchants with an embedded payment form must confirm their site is not susceptible to attacks from scripts that could affect their ecommerce systems. The requirements remain in the full standard.
In practice, that means you should know every script that loads on checkout, remove the ones you do not need, and monitor for changes. Confirm with your acquirer or payment provider which questionnaire applies to you. This is general information, not legal or compliance advice.
Measuring whether your controls work
Track a few numbers monthly, and review them after every change to rules or checkout:
- Chargeback rate (disputes divided by transactions), split by reason code.
- Authorization decline rate, and any sudden spike.
- Manual review rate and how many reviewed orders were genuine.
- False declines: legitimate customers blocked. Sample blocked orders and contact a few customers if you can.
- Refund rate by customer to find repeat abusers.
Clean data helps here. If your analytics count fraudulent test orders as revenue, your reports will look better than reality. Server-side events that only fire on confirmed, paid orders give a truer picture; see our guide to server-side tracking for ecommerce.
Balancing fraud control and conversion
Every control adds some friction. The aim is to put friction where the risk is, not on every shopper.
- Use invisible CAPTCHA by default and show a visible challenge only on risky sessions.
- Apply step-up checks (one-time codes, 3D Secure) to risky orders, not every order.
- Rate-limit by behavior (many attempts in minutes) rather than blocking whole countries.
- Write a short playbook for support staff on refund requests, so decisions are consistent.
FAQ
Do I need a separate fraud tool if my payment provider has one?
Often not at first. Most providers include risk scoring and rules. Add a dedicated tool when you sell high-resale goods, see heavy manual review, or need rules across several payment methods.
Does 3D Secure stop all fraud?
No. It adds issuer authentication and can shift liability for some fraud chargebacks, depending on the scheme and region, but it does not stop account takeover, refund abuse or card testing on endpoints that skip it.
Should I block orders from certain countries?
Broad country blocks lose real customers. Use behavior and order signals first, and restrict only specific high-risk combinations you can see in your own data.
Next steps
Start with the table above: enable reCAPTCHA in the right places, check your payment integration is current, and set a monthly review of chargebacks and declines. If you want help configuring these controls or monitoring a Magento store, Mistri's Magento support and maintenance service covers security patching, monitoring and fixes.
Sources: Stripe: Protect yourself from card testing; Adobe Experience League: Google reCAPTCHA; PCI SSC: FAQ clarifies new SAQ A eligibility criteria.
