Spent a few hours today manually refunding 50+ payments. It would have been a ton more but we already setup some pretty strict rules several weeks ago when this happened before.
Contacting Stripe back then was a complete waste of time.
We implemented a bunch of rules manually which mostly fixed the issue and I reached out to support to ask if there was anything else we should do.
A few days later they said we need to "take immediate action" and offered only generic advice.
I told them what we already did (implementing the Radar rules manually) and they said oh yeah seems fine, looks like it stopped. But the kicker is we did that before they reviewed our account and told us we needed to take action. What a joke.
This was after spending tens of thousands in fees in a single month with them.
The only reason some of these payments went through this week is because of the ridiculously low Risk Score that Stripe assigned some of the payments so our rules weren't triggered (why worry about a transaction if Stripe gave it a 0 out of 100 risk score?)
I really want to know how Stripe can assign a ZERO risk score to a customer using a card from a different country from the IP, with the wrong country in the billing address, with no CVC pass, and with a lot of related failed payments from different cards associated with the same IP/email. Madness.
Really sorry to hear about that experience — we need to do better here. If you want to shoot me an email (wmegson [at] stripe [dot] com) I can take a closer look at those specific charges. We are identifying those charges and are going to automatically refund any impacted transactions and waive the fees for those payments. We'll also waive the dispute fee (if a payment has been disputed).
The team is digging into why the risk score is low. In general, the types of signals you describe weigh pretty heavily in Radar’s risk assessment, and should result in higher risk scores. In this particular attack, fraudulent actors are using some pretty sophisticated scripts to try and obtain lower risk scores. We’re iterating quickly to address and stop these types of attacks and score them correctly going forward.
Hi dulse, while you are here, there is another issue with high-risk payments. You can see in your dashboard the count of "high-risk payments", but there is no way to actually review which payments were flagged as high-risk. This seems like it should be easy to implement. I'd expect there to be a report or filter here in the payments tab. I hope you can help!
But OP doesn't specify whether he's using Stripe Checkout integration (where stripe 100% control the landing page hosted in stripe domain) or other integration types (e.g. direct API call / embed which has higher risk). With Stripe Checkout integration type, you redirect users to a payment page hosted by stripe and have no ability to check whether the user is performing card testing there because the payment page is in stripe's domain, so stripe should be the one responsible with card testing prevention when using this discussion integration type.
That is a very hopeful (and naive) view of liability in the merchant processor space. By default all liability falls onto the business, not your merchant processor unless you specifically negotiated for a liability shift.
What can we do then? Stripe's own documentation recommends us to use Stripe Checkout because it's the most secure against card testing, and that checkout page is owned and operated by stripe so it's not like we can add custom card testing detection logic there.
I had a significant (to me) amount of EFT fraud that happened because of Stripe. Using Stripe Connect, I had a health-related marketplace application, and purported sellers would set up their bank account for EFT transfers -- and the bank accounts were CashApp accounts (technically the Cash App banking partner but still controlled by CashApp.) They then used stolen credit cards to "buy" services from themselves. Then the funds from the stolen cards would be transferred via EFT to the CashApp accounts. Then the charges would be challenged and reversed and the CashApp accounts were long-since emptied. Leaving me to personally pay for the fraud reversals (and charge back fees for each of the credit card transactions.) To the tune of over $27k.
Contacting Stripe about this (this was about 2 years ago) -- apparently this was all my fault -- despite CashApp "bank" accounts being bastions of fraud, and the credit card transactions all being from a single IP address. And I was given the run around since it wasn't my bank account used for the EFTs, so I didn't have a "fraud" claim and the stolen credit cards weren't mine either. But I was left holding the bag. Stripe took the negative balance out of my bank account.
Basically fraud is my problem even though their systems enabled it (for real, a simple check of an account routing number shows that it's the holding bank for CashApp, yet they allowed the EFTs without even the most cursory hold) -- but Stripe for years had no problem getting my more than 3% in credit card fees. Also the transaction size was far different than the typical transaction size that occurred for multiple years. But yeah, I get it, it's all my fault.
I contacted law enforcement with extremely detailed logs, even the geographic area where the transactions happened (down to the block of a neighborhood in Florida.) I contacted Stripe, I contacted CashApp. And nobody gave a shit because it wasn't their money.
If Stripe were on the hook for the fraud, I'd bet their systems would get really good in a hurry. As it is they not only didn't have any liability, they also made money from me on the chargeback fees. And CashApp doesn't care because it isn't their money either.
I'm working on a new startup project now and Stripe is not on my list of payment processors. I will never use anything Square-related ever again either. I realize that the others probably aren't any better, but that there was no empathy (and for weeks after, attempted fraud with Cash App banks accounts continued to be attempted, but I had manually blocked transfers to that specific routing number in my application code -- so I saw the fraud attempts continue long after.)
It's weird that Stripe has a rule you can use to block all prepaid cards, but has no rule for blocking CashApp and its ilk. (https://www.papara.com/en is another one we've been dealing with.)
I think of these "online wallet" services as effectively "VPNs for money": they give a fraudster who wants to get around some other form of blacklisting, as many additional credit card numbers to spread their tx volume across as they like — all with arbitrary credentials (because these cards are issued by "online banks" who never see their customers in person, so it's very easy to register accounts with purchased false identities. And people also just resell them: https://wmcentre.net/en/item/papara-vasha-turetskaya-zarubez...)
If I can block Tor IP addresses in Cloudflare, why can't I block these "money VPNs" in Stripe?
Are there any payment processors you can recommend, especially re. fraud protection? We have started out with stripe (because the API is so damn convenient), but HN has so many stories like this were seriously reconsidering that choice.
It's a shame that in every one of these threads someone from stripe steps in and promises to sort everything out for one customer, but the underlying issues never get resolved.
I'm not saying that fraud is an easy problem to solve, but I think you're absolutely right that this is a case of misaligned incentives. If it were Stripe's liability, it would get solved for _everyone_, rather than being in this middle ground where if you're lucky you might get help if you post on HN
It's hilarious. People pay them for a credit card fraud prevention service but end up taking on the actual fraud responsibility anyway. Stripe is providing zero value here.
[I lead Radar at Stripe] We're still investigating but have blocked the majority of this attack from the Stripe network. We're going to refund any impacted transactions and waive the fees for those payments. We'll also waive the dispute fee (if a payment has been disputed).
More broadly, we’ve seen an uptick in card testing attempts across Stripe. While the absolute rate of successful card testing across the Stripe network is flat-to-somewhat-down, it’s not evenly spread—some businesses are seeing more than others. For these new testing attacks, we’re deploying mitigants in real time.
Will your customers need to give you the full list of the refunded transactions? Since you couldn't detect them in the first place I don't imagine the fees will be automatically refunded?
Also, after posting this thread I just had to refund two more payments from an Indian IP address using a Singapore card with a billing address in the USA with a ZERO risk score. How does that make any sense? There is no CVC check listed and the zip check is "Unavailable"
I simply don't understand some of these scores
How could there not be a minimum risk score in a situation like this where none of the countries even match up...
I'm the OP of the Twitter thread – I've had the exact same experience: unrealistically low risk scores for most fraudulent transactions. There were plenty of red flags for each of them (400+ cards and 40+ names under one single IP, most payments got already flagged for credit card testing fraud early on before succeeding after many tries...) Even dumb heuristics would have blocked 90% of the fraudulent payments. I appreciate Stripe is fixing this quickly after making it public and refunding fees, but something is definitely wrong with their risk calculation algorithm.
I have experienced the same. An absolutely ludicrous set of suspicious data points like that and Stripe scores it a zero or near zero. We process hundreds of millions of dollars in transactions. Have gotten zero help from Stripe on this scoring.
We're going to automatically refund the transactions and fees, but also support any write-ins if you feel we missed any. (We have some ways to identify the transactions after they happen).
I agree with you, it's very counter-intuitive why these transactions are getting through Radar. We're iterating on some fixes right now that should stop this going forward by addressing this type of attack.
One way I can imagine this happening: if the carder is able to steal the cardholder's tracking cookie or other credential that Stripe trusts due to a previous legitimate transaction, and this causes Radar to disregard signals that would normally lead to a high risk score. (Just a hypothesis, I have no inside info.)
With the way they cycle through cards in the same checkout session I 100% don't think this is happening, but if it is then I wouldn't even blame Stripe at that point lol
What I’d love to know is: many fraudulent users try out different cards one after the other. How is it not the default case that Stripe blocks these users? It’s the most common pattern we see, easily identifiable by the repeated failed attempts with different cards.
Why did it take a Hacker News thread for you to actually do something useful about this? If this is the first time you're hearing about that it's a pretty severe failure of multiple layers of your customer service procedures. I certainly wouldn't recommend you guys versus other processors I've used at work who would actually do something about this when calling or emailing through the usual channels. This is a very "Google" way of handling things to have to Tweet or post on HN to get any kind of real support and it's very concerning.
Hi dulse, can you please make a public announcement with much more clarity. We received one of your alert emails but it was very cryptic with very little information and no mention this was happening across the network. Our fraud team spent two hours in a panic until we found this thread via Twitter.
This is not a new thing, it's a pretty standard MO of fraudsters to check if the cards they have purchased/stolen are going to work, i.e. have a value to resell.
New small businesses, particularly those that are potentially having a spike in sales (anything AI right now) are a good target as the operators may not have put into place their own monitoring and mitigation yet, but they have enough volume not to trigger an auto lock from the card processors.
Personally I have found Stripes fraud protection better than the competitors, however this thread has some good points about how some of these payments should have been auto-blocked.
Stripe does do pretty good, but I don't understand the scores for some.
I'm looking at a payment I refunded today with a ZERO risk score.
1 minute before this one went through, the same Stripe customer tried a different card and it was blocked with the message "Don't tell the customer that the card was reported lost. Instead, direct them to contact the issuing bank."
The same IP address has THIRTY blocked payments using dozens of different cards over the course of 2 hours.
Their IP address is in the USA and is a VPN. The card originated from Singapore. Their billing address is the Philippines. The name they used is "jake smith".
Again, ZERO risk score out of 100 from Stripe. What the hell...
You don't need any AI to properly reject these orders. In fact, using AI here merely opens you up to the possibility that fraudsters find a weird structure that the AI black box somehow labels as non-risky.
I'm annoyed that the title of my post was changed. I gave a description of what was happening and it has been changed to a random quote from the tweet
This makes it less clear that it is happening to more than a single company and the way it is quoted makes it sound like I am the same person as the Twitter poster
Stripe definitely isn't the only service experiencing this. A legacy system we're in the process of migrating has been hit with a large amount of these in the last month. In particular, they're trying to find the expiration date for the cards - they firehose a hosted payments page with as many card numbers as possible but the same expiration month and year in hopes of hitting the lottery.
We found them to be coming from the same email address. Even when we removed the customer from our system, they'd create a new profile with the same email. To solve the problem in the short term, because they insisted on using the same email every time and were being absolutely relentless - whenever they logged in to a profile with that email, I redirected them to a dummy checkout page. That bought me enough time to write some rules that if someone makes more than X simultaneous connections, it blocks their IP and presents a "please call us" message.
They've tried about a dozen times in the last couple weeks, and they keep shutting themselves down by trying to scale up to a ridiculous number of connections.
The behavior seems strange. They insist on using the same email address and they do nothing to change their approach.
So, I have relevant knowledge in the credit card fraud prevention industry, and Stripe looks so weird to me. What are you paying for? If Stripe isn't taking on the liability for incorrect scores, they could literally just be returning mostly random results and you would be no better or worse off. If you have to implement rules on top of their system, you are doing their job for them.
Is there really nobody you can pay to do the credit card derisking for you?
Exact same pattern at my AI start-up. Custom Stripe Radar rules seem to solve the bulk of the issues, but inevitably real customers get caught up in the mess as well.
There is an infuriatingly high amount of obviously fraudulent charges though with a very low Stripe risk score that only custom rules catch.
Thank you to the Stripe team for finally taking this seriously and stepping in to resolve this. My guess is that prior to today, this was never elevated to the proper people for real action.
Until then, if your name is Jake Minas and you're trying to get a subscription: I am sorry.
I had the opposite issue -- something like 90% of genuine payments on my account are rejected by the fraud detector on the first try and have to be retried daily for several days before going through. I exchanged over a hundred emails with support in which they read the card testing script to me, tried to upsell me on "better" fraud management tools, disregarded any details I provided to show that the activity was non-fraudulent, gave me no insights into how the fraud detector worked or why it might be giving false positives, and refused to escalate my ticket anywhere. I had to beg to be put through to an engineer who knew anything about it, and still I couldn't get past front line support. Long gone are the days where you can talk to a Stripe engineer on IRC. Really badly soured me on Stripe and I started working on plans to move away from the platform entirely.
What's the motivation for this sort of attack? I'm quite sure chargebacks only ever put money back into the cards from which the money originated (i.e. the stolen credit cards; not into the attacker's account), which makes it seem kinda pointless.
They use debit cards usually and they try to push a small dollar amount on the card to see if it is valid/will work.
Basically, someone farmed a bunch of numbers, sold it to someone, that new owner is now testing them to see if they can sell them further to others / launder the money off them.
I’ve been using stripe for about a decade on my small SaaS. This is extremely common, and all those custom rules are familiar. Stripe has the tools to deal with it, but you must configure it. I wouldn’t fault stripe as much as the training/docs on setting up a stripe account should include how to protect yourself from these. We’ve managed to get it down to a few fraudulent refunds per week. It’s still a big time sink. We have to implement all sorts of pre-fraud triggers within our app to try to catch them as early as possible. And review recent subscriptions daily. This seems to be the nature of the beast. A cost of doing business is losing card disputes.
Agreed, being able to set the rules the way they allow is very powerful and once configured should basically get rid of these attacks. But why does every merchant have to learn what rules need to get setup to prevent these attacks, it seems silly.
I believe in this case its that AI is hot right now, so AI SaaS companies are potentially getting a ton of new subscribers, charges, etc. So carders try to sneak into that traffic when testing cards so they go unnoticed.
What do you mean? AI companies seem to be getting targeted here. Could be happening to other companies too but the founders in that thread are all from AI-related companies from what I've seen (I avoid Twitter as much as possible though)
The easiest win I've come across is adding a CAPTCHA when requests exceed a certain threshold. Yes, CAPTCHAs suck, but this way 99.9% of users don't have to deal with one.
I know hn is not crypto friendly but crypto payments don't have this problem at all. Many of the heurestics used to defend against these problems too end up hurting we those in emerging markets including even cards issued by local banks. I hope merchants adopt crypto based payments more and more as an alternative.
Crypto not supporting chargebacks/disputes is not a feature. CC companies / processors are required by law to support these workflows as consumer protection.
This situation can still happen exactly in a crypto world, but it’s the consumer getting screwed instead of the business.
In the stripe scenario, consumers have had their CC info stolen. Bad actors are now working through that list, abusing this business.
In a crypto world, a consumer would have their key pair stolen and immediately be completely broke because everything can be instantly and irrevocably stolen.
Understood but in the case of crypto, you don't hand over your private keys to third-parties unlike cc where you have to hand over every information about your card in order to make payments. Thi is the main vector of stolen credit cards so I fail to see this as a serious problem.
There's an unfounded assumption in what you're saying: people make mistakes. In the current system without non-repudiation, we can repudiate our mistakes and get our money back. In your crypto-based system, if someone tricks me into divulging my keypair and impersonates me, I can't repudiate that transaction so it's gone forever. And so you're perpetually one mistake away from losing everything which was what the consumer protection laws are protecting you from in the current system. They protect you from losing everything for one mistake.
Crypto is stolen every day. You can argue the theoretics of it but if you search google or Twitter for "crypto stolen" you'll get tons of results every day of people having their funds unexpectedly drained.
Crypto maxis always like to argue that crypto theft isn't possible, but the reality is it happens a lot and there's no recourse when it does (which is what makes it an attractive target).
This isn't really a property of cryptocurrencies, but a property of signed transactions. We could absolutely have traditional banking transactions online where you don't give the information to the PoS that is sufficient to create a new transaction. In fact, this is exactly what chips are doing in an in-person transaction. The hard part here is getting everybody to have the right equipment and software to sign these transactions when purchasing stuff online.
Cryptocurrency does not actually solve this problem. It just gives people a greater incentive to push through the pain of solving this problem.
There's zero possibility for tech to fix the main step of fraud in money, which is social engineering. Being unable to fix a mistaken transaction is not a feature.
I thought about that. Funny enough crypto and CCs are very much based on the same model.
CCs have chip mode. Chip mode transactions are impossible to spoof. They are one time transactions protected with nonces and very good cryptography. But CCs have a weakness when used online because you have to enter in your secret numbers to use them. When these secret numbers are entered into a fraudulent website, that bad actor now has access to your card _until the CC company stops it_, either at your discretion or their own.
Crypto is quite fancy, but you can’t solve wrench problems [1] with technical solutions. Consumers are still going to fall for phishing attacks, they will still accidentally loose their keys. The only difference is the consumer has no recourse. They are good and properly screwed.
Example: someone holds you at gunpoint and demands your secrets. With CCs you just hand them over, then as soon as you can call in and dispute all charges. If a guy with a gun demands your pub/private Keys, I’m not sure what you would do.
I supposed that is a boon for business, and business rules America, but unfortunately this is another problem that crypto does not solve.
What is holding back Bitcoin adoption for small online payments? With Bitcoin, a payment is a payment. So this problem would never occur.
The two arguments I often hear are "losing keys", which would not be a big issue for small amounts, and "fees", but that is avoided via the Lightning Network these days.
Is it that every payment is a taxable event, so it is too cumbersome for the customer because of taxes?
I'm trying to relate this comment with the one you're replying to, but I'm not seeing how that led to the assumption that people are giving their CC # to random websites.
You can make a mistake or get scammed using well-established websites, after all.
It is a big loser for the buyer. What if the seller is fraudulent? Now you are out on the BTC and there is absolutely no protections or regulations on getting that money back. Why wouldn't you just use your credit card with excellent consumer protections provided by your issuer?
It doesn't actually solve anything from a KYC or trust perspective, which is at the root of lots of these problems. A good interaction is "I, the buyer, have money, you, the seller trust me that I have the money that I am digitally transacting to you. After the sale is made, the transaction clears, I have less money, you have the money instead." This contract breaks when either side doesn't do their job -- provide the money for the service, provide the service for the money. BTC doesn't solve this for both parties.
Well that's what Paypal (and Stripe) essentially is.
As a seller, I don't have to implement PCI compliance, deal with an acquirer bank to process transactions, fraud checks, whatever - I link up the Paypal/Stripe/... account to my shop and that's it.
And as a customer, I don't need to trust Joe Random's webshop with my CC details, and I have a reasonably well working customer support when the seller turns out to be shady.
> What is holding back Bitcoin adoption for small online payments?
Bitcoin is pretty high friction, and comes with a bunch of downsides (no recourse for errors/scams, value volatility, etc.) that are important to some people.
Not to mention that the cryptocurrency world is generally full of shady actors and many simply don't want to be associated with that.
> What is holding back Bitcoin adoption for small online payments? With Bitcoin, a payment is a payment.
you need easy ways for people to get into Bitcoin. A CC (or in Europe, SEPA direct debit) is easy, customers are already used to this, and it works hassle-free.
Meanwhile, Bitcoin? If you're not set up with an exchange already, you need to set up an account, pass through KYC crap which may take hours, and only then you can pay. The only kind of services worth that effort are truly anonymous VPNs and servers or drugs.
Lightning is not needed at all and is used by non legitimate actors. LN is also not widely adopted worldwide and doesn't solve any problem that is better than what already exists with credit cards.
Contacting Stripe back then was a complete waste of time.
We implemented a bunch of rules manually which mostly fixed the issue and I reached out to support to ask if there was anything else we should do.
A few days later they said we need to "take immediate action" and offered only generic advice.
I told them what we already did (implementing the Radar rules manually) and they said oh yeah seems fine, looks like it stopped. But the kicker is we did that before they reviewed our account and told us we needed to take action. What a joke.
This was after spending tens of thousands in fees in a single month with them.
The only reason some of these payments went through this week is because of the ridiculously low Risk Score that Stripe assigned some of the payments so our rules weren't triggered (why worry about a transaction if Stripe gave it a 0 out of 100 risk score?)
I really want to know how Stripe can assign a ZERO risk score to a customer using a card from a different country from the IP, with the wrong country in the billing address, with no CVC pass, and with a lot of related failed payments from different cards associated with the same IP/email. Madness.