Hacker News Reader

Hacker News

Comment by hjek | Hacker News Reader

Parent Full thread

hjek

I like that they are open about their expenses[0]. That's unusual.

I wish they would be able to accept payments w/o requiring users to run non-free JS.

[0]: https://10er.co/open

View on HN

If I wanted to accepted payments with open source JS / no JS, are there libraries that make that easy?

The benefit of using the drop-in iframes / client side AJAX is that I get to take money without worrying about PCI compliance -- whereas if I hit some API serverside I'm handling people's credit card information myself, no?

Would be curious to know what options are out there.

I haven't done web payments for quite a while, but the way it was done 12 or so years ago was, that you generated some signed data for inserting into a hidden input inside a <form action=https://payment-processor.com/...>, and put that into a page server side. This would include all the order and merchant info. You'd also add a submit button with a "Pay now" text.

User would then submit the form and that would take him to the payment processor. The rest was payment processor calling some webhooks on your server with payment verification/other status. You wouldn't see/handle any ccard info at all.

No iframe trickery, no javascript necessary at all.

Users dislike that because it bounces them to a different site.

Going to a different site was sold as a benefit (given that the different site is/was the biggest and the most used bank in the country - so this helps with the trust issue).

Also it's strictly superior to iframe hackery anyway. At least you can check that the site is not trying to scam you for your CC info, which you really can't (as a normal user) when the site is using iframes, because you'll not see iframe's URL in the URL bar.

I'm sure that's correct, but I doubt most users are that sophisticated.

Speaking of which, how do you know?

Not that many people fall for phishing e-mails, for example. It's somewhere between 10-30% based on email type, if that's anyhting to go by.

I couldn't find any research on purely web based phishing.

I'm not talking about people falling for phishing, I'm talking about legitimate customers getting irritated or suspicious and abandoning the purchase after being bounced to another domain to put in their credit card details.

Our conversion rate got much better when we switched to a single-page purchase flow. My theory is that because "real" sites like Amazon don't force users over to a separate bank page, users have come to expect that experience. Redirecting out to Paypal (or whatever) marks you as a "disreputable" fly-by-night operation in users' minds.

I guess it depends on the country. Where I'm from, people were used to push payments (like free wire transfer), or cash on delivery payments, when shopping online. Banks worked hard to change that in the last decade+, so now debit cards are used much more than before. Credit cards are used very little (10% of online purchases).

I only guess that this leads to a feeling where when you give a card info to someone, it's like giving them access to your bank account. But 1 in 2 users can't tell a difference between debit and credit, so who knows.

Users don't like giving card info to companies and almost no companies, including very big online stores, handle card info themselves, or use single-page purchase flow. I rememeber only two local websites that didn't redirect me to some payment gateway in the last 10 years. Amazon is not a thing here at all.

Thanks! I like to share.

JS is he way Stripe works and without Stripe there's no 10er. You're the first one to mention this though. So while I agree that it's not without problems, I'm not sure it's holding that many donators back.

I would be surprised if even 1‰ of the potential donors would care about this aspect. Best of luck with the business!

Reply on news.ycombinator.com