If someone uses WooCommerce for their store, they have 79 different payment integrations, including Stripe, Paypal, Amazon Payments, along with merchant account gateways like Authorize.net. Some of them are paid extensions but rather cheap considering the use.

https://woocommerce.com/product-category/woocommerce-extensi...

If in fact High risk is necessary then NMI is the most common gateway. Be careful they require a rolling reserve and can require multiple buckets capped at a certain amount, commonly 50k / month.

We write a few a high risk accounts per month. As a matter of fact I just had a call center run across my desk a few hours ago.

Exhaust all underwriting options as each processor has a different risk tolerance. For instance this call center is now using NMI and a rolling reserve, I've found another processor (one of the big 5) that will not fall under the High Risk thus saving a boat load not to mention negating the accounting nightmare that comes with rolling reserves and high risk processing.

What Im talking about is to add another abstraction layer, so you can have both payment processors and decide which use on the fly, both integrated with any ecommerce framework you use

You're still going to have some grief is you sign up 2 years worth of customers to recurring subscription via Stripe and then have them pull the rug out from under you. Sure you can switch to your backup processor(s) for new customers, but you'll need to go back to all your existing subscription customers and ask them to re sign up to their recurring subscriptions with the new processor.

Its much harder to engineer a payment abstraction layer with recurring payments where you're not relying on Stripe's subscription features that are not migratable to another payment processor.

When building out your business, you need to look for possible points of failure, assess the risk of each point, and then consider mitigations.

Payment processing is a possible point of failure. Chances of it failing? I think anyone who's read HN/Reddit/etc would have to evaluate the chances as fairly high. Cost to the business of it failing? Often extremely high.

Having done this analysis, you can look at mitigations: sign up with both PayPal and Stripe, get a merchant account, etc.

Then build the redundancy into your system. Yes, this probably means you cannot use the fancy features because there's no good cross-provider abstraction. That's the cost: you might have to implement recurring transactions yourself.

This happens over and over again. Your individual business is worth basically nothing to your cloud provider, your payments provider, your CDN, your domain registry, etc. They do not care if it breaks.

You have to have redundancy for anything you cannot operate without.

Maybe the abstraction can be a selling point for your customers. They can sign-up for the recurring Stripe subscription but it comes with the risk of suspension. If they are ok with it, atleast they can't claim "I didn't know this" if/when it happens (this risk can be included in the contract to deal with executives leaving/"amnesia"). Or they can also have redundancy, which of course costs extra but can be thought of as an insurance and the abstraction does the rest.

This seems sound for one off transactions, but I'd be interested in how to make this work with subscriptions, assuming you don't want to take the PCI burden of holding the raw card details - is it a case of asking all your customers to resubmit their details to the new payment processor?

I guess in the case of the orchestrator you linked they retain the card details and can then charge using any of n processors, though I'd be interested in thoughts from the overall thread where people are advising to be ready to change payment processor

Spreedly is a very good provider for this.

Yes thank you, couldn't remember their name

Thank you for bringing the "payments orchestration solution" term here! Have something to learn about.