I really like Stripe. They're working hard to make payments work as well as GitHub does for source control, and this is yet another really useful tool. They're not perfect--we still encounter bugs occasionally--but they're responsive and friendly. Goes a long way.
However, one tiny nitpick:
The Stripe brand is not equivalent to paypal and other common payment options, it doesn't yet mean anything to most people. The button saying "Pay with Stripe" might confuse people or not convert optimally, perhaps let the text be customized?
That was my first concern as well. This is a great feature, as long as we can customize the button, otherwise I'm not really excited to share this with customers. As much as I love Stripe, my customers want a way to "Pay with credit card" not "Pay with Stripe".
I'd like to reiterate how important this point is. Not being able to edit the button text is the only hang up I have from implementing the "Stripe" button.
Even when the brand is as big as PayPal, I think that the OP's point stands. When you "Pay with PayPal," you are generally using your PayPal account. You don't need a Stripe account to pay, so you're not paying "with Stripe." PayPal is the system, Stripe is an implementation detail.
I think they need to start with something like 'Pay with Credit Card <br/><small>powered by Stripe</small>', and as their brand grows switch the emphasis to their brand and away from the word Credit Card.
Glad to see they were responsive. I like their work, and love that they've been doing a great job of addressing my actual needs (adding recurring billing, fixing the button nigh instantly)
A co-branded button might be a feature in the future, but that effort was a swing and a miss.
We definitely won't require the button. Hopefully we'll make it useful enough that a lot of people will want to use it. But we also recognize that everyone's needs are different and don't want to force a one size fits all approach onto all our users.
Yea, I agree - if you are accepting payments from non-developers it's probably going to damage your conversion rate. Having an option for a "Powered by Stripe" logo would probably be a better way to build brand awareness.
This will probably confuse consumers until Stripe has the brand awareness of Paypal.
Yes, I absolutely agree. We're redesigning that part of the button, and allowing people to specify various options, such as 'Pay', 'Add Card', 'Checkout' etc.
When it comes to payment-related code, I wouldn't even consider it an option for my shop w/o reviewing it. Was that by design or will it be minified in the future?
Great. While I have your ear I just want to reiterate that the text should be completely customizable, presets to select from are better then nothing but don't make sense.
Who knows what usage people might dream up, what wording works best for their unique case, or hell, different languages. In my humble opinion, everything about the button should be overridable.
I'm using the Stripe button and loving it. I don't mind promoting the Stripe brand, especially when you guys reach the point of adding value because of already established consumer trust, but I'm glad to hear that I'll be able to change the text on the button. Any idea how long until the feature is available?
I agree with you if the button is standing alone, but if its a "Pay with Stripe" button alongside a Paypal and Google Checkout button then I think it adds more street cred than is taken away.
I would love this feature. I'm going to go ahead with implementation even without it, but being able to customize the text would make it that much better.
For me, it would be great if the entire button was replaceable with my own link, not just the text (ie. if I could style it with CSS to my heart's content)
Because users wouldn't have to retype their CC on every page, thereby trusting each site owner (and more). Instead, you'd get used to Stripe already having your info, and a page where the Stripe button prompted you for it would be suspicious.
Actually, I'd be interested to know what are the main obstacles in launching this service internationally. Is it mainly bureaucracy and legal issues, or are there yet other considerations?
There seems to be a bug in Chrome when the javascript validates my MM input. Notice that MM is impossible (66) yet it highlights the YY box (which is valid): http://i.imgur.com/iHYFe.jpg
EDIT: to avoid any FUD, there's no problem with the URL; as the replies say, the path of the target URL is encrypted under SSL.
---
ORIGINAL: I have a question about the security of the button, though I may be wrong. The outgoing request is a GET with the credit card info in plain-text as a query parameter. With it went all of the cookies in the origin's domain.
Yes, the request is still encrypted. However, the original page will be subject to man in the middle attacks, which is why Stripe requires that payment pages using the Stripe Button or Stripe.js are served with SSL.
The technical advantage is getting around the same-origin policy by using JSONP (which by its nature can only be used with GET requests for the script).
SSL encrypts the query string. The only thing in the clear on the wire is the domain name (api.stripe.com). Although there may be other ways for GET query data to leak out (bookmarks, plugins...)
This is OT, but actually I wondered why there is no dnss equivalent to https. Leaking the domains you visit through dns queries is also a problem for TOR and other anonymity systems. Usually the DNS resolver one uses is provided by the ISP. Of course you can change that, but then still the unencrypted DNS queries are sent through central points on the ISP side, making it very easy for them to connect your account with the domains you visit.
The German Privacy Foundation has been offering DNS-over-SSL and DNS-over-HTTPS for quite a long time.
OpenBSD accepts a "tcp" option in the /etc/resolv.conf file in order to force connections to use TCP so that they can easily be tunneled over SSH.
The popular Unbound caching resolver can communicate over SSL to an upstream resolver, and there is even a nice GUI: dnssec-trigger. NLNet provides a public resolver that of course supports this protocol.
dnscurve is a protocol for authenticating and encrypting data between an authoritative server and a resolver.
dnscrypt is a different protocol (although partly based on the same crypto primitives as dnscurve) for authenticating and encrypting data between a resolver and a client.
OpenDNS implemented dnscurve in 2010, and dnscrypt in 2011.
All these protocols have issues in the real world, due to routers and firewalls intercepting DNS traffic, and dropping encrypted queries. Some broken devices and resolvers are even breaking DNSSEC (stripping records), but this is far less common.
A workaround is to use a different port and protocol, typically TCP port 443. Or to use encapsulation in TXT records, which has different issues.
dnscrypt's successor, called dnssig, is also being worked on in order to always offer authentication, and optional encryption.
Cookies are only sent for the domain involved in the request, so only stripe.com cookies would be sent to Stripe, not any cookies for the domain hosting this button.
PCI compliance largely requires that this such data never exist in the first place. Perhaps you can get by with scrubbing after-the-fact if the disk is encrypted, but logs are still "data at rest" and on an unencrypted filesystem I don't see how you could be compliant.
Yes, but the guy I replied to said he scrubbed it, which implies that they did not prevent anything from being logged, but instead they cleaned it up afterwards. Thus the reason for me saying what I did.
In my opinion the button resembles a regular bootstrap button. I think Stripe ought to give this button a little creative touch to make it instantly recognizable; you know, building the brand recognition thing. When I see the Paypal button i instantly know what I'm clicking on.
I use Stripe on our website for payments and it's beautiful. I agree that Stripe is still not that well known outside tech/geek circles. But it will be very useful for one-time payment type of websites/blogs and I'm sure it will give lot of brand lift to Stripe in non-tech users.
To Stripe Folks: It would be great to have "Powered by Stripe" badge so that developers can show that payments are taken care by Stripe.
I'd love to hear the security implications of the button. Seems to me that someone could easily replicate this and trick users into entering their credit card number. Am I wrong? Are there any other avenues of attack? I have an idea about something similar but since I'm no security expert, I'd love to hear what more experienced hackers think.
Phishing attacks have always been possible and will continue to be possible.
Having people enter their credit card details into random online sites is always going to stick around as long as eCommerce exists. You don't have to put a Stripe button on your site for that to work.
In other words, no more insecure than any eCommerce site.
It's not more insecure, but it seems impossible for the end-user to know whether a Stripe form that just popped up is real or fake. Whereas you can first redirect the user to a well-known payment site, where they can verify the site's identity from the SSL info in the URL bar, before trusting it to enter their credit card data.
I agree. I recall when Facebook Connect was first introduced, it provided websites the ability to let non-logged-in users to login to Facebook via an inline iframe. (the experience is pretty much same as Stripe's button's approach). Facebook disabled it shortly after for the reason that I think it's pretty obvious: one can easily create an iframe login form that pretends to be from Facebook and use it to phish login credentials. Instead of using iframe, Facebook now popups a window to prompt user for login credential and app authorization. I believe it will only be a matter of time before Stripe abandon this inlined approach and switch to a popup-based solution; otherwise, they will likely jeopardize their brand/trust when malicious people start to spoof their payment flow.
Also strongly agree. And am still confused about why I had to scroll down to the bottom of the comments to find people who point out what seems (to me) obvious: there is no way in hell I'm entering my credit card into an inline frame.
Does Facebook have any plans do away with the iframe while fixing the issue? I'm trying to figure away out but it just seems like there's no way at the moment.
I strongly agree, and wish I could upvote you more. Before I enter CC details on any site, I check: is it HTTPS? Is the domain correct? The average user might not, sure, but it's there for those of us who do.
This abstracts that away. Creating a duplicate popup would be trivial, and harvesting data -- while appearing "trusted" -- is easier this way than the other way (because you don't even need to bother faking a domain).
I hope the Stripe people are taking this into consideration.
I'm glad someone doesn't think I'm paranoid. We're dealing with money at work and someone thought of the same concept - make it look clean and make it look cool but there's no real way to let a user know that this is legit. I'd love to hear and discuss what Stripe has in mind (Don't worry, we're not in competition :) )
Looks great. I can only imagine that this is the first step towards allowing users to store their credit card information securely with Stripe and not have to pass it through every merchant site. I can't wait until the day that Stripe's ease of use for developers meets (and exceeds) Paypal's ease of use for customers.
Every time I see yet another Stripe post on HN, I get all sad all over again knowing they have no real plans to launch in NZ (or any other country afaik).
After a year or so of waiting they have expanded to only one other country (Canada), and they still completely avoid talking about future expansion other than a token "We are working on expanding into other countries" sort of answer =/
Very cool looking project, but looking more and more like it's never going to be able to used by the majority of the world... (ie any developers living outside of the USA).
I'm sorry. It's really frustrating for us too. To the extent it helps, Canada is very much just a first step for us. We're actively working on a number of countries—including New Zealand specifically.
Hello Winter_Blue Sir. I am Prince Whatusername, a member of the Nigerian Royal Family and I am sending you an email to tell you the good news. I have recently come into a large sum of money (10,000,000 US Dollars) and I would like to share some with you..........
Is Asia being considered at this point? I would expect the English market to be top priority but I'm sure there are at least a few Japanese and Chinese developers who would love to start using Stripe...
EDIT: Many of these countries aren't as "online" as the ones with Her Majesty on their money. But, I should add India scores better on the "number of Internet users" scale than the UK, NZ or Canada.
India should theoretically be the next stop for any startup wishing to expand into other English-speaking markets.
How can you say it's "looking more and more like it's never going to be able to be used by the majority of the world... (ie any developers living outside of the USA)." when they just finished their first expansion.
Now that they've got a system down for expanding, they don't have to do so much work next time. Though every country will still have it's own set of rules and regulations regarding the finances, you must crawl before you can walk, yet alone run.
I have no idea how long it took Paypal to reach as many places as it has, but we have no reason to doubt Stripe will get there too.
> Now that they've got a system down for expanding
I don't think they do since every single expansion is going to be pretty much unique due to the laws and regulations of the country they are expanding to. That is the main problem they have to face and the reason for their 'slow' expansion.
I am sure they can streamline a few small things but I doubt they will be able to speed up things that much.
They're in a business and industry that is difficult enough to launch in a single country, have repeatedly stated their intention to expand, backed up their talk by launching in Canada and yet you say, "no real plans to launch in NZ (or any other country afaik)", "completely avoid talking about future expansion" and "looking more and more like it's never going to be able to used by the majority of the world"?
There are reasons the options are poor; consider those and be patient. The fact that they're even thinking about expanding at this point is impressive enough, considering the hurdles.
With a growing startup ecosystem (500 startups being officially here, for example) and very few payment solutions (for example, Paypal only offering Payments Standard), I thought I'd just drop in to inquire about Mexico on the short list for expansion.
Love the new button, GoCardless is a good alternative for UK (and soon Europe) focused businesses until Stripe launches, know they are different as GC uses Direct Debit.
It's definitely for a certain type of seller. Although you could technically use it for micro-payments, it's not very effective at all. There's Braintree among other competitors too.
Yeah ... but this button is making fishing super-easy. I'm really not sure it's a good idea (the iframe is a clever trick, but the interface could very easily be copy/paste in a fishing website. Users would have no way to check if their credit card is stolen by the website).
The usual way that Stripe works is that you enter your cc info on the merchant's site and it gets sent to Stripe via Javascript. The only difference here is that they're packaging it up nicely.
Boom! The button idea is brilliant. It really seems like Stripe has the potential here to become the payment fabric of the web in a way PayPal once could have been but botched due to a lousy UX.
It would be cool, if you start typing numbers* into the first field, it automatically switched focus to the proper second field and put the CC numbers there. Just made the mistake myself, started typing the example CC number and only afterward noticed I filled out the "Full Name" field.
*May cause problems for 2Pac and other new age names...
2pac would be fine, no common cards use a 2xxx prefix anymore (only [3 4 5 6] are in use these days). 50 Cent might cause issues, but those could be dampened by not bouncing to the CC field until you've entered 4 characters or so.
I think the best design would be to bounce down upon the first number (99.999% of cases) but then allow for the entering of numbers if the user manually clicks back up and enters a number as their name (0.001%).
163 comments
[ 5.6 ms ] story [ 253 ms ] threadHowever, one tiny nitpick: The Stripe brand is not equivalent to paypal and other common payment options, it doesn't yet mean anything to most people. The button saying "Pay with Stripe" might confuse people or not convert optimally, perhaps let the text be customized?
Stripe Team: Well done otherwise. Love it.
I think they need to start with something like 'Pay with Credit Card <br/><small>powered by Stripe</small>', and as their brand grows switch the emphasis to their brand and away from the word Credit Card.
A co-branded button might be a feature in the future, but that effort was a swing and a miss.
This will probably confuse consumers until Stripe has the brand awareness of Paypal.
Yes, I absolutely agree. We're redesigning that part of the button, and allowing people to specify various options, such as 'Pay', 'Add Card', 'Checkout' etc.
When it comes to payment-related code, I wouldn't even consider it an option for my shop w/o reviewing it. Was that by design or will it be minified in the future?
[1]: https://button.stripe.com/v1/button.js
Who knows what usage people might dream up, what wording works best for their unique case, or hell, different languages. In my humble opinion, everything about the button should be overridable.
... why?
Actually, I'd be interested to know what are the main obstacles in launching this service internationally. Is it mainly bureaucracy and legal issues, or are there yet other considerations?
Normally I'm asked for at least a Post Code, which I assume is part of reducing fraud, through making it a bit more difficult to use a stolen card.
---
ORIGINAL: I have a question about the security of the button, though I may be wrong. The outgoing request is a GET with the credit card info in plain-text as a query parameter. With it went all of the cookies in the origin's domain.
GET https://api.stripe.com/v1/tokens?key=W1xyC0XilnJTkz52noGj1Hh...
The SSL keeps the cookies safe from loggers, but not from stripe. The URL, however, is not protected from anybody, right?
In a simple sense, only the host name and IP address are not protected.
There is one by djb: http://dnscurve.org/
OpenDNS implemented it in 2010 (they call their implementation DNSCrypt, it usually requires an OS extension)
OpenBSD accepts a "tcp" option in the /etc/resolv.conf file in order to force connections to use TCP so that they can easily be tunneled over SSH.
The popular Unbound caching resolver can communicate over SSL to an upstream resolver, and there is even a nice GUI: dnssec-trigger. NLNet provides a public resolver that of course supports this protocol.
dnscurve is a protocol for authenticating and encrypting data between an authoritative server and a resolver.
dnscrypt is a different protocol (although partly based on the same crypto primitives as dnscurve) for authenticating and encrypting data between a resolver and a client.
OpenDNS implemented dnscurve in 2010, and dnscrypt in 2011.
All these protocols have issues in the real world, due to routers and firewalls intercepting DNS traffic, and dropping encrypted queries. Some broken devices and resolvers are even breaking DNSSEC (stripping records), but this is far less common.
A workaround is to use a different port and protocol, typically TCP port 443. Or to use encapsulation in TXT records, which has different issues.
dnscrypt's successor, called dnssig, is also being worked on in order to always offer authentication, and optional encryption.
To Stripe Folks: It would be great to have "Powered by Stripe" badge so that developers can show that payments are taken care by Stripe.
Having people enter their credit card details into random online sites is always going to stick around as long as eCommerce exists. You don't have to put a Stripe button on your site for that to work.
In other words, no more insecure than any eCommerce site.
This abstracts that away. Creating a duplicate popup would be trivial, and harvesting data -- while appearing "trusted" -- is easier this way than the other way (because you don't even need to bother faking a domain).
I hope the Stripe people are taking this into consideration.
After a year or so of waiting they have expanded to only one other country (Canada), and they still completely avoid talking about future expansion other than a token "We are working on expanding into other countries" sort of answer =/
Very cool looking project, but looking more and more like it's never going to be able to used by the majority of the world... (ie any developers living outside of the USA).
Someone care to explain?
[1] https://en.wikipedia.org/wiki/List_of_countries_by_English-s...
EDIT: Many of these countries aren't as "online" as the ones with Her Majesty on their money. But, I should add India scores better on the "number of Internet users" scale than the UK, NZ or Canada.
India should theoretically be the next stop for any startup wishing to expand into other English-speaking markets.
Now that they've got a system down for expanding, they don't have to do so much work next time. Though every country will still have it's own set of rules and regulations regarding the finances, you must crawl before you can walk, yet alone run.
I have no idea how long it took Paypal to reach as many places as it has, but we have no reason to doubt Stripe will get there too.
I don't think they do since every single expansion is going to be pretty much unique due to the laws and regulations of the country they are expanding to. That is the main problem they have to face and the reason for their 'slow' expansion.
I am sure they can streamline a few small things but I doubt they will be able to speed up things that much.
There are reasons the options are poor; consider those and be patient. The fact that they're even thinking about expanding at this point is impressive enough, considering the hurdles.
I've used the service for a client and am in the process on two others. Highly recommended, especially if you've ever been in PayPal integration hell.
*May cause problems for 2Pac and other new age names...