[jenanwise]

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

[GordonS]

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.

[ycombinateur]

I so unbelievably strongly agree. There should also be a pop-up version of checkout instead of a redirect.

The only two features I care about are (i) a simple popup to accept cc details (ii) an aesthetically pleasing interface

[gideonatstripe]

Hey GordonS,

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 [e-mail] so I can get some more feedback from you?

[electroly]

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?

[jenanwise]

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 [e-mail]?

[electroly]

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.

[dfabulich]

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.

[cwood119]

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.

[gideonatstripe]

Hey electroly,

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 [e-mail] any time

[electroly]

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.

[rurp]

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.

[gideonatstripe]

Hi @rurp,

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 [e-mail] so I can get some more feedback from you?

[JonoBB]

Don't like this at all.

Two of the key features of going with Stripe was:

i) Checkout on our page

ii) Simple implementation with a tiny amount of JS

Without the legacy version, we're losing one of these 2 key features.

[JimDabell]

> supporting a unified API that can work with redirect-based payment methods

Does this mean that it will be possible to implement Stripe payments that work without JavaScript?

[jenanwise]

Not yet, but the amount of JavaScript necessary is really small. Essentially:

Essentially:

  window.Stripe('<your key>').redirectToCheckout({sessionId});

[dfabulich]

Plus 33KB of Stripe's own JS (123KB after ungzipping).

When using server integration, shouldn't the server be able to compute the link itself? Why does the server integration require Stripe JS at all?

[CodeWriter23]

I'm gonna go out on a limb here and guess there's some Panopticlick/Recaptcha style human detection / fraud prevention going on in the JS.

[grey-area]

Why tho?

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?

[CodeWriter23]

@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?