Stripe Checkout
stripe.com
stripe.com
"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.
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.
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.
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.
In short, "remember me" should be done after the user presses a button to submit the form.
"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.
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...
> 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 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'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 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).
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.
As a developer (or really any type of employee or contractor) you should balance your desire for control with actual business results.
-Provides enough detail to answer anyone's questions about what it does -Doesn't clutter the overall UI
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.
And it does a great job at actually communicating exactly what you wanted it to, which is also an uncommon skill.
Would like to get feedback on what you really liked about Stripe experience and how to improve Castbin.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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?
> 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.)
2 big issues.
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.
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.
Am I understanding it right?
One implementation from Stripes docs https://stripe.com/docs/checkout/guides/flask
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.
Any chance this is possible for us as well? This is the only reason we're using PayPal for the majority of transactions at the moment.
Thanks, Ritesh
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 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.
Well played.
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?
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?
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 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.
I'd be curious as to how many you'd lose by ditching PayPal versus how many would just go ahead and put in a CC.
The cart is fully responsive so it works on mobile as well!
I am one of the founders, let me know if you have any questions.
Now you're asking people to blindly punch information into a box and hit send?
Paypal really needs a new leadership team that promotes innovation. Stripe is cleaning up, and I'm about to take a lot of business to Stripe...
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?
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.
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.
Would be exciting to see a shopping cart / coupon features some time in the future.
You 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?
Simply paste their code into your HTML and you are about done. There's no other backend code, etc. required to make it work.