Hacker News Reader

I certainly hate it when merchants bounce me to a different site. It's most likely I will never complete the transaction and just buy from Amazon instead.

If your site sacrifices user experience, I will hate your site. Simple as that. Amazon understands the convenience factor really well.

I hope Apple Pay (on the web) takes off. While I don't like yet another middle man, and I don't care about its security benefits in the slightest, I appreciate the consistent and convenient interface it provides, so I will use it, if offered the choice.

>>If your site sacrifices user experience, I will hate your site. Simple as that.

Even if said sacrifice keeps your credit card safe?

I mean, if you are staying on the same site, you have no guarantees that the site isn't storing your credit card info in an unsecure manner.

I don't care about keeping my credit card safer that it already is. I am not liable for credit card fraud. In this insecure world we live in, I have not lost a single dime, nor any time, nor was I inconvenienced in any way by card theft. It's not my problem to worry about.

My debit card was skimmed once, a few weeks ago. The bank detected fraud, notified me that they sent me a new card, and I didn't lost any money. I only lost two minutes of my life while I was talking to the bank on the phone.

I'm assuming you ended up with no debit card for a few days at least. That's a huge inconvenience in my opinion.

No, because I have many debit cards from different banks in order to have redundancy and increase availability when the bank's system is down, or a particular card simply won't work at some merchant, but other will (usually happens in the US with my European cards).

So the sites should drop the safety features because there exists a user who would not be personally inconvenienced by the theft of their credit card details?

And that adds the overhead of managing multiple balances, fees, and credentials. You don't seem to be a typical bank user, so I'm still going to conclude that getting a credit/debit card stolen is a huge inconvenience.

The biggest risk of credit card data being stolen is not loss of money, but identity theft.

> it really hurts conversions

This. We saw about 50% would prefer on-site transactions, 50% would prefer off-site transactions (PayPal or Amazon payments). Remove one of the options and half your customers just disappear.

Was about preference, or maybe most people just shrug and choose one at random?

Most people don't want to bounce customers to a third party site for payment, it really hurts conversions.

That is certainly true in my experience.

Also, some of the payment services have a habit of changing the appearance and/or behaviour of their hosted systems, sometimes not for the better, and typically without warning. That is a risk you might not be willing to take for something as important as your payment flow. I know of at least one local business that switched from Stripe Checkout to using Stripe.js from their own site as a direct result of Checkout being significantly changed and resulting in customer support enquiries about the new behaviour that the business had no idea how to answer.

I've worked with similar organizations that want the transaction on their site due to all the reasons mentioned in the comments.

There are providers that use JavaScript to allow you to take payment information on your platform but never let the sensitive details hit your server. I believe this removes your platform as an attack vector for leaking credentials. The only locations that have traces of that information are the browser and the payment provider.

Unfortunately, even if your payment service is hosting the system that processes the sensitive details, there's always an element of vulnerability on the merchant's side if they are hosting the rest of the site, simply because a compromise could redirect customers to a hostile alternative site to collect those sensitive details. At that point, they're really no better off than a completely fake site that never had any real relationship with a payment service at all. Merchants should always be serving their own pages securely for this among other reasons, even if they are never intending to receive sensitive payment credentials.

You are absolutely right.

Which presumably is why the attackers here are injecting their own client-side JavaScript that sends a copy of the payment information to the attacker. Even if the business never sees a copy of the sensitive information, their server can still be made to serve up malicious code that does.

Yep. I completely agree. I hadn't had my early am coffee yet ;)

I don't understand this at all. I really, really don't want to give my credit card details to some random webshop who are exceedingly unlikely to have solid security. If I can use PayPal or another well known payment provider, great, I don't even have to type in my details. But even a less well known PSP is more likely to get it right than a small business webshop.

A slightly jarring user interface seems a small price to pay for a much lower chance of my payment details being compromised. Is this a minority view?

I am not liable for credit card fraud. The last thing in the world I want is inconvenience for me, when it's other people's money at risk (bank, merchant, CC company, whoever), not mine.

On the other hand, Paypal itself is a liability. Blocking your account (and your money!) for months without recourse, randomly reducing expense limits to nothing (50 EUR) are not just some Internet stories, but things that have happened to me personally multiple times.

When my card was stolen (debit card even!), I didn't lose a dime, nor time. Bank just sent me a new card the same day. I didn't even have to report the fraud, they detected it themselves, as they are really good at that. They just called me to tell me about it, and that they sent me a new card.

You aren't liable for credit card fraud, but that money comes from somewhere. Today it is a small percentage charged to the vendor; do they pass it on?

And tomorrow, when the problem gets worse and the fees start to climb, will you still not care?

Why be content with a system that may indirectly charge you for other people's lack of security?

Why not look for ways to focus the cost on the vendors who lack security?

Yes, you're right, they pass it on. But as costs start to get noticible to the involved parties (direct and indirect), hopefully that would prod the ones that don't care now, to start.

As a merchant, I am the one responsible. When a stolen credit card gets used on my site, I am the one that has to pay for that (assuming Stripe does not block it through fraud prevention). Which is fine, because my fraud rate is very low. But it's an odd situation because in effect I am being penalized for someone else's lax security. Sure I could try to come up with my own fraud prevention algorithm but I highly doubt that as a small vendor I could beat Stripe in that department. So it doesn't matter how well I'm protecting my customer's card data, the fact is if someone's info is stolen from some other site or an atm skimmer or somewhere else, and then the perpetrator buys product from my site, I have to pay for that carelessness.

