How to protect SaaS from card testing attack?
Yesterday, someone decided to test stolen cards on Seodity. Luckily, we quickly noticed that something was wrong (too many customers in a short amount of time, many blocked payments, but some going through) and temporarily disabled payments to reconsider our next steps. I found an article on Stripe about this (https://stripe.com/docs/disputes/prevention/card-testing) and purchased a Stripe Radar subscription to gain more insights into fraudulent payments.
In the end, we paused new payments for a few hours and then resumed them, but I don't think this is the best course of action for such scenarios. We also refunded all payments that appeared fraudulent to protect ourselves from chargebacks.
It's strange to me that someone chose Seodity for card testing, as it has a high friction to make a payment - you have to register an account, and the registration page is protected by an invisible captcha. This means you need to do it manually (and it seems they did, as there were 5-10 minutes between attempts).
We've set up some blocks in our Stripe Radar subscription for high-risk payments, and we'll be reviewing payments manually when the risk is elevated.
I was wondering if any of you have experience with card testing prevention. Is there anything else we can do to protect ourselves from this kind of activity?
Hey @gregory90, there is a solution available for this. It prevents and blocks scammers who use tactics such as card fraud, multi-accounts, free trial stealing, manipulating fingerprint systems, and more. This is achieved by implementing a KYC (Know Your Customer) identification process. Installing this solution can reduce fraud by up to 90%. You can learn more about it at kycwidget.com.
I have the same problem, how did you solve it?
I didn't actually - paused new payments and resumed them after few hours.
I was thinking about requirement for email address verification, but this would increase friction from sign up to payment, so I don't think it's good idea.
This comment was deleted 5 months ago.
Thank you!!
Last week, Shannon Mattern shared a terrifying saga she's going through with fraudulent Stripe activity on her "Profitable Web Designer" podcast. The card testing and fraud was scary, but Stripe's (lack of) response was even more concerning...
https://webdesigneracademy.com/my-stripe-account-was-hacked-and-stripe-said-i-have-to-repay-70k
I wonder if there is a way to disallow payments done through VPN? I would guess the attacker uses one.
Yes, I think it was VPN, as there were payments from multiple countries and IP addresses. I'd like to know this too!
Shouldn't Stripe do his for you?
They blocked payments which they marked as "high risk", but there was a lot of "elevated risk" payments which came through.
I thought about limiting the checkout requests from the sam IP address
We already do that, didn't work this time, as payments were made from different IP addresses.
May I ask if the IP addresses came all from from a specific country? Or are they scattered from all over the word?
Scattered all over the world - I couldn't find anything which would link these fraudalent payments.
How can you be sure, then, that they're fraudulent?
They would have entered "...." in name field, or try few different cards which would get blocked, and then third or fourth would work.
If you notice that attacks keep coming from a particular country where you have no or minimal revenue, you can block that country.
Every payment was from different country and different IP address unfortunately.
Maybe You can use Address Verification that checks if cardholder's address and zipcode match or not.
That could work, I'll try, thank you!
But doesn't the attacker knows the address of the credit card?
I don't think so - there's no address on the credit card. It really depends where these cards data was stolen from.
Im currently dealing with this. I am a small Saas startup and ran google ads. As soon as I ran ads I got loads of signups and even with email verification and address verifcation with cvv for credit cards they still get through. I also have IP Velocity filter in place. We use Authorize . net for the gateway and have their fraud filters in place. Ive already lost one merchant account 7 days after launch which forced us to pause all payments and we got left on the hook paying out of pocket for the api calls the user spent. Went ahead and got another merchant account and set up AVS verification with IP velocity filter set to 3 an hour and STILL got hit with a fraud card being used. I am now going to implement Phone number verification and maybe make the app crypto only and just stop accepting credit cards at this point.
The worst part about all of this is you don't build the fun things you want. All of a sudden Im diving into this months long rabbit hole of payments and security. I want to work on features that make my app stand apart, not spend my life on card fraud.
Glad you caught wind of it straight away -- would've been such a huge headache tbh!
We've experienced similar in our SaaS app. It's a huge pain.
We implemented phone number verification (with uniqueness check - no re-use allowed) as part of the process of signups. It's a layer of friction for signups, but it means our signups tend to be more legitimate and for some reason receiving a text to a valid phone number seems to be harder for these bad actors than obtaining a bunch of card numbers.
Our service handles payments on behalf of providers, so those providers also have Stripe connected accounts. The bad actors tend to use the same handful of banks that they want to send the fraudulently charged money to. So when we see those banks we pause payouts and watch the transactions to see if they look legitimate or not before we resume payouts. Often they'll reach out to support and it becomes very obvious if they are a real customer or not.
Stripe is pretty good at preventing some amount of fraud, but not all of it. Definitely still takes some close eyes to keep things legit.
I'm so lucky to have found this site, which gave me easy access to good information
This comment was deleted 5 months ago.