New version of Stripe Checkout
stripe.com
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.
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.
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.
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)
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.
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.
If merchants would display a "Processed by Stripe" early on, I'd let up a bit.
The friction in the PayPal UI of making you log in to PayPal to make the payment is a pretty big trust signal IMO.
With PayPal as long as I only enter my password on paypal dot com I know I'm safe.
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.
And your shipping address. That's the killer app for me.
One email/password combo is all it takes to get whatever random thing I'm looking at into my office. It's a real convenience.
Do u mean Euro Paypal accounts cant be just frozen unilaterally etc ?
It is country dependant. The UK is majority credit card.
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.
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.
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.
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).
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 run a B2B SaaS and have so far had exactly zero requests for PayPal. I keep wondering if I'm missing out.
As an individual consumer, I'm much more fickle since I'm usually buying commodities and convenience matters.
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.
There are far to many horror stories about PayPal for me to trust them as a business partner.
SCA: https://stripe.com/en-US/guides/strong-customer-authenticati...
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.
https://www.reuters.com/article/us-europe-moneylaundering-fa...
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 beating this drum because it's still a serious problem and nobody seems to care.
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.
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.
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 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.
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.
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 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.
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.
https://www.commerce7.com/blog/how-digital-wallets-increase-...
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.
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.
Punching a cc is the worst horror UX ever in the history of life
(Presumably the apple pay button doesn't show up if you're not on one of those.)
(I work on Checkout)
But Stripe removed the modal option from Checkout because features?
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?
How is this handled on web forms? I have neither of those but it shows up on the preview.
I don't care, I think it's fine ala login via Google/FB links on login forms being on top. I'm just curious!
I'm guessing there will still be a link if the company supports it if it's the former (first party user level).
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!
I've been getting this WordPress "error" about not having Apple Pay working.
I would never use an Apple product so I was wondering how I got that on my WordPress install.
Now I'm curious if Stripe had better competitors?
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.
With instant (bank) payment coming in september, SEPA might be the option of choice in EU (also Paris here ️)
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.
I understand the desire for a converged Checkout API and UI, but I still kind of wish there were 2 options - modal or redirect.
The only two features I care about are (i) a simple popup to accept cc details (ii) an aesthetically pleasing interface
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?
Does this mean that it will be possible to implement Stripe payments that work without JavaScript?
Essentially:
window.Stripe('<your key>').redirectToCheckout({sessionId});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?
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?
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?
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.
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
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.
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?
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.
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
This change seems to solidify the distinction between Stripe-hosted vs self-hosted
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...
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 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.
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.
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 :).
They now allow email to be prefilled. Very slick when using an Apple device.
Wish they did a slightly better job comparing the old and new on https://stripe.com/docs/payments/checkout
Benefits: 40+ payment methods (including PayPal), full tax management (including filings), more customization options, etc.
Seems like Stripe is behind the 8 ball with this one. Or what am I missing?
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.
>...the new version of Checkout is a smart payment page hosted by Stripe that creates payments or subscriptions. It supports Apple Pay...
Learn more at:
https://stripe.com/docs/apple-pay
https://stripe.com/docs/payments/checkout/migration#client-s...
https://stripe.com/docs/payments/checkout/migration#api-subs...
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.