# Survive a fraud attack on your store
Source: https://paymentsandrisk.com/docs/playbooks/survive-fraud-attack

Last updated 23 October 2026.

TL;DR

-   Bots keep trying cards? Start with your platform below.
-   CAPTCHA hasn't stopped it? Check the payment route too.
-   Save example IDs and timestamps for your provider.
-   Check which events you're actually being billed for.
-   A Stripe secret key leaked? Use the [key-response steps](https://paymentsandrisk.com/docs/playbooks/survive-fraud-attack/#stripe-key-leaked).

Your checkout's filling with failed payments and fake orders. You can start with one support case, even if you're working alone. Find the payment route your provider sees. Ask them to contain it, then check payments and costs.

Where to go next

-   [Should I ship one Shopify order?](https://paymentsandrisk.com/docs/playbooks/shopify-first-week/#should-i-fulfill-this-order)
-   [What does card testing look like?](https://paymentsandrisk.com/docs/fraud/types/card-testing/)
-   [Which payment state needs cleanup?](https://paymentsandrisk.com/docs/chargebacks/refund-strategy/#which-state-are-you-in)

## Bots keep trying cards. What should I do first?

Save a few order, payment or request IDs. Include timestamps, the time zone and the first observed attempt. Add your provider, account and store location. If you're using a plugin, record its name and version. Keep secret values and customer card data out.

Ask the provider to distinguish payments from saved-card requests. Stripe documents attacks against both actions. VENDOR [Stripe card-testing guide](https://docs.stripe.com/disputes/prevention/card-testing).

Send this through the provider's support channel:

> We're seeing repeated attempts from \[time and time zone\]. Here are example IDs and the affected payment route. Please confirm what you can contain on our account. Which changes need our developer, and when should we check again?

Review suspicious successful orders separately from the attempt flood. If you're on Shopify, use the [order-review steps](https://paymentsandrisk.com/docs/playbooks/shopify-first-week/#should-i-fulfill-this-order). For suspected secret-key exposure, go straight to [key response](https://paymentsandrisk.com/docs/playbooks/survive-fraud-attack/#stripe-key-leaked).

### Which route fits your platform?

Use the handoff below to find your next step. Confirm your plan, permissions and region against the [processor settings guide](https://paymentsandrisk.com/docs/fraud/processor-rules-configuration/). Agree how you'll undo a rule before installing it.

| Your setup | Supported starting point and boundary |
| --- | --- |
| Stripe Checkout or Payment Element | Open the example payment's details and block reason. Give the developer Stripe's integration-specific card-testing guide. VENDOR [Stripe](https://docs.stripe.com/disputes/prevention/card-testing). |
| Shopify | Use the [order-review section](https://paymentsandrisk.com/docs/playbooks/shopify-first-week/#should-i-fulfill-this-order) for orders. Send attempt IDs and times to Shopify Support separately. |
| Square online payments, US help | **Payments & invoices > Risk Manager** is the documented entry. Owner or Risk Manager permissions are required. VENDOR [Square](https://squareup.com/help/us/en/article/6816-navigating-square-risk-manager). |
| WooCommerce PayPal Payments | Use this plugin's [official CAPTCHA setup](https://woocommerce.com/document/woocommerce-paypal-payments/fraud-and-disputes/). It requires version 3.3.0 or newer and both v2/v3 key sets. Its path is **WooCommerce > Settings > Integration > WooCommerce PayPal Payments reCAPTCHA**. It covers PayPal endpoints, not every gateway. VENDOR [WooCommerce](https://woocommerce.com/document/woocommerce-paypal-payments/fraud-and-disputes/). |
| Another WooCommerce gateway | Name the installed plugin and version in the support case. Ask its publisher for the supported containment path. Use that plugin's own instructions. |
| Another platform or an unavailable menu | Send the common incident script to your provider. Ask which controls your account actually supports. No guessed menu is needed to open the case. |

For PayPal Payments plugin help, Woo documents **Get Support > Technical support > PayPal Payments**. Its request needs a system status report. Send a redacted report privately through the verified support channel. VENDOR [WooCommerce help requirements](https://woocommerce.com/document/woocommerce-paypal-payments/fraud-and-disputes/#get-help).

Got two active or legacy gateways? Before disabling either, ask your integration owner which route received the attempts and who owns the test and rollback. Test legitimate checkout and any saved-payment use in staging first.

## CAPTCHA hasn't stopped it. Where are requests going?

Ask your developer to trace the protected action. Stripe requires server-side challenge checks on relevant payment requests. Include any path that saves or validates cards. A visible challenge alone doesn't establish that coverage. VENDOR [Stripe CAPTCHA implementation](https://docs.stripe.com/disputes/prevention/card-testing).

Hand over this question:

> Which endpoint receives the attempts, and which plugin handles it? Does the server reject an invalid or absent challenge? Please test the payment and saved-card routes we actually use. Show the rejection before the protected action, with a rollback.

If you're using hosted checkout, send that question to the platform. Ask which server controls it can check for you. Keep detailed rules with the [processor settings owner](https://paymentsandrisk.com/docs/fraud/processor-rules-configuration/).

## What am I being charged for?

Ask for the invoice lines covering the incident window. Stripe documents authorization fees on custom pricing and dispute fees. That isn't a fee claim about every failed attempt. VENDOR [Stripe card-testing consequences](https://docs.stripe.com/disputes/prevention/card-testing).

Google's linked billing guide covers Google Cloud Fraud Defense. Check the actual product, project and organization behind your invoice. VENDOR [Google billing guide](https://docs.cloud.google.com/recaptcha/docs/billing-information).

Stripe's US pay-as-you-go Radar offer starts at **US$0.05 per screened transaction**. Radar Lite includes card-testing prevention at no extra charge for businesses on standard payments pricing. Check which product and plan you're actually using before applying either statement to your bill. VENDOR [Stripe pricing](https://stripe.com/pricing), [Radar pricing](https://stripe.com/radar/pricing).

Use this worksheet without inventing a rate:

| Record | Ask for this |
| --- | --- |
| Payment authorization | Billable event, contract, counted attempts and exclusions |
| Fraud screening | Screened event, plan, allowance and overage line |
| CAPTCHA | Provider, project, assessment volume and billing period |
| Captured payments and disputes | Principal movements and fees on separate lines |
| Adjustments | Fixed charges, credits, currency and written explanation |

> Please itemize charges during \[window\] for this account. Which failed, blocked or uncaptured events were billable? Show the event count, rate, exclusions and any credits. Can you review the incident for a credit?

Keep an unanswered price marked unknown, rather than zero. Save the invoice and response with your incident log, then take that record into the [vendor selection guide](https://paymentsandrisk.com/docs/fraud/vendors/selection-guide/) when reviewing paid screening. This worksheet only collects the incident's events and charges.

## My Stripe secret key leaked. What now?

An exposed secret or restricted key needs prompt rotation. Act even if you're unsure anybody saw it. Stripe treats that exposure as a potential compromise. VENDOR [Stripe key security](https://docs.stripe.com/keys-best-practices).

First identify the key type, account and operating mode. Publishable keys are designed for client-side use. Webhook signing secrets are separate from API keys. Check the type before treating a public identifier as a secret. VENDOR [Stripe key types](https://docs.stripe.com/keys).

Get your integration owner involved now. Follow Stripe's compromised-key sequence:

1.  Open **Developers > API keys** and find the affected key.
2.  Open its menu and choose **Rotate key**.
3.  Choose an expiry that allows testing the replacement.
4.  Update the backend through your secure deployment process.
5.  Confirm the integration works using the replacement key.
6.  Delete the compromised key after that confirmation.

Stripe's incident guide documents that order and immediate deletion. VENDOR [compromised API keys](https://support.stripe.com/questions/protecting-against-compromised-api-keys).

Choosing **Now** during rotation deletes the old key immediately. Callers still using it can lose access. A later expiry leaves the old key valid until revocation. Have the owner manage that tradeoff urgently with Stripe. Keep that exposure window as short as your incident response allows. VENDOR [Stripe rotation and expiry](https://docs.stripe.com/keys).

For a hosting-managed key, follow its supported rotation process and confirm the running application picked up the replacement. Ask the hosting provider how it supplies and rotates your managed key. VENDOR [managed keys](https://docs.stripe.com/keys-best-practices#managed-api-keys).

Then open the affected key's menu and **View request logs**. It opens Workbench. Review requests since the suspected exposure. VENDOR [Stripe request logs](https://docs.stripe.com/keys#view-request-logs).

Record unexplained activity and ask Stripe to investigate it. Fix the exposure source before calling the incident closed. If the replacement was exposed through the same flaw, rotate again. Stripe's guide also calls for reviewing other exposed credentials. VENDOR [compromised API keys](https://support.stripe.com/questions/protecting-against-compromised-api-keys).

> A Stripe credential was exposed at \[location and time\]. Please help contain access and review activity since exposure. Our integration owner is \[name\]. We'll share identifiers and request IDs, never the secret value.

Keep the key value out of support messages. Stripe says it'll never ask for your secret key. VENDOR [key-handling guidance](https://docs.stripe.com/keys-best-practices).

**Connect platforms:** use Stripe's [Connect-specific remediation](https://support.stripe.com/questions/protecting-against-compromised-api-keys) with your platform incident owner. Its connected-account and payout actions aren't a single-shop checklist. Stripe doesn't guarantee payout reversal.

### Can I reopen the affected checkout?

Ask the owner to record what changed and when, comparing the same route and time zone before and after. A smaller order count isn't the only check. Confirm legitimate checkout still works before relaxing changes gradually.

You're rebuilding the payment integration? [Review it before relaunch](https://paymentsandrisk.com/docs/playbooks/stripe-first-week/#ai-built-checkout-review).

For successful suspicious payments, use the [payment-state guide](https://paymentsandrisk.com/docs/chargebacks/refund-strategy/#which-state-are-you-in). Check captured, pending, refunded and disputed records before choosing an action. Choose each cleanup action from that guide, using the actual payment state.

Scale Callout

| Your setup | Next action |
| --- | --- |
| Solo shop on hosted checkout | Open one provider case and name the next check time. |
| Plugin shop with an agency | Give the agency the route, plugin version and test handoff. |
| Custom integration or Connect platform | Name integration and incident owners, including credential response. |

Where This Breaks

An order review isn't a test of endpoint protection. A capture setting isn't proof the attack stopped. Confirm your actual gateway and entitlement before changing controls. Keep unknown prices and unexplained activity open for investigation.

Test to Run

Use the provider's supported sandbox or your staging setup. Have the owner test legitimate checkout and approved rejection cases. Include the saved-card route if your integration uses it. Record the rejection point, affected action and rollback. If you're adding a rate rule, test its exact boundary and a legitimate repeat purchase or shared-IP customer. Confirm you'll be able to undo it. For a key drill, verify the retired sandbox key fails. Verify the replacement works, without recording either key value. Keep these drills in the supported test environment.

Solo operator? Here's your version of this playbook

You don't need a fraud team to survive an attack. If you're on Stripe, Square, or Shopify and seeing a flood of tiny orders, failed payments, or weird signups:

1.  **Review risky orders before you fulfill them.** On Shopify, use manual payment capture to review orders before charging. If you automate capture with Shopify Flow, use **Order risk analyzed** and keep manual capture on. For Stripe or Square, review your processor's fraud controls.
2.  **Add a CAPTCHA to checkout** (built into most platforms, or a free plugin). If attempts keep coming, [check where they're going](https://paymentsandrisk.com/docs/playbooks/survive-fraud-attack/#captcha-hasnt-stopped-it).
3.  **Call your processor's support line and say "I'm under a card testing attack."** Ask them to add velocity limits to your account. They deal with this daily.
4.  **Pause any ads** pointing at the page being attacked - you're paying to import fraud.
5.  **Check each payment's state before you refund.** Stripe's [card-testing guide](https://docs.stripe.com/disputes/prevention/card-testing) says to refund fraudulent payments to avoid disputes. Ask your provider how to handle the rest while containment continues.

Then use the hour-by-hour checklist below, where "fraud team" means you.

The 24-hour view

-   **Hour 0-1**: Confirm attack is real, identify vector ([card testing](https://paymentsandrisk.com/docs/fraud/types/card-testing/), [ATO](https://paymentsandrisk.com/docs/fraud/types/account-takeover/), etc.), enable emergency friction, block bad IPs/devices
-   **Hour 1-4**: Pattern analysis (IPs, devices, BINs, emails), deploy targeted rules in priority order
-   **Hour 4-24**: Measure effectiveness, tune controls, gradually relax emergency measures
-   **Post-attack**: Root cause analysis. What would have detected this earlier?
-   Even in crisis, you're running experiments: hypothesis, metric, kill criteria

24-hour response guide for active fraud attacks.

Every attack is an expensive lesson. Don't waste it.

## Workflow Overview

```mermaid
flowchart LR
    A[<b>HOUR 0-1</b><br/>Contain] --> B[<b>HOUR 1-4</b><br/>Analyze] --> C[<b>HOUR 4-24</b><br/>Stabilize] --> D[<b>POST-ATTACK</b><br/>Learn]

    style A fill:#b42318,color:#fff
    style B fill:#5e4b8b,color:#fff
    style C fill:#9a5b00,color:#fff
    style D fill:#1f6f4a,color:#fff
```

| Phase | Key Tasks |
| --- | --- |
| **Contain** | Confirm attack is real, block bad IPs/devices, notify fraud team |
| **Analyze** | Pattern analysis (IPs, devices, BINs), update rules, expand blocks |
| **Stabilize** | Fine-tune rules, restore normal operations, track losses |
| **Learn** | Root cause analysis, permanent changes, write incident report |

## When to Use This Playbook

-   Sudden unexplained increase in suspected or confirmed fraud on comparable traffic
-   Card testing attack detected
-   Coordinated fraud ring identified
-   ATO wave hitting your accounts

## Hour 0-1: Assess & Contain

### Immediate Assessment

```text
□ Confirm attack is real (not false positive spike)
□ Identify attack vector:
   □ Card testing (high velocity, small amounts, high declines)
   □ ATO wave (failed logins, profile changes)
   □ Application fraud burst (similar applications)
   □ Transaction fraud spike (unusual patterns)
□ Estimate current exposure ($)
□ Identify affected segments/products
```

### Immediate Containment

```text
□ Enable emergency friction (CAPTCHA, rate limits)
□ Block identified bad IPs/devices
□ Lower auto-approval thresholds
□ Increase manual review queue priority
□ Notify on-call fraud team
```

This is a Bet

Some emergency measures hurt conversion. Take the hit, but write down your assumptions and metrics so you can back out intelligently later.

If you block all orders from a country, measure: how many good orders are you losing? Is that worth the fraud prevented?

### Communication (Hour 1)

```text
□ Alert fraud team lead
□ Notify security team
□ Brief management (if large scale)
□ Prepare customer support talking points
```

## Hour 1-4: Analyze & Adapt

### Pattern Analysis

```text
□ Identify common attributes:
   □ IP ranges
   □ Device fingerprints
   □ BINs/card ranges
   □ Email patterns
   □ Shipping addresses
   □ Time patterns
□ Determine attack sophistication level
□ Estimate attack scale and trajectory
```

### Deploy Targeted Rules

Based on patterns found, deploy rules in this order:

**1\. High-confidence blocks (low false positive risk):**

```text
□ Block specific device fingerprints seen in fraud
□ Review IPs linked to confirmed attack attempts; check sample size and shared-network users before blocking
□ Block email domains used only in fraud
```

**2\. Medium-confidence rules (some false positive risk):**

```text
□ Add velocity limits (transactions per IP/hour)
□ Require step-up auth for flagged BINs
□ Manual review for new customers from affected countries
```

**3\. Last resort (high false positive risk):**

```text
□ Decline all orders from specific countries
□ Manual review all new customers
□ Pause specific product categories
```

### Rule Testing Even in Crisis

You're still running experiments, just faster.

For each rule you deploy:

-   **Hypothesis:** This rule will block X% of fraud with Y% false positives
-   **Metric:** Track blocks and confirmed legitimate orders blocked using [Fraud Metrics](https://paymentsandrisk.com/docs/fraud/metrics/). Keep unresolved cases separate; complaints alone don't measure the rate.
-   **Kill criteria:** Set a loss and customer-impact cap with the incident owner before enabling the rule. Review early blocks immediately; revise or roll back if that cap is reached. See [live-test safeguards](https://paymentsandrisk.com/docs/reference/experimentation/#before-a-live-test).

## Hour 4-8: Stabilize

### Measure Effectiveness

```text
□ Track fraud rate change since rules deployed
□ Monitor false positive rate (customer complaints, support contacts)
□ Compare hourly fraud $ before/after
□ Assess customer impact
```

### Tune Controls

```text
□ Tighten rules if attack continues
□ Loosen rules if false positives too high
□ Add new rules as patterns emerge
□ Remove ineffective rules
```

### Document Actions

```text
□ Log all rule changes with timestamps
□ Document decision rationale
□ Track affected customers/transactions
□ Preserve evidence for investigation
```

## Hour 8-24: Recover & Learn

### Transition to Normal

```text
□ Gradually relax emergency controls
□ Return manual review to normal staffing
□ Monitor for attack resumption
□ Keep targeted blocks in place longer
```

### Impact Assessment

```text
□ Total fraud prevented: $_______
□ Total fraud losses: $_______
□ Estimated false positives: _______
□ Customer complaints: _______
□ Operational cost: $_______
```

## Post-Attack (Day 2-7): Learn

### What Would Have Caught This Earlier?

The most valuable question. Don't skip it.

```text
□ What signal appeared first?
□ How long between first signal and detection?
□ What alert or rule SHOULD have fired?
□ What data did we not have that would have helped?
```

### Root Cause Analysis

```text
□ How did the attack start?
□ Why wasn't it detected earlier?
□ What control gaps were exploited?
□ How can we prevent recurrence?
```

### Permanent Improvements

Based on what you learned:

**New detection rules:**

```text
□ Rule 1: _______________ (catches: _______________)
□ Rule 2: _______________ (catches: _______________)
```

**New alerts:**

```text
□ Alert if _____________ exceeds _____________ in _____________ window
```

**Process changes:**

```text
□ _____________________________________________
```

## Incident Report Template

Document for future reference:

```text
Attack Summary:
- Date/time started: _______________
- Date/time contained: _______________
- Attack type: _______________
- Duration: _______________
- Total exposure: $_______________
- Loss prevented: $_______________
- Actual loss: $_______________
- False positives: _______________

Root Cause:
_________________________________

What Worked:
_________________________________

What Didn't Work:
_________________________________

Permanent Changes Made:
_________________________________

Open Questions:
_________________________________
```

## Quick Reference: Common Attack Types

| Attack | Signs | First Response | False Positive Risk |
| --- | --- | --- | --- |
| Card Testing | High velocity, small $, high declines | Rate limit, CAPTCHA | Low |
| ATO Wave | Failed logins, profile changes | Lock accounts, MFA | Medium |
| App Fraud Burst | Similar applications, velocity | Tighten onboarding | Medium |
| Transaction Spike | Unusual patterns, new customers | Lower approval threshold | High |

## Emergency Contacts Template

Fill in for your organization:

| Role | Name | Phone | Email |
| --- | --- | --- | --- |
| Fraud Lead |  |  |  |
| Security |  |  |  |
| Engineering |  |  |  |
| Customer Support |  |  |  |
| Management |  |  |  |
| Legal |  |  |  |

## First Experiment to Run After an Attack

Once the crisis is over:

**Hypothesis:** We would have detected this attack X hours earlier if we had \_\_\_\_\_\_\_\_\_\_\_\_\_.

**Experiment:** Build that alert or rule. Backtest against the attack data. Deploy in shadow mode.

**Expected outcome:** Next similar attack gets detected faster.

## Related

-   [Card Testing](https://paymentsandrisk.com/docs/fraud/types/card-testing/) - High-velocity attack pattern
-   [Account Takeover](https://paymentsandrisk.com/docs/fraud/types/account-takeover/) - Credential abuse attacks
-   [Velocity Rules](https://paymentsandrisk.com/docs/fraud/detection/velocity-rules/) - Rate-based detection
-   [Data Enrichment](https://paymentsandrisk.com/docs/fraud/detection/data-enrichment/) - IP and email pattern analysis during attacks
-   [Device Fingerprinting](https://paymentsandrisk.com/docs/fraud/detection/device-fingerprinting/) - Device-based blocking
-   [Risk Scoring](https://paymentsandrisk.com/docs/fraud/prevention/risk-scoring/) - Combining fraud signals
-   [Fraud Metrics](https://paymentsandrisk.com/docs/fraud/metrics/) - Measuring attack impact
-   [Processor Rules Configuration](https://paymentsandrisk.com/docs/fraud/processor-rules-configuration/) - Emergency rule deployment
-   [Manual Review](https://paymentsandrisk.com/docs/fraud/detection/manual-review/) - Escalated review queues
-   [Network Programs](https://paymentsandrisk.com/docs/chargebacks/reference/network-programs/) - Threshold monitoring
-   [3D Secure](https://paymentsandrisk.com/docs/fraud/prevention/3ds/) - Authentication friction
-   [Alerts Configuration](https://paymentsandrisk.com/docs/operations/alerts-configuration/) - Setting up attack detection

Build proper defenses

Attack contained? Learn how to set up lasting fraud protection so you're ready next time. **[Start The Guide, Pathway 3: Protecting from Fraud](https://paymentsandrisk.com/docs/learning-pathways/protecting-from-fraud/fraud-basics/)**, 3 lessons covering fraud basics, free protections, and ongoing monitoring.

## Sources

| Source | Supports | Opened |
| --- | --- | --- |
| VENDOR [Stripe card-testing guide](https://docs.stripe.com/disputes/prevention/card-testing) | Payment and saved-card routes; payment details; server-side CAPTCHA; custom-pricing authorization and dispute fees | 2026-10-21 |
| VENDOR [Stripe API keys](https://docs.stripe.com/keys) | Key types; webhook distinction; rotation expiry and Now; Workbench request logs | 2026-10-21 |
| VENDOR [Stripe key security](https://docs.stripe.com/keys-best-practices) | Immediate response to exposed secret or restricted keys; secure handling; managed-key boundary | 2026-10-21 |
| VENDOR [Stripe compromised-key response](https://support.stripe.com/questions/protecting-against-compromised-api-keys) | Rotate, test, replace, confirm, delete; investigate and repair exposure; separate Connect response | 2026-10-21 |
| VENDOR [Stripe US pricing](https://stripe.com/pricing) | US public pay-as-you-go Radar starting price: US$0.05 per screened transaction, as opened 2026-10-21; not an account quote | 2026-10-21 |
| VENDOR [Radar pricing](https://stripe.com/radar/pricing) | Radar Lite card-testing prevention at no additional charge on standard payments pricing | 2026-10-21 |
| VENDOR [Square Risk Manager, US](https://squareup.com/help/us/en/article/6816-navigating-square-risk-manager) | Payments & invoices entry; owner or Risk Manager permissions | 2026-10-21 |
| VENDOR [WooCommerce PayPal Payments](https://woocommerce.com/document/woocommerce-paypal-payments/fraud-and-disputes/) | Named plugin only; 3.3.0 minimum; both v2/v3 keys; settings; support report | 2026-10-21 |
| VENDOR [Google Cloud billing](https://docs.cloud.google.com/recaptcha/docs/billing-information) | Cloud Fraud Defense assessment billing; product and organization scope | 2026-10-21 |