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