Hacker News Reader

Comment by donatj | Hacker News Reader

This. Entirely.

I used to work for a small ecommerce webdev shop. I’ve worked on sooo many shitty insecure shopping carts over the years I simply know not to trust basically any small website asking for my card. Completely unencrypted, storing CVVs, sending CC details as GET parameters, I’ve seen it all. It’s painfully common!

If a company is not a huge name, and is handling your credit card info themselves, they are mishandling your credit card information in one way or another. I guarantee it.

Having been through PCI compliance, it’s no joke. It’s really not worth doing yourself in my strong opinion.

View on HN

This. I wish there was a fundamentally different way of handling payments. Something like a one time hash you give the vendor that serves like a digital check(cheque). This way, if they lose the hash they lost their money instead of the customer's.

Handing a merchant credit card details "feels" like handing them a blank Check and trusting them to not take more than they should because of the risk of them losing the data.

Edit: The digital hash should say where money comes from, to who, for what purpose, time, auth code and so on.

I live in Denmark, and they have a system of phone banking here called "Mobile Pay" it works kind of like that. Where you transfer money to the merchant public phone number and show them proof of sending.. However it only works for in-person payments where you can swing your phone to show.

There are also banks that provide virtual credit cards that can only be used by one merchant and where you specify the max amount and expiration date.

Yeah, but that's like buying a gift card for every merchant. That's a huge inconvenience. I can't buy one for every small website I want to buy stuff from..

It's 2018 we should be generating these on the fly from my encrypted 2FA phone app instantly.

This is a reality in many places already. On the internet I never input any real card details, I go to the app, generate a virtual card with X amount available or for one buy only or for a single merchant for Y amount of time and use the generated card details instead.

You do, if you use Apple Pay or Google Pay.

There's ApplePay, which provides a very nice experience (if your customer is using Safari :( )

> I wish there was a fundamentally different way of handling payments

Seconded. At the risk of simply rephrasing everything you just said:

It's a pity the banks and credit card companies just refuse to innovate.

When I buy something from an online vendor, they should never get my full card details. PayPal ameliorates things (you can generally trust PayPal), but really there should be no need for PayPal. The banks/credit-card companies should provide a convenient way to authorise the payment, in a way that doesn't trust the vendor.

Here in the UK, we already have chip-and-pin, and card readers (the kind that show unique numbers - they're used for online banking), but we're still stuck with the trust-the-vendor-or-use-PayPal model for online payments.

Using card-readers for online payments would also help with credit-card theft.

> (you can generally trust PayPal)

I agree, but I also have a counterexample:

"Oh, you bought SOFTWARE?? All those pretty marketing pages about our amazing safety and protection system do not apply to virtual products. We agree this vendor totally screwed you over, but it's not our problem."

(this was a few years ago, may have changed)

edit: It eroded my trust in the company completely. I don't really have an opinion of their technology.

PayPal have certainly had a few screw-ups. My personal favourite: when they locked $750,000 of MineCraft sales money. http://www.escapistmagazine.com/news/view/103385-PayPal-Free...

At a glance it seems software products are now covered - https://www.paypal.com/il/webapps/mpp/ua/useragreement-full?...

Card-readers are “trust your bank with information security” black boxes.

If their online banking password policies are anything to go by — Halifax and especially Nationwide — then very definitely no thankyou.

Nationwide asks you to set three pieces of memorable information. You can then log in with any 1 of those 3, at your option. https://onlinebanking.nationwide.co.uk/AccessManagement/Logi...

This seems obviously stupid to me, but I'll accept that Nationwide knows better than me if HN says so.

> Card-readers are “trust your bank with information security” black boxes.

Well of course I trust my bank. No escaping that. The point is not to have to trust the vendor.

> online banking

I wasn't suggesting a payment system based on signing-in to online banking.

Your complaints about online banking security may be valid, but aren't the same issue.

Many online payment processors have integrations that don't require card information to reach the merchant's server. For example, if you use Stripe[0], the merchant only receives a token that can be used for API calls. If you use Apple Pay or Google Pay, regardless of payment processor, the merchant receives a transaction-specific credit card.

[0] https://stripe.com/us/payments

There is payment systems being standardised in browsers at the moment.

https://www.w3.org/TR/payment-request/

Google Pay follows this standard. Apple Pay has a similar, but Safari-specific, API.

Isn't 3DSecure like this? If properly implemented (a giant if, there), the query to the payment provider would happen using client-side Javascript, so your credit card data doesn't touch the shop's server. Then a 3DSecure window from your bank pops up so you can confirm the payment.

The alternative, telling the user to manually go to their bank and generate a token for amount X, would lead to so many people not bothering, and to so many lost sales. Or copy-paste errors, because users are dumb.

The problem with 3dsecure is that it's still driven by the merchant. If you see it, you can be pretty sure they're doing something right, but if you don't see it then you've just given them your payment details and have no recourse.

Many just don't turn it on because it's another step and they don't have issues with fraud, as well.

I could be wrong but I think this is how Apple Pay is supposed to work. (Though a non-proprietary version of this would be fantastic, but this is a baby step I suppose.)

That is mostly how Apple Pay works. The one-time hash happens to be a transaction-specific credit card.

You can do all of that with Adyen, however if you run a shop which people only buy from once in a while, e.g. garden sheds, then you would not have value in the token, therefore this is not a common feature.

Adyen works with your shop no matter how PCI compliant and well-built, so you can have it in the checkout or the separate payment page. Interestingly you can also pay by paypal via Adyen.

I have found the online login bit for merchants to be as flaky and naff on Adyen as other payment gateways of yesteryear - forever timing you out and not letting you in, just really bad UX as banks seem to prefer.

I don't see these blockchain based payment systems as fundamentally solving anything in online payments needed for ecommerce, the Adyen tool kit is pretty large and bits such as the 'token' are not needed in real life, or some of the stranger mobile payment solutions that also promise to change the world as much as the crypto-coin 'promises'.

not sure if this is an obtuse cryptocurrency joke, or you didn't realize you were describing cryptocurrency...

> If a company is not a huge name

Not to be snarky, but a huge name is no guarantee of safety. See: Target, Equifax.

Even eBay itself (PayPal's parent) had a major password hack in 2014.

However, the advantage of PayPal is that I can buy from multiple websites while only needing to trust one entity with my credit card information.

If trusting one entity can already be insecure, having to trust dozens of them is nuts.

Parent didn’t say that. You assumed the converse.

And why would that matter to me? I've shopped online at small (and large) vendors for 20 years and I've never experienced fraud. Even if I did, the CC company covers it, don't they?

But these problems don't exist if you use a service like Stripe. You never ever store any confidential customer information on your own servers.

Stripe was just getting big as I left for a job in edtech so I never had a chance to work with it. Excuse my ignorance but does it require you to send your card info to the vendors server rather than directly to stripe? If that’s the case you are still wide open to basically every form of bad handling.

Just because a vendor doesn’t NEED to store your CC doesn’t mean they’re not out of sheer ignorance or incompetence.

Nope, it's designed so that the card details never touch the vendors server. They don't see it to be able to store it.

Reply on news.ycombinator.com