[m11a]

To pull that off, they'd have to (technically) process the card info, which puts them in the scope for PCI compliance. By that point, I don't know why they'd send card info to 3 processors especially when they know, at that point, which processor they're gonna process it with. It would just make more sense to send it to the 1 processor the code ends up deciding to use.

[cj]

No, I don’t think that’s accurate.

With stripe.js, you send the cc info directly to stripe from the browser. Stripe returns an identifier which you can use in the future to charge the card.

Assuming other payment processors work similarly, you could easily send the credit card details to multiple payment processors directly from the browser to the payment processors, and then store the card identifiers from each processor (not the card number) in your database to charge it at a later date.

[m11a]

Stripe.js creates an iframe hosted by Stripe which sends the card information directly to Stripe. The merchant cannot see or intercept that card info, during or after transmission, and thus cannot send it to another processor (at least not using the same payment card input boxes).

[cj]

Ah yes, Stripe.js v3 works the way you described.

I was thinking of Stripe.js v2 which doesn’t require an iframe / supports custom payment forms.

[dylz]

I can't think of any payment processor that would allow this without 3 separate entries.

They would be upset or bring you into PCI scope if you were modifying or tampering with their single input SDK to send cardholder data elsewhere.

[sumedh]

Dont know about Stripe but Braintree has a forwarding API where the card details go to Braintree then Braintree forwards that data to another payment gateway you have signed up for, the other payment gateway sends a token to braintree which forwards that token to you.

Then you have an option to make the payment on Braintree or the other payment gateway using that gateway's token.