Despite being nearly 3-year old advice, moving security / trust symbols into the visual field of sensitive information remains an easy conversion gain that we see STILL work nearly every time to the order of 5 - 10% gains.
But the current reality is that even being able to test your checkout process on most of the leading "off the shelf" ecommerce platforms is an incredible pain in the ass (I'm looking at you Magento, Oracle ATG, etc)
If Stripe executes on this idea - scaled cart testing - every dollar that an organization pays for Stripe fees is easily cancelled out by a properly optimized checkout form. This is huge.
>I have yet to meet a retailer that we can't hit at least 15 - 25% improvement in sales by testing and fixing their checkout.
>make a major impact on the GDP
I agree on the percentages (I'm myself a big advocate for A/B testing), but I do think that a lot of those gains are made because a certain company becomes a lot "better" than their competitors by employing these kinds of techniques.
Example from my personal life today: I looked at gyms in London. After about looking at 5 I got slightly annoyed: They tried to hide their prices, generally broken UI and I felt they were trying to trick me into a high-paying contract. I then stumbled over site 6: Clear value proposition, not afraid to ask their prices and super easy to do a first training. Sold.
If every single gym out there had a great website, I still would only get 1 gym membership. Though it would probably help if it didn't cause me so much time & pain to do it. But most of the pain is not in the checkout process (punch in credit card numbers). In fact I don't think I've ever not made a purchase because the credit card form wasn't to my liking, the buy/no buy decision generally gets made much earlier and that's an issue that I don't think is for Stripe to fix, but rather for individual companies learning about & implementing great sales channels.
If you dont mind, could you share some of the gym websites you mention in your comment (especially the good one)? I'm a web developer and I happen to have a lot of clients in the health club business so I am very curious to see the sites you looked at (and hope none of the bad ones were me! :)
I don't think that's true at all. It will certainly disproportionately benefit companies that smooth out the kinks before their competitors do, and that will be eliminated with industry wide adoption.
But take the inverse; if every transaction in the world were made more difficult (eg, by removing credit cards and bank transfers, leaving cash and mailed cheques), do you believe that wouldn't shrink the economy?
Worldwide adoption of best practices certainly wouldn't suddenly increase the worldwide GDP 20%, but the rising tide of demand due to reduced transaction friction would lift all boats, so to speak.
That could be one effect, but another effect could be shrinking of the economy. (eg. cases where someone would have made a good & smart purchase but didn't due to amount of effort involved)
Why the high value for a constantly growing economy? GDP is the wrong set of metrics to follow anyway because if you do something that causes pollution and harm to people and the environment, it's recorded as a positive increase.
I'm not sure whether a constantly growing economy is good or bad. Seems very multi-faceted and almost meaningless, really. An economy could be growing or shrinking for so many good or bad reasons.
I think the point we're making is that if people couldn't make the transactions that they wanted to make, it would definitely shrink. That feels like a bad reason for why an economy should shrink.
I appreciate the sentiment, but it's worth pointing out that online retail I the US only accounts for about 5-7% of the market. The UK is doing probably the highest at around 12-15%. So it might make a blip, but don't get too carried away
For those of you reading Third-party JavaScript[1], check out their source https://checkout.stripe.com/v2/checkout.js (it's uncompressed!). There's a lot of stuff to learn there.
Hey stripe listen. Redirecting to stripe.com is STRESS but its good for users because of security.
The overlay can (and would) easily be imitated by crooks who want to steal credit card details.
It would be much safer for users if you offer a paypal-like service where you store their credit details before hand. If you do this, then this is what should happen.
If the users has already logged in, then the overlay would simply be selecting the amount to pay (which coincidentally is shorter for users) and optionally, which source of fund to deduct from if user has multiple credit cards stored.
Security of funds is more important than ease of use.
Unless you are doing very simple ala carte purchases this button reduces total complexity by maybe 5%. If you are doing subscriptions, with coupons, with trial periods, creating users at the same time, wanting to show the user their coupon/trial status, last 4 of their CC, send emails on failed payments, cancel accounts on failed payments, let people update their card, etc, etc, etc it is still very complicated to get all that integration correct.
What stripe needs to do is sponsor the development of an official rails gem that handles all these things like ActiveMerchant (plus views people can then hack on like normal rails views). Many people are implementing these things over and over again, probably including stripe developers themselves for their own side projects. It is a huge waste of effort and source of bugs for everyone.
One nicely written gem that integrated easily with common practices for User models and people could integrate stripe with a simple "stripe_user :subscription, :email_notify" whatever. That would be awesome.
I realize rails is not the entirety of their business but I'm just saying it would make me and a lot of other people happy.
It's not clear to me what you are envisioning here.
ActiveMerchant is a payment gateway abstraction layer, and in fact it already supports Stripe. It has two use cases: A) legacy gateways with shitty APIs and libraries (eg. Authorize.net) and B) theoretical portability between gateways. At my company we recently swapped out AM for the Braintree gem because the lowest-common denominator made it inferior for interfacing against Braintree, and the payment interface surface area in the app is small enough anyway that the theoretical advantage if we switch payment providers is negligible anyway.
Stripe if anything has a better API and ruby library than Braintree (Stripe uses a lot of Ruby internally is my understanding), so what's missing?
A higher-level gem that gives you plugin payments would necessarily start making assumptions and compromises that would quickly whittle down the number of ideally-served use cases, whereas the Stripe API as it stands now is at the granularity to fit the maximum number of use cases without being over-complicated. If you want to make something easier I think you veer into clumsy high-level components that is more akin to Drupal than Rails.
Sorry, what I described doesn't jibe with my comparison to ActiveMerchant as you pointed out. However it would still be badass to get a dropin solution for using Stripe in more complicated applications. And I know Stripe has a better API than alternatives but that doesn't mean it isn't still tricky.
I'm not sure I agree that a higher level gem would be of limited use or only of use to a few applications. I think it can definitely be done in a way that would have helped me big time in all three applications I've integrated with Stripe despite their unique needs.
I'm hesitant to add this to https://www.bngal.com because it seems like there could be usability issues if you need to capture other information on a single checkout form (email address, shipping address, shipping method, etc.).
It seems like a customer would do the following:
- Fill out all data except billing info
- Click the "Pay with Card" button
- Overlay comes up, they enter billing info, then click "Pay $X"
- Overlay closes, token is passed back to form, form is automatically submitted via JS
The proof is in testing and data of course, but my gut tells me people prefer just a single form and button. That's why I like the original checkout method.
Although it is possible to collect the customer's billing address (using the 'address' option) using the Checkout form, it isn't (yet?) possible to add other, arbitrary fields.
For instance, collecting an email address would have to be done elsewhere.
Not having the ability to add an email address field to the checkout form is a real deal breaker for me. I wonder why they did not implement an optional email field.
Yeah, we've had various iterations of this live on the site for a while, though we never announced anything. We renamed it to "Checkout" a few weeks ago.
It looks like `token` is the only callback you can pass to the popup and it receives nothing but the stripe token. Is there any reason not to include more information?
For comparison, this is what stripe.js gives you
{
id : "tok_u5dg20Gra", // String of token identifier,
card : { // Dictionary of the card used to create the token
name: null,
address_line1: "12 Main Street",
address_line2: "Apt 42",
address_city: "Palo Alto",
address_state: "CA",
address_zip: "94301",
address_country: "US",
country: "US",
exp_month: 2,
exp_year: 2012,
last4: "4242",
fingerprint: "BzXGiNioaEH4iECL",
object: "card",
type: "Visa"
},
created : 1358552058, // Integer of date token was created
currency: "usd", // String currency that the token was created in
livemode: true, // Boolean of whether this token was created with a live or test API key
object: "token", // String identifier of the type of object, always "token"
used : false, // Boolean of whether this token has been used,
}
My app uses this information. So as much as I want to, I can't just drop in the new code.
I could use Stripe.getToken but I don't see why I need the extra roundtrips to the server (one for stripe.js, one for getting the info about the token)
Edit: Never mind, I didn't read the docs carefully enough. The callback receives all that, my bad. In the stripe.js docs the parameter is called response and in the new one it's called token. Sorry ;)
Yeah, first they asked for a business certificate and a photo of an id, then they asked for a sign contract, the ToS and an imprintation (or something like that), and I don't know if they'll ask for more. We'll see.
Yeah, the "imprint" is a Germany thing. Every web site needs to have the name and address of the person/company responsible for it. It's a very silly German regulation but if you want to use Paymill you have to comply with it.
Stripe isn't here, and any desire to support their innovation whilst waiting for them to arrive leads to European startups potentially missing opportunity.
It's our responsibility as European startups to get money through doors, and if Paymill is here doing that for us today, then give us a good reason not to use them.
If and when Stripe arrive, I'm sure that many HNers would switch to Stripe as the innovation and support is great. But fact is, they are not here yet... and the only thing that matters is how to process payments in a way that is smooth and minimises our dev time to implement.
If Stripe want our business, then on the day they launch across Europe then they can fight for it.
Until then, Stripe are not here... they aren't even a contender because they are not here. Startups are not going to wait for them on a promise that it will be "soon".
The great thing about the Paymill API is that it is such a Stripe rip-off that if we implement out payment flow based on their API, then we have in fact given ourselves the least painful route to later transition to Stripe.
Implementing Paymill gives us a more likely route to transition to Stripe than implementing one of the incumbents flows (PayPal, MoneyBookers, etc).
So of all options actually available to European startups, Paymill look pretty good.
My reasoning is simple (and has already been stated clearly) - The Samwer brothers are notorious for cloning as many hot valley startups as they can, often pixel for pixel.
Might be legal, but it's certainly not an ethical way to do business. Additionally, I would never trust my business with a company that was in it for the money, especially if they could shut it down at any time, as they often do with other clones that aren't quickly adopted.
Lastly, it's clear you and I have a different set of values, therefore I am uninterested in persuading you of anything. The fact that you don't see anything wrong with cloning other businesses makes you a perfect customer for one that does.
Is it really so hard to understand, or are you being intentionally obtuse?
It really is so hard to understand. We've been begging Stripe to come to Europe for ages now. They still aren't here. Paymill managed to open a company in that time, and do what Stripe does.
Most companies are in it for the money, that's why they're formed. Do you think Stripe will continue existing if they don't make money? That said, the part about shutting down companies that aren't quickly adopted is the only real argument you've made in this discussion.
Copying elements from a startup is ethically dubious, sure, but Paymill is providing a valuable service to people who wouldn't otherwise have it. It's "Stripe for Europe", but why is that bad? If frozen yoghurt is all the rage in the valley at the moment, is it unethical for you to open a frozen yoghurt shop in your home town?
I would totally switch to Stripe if they were available in the EU.
I am thankful that Paymill tries to replicate the awesomeness of Stripe.
Blasting Paymill for copying the model of Stripe is not in the same category like calling distribution of copyrighted material theft.
If executed well it is a net benefit for society.
Hell, I'll invent an app just so I can use Stripe and reassure myself that it's all going to be OK and I'll never have subject myself to the existing solutions again.
That is really nice. Love the integration hooks as well. Next up is a 'we know who you are' stripe cookie that would let you "pay with stripe" on web site A without entering any of this data. Or, for the paranoidish "Enter your StripeID: xxxx" pause "Enter the code we just texted you: xxx" thanks!
Stripe is pretty cool. We've been using it on http://www.IslamicEventFinder.com and was the best library experience to integrate. A few things we noticed, the CVC check is not as impressive, it charges the card even if the CVC is not correct, at least we've seen in a few instances. Other than that it looks solid.
Would prefer some sort of a seal or something on the popup to indicate that their payments are safe, a few clients asked. At least an option to customize displaying that seal would be great and also may be the type of credit cards Stripe accepts.
Is this Checkout thing same as Stripe.js? I didn't get a chance to checkout (lol) this fully yet!
Because the assumption is it's a valid charge but the user simply mistyped their CVC (or don't understand what that number is and put in the wrong thing entirely). If these purchases are rejected, the user may never complete the sale.
I was a bit shocked to see this behavior at first and spent some time debugging it thinking it could be an issue on my side. It turned out not. It's no big deal but could bring doubts on consumer's mind if they intentionally type wrong CVC (I used to do that before on other websites!). Glad to hear that Stripe is on it and can't wait for that tool to show up.
Can you please also answer a few of my other questions including the reliability seal thing? I'm sure that would be a simple change from your side and the developers may not even have to do a thing.
This is great, and I've implemented it on two different sites so far. It's great to be able to tell a client "Just go to Stripe.com, link it to your bank account, and add my email to the account" rather than setting it all up from scratch.
The charging isn't done on the client, it happens later on the server. All this checkout does is turn a user's credit card into a token that you can safely send to your server. Then, server side, you can charge the card or sign the user up for a subscription.
So, in other words the price is client-side, and only used for display. The token gets submitted in a form to your server. And you build the receipt page.
At a previous company, we also found it to be a usability issue. Customers were confused when they were looking for a place to put their name, but couldn't find one. Incidentally, we encountered the same problem when we removed the "State" field from the address section (we could glean it from the zip).
Sample size of one company, so take this for what it's worth.
The dashed vertical line is the maryland/delaware boundary.
You can see there are people both in maryland, and delaware, who have that zip code. The post office is in seaford, de.
This actually came up in the real world in some elections stuff, because these folks often list their mailing address as in seaford, de, but vote in maryland ;)
I like having the city and state filled from the zip code. That way the user can see that it is being used and will not be confused. Plus, pushing a button to enter text that you normally would have to spend time filling out feels like a reward.
This actually wouldn't surprise me. Similarly, not asking for the card type is confusing to some people (even though the card type is identified in the first characters of the card number).
Does this mean the older Stripe Payment "Tag" is deprecated? We're currently using it to great success, but I'm no longer seeing it mentioned in the docs. I don't really want my users to have to press an additional button -- right now as soon as they're on the payment page the form is right there waiting to be filled in.
Well, for what it's worth, I think it would be worth offering the ability to embed this both as a button and as a part of an existing page without the popup. In the meantime, I'll continue to use the payment tag.
Has anyone ever tried making the credit card box freeform? Where there are no rules. Just type your credit card number, your 3 digit security code, your expiry date, and name, and the form works out what entry is what data. I wonder if it would be easier to out weight the confusion of a user trusting a computer.
Big point: I wouldn't want it user-facing (e.g. the ubiquitous self-checkout that is online shopping), but it might be a nice tool for power users (e.g. cashiers).
Yeah, all good and well … but I just used this with a UK Visa Debit card (which are pretty strict in terms of acceptance) on Gumroad, and not only did the thing not verify without a name, but my card got flagged for fraud and frozen until I contacted my bank! I'm pretty nervous about using it now.
An international purchase that doesn't ask for the name on your card though? (I know most check as my CC has a weird format, if it's put in wrong it doesn't validate.)
Added this to https://www.startupthreadsmonthly.com a few weeks ago and have had good success with it. Easy to implement and trigger from js. Still pulling in conversion numbers but users have said they like the flow.
yes, the button is no problem...everything after that is loaded in an iframe though, and so i think xss safeguards prevent you from modifying any of the elements.
Has anyone else not been receiving 'charge.succeeded' events on their Stripe webhooks? We have been receiving all events except that one, even when all charges are succeeding as verified through the management panel. This is a big problem as that is the event that's used to actually process a payment and create a new account.
The problem seems to have been going over for around 8 hours now.
We've received no reply from their support in 4 hours.
Anyone have any ideas how to get in contact with them at this time?
Great looking checkout form. Stripe's adding some clutch features, somewhat seem to be evolving for just payments for developers to payments for developers and others.
The site describes the popup as an "overlay." Another commenter used the words "div popup."
I'm writing this on a machine with Chromium and Firefox on a nearly new Linux Mint 14 install (all packages are up-to-date) with no browser extensions or other weirdness. When I click the "Pay with Card" button in the article, both browsers open it in a new tab.
Are my browsers broken, is Stripe's code broken, or is there some miscommunication about what the button is supposed to do?
Yeah, you can definitely use this with recurring payments. Once you attach the token created by the Checkout to a customer, you can bill the customer whenever you like. (There's more at https://stripe.com/docs/checkout)
Checkout simply creates a token, that you can use to set up a one-time payment, recurring payment, or even to just create a new customer object in Stripe.
Does anyone know of a tutorial or some skeleton code samples that allows you to build an embeddable website widget like this?
From what I can see, there are 2 iframes for the button and the hidden overlay. Clicking on the iframe button enables the overlay via some sort of iframe to iframe communication on the parent(host) page
I haven't used the checkout button yet, but here's what I learned from rolling my own: the form comes in with a token which you then charge with the stripe Python API, and on successful payment, you receive a callback at your webhooks url (which you set in the stripe settings). Take a look at the Django-Zebra app (https://github.com/GoodCloud/django-zebra).
fwiw -- my site is hosted with a company that doesn't have ssl, and we just direct our payments over to a heroku page, which is served by ssl on their free plan.
This is going to lead to phishing. Obviously the possibility is already there, but something tells me that once users get used to this, it will be lead to credit card fraud.
Not on a secure site? Well, the stripe widget just popped up, so it looks legit...
You shouldn't use it on an insecure site, just like any other site requesting credit card credentials. If the site's insecure someone can MITM the whole thing.
Any Stripe employees want to comment on the idea of integrating this with a native iOS app via a web view? My guess is it will still be too clunky vs building your own, but the benefits of continued improvement may be worth it.
Does Apple allow that, without taking their 30%? I was under the impression that's why Amazon doesn't allow you to purchase books through the Kindle app anymore.
Stripe already works with several companies that accept payments and bypass Apple's cut, such as OrderAhead and Exec. There are some types of purchases that must go through Apple, however, such as digital goods/content.
PayPal's PayFlow Pro product would return valid for 1XX, 2XX, 3XX CSCs and different errors (mostly CSC verification related) for 4XX, 5XX, 6XX, 7XX, 8XX, 9XX. Was quite useful for testing.
I love it, but for my app we charge subscriptions with a free trial up front. Do you have any suggestions on how to phrase the wording so it's clear that the charge isn't going to happen right away?
Thank you for mobile support! You guys are truly awesome. If only you would allow me to accept payments without a business and bank account number, like PayPal does...
We don't require a business number of any kind, you can sign up as an individual (the question will be "business type", and individual is one of the options).
I did this the first time I used Stripe, in a little project where I was mainly gauging interest for whether I'd persue it further. Just opened up a second checking account and linked Stripe to that. No cost or pain for me.
You should take a closer look at Stripe before jumping to such conclusions. It's hands down one of the smartest, cleanest and best-documented APIs in the history of the Internet.
They would not make a glaring mistake like this (though their users easily could).
Is this what HN has come to now? People jumping to ill-informed conclusions simply for the sake of triumphantly finding an ostensible flaw are voted higher than people who know what they're talking about?
I have yet to meet a retailer that we can't hit at least 15 - 25% improvement in sales by testing and fixing their checkout.
Take those gains and multiply that times the entire internet and Stripe has the opportunity to make a major impact on the GDP (I'm only half kidding).
A few years back I shared one of our "low hanging fruit" cart optimization strategies that almost always works:
http://www.conversionvoodoo.com/blog/2010/07/proper-placemen...
Despite being nearly 3-year old advice, moving security / trust symbols into the visual field of sensitive information remains an easy conversion gain that we see STILL work nearly every time to the order of 5 - 10% gains.
But the current reality is that even being able to test your checkout process on most of the leading "off the shelf" ecommerce platforms is an incredible pain in the ass (I'm looking at you Magento, Oracle ATG, etc)
If Stripe executes on this idea - scaled cart testing - every dollar that an organization pays for Stripe fees is easily cancelled out by a properly optimized checkout form. This is huge.