How do I stop card testing attacks on my Stripe account?
For the past several months I have been getting hit with several card testing attacks. I sell a product with a subscription (which is processed via Stripe). The problem is that everytime this occurs I have to manually go into my account and determine if it is a card testing attack and then if it is then I have to refund and block the payment. Not a big deal if it happens once or twice but has been happening very frequently on my account. I've tried everything I can on my end but it's very limited what I can do since they don't even go through my website (I use Stripe Checkout, which they say is excellent protection against card attacks - which seems untrue to me). They simply get my public key (which I've rotated) and create their own checkout session. I've reached out to Stripe SEVERAL times and it is really annoying that they are unable to stop it.
What can I do, short of switching to PayPal or another provider?
Thanks!
I thought the whole point of using Stripe was they handle thia shit for you.
I was on Stripe Radar's free trial, but it wasn't as effective as I liked - it also turned out to be very pricey paying £0.04/screened transaction.
I've now rolled my own combination of IP-based bans on creating checkout links + notifications if a purchase has many failed attempts using diff cards (you can do this for free through Stripe's API). I refund suspected fraudulent transactions religiously without question as the $20 dispute fee is crippling, and have systems that will auto-generate and submit evidence to banks whenever I receive a dispute. I wish Stripe would do more to help!
Most of the time these testing card attacks are automated. If so, You can implement code and use Stripe element. Additionally, add logic if you get request from same IP in, let say 5 per within 1 minutes then block them for 15 minutes or so. Add Captcha and use CloudFlare to block IP ranges.
Hi! I work on card testing at Stripe and would love to help. Sorry to hear about this experience, would be great to dig in and see how we can fix it and improve our system.
If you could, shoot me an email and we can dig in? I'm at wmegson [at] stripe.com (will DM you as well).
Depending on where your customer base is, the fraudulent transactions usually come from like the middle east, eastern europe, and other countries. See if you can track where those transactions are originating from HTTP request wise.
You might be able to just block traffic from those regions if it does not impact your business and customer base.
Not the best or cleanest solution, but when Stripe fails to handle fraud for you, you've got to get creative and hit the problem from all angles.
Can you add a custom field to your payments flow, readable from Stripe? Use JWT or some other cryptography signature to tag good transactions.
Sound like the kind of thing you’re paying Stripe to deal with?
Open a support case every time it happens.
I don't get it, you have to generate the session server side before redirect so you can do all your checks there, from rate limiting, etc.
pass a nonce or something that you can check for before creating the redirect to make sure it's being generated from your own site.
We had the exact same issue. Turns out cycling (all) the keys stopped it immediately. This was after looking through docs and many emails with stripe that never mentioned this as a solution.
Hey — I work at Stripe. Sorry you got hit by card testing. Could you email me at edwin@stripe.com and we can take a closer look?
If possible, collect fingerprint information through a side channel such as WebRTC or WebTransport, and use the info to correlate payments. Or, if the attack is executed from a non-browser environment, you can pattern match the order of TLS cipher suite to that sent by the attacker and block them straight away.
Are you using the latest Payments Intent ? That shouldn't allow attackers to use your Public key and create their own checkout page.
what’s a card testing attack? how does it work?
seems odd that this is your problem. seems like something stripe should be on the hook for.
Using a fraud check service like Sift can help.