Lets discuss Stripe Fraud prevention and Radar
Howdy LES!
Fraudulent disputes are brutal—especially for small providers, like myself.
A single “test” payment or low-value order can turn into a chargeback that wipes out the revenue and slaps you with an extra fee. My PSA: **turn on Stripe Radar and tune it for our kind of business ** so you’re not paying real money for €1.50 card tests.
What Radar does: Stripe scores every payment for risk (0–99) and can automatically block, review, or step-up authenticate (3D Secure) the sketchy ones. Defaults are sensible, but a few tweaks make a big difference for hosts and other small shops.
Three quick tips:
- Use the default thresholds (block ≈ 75, review ≈ 65) as a baseline, then tighten if you’re seeing card tests or “low-amount” fraud spikes.
- Ask for 3D Secure on higher-risk payments (for example: new customers, high amounts, IP/card country mismatch). 3DS can shift fraud liability to the issuer when the authentication succeeds.
- Lean on allow/block lists for repeat good customers and known abusers (emails, IPs, BINs). It’s fast and reduces false positives.
About dispute fees: if a dispute lands, Stripe debits the payment amount plus a dispute fee (and sometimes an additional counter-dispute fee). Exact amounts depend on region, so check your local pricing. Prevention really does pay.
If anyone wants a starter set of Radar rules tailored to low-ticket hosting, I’ve put some examples below, use them for your safety!
1. Quick “turn this on” checklist (Stripe Dashboard)
- Risk thresholds: keep the default block/review thresholds to start; backtest before tightening.
- 3D Secure: enable/request 3DS dynamically for elevated-risk scenarios (you can do this with Radar rules.
- Analytics/Insights: check Radar Analytics to see top fraud drivers and tune rules from real data.
2. Copy-paste Radar rule ideas
Keep in mind these are examples, test and adjust the rules to your liking.
- High-risk payments
Block if :risk_level: = 'highest'
Review if :risk_level: = 'elevated'
(Use these with your thresholds so ML + rules work together.)
Country/IP mismatch (common with card testing)
Block if :card_country: != :ip_country:Step-up auth for suspicious combos
Request 3DS if :risk_level: = 'elevated'
Request 3DS if :is_anonymous_ip: OR :is_proxy:
(Use request-3DS rules before block/review rules; that’s the evaluation order.)
- Velocity limits (burst attempts)
Block if :authorized_charges_per_ip_address_hourly: > 3
Block if :authorized_charges_per_card_number_hourly: > 3
(Adjust thresholds based on your pattern; Stripe calls these “velocity” attributes.)
That’s it from me. Turn on Radar, tune a couple rules, and keep your margins yours. Got questions? Feel free to ask.
Comments
Stripe Radar is the worst, I had to create a second virtual card, because my virtual once I used to pay for virtual servers, got blocked a few times, randomly.
Free NAT KVM | Free NAT LXC
Do you know any other alternatives to reduce fraudulent charge-backs? Since I am open to trying out other payment methods aside from Stripe, if it helps reduce situations like this.
Stripe was pretty horrible in our experience, and despite having had Radar active and custom rules in place we encountered an issue where a user had generated many many "Add Funds" invoices for like $10 each, and tried several cards on each invoice until one worked. He did this about 85 times.
Me, a stickler for review of daily operations and what not, noticed during my daily look at the transaction log that there was an uncommon sight: A bunch of $10 invoices being paid one after another over the course of several hours. When you're in business a while you sort of know what payment amounts are normal and what a normal transaction history looks like. A bunch of $10 transactions in a short amount of time when none of our products are priced at $10.00 sort of raised suspicion that something was up.
Anyway, review it and see what was happening. Check the transactions with Stripe and you can clearly see multiple failed attempts of payment from different cards for each invoice. Why Stripe doesn't block this, even without a specific rule in place via Radar, who knows?
Anyhow, I suspend/terminate the services he purchased with the account credits he accrued and manually refunded each transaction 1 by 1 to the original source. Took a couple hours and was literally 85 or so individual transactions. I have no doubt in my mind that they would have all been disputed in due time, so wanted to go ahead and be proactive, kick the customer to the curb and refund the $850~ or so.
What does Stripe do? Pat me on the back and tell me good job for being proactive? Reach out to me to ask why the high volume of refunds in a short period? Nah. They just locked the account with no appeal until much later. Pretty sure we can use Stripe again now, but have no desire to.
TLDR: Super common and basic things like trying to pay a single invoice with 3 or 4 different cards until one works doesn't trigger their 3DS or whatever security protocol, didn't block the transaction(s) or even mark them as high risk. We had several Radar rules in place already for larger dollar amount orders, high risk countries, etc but there wasn't anything "by default" that would have prevented what this customer did.
In the end, changed it so that you can't add funds to your account unless you already have an active service and stopped using Stripe. Probably lost a few customers over it that didn't want to use PayPal or crypto or GoCardless, but it's less headache now.
We've been using GoCardless for a couple years now. It's not incredibly popular but we've had no real headaches with it. Crypto is our main revenue source, and there are no chargebacks possible there. Other than that, PayPal is still the one globally known and recognizable and trusted payment processor. Very rare to get a chargeback there that you can't win so long as you provide evidence and respond to the disputes.
[ IncogNET LLC ] - Since 2020
[ The Internet Speech & Privacy Company ]
That's a really nice response, thank you really appreciate it!
And I have considered crypto, but been kinda holding back on it because my accounting software, gotta kinda figure how it works there. And well, PayPal, I've been told that "Stay away from PayPal, they got astronomical fees"
But I also know from prior experiences with PayPal, that they got great customer support, and well, its not difficult to win disputes that are clearly fraudulent, which on Stripe, is not even worth trying....
So thank you for the comment, and if you maybe have more tips on crypto, and you feel like sharing, let me know, maybe I'll actually give it a try!
It's quite possible Stripe has improved, and it's also possible that what had happened could have been prevented had I created the rules for it myself. (Though, I still think trying several cards until one works is a red flag that should be blocked regardless if a rule was manually created for that scenario specifically).
Crypto, for that we just self-host BTCPayServer for processing it but the storage / resource requirements for doing that will likely cost more than using a trusted exchange / processing company with minimal fees. Seems many use NowPayments, Cryptomus, BitPay, etc. I have no real strong opinions on any of them as I've only used them as a customer
[ IncogNET LLC ] - Since 2020
[ The Internet Speech & Privacy Company ]