OrderGateTürkçe
All guides

Card testing at Shopify checkout: what actually helps

Checkout rules are the wrong primary tool for card testing. A script rotates card numbers, email addresses and often IP addresses, so static rules match yesterday's attempt rather than today's. Shopify's own fraud analysis and payment-provider controls do most of the work here; rules help against the narrower case of a repeat human abuser.

What card testing actually is

Card testing is a script validating stolen card numbers by making small purchases somewhere that will accept them. Your store is not the target; it is the instrument. The tell is a burst of low-value attempts with a high decline rate, often on a single cheap product.

The important property, for anyone reaching for a blocking rule, is that the attacker controls every field a rule could match: card, email address, name, and in most cases the source address too.

Why checkout rules are a weak answer here

A checkout validation function sees the cart: the buyer's email, the delivery address, whether a signed-in customer carries a tag. Against a rotating script, blocking an email address is obsolete by the next request.

There is also no IP address in the function input and functions have no network access, so nothing evaluated inside checkout can rate-limit by network origin. An app advertising IP blocking is doing it in the storefront layer, which does not survive a script talking to checkout directly.

What does help

  • Your payment provider's controls are the front line: decline-rate limits, velocity rules and 3D Secure make the store useless as a testing instrument, which is what makes the traffic go elsewhere.
  • Shopify's built-in fraud analysis flags high-risk orders after the fact, and Fraud Control checkout rules can block earlier — though the Help Center documents those as available only to stores using Shopify Payments.
  • Removing whatever made your store attractive: a very cheap product, no rate limit on discount codes, or a public storefront with no bot protection at the edge.
  • Cloudflare or similar bot management in front of the storefront, which acts on the request before checkout is reached.

Where rules genuinely earn their place

Rules are for the case card testing is usually confused with: a specific person who keeps coming back. Serial refunders, chargeback repeat offenders, a competitor placing fake orders, a region you no longer ship to. That behaviour is human, low volume, and identifiable — and a rule against a domain or a location holds for months rather than seconds.

It is worth being clear which problem you have before choosing a tool. A burst of hundreds of declines in an hour is card testing and is a payment and edge problem. Three refused deliveries from the same street over two months is a rules problem.

OrderGate log-only mode reporting how many recent orders the rules would have blocked.
Log-only mode reporting what rules would have stopped, on a demo store — the counts are sample data.

What OrderGate claims, and what it does not

OrderGate blocks buyers matching merchant-defined rules inside checkout validation. It does not stop bots, cannot see an IP address, and is not a card-testing defence. Any app in this category promising otherwise is describing something happening in a different layer.