[eeke]

Card issuers are often able to detect that a transaction is fraudulent before it is disputed, and when this happens, they will send us a notification. These notifications are commonly called TC40s (Visa) or SAFE reports (MasterCard). On average ~60% of early fraud warnings end up being disputed, and most disputes have an early fraud warning (though there’s a wide range depending on your business). If you refund these charges before they become disputes, you can avoid the dispute entirely. It doesn't solve all dispute problems but it can be pretty effective. I’m happy to take a look at your account to calculate what percent of disputes have an early fraud warning.

[jacquesm]

It's telling for the industry as a whole that the card companies failure to do their work properly still can result in extra charges to the merchant.

After all card companies have a tremendous amount of data at their disposal and are apparently able to detect a large percentage of fraud before a dispute is raised and yet do not pre-emptively block the charges or reverse the transaction.

I've been on the receiving end of these kind of dispute resolution processes and in spite of doing everything by the book we still ate quite a few chargeback fees on charges that to us looked just as legit as every other charge that passed through. (Not with Stripe though.)

[pas]

They optimize this for max profit. Of course. So they found that this is the sweet spot, that generates the maximal volume while keeping fraud to minimum (also keeping users as happy as they can - that is not bothering them with preventative measures, and then of course making it easy to do chargebacks).

[scrollaway]

60%… I've had some of my customers' cards get reported as stolen, and a recurring charge pop up (on a customer who had subscribed months ago) and get flagged. I do not act on it, a dispute gets filed, and the customer wins the dispute despite me providing evidence that this was clearly an intended charge (and clearing that up with the customer afterwards!).

Winning a dispute on Stripe has always felt impossible to me. I stopped trying after a while, and just let the disputes default to a loss after they time out.

[Silhouette]

We're about 50/50 on the relatively few chargebacks we've had. In 100% of the cases, it was a genuine charge for a real customer, the customer openly acknowledged that when contacted, and this evidence was supplied as part of the dispute.

Our customers have generally been responsive when asked about a chargeback. It seems like in many of the cases there really had been a problem with their card being stolen or the like, but often all subsequent transactions had been disputed by the card issuer, even long-standing recurring charges. It wasn't clear in many of these cases that the customer had requested this, or even knew that it was happening.

Even when customers assured us that they had personally contacted their card issuer to tell them a charge was legitimate, that was no guarantee that the chargeback would be cancelled. Unless we have customers who are spending considerable time writing apologetic emails to us and offering to pay us some other way and yet for some reason lying about that contact, the card issuers aren't keeping up their side of the bargain here.

In 0% of cases was it worth the time we spent putting together comprehensive evidence to dispute a chargeback, even when we won. Like scrollaway, we just don't bother now.

If you have a system where a charge can just be arbitrarily reversed and it's not worth fighting it as the merchant even if you have overwhelming evidence of its legitimacy, that tells you how legitimate the whole system is, doesn't it?

[PatrolX]

But wait, what about Stripe Radar?

If card issuers are "often able to detect that a transaction is fraudulent before it is disputed" (presumably because of transaction history) then why can't Radar block the transaction from ever taking place? Maybe there's more to it than transaction history? Can you clarify?

[patio11]

Here's a stylized example which may help:

Monday: credit card does a transaction at a particular business.

Thursday: user calls bank to report card stolen as of previous Sunday. This kicks off a TC40 on all transactions on or after Sunday.

Friday: bank staff and/or user walk through the transactions which were post-theft, figure out which ones were still authorized (e.g. the recurring Netflix bill), and file disputes on all the other ones.

Since there is no way to send the TC40 back in time to Monday, it can't influence the fraud scoring run at the time of the transaction. But there is, in this stylized example, a window between the TC40 and the dispute for the business to proactively investigate and possibly refund.

[jacquesm]

> But there is, in this stylized example, a window between the TC40 and the dispute for the business to proactively investigate and possibly refund.

There is also a perfect opportunity for the IPSP to flag the transaction and reverse the transaction before it becomes a problem for the merchant.

[globile]

Isn't this what Ethoca and Verifi do?

[michaelt]

  Card issuers are often able to detect
  that a transaction is fraudulent before
  it is disputed, and when this happens,
  they will send us a notification.

Is there a mechanism like that but in the reverse direction? i.e. if a seller detects someone testing stolen cards, and wants to alert the card issuer all those cards are stolen?

[michaelmior]

Shouldn't the issuer be able to figure this out on their own when they see the attempted charges coming in? It seems like the resources of the issuer would be better spent improving their own detection rather than dealing with third-party reports.

[michaelt]

Retailers might enjoy better information (account history, items in basket and suchlike), might have already borne the cost of manually checking the order, or might have better incentives (as it's them who loses money if an order was placed with a stolen card)

After all, if the issuer had been able to figure it out, the payments would have failed preauthorisation.

[jacquesm]

Too much abuse potential, for instance, a software error could flag 'good' cards as 'bad' and cause a lot of headaches for other merchants.

[MichaelApproved]

I think Strip has a report fraudulent transaction feature. I've had someone do several $1 test charges on a donation page for a charity I managed. I was able to report the approved cards as fraudulent transactions.

This was many years ago. At the time, I think it was a beta feature so I'm not sure if it's been rolled out to everyone yet.

[ascar]

You are proposing he should also proactively refund the other ~40% of valid purchases to avoid the ~60% that end up in disputes? Did I get that right? If yes, that doesn't sound like a viable idea.

[URSpider94]

If it’s a SaaS business, that may very well be a viable approach. The cost of dealing with a dispute on the 60% of claims could be significantly more than the profit on the 40% that won’t be disputed. Additionally, the customers only get back the money for the disputed transactions, not perpetual future access to the software (as they would if it were a physical good, or a shrink-wrapped disc).

[dennisgorelik]

"the other ~40%" -- are NOT necessarily valid purchases. Most likely they are fraudulent purchases that were not charged back.

[zenexer]

That’s pretty cool. Is this something Stripe customers have to pay an additional fee to access, or is it included?

Another question: what’s the percentage of false negatives?

[eeke]

It’s included! And, in fact, we just launched the API publicly.

https://stripe.com/docs/disputes#early-fraud-warnings https://stripe.com/docs/api/radar/early_fraud_warnings

As for the percentage of false negatives, it really depends on your business. We definitely recommend looking at your own early fraud warning and disputes history to determine what makes the most sense for you.

[dthedev]

It says on the page, the service costs 0.4% per transaction.

[jtbayly]

That's for the service in the original link. Not sure that's the same for the potential service under discussion here.

[numlocked]

Yes, but the only way to get that data is to read an email that Stripe sends. There is no programmatic access to the data.

[Havoc]

60%...wow.

Cool - thanks for answer Q