Comment by weird-eye-issue | Hacker News Reader

Comment by weird-eye-issue | Hacker News Reader

weird-eye-issue

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!

Thanks for the feedback! Will take a look at this, agreed that sounds easy and helpful.

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?

No, that's clearly not true. Otherwise this thread would not exist

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.

Stripe will not eat the fees for card testing.

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.

Radar fraud rules. Like is already discussed in the Twitter thread. How hard is it to read?

I admit I didn't scroll too far down beyond the signup modal.

You are so naive (and wrong) lol

Also, it is mentioned in the thread they are using Stripe Checkout (we are too)

I'm the thread OP – can confirm we're using Stripe Checkout and all CC processing happens in a fully-managed Stripe Checkout page.

We're not using any other API from Stripe other than that required to launch the hosted Checkout page.

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

Yikes

Basically Stripe facilitated money laundering and then left you on the hook for it while happily taking fees from you

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

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?

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.

Reply on news.ycombinator.com