Stripe Checkout is nice, but unfortunately it's not suitable for us, since the "Remember me" checkbox cannot be hidden.
"Remember me" is confusing for users. What is being remembered? By whom? When you're dealing with users who may already be concerned about whether it's secure to enter their credit card number into your website, I feel like the "Remember me" box is just adding another layer of confusion and concern.
I'm surprised that the "Remember me" checkbox can't be hidden, given how focused on their customers Stripe normally is. The "Remember me" checkbox feels like something Stripe is pushing on me to help them with their business objectives, which isn't the vibe I usually get when dealing with Stripe.
[Tl;dr on the below: the changes we make to Checkout are designed to increase our merchants' revenue. If a change doesn't do that, it will be reverted.]
The confusion point you cite was our biggest concern in building the "Remember me" functionality. On the one hand, it's clearly good for our merchants* if customers don't have to constantly retype their card details. On the other hand, it'd be bad if we were scaring them away with something confusing.
So we've been testing Checkout for months. After tons of testing across different sites, types of business, and devices, we're confident that "Remember me" does not harm conversion rate. On the contrary -- all the evidence we have shows that it increases it. If a business has a lot of returning customers, this effect can be very big. For example: we ran an experiment that simply removed the "Remember me" option on Humble Bundle, and determined that they would make less money without it.
To your point about being focused on customers: our rule is to always do what's best for the merchant. I want to really emphasize this point, because I believe it very strongly. The strategy tax example you cite is precisely what we insist we can't do, and where we believe other companies and products have gone wrong.
We've discussed the possibility of allowing users to hide the "Remember me" checkbox, and our belief is that having that option is probably not the best thing for the merchant. We consider it our job to optimize the Checkout in order to maximize our users' revenue. If we add more options, we can easily end up with something confusing and inconsistent. Having a ton of configuration options would also make it harder to pursue other ideas and avenues. The whole point of Checkout is to enable ongoing iteration and improvement. As a result, we'd much rather make the macro guarantee ("we'll work on increasing your revenue"), and build the infrastructure that enables us to do that, rather than forcing merchants to guess what particular tweaks might work best.
Still, even though we've leaned against doing so thus far, we're by no means strongly opposed to removing it. Perhaps, for example, we should have an option that doesn't show "Remember me" but will pre-fill the details if they've been entered elsewhere. Again -- our goal is just to do what's best for the merchant.
* We generally don't like the term merchant, but I'll use it here for clarity.
I think the trap here, a function of scaling any business, is that what's best for most of your customers isn't necessarily best for all of your customers. Another perspective is that what's right for your 2013 customers isn't necessarily the right thing for your prospective 2014 customers.
One possible outcome of your decision is that you're optimizing for customers who have repeat business and against customers with one-off business. That may well be right thing for Stripe.
I am a strong supporter of opinionated software but I think that view has to be colored with "this solution will be wrong for some customers" and "we are not building a solution for every customer". I imagine these assumptions are implied in your explanation above.
For sure. We haven't seen evidence yet that there are things that are amazing for some segments and bad for others -- but if we did (or if we do in future -- we're still measuring), that'd certainly inform our approach.
Also, it's probably worth emphasizing that the traditional Stripe integration options are all still present and always will be.
Maybe. Unless the merchant is also changing site content that you're not aware of and then everybody ends up making decisions based on flawed data and assumptions.
If recurring vs not is important to how Remember Me is perceived, and you've been a/b testing it, you could probably test this particular hypothesis easily.
Probably want the business's prior permission first before testing their revenue funnel - and not just sitting comfortable with a "things will be evolving and changes might happen" as acceptable.
Why isn't it removable? I know things about my customers that you couldn't.
This is the single biggest thing that makes me question whether I trust stripe long term. If you're going to make netwok decision like this now, where's your limit? It stops feeling like payments for developers and starts feeling like a "PayPal that hasn't started fucking over their merchants... yet"
Well, I tried to outline the thinking above, but we're not absolutely attached to it either. If there is some reason it's bad for your customers, we'd love to talk. Can you drop me an email? I'm patrick@stripe.com.
What if you could request a semver range for the checkout js file? That way vendors could opt in to fixes, enhancements or major changes and be confident in the level of volatility in UX for their customers.
A few of the sites I'm involved with have very high trust requirements (think childcare) and low average sophistication users. My core user concern is: users losing trust in my site when they see their credit card info pre-filled but they haven't given it to me. Or, another site having cc info pre-filled when they only ever gave me their CC.
My users shouldn't have to understand the stripe network model to not lose trust in my website. A site knowing, or claiming to know more than it reasonably should is a sign of fraud. In a high trust industry, you need to be very, very careful at the signals you're sending your users. Some of my users will get confused if they click "remember me" and think I stole their credit cards and sold it to other sites.
From a developer perspective, what really concerns me is that this decision was and is clearly being made as "we'll do what's right for stripe and the stripe network in aggregate" not "we'll do right by each merchant." Given that you forced this into the product and then didn't even give an opt out, how can I trust that you're not going to make other changes? E.G. my users now have to create a stripe.com account to use the service in the future? Or, start heavily pushing users to pay by ACH (also something paypal has done)? I don't use paypal checkout because I don't want to force my users to have paypal accounts and I don't trust paypal because they have a long history of these kinds of decisions.
That people are saying "that's the way paypal would add features to the product" should set off red flags and alarm bells in your CEO suite. Right now people are suggesting stripe with the same fervor they're telling their friends to never use paypal. That kind of fanaticism is hard to buy, and if you lose it, impossible to get back. Since you added this "feature," I've stopped suggesting stripe emphatically and without reservation. I just don't know if I'm willing to put my reputation next to your future decisions anymore.
This hurts, emotionally, because I trusted you guys. And moreover, I was excited that there was finally a payments company that didn't suck. Now, I don't know if I was a rube for trusting and promoting you. The emotional process of going from excited evangelist to caution is worse than never being excited about something to begin with.
As a payments provider you act as our agent in the cc world. This "new feature turned on network wide (1) by default (2) without a way to turn it off (3), because we want to test it (4)" makes me trust you less as an agent in 4 separate ways.
I didn't opt into this, it just showed up one day with no explanation.
> We consider it our job to optimize the Checkout in order to maximize our users' revenue.
Even if you ran a controlled study and determined that this checkbox increases conversion by 100x for 99% of your merchants, it is still quite possible that for someone out there with some business in some selected market it harms them (potentially enough to be devastating). There is a reason why PayPal has tons of tiny little options for manipulating parts of the display given to the user, and it isn't because they are somehow incompetent. Unless you are running, per merchant, some kind of machine learning algorithm that optimizes the display for them, thinking you can optimize the flow for everyone and then should purposely not provide options because the merchant might harm themselves if they don't listen to your advice is nothing but hubris.
I agree. I'd go further: even if we were running some kind of crazy ML on a per-merchant basis, I still don't think we could cater to every single use case. I don't think that any UI we build -- no matter how many knobs and whistles it has -- will handle everything. The Checkout page points out that you can still build every pixel of the UI yourself, and Stripe will always support that. Checkout is another option alongside the integration we've always supported, not a replacement.
No, PayPal is fucking incompetent. That's why they have like 4 APIs that do the same thing, except they don't have feature parity and you need a feature from the Pay API and another feature from Express Checkout and you can't do either one of those because PayPal sucks.
We do not have many returning customers, and our customers are not as tech savvy as Humble Bundle customers, by a long shot.
We are using Stripe.js with our own form instead. It's not as nice as Checkout, and I really wish I could use Checkout instead, but as a developer I need to be in control of my user experience, and "Remember me" is not appropriate for my application.
Maybe, but I'm not sure that a test could change my mind, unless it resulted in a massive boost in revenue.
Let's say that the vast majority of my customers do not want to use "Remember me", and that most of them examine the option and leave it unchecked, as is their desire. I've still introduced friction into my payment process, and possibly left a bad taste in the mouths of many of my customers. Maybe not enough that they stop doing business with me, but it could still taint my reputation in their eyes, as a company that is trying to push them down a path that they almost certainly don't want to take.
Testing may indicate an increase in revenue, but it can't account for reputational damage, unless we're going to ask every customer how they felt about the checkout process after they're done.
So, testing based on revenue alone isn't enough. There is probably plenty of testing that shows that adding an array of annoying up-sells during checkout increases revenue, but that doesn't mean it's something I want to do.
Any interest in coming by Stripe for lunch/dinner? I'd love to chat about this more and figure out a good way to accomplish this. (I.e., a product you'd be happy integrating that we iterate on over time.) I'm patrick@stripe.com.
It seems your customers are telling you EXACTLY what they want - an option to remove 'Remember Me'. You don't seem to want a conversation about it so much as a chance to sell people on it.
I'm sorry that it comes across this way. Checkout is an optional product. I've tried to explain that 1) we'll remove it if we find data that suggests it's bad, and 2) we're in no way strongly opposed to removing it. I mean, we're not wedded to any particular aspect of Checkout -- we just want to stay true to the goal of making informed, data-driven decisions and reducing complexity for merchants. If it's bad, we won't just add an option to remove it -- we'll remove it for everyone. This goes for any change in Checkout.
> we'll remove it if we find data that suggests it's bad
So how about instead of saying "let's have coffee" you look at the accounts of some of these people complaining to verify for yourself the things they are saying (such as "lower conversion")? If you feel Stripe doesn't have the data requires themselves to determine this, maybe asking a few of these merchants to send you a report documenting the sales penalty they experienced? This doesn't seem like a very difficult situation to verify, and it sounds like you will be able to learn something really valuable in a really short amount of time that could affect not just this feature but your entire product roadmap.
The "let's have coffee" line (which you tried to use on me as well back when I was demonstrating API flaws and limitations in Stripe a couple years ago ;P) is really difficult to interpret as a "data-oriented" approach to helping merchants: "let's talk about this in person" almost always translates to "I'm a people person who is good at convincing people of things in real time, so how about we move this conversation from a medium that involves long, thought-through arguments that can be backed up by data to one where we are both forced to think on our feet and operate out if memory" ;P.
> If it's bad, we won't just add an option to remove it -- we'll remove it for everyone.
What everyone here is trying to tell you is that this feature probably works well for some merchants (I mean, you even claim to have tested this yourself, so clearly it must) but horribly for others. Is this really an impossible idea to you? :( The people complaining also spent a bunch of time not "just complaining", but providing reasons why their situation caused the flow to be awkward, and those reasons clearly don't apply to all merchants: in some cases people have even tried to determine "the core difference" (one-shot vs. repeat sales). This would be a great opportunity to not pull a "let's have coffee", but instead dive into the data and specifics of the complaints with the people who are trying to help you.
I don't think that "talking" and "analyzing" is a dichotomy. (As shown by the very helpful feedback on this thread.) We've been watching the numbers closely, and we'll continue to do so. If we find that there are merchants for which this works horribly, we'll absolutely rethink our approach. (And they're of course free to not use Checkout.) Coffees drunk and lunches consumed -- i.e., HN threads continued in a higher-bandwith medium -- are orthogonal.
It's this kind of proactive engagement and quest for a clear understanding of your users and their goals that has had me waiting so impatiently for Stripe to become available in Australia.
We're prelaunch right now, but are about to implement Stripe (what will likely be checkout) shortly, after having already settled with a local payments provider.
If you're ever this side of the pond be sure to look me up and we will grab a beer.
I did exactly the same thing. I had to use Stripe.js and a custom form.
I'm doing a monthly subscription, so it feels too weird to have a "Remember Me" button. If my customers are trying to sign up for an ongoing thing, why wouldn't I remember them?
Incindentally, this is a good article that tells how to do the credit card logo, just like they do in Checkout. So I don't look too bad....
I think this is an excellent, well thought-out reply.
It still doesn't matter if Remember Me is better for merchants or not. What matters is whether the merchant wants to be able to hide that feature or not. If they choose to shoot themselves in the foot, it should be their choice.
There are only a few actually plausible reasons why a service would prevent turning this feature off. A nanny mentality (we know what's best for you), which is insulting to the merchant/s. Or because Stripe is pushing something primarily for their benefit, and all the 'explanations' are nothing but rationalizations to make that smell better, the merchant's wishes be damned. Both scenarios are bad.
If they want to shoot themselves in the foot, can't they just make their own payment form while still using Stripe as the processor? That would allow practically any customization of the form that they want.
The plausible reason has been explained by pc like half a dozen times in this thread. Checkout is not the only option. You can build a form from scratch if you want customizability. Stripe is presenting developers with two options: one where they do the analysis and optimization and present you with a ready-to-go payment solution, and another where you can customize it to your heart's content. You (and others) are complaining because you can't customize the former option. This makes absolutely no sense.
Here's a suggestion - why not move the "remember me" checkbox to the screen that appears AFTER the user submits the form? If they don't fill the form out, there will be nothing to remember. And when they do, they've invested enough time and effort to WANT to save their work. Plus, they got to the finish line quicker and with less distractions.
In short, "remember me" should be done after the user presses a button to submit the form.
That philosophy works fine with merchants who hope for repeat sales from the same customer. But what about subscription payments (what I use Stripe for). A remember me button doesn't make sense there, as they are never re-entering the data to make another purchase. Perhaps you didn't test it with enough variety of merchants?
We definitely tested it with merchants who take subscription payments. But, yeah, the considerations are different, I agree. The primary motivating use case for Checkout was "standard" checkouts rather than subscription flows (even though it works well for the latter). I suspect we'll take a look at redesigning that flow entirely at some stage, with a product that may look quite different to Checkout.
"worked well". Now everyone using Checkout for subscription flow has to do work to change it. You just cost your users a lot of hours work, and my site only brings in enough to pay for the hosting costs. Err, thanks?
It's great to hear that Stripe is iterating on products and personally I have been happy with Checkout in the past (I think we were the first site to integrated Checkout when @maccaw first build it). After reading other people's feedback here I totally understand their situation given that Stripe isn't a household name among consumers like Paypal (I hope it will be at some point but don't know how given the lack of consumer products). Why not just add "remember me" as the last step after customer has already inputted their information? This would not create any friction pre-payment and you would have more room to explain the feature. This would of course favor merchants and not Stripe, as you would probably gather less cookies.
My 2 cents.
PS. If Checkout is an experiment still, I would highlight that on documentation. One can't expect people to go and read announcement blog posts dating back a year.
I'm not sure you'd be using their checkout form though for signing up folks for subscription plans. I mean you could but most folks like to control the flow with subscription based plans where there are multiple plans and features etc. Or maybe they intend for it to be used by subscriptions sites too.
I’m going to respectfully disagree with almost everything there, based on our experience.
TL;DR: The changes do not benefit us or our customers, caught us by surprise, and created customer support issues almost immediately. As a direct result, we are now working on moving to a stripe.js form where Stripe’s branding will be hidden as much as possible and we retain full control of our user experience.
I do want to start with my usual caveat that while I’m discussing negatives here in the hope of promoting improvements, we’re generally positive about Stripe, and I’ve waxed lyrical about checkout.js specifically in the past. This appears to have been a blip and hasn’t particularly shaken our general confidence as Stripe customers.
I should also acknowledge that I did promise to send the information below to one of Stripe’s people who replied to my e-mail several weeks ago, and I haven’t; mea culpa. I might as well put it here for general discussion at this point.
So, we’re planning to dump Checkout for a few reasons, but first among them is that Stripe changed our users’ experience for the worse, without our knowledge or consent. That simply shouldn’t happen. I appreciate the desire to incrementally improve things, but not everyone will share the same views on what is an improvement, so pushing changes to our user experience in an uncontrolled way is not really acceptable to us.
For example, our customers typically sign up once for a subscription and then never enter their card details again, so the remember-me changes do absolutely nothing positive for them or us. On the other hand, almost the first customer we had sign up after the changes went live then contacted us to say he’d put in an incorrect phone number and could we please change it to a different one he mailed to us. Our first reaction was that we didn’t collect phone numbers. This is how we discovered Checkout had been changed. Then we looked on the Stripe dashboard to see how to update the information, and it’s not there, so all I can do is mail the Stripe support team to ask for help (and, to be fair, they did, very quickly). So now I’ve gone from having a reasonably streamlined sign-up process to having a paying customer who is distressed because they’ve made a mistake and I can’t even fix it for them. Epic fail.
We had similar reactions to the prompt for an e-mail address, when we had chance to watch some users signing up in person a few weeks ago (not watching them actually enter their card details, of course). They’d just entered their name, postal address and e-mail address on our create-account form, clicked through to pay by card, and now the next thing they get is a prompt for much the same details again! I think every person who signed up that day challenged something at this stage in the process, several being suspicious of spam.
Perhaps the most surprising thing to me, as someone who’s seen overwhelmingly positive views of Stripe on forums like HN, is that the Stripe brand was a clear negative in the sign-up process. In the UK, Stripe is not a well-known organisation in the way that say a high street bank is, and we appear to be losing some level of business immediately because of the branding. For example, someone mailed us essentially asking why we’d let this Stripe organisation hijack our site. There was clearly some general uncertainty from that particular user — they also thought the Stripe form was not secure, because on their iPad it popped up in a separate tab and they didn’t see the padlock icon in the usual place — but uncertainty is to be expected from non-technical customers.
I wanted to send them links to authoritative sources to prove that Stripe was legitimate, but this proved surprisingly difficult. Googling any likely variation of “Stripe PCI” or “Stripe security” turned up more negative links than positive ones on the first SERP (justified, correct, or otherwise, there they were). When I searched for “Stripe hack” I found numerous links to a site called Hacker News, which of course is no surprise to us but more so for our non-geek customers. When I went to look up Stripe’s entry in the Visa Global Registry, as linked from their own site (https://stripe.com/gb/help/faq#pci-compliance), it only showed them as operating in the US and Canada, but both we and our customer were in the UK.
So the bottom line is that we’re going to move away from both Stripe-controlled UX (where the changes have been a clear negative in our case) and the Stripe branding that comes with Checkout. It’s a shame, because the idea is still a great one and obviously it’s more work for us to redo the integration, but when 100% of the customers you’re watching sign up don’t like something about your sign-up process...
Thanks for the long and considerate comment. To briefly respond --
> So, we’re planning to dump Checkout for a few reasons, but first among them is that Stripe changed our users’ experience for the worse, without our knowledge or consent.
When we first launched Checkout, we tried to emphasize that this was a canvas for Stripe to test out improvements. The last paragraph of the launch blog post[1] was:
"Ultimately, we think the structural shift is most important. Normally, you build a payment form and move on. Maybe you eventually get time to revisit it a year later. By integrating Stripe’s payment form, your checkout is continually improving. As we refine and iterate over time, we’ll be able to immediately pass enhancements on to anyone who uses it. We’re looking forward to seeing what you build, and to doing our part to help improve commerce on the web."
Still, I apologize that it was surprising -- and, especially, that it caused any issues for your customers. I think we likely made a mistake not emphasizing this even more than we have. Checkout is very much an ongoing work.
> For example, our customers typically sign up once for a subscription and then never enter their card details again, so the remember-me changes do absolutely nothing positive for them or us.
Well, the goal isn't just to store card details for your customers -- the idea is also that people don't have to type details on your site if they've already typed them on some other site.
Your points on the flow are well-taken (we now enable you to pre-fill email addresses nicely), and you're right that we should probably create a customer-facing "Why you should trust Stripe" page.
While Stripe.js will always be a first-class citizen on Stripe, and you're obviously very welcome to use it, my sense after reading your comment is that most of your issues are likely solvable. If you've any interest in talking more, I'm patrick@stripe.com.
I was also unpleasantly surprised. My initial reaction was that Stripe had jumped the shark to create a Paypalesque checkout experience.
I switched to Stripe Checkout to allow me to focus on other tasks. I was using a versioned API (v2 in the URI), and then it was changed unexpededly. I had to stop in the middle of busy week and go code up my own payment form and get it into production.
My chagrin wasn't just over the UI changes, it was also that the data fields collected and passed to my app changed. (The "Name on Card" field was dropped and email address added)
I know additional anecdotes aren't worth much, and I'm a very small fish, but the addition of the email address and the "remember me" checkbox was an unpleasant surprise for me as well and seems to have increased confusion/uncertainty for my customers.
I'm the author of "Learn Java the Hard Way". My customers aren't interested in a "relationship" with me or my site. They just want my PDF.
Since you implemented this change, 1) my total sales are down and 2) the fraction of users buying with PayPal instead of Stripe has increased.
My 'N' is pretty small, so I can't with confidence say the thing is statistically significant, but it's something I have noticed.
I would VERY MUCH like the option to hide both the "email address" prompt and the "remember me" checkbox.
Hm, could you email me? patrick@stripe.com. I suspect that this is an anomaly, as you say (almost all small samples will randomly skew in one direction or another), and our data strongly suggests and testing suggests that this increases sales -- but if you're right, not only will we add the option to hide it, but we'll proactively do it ourselves.
So, I as a user see the remember me option ONCE, and it's only the first time I check out with stripe, right? Then in theory I go to some other site and it increases conversion on site b because it pre-fills my saved CC info, etc. It seems plausible that change will increase conversion on the second site, but as appears to be the case anecdotally, the change can decrease conversions on the first site. Seems like this could be painful for a site with one-time sales. Could it instead be a dialogue that pops up with clear stripe branding that asks if you want to remember the card for future visits on the web and explains what it is?
We roll our own stripe forms, so this hasn't caused us any issues. Knew that checkout was not something we would use for this reason.
The important thing to see, I think, is that the gains will come not on the first day this rolled out, but over time. One tiny merchant on a single day as the only data point is a sad sample to base decisions on. Particularly for said tiny merchant. Their pick up in sales will not happen immediately, but with time. Removing the "Remember Me" in freakout mode will likely be just shooting themselves in the foot, in a very short term way. But then again, even big companies only worry about the next quarter's financials, and the government so longer invests in infrastructure, so I guess this is the new normal.
When we first launched Checkout, we tried to emphasize that this was a canvas for Stripe to test out improvements. The last paragraph of the launch blog post[1] was
For anything it’s worth, I had never come across the idea of Checkout as a test platform before this discussion, nor seen that blog post. We first discovered Checkout while looking through the basic integration documentation on your site as it was at the time (probably about a year ago) and it seemed like the obvious way to go rather than having yet another form to implement manually and then use stripe.js.
If that has always been the policy, perhaps we should have known and somehow we missed it. In any case, while you’re almost certainly right that most of the issues I mentioned are fixable, it seems like an even clearer decision to move to stripe.js now, because the one issue that it seems won’t be fixed — because it’s already working as intended from your point of view — is ensuring stability in our UX.
we should probably create a customer-facing "Why you should trust Stripe" page
I could not agree with this more strongly. If I could have directed my hesitant prospect to a single page setting out Stripe’s credentials, preferably linked to reputable independent sources for verification, then if nothing else it would have saved us a lot of time trying to figure out what to say and then probably coming up with much the same answer as 1,964 other businesses who use Stripe anyway. :-)
> Perhaps the most surprising thing to me, as someone who’s seen overwhelmingly positive views of Stripe on forums like HN, is that the Stripe brand was a clear negative in the sign-up process. In the UK, Stripe is not a well-known organisation in the way that say a high street bank is...
I am pretty shocked this came as a surprise... customers are not developers: Stripe is just a credit card processing company, providing no user-focussed services (as does your bank, PayPal, or Square, all companies a user might plausibly have heard of and could theoretically have some positive trust associated with: of course, one would also be surprised if a user recognized "Square" even if they use one every day at some restaurant, and depending on your target market they might also not have heard of "PayPal", and while large banks tend to have a lot of brand recognition, it tends to be tied to local regions where the bank operates).
I've experienced this first hand. Stripe is great, and so (was) checkout, but the silent iteration is terrible as a developer. You wind up with support calls saying "why does this look different" and you have no idea anything changed. It's tiring.
It's awesome that you've tested Checkout and are confident that it helps conversion. Would you guys consider releasing the experiments that your ran? I think it'd be a great lesson in testing out products pre-launch.
What if it said "Remember payment details" or "Remember your payment info"?
Although, I agree with the core complaint. It should be a simple parameter to turn that section off and hide it. Or possibly a parameter to change the text next to the checkbox.
Yeah, that's probably a good idea. (It's also possible that we should have an option to disable the checkbox while still enabling customers to log in with their payment details if they've been entered elsewhere...)
I suspect few merchants would experience meaningful drop-off by this inclusion and that over time the feature will benefit all Stripe-using merchants (by increasing the universe of "express checkout enabled" buyers).
As a developer (or really any type of employee or contractor) you should balance your desire for control with actual business results.
You should add that to the "Show me" tour on the website, because currently it looks like the user has to check the box before they see the info, which seems like it would have more psychological friction than also having a (?) button.
I use Stripe Checkout myself, but I think if you make your own form you're be able to leave 'remember me' out. Correct me if I'm wrong though, haven't made a custom form in a while.
Sorry, point of confusion here: what do you want to happen without the line? It's not clear from your comment.
Let Stripe remember the customer without asking (because repeated payments are an obvious thing, and you have to keep the details in your books anyway, so for them, it's a no brainer) or on the contrary don't even consider the possibility (because you don't expect any repeated sales)? In the first case, the problem is that you point it out to customer and make them scare of something innocuous, that they would find obvious if they had to go through it; in the second, you force them to click out an unnecessary option.
Comments seem to point at both options, without realising the confusion.
The potential with saving payment information and tying it to a phone number is really, really exciting. Imagine having a customer come in and buy something without having to enter their credit card. I just donated to Watsi without having to take out my wallet.
The demo of checkout available at https://stripe.com/checkout uses a canvas element for the demo animation. It's a really well done walkthrough. Was it entirely custom-coded or done using a framework / tool to help?
The canvas element is only used on Chrome as it has a hard time rendering animations above a big CSS radial-gradient. The whole animation is just using DOM elements, CSS transitions/animations and requestAnimationFrame. And yes, entirely handmade :)
The code has been specifically made for that particular animation and, to be fair, it wasn’t even modular enough for my own needs :D Joking aside, I’d love to blog about it and more generally about animations in UIs.
You really should do a blog post about it, the first thing I did after admiring the animation was pull open the inspect panel to see how it was done haha. I would love to read more about it.
So, the technical part isn’t that crazy tbh — as soon as you respect some pretty straightforward principles you should be fine (animate only transform/opacity, favour requestAnimationFrame over setInterval, transitionend/animationend events over setTimeout, …). The complicated part was mostly the “creative” process, ie. how fast should the animation run (some people read, others don’t), what's the appropriate bezier-curve, how make the play button “engaging” enough so people don’t feel like they’re gonna watch a billion-hour screencast, etc.
Fantastic stuff. My first experiences in digital design were from the video side so I used to do keyframe animations in Final cut pro, Apple's Motion, and After Effects. Seeing experiences/animations on par with video using just the DOM is very very exciting for me and can't wait to see your post when you get around to it.
This is a really bright idea, in that almost all companies do an absolutely bloody abysmal job of implementing their checkout flow. The median testing budget for it is generally zero, unless you scope the population to "large, savvy ecommerce providers." I love the idea of being able to basically take advantage of the herd effect for optimization, and clearly there are non-linear advantages to the Stripe ecosystem, because getting credential/CC pairs into the system most probably increases systemwide spend on them and that is how both merchants and Stripe make their money.
I'm probably going to try this in Bingo Card Creator in an A/B test against my existing purchase flow at some point. I'll be honest: the likelihood of the average English teacher knowing Stripe does give me a bit of pause with regards to the UX and the prospects of my VA having to answer a lot of "Who is Stripe and why are you telling them my credit card number? Did your Googles get a virus?" emails. Still, seems like it is worth testing. Worse comes to worse, all you do is go back to the pre-existing checkout flow, like whatever Stripe.js integration you're using right now, and then you have full control over the experience.
I have seen and supervised successful redesigns of purchase experiences before. They print money. BCC got a 60% or so lift in purchases using a Stripe-powered checkout back in the day, after some hillclimbing, discovery of synergistic effects, and burning the kinks out of my integration. I think there's likely motivational numbers hiding in a lot of your businesses. You should absolutely be testing them on a regular basis yourselves, but this seems to be a decent stab at a way of doing testing without requiring focus/bandwidth or major traffic [+], which are two major reasons people give me for not testing.
[+] I have noticed many people suggesting "You could do per-account multivariate testing on e.g. whether the Remember Me button is a win or not", and feel obligated to point out "That will probably only work for accounts which are doing, minimally, thousands of transactions a month." The great thing about this is that if you've got only 2k visits a month and 40 purchases if we assume that systemwide performance is a good proxy for your performance (and n.b. that's an assumption which is tractable to measurement) then we can still get solid test results by using the other millions of visitors and hundreds of thousands of transactions flowing through the system every $PERIOD.
Background: I spent the last 2.5 years working as a product manager at another payments company. I've integrated Stripe.js in various side projects. I saw first hand what happens when you make a checkout highly customisable (dozens of options): you introduce huge complexity cost.
Here are some ways this manifests:
- longer dev cycles/increased difficulty in testing/more frequent release rollbacks
- higher merchant support costs
- harder to innovate
- a need to support dozens of legacy use-cases that only some merchants use
- harder to onboard new merchants
- more complex sales process
- inconsistent user experience for customers
- higher staff training costs/time
- impossible to optimise conversion for the majority, as each merchant is showing a different checkout.
It all starts with 1 option, but it's a slippery slope.
In summary, I think Stripe are probably taking the right approach here, and I wish them the best of luck.
TL;DR: +1 on making the "Remember me" checkbox optional.
I'll try to offer a slight variation on what others have already mentioned regarding checkout. Like many of them I find Stripe to be very well thought out and easy to implement.
As far as Checkout goes, the idea is great but it might need some updates in order to make it more useful to a wider audience.
As other mentioned, the "Remember me" function was enough for me to not use Checkout. It is confusing, perhaps because it introduces a mental shift in the user's mind, where out of a sudden they need to understand how this other company "Stripe" will magically keep their info across devices. A way to hide that field wouldn't harm anyone (other than Stripe's ability to do branding).
It would also be nice to allow style customization of the form.
At CircleCI, we've been using Stripe Checkout for quite a while. It was increadibly easy to set up and very high quality (we replaced a hacky ugly checkout page with it), and it looks really professional. That professionalism is really important at the final stage of the funnel.
One of the things that's really interesting about Checkout is that Stripe is actively focusing on increasing the conversion rate for us. Their new layout (with the phone number) has a 20% high conversion rate than the previous version.
Try watching the animation (click "Show me" on the page). Basically, we use your email address and phone number to save you from having to type in your credit card number everywhere.
We've been using Stripe Checkout at Humble Bundle for quite a while and it has been awesome. It is really easy to set up and once a customer has used it, it's incredibly easy to checkout in the future. Every couple weeks I hear about a new A/B test that is running to try to make it even better.
Small question about Humble Bundle's usage of Stripe: what prompted the move from requiring only the CC, expiration date and CVV, to full name and address? I was disappointed to see that.
First off I'm a huge stripe fan I recommend them to clients daily.
I contacted stripe about an option to disable remember me on an existing stripe checkout form at the request of a client.
I was very surprised stripe said that wasn't going to be an option. They said we tested it and it will increase your conversions so it's not going to be optional.
Not very stripe like at all. I can understand it being on by default to move things toward their business goals. And it even looks like a nice feature.
But for it to be required doesn't seem friendly.
Being developer focused I would expect stripe would appreciate having control over the look and feel of your checkout process.
I'd like to hear an explanation of the issue it would cause stripe if it was on by default but they provided a flag to turn it off like some of the other checkout fields.
> Being developer focused I would expect stripe would appreciate having control over the look and feel of your checkout process.
I completely agree! Stripe always has and always will let you have complete control over every pixel of the look and feel. In order to enable us to experiment and optimize with Checkout, we can't enable as much experimentation and customization there. But if you'd like to build your own flow, we'd love to help enable it :-).
I see the simple integration and custom integration . . .
under custom it would be great to have an option for
data-remember-me
false
I expect stripe has enough traffic to experiment and optimize with remember me being on by default on most stripe checkout forms.
Being a developer it's a simple addition for stripe to make for more flexibility . . . if it's enabled by default I expect it would be active on most of your checkout forms.
I just don't see a reason not to offer this option.
It might not affect conversions on 90% of checkout forms.
But it is affecting conversions for clients signing up for stripe. I have existing clients asking for it to be removed . . . and new clients asking for it to be turned off on their stripe checkout.
Granted we could all roll our own forms without it but checkout is one of the big selling points for getting new clients to sign up for stripe is how fast it is to setup with stripe checkout.
I guess it would be interesting to hear an explanation of why it isn't an option since you offer similar options for the 'custom' stripe checkout form.
> We've been testing this for the past couple of months—our hypothesis was that it would increase conversion rates—and we're delighted that it has been confirmed.
pc, do you know if the conversion rates increased for the majority of the subscription-based sites that you monitored?
Our company has a subscription-based service that uses Stripe Checkout, and some of our customers have expressed confusion regarding the "Remember me" feature. Even the CEO of our company expressed confusion initially, and he requested that I ask Stripe for the option of hiding the "Remember me" field.
From their perspective, there's no reason why their payment information should be remembered because they have no reason to enter their payment information again in the future since our service is subscription-based.
I think the "Remember me" feature would be less confusing at an e-commerce site where customers may make additional purchases in the future.
Also, we'd like to be able to hide the customer's email address in Stripe Checkout, not just disable the email address field.
So essentially, we want the old Stripe Checkout that only requested payment information.
> pc, do you know if the conversion rates increased for the majority of the subscription sites that you monitored?
We did look at the effect on individual sites (rather than across all charges as a whole). But I generally agree with you that it'd be nice to have something better-tailored to subscription website flows. (I suspect that this product might look quite different to Checkout.)
FWIW, I don’t see any particular problem with using a Checkout-style process for subscriptions. We used it for that from the start, and looking through this discussion it seems we’re far from the only ones.
For us, the big win was having a reasonably polished and ready-made form to get from zero to having a card token, which meant one fewer thing for us to worry about during integration (and building the rest of our site, of course). That seems just as valuable whether you’re accepting single payments or signing people up for a subscription.
We set it up over here @Patreon and it was EZPZ. One issue that wasn't clear from the documentation -- the "custom" setup (https://stripe.com/docs/checkout#integration-custom) is preferable for so many reasons (and it's no harder to setup, not sure why it's not just the only option) -- it doesn't "take over" the form so that a credit card is required on submit and it also returns a bunch more relevant info like the last 4 digits of the credit card, the expiration date, etc. so you can save and display the card info for future checkouts.
> it also returns a bunch more relevant info like the last 4 digits of the credit card, the expiration date, etc. so you can save and display the card info for future checkouts
I believe you can get all that out of the token Stripe gives you with Checkout. It's certainly available in the dashboard for a Checkout charge.
Hot damn. The design and experience I felt from this page is overwhelmingly great. I've always loved stripe's design and they continue to blow me away. Really excited to activate our account any day now.
I don't want to detract, but it's a shame that your https://stripe.com/checkout page isn't optimised for mobile. I wanted to have a look at the demo on my phone as well as on my desktop.
Interesting move by Stripe, and I guess it explains why WePay and Balanced choose to focus on the API and not their d2c offerings.
With the 'remember me' feature, Stripe has chosen to impede upon the territory of their developers, which greatly concerns me.
I love their product, but one of the reasons I choose to use them is because of the options that their API provides. Is this a back-end play to eventually cut out developers, or is it designed to help them sell more product? I'm sure Stripe staffers will say that it's the latter, but if that's the case, who is the primary customer for this offering?
This move was directly motivated by our users telling us that they want us to help fix payments on mobile devices. If you want to use Checkout (it's completely optional, and will always be), we think it can help you a lot here. Checkout contains the smallest amount of Stripe branding possible.
> Is this a back-end play to eventually cut out developers
That's crazy! We built a new feature in response to feedback from developers. Nothing is going away.
Can you imagine ways of doing this better? (I'd genuinely love to hear suggestions.)
First off, the entering of email addresses and remember me stuff is confusing for my customers. We sign up people for a free trial and take their credit card details before we sign them up as users. Even quite technical people have dropped out of the flow after signing in with stripe thinking "I've given them my email" and so people haven't properly finished the signup process because of this (I'm guessing I can probably get this email, however I'd still need to prompt them for a password).
The second big issue is that the constant changing of the form kept breaking various integration/acceptance tests that I had written. This was pretty frustrating as it seemed that I would get a different box from time to time and my tests would start failing.
I get the desire to A/B test, and the desire to build a network of users who have already given their credit card details (obviously amazing for mobile) but it would be nice for us customers if we had a flag where we could switch it off.
Ask HN: I run a tiny home business making widgets. My web page, including order form, is pure HTML.
From what I can tell (looking at page source for the Watsi example), at the very least in order to use Stripe, I have to add some JavaScript to my web page, and of course test it.
Granted, that shouldn't be a big problem for a skilled web developer, but I'm not one.
You need some lines of JavaScript you can basically copy 1:1 from the docs (or if you scroll down the linked page there is also an example).
But you also need some backend to handle the actual payment. The widget generates a token which you can use to create customers, charge them etc.
Have been using Checkout on https://deployer.vc and https://zoned.io - it's absolutely excellent: very easy to integrate, and looks really good. Will be switching over the other products as well over from PayPal.
May I ask a honest question: why did you add email and remember me? It looks something like VCs will suggest. This makes me no to trust Stripe as platform.
Somebody smart said: the incumbent are wounded by the first disruptor and that disruptor eventually becomes the same as the incumbent and, then, both are killed by the real disruptor.
Now if they only did same/next day payouts. The founder once said this was possible if you emailed him. I emailed him and got zero response, from him or anyone else, so I'm guessing they are only doing this for super high volume merchants.
Hi Patrick, is there any timeline for international payout support? I am currently working on a marketplace project and I'm looking for options other than PayPal.
I'm particularly happy that iOS Chrome is now a "first class citizen". There were some shaky times before where it (provided you saved your form) showed the mobile view that Safari gets; then where it failed completely (with a JS alert()); where it showed the desktop modal (okay, but a bit janky) and finally where it had a made-for-mobile modal.
I'm a big fan of Checkout otherwise: it's definitely simplified things for me. I'd just like to see more communication regarding changes: I discovered most of those myself from my staging site.
From your video, I noticed that on a smart phone, you authenticate user by sending a code through text. Isn't that redundant? Whoever has that phone will get that text..
Whatever API they are using the get the phone number without the user entering it on mobile is probably easy to spoof. It may not even work on all platforms and the user may have to type a phone number in that case.
Would you trust a phone number handed to you by a PhoneGap JavaScript method, for example? It would be pretty easy to tweak to return whatever is needed.
The mobile number is entered by the user on his first purchase, not retrieved from the device itself. I don't think any device exposes phone numbers to browser APIs at all.
Stripe Checkout is amazing. Used it for a few months and it's worked extremely well. Glad they are constantly updating it. Looks even better than it did before.
That was my initial thought too. "How would this work on mobile if it's not giving Apple a 30% cut?" Turns out "mobile" means "mobile web", not to be used in-app.
We use Stripe checkout at http://leaddyno.com for subscription signups using the custom integration features of the checkout widget. We also use it in our app for customers to update their billing information. Its great they made such an awesome widget and ALSO made it very easy to customize and integrate programmatically! We love it!
PC is this cross merchant? That is, if one end user of a Stripe merchant stores their card and then that same end user visits another Stripe merchant are they remembered? I see "Stripe stores your card for this site and others" or wording like that.
Nice, Checkout is great for Ad-hoc payment. I'm using WordPress Easy Digital Download plugin that already has Stripe support. EDD automatically creates user account, and tracks usages, and sends confirmation and download emails to buyers.
Now I'd just love for you all to make capable of having products attached to it and operate like a shopping cart ;) -- But seriously your designs look so good, I'd actually want that.
Stripe checkout is great, but I really miss the ability to add custom fields to the form, such as VAT number and Company name.
I realise that allowing to add a whole bunch of fields can hamper usability, but I have to collect the VAT number in order to figure out how much to charge the customer.
Does anyone have a recommendation about what to do here? Roll our own form and lose all the nice stuff from Stripe Checkout?
Display a new form for VAT after displaying checkout, and charge after that?
I use Stripe Checkout at postperfect.co. The only thing I really wish it could handle was a discount code implementation, which I had to do myself unfortunately.
I still don't completely understand how Stripe can be so cheap. How do they pass charges onto payment processors without incurring some sort of fee that is not equal to the market rate for all other transactions? Is there some sort of fee scale on the processor side that decreases as the transaction amount increases?
I'm guessing you could renegotiate the rate based upon taking on some of the liabilities. e.g. if Stripe says, hey if we take on all the cost of fraudulent transactions, can we get a discount for the transactions we send through your network?
Very interesting. Since Checkout brings in an element of the developer contributing a user to Stripe via 'remember me', I'd love to know the tradeoff here.
What is the probability today, that when a user of my app hits Checkout, they will already have a credit card saved which makes signup faster?
Checkout is a great way to get started fast (like, in <15 mins).
Multilingual support would be great, and also a more customer friendly interface for those who might not be familiar with things like CVCs. Those two things are reasons I had to stop using checkout and use stripe.js instead.
Looking back at my sales, too many customers use Paypal to simply go to Stripe only.
I wish someone would make something that is as easy to use as Stripe but also offers Paypal. The few I've seen are still everything and the kitchen sink, not just a simple stripe + paypal combo.
While this is admirable, it flies in the face of security-based UX. For years we've taught people to only send sensitive information over SSL, and to look for the lock, green bar, etc.
Now you're asking people to blindly punch information into a box and hit send?
Stripe is pretty sweet, and we're in their beta to receive funds in two days. Any idea how they actually do this? Two is certainly faster that the normal seven days, and I'd love any insight or theories from the HN community.
I am getting ready to launch a product. I was using Wepay until they eliminated their checkout form. Switched to Stripe, read up on the API, and implemented the form. Now you tell me their is a simple checkout widget available. Sigh.
I love the UX for the stripe checkout. It seems like the integration script creates a full page iframe allowing the widget to have full control over the UX. Is there any guide to building a similar full page iframe widget for other applications?
I really want to use Stripe but it would be great if they had a more favorable pricing structure for microtransactions. Paypal, for example, will charge 5%+$0.05 or 2.9%+$0.30 (whichever is lowest) for digital goods transactions.
This. You basically have to use PayPal or Amazon Payments when you're dealing with microtransactions if you don't want to lose up to 40% just in processing fees.
The workarounds with bundling transactions don't really work for my use case.
Yeah, no. Does that site support credit/debit card transactions? Nope. ACH / bank transfer payments are a non-starter for many people and sites, and conversion rates are much lower.
I'm pretty sure the OP was referring to credit/debit transactions...
Just saying there's an option - and we've made ACH way better (I should have disclosed up front in the original post that I'm a founder) and increase conversions above and beyond CC's. It's also safer - nobody ever gets your info, it stays with your bank where it belongs. It's something to consider.
I think Knox with a fallback to Amazon Payments is a great stack for Micro if you want my opinion.
Looks pretty good. Except I assume it's only for US customers? We're based in Germany, where bank payments are more common than credit cards (because only relatively few people actually have credit cards).
This has existed for a while, and I'm using it on my site. Didn't know it was "beta." Works great. (Still in test mode though, have not yet exited beta so I'm not taking anyone's money yet.)
I'm not a fan of the payment input in a separate window, although I'm not sure if that's just a browser quirk on my end. Much preferred the old modal dialog on the same page.
The use case is for marketplaces (and maybe crowdfunding sites). An escrow service is a means to increase trust for both the buyer and seller sides. Funds are paid up front but held in escrow until goods are effectively exchanged or services rendered.
I realize that it is a major feature and requires more than just code, but I'd love to see another major player in this space that isn't PayPal. Balanced Payments and MangoPay are great but they aren't household names (that customers are likely to recognize) like Stripe is fast becoming.
Stripe does exactly this. When you make a payment to stripe it does into your account which is an escrow account, which you can then use to make payments to others, like a marketplace setting.
My name being Ben and a stripe, dribble & humble bundle user, I had to open in an incognito window to double check that it wasn't scraping my name somehow..
They're great the first time you charge someone. But there are things that can be really hard when you try to add seats to an account or do renewals. E.g. one thing that I know has been really frustrating to our engineers is that they don't support applying a discount amount per seat.
Does this allow you to change the price dynamically though?
For example, if the user selects Canada for their billing address I must then add the appropriate taxes to the price dynamically. Doesn't seem like that is possible?
I'm afraid we don't support that use-case yet. If you'd still like to use Checkout, you could use it as a method for the user to add their card, and confirm the payment amount on a separate page. (the 'amount' field is not required)
so how do I integrate this to my website ? I am currently using https://www.paymentiframe.com/ because the form looks really nice like a credit card form.
I'm not a security expert, but using a random 3rd party's IFRAME on your website to process payments through Stripe sounds INCREDIBLY dangerous. I would advise simply using Stripe Checkout https://stripe.com/docs/checkout
Simply paste their code into your HTML and you are about done. There's no other backend code, etc. required to make it work.
"Remember me" is confusing for users. What is being remembered? By whom? When you're dealing with users who may already be concerned about whether it's secure to enter their credit card number into your website, I feel like the "Remember me" box is just adding another layer of confusion and concern.
I'm surprised that the "Remember me" checkbox can't be hidden, given how focused on their customers Stripe normally is. The "Remember me" checkbox feels like something Stripe is pushing on me to help them with their business objectives, which isn't the vibe I usually get when dealing with Stripe.