I used to work on billing and a bit of payments stuff for a large SaaS company, so I have some experience with this.
When you charge a credit or debit card, send a bunch of messages that end up going to an organization called a payment processor. Payment processors do stuff like make sure your account has enough money/remaining credit and also have fraud checks and other security features. Sometimes, the payment processor rejects a payment because of insufficient funds, suspected fraud, their system being down or a malformed request. Unfortunately, a lot of this stuff is pretty archaic and there are a few layers between your servers and the processor, so it's very hard to debug. On your end, you could simply retry payments if they get rejected, but that might lead to a set of ping pong failures that might even trip fraud alerts to the customer. You can also have retry logic that uses an exponential backoff, just like any other request. That's a reasonable strategy, but you can probably do better.If you're a big company, involuntary credit card churn is actually a pretty sizeable source of churn for you. 99% transaction completion rate sounds pretty good until you realize it means a guaranteed 1% churn rate (assuming people don't sign up again), which is not insignificant. You really want to get this as low as possible.
Enter Stripe: Stripe has handled a very very large number of payments, and they probably have really comprehensive data about failure rates. This allows them to identify patterns and come up with some rules around retries. A simple (fully hypothetical) example is: If a transaction is declined for insufficient funds, retry again on the 15th and the last day of the month (usually when people get paid). These rules can get really complicated. We had some rules that were as complex as "If the cardholder is in Spain, and the card is Amex, retry in three days before 5pm if it's a weekday, otherwise wait until Tuesday."
Overall, this is a pretty nice feature for large customers with high transaction volumes. We did the data analysis/rule generation ourselves and hand rolled the retry logic in our system, but offering it as a built-in service is a convenient (albiet probably expensive) perk.