It's been a while since I dealt with this side of ecommerce - how can you have several payment processors, and rotate them, without having to handle card data yourself? (Most folks aren't really equipped to do that.)
Then you only loose the recurring payments on the lost provider that are on hold, and you are not dying, so you can resolve that problem using a lawyer.
This is crisis management, not technical perfection that you need for those situations.
display_cc_form_that_handles_cc_data_so_we_do_not_have_to() {
which_one = random_number(3)
switch which_one {
case 1:
display_authorizedotnet_form()
break
case 2:
display_stripe_form()
break
default:
display_paypal_form()
}
}
Like maybe don't literally randomize it request-by-request, but that's how you'd be ready to use multiple processors, and you could do something a little more complex to, say, rotate which one you're on every Wednesday, or whatever. Or just have it ready so a one-line code change or config toggle switches which one you're on (that's only worse because if something's not used frequently in prod, there's a good chance it doesn't actually work, even if it once did)
Yes this has an increased cost if your processor charges by number of customers, but I don't think that's particularly common - these two were just revenue + monthly fee.
Splitting up your payments reduces your volume with each one, which can mean you're paying higher rates overall. Or, if you go the "keep an unused alternative on standby" route, you'll likely at least have some initial traffic that pays higher public-pricing rates until you can convince them to give you a better rate, and put it in effect.
Still might be worth it as a kind of insurance premium, but it's something to consider.
'pc86 has an interesting solution in a sibling comment, but I don't think you can do this across the high-touch providers, eg Stripe+Paypal.