HN Explorer

Ask HN: How do I stop card testing attacks on my Stripe account?

83 points by tempaccount3333 ↗ HN
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!

45 comments

[ 2.3 ms ] story [ 101 ms ] thread
anenefan
Vouched as this seems like a question others who use Stripe could sort out.

As little as I know about check outs, (I know nothing,) I'm unsure why a public key would be used to pipe the request to Stripe? Surely any request to a third party needs an additional security measure apart from being merely being logged into the site.

https://stripe.com/en-au/newsroom/news/card-testing-surge

https://stripe.com/docs/disputes/prevention/card-testing#pre...

weird-eye-issue
Yeah, a secret key is used to create a Stripe checkout session
[deleted]
(comment deleted)
imtu80
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.
tempaccount3333
Unfortunately, the attacks are happening completely outside of my website. The attacker is generating a Stripe Checkout page using my public key - which I have rotated several times. Implementing a captcha on my end won't work and I have no control over blocking IP addresses.
magundu
Now more people know how to do the card testing.

There must be an option to allow stripe script only in specific domains and sub domains. All other domains should be blocked.

tehbeard
Doesn't work as that kind of info is in the http headers sent by the client..
harg
Are you sure this is how it’s being done? My understanding of stripe checkout is that you need the secret key to create a checkout session.
tibbon
Using a fraud check service like Sift can help.
ThePowerOfFuet
At $5K a month last time I looked at them, Sift is a nonstarter for small businesses.
Temporary_31337
Sound like the kind of thing you’re paying Stripe to deal with? Open a support case every time it happens.
perfmode
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.

nibbleshifter
It's where attackers use your sites payment method / card processing method to make a shitload of small transactions to verify the stolen credit cards they have are valid.

Transaction succeeds? Cards valid.

quickthrower2
That raises more questions. My product is $29 say. How come they are allowed to make a small transaction at all?
withinboredom
Because they generate their own links using the checkout api for clients (thus all they need is your public key)
stef25
OP says they're using his public key to create their own checkout page so they can set whatever price you want.

Kind of doubtful that all you need to test cards is a public key scraped off any site that's implemented Stripe.

tempaccount3333
They are using my subscriptions. They don't set their own price
chrisdkemper
The attacker unfortunately doesn't have to use any aspect of the products that the site implements. In my situation I have different subscription levels, but the card attacker disregards all of it. Stripe really shouldn't allow for a card to be referenced without a predefined product also being referenced.

It's almost as is Stripe doesn't want to stop the attacks because they're making so much from fees

tempaccount3333
They are using my predefined products/subscriptions and aren't creating their own.
a_simm
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.
newusertoday
can you elaborate what do you mean cycling all keys?
dinkleberg
Cycling keys means replacing all of your API keys. So if you go into stripe and generate new keys and then update those in your app (it sounds like you need to make sure to replace all of the stripe related ones), you’ll have “cycled” them (then once your new keys are running, you should invalidate the old keys if they aren’t in use).
chrisdkemper
How long did this work for you? I've cycled my keys multiple times and it goes any time from 6 weeks to less than a week till the attacks start again.
tinyprojects
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!
rgavuliak
Almost feels like you could provide this to other merchants in some way/shape/form.
danpalmer
Out of interest, how effective do you find challenging the chargebacks is in practice?

I always thought about automating this (or for lost delivery claims with shipping companies) but the numbers never worked out for it to be worth it because the success rate seemed like it would be so low.

tinyprojects
I've only trialled this system recently, but my current results are:

1 Win

2 Partial Wins (basically a loss with how much you get back)

3 Losses

All these payments were fraudulent (a user doing credit card testing) and disputed by foreign banks (Thailand, Malaysia, Brazil). I think these cases are much harder to win, because the actual card holder is technically in the right to request the money back on their stolen card for a transaction they didn't do.

Much better than my previous results of just accepting each dispute though :)

danpalmer
Thanks. Are your charges much more than the chargeback processing fee?

One of the issues for us was that while the chargeback processing fee was ~£20, the order values were only ~£100-300, so even in the worst case of ~£320 lost, multiplied by roughly 1 in 10 non-fraud mistaken chargebacks, and 50% win rate, the value is only £16. At that amount it would take a lot to recoup the development costs. These are all very rough numbers, but illustrative I think.

tinyprojects
Much less - 99% of our transactions are < $20, so every time we get hit with a dispute it's already an instant loss in terms of the dispute fee cancelling out any revenue gained back from winning the dispute.
zacharybk
It would be awesome to hear/see more about the system you built to auto-generate and submit evidence. This is a huge pain for many companies which an open source tool could solve.
tinyprojects
Sure! I basically use PDF Lib to generate a letter with all my evidence bundled into one pdf file. It sucks up data from my database about the user's activity. Format is the following:

Formal 1 page letter with company logo - "Dear Sir/Madam.. writing about $9.99 dispute for card XXXX on X date for user [NAME]" (all this is pulled from the Stripe API).

I then have 5 appendixes on separate pages:

Appendix 1: Users' receipt (just a pic of the Stripe receipt)

Appendix 2: User's order history (just printed, name of items, price, and timestamp)

Appendix 3: Screenshot of the user's purchases page clearly showing the item

Appendix 4: Email confirmations - I store copies of each HTML email sent, so just take a picture of this.

Appendix 5: Site activity with IP addresses and timestamps. This is all user actions on my site (viewing items, purchasing, etc.)

I created it because I had 20 disputes piling up, and I was dreading processing them all. Given that you're likely to lose the majority of disputes, it's super discouraging to put in the work, but this makes it a bit easier (I don't want to let fraudsters just get away with it!).

koromak
Figure out a way to suck up this data through Stripe API alone and this is potentially a product
ookblah
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.

louwhopley
There's a client-side only implementation of Stripe Checkout, which is what the OP might be using. [tutorial example](https://designcode.io/advanced-react-hooks-handbook-stripe-c...)
ookblah
that's probably a legacy version then. had a similar issue with the old checkout flow where card testers could just generate tokens using ur public key and feed it to whatever endpoint. they need to move to payment intents.
nibbleshifter
I thought the whole point of using Stripe was they handle thia shit for you.
MagicMoonlight
Yeah why would you pay them a huge fee if you then have to manually deal with fraud
frankreyes
Can you add a custom field to your payments flow, readable from Stripe? Use JWT or some other cryptography signature to tag good transactions.
weird-eye-issue
Could add metadata to the customer when you create them as part of the create checkout flow
codegeek
Are you using the latest Payments Intent ? That shouldn't allow attackers to use your Public key and create their own checkout page.
gt565k
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.

0xbkt
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.
edwinwee
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?
dulse
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).