4 ms·
They have the embedded option as well: https://stripe.com/docs/stripe-js#stripejs-and-elements https://stripe.com/docs/stripe-js#stripejs-and-elements This cha
by bpicolo 8y ago
They have the embedded option as well:
https://stripe.com/docs/stripe-js#stripejs-and-elements https://stripe.com/docs/stripe-js#stripejs-and-elements
This change seems to solidify the distinction between Stripe-hosted vs self-hosted
- dfabulich 8y agoElements isn't "embedded Checkout." Elements is "roll your own Checkout using Stripe's UI components."
- bpicolo 8y agoIt's more than that. The loaded JS library renders your inputs into iFrame elements (for PCI compliance). So it takes that HTML and embeds it down. Recent PCI changes added different-domain hosting for the form itself as a requirement for compliance, which is why you see providers moving to different sorts of embedding. https://stripe.com/docs/security#validating-pci-compliance https://stripe.com/docs/security#validating-pci-compliance
- nailer 8y agoAnyone got any thoughts on when to use Elements vs the new Checkout?
- jenanwise 8y agoWe've got a page for that! https://stripe.com/docs/payments https://stripe.com/docs/payments
- stickfigure 8y agoUnless you're a Big Stodgy Corporation that must have exactly your own custom flow, always prefer the Stripe Checkout flow (either new or old) over Elements. Checkout is easier to implement, provides a polished UX, and users are more likely to trust it over your custom flow.
- jjevanoorschot 8y agoUse Checkout unless you have a good reason not to. The main benefit is that if there is any large change in regulation (like SCA right now in the EU), Stripe will update Checkout and you will not have to change anything.