4 ms·

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 y

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.

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.