> Yeah their API is a little bit... bloated for simple needs since they're covering for many different use-cases
You're right. We're fixing this. Stay tuned.
You're right. We're fixing this. Stay tuned.
We finished migrating to SCA-enabled payment flow not few days ago. Apparently, you can't create a PaymentMethod instance without using Elements and we don't have the time (nor do we see any practical need) to redo the frontend with them. So the end result is a Frankestein-style frontend that uses the v3, but with a fair share of v2 methods, because it's the only way to retain all the functionality we had prior to the migration (e.g. saving the card info for future use). This was a bit of nasty surprise to be honest. Migrating to the v3 basically breaks existing systems in a non-trivial and expensive to fix way... and the migration is mandatory because of SCA.
* SCA = strong customer authentication
According to [1] it is required and there's no other (documented) way to do it.
Ditto for stripe.createToken() [2].
In fact, there's no word in the docs on how to feed raw card data into the v3 at all.
So we had no choice but to use Stripe.card.createToken() from the v2, but then also use stripe.handleCardAction() from the v3 for confirmation... it's a mess. What did we miss?
[1] https://stripe.com/docs/stripe-js/reference#stripe-create-pa...
[2] https://stripe.com/docs/stripe-js/reference#stripe-create-to...
[0] https://stripe.com/docs/security#validating-pci-compliance
[1] https://stripe.com/docs/api/payment_methods/create#create_pa...
[2] https://stripe.com/docs/stripe-js/reference#stripe-handle-ca...
That's the flow we had with the v2 and that's what we can't replicate with the v3.