eeke

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

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.

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

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.

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

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.

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.

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

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.

(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!

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.

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

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

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.

Radar PM here. I’m sorry to hear this. If you’re up for it, I’d love to dig into the charges you think Radar’s gotten wrong (my email is eeke@stripe.com).

PM for Radar here. Really sorry to hear that. Portions of your comment are surprising to me but I don’t want to discuss your business in public. We’d be happy to discuss in private. If you don’t want to, we respect that.

For the benefit of other HNers: if you ever have a concern about this sort of issue, we’d love to hear from you (my email is eeke@stripe.com). This is all I do every day; you can never waste my time.

(PM on Radar here.) This button exists! You can mark a transaction as safe directly from the Stripe Dashboard. If you don’t see this feature for whatever reason, just email support@stripe.com and we’ll get you access.

PM on Radar here. There is! If you see a payment blocked for high risk in the Stripe Dashboard, it means that Radar blocked it before the card was charged. That is, the customer’s bank would have no record of the charge. In addition to the risk evaluation, Radar also provides the primary reason a transaction is believed to be high-risk (for example, the card has been linked to an unusually large number of card payments in the Stripe network over the past 24 hours).

PM on Radar here. There are a couple of ways to handle this. You could, as you said, add a customer to your allow list as soon as they pass the initial charge (and AVS) check. You can also use the new `is_recurring` rule attribute [0] which identifies whether the payment is a subscription charge or not (though there’s some additional work to distinguish the first charge, and how you use it depends on the nuances of your integration). I’d be happy to discuss your specific use case in more detail. Feel free to email me directly (eeke@stripe.com).

[0] https://stripe.com/docs/radar/rules/reference

Hm, I’m sorry to hear about this. I work on Stripe Radar and would love to take a closer look into these disputes to see how we can help. Could you email me at eeke@stripe.com?