Stripe Chargeback Protection

Things like this are great for the average to small merchant, BUT if you're processing more than, say, 50,000 USD a month, relying heavily on the Stripe ecosystem can take its toll and can cost you big time.

- Use Stripe as the only gateway for all your international traffic, and you will see alarming drops in acceptance rates, meaning the chance of successfully charging a Mexican customer in Mexico with a US Stripe account is much lower than if you have a local acquirer. By a lot!

- Rely heavily and blindly on Stripe Radar for post-charge suspected fraud alerts charges, and you will be refunding many valid orders.

- If you go all in with Stripe Checkout, you are getting a lot of good stuff at a price. If stripe dynamically uses 3DS to sift potential fraud users, you are going to hurt your conversion rates.

Been a big fan of Stripe for a long time, but when order volume goes up, and you grow internationally you have to consider other alternatives and/or backup plans, such as smart routing, local merchants, alert networks (ethoca, verifi), pre-checking for pseudo 3DS charges (no auth need, but fully protected, etc)

Not taking into account these 3 things, can drop your conversions by big double digit percentages.

EDIT: spelling

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?