[gorbypark]

I’m a one man dev shop but in an app I’m developing I decided to implement payments with two (or more!) processors with the ability to set a weight for each. It hasn’t launched yet but the current plan is to have about 90% or so of transactions flow through Stripe with the other 10% being a “hot backup”, more or less. If anything happens, I can just flip over to the other processor. I decided to actually have the second processor take a small amount of payments so there is less of a risk of it not working seamlessly in the event of a crisis with Stripe. It’s going to cost slightly more in transaction fees but I think it’s worth it.

[hakfoo]

Some gateways offer a more decoupled concept-- you can have one API account, but set it up to route the transactions to different processor accounts based either on predefined rules or an API field during the individual transaction. The nice thing about this is that you can still use the gateway's client-side stuff (i. e. the "embedded form" that reduces your PCI compliance scope) and a single API for all transactions.

I'd think that would mitigate most of the risk, because then the gateway usually is a relatively neutral middleman-- the processors are more in contact with the actual money and more likely to be the true source of arbitrary and weird behaviour, so I can concur it makes sense to be less dependent on them.

[gorbypark]

Yeah, I decided to more or less implement this myself so I could use Stripe as the main provider still.

[arikr]

Smart!