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?
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?
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.
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)
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.
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.
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.
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).
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.
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.
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.
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...
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..........
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.
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.
Why would we use a payment processor that only works in the US and Canada? I mean everything I've seen about Stripe looks utterly fantastic, but we've been waiting ages for it to come to Britain and Europe, when is this actually going to happen? What actual roadblocks are in the way of this happening? What have the team responsible for this been doing for the past year or so, sitting on their arses?
Every time someone posts about stripe there is this comment. They have said numerous times that they are working on it and they have to pass through several regulatory hurdles to do so. They also explained in their blog post about the canadian support that many of the hurdles of adding a secondary region to the platform wont have to be done for further regions. So your answer is it will be released when its ready.
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.
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.
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.
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.
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.
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.
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).
I wanted to say thanks for the comments. This is just a beta product that we're experimenting with. As many people here are pointing out, there's still a lot we want to fix and improve (e.g. the button text and how validation works). We definitely welcome any feedback, though -- especially if you go to implement it on your site.
This is awesome guys, great work. One quick nitpicky thing that I don't think has been addressed yet: In Safari after the cancel button has been clicked, clicking the button fades in, then out, and in again before you can enter anything. Edit I'm using Safari 5.1, doesn't seem to happen in 6.
Great work but I do have questions about the security implications. I'd love to have a chat if you have some time. I'm trying to do something similar (button popups and involves money) but we're non-competing.
In case any Stripe folks read this, I tested it with an invalid month (13) and valid year (16,15,13,12 in that order) and valid everything else, and every time it put the red error highlight around the year instead of the month.
No comment box on post page, so posting here instead.
The Year field is specified as YY but it allows you to write up to 4 digits, even though the characters shown are only 3 (the field is not large enough). Tested on Chrome and Firefox on Windows 7.
nb I tried 2015 as year and it was accepted, so I suppose it's ok to specify years in 4digit format
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?
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%).
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.
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 :) )
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.
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
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.
I'm not sure having a modal is the best idea -- aren't modals generally frowned upon because they require a mental recontextualization and disrupt the user's flow? I'm just curious if anyone else had this thought.
Although I can see why having a prepackaged one-button solution would make sense, where Stripe takes care of the presentation / styling / inputs, so there actually is a change of context.
For the record, I use Stripe at my company, and I love it!
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.
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.
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.
For some reason I couldn't find the cancel button, honestly had to look for it for a while. My brain expected to be able to click in the top left or right or on the background to dismiss it, never though to look next to the "pay" button. But otherwise the design is awesome!
Yeah, I'd say a big red cancel button (or maybe give the "Pay" button the whole bottom slice, and have a traditional red X button in the corner), and the ability to dismiss the dialog by clicking outside of its frame would go a long way here.
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.
I don't think that is what Stripe is meant to do. That button doesn't even charge your customer. It provides only a token that you can use server-side to charge the customer.
We're currently implementing invoice payments with the new Stripe button over at Paydirt (https://paydirtapp.com).
One little issue: in Chromium 20.0.1132.47, the button renders with a line break and overflows the iframe like this: http://imgur.com/88st1
The same page renders the button fine in Firefox and other Chrome browsers I checked. Adding `white-space: nowrap;` via the Chrome inspector fixes the problem.
I'm tristan[ at ]paydirtapp.com if you need it replicated.
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.
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 love the Stripe service and use it anytime I have the need for accepting CC payments. However, as a consumer, I see myself choosing the Paypal option for the sole reason that I only have to type in a password vs. taking out my credit card. Its the same reason I love buying items from Amazon. Any alternative to Paypal has to make the buying process just as easy.
Nice implementation. Though I wish they would address the issue with CCV validation. If you use the test card 4000000000000101 which will fail the CCV check, you still get back a valid token.
There doesn't appear to be any way to configure their API to reject a token request with an invalid CCV short of creating a customer record for each request.
Stripe looks great and affordable! Alas, still not available in Europe (request was sent to them more than a year from now). In the meantime, we are working with Avangate.
Stripe has been 5x better than Paypal for me (approximately). Process is seamless. Still waiting on more people to get integrations baked in, but this is good stuff.
The blue color is reminiscent of twitter bootstrap, but the pay dialog with the subtle embossing and slightly rounded corners must have been made with lots of love and care.
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?