Stripe Button (beta) | Hacker News Reader

Stripe Button (beta)

stripe.com

289 pointsfirefoxman1159 comments

Outstanding.

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.

Stripe Team: Well done otherwise. Love it.

The Stripe brand is not equivalent to paypal yet

Hear, hear. I actually wrote just that at first but dropped yet by mistake when I reworded my post. Not yet, but here's hoping.

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.

It's pretty much a showstopper for me.

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.

If you haven't checked back already, they fixed this. See upstream in the thread.

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.

Agreed. Hope they don't pull a twitter and require devs to use their buttons.

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.

Weirdly enough, I think if you don't require it, I'm more likely to use it anyway. I call it the 'how dare you' syndrome.

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.

We are working on making the text customizable right now. The button is still a bit of an experiment, so we're taking in feedback and iterating.

Love to have the button text customizable as well. Awesome work though.

Hi, I'm the developer behind the button

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.

Howdy. Thanks for not minifying the JS[1].

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

Though we'll probably minify it in the future, we also will have a non minified version for people to look through.

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?

In your HN profile, it says you work for Twitter. Do you currently work for both Stripe and Twitter?

Probably just hasn't changed HN profile yet, LinkedIn says moved to Stripe in July. http://www.linkedin.com/in/alexmaccaw

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)

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.

Just wondering (*hoping) the UK is in that small list of countries too?

Yeah, Patrick has mentioned that they're working on the UK before. Makes sense, it's the next-biggest English-speaking market after Canada.

As a stereotypically humble Canadian, I feel compelled to point out that UK is an even bigger and more English-speaking market than Canada.

Ah you're totally right. The UK has almost twice the number of Internet users.

I would hazard a guess that the English Speaking Internet User population of India is likely higher than the UK as well.

And Nigeria has the largest population of English-speaking nobility.

It took me three reads to get that. Well done good sir.

I don't get that (Nigeria has the largest population of English-speaking nobility.)

Someone care to explain?

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..........

With apologies to Her Majesty, Canada has more progressive banking regulation.

Canada is a decent pilot market for the UK, since the Queen is on our money and we misspell words the same way as the UK...

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...

There are 43 countries[1] with more English speakers than New Zealand. What led you to work on NZ first, rather than say, India or Philippines?

[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.

Other factors like the country's legal system are also important, especially for a business that is going to be tightly regulated in most places.

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.

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?

Especially since the Samwers managed to clone the whole thing for Germany. I might actually go with them.

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.

I think it's important that they realised just quite how large the demand is for this to happen.

These guys ship like crazy.

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.

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.

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?

HTTPS URLs are encrypted along with the rest of the request.

If a web designer adds this script to a non-HTTPS page, is that still the case?

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.

That is interesting, the form is a POST, must be Javascript doing the GET in its place. I wonder what the technical advantage of GET is in this case.

Maybe has something to do with this: https://stripe.com/blog/stripejs-and-jsonp (they mention JSONP only supporting GET requests)?

Yup. Duh.

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).

The path part of the URL is encrypted along with the rest of the request. Only the DNS lookup (i.e., the hostname) is in the clear.

Okay, thanks for clearing that up for me.

Not at all, sorry for piling on :) I swear there were no other replies when I commented.

Wouldn't stripe's server logs also have the get params in cleartext?

They're most likely being scrubbed out, same as you would with passwords.

The path and parameters of the URL are part of the HTTP conversation that is encrypted.

In a simple sense, only the host name and IP address are not protected.

Isn't the hostname encrypted as well? My understanding was that's the reason you have to have a unique IP for SSL and can't rely on a vhost setup.

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...)