Personally I think the banks should be paying for the bulk of this fraud out of the 2-3% transaction fees, not merchants who may not have anything to do with the problem. This way, there's strong incentive to actually issue secure cards and improve security. Right now, it's no skin off their backs, so nothing is improving.

>Sure I could try to come up with my own fraud prevention algorithm but I highly doubt that as a small vendor I could beat Stripe in that department.

You're seriously overestimating the fraud protection Stripe does.

Some years ago I had a Bank of America credit card. My new card never arrived in the mail, and I discovered 3,000 in charges. When I reported it, Bank of America insisted that they had mailed me the card and that I was responsible for its use. I appealed, and they still insisted that I pay the bill. I don't know their logic - was it just some employees trying to increase profit - like Wells Fargo today? And what choice did I have? Hire a lawyer for $400/hour? Lose hours of work time fighting them? Allow my credit to be wrecked? So I paid them and got a different credit card. (They even fined me and charged me interest for the months I was contesting the charges.)

In the end, they hold an unfair power over those who they can extort. I wish we had much better consumer laws - to actually protect us.

> I wish we had much better consumer laws

We have excellent consumers laws in this particular regard. If only consumers fought for their rights instead of paying the mafia!

> Hire a lawyer for $400/hour?

You don't need a lawyer for small claims court.

Now (post 2009) you can make a complaint to CFCB who I hear is really helpful and pro consumer but I don't have first-hand experience with them.

They are who fined Wells Fargo.

> Is this a minority view?

I don't know, maybe. I have zero liability on credit card purchases, and while it's certainly an inconvenience I never don't buy something because my details might be leaked. Who cares, why put yourself through the constant mental effort for an event that happens maybe once or twice a decade if you are exceedingly careless?

I absolutely despise being sent to a third party site - usually a broken one that takes forever to load, with some annoying "security" authentication, or OTP, etc. when really all I wanted was amazon one click and to move on with my life.

By far the #1 way a small merchant can get me to click the buy button is make it easy for me to checkout and pay. If I have to sign up for an account, be redirected around the world, etc. I generally tend to lose interest and just go back to newegg/amazon. Note that this sometimes is a third party payment link such as Paypal due to the nature of the service - but you have to think about user experience first, not last.

Also your requirement makes absolutely no sense to me. If a merchant is compromised to the point that javascript can be injected, it's not much more difficult at all to direct you to a fake paypal skimmer that you likely won't notice. I agree it raises the bar a bit, but not by an appreciable degree.

"I have zero liability on credit card purchases"

Not quite right. Many banks make you liable for the first $50, for each occurrence of fraud. Also they typically require you to notice and report a fraudulent charge within 30-90 days or else you are liable for 100% of the amount.

The person said they have no liability, how is saying that many banks don't refuting what they said?

More specifically: U.S. law puts a $50 cap on consumer liability, but many credit cards voluntarily lower it to $0. The $50 is a ceiling, not a floor.

In theory, maybe. But phil21 is correct that credit card users have zero liability in practice.

Most card issuers these days will proactively contact the customer to inquire about suspicious charges.

Nope, if your credit card number is stolen and used online for a card-not-present transaction you have $0 liability by law.

>Is this a minority view?

Most likely. The fact that you understand what is happening when your store webage you're on goes white the words in the www bar change and then you're on a different site and it's asking for credit card info kind of illustrates this point.

Could you imagine trying to buy eggs at the supermarket then when it comes time to swipe your credit card, being asked to leave all your eggs at the register, go over to a different store with your credit card, swipe your card there, sign the paper, then go back to the original store and pick up your eggs? I imagine that's how a lot of people visualize going to a PSP site to enter credit card info.

Doesn't Apple Pay make this a non issue?

Especially now that it can be deployed on websites?

Like so many other areas, it's really a shame that the industry can't co-operate here. Apple Pay works fine at the one location near me that supports it, but it's a headache for the merchant (I might be the only person who uses that payment system) and the consumer (lack of support elsewhere).

The equation for websites is similar given Mac users are a minority, and many Mac users use Chrome.

Apple Pay online is great for convenience and security, from a practical point of view, but on a more abstract point of view I think something is deeply flawed about the payment industry if the solution is to add yet another middle man.

I want a world where payment is convenient, security is excellent, and there's no mandatory mafia of middle man between my electronic money and the merchant. It's fine that people chose to use banks voluntary, banks provide many services people want. But it should not be mandatory to use banks, if you chose to do so, and most certainly it should not be necessary to implicate yet another 3rd party to the transaction (VISA/Mastercard). And now we are adding a 4th party!

Whether to use a 3rd, 4th, 5th party should be users' choice. Some people value security, others privacy, others convenience; some people want 2FA for every transaction, some people hate PINs and want just to swipe a card, etc. All this should be client side; user's side. Open payment protocol with multiple implementations. Merchant just uses the protocol. If some new payment revolution is coming, merchant should just update his software.

We have technical solutions to do all this, but most people do not understand that this is possible, what the existing system entails; and the people in charge of this don't want to lose the power.

>it really hurts conversions

That has to be a local issue, because that is flat out wrong. The majority of all e-commerce sites does exactly that. I have yet to meet a PSP that believe send the entire credit card number, expiry and CVV was the right solution. I've talked to exactly one PSP that supported accepting credit cards in an iframe, and that was only available to existing customers, because they where discontinuing that service.

In most of northern Europe at least, customer have been use to credit card payments redirecting them to third party sites since at least 1999. It has zero effect on conversion.

> That has to be a local issue, because that is flat out wrong.

You can't declare it a possible local issue and then say it's wrong.

And it's definitely been measured (in my own testing at various companies and by many many others) that it hurts conversions to break the flow into separate redirect.