Incident Response During a Fraud Attack

A fraud attack rarely announces itself politely. One minute your dashboard is quiet, the next you have 340 orders in twenty minutes, a wall of declines, and a processor email threatening to review your account. The stores that come out of this intact are not the ones with the best luck. They are the ones with a plan they can run under pressure.

This is that plan. Treat it as a runbook you can open mid-incident and follow line by line.

Phase 1: Detect

Most fraud attacks look like one of two patterns. Card testing is a flood of small orders as attackers validate stolen card numbers against your checkout. Bot-driven fraud is automated ordering at scale, often targeting high-resale items or exploiting a discount.

Signs you are under attack right now:

• A spike in authorization declines far above your baseline. A store that normally sees 3-5% declines suddenly seeing 40% is the clearest tell.
• Many small orders in minutes, often identical amounts, sometimes as low as $1-2.
• Repeated card attempts from similar email patterns (random strings, plus-addressing, disposable domains).
• A single IP or narrow IP range driving dozens of checkouts.
• Processor or gateway alerts about unusual authorization volume.

Confirm before you act. Open your Shopify orders filtered by the last hour, sort by time, and look for clustering. Two suspicious orders is noise. Forty in fifteen minutes is an incident.

Phase 2: Contain

Your first goal is to stop the bleeding, not to investigate. Investigation comes later.

Contain checklist:

1. Enable extra checkout friction. Turn on reCAPTCHA or Shopify's checkout verification if it is not already active. This alone breaks most unsophisticated bots.
2. Throttle or pause risky payment paths. If card testing is hammering a specific gateway, consider temporarily disabling accelerated checkouts (one-click wallets) that skip friction.
3. Reduce the attack surface. If a specific discount code is being abused, deactivate it immediately. If a product is being targeted, set its inventory to a low buffer or unpublish it briefly.
4. Cancel and void, do not fulfill. Do not fulfill or refund in a rush. Cancel suspicious orders and void the authorization so no capture occurs. Refunding a fraudulent capture can cost you the item and the fee.
5. Notify your payment processor. A short message that you are aware and containing an attack buys goodwill and may prevent an automatic account hold.

Containment is about buying time. It does not need to be elegant.

Phase 3: Block

Now you move from stopping the flood to closing the door. This is where automated rules earn their keep, because you cannot manually block faster than a bot can order.

What to block, in priority order:

• Offending IP addresses and ranges. Pull the IPs from your recent fraudulent orders and block them at the app or firewall level.
• Email patterns. Disposable domains and obvious throwaway addresses (long random local parts) should be denied at checkout.
• Geographies you do not serve. If you only ship to three countries, block the rest during the incident.
• Velocity thresholds. Cap how many orders a single customer, card, or device can place in a short window.

This is exactly the work a fraud filter is built to do automatically. Shieldy — Fraud Filter lets you set IP, country, email, and velocity rules that block abusive checkouts before they ever become an order, so you are not copying IP addresses into a blocklist by hand while the attack is still running. Setting those rules up before an incident is ideal, but even mid-attack the payoff is immediate.

A quick note on blocking scope: prefer narrow, reversible rules. A country block during a two-hour attack is fine. A permanent block on a country where you have real customers is a self-inflicted revenue wound. Write down every rule you add so you can review and relax it later.

Phase 4: Review

Once the flood slows and your declines return toward baseline, the incident is not over. It is in review.

Immediate review (same day):

• Reconcile every suspicious order. Confirm each was voided or cancelled, not captured. Flag anything that slipped through for chargeback monitoring.
• Check what got through. Some legitimate-looking fraud may have passed. Hold fulfillment on borderline orders for manual verification (phone, address confirmation).
• Screenshot the evidence. Order timestamps, IP clusters, and decline logs are useful for your processor and for your own records.

Follow-up review (within a week):

• Watch for chargebacks. Card-testing victims file disputes days later. Tag affected orders so you can respond fast with evidence.
• Relax temporary rules. Turn off the emergency country blocks and discount pauses you no longer need, but keep the durable ones (velocity caps, disposable-email blocks).
• Write a short post-mortem. What was the entry point, how long until you noticed, what worked, what did not. This is how the next incident becomes a ten-minute event instead of a two-hour crisis.

A one-page incident summary

Keep this where your team can reach it:

• Detect: Spike in declines or small orders in minutes from narrow IPs. Confirm by clustering in the orders view.
• Contain: Add checkout friction, pause abused codes, cancel and void (do not refund), notify your processor.
• Block: IPs, disposable emails, off-market geographies, velocity caps. Narrow and reversible.
• Review: Reconcile orders, hold borderline fulfillments, watch chargebacks, relax temporary rules, write the post-mortem.

The difference between a scary story and a footnote is preparation. Configure your velocity, geography, and email rules while things are calm, decide who owns the runbook, and rehearse the containment steps once. When the real attack comes, you will already know exactly what to do.

If you want those blocking rules standing guard before the next spike, set up Shieldy and let the automated filters absorb the first wave for you.