3 ms·

display_cc_form_that_handles_cc_data_so_we_do_not_have_to() { which_one = random_number(3) switch which_one { case 1:

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.
eropple 4y ago
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.

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.

eropple 4y ago

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.