4 ms·

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 regular

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.

eropple 4y ago
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.)
- deleted 4y ago
  [deleted]
- BiteCode_dev 4y ago
  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.
  - deleted 4y ago
    [deleted]
- yamtaddle 4y ago
  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)
  - pc86 4y ago
    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.
    - exhilaration 4y ago
      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?
      - pc86 4y ago
        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.
  - PeterisP 4y ago
    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.
    - yamtaddle 4y ago
      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.
brightball 4y ago
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.
- hinkley 4y ago
  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.
  - brightball 4y ago
    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.
    - hinkley 4y ago
      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.
- connordoner 4y ago
  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.
gingerlime 4y ago
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.
- brightball 4y ago
  Fwiw, I’m just using them as an example. There are likely plenty of other options.
KaoruAoiShiho 4y ago
That's why you need a self hosted solution.

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.

eropple 4y ago

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

deleted 4y ago
[deleted]
BiteCode_dev 4y ago
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.
- deleted 4y ago
  [deleted]
yamtaddle 4y ago
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)
- pc86 4y ago
  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.
  - exhilaration 4y ago
    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?
    - pc86 4y ago
      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.
- PeterisP 4y ago
  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.
  - yamtaddle 4y ago
    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.

brightball 4y ago

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.

hinkley 4y ago
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.
- brightball 4y ago
  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.
  - hinkley 4y ago
    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.
connordoner 4y ago
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.

gingerlime 4y ago

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.

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

KaoruAoiShiho 4y ago

That's why you need a self hosted solution.