Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New version of Stripe Checkout

stripe.com

Post reply on HN
Print view View original

51–60 of 162 posts

Re: New version of Stripe Checkout

#51

Post by TazeTSchnitzel »

foobarbazetc wrote: post #46
quotha wrote: post #27

Earlier quoted context omitted.

I think it's just a matter of time before people switch from using PayPal.

We thought this and killed our PayPal integration (went Stripe only) and lost double digits in sales (and received constant emails asking for PayPal). Unfortunately people want PayPal for whatever reason. Everything about PayPal from the merchant side sucks (bad API, bad recurring billing features, slow, no refund of fees for refunds from May, 6 months for someone to do a chargeback!, etc etc)

Losing a lot of sales is not surprising if you're forcing existing customers to change payment method. It's enough hassle many will just leave if your service isn't special enough to them.

Beyond that, a big reason to use PayPal is that simply, a lot of people don't have a (internationally accepted) card they can use. PayPal is a useful middleman for those people if they support a payment method they do have.

Re: New version of Stripe Checkout

#52

Post by jenanwise »

electroly wrote: post #45
jenanwise wrote: post #30

Earlier quoted context omitted.

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…

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?

Re: New version of Stripe Checkout

#53

Post by dfabulich »

jenanwise wrote: post #47
JimDabell wrote: post #42

Earlier quoted context omitted.

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

Not yet, but the amount of JavaScript necessary is really small. Essentially: Essentially: window.Stripe(' ').redirectToCheckout({sessionId});

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?

Re: New version of Stripe Checkout

#54

Post by plantain »

Glad to see "Support for iDEAL, SEPA Debit, and other European payment methods" is on the roadmap - the world is bigger than the US, and many European's don't have cards. Hopefully they don't continue requiring you to obtain your own SEPA creditor identifier, as that simply isn't available to many non-EU companies wanting to trade in the EU. We are integrating Braintree currently just to support SEPA for European customers...

Re: New version of Stripe Checkout

#56

Post by cstejerean »

foobarbazetc wrote: post #46
quotha wrote: post #27

Earlier quoted context omitted.

I think it's just a matter of time before people switch from using PayPal.

We thought this and killed our PayPal integration (went Stripe only) and lost double digits in sales (and received constant emails asking for PayPal). Unfortunately people want PayPal for whatever reason. Everything about PayPal from the merchant side sucks (bad API, bad recurring billing features, slow, no refund of fees for refunds from May, 6 months for someone to do a chargeback!, etc etc)

I use PayPal for random sites that I don’t know because I don’t like handing my credit card info to random websites. Now I would personally trust Stripe Checkout (especially on a stripe.con domain rather than in a modal) but that’s because I know Stripe. The dislike of PayPal among techies is not common the population at large in my experience.

Another thing I use PayPal for is any kind of subscription, because I know I can cancel it from the PayPal side without having to worry about jumping through hoops.

Re: New version of Stripe Checkout

#57

Post by bpicolo »

dfabulich wrote: post #25
bpicolo wrote: post #23

Earlier quoted context omitted.

They have the embedded option as well: https://stripe.com/docs/stripe-js#stripejs-and-elements This change seems to solidify the distinction between Stripe-hosted vs self-hosted

Elements isn't "embedded Checkout." Elements is "roll your own Checkout using Stripe's UI components."

It's more than that. The loaded JS library renders your inputs into iFrame elements (for PCI compliance). So it takes that HTML and embeds it down. Recent PCI changes added different-domain hosting for the form itself as a requirement for compliance, which is why you see providers moving to different sorts of embedding.

https://stripe.com/docs/security#validating-pci-compliance

Re: New version of Stripe Checkout

#59

Post by JonoBB »

jenanwise wrote: post #30
pupppet wrote: post #22

Wasn't the advantage of the original checkout the customer didn't have to leave your site?

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…

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.

Re: New version of Stripe Checkout

#60

Post by electroly »

jenanwise wrote: post #52
electroly wrote: post #45

Earlier quoted context omitted.

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 c…

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.

Post reply on HN