I’ve been working with the Stainless team over the last year, and I rapidly went from being highly skeptical of outsourcing SDKs to being one of the team’s biggest fans.
Separately, as a consumer of many afterthought-ish SDKs for popular services, I’m extremely excited to see their work opening up to more developers. I hope it raises the bar for SDKs everywhere!
You’re right, they are definitely not trivial :) We’ve done a lot of work to make Checkout automatically support PSD2/SCA compliance out of the box — we’ll trigger 3DS only when it’s required. More here: https://stripe.com/en-US/payments/strong-customer-authentica...
We found that legacy version of Checkout did not allow us to build a number of features that users have been asking about for years—including instantly turning on Apple Pay without needing you to register with Apple directly, supporting a unified API that can work with redirect-based payment methods such as iDEAL (coming soon), and a bunch more features that we're working on. If you're looking for something embedded in your page, we have Elements: https://stripe.com/docs/stripe-js/elements/quickstart
Plenty Stripe users don't care a jot about Apple Pay, especially those in the B2B space - I consider it a real loss to have customers be redirected vs just showing a modal. As another commenter mentioned, it also means another step for the end user.
I understand the desire for a converged Checkout API and UI, but I still kind of wish there were 2 options - modal or redirect.
Gideon from Stripe Product Ops here. I definitely hear you RE: wanting to keep an modal version. If it's not too much trouble, could you email me at gideon+hn@stripe.com so I can get some more feedback from you?
Is the legacy Checkout version going away? I'm nervous that it's being called "legacy." It works perfectly for us; we don't see a benefit in implementing Elements, and the new external checkout flow is a negative for us. Will we be forced to migrate?
Future development will be focused on Elements and the new version of Checkout, but we’ll continue to maintain the legacy version as long as we can. Note that if you’re accepting payments from PSD2/SCA-impacted countries, we do recommend using Elements or Checkout, as the legacy version of Checkout doesn’t support 3DS.
Would love to hear more about why Elements or the new version of Checkout don’t work for your use case — can you shoot me an email jenan@stripe.com?
For us it's all about implementation simplicity. For a small peanuts site that's a little too complicated for Shopify but not nearly profitable enough to support paying for a lot of custom development, "legacy" Checkout slotted in perfectly. Not having a redirect-based workflow means we don't have to break apart our own checkout process; I can just have one simple HTML form with some magic JavaScript and then by the time my (one, single) checkout script gets the form, it's already done with the payment.
I didn't have to implement my own payment form (like Elements would require me to do) and I didn't have to split up my own flow over multiple pages (like new Checkout would require me to do). This is one of, if not THE, distinguishing feature for us vs. PayPal. If I were OK with a more complicated multi-page checkout process, I would have just used PayPal which customers prefer anyway.
I agree 100%. For now, I'll just keep using legacy Checkout, but some day legacy Checkout will stop working. When that day comes, the effort to port to the new Checkout will be approximately the same as the effort to port to PayPal. If there's no pop-up mode by then, I'll probably just switch to PayPal.
Same. Forcing the user to navigate to an external page breaks my UX in so many ways. The migration for me is more than just implementing the new checkout, it's a refactor for the UX and upgrade flow that I would rather avoid.
Gideon from Stripe Product Ops here. Can you tell me more about your integration if it's not too much trouble? You can email me at gideon+hn@stripe.com any time
Just a followup now that I've seen some more details elsewhere that has strengthened my resolve: if you expect me to implement a webhook or to poll for completed transactions, you've lost me, and I think you've lost the knowledge of why people chose Stripe Checkout for their websites in the first place.
As soon as legacy Checkout stops working, I'm gone. If I'm implementing webhooks, then I'm implementing it for PayPal instead. Then at least I'd be gaining something for my effort (user-facing PayPal support) instead of just doing extra work to satisfy Stripe's whims because THEY want to do something that I don't care about.
I can't second this enough. Stripe making their software categorically worse for a number of longtime users is infuriating. It's one thing when a toy app does this, but for something as critical as handling payments, "Well we want to add some features you don't care about" doesn't cut it.
Gideon on the Stripe Product Ops team. I'd love to hear which features aren't important to your business and which features would be. If it's not too much trouble, could you email me at gideon+hn@stripe.com so I can get some more feedback from you?
It seems odd to require client side code (probably rendered by the server anyway) just to do a redirect, servers are perfectly capable of that. Doesn't the server have the sessionId and public key anyway? Why do you do it this way?
@jenanwise, I can't really tell by the example aside from not being prompted for a phone number, but is the 2FA via SMS for returning customers going away?
The Apple Pay button will only show up to customers who have Apple Pay onboarded and enabled. Customers who don't care about Apple Pay won't ever see the button.
Oh they mean connected on the users Stripe account or the companies? I thought OP meant some iOS API to see if they have Apple wallet set up with an active card.
I'm guessing there will still be a link if the company supports it if it's the former (first party user level).
I wrote some notes below (https://news.ycombinator.com/item?id=19740475) but TL;DR is that this lets us support a lot of features that that the legacy version never could. If you’re looking for an embedded form, Elements work great (https://stripe.com/docs/stripe-js/elements/quickstart) — you can of course pair Elements with a lightbox/modal library to get a similar experience to the legacy version of Checkout.
A modal with Elements could support all the features that old modal Checkout supports. It would not be able to do all the things that new non-modal Checkout will be able to do in the near future.
The Stripe 3DS and SCA page says a modal in combination with Elements is fully supported:
Pre-built modal: The Payment Intents API integrates tightly with Stripe.js and Elements to simplify the authentication process. If your Stripe integration uses handleCardPayment or handleCardAction, Stripe.js automatically handles the authentication process—displaying a modal dialog where the customer can provide the requisite information.
This makes it look like we can build a modal version via Elements which fully supports SCA and 3DS through another modal. All on one page.
Also, the Paymentintent docs say we have to set the viewport to mobile on our page so that the UI of Elements can handle 3DS, this makes it also look like it works on our page through a model without redirects. Otherwise Stripe would set the viewport.
Does Elements fully support 3DS and SCA all on our page through modals or not?
In Elements the payment request button utilises the PaymentRequest API, so Apple Pay in Safari, a (default) purple browser button in Chrome, etc. So I imagine so.
Separately, as a consumer of many afterthought-ish SDKs for popular services, I’m extremely excited to see their work opening up to more developers. I hope it raises the bar for SDKs everywhere!