5 ms·

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

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 https://stripe.com/docs/stripe-js/elements/quickstart

GordonS 7y ago
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 7y ago
  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
  - deleted 7y ago
    [deleted]
- gideonatstripe 7y ago
  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 gideon+hn@stripe.com so I can get some more feedback from you?
JimDabell 7y ago
> 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 7y ago
  Not yet, but the amount of JavaScript necessary is really small. Essentially: Essentially: window.Stripe('<your key>').redirectToCheckout({sessionId});
  - dfabulich 7y ago
    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 7y ago
      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 7y ago
    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?
electroly 7y ago
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 7y ago
  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?
  - electroly 7y ago
    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 7y ago
      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.
JonoBB 7y ago
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.
CodeWriter23 7y ago
@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?

GordonS 7y ago

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 7y ago
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
- deleted 7y ago
  [deleted]
gideonatstripe 7y ago
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 gideon+hn@stripe.com so I can get some more feedback from you?

JimDabell 7y ago

> 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 7y ago
Not yet, but the amount of JavaScript necessary is really small. Essentially: Essentially: window.Stripe('<your key>').redirectToCheckout({sessionId});
- dfabulich 7y ago
  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 7y ago
    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 7y ago
  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?

electroly 7y ago

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 7y ago
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?
- electroly 7y ago
  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 7y ago
    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.

JonoBB 7y ago

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.

CodeWriter23 7y ago

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