[eeke]

We can send you a webhook on every dispute being created (https://stripe.com/docs/webhooks) and you could use the API to either refund the underlying charge or accept the dispute (and refund the underlying charge).

We can also give you access to receiving early fraud warnings from issuers (like Visa TC40s). These are notifications from the issuers that the customer is likely going to dispute a charge. If you're happy proactively refunding customers you could do so without incurring the dispute fee (though TC40s and the MasterCard equivalent can still count towards monitoring programs). Let me know if you're interested ([e-mail]).

This gets you most of what you want. The subtleties:

1) The credit card ecosystem wants to discourage chargebacks as a routine mechanism for canceling, and so there will still be a fee assessed by the networks and hence by us.

2) The credit card networks have thresholds for how many chargebacks a customer can be doing while making responsible use of their rails, and if one routinely exceeds that, they will give a very serious warning to change business practices and, if one’s numbers do not improve, they will terminate one’s access to the rails. We have substantial experience with B2B SaaS businesses and it is _extraordinarily_ unlikely that a B2B SaaS business comes close to those thresholds, even after accounting for unfortunate user behavior.

[jasonkester]

How does that work? When I'm notified of a dispute, the first thing I do is go in and refund the charge. I still have to watch the whole dispute resolution process play out and have it be ruled against me.

How would I go about stopping it before it starts, as you seem to imply is possible?

Edit to add: Does it even make a difference if I go in and refund the disputed payments? It sounds like I get dinged either way and the customer gets their money back either way. Should I save myself the effort?

[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

[MichaelApproved]

Doesn't sound like they're implying that it's possible.

Sounds like they're allowing you to automate the dispute process but it'll still be a negative mark on your account.

Side note, are you getting anywhere near the number of disputes for this to matter to you? Seems like you have good refund policies and you'd probably be below the threshold for account termination.

[Filippoi]

> We can send you a webhook on every dispute being created (https://stripe.com/docs/webhooks) and you could use the API to either refund the underlying charge or accept the dispute (and refund the underlying charge).

Unfortunately, I don't think that's possible.

On Stripe, attempting to refund an actually disputed charge results in an error / invalid request.

https://stripe.com/docs/error-codes#charge-disputed

It does work for inquiries but I am not sure how often those happen vs. "proper" declines/chargebacks. I'd assume the majority is of the latter type.

[kweks]

Refunding a charge back is / can be a bad idea - you can refund, still lose the charge back, and pay for the chargeback. For a $100USD transaction you risk losing 230USD as opposed to 130USD if you refund. It's even written on the dispute page on stripe to avoid refunding charge backs

[gist]

Is it possible to have the extra fee (.4%) only on some transactions or does it have to be applied to the entire account? For example in what we do we have very large transactions where we know the customer very well and we don't need this. But other transactions are typically small but more importantly they are of a different type where the risk of fraud is much higher and the protection is warranted. Just wondering other than getting setup for two different accounts (which may not even be possible) how this situation would be handled. I do understand the idea of wanting the .4% not applied selectively however it would be good if there was a way to specify the transaction class in some way to account for this situation.

[JamesBarney]

I think this request is like going to a $60/month gym and asking to only pay 2$ when for days you go the gym because you only use it 10 times a month. The .4% on good transactions is subsidizing the shitty transactions.

[huac]

adverse selection ;)

[flibble]

> We can also give you access to receiving early fraud warnings from issuers (like Visa TC40s).

Can we get webhooks for these? We currently have to manually refund charges when we get the ‘suspicious transaction’ email from stripe, which is a pain.

[puddingpop]

You can indeed get a webhook for these: https://stripe.com/docs/api/events/types#event_types-radar.e...

(disclaimer: I work on Radar at Stripe)