The real solution is to never rely on one party. We fall back to another payment processor after using a heuristic to see if the error isn’t one that makes sense. If it’s a problem with the payment card, it’ll fail again, no harm done. If it’s a problem with the provider, it’ll go through.

(We wrote a payments abstraction library easy enough to (partially or fully) fill for any payment provider’s core functionality, so it’s literally just a couple more lines of code at the call site. It took several rewrites to get the abstraction to cover all the oddities each time we added a new provider implementation, though!)

But for that you have to touch CC info directly with all the risks and compliance bullshit.

You can use a third party vault to collect and store CC info without it touching your servers. I use Spreedly. I can then charge any of the stored cards with any of like 45 different payment gateways, including Stripe. Keeping your own billing systems online when one of your gateways is down is one of the use cases. This has worked great for the past 7 or so years I've been using them. It might become more difficult with PSD2 SCA however...

what happens when the vault goes down?

That happens much less often than payment gateways going down. Spreedly's service is at least an order of magnitude less complex than running a payment processing company. However, you can have resilience against that situation by having a backup integration with one of your payment gateways directly. Spreedly will gladly collect a customer's credit card for you, save it in their vault, AND save it in your Stripe account, and any other gateways you work with. So, without having touched any CC info yourself, you can tell Spreedly to charge a customer via Stripe, or you can directly tell Stripe to charge that same card.

Thank you.

have your script test for your own network possibly being down, then if it gets a bad response, put the transaction in a queue to be retried later