This is a beautiful user interface, but in my business, ~40% of our payments are through PayPal. To integrate Stripe Checkout, we would have to ask the customer whether they're paying with a card or using PayPal prior to displaying the Stripe UI.
While that is not the worst option, our current UX is similar to Shopify, where there is an accordion component with multiple options: PayPal, Credit Card, Apple Pay, etc..
Stripe wants to fetch a premium with this feature. As such, they should bite the bullet and allow merchants to integrate PayPal as a secondary option (similar to how Apple Pay is displayed).
I will say that this is a pretty nice improvement from the modal Stripe Checkout that has been around for several years.
> Stripe wants to fetch a premium with this feature. As such, they should bite the bullet and allow merchants to integrate PayPal as a secondary option (similar to how Apple Pay is displayed).
I expect this is not Stripe's decision. PayPal own Braintree, a Stripe competitor, whos unique selling point is that they also support PayPal through one API. I suspect PayPal want to keep this distinction.
Without support from PayPal, I'd expect the most that Stripe could do is implement a way for you to provide extra non-Stripe payment option buttons, which would just redirect to some URL provided up front. Not a great developer experience, and not much of a UX improvement.
Before PayPal bought Braintree, they were a separate company that provided the same service (cards & paypal as an option). Presumably they did this using PayPal's APIs - I'm familiar enough with them to think it should be possible for anyone. However, those APIs are horrible and PayPal's technology platform is a trainwreck, so I can understand why they might not be rushing it out.
You're 100% right, what Braintree does can be done using PayPal's API directly, even what Braintree calls their "in-context" PayPal payments. This is pretty much exactly what we've done at https://processout.com (shameless plug!)
The APIs may be available, but I'd expect the terms of use of those APIs will say something about not using them for competing businesses or some language that could be used to exclude Stripe from being able to offer it as an integration.
There are rumours that Stripe _are_ working on PayPal integration, but I expect this would only launch with PayPal's blessing through some business deal, not just from Stripe's work.
Recently PayPal stopped allowing Adyen, one of the biggest payment service providers, to integrate with their platform. I'm not quite sure that integrating with PayPal is an option for Stripe, and even if it technically were an option, I'm sure it wouldn't be an economically viable one.
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.
As devs, we know in theory Stripe and PayPal are roughly equivalent in terms of protecting a card number. But the streamlined Stripe UI with the subtle branding doesn't drive home to the customer that Stripe is keeping your card number safe vs. random merchant storing all 16 digits in a hackable database somewhere.
The friction in the PayPal UI of making you log in to PayPal to make the payment is a pretty big trust signal IMO.
Stripe isn't as safe. PayPal collects my details only on paypal.com, Stripe collects my details on all sorts of domains, where who-knows-what JS might be present.
Are you speaking about real threats that cannot be mitigated by best practices, or theoretical threats of the future? I guess in other words, I’m under the impression using Stripe and following OWASP and script signing that my customers are safe. If I’m incorrect please pass me a clue.
As a customer, how do I verify that the merchant is following best practices and hasn't by mistake forgotten some ad script enabled on the payment page?
With PayPal as long as I only enter my password on paypal dot com I know I'm safe.
If you’re very careful and copy/paste the PayPal URL into an editor and verify you didn’t get sent to PayPal.com.evil.domain, then you’re very likely to be safe.
I'm with you. I hate paypal, and I love stripe. But I am not going to hand my card number to a merchant I don't know. I broke this rule once in 2016, and regretted it.
If merchants would display a "Processed by Stripe" early on, I'd let up a bit.
This is it exactly. I think for Stripe to really succeed in consumer space and not just among techies, they need to have a manageable back end for consumers to log in and be able to stop payments any time and allow for storing of cc info so people are not asked to enter it on a random website.
The advantage of PayPal is that I can make one-time purchase at random vendor whom I have no prior experience with, without having to trust them to protect my Credit Card info.
Further being famously bad at developing software anyone would want to use doesn't necessarily mean that someone is incompetent in all aspects but it would decrease my trust in paypal just a little.
From an end user perspective, Paypal is a service which magically sends money over the Internet, and you're near-permanently logged into it, so you can pay for anything with almost no friction after you use it for the first time. A Stripe dialog is just a form/modal you see on a website asking you for your credit card details.
They're similar services when you break them down, but Paypal is almost more like a social network for users, with accounts people may re-use dozens or hundreds of times over a year to pay for things. Many end users probably have no clue what Stripe is and just see a generic Web 3.0-looking credit card form (probably ignoring reassurances about how the merchant website doesn't actually receive the card data; that stuff goes over many people's heads, or they just don't even notice it).
In that case I might be wrong. I've only ever used Stripe as an end user, and each time I used it it just appeared to be a credit card form, with no accounts and no memory of previous credit cards I've entered (which is what I would want anyway).
While it's similar, I think there's hesitation since the customer might not know that it's similar in this regard.
Plus the act of re-entering the credit card number and/or not being able to use a recurring PayPal balance to pay off something might be a non-starter for some.
Maybe with the new checkout, which seems to use dedicated domain.
If I remember right, the older checkouts were hosted on vendor's website -- and you would not know if the cc info really goes to stripe only, or if vendor grabs a copy as well.
Not really, how does the end user know that the credit card number they're entering isn't being stolen by the merchant they're buying from? In theory the merchant should never even get the credit card number if they're integrating with stripe honestly and correctly, but the end user won't know that unless they're inspecting the traffic.
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.
I won't claim my reasoning is the what's keeping people asking for PayPal, but here is why I prefer to pay via PayPal:
My biggest fear of paying via Stripe is not having the ability to cancel payments on my own or to cut random company access to my credit card without having to talk to my CC company or bank.
PayPal gives me a bit more piece of mind because I know I can log in and find subscriptions and cancel them right from the back end and payments will be stopped. With Stripe, I can't do this. Not to mention Stripe dashboard is a UX nightmare from the consumer perspective. I don't think any consumer would log in to Stripe to manage their payments (assuming they could) as things stand right now. I think this is a missing feature that Stripe has to integrate in order to finally let PayPal die. That and time.
As a consumer, I want to be able to go to Stripe, easily log in, see all of my subscriptions / payments and be able to stop them with a click of a button. As long as this is missing, I would rather use PayPal's shitty UI and hidden subscription management area.
Paypal is just another "you pay for convenience" service. Not having to type in your card details for every site means you can impulse buy any time you want.
Another draw of Paypal I remember 5-10 years ago was being able to use money obtained on consumer-to-consumer markets. If you were to use any other p2p service (be it venmo, cashapp, etc) you would be required to have a bank and your money almost certainly will end up hitting your bank account. With Paypal, you can receive money from people then turn around and use that "paypal balance" for many real online storefronts without it showing up in your bank (or without having a bank account at all). Note - this may no longer be true as I believe Paypal has changed how it verifies accounts.
Maybe Stripe should create a paypal-like service for consumers where you can they can pay via "stripe balance" and use a single saved card everywhere.
I'm an European and always pick Paypal over credit card. Credit cards aren't really a thing in Europe. I also much prefer Paypal's direct debit options, where the transaction is immediately visible on my bank account instead of coming in aggregate a month later.
I wonder if this could have been mitigated by offering a coupon to customers who tried the new stripe checkout option for months leading up to switching over?
If the cost of discount is less than the cost of supporting paypay it might be worthwhile.
Or if you pay more to use paypal for example raise prices slowly while offering a discount for using stripe.
I wonder why Stripe doesn't offer an option for this kind of service. In the end, people just want it to be simple. If Stripe provides the better business side tools and integration and an ability to have to trust only Stripe with my payment info, it seems like a win-win.
Anecdotally as a person who often evaluates / purchases software for a smallish business, I don't care at all what payment methods you support as long as I can try the functionality without going through the payment flow. Businesses have bookkeepers and bank accounts, we'll mail a paper check or even make a wire transfer if thats what we really have to do to get a service that provides value - it'll be more annoying than a credit card, but by the time we arrive at the point where I'm annoyed, the purchase decision is probably already made based on other merits.
As an individual consumer, I'm much more fickle since I'm usually buying commodities and convenience matters.
I specifically prefer using PayPal. I like going to another site so I don’t have to trust the implementation on the site I’m buying from, and I like having my transaction history in an account that I can sign into. I have turned down many purchases because PayPal wasn’t supported.
I wind up using about once or twice a year when I pay for a foreign hosted server... My CC usually declines the charge and makes it a mess.. paypal to the same CC just works.
Not going to happen. As devs we forget that PayPal is THE fastest and most safe way to pay online from a customer's POV. The login is a click or two. You never have to distribute your credit card details.
Removing the option that 40% of your site's customers are trusting to complete the transaction sounds like a terrible business move. Even with the horror stories.
EU e-commerce credit card transactions currently often redirect to the bank providing your card to authenticate before accepting the payment. The UX is very poor. The beneficiary of the check is the bank, but they tell you it is done for your own security.
For some reason, financial institutions are well trusted in Europe, regardless of recent behaviour.
The first time I saw this flow I thought I was getting phished. It really is ridiculous how you get sent to a strange domain name which may or may not have the name of your card issuer in it.
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 beating this drum because it's still a serious problem and nobody seems to care.
In Plaid's case, the issue is twofold: (a) the chilling effect of "training to get scammed," as you mention; (b) the fact that Plaid's servers log into your bank account on your behalf without clearly disclosing that to the user (unless you have 2FA enabled, in which case they will helpfully instruct you to "disable extra security settings at sign-on"). In fact, it's worse than no disclosure, because Plaid imitates the branding of the login page of your bank.
The solution is obvious, although maybe less than palatable to the Plaid marketing department. Plaid needs to be extremely clear that it is logging into your bank account on your behalf (including detailed statements about security architecture and data retention). They should also stop appropriating the logos and login branding of banks.
In the case that Plaid is not doing this (maybe a few years from now every bank finally has an API, or maybe you use a bank that has one now), then they should use proper third party authorization flow with the bank, where the user explicitly grants privileges from their bank account to Plaid.
Regarding the topic at hand -- Stripe Checkout -- it's a bit disingenuous to equate its flow with Plaid's. The major difference is that Stripe is not logging into your bank account on your behalf without informing you.
The quoted language in my comment is some I have seen in a plaid powered app, where you need to press a button at your bank that says "disable extra security at sign-on" in order to disable 2FA.
The fact is, if you have 2FA enabled, plaid cannot login on your behalf. That said, it does seem technically possible for plaid scrapers to login, tell you to expect 2FA from your bank, and then echo your response back to the bank. But from what I've seen, they did not do this. Perhaps because they need to login at a later time, so they want to save your password and be able to login then.
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.
Just to be sure, if your business is domiciled outside of the EU (e.g. Australia), there is nothing to be done regarding SCA, right?
In other words, there's no risk with sticking to Stripe Checkout Legacy, even for European cards?
I have read some contradicting documentation.
[1] states the business AND customer must be in EU ("if all of the following apply"), [2] says "payments to European businesses or from European customers". :\
> While SCA is not legally required for businesses outside of Europe, we expect a small minority of European banks to require SCA for all payments regardless of where a business is located
I can believe this since the debit card associated with one of my european banks will only allow online transactions with 3DSecure.
> The beneficiary of the check is the bank, but they tell you it is done for your own security.
To clarify, this is about a liability shift. By putting customers through payer authentication, liability for fraud shifts to either the merchant or the customer, depending on the flow, rather than the bank. This is why the bank is the beneficiary.
After skimming the docs, I'm not sure why you'd want to choose Checkout over Elements in a lot of situations, other than getting some great design work for free with Checkout. The dev time to implement Elements doesn't look that different from the new Checkout, and Elements doesn't require you to redirect your customers away from your site or force a multi-page checkout experience, which is generally associated with lower conversion rates. This also feels really ecommerce oriented, and less friendly to SaaS MVPs, etc.
The old version of Checkout was so dead simple to implement that it had a clear value prop over Elements, but at first blush this seems like a tossup. Braintree's js embed also came to mind after seeing this, since it's a bit less refined than the old version of Checkout, but it's simpler than this solution, and keeps users on your site.
EDIT: After looking closer at the docs, it does indeed look like you'd want to use Elements for SaaS or similar digital products. Unless I'm misunderstanding something, after the user completes their payment on Checkout, Stripe sends you the payment via a webhook, or you have to poll for the transaction. That's a big step back from the old version of Checkout, where you would send a token through to your server from the checkout form, and find out immediately if the payment went through or not so that you could proceed accordingly. This looks nice for ecommerce sites where delayed fulfillment is expected, but not for user subscriptions or account upgrades.
I'm sure they did tons of testing on the experience, but I'm not a huge fan of the Apple Pay button being up top and appearing so prominent.
My guess is that the vast majority of people won't end up using Apple Pay, so from a UX standpoint, I don't understand why it's above the credit card content as opposed to below.
My guess is that they worked out some kind of lucrative partnership with Apple.
The Apple Pay button will only show up to customers who have Apple Pay onboarded and enabled. Customers who don't care about Apple Pay won't ever see the button.
Oh they mean connected on the users Stripe account or the companies? I thought OP meant some iOS API to see if they have Apple wallet set up with an active card.
I'm guessing there will still be a link if the company supports it if it's the former (first party user level).
I wrote some notes below (https://news.ycombinator.com/item?id=19740475) but TL;DR is that this lets us support a lot of features that that the legacy version never could. If you’re looking for an embedded form, Elements work great (https://stripe.com/docs/stripe-js/elements/quickstart) — you can of course pair Elements with a lightbox/modal library to get a similar experience to the legacy version of Checkout.
A modal with Elements could support all the features that old modal Checkout supports. It would not be able to do all the things that new non-modal Checkout will be able to do in the near future.
The Stripe 3DS and SCA page says a modal in combination with Elements is fully supported:
Pre-built modal: The Payment Intents API integrates tightly with Stripe.js and Elements to simplify the authentication process. If your Stripe integration uses handleCardPayment or handleCardAction, Stripe.js automatically handles the authentication process—displaying a modal dialog where the customer can provide the requisite information.
This makes it look like we can build a modal version via Elements which fully supports SCA and 3DS through another modal. All on one page.
Also, the Paymentintent docs say we have to set the viewport to mobile on our page so that the UI of Elements can handle 3DS, this makes it also look like it works on our page through a model without redirects. Otherwise Stripe would set the viewport.
Does Elements fully support 3DS and SCA all on our page through modals or not?
In Elements the payment request button utilises the PaymentRequest API, so Apple Pay in Safari, a (default) purple browser button in Chrome, etc. So I imagine so.
Others have already mentioned that it only shows up for compatible devices, but why would you want it to show below the payment form? That means a user would start filling in the form before realizing there's an alternate payment method. That seems like bad UX to me.
The only thing that's jarring to me is how the button takes the full width of the screen. This is just me nitpicking though, the design otherwise looks great!
Depends on whether your customers are buying on desktop or mobile. It is a big advantage for mobile conversions to support payment solutions like Apple and Google pay.
My anecdata is from this past weekend when I had a choice of ordering from two different pizza apps. I went with the one that offers Apple Pay because the checkout process is so frictionless.
When it comes to buying things online, for me I prefer Apple Pay > Stored credit card number (Amazon) > Punching in a credit card number > PayPal. For me, this is 90% about trust.
Again, just one data point, but it's the only one I have.
I'll personally support this claim, on my iPhone Apple Pay is so seamless (finger over home button and done) that I'll consciously want to purchase it more.
Similar story for one-click solutions such as paypal and amazon. If I don't have to get my card out then I'm far more likely to make a purchase.
> Finger over home button
One of the best use cases for touch id. Apple pay with FaceID is so much more of a pain in the rear. I have to double click the power button, position the phone so it can see my face, then put it back over the reader. Not at all seamless.
The Apple Pay button is a browser feature and unless you mimic it using CSS, it will only show up if you're in a supported region with a supported device that has apple pay enabled and cards added.
Not sure I agree with that. I assume Apple Pay button will only show for customers who have Apple Pay setup/available to use, and for those customers using Apple Pay (1 click secure payment vs manually entering in card info would seem a no brainer).
That's a commonly used design though. Putting integrations above the standard form itself. Many forms do this with Paypal integration instead of Apple Pay.
As a user, I wouldn't want it to be hidden far below the other fields since I might not notice the button and start to fill out the fields unnecessarily.
That doesn’t sound right... what does Stripe have to do with Wordpress? And if Apple Pay is not configured, it’s not going to throw an error, it just won’t show the button.
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...
Be careful when integrating SEPA payments. The asynchronous payment confirmation and no questions asked chargeback policy for 8 weeks after the payment has cleared can be disastrous.
At least here in Finland SEPA direct debit is usually disabled by default for extra security* as domestic shops do not use it (we have redirect-based bank buttons instead) and with foreign ones one usually uses card instead.
So not really an option of choice in entire EU unless something changes - you don't want to tell your customers to enable something on their bank account first before purchase.
But VISA/MC debit cards are extremely common here, so I guess card+SEPADD might cover most people in EU. Though I think many people here are vary of entering their card details online as they are not used to that (then again, I guess the advent of Netflix and others must've made more people familiar with that).
* IIRC you just need the user's IBAN and consent, and IBANs are not really private as people use them to make payments to each other.
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
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.
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?
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?
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.
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.
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 gideon+hn@stripe.com any time
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.
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.
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 gideon+hn@stripe.com so I can get some more feedback from you?
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?
@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?
The EU is not a priority for Stripe, which I think is very unfortunate. They only support a subset of countries. I would have switched from Braintree a long time ago if only Stripe were available in Poland.
Braintree works, but is a source of ongoing cost, as it is impossible to do automatic reconciliation. There is no way to connect the (batched) payouts that you get with transactions/invoices. A major problem in the EU.
Also, Braintree has a terrible risk-review approach, where if you trigger a risk review (for example, by growing), they will freeze your accounts for an indefinite amount of time (from weeks to months) and demand various documents from you.
We are actively working on Poland. I would love to learn more about your business and potentially get you early access. Please contact me directly. My email is felix at stripe com
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.
Unless you're a Big Stodgy Corporation that must have exactly your own custom flow, always prefer the Stripe Checkout flow (either new or old) over Elements. Checkout is easier to implement, provides a polished UX, and users are more likely to trust it over your custom flow.
Use Checkout unless you have a good reason not to. The main benefit is that if there is any large change in regulation (like SCA right now in the EU), Stripe will update Checkout and you will not have to change anything.
3 days after I launched a new site with Stripe-payment.
I love that they removed the “open in new tab for payment” on mobile phones.
Maybe I have to do some rewriting before the weekend..
I have a form that users fill out for one of my side projects with normal credit card info. A few users over the years have requested paypal, but not so many that I felt compelled to dive into their API mess.
But now I probably need to make a change. Stripe Checkout integration looks pretty similar to Paypal Checkout (though with better docs and a more up to date NPM package), but I wonder if I shouldn't just bite the bullet if there are so man y more customers that would use paypal...
Whenever I see these kinds of changes I wonder if the company has any idea of why people use their product.
Given the comments here, either Stripe has no idea that people use Checkout for the single page experience, or they do know it and are just happy to nuke 50% of their customer base for reasons.
It’s just a different product. But it’s being released as a new version of an old one.
I bet the frame busting is deliberate. As a consumer I prefer seeing the Stripe padlock on the current page...a reason this commenter gives for preferring paypal: https://news.ycombinator.com/item?id=19741689
I tried some anti-frame-busting javascript and nginx return 204 trickery which prevents the top redirect but it still returns a Stripe error within the iframe complaining about not being able to redirect.
Looking good, Stripe. I love how you are on to things like SCA well in advance, making life easier for us merchants.
Now if you’d just finally add some VAT handling to Stripe Checkout, and to Stripe overall...then us merchants in the EU will be able to use these nice Checkout pages you create.
I've been looking a fair bit into these embedded checkout things recently and I gotta say that braintree is far-far inferior to Stripe in terms of offerings, usability, API, etc.
There's things one would consider no-brainers for this type of service like discount codes with an expiry date and maximum number of uses that Braintree doesn't offer but their saving grace is PayPal support that, for better or for worse, is a must for most businesses.
The end result is that a dev needs to create a custom checkout UI integrating both services and having their customers split among the two ecosystems which is just gross :).
One of the pain points of the last Checkout page was that it required server-side code. This new version can be used with fully static websites out of the box!
I switched today to the new Checkout and it worked flawless (took me ~1.5 hours).
Let's see how people react to the new checkout. However PayPal is still more common for us (1. classic bankwire, 2. PayPal, 3. Credit card, 4. Sofort/Klarna). Target audience for the ranking is a high order value manifacturing German B2B shop.
Interested to see what the PSD2/SCA implementation looks like. Stripe will go out of their way to avoid adding friction, but the requirements are not trivial.
You’re right, they are definitely not trivial :) We’ve done a lot of work to make Checkout automatically support PSD2/SCA compliance out of the box — we’ll trigger 3DS only when it’s required. More here: https://stripe.com/en-US/payments/strong-customer-authentica...
I've been neglecting the maintenance of the package "react-stripe-checkout" for a while and though this would be a good time to finally bring it up to date, but it appears the new version of checkout was created with a very different use case in mind. Single page, JS rendered apps don't really fit the model, and should probably use legacy Checkout or Stripe Elements.
Disclaimer: Slightly off-topic rant about why I as a consumer will always avoid Stripe:
Will they now not lie about wire transfer being US-Only and accept the debit card they say they accept?
My one interaction with Stripe was absolutely horrible, lost my vendor which is otherwise great a (subscription) sale and will take a lot of effort to right.
Edit: Right, it wasn't just errors, but it just didn't work with any message. One time the credit card number field just became red and shook.
Yes, I'm outside of the US. But was using a card from a provider that was listed as supported. I found no qualifying statements anywhere (in fact I found about no statements meant for end users digging through the Stripe website) and help texts on the page were non existent or utterly useless.
Days of pain trying to pay a damn invoice. The folks at Notion were nice enough to void it, but I ended up switching to dynalist.io for my notes anyway because my trust was sustainably broken.
This experience gives me the impression that Stripe are utterly incompetent in their core business, accepting money.
Weird…sorry about that. I'd like to look into why it was declined. Could you email me the date you tried, card last 4, card brand, and expiration date? If you can dig up that interaction and forward it to me as well, that would be helpful. edwin@stripe.com
While that is not the worst option, our current UX is similar to Shopify, where there is an accordion component with multiple options: PayPal, Credit Card, Apple Pay, etc..
Stripe wants to fetch a premium with this feature. As such, they should bite the bullet and allow merchants to integrate PayPal as a secondary option (similar to how Apple Pay is displayed).
I will say that this is a pretty nice improvement from the modal Stripe Checkout that has been around for several years.