[BlackFly]

The real solution to the problem is use of an integrated circuit card, usually through EMV.

If a web merchant uses 3D secure or Verified By Visa or SafeKey (from MC, Visa and AmEx respectively), the issuing bank can implement the same level of security in a web transaction that occurs in a card present chip transaction. Proof that the transaction was originated by someone who has control over the card, proof that the transaction was originated by someone who has knowledge of the PIN.

In these schemes you can store the PAN all you want. As long as the 3DES key is never read from the card, the PAN does you no good. Hopefully, when the USA catches up to the rest of the world in this regard, PCI will relax security requirements for merchants/acquirers.

[falcolas]

Verified by Visa is bad for the consumer: it shifts all the risk of fraud onto them. If the PIN is intercepted, and subsequent purchases are made with that PIN, the owner of the card is liable for all of those purchases; they are considered to have made them because their pin was present at the time of purchase.

[_delirium]

That's generally been the case in Europe, but as I understand it this "liability shift" would be more difficult to enact in the U.S., because U.S. law has blanket limits on consumer liability for credit-card fraud (maximum $50 for card-present transactions and $0 for card-not-present). There are exceptions if the bank can show that you were negligent, e.g. you knew a card was stolen but failed to report it in a timely manner, but the burden of proof remains on the bank in those cases.

[mseebach]

There is a major use case around "card not present" transactions.

Anything recurring, such as AWS, hotel/car rental express check-out/return, Amazon 1-click and Uber and similar mobile payment use cases will get significantly higher friction if you have to complete a chip-and-pin for each of these.

A quite simple fix to these would be to allow storage of a token linked to the PAN which is locked to a specific merchant - so, they're worthless if stolen, but can be used like the PAN is today to perform "card not present" transactions for that merchant.

[BlackFly]

This problem has already been solved.

Most interchange protocols contain flags for recurring payments and standing authorizations. Only the first such transaction contains chip data to prove that the cardholder actually wants to authorize a standing auth/recurring auth.

In these cases, the standing authorization is already tied to the merchant + PAN + address details. Using chip in the first place is what allows a database compromise which leaks the PAN to not enable a criminal to authorize at another merchant: they won't be able to generate the ARQC needed to authorize.

All subsequent standing auths are card not present anyways.

[nothrabannosir]

This solution is already implemented in large parts of the world and good to go! But the incentives are sometimes not right. Ultimately, I want IC payments to be cheaper, as a merchant. I want my incoming IC payments to be in a separate bookkeeping from the non-IC: increase in fees on the latter, I'd like to keep my rates for the former.

Ultimately, I can then pass these savings on to the customers.

But as long as there is no incentive to ask for IC, why would I? It's just an annoyance.

[BlackFly]

I'm a bit confused as to what you mean.

Physical merchants eliminate liability for fraud and get reduced interchange fees by accepting chip.

Web merchants get reduced fees by using 3D secure (and the other scheme's versions). It is the issuing banks decision whether the 3D secure uses a chip or not, not the decision of the merchant. Many banks use sms push, RSA tokens, OTP sent in an envelope, or just passwords.

[dlubarov]

My understanding is that

- The liability shift will pressure merchants just to use EMV-capable terminals. As long as they're using one they won't be penalized for swiping.

- However, the networks require certified EMV terminals to reject swipes from chip cards. (They can tell from the service code in the card's track data.) Unless dipping fails a certain number of times, in which case the terminal can allow swiping as a fallback.

So merchants are incentivized to get an EMV-capable terminal, issuers are incentivized to replace magstripe cards with ICCs, and terminal requirements (mostly) prevent swiping ICCs.

[gkoz]

What has 3D Secure got to do with EMV? How is it supposed to use the chip and the PIN?

[tomjen3]

>If a web merchant uses 3D secure or Verified By Visa or SafeKey (from MC, Visa and AmEx respectively)

then he better hope that all his competitors do to. It is a major hassle and risk for the consumer so I haven't set my card up to work with those. If it gets stolen it gets stolen but that can happen even if I get it verified.