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?
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.
Stripe Team: Well done otherwise. Love it.
This will probably confuse consumers until Stripe has the brand awareness of Paypal.
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.
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).
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.
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.
Someone care to explain?
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.
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.
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.
The SSL keeps the cookies safe from loggers, but not from stripe. The URL, however, is not protected from anybody, right?
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.
In a simple sense, only the host name and IP address are not protected.
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.
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.
No comment box on post page, so posting here instead.
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?
*May cause problems for 2Pac and other new age names...
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.
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.
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!
I would love a complete solution that just allows me to connect this button to a product, and then Stripe takes care of everything else.
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.
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.
Truth. I wonder if Amazon has looked into entering this market.
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.
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.
I found a few tiny mistakes under "About Us", specifically: "The /book book/ didn't make him rich, but it did sell enough /copied/..."
Just trying to help :)