Even the domain name (in the Host header) will be encrypted (unless SNI is used? http://en.wikipedia.org/wiki/Server_Name_Indication)

The domain name is unencrypted in the dns lookup.

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.

> actually I wondered why there is no dnss equivalent to https.

There is one by djb: http://dnscurve.org/

OpenDNS implemented it in 2010 (they call their implementation DNSCrypt, it usually requires an OS extension)

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.

Still seems like a bad idea to use GET, though- those URLs often appear in logs. POST bodies do not.

DevOps here. You scrub those out.

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.

Most webservers that I am familiar with have configurable log formatting, so you could prevent it from being logged in the first place.

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.

The logs sit on a ramdisk before being scrubbed; power removed before scrubbing? Logs are lost, but PCI compliance is maintained.

Patrick from Stripe here.

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.

Hi Patrick,

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.

Thanks, we're fixing this.

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

Additional: the home/end keys don't seem to work in the text entry fields. I'm using Firefox 15 on Linux.

The more I Stripe the more I die inside looking at my Paypal websites.... Please bring it to the EU(at least the UK)

Agreed. Paypal is flat out painful. But they certainly have a huge advantage when it comes to international payment processing.

A 100 times this. And not just the UK please!

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.

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'm not sure what you mean -- Facebook disabled the iframe approach long ago.

Ah sorry. My bad! I meant if Facebook has any plans to avoid using the popup window?

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 :) )

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!

Well the 'purchase' is usually the conversion point of a particular workflow so I don't think that this is really that much of a disruption.

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.

Nice. In the next step, could Stripe start cookie-ing people to remember their payment info across sites?

I'm pretty sure a cookie wouldn't be the safest idea in the world to hold these kind of information

I'm pretty sure they meant that the cookie would be a token and not contain the actual data.

Let me get this straight, you want a Stripe cookie that remembers a user's payment information across unrelated websites?

Yes, like Facebook Connect. This would in fact be more secure than the current solution.

> This would in fact be more secure than the current solution.

... why?

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.

So... like Paypal?

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!

Indeed, I searched quite a while (ok, 2-3s) for a way to get out.

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.

Out of curiosity, does this button produce a receipt of the transaction? Or do I, as the developer and site owner, have to create that manually?

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.

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.

Please bring this to the UK before i kill myself!

Hi Patrick. Great stuff!

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.

Cheers.

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.

I wouldn't call it slightly different, GoCardless is not much good to people looking to lots of small payments.

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.

They must be kidding. They're not seriously going to ask for CC credentials in a javascript popup without any means to inspect an SSL certificate?

Wow, the open/close animation is smoooooth! Almost as impressive as the functionality itself. Going to have to inspect the CSS for that goodness.

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.

>Its the same reason I love buying items from Amazon.

Truth. I wonder if Amazon has looked into entering this market.

https://payments.amazon.com/sdui/sdui/business/cba

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.

Does Stripe ask for any more information than that available on the card?

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.

Waiting for the the day us New Zealanders can use this instead of PayPal.

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.

This is what it looks like on linux, Chromium Version 22.0.1229.92 (159988)

http://imgur.com/Fqm52

I'm using the new stripe button on http://jungleblaze.com and love it.

Hi, nice site you have there.

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 :)

Thank you!

Well done Stripe! Love the creativity and dedication towards simplifying every possible approach to payment processing.

How about it goes even further, i.e. use the webcam to take a snap of the credit card to fill in all card information?

The button itself could use a bit more personality, it currently looks like the generic bootstrap button

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.

The dialog is very nice, agreed - but the button itself is missing the 'brand touch', despite the fact it may have been designed with lots of love :)

Great. But I would like the ability to customize the look of the button if it doesn't go with my design.

Definitely need to add a close button at the top right of that window. Otherwise, nice work! :p

I love it. Well executed. My only comment is to make the text on the button customizable.

I see an empty space on IE 10, could anybody post a screenshot please?

Could you contact me at alex@stripe.com and we can get this resolved. Thanks!

Seems to be resolved, cool.

This looks so awesome! I'm really excited to add this to my projects.

Please open to Europe!

They really disabled Ctrl-c?

Credit card payments is not a place to show off your ability to make pretty animations, IMO.

What are you talking about? The animations are extremely tasteful and restrained. Don't be a curmudgeon.

Reply on news.ycombinator.com