Live data from Hacker News

New version of Stripe Checkout

stripe.com

161–162 of 162 posts

Re: New version of Stripe Checkout

#161

Earlier quoted context omitted.

Exactly the point I made about Plaid's login flow- https://github.com/plaid/link/issues/68#issuecomment-4408942... For the average Web user, if you don't see a name you trust with an EV cert in friendly green in your address bar, you shouldn't be giving up the keys to your bank account. Plaid and (soon formerly?) Stripe embedding their widgets into the parent page are just training users to get scammed. I'm still bea…

EV is not a solution to any problem, much less this. This is a bigger problem with how the web communicates identity, I wouldn't really blame Plaid/Stripe/etc, their alternatives suck. I think Stripe is a great example for this because in many cases, it's not actually clear where your credit card/etc is going, webpages just silently pass the form fields to Stripe.js.

Really the key is to have a TLS-secured connection to a domain that you trust. The EV cert is just icing on the top that anyone doing payments or bank integration should have. It's slightly harder for a scammer to get and keep an EV cert than a standard cert.

And you're right- the issue is with communicating identity to the user. The best way we have for doing this is to have the entire tab be served from the trusted domain, with the browser checking for mixed content to make sure your data is safe. But the problem is that Plaid and Stripe.js don't even support this basic mechanism for communicating to users that they're safe. Someone decided that a slightly slicker UX was worth totally giving up on this identity issue. I think it is fair to blame them for that.

Re: New version of Stripe Checkout

#162

Earlier quoted context omitted.

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…

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.
Post reply on HN