Solved: The Stripe slow-burn how to fraud playbook!
Source: Dev.to
TL;DR
Merchants face a “Stripe slow‑burn” card‑testing attack, where fraudsters validate stolen credit cards via low‑friction payment forms, incurring dispute fees and risking account suspension. Combat this by implementing immediate rate limiting and CAPTCHA, then leveraging Stripe Radar and 3‑D Secure, and considering geo‑blocking or identity verification for persistent threats.
The “slow‑burn” attack involves bots testing thousands of stolen credit‑card numbers with tiny transactions on simple payment forms. The result is:
- Merchant transaction fees for every attempt.
- Dispute/charge‑back fees when the real cardholder reports fraud.
- Potential Stripe account shutdown after repeated abuse.
Immediate Mitigation (Weekend‑Fix)
- Edge‑level rate limiting – e.g., NGINX
limit_req_zone. - Client‑side CAPTCHA – e.g., Google reCAPTCHA v3.
These steps make high‑volume automated attacks expensive and noisy while you work on a permanent solution.
Example NGINX Configuration
# In your nginx.conf http block
limit_req_zone $binary_remote_addr zone=payment_limit:10m rate=5r/m;
# In your server block
location /api/v1/payment {
limit_req zone=payment_limit burst=10 nodelay;
# ... your other proxy/fastcgi settings
}The snippet limits a single IP address to 5 requests per minute for the payment endpoint, with a burst capacity of 10. It’s blunt but highly effective.
Add Google reCAPTCHA v3 to the payment form to raise the bar further.
Permanent Solutions (Architectural Fix)
1. Stripe Radar
Stripe Radar applies machine‑learning across the entire Stripe network to flag and block fraudulent payments.
| Tool | What It Does | Why You Need It |
|---|---|---|
| Stripe Radar (Default) | Provides risk scores and basic block rules. It’s on by default but needs configuration to be aggressive. | Baseline protection – set the “risk level” you’re comfortable with and block high‑risk scores. |
| Radar for Fraud Teams | Lets you write complex, custom rules (e.g., “Block if card country ≠ IP country” or “Block if > 3 attempts from this IP in 1 hour”). | Surgical targeting of the exact patterns you’re seeing. Extra cost is cheaper than thousands in dispute fees. |
| 3‑D Secure (SCA) | Forces an additional verification step with the cardholder’s bank (SMS code, app approval, etc.). | Liability for fraudulent disputes shifts to the issuing bank. Adds a little friction for users but kills this attack vector. |
Implement 3‑D Secure dynamically (only for suspicious transactions) to keep the user experience smooth for legitimate shoppers while forcing high‑risk payments through an extra check.
2. Additional Defensive Layers
| Technique | Description | When to Use |
|---|---|---|
| Geo‑blocking | Block or challenge requests from countries you don’t serve. | Persistent attacks originating from specific regions. |
| Identity verification | Require email/phone verification or a one‑time password before payment. | High‑value transactions or accounts showing repeated failures. |
| Web‑application firewall (WAF) | Deploy rule‑sets that detect known card‑testing patterns. | Complementary to rate limiting; catches bursts that slip through. |
Narrative Example (What Went Wrong)
It was 3 AM on a Saturday. My phone buzzed—not a PagerDuty alert, but a Slack message from Head of Finance: “Darian, why do we have over 4,000 new $1 ‘donations’ from all over the world in the last 12 hours?”
Our simple, unprotected donation endpoint was being used as a credit‑card validator for fraudsters. Each “successful” $1 transaction was a ticking time‑bomb for a $15 dispute fee, and Stripe was threatening to shut us down.
The attackers weren’t after our money; they wanted to confirm which stolen cards were still live. Successful $1 charges marked a card as LIVE, after which it could be sold on the dark web for a much higher price. Failed attempts were simply discarded.
Playbook Summary
| Phase | Action | Tools / Config |
|---|---|---|
| Triage (Get through the weekend) | Stop the flood. | Edge rate limiting (NGINX, Cloudflare, etc.) + CAPTCHA (reCAPTCHA v3). |
| Short‑term hardening | Add basic fraud detection. | Enable Stripe Radar (default), set aggressive risk thresholds. |
| Long‑term defense | Deploy custom rules & verification. | Radar for Fraud Teams, dynamic 3‑D Secure, geo‑blocking, identity checks, WAF. |
| Monitoring | Keep an eye on metrics. | Stripe Dashboard → Radar logs, webhook alerts for high‑risk events, server logs for rate‑limit hits. |
Final Thought
Panicking won’t help, but acting fast will. Deploy the quick edge‑level fixes now, then roll out the robust Stripe‑centric defenses. The combination of rate limiting, CAPTCHA, Radar, and selective 3‑D Secure will turn a bleeding‑slow‑burn attack into a dead‑end for fraudsters.
Users
1️⃣ Geo‑blocking
Dive into your analytics and the Stripe data. Is 95 % of the fraud coming from IP addresses in countries where you have zero customers? Block them.
- Do not implement the block on your application servers; that’s too slow.
- Implement the block at the edge: Cloudflare, AWS WAF, or your infrastructure firewall.
A Word of Warning:
VPNs are a thing, and you can inadvertently block legitimate customers who are traveling or concerned about privacy. This is a business decision as much as a technical one. Communicate with your product and leadership teams before flipping this switch.
This is a heavy‑handed tool, but if your business is primarily North American and the attacks are coming from Eastern Europe, it’s a logical step.
2️⃣ Increase sign‑up friction
Fraudsters love easy targets. If your payment form only requires an email and a credit card, you’re a prime target. Consider adding a required phone‑number verification step (using a service like Twilio Verify) before a user can access the payment form.
- It’s a hurdle, but it’s one that most bots can’t jump.
Bottom line
Fighting this kind of fraud is a continuous process, not a one‑time fix. By layering these defenses, you can turn your application from a soft, inviting target into a hardened, frustrating one for attackers, letting you and your team get back to sleeping through the night.
👉 Read the original article on TechResolve.blog
☕ Support my work
If this article helped you, you can buy me a coffee:
👉