Hacker News Reader

Comment by BiteCode_dev | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com