Let people pay you. Make it easy | Hacker News Reader

Let people pay you. Make it easy

github.com

94 pointsbegriffs49 comments

The demo app is not served over HTTPS, nor do the instructions tell users to use HTTPS. This is bad.

Yes, in its normal (unattacked) operation, the connection to Stripe will be safe HTTPS. But if someone does a man-in-the-middle attack, then there will be no connection to Stripe, just a connection to an evil website that steals the card (or both to be sneakier; it doesn't matter).

If you're not serving your site over HTTPS, then an attacker can arbitrarily rewrite the content of your site, so no one can trust it.

This is a fantastic point. Someone should make a pull request so that the app requires some CERTIFICATE_PATH variable set and won't work without it. HTTPS or equal security is absolutely required for anything to do with online payments.

It is, although Stripe does only use https. When you post that form stripe.js captures the form submission and submits to its server, returning instead some tokens to identify the charge, so what is submitted through http is actually just a mostly worthless token (assuming that the credentials for the app are secure).

I'm not disagreeing with you, but the site running on https only is important in the context of the user not being thrown away by the lack of https, sensitive information is only transmitted through https.

There's more to it than that, re-read jackowayed's comment. Man-in-the-middle attacks are a real threat that should be considered.

You don't know (as a normal user) that the submission is going to go to Stripe with any high degree of certainty. Someone MITMs the plain http form and changes it to direct the cc info to a malicious server.

What stops anyone doing that on most e-commerce sites? If I go to Amazon.co.uk, my basket is served over HTTP. A man in the middle attack could rewrite that and get me to log into a fake site that looks legit.

Of course, the obvious answer is to run everything over HTTPS, but I'm not sure I understand the difference in what Amazon do and this demo page.

Yeah, even displaying a login form on a non-https page is a big hole for mitm attacks, but most of the web can't be bothered.

Even displaying any page over non-HTTPS and linking to a login page is a big hole for MITM attacks. Who's to say the login page is really on the correct server? As long at the little lock looks green (does Joe Public even pay attention?), it's safe ... right?

The idea is that hopefully the page where you enter cc and other personal info is https. This way, the user can look at the url and see, is this https to the site that I think it should be? If yes, enter personal info, else leave. That methodology works even if the main site is not https. An attacker can only at best replicate the page without https.

I would like to believe that everyone follows that methodology, but I have more experience that that. So for now, I like to believe that at least people who visit hn follow that methodology.

I'm a big proponent of SSL-everywhere, but paying Heroku $20 / month to have a custom endpoint seems absolutely obscene (especially for a small shop worried about simple once-off payments). I guess you could forward non-encrypted requests from your custom domain name to the Heroku-branded endpoint, but that is awfully ugly (and potentially scary to the end user).

Almost best to roll with a cheap $5 plan from Digital Ocean - except then you lose all of the ease of use this project is meant to solve.

At the very least he should probably highlight the possibility of MITM attacks when not serving the original page over HTTPS, but I'm not sure how to solve the SSL issue in a way that's as simple as what Heroku offers without dropping a lot of money in monthly fees.

Annoyance: you start reading, and the page suddenly scrolls back to the top.

That is, the page has mostly loaded. You scroll down, and start to read. The rest of the page loads, and it scrolls back up to the top. (I'm assuming the page codes this, and it isn't a behaviour of FF 20.)

So many sites do this, and it is so annoying. Probably, on github's own servers, loading is so fast that they never experience this problem themselves.

This looks cool, but probably worth pointing out that it's only relevant to Americans or Canadians as it relies on Stripe.

And UKians soon

http://thenextweb.com/uk/2013/03/01/stripe-uk-europe-launch/

Some UKans now, I'm in the beta and it's amazing. I use it for early beta access here: http://beta.getinstabot.com/

Couldn't be easier to work with. Major, major props to the Stripe team.

It sucks so much that we don't have a global, nation-independent payment system. Oh wait.

I appreciate this effort. But isn't integrating Stripe fairly easy with Stripe Connect button (https://stripe.com/connect) without any effort on backend, or even integrating any backend code?

It seems like Stripe connect requires users to create accounts. I wanted to make the minimal app possible to pay me. No accounts, no nothing, just payment.

That said, there's not much to my app. Just some rails routes, a form, and Stripe Checkout on the client side. But it gets the job done.

Yeah, sounds like he meant Stripe Checkout, which is half of the same thing you do (it returns a token, which you then need to charge), but has a better UI.

It sounds like Stripe Checkout is what's needed here. Maybe that's what was meant.

The short answer is: No.

Connect is for marketplaces and does some amazing things to make 3 party payments substantially less painful.

Checkout is for 2 party payments and does some amazing things to make getting credit cards and storing them in a secure vault substantially less painful.

However, neither solution is drop-in zero-code.

Stripe focuses on removing friction at the hard parts of the problem so you can build machines that do payments, Paypal focuses on payments that require no effort on the backend.

It seems like a PayPal button would solve the same problem a whole lot easier.

But then you risk becoming another horror story of Paypal if things go wrong.

Statistically, things do not often go wrong with PayPal. The number of "horror stories" is extremely low for a payment service with hundreds of millions of accounts and $145 billion in payment volume. Regardless, the idea here is to be quick and dirty to accept occasional payments. There's no risk there since you can immediately withdraw the payment. If your account gets closed, who cares. You don't need a Stripe account, a Heroku app, and devops knowledge when copying and pasting a PayPal button or telling someone to send money to your e-mail would suffice.

In my last company a VP once told us, when you do a good job- customers don't feel a need to tell you about it. They just assume things are going right and let it run that way.

But when you do something wrong they generally want to make it clear.

That is what is happening with PayPal here. No one feels the need to write something good about them when everything is going right(Even if that is happening all the time). One genuinely dissatisfied customer can bring you a lot of bad name(Even if sometimes that is purely an exception).

The PayPal horror stories are just the problems that people shout about and that go viral.

In fact the problems with PayPal are much more wide spread. I'd say that PayPal got lazy because no one has challenged them. As a result they still have an underinvested product that is painful to use.

I've used paypal as a merchant/developer on many products and on my latest project I actually decided not to bother charging customers until Stripe arrived in the UK (which it now has).

It's not that people don't feel the need to write something good about PayPal, it's that there's very little good to write about PayPal.

(not to detract from what PayPal originally did, which was monumental at the time, but they rested on their laurels)

Yes, they might be relatively low, but the way they handle account freezes just leaves a bad taste in the mouth. I understand wanting to prevent fraud, but it seems like they catch a lot of innocent people and force them to prove that the money was obtained legitimately. Guilty until proven innocent.

Paypal is infinitely better than Stripe for me, simply because Stripe doesn't work outside US/Canada.

Right now, as an Indian user, Stripe is just something I read about in HN. Paypal is a service which I can use and it works quite well. Nothing against Stripe though. They are still young, and expanding in other countries requires a lot of complicated regulatory work.

I'd be interested in reading about some of the horror stories that developers selling digital goods (paid subscriptions, digital downloads etc) have had with Paypal. Any pointers?

As a developer outside US, Paypal is pretty much the only option available to my startup (selling paid subscriptions to a blogging platform). But it would be good to hear about some issues developers have had with Paypal so that i could try to avoid them.

http://money.cnn.com/2013/01/21/technology/paypal-frozen-fun...

http://conferencesburnedbypaypal.tumblr.com/

http://elliotjaystocks.com/blog/good-riddance-paypal/

http://open-source-scotland.com/2012/news/oss2012-is-hereby-...

http://www.xbmc4xbox.org.uk/2013/01/paypal-guilty-until-prov...

http://www.escapistmagazine.com/news/view/103385-PayPal-Free...

Thanks for the links.

If you offer PayPal only then I'll buy somewhere else.

Does this need the overhead of being a fully-fledged Rails application? What about making it a Sinatra app?

Heh, that is very easy.

I like it BUT it is SO simple and ad-hoc that I wonder if people would be put off by it.

Like the story about users who disbelieve a big system has done something unless it takes a few seconds to process etc.

I wonder if people will think "This is too easy; it must be a scam"

Casual use doesn't fit well into most tech company's business models. Their APIs made to work for casual use because they don't get used casually enough to make the support costs of casual use outweigh the marketing gain for serious customers. If this was turned into a WordPress plugin that caught on and tens of thousands of people installed it on their blogs for casual use, I think Stripe would probably make it more difficult to sign up.

This is nice, but what we really need is something that generates non-ugly "buy" form templates that work with Paypal, Amazon, Google Wallet, and Stripe for direct CC purchases.

Stripe is currently not supported in my country.

PayPal is pretty much the only payment gateway supported.

Is there something like this, but for PayPal?

PayPal, outside of the US, requires you to pay over their site. So no, there isn't something exactly like this for PayPal. You could, however, just embed a PayPal button in your checkout and have the buyer complete the order and pay on PayPal.

But then you have to pay stripe's transaction fee. Why not use something like venmo that is free when you use it with ACH?

Can you share any experience you've had implementing w/ Venmo, especially in comparison to this Stripe implementation?

Is it even legal to accept money like this as a non-business entity? What about taxes?

To be punished for looking after oneself huh.. Well, we have to grow up someday. edit: to by slightly more productive, I'm unsure of any potential legal issues regarding this.

It's income, just like any other income, and is subject to income tax in the US. If you're paid more than $20,000 and had more than 200 transactions, you'll get a 1099-K, but even if you don't, you still have to report it as income on your 1040s.

Also, see these entries in Stripe's FAQ - you're not required to be a business to use stripe: https://support.stripe.com/questions/sole-proprietor-without... https://support.stripe.com/questions/do-crowdfunding-sites-n...

AIUI, incorporation is mostly about limiting liability, and making it easier to sell off the business (or shares thereof) later. There are probably other advantages as well, but making it legal to accept payments at all isn't one of them.

Is it even legal for two people to voluntarily transact using currency? Man, that's some pretty scary thinking...

https://spacebox.io/

> All plans are subject to Stripe's additional transaction charge of 2.9% + 30 cents per transaction.

They should just put that center at the top of the site so I can bounce faster.

https://coinfly.com does the same thing, easy way to send invoices with Stripe.

This is nice. I like it.

Thanks!

you da man, joe! thanks!

the check's in the mail. ;+)

-bowerbird

Reply on news.ycombinator.com