6 ms·

We've been targeted with a credit card testing fraud attack on Stripe

weird-eye-issue 3y ago
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.
- dulse 3y ago
  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.
  - mchusma 3y ago
    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!
    - dulse 3y ago
      Thanks for the feedback! Will take a look at this, agreed that sounds easy and helpful.
  - neurostimulant 3y ago
    I'm under impression that we basically don't need worry about card testing if we're using Stripe Checkout instead of direct API calls. Is that true?
    - weird-eye-issue 3y ago
      No, that's clearly not true. Otherwise this thread would not exist
      - neurostimulant 3y ago
        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.
        simfree 3y ago
        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. Stripe will not eat the fees for card testing.
- briandear 3y ago
  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.)
  - weird-eye-issue 3y ago
- WirelessGigabit 3y ago
  Wait, let me get this straight: Stripe gives you a score and can still complain? What's the incentive for them to give you an accurate score if they make money anyway?
  - mrguyorama 3y ago
    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.
samwillis 3y ago
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.
- weird-eye-issue 3y ago
  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...
  - liveoneggs 3y ago
    they don't AI hard enough
    - mrguyorama 3y ago
      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.
      - throwway120385 3y ago
        Which is one of the concerns I've had about AI/ML since it became in vogue to use it for these problems.
JonathanBeuys 3y ago
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?
- deleted 3y ago
  [deleted]
- weird-eye-issue 3y ago
  Oh yeah let's re-hash this conversation for the millionth time. Seems really productive.
  - JonathanBeuys 3y ago
    Im on HN quite a lot, but have not seen a discussion on what holds Bitcoin over Lightning back for online payments.
    - colesantiago 3y ago
      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. Especially with no dispute mechanism either. So no thanks to crypto at all.
- ceejayoz 3y ago
  > What is holding back Bitcoin adoption for small online payments? With Bitcoin, a payment is a payment. So this problem would never occur. Consumers largely don't want a "got scammed? you're fucked, no chargebacks!" payment method.
  - JonathanBeuys 3y ago
nomilk 3y ago
Relevant tweet from one of the founders mentioned in the OP tweet: https://twitter.com/levelsio/status/1665625055777398784 https://twitter.com/levelsio/status/1665625055777398784
- mliker 3y ago
  What kind of businesses are susceptible to this type of attack? Do companies multiplex into Stripe and other payment providers to mitigate the risk?
version_five 3y ago
What is the AI angle? Does it stand for something else here?
- weird-eye-issue 3y ago
  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)
- jmuguy 3y ago
  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.
  - version_five 3y ago
    Ok. The title implies that it's something active that's happening related to AI companies which is confusing (and incorrect).
ruffrey 3y ago
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.
- weird-eye-issue 3y ago
  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. Also what is up with their risk score in situations like this: https://news.ycombinator.com/item?id=36197303 https://news.ycombinator.com/item?id=36197303
christkv 3y ago
Anybody have a good list of suggestions on pre verification strategies and is this a big problem when you run thirty day free trials?
- whakim 3y ago
  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.
nomilk 3y ago
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.
- weird-eye-issue 3y ago
  It is in the title. "Card testing" - Google it
  - nomilk 3y ago
    Ah, the attacker learns if the card really works.
- darkwizard42 3y ago
  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.
- acomms 3y ago
  Theories are discussed in the linked thread
dulse 3y ago
[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.
- weird-eye-issue 3y ago
  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...
  - rameerez 3y ago
    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.
  - dulse 3y ago
    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.
ddevault 3y ago
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.
- mwcampbell 3y ago
  Have you decided yet what you'll be moving to?
  - ddevault 3y ago
    Mollie.
hunkins 3y ago
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.
weird-eye-issue 3y ago
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
- gurjeet 3y ago
  I've seen this happen to a few others, including myself, when it's clear that the title was thoughtfully created to convey something substantial. The way I've made peace with it is to think "not my platform, not my rules", and let others change the title to whatever they please.
yaa_minu 3y ago
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.
- andrewxdiamond 3y ago
  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.
  - yaa_minu 3y ago
    In what ways would a consumer be screwed if crypto payments become dominant? I'm genuinely curious
    - andrewxdiamond 3y ago
      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.
      - yaa_minu 3y ago
        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.
        andrewxdiamond 3y ago
Pete-Codes 3y ago
Sadly seen this all over my timeline today
mrguyorama 3y ago
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?
xtrohnx 3y ago
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.
cvalka 3y ago
Why not mandate 2FA?
siburo 3y ago
[flagged]
siburo 3y ago
[flagged]

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.

dulse 3y ago
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.
- mchusma 3y ago
  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!
  - dulse 3y ago
    Thanks for the feedback! Will take a look at this, agreed that sounds easy and helpful.
- neurostimulant 3y ago
  I'm under impression that we basically don't need worry about card testing if we're using Stripe Checkout instead of direct API calls. Is that true?
  - weird-eye-issue 3y ago
    No, that's clearly not true. Otherwise this thread would not exist
    - neurostimulant 3y ago
      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.
      - simfree 3y ago
        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. Stripe will not eat the fees for card testing.
briandear 3y ago
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.)
- weird-eye-issue 3y ago
WirelessGigabit 3y ago
Wait, let me get this straight: Stripe gives you a score and can still complain? What's the incentive for them to give you an accurate score if they make money anyway?
- mrguyorama 3y ago
  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.

