> 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 JavaScr

> 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. 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.