And if ChargeBee bans you, you are still dead because that's a single point of failure. No, you should have several payment processors, and rotate them regularly to check they work.

Besides being a single point of failure, we tried to switch to ChargeBee and found them to be pretty lacking (to put it mildly). The platform looks nice and has lots of options, but under the hood things seem pretty fragile. Horrible docs, random 500 errors that weren't showing on the status page (and support ignored until more customers reported it), our Stripe gateway disconnected and the system still appeared to be working (partly, partly failing) with no alerts, plus lots of other odd behaviour. To be fair, all of this was on the test system, but we didn't feel confident to go live so we put the migration on hold. YMMV of course.

Fwiw, I’m just using them as an example. There are likely plenty of other options.

Under ChargeBee's terms, they must provide you with your data for up to 120 days following any termination. So there's that at least.

> 7.2.3. Data Export Following termination or expiration of a Subscription, We will retain that Account’s Service Data for one hundred twenty (120) days from such date of termination or expiration (“Data Retention Period”).

I mean, ideally we need an open source PCI compliant equivalent of ChargeBee so that you can 100% own your customers payment information.

That's the way this problem really gets solved, but the security surface for that open source project is going to be a challenge.

SLAs only entitle you to a refund, not compensation for lost income. If you’re not making at least four times as much off a service as you pay for it, you really need to think about why you use that service.

Power can go out. Promises from the power company don’t fix that. Only backup power does.

Point here was that you’d hypothetically be able to get all of your data to setup an alternative if you had to, rather than just being shut down and waiting for them to fix it.

Once you trust your vendors absolutely, your company becomes their company, because they can do whatever they want with it.

What always confuses me about this is that it seems like many owners trust their vendors over their own employees and I don't even know where to start unpacking that sentence.

The problem with that idea is that PCI compliance doesn't just include the software you're running, but the infrastructure you run it on, various elements of organisational security and, of course, certification costs.

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.)

You use several API, attach one provider per customer to divide the risks. When one provider bails out, you onboard new customers and new payment on the other payment provider.

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()
        }
    }

Plus the same integration work for each one that you'd have to do anyway (which may be little or none if you're using a platform that integrates all of them via plugins or settings or whatever)

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)

It's been a long time since I've worked in eCommerce but at my last ecom role we used two payment processors and simply stored the card data with both for every customer, and the relevant IDs in the customer record in the database. Whenever anything got charged we'd check which processor we were supposed to use and off we went.

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.

Great solution, I wouldn't have thought of this. Did you ever get complaints about the charge description looking different month to month, or did both processors pass the same description to the customer's credit card?

I don't remember for sure (this was pushing 10 years ago and early in my career), but I don't recall any complaints of that type.

The problem is with recurring payments. If you used this approach and 1/3 of your customers were initially billed through Stripe, then if Stripe bans you then you can't charge the next month's bill through something else because you don't have the stored data for it, you have to ask them to re-enter data in another processor's system.

Another wrinkle, in practice, is that you can often negotiate significant discounts on fees, based on volume, if you've got enough of it. Yes, including with Stripe and other places that have fairly-transparent public pricing—the big-boys don't pay those rates, they pay lower ones negotiated with a sales rep.

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.

This isn't "rotating payment providers", though, this is sharding customers across them. Which may be a good idea, insofar as it could reduce your blast radius, but it doesn't allow for portable customers--which seemed to be what the GGP was implying.

'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.

That's why you need a self hosted solution.

This is one of the reasons that I usually use https://killbill.io/

Have you tried or considered lago? (getlago.com) I haven't heard of killbill, so will definitely look into them. Love that they're open-source as well and seems like they've been at it a long while.

Thank you! First I hear about either of those, but definitely interesting. Are there paid / hosted versions of lago? after a sub-par experience trying to switch to ChargeBee I'm looking for alternatives, but struggle to find something that fits our needs.

Yep there is a paid / hosted version of lago; I believe you can book a demo of the hosted version from their website and get a good 1 on 1 with one of their developers so you can see if it works for your needs.

Lago looks interesting, and promising if development continues, but nowhere near as feature complete or battle tested as Kill Bill.

Lago looks beautiful, thanks for sharing!

I will definitely look into that.

We're built on Rails which has the extreme luxury of being able to use ActiveMerchant, which does exactly this. The problem is, abstraction falls apart when you're using functions that are specific to a product. Stripe Connect is is nearly impossible to replicate with an adapter.

Yeah my “business” (just a small app) uses a third party API for tracking packages. You better believe I abstracted that API and programmed to the abstraction, so in case I ever need to move off that API I can do it very easily.

It’s not just getting banned, they could change their pricing on you or just straight up close their doors. You never want your business to be totally dependent on another company. If it can’t be avoided, get on a service contract with them.

Yup I did this at my last business in 2008; instead of changing payment processors we abstracted them away behind a pretty small API that also stored and charged card numbers. We could flip back and forth between two. PCI DSS gradually became a bummer around that time but it was a very slow introduction which we were able to cope with.

I'm just starting to use Lago (getlago.com) for this. I'm not affiliated with them, but it solves the need for me for an open-source payment-processor-agnostic billing system that can easily swap between processors while maintaining a single source of truth.

But what happens if getlago.com bans you? Haven't you just moved the single-point-of-failure at a different place?

It's open source, so I can just set up my own instance. I just have to be careful to make sure that process is as easy as possible. You never know what provider may ban you so yeah that's definitely a concern, but that's why I build on only open source.

Oh wow, I thought it was a paid service! That is good! Thank you for the clarification !

> Stuff like this is why I think a business should have a system that abstracts away the payment processor.

Realistically, more humanly, payment processors and other big tech companies that are basically societies digital gum and infrastructure can simply not be tasked with making these calls. I also don't think they are very keen to do it but in the absence of timely regulation they must.

There have to be more rigorous ground rules (what is the business allowed to do, what must they do, what is the user allowed to do, and what are they entitled to), by law, and quickly.

But there are tons of rules and laws around payments already, and they are often the reason why providers are so trigger happy and conservative even if it means losing clients. Regulatory requirements (KYC, money laundering, sanctions) usually force them to make those calls, quickly and by design. It's very clear that most financial regulations are customer/client unfriendly, and inherently treat them with distrust.

I'm not saying that's an inherently good or bad thing... But it sure would be hard to fit both customer protections laws and service guarantees while at the same time having laws that explicitly force providers to do the opposite.

There is nothing intrinsic about financial regulations that needs to be customer unfriendly. Checks can work both ways and what happened at stripe could for example be avoided by a statue which requires a reasonable explanation and a clear path and timeline towards resolution for the customer, regardless of the company they work with.

You think stripe and PayPal are not keen to control the flow of information and business success?

You still have a Single Point of Failure. ChargeBee could shut you down too.

You are right that redundancy is important, but redundancy either in cloud vendors , payment processors or even high availability of your app takes time and effort with no immediate ROI as apposed to buliding features , better customer service.

When running a small business you always take lot of risks by cutting short processes large organisations will have. Judging which ones to take and which to mitigate is a not a easy skill, many times people get it wrong .