3 ms·
After skimming the docs, I'm not sure why you'd want to choose Checkout over Elements in a lot of situations, other than getting some great design work for free
by w4 7y ago
After skimming the docs, I'm not sure why you'd want to choose Checkout over Elements in a lot of situations, other than getting some great design work for free with Checkout. The dev time to implement Elements doesn't look that different from the new Checkout, and Elements doesn't require you to redirect your customers away from your site or force a multi-page checkout experience, which is generally associated with lower conversion rates. This also feels really ecommerce oriented, and less friendly to SaaS MVPs, etc.
The old version of Checkout was so dead simple to implement that it had a clear value prop over Elements, but at first blush this seems like a tossup. Braintree's js embed also came to mind after seeing this, since it's a bit less refined than the old version of Checkout, but it's simpler than this solution, and keeps users on your site.
EDIT: After looking closer at the docs, it does indeed look like you'd want to use Elements for SaaS or similar digital products. Unless I'm misunderstanding something, after the user completes their payment on Checkout, Stripe sends you the payment via a webhook, or you have to poll for the transaction. That's a big step back from the old version of Checkout, where you would send a token through to your server from the checkout form, and find out immediately if the payment went through or not so that you could proceed accordingly. This looks nice for ecommerce sites where delayed fulfillment is expected, but not for user subscriptions or account upgrades.