Survive a fraud attack on your store
- 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.
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.
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.
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. For suspected secret-key exposure, go straight to key response.
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. 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. |
| Shopify | Use the order-review section 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. |
| WooCommerce PayPal Payments | Use this plugin's official CAPTCHA setup. 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. |
| 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.
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.
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.
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.
Google's linked billing guide covers Google Cloud Fraud Defense. Check the actual product, project and organization behind your invoice. VENDOR Google billing guide.
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, 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 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.
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.
Get your integration owner involved now. Follow Stripe's compromised-key sequence:
- Open Developers > API keys and find the affected key.
- Open its menu and choose Rotate key.
- Choose an expiry that allows testing the replacement.
- Update the backend through your secure deployment process.
- Confirm the integration works using the replacement key.
- Delete the compromised key after that confirmation.
Stripe's incident guide documents that order and immediate deletion. VENDOR 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.
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.
Then open the affected key's menu and View request logs. It opens Workbench. Review requests since the suspected exposure. VENDOR Stripe 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.
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.
Connect platforms: use Stripe's Connect-specific remediation 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.
For successful suspicious payments, use the payment-state guide. Check captured, pending, refunded and disputed records before choosing an action. Choose each cleanup action from that guide, using the actual payment state.
| 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. |
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.
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.
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:
- 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.
- Add a CAPTCHA to checkout (built into most platforms, or a free plugin). If attempts keep coming, check where they're going.
- 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.
- Pause any ads pointing at the page being attacked - you're paying to import fraud.
- Check each payment's state before you refund. Stripe's card-testing guide 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.
- Hour 0-1: Confirm attack is real, identify vector (card testing, ATO, 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
| 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
□ 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
□ 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
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)
□ Alert fraud team lead
□ Notify security team
□ Brief management (if large scale)
□ Prepare customer support talking points
Hour 1-4: Analyze & Adapt
Pattern Analysis
□ 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):
□ 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):
□ 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):
□ 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. 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.
Hour 4-8: Stabilize
Measure Effectiveness
□ 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
□ Tighten rules if attack continues
□ Loosen rules if false positives too high
□ Add new rules as patterns emerge
□ Remove ineffective rules
Document Actions
□ 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
□ Gradually relax emergency controls
□ Return manual review to normal staffing
□ Monitor for attack resumption
□ Keep targeted blocks in place longer
Impact Assessment
□ 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.
□ 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
□ 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:
□ Rule 1: _______________ (catches: _______________)
□ Rule 2: _______________ (catches: _______________)
New alerts:
□ Alert if _____________ exceeds _____________ in _____________ window
Process changes:
□ _____________________________________________
Incident Report Template
Document for future reference:
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 | |
|---|---|---|---|
| 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 - High-velocity attack pattern
- Account Takeover - Credential abuse attacks
- Velocity Rules - Rate-based detection
- Data Enrichment - IP and email pattern analysis during attacks
- Device Fingerprinting - Device-based blocking
- Risk Scoring - Combining fraud signals
- Fraud Metrics - Measuring attack impact
- Processor Rules Configuration - Emergency rule deployment
- Manual Review - Escalated review queues
- Network Programs - Threshold monitoring
- 3D Secure - Authentication friction
- Alerts Configuration - Setting up attack detection
Attack contained? Learn how to set up lasting fraud protection so you're ready next time. Start The Guide, Pathway 3: Protecting from Fraud, 3 lessons covering fraud basics, free protections, and ongoing monitoring.
Sources
| Source | Supports | Opened |
|---|---|---|
| VENDOR Stripe card-testing guide | Payment and saved-card routes; payment details; server-side CAPTCHA; custom-pricing authorization and dispute fees | 2026-10-21 |
| VENDOR Stripe API keys | Key types; webhook distinction; rotation expiry and Now; Workbench request logs | 2026-10-21 |
| VENDOR Stripe key security | Immediate response to exposed secret or restricted keys; secure handling; managed-key boundary | 2026-10-21 |
| VENDOR Stripe compromised-key response | Rotate, test, replace, confirm, delete; investigate and repair exposure; separate Connect response | 2026-10-21 |
| VENDOR Stripe US 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 | Radar Lite card-testing prevention at no additional charge on standard payments pricing | 2026-10-21 |
| VENDOR Square Risk Manager, US | Payments & invoices entry; owner or Risk Manager permissions | 2026-10-21 |
| VENDOR WooCommerce PayPal Payments | Named plugin only; 3.3.0 minimum; both v2/v3 keys; settings; support report | 2026-10-21 |
| VENDOR Google Cloud billing | Cloud Fraud Defense assessment billing; product and organization scope | 2026-10-21 |