samwillis 3y ago

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.

weird-eye-issue 3y ago
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...
- liveoneggs 3y ago
  they don't AI hard enough
  - mrguyorama 3y ago
    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.
    - throwway120385 3y ago
      Which is one of the concerns I've had about AI/ML since it became in vogue to use it for these problems.

JonathanBeuys 3y ago

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?

deleted 3y ago
[deleted]
weird-eye-issue 3y ago
Oh yeah let's re-hash this conversation for the millionth time. Seems really productive.
- JonathanBeuys 3y ago
  Im on HN quite a lot, but have not seen a discussion on what holds Bitcoin over Lightning back for online payments.
  - colesantiago 3y ago
    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. Especially with no dispute mechanism either. So no thanks to crypto at all.
ceejayoz 3y ago
> What is holding back Bitcoin adoption for small online payments? With Bitcoin, a payment is a payment. So this problem would never occur. Consumers largely don't want a "got scammed? you're fucked, no chargebacks!" payment method.
- JonathanBeuys 3y ago

nomilk 3y ago

Relevant tweet from one of the founders mentioned in the OP tweet: https://twitter.com/levelsio/status/1665625055777398784 https://twitter.com/levelsio/status/1665625055777398784

mliker 3y ago
What kind of businesses are susceptible to this type of attack? Do companies multiplex into Stripe and other payment providers to mitigate the risk?

version_five 3y ago

What is the AI angle? Does it stand for something else here?

weird-eye-issue 3y ago
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)
jmuguy 3y ago
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.
- version_five 3y ago
  Ok. The title implies that it's something active that's happening related to AI companies which is confusing (and incorrect).

ruffrey 3y ago

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.

weird-eye-issue 3y ago
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. Also what is up with their risk score in situations like this: https://news.ycombinator.com/item?id=36197303 https://news.ycombinator.com/item?id=36197303

christkv 3y ago

Anybody have a good list of suggestions on pre verification strategies and is this a big problem when you run thirty day free trials?

whakim 3y ago
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.

nomilk 3y ago

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.

weird-eye-issue 3y ago
It is in the title. "Card testing" - Google it
- nomilk 3y ago
  Ah, the attacker learns if the card really works.
darkwizard42 3y ago
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.
acomms 3y ago
Theories are discussed in the linked thread

dulse 3y ago

[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.

weird-eye-issue 3y ago
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...
- rameerez 3y ago
  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.
- dulse 3y ago
  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.

ddevault 3y ago

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.

mwcampbell 3y ago
Have you decided yet what you'll be moving to?
- ddevault 3y ago
  Mollie.

hunkins 3y ago

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.

weird-eye-issue 3y ago

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

gurjeet 3y ago
I've seen this happen to a few others, including myself, when it's clear that the title was thoughtfully created to convey something substantial. The way I've made peace with it is to think "not my platform, not my rules", and let others change the title to whatever they please.

yaa_minu 3y ago

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.

andrewxdiamond 3y ago
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.
- yaa_minu 3y ago
  In what ways would a consumer be screwed if crypto payments become dominant? I'm genuinely curious
  - andrewxdiamond 3y ago
    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.
    - yaa_minu 3y ago
      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.
      - andrewxdiamond 3y ago

Pete-Codes 3y ago

Sadly seen this all over my timeline today

mrguyorama 3y ago

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?

xtrohnx 3y ago

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.

cvalka 3y ago

Why not mandate 2FA?

siburo 3y ago

[flagged]

siburo 3y ago

[flagged]