On your second question, there is a zero-trust way of using Retool via our self-hosted version, which installs in a few minutes via Docker (https://retool.com/self-hosted/). If you want, you can even fully airgap your Retool instance such that no data goes in or out. (In the future we are also thinking about how we can integrate with credentials stores!)

We have something for exactly this situation shipping very soon! Happy to give you beta access if you'd like to drop me a quick note from the email you signed up with (eeke@retool.com).

Well, no wonder your business has great traction when you are so involved :) Thank you for the invitation! I've just sent you a msg from an inbox starting with tylkointernet

I head up product at Retool. I’m sorry to hear about the issues here. We’ve been heads down on improving the performance of apps like yours by moving work into the server-side, re-architecting parts of our codebase, geolocating our servers closer to users, and a number of other initiatives. We’re releasing these improvements as we prove their efficacy, while other improvements are under more experimental feature flags. If you’re interested, our engineering team would love to get these safely turned on for you—Just reach out to me at eeke@retool.com.

Thanks for your comment. We want our products to substantially decrease the barriers to international commerce, and they’re used by both businesses which are just getting started up to multinational companies with extremely sophisticated understanding of their payments needs.

Auth rates are a deep topic, and one we’re experimenting on constantly.

The topic of whether a particular business will get better auth rates going through a local gateway is a complicated one (that is probably true of many businesses and not true of many businesses); we’re working on making this sort of thing unnecessary for most businesses to think about. Philosophically, centralizing this sort of work at Stripe makes a lot of sense to us; we can deploy more engineers against auth rates than any Stripe customer could because we have a much larger surface area for improvement than any customer does.

Many of our users want something which works out of the box, and they’re the target audience for Checkout. If you want to rigorously test the behavior against your sophisticated understanding of conversions in your own business, that’s awesome; you can see exactly which transactions we flagged for being on the fence using the API.

It’s always a balancing act to make things which work out-of-the-box for someone’s first business on it’s first day and still have the power and configurability expected by extremely sophisticated operators. Getting this balance right is extremely important to us.

Thank you for your many detailed replies here! This idea that parent brought up is one I've heard before: Stripe declines payments that a local gateway service would have accepted, for reasons unrelated to fraud protection. That's always made me scratch my head because my (admittedly primitive) understanding is that you're eventually hitting some API at the bank which accepts or declines the charge. Why would it matter whether it's Stripe hitting it or some other gateway? I assume Stripe has more resources to attack such problems than your average Mexican gateway provider, so there must be some intractable problem in there somewhere?

We switched from stripe to local payment gateways in some countries because some banks automatically convert any charge by stripe to USD making it more expensive for the end client and refusing in some cases the charge, when in local gateways everything goes through in the local currency.

Additionaly stripe charges their 2.5% to 3% + 2% conversion fee making it impossible some business models that are low margin.

(PM for Chargeback Protection.) Yep, Chargeback Protection only works with the new Checkout so we’ll only protect any transactions that are processed through the new Checkout. You can keep your existing integration for iOS and Android, but those charges will not be protected.

(PM on Chargeback Protection here.) We are rolling out with our new Checkout first because it allows us to tweak the checkout flow and e.g. send a payment which we’re on the fence about to 3D Secure (3DS) but let obviously good payments go through without 3DS. We are also exploring ways to expand Chargeback Protection to other integration options!

Thank you so much for your work on this! Really hoping you expand this to elements. (See my comment at the root level.)

This is a game-changer. We do all or nothing semi-annual educational events and fraudulent chargebacks are a HUGE source of anxiety.

.4% seems to be a very fair percent as well to charge to make this problem just go away for businesses like ours.

We happily refund customers that go through normal refund channels, but fraudulent chargebacks are a significant source of stress and revenue uncertainty.

Just last night I was shaking my head as I stumbled across an email from a customer confirming that her friend referred her to our event and that she was coming. But then a couple months later she changed her mind. We told her it's way too late for us to give her a refund on her deposit (which was clearly stated to be non-refundable in the first place). So she told her credit card company that she doesn't recognize the charge.

Even though we added her emails to our dispute evidence, and submitted evidence that she was aware of the non-refundable policy for ticket deposits, we still have no idea whether we'll actually win the dispute.

Incidents like this are a major source of frustration, and your solution is going to help us operate with less uncertainty.

Hi Eeke. A few years back, we lost a merchant account with stripe due to an unfortunate combination: no chargeback insurance enabled, high average transaction value (~600EU) and low monthly volume (we were starting up).

Got one charge back for 800EU that blew us out of the water. Would there be a mechanism to re-apply, with CB protection enabled ?

We struggled to have this discussion with a Real Person at Stripe to discuss this .. would you have any leads ?

Hrm, I'm sorry for that struggle. I'd like to look into this—could you email me directly at edwin@stripe.com and I can review what happened (and see if we can help you get set up again)?

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 (eeke@stripe.com).

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.

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?

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.

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

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

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.

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?

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?

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.

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

  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?

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.

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.

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

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.

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.

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

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

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?

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.

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

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

60%...wow.

Cool - thanks for answer Q

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.

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

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

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.

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.

adverse selection ;)

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

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)

(I work at Stripe on Radar.) We see Chargeback Protection mostly as a way to prevent our users from burning too much founder attention doing chargeback management. Managing abusive use of the credit card rails, both by fraudulent businesses and by people attempting to defraud legitimate businesses, is something that we have substantial experience with. We have had years to tune our machine learning models; this both helps every user of Stripe (through blocking transactions likely to be fraud-y) and gives us the confidence we need to roll out a new product like Chargeback Protection widely.

We will, of course, monitor it during the rollout and adjust as we go.

> prevent our users from burning too much founder attention doing chargeback management

Yikes. Yes. Thank you. I wish i had this 2 months ago.

Thanks for the feedback! Our first priority at the moment is seeing how this performs and then rolling out additional integration options, but we might explore giving users additional control over the mechanics as time goes on.

I’m the PM on Chargeback Protection. Startups told us they don’t want to deal with the hassle and unpredictability of chargebacks; that’s why we built this. Happy to answer any questions you have.

0.4% is an extremely steep price for a company like mine doing over $2.5m in annual turnover (saas) which has a very low fraud rate. I actually think currently we pay less than that by doing nothing (meaning letting Paypal handle it, and losing every case). However I'd gladly pay a few thousands per year for it, or be able to pay it on selected transactions (only US for instance).

Then this offering isn't cost effective for you and you can ignore it. I'm not sure I understand why this thread is full of people complaining it doesn't solve a problem this solution isn't targeting, or, like you, saying this costs more than simply accepting your low chargeback rate. When I rent a car, I decline the offer for me being able to return the car without gas because for me, it's trivial and cheaper for me to refill the car. I don't complain that the price should be lower, or that they should instead be offering sunroofs on more cars.

And I'm the opposite. I return the car empty every time, because the cost of "finding a gas station" when you're in a hurry to catch a flight isn't worth the extra $X they charge for the service to fill it. Choices are great!

It’s called product feedback. You are also complaining about the poster’s complaining, which is essentially the same thing.

> However I'd gladly pay a few thousands per year for it

0.4% on $2.5m is $10k a year. I realize "ten" is a bit more than "a few", but is Stripe's price point materially that far off from where you want it to be?

Said another way, I imagine that there are at least a few problems smaller than chargeback protection at your company that you throw $10k or more at just to make that problem go away... right? If so, this makes their price somewhere between reasonable to good.

I am really curious about your thinking on their price as it relates to other expenses in your company. Could you expand on that?

What he's saying is that currently doing nothing costs him less than what paying 0.4% to 'insure' transactions would, so why bother with insurance?

Ultimately established companies know how much chargebacks cost them and thus whether this product is worth it (= costs less).

Another thing to take into account is that if you're not using Stripe Checkout now, you will have to migrate to it, and since Dynamic 3DS will be used to filter and "secure" potential fraud, you will probably see a decrease in conversion rate.

welp I'm ashamed, my mental math was off by one zero, and I thought I was going to pay 100k/year. At 10k I'll buy without thinking about it.

Use a separate (insured) merchant account for the dodgy transactions?

you should look into chargehound[chargehound.com], i think they would work for you.

Their cost estimator estimates 30 minutes preparing a chargeback dispute. I do them when they come in and it never takes even 5 minutes.

Hey there, founder of Chargehound here, it's a slider so you can adjust it to 5 mins if you want.

Many companies do take up to 30 minutes especially if they are compiling a comprehensive portfolio (if the dispute is for thousands of dollars) and are outsourcing the representment.

As an end user, how can I tell the modal dialog is actually my bank?

It looks trivial for the vendor to man in the middle attack.

I’d take my business elsewhere if presented with a UI from some random e-commerce site asking for extra personal information.

3D secure payments in Europe have been a standard for years - being presented with additional verification steps for online purchases.

Attacker cannot know who you bank with. Plus, most of the time the confirmation screens are something like confirming 2nd/Xth characters of your password/date of birth.

I bank with Monzo and they send a push notification to my phone with an "Approve" button. No way to fake that.

> confirming 2nd/Xth characters

That is somehow significantly less reassuring than not having 3D Secure payments in the first place.

Before this, if a customer opened a dispute and you won, you (the business owner) didn't have to pay any dispute fees without having to pay for anything extra. It was just a part of the standard Stripe offering.

You even wrote this on your site's documentation[0]. Here's what it says as of right now:

> There is a dispute resolution process through which you can respond and submit evidence to make your case that the payment was valid. If the dispute is found in your favor, the disputed amount and fee is returned back to you.

If we don't opt into this new fraud protection service, are all dispute fees still waived if the business wins the case?

[0]: https://stripe.com/docs/disputes

I work at Stripe. That’s right! Nothing changes in the way we handle disputes for businesses that are not on Chargeback Protection. Your dispute fees are still waived if you win the dispute.

I'm curious if there is a way we could avoid the cost all together if we don't need the money deposited in our bank accounts right away?

I work for a non-profit & we had some very large donations come in online through Stripe. Someone did a typo donated $10,000. I'm sure we could set some max limit & say no donations larger than $X but it was common to have $1,000 donations. Even with a $1,000 donations the fee gets expensive.

In our case, we don't need those funds immediately. We would much rather not have access to them for a month & not have to worry about a request for the funds to be refunded.

Will Stripe still take efforts to prevent fraudulent transactions for customers who don't pay an extra 0.4% for it?

I work at Stripe. Yes, absolutely. We’re continuing to invest in Stripe Radar and our machine learning fraud prevention (the team is doubling by the end of the year!). Radar is included at no additional cost in our standard payments processing pricing (2.9% + 30 cents in the US, with similar pricing elsewhere).

Great product! Will this be rolling out in Hong Kong at some point in the future?

(PM on Chargeback Protection here.) We’d like to extend Chargeback Protection to all Stripe countries eventually. Stay tuned!

Any ETA on when chargeback protection will be available for Stripe.js?

No ETA just yet, but we are exploring ways to bring Chargeback Protection to other integration options!