Earlier quoted context omitted.
> 2. (As mentioned in the article) issuers accept transactions from EMV (chip)-capable readers that nominally originate from EMV-capable cards without requiring the chip to be used. So what’s the point of the chip? (Note that this allows a card to be cloned without even touching the card - see #1.) I would think the issuer could refuse the transaction higher up in the process, but it's faster and fewer packets going…
That’s like saying you think a server can reject a wrong password on the backend, but it’s faster and fewer packets going back and forth if the client JavaScript just verified the password before sending POST. This is nuts. At least there’s nothing fundamentally wrong with a card reader also rejecting the transaction. (It’s also not fewer packets. Although it does require the backend to know whether the card reader c…
I don't think it is nuts. The terminal doing the rejection accounts for the "oops the customer did something wrong" case of swiping the card when the issuer wants them to use chip. It's better to tell the customer this now than run an entire transaction.
But checking on the far end that the transaction meets all of the issuers rule accounts for the fraud case of "someone has maliciously rewritten the magnetic stripe data to try to go around the requirement to insert the card." Since, hopefully, this happens far less often than the first case, it is an acceptable path.