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)
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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’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...
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 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. :-)
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)
> 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.
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.
> 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.
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.
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...)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
213 comments
[ 3.9 ms ] story [ 243 ms ] threadYou can! The docs on our custom integration are here: https://stripe.com/docs/checkout#integration-custom
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?
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.
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.
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.
It mightn't suit your use case though.
The workarounds with bundling transactions don't really work for my use case.
I'm pretty sure the OP was referring to credit/debit transactions...
I think Knox with a fallback to Amazon Payments is a great stack for Micro if you want my opinion.
"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.
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.
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.
Also, it's probably worth emphasizing that the traditional Stripe integration options are all still present and always will be.
but seriously, have at it. Guaranteed there's prior art.
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.
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.
"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?
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.
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.
Out of curiosity, would you be open to running a test to see if "Remember me" has any impact in either direction?
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.
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.
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'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....
https://yoast.com/checkout-field-validation/
But still I would like to have that time back again.
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...
> 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.
[1] https://stripe.com/blog/stripe-checkout
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.
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.
If I lose sales for two years and then EVENTUALLY get a bump, that's two years of network effects and word-of-mouth that I've missed out on.
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. :-)
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 think it would've been prudent to respect the versioned API (https://checkout.stripe.com/v2/checkout.js), and do A/B testing on the latest (https://checkout.stripe.com/checkout.js).
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).
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.
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.
In short, "remember me" should be done after the user presses a button to submit the form.
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.
-Provides enough detail to answer anyone's questions about what it does -Doesn't clutter the overall UI
https://stripe.com/docs/tutorials/forms
As a developer (or really any type of employee or contractor) you should balance your desire for control with actual business results.
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.
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.
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.
Would be exciting to see a shopping cart / coupon features some time in the future.
Simply paste their code into your HTML and you are about done. There's no other backend code, etc. required to make it work.
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.
Not someone who stole the remember-me cookie off the phone, though.
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.
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.
Thanks again for a great product.
> 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 :-).
When I look at https://stripe.com/docs/checkout
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.
Why would offering this option be bad for stripe?
Thanks again for a great product.