|
|
|
|
|
|
by tarstarr
2992 days ago
|
|
|
On your integration -- you won't have to change anything if you're currently using Stripe Subscriptions. You can continue as you are. On high decline rates -- Of course, we're hoping Smart Retries and automatic card updater help you here without any additional work on your side. That said, drop us a line! There's actually quite a few things you can do on your end to minimize declines (pass us the right information at the time of charge, segment your decline reason codes in Sigma, experiment with trials, etc.) that can help reduce passive churn. (Docs on declines here: https://stripe.com/docs/declines) |
|
|
On the decline rates, we actually have dropped you (Stripe) a line -- many times, in fact, and via multiple channels. In some cases, we never received a reply at all. In the others, the reply was essentially that you didn't know why the failure rates were so high and there was nothing actionable you could suggest to improve them.
I appreciate the link to the declines page, but I think that information has been available for quite a while now. What we have really needed is the detail about exactly what would happen if we configured the existing Dunning management to retry things, for example which objects get created in your system and/or get reused on retried payments, and which webhooks get sent at which points in the try/retry/give-up process and which objects they refer to. As far as I'm aware, none of this has ever been included in your usual documentation areas.
With today's announcement, it would now also be helpful to know the differences between the previous Dunning controls and the new Billing system, and how to migrate between them if necessary. The controls for the new smart retries feature seem to be in the same area on the dashboard, but as with the older controls, if there's any documentation anywhere about what any of these settings actually do under the hood, or how to simulate the relevant scenarios for integration and testing purposes, I can't find it.
It would also help to fix some limitations of the current tools, and again maybe the new Billing system helps with this but we haven't spotted it yet. For example, one problem we've run into a few times now is that address verifications are all-or-nothing. Either we don't use them (presumably worse for fraud detection) or we do (but then if a customer moves house and doesn't tell us, their next charge on a subscription will fail). In terms of risk, it would seem to make sense to check the details that don't appear on the card itself for the first payment(s), but after a while to trust that the card really does belong to the customer claiming it and downgrade/ignore those signals in later fraud checks, but this doesn't currently seem to be possible.
I appreciate that you're probably all very busy today with the roll-out of the new system, but I'm sure we're not the only ones who would be grateful if these kinds of documentation gaps and any actual limitations in the functionality could be addressed when time allows.