Earlier quoted context omitted.
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…
A better comparison would be the client JavaScript rejecting a four-character password, because it knows the backend policy requires at least eight. Done right (without e.g. checking for "key down" events to thwart password managers...), this could could actually improve security somehwat by avoiding whatever the user entered (maybe a low-entropy PIN?) hitting the network or backend, besides providing for a faster er…
Not if done both client-side and server-side.
Right now, if I swipe my magnetic stripe, then terminal will reject it if the stripe has the magic bit set. If the magic bit is clear, the terminal will (eventually, but usually while the customer waits) send a message to the network saying that the card was present and asking for authorization. The network responds. No additional round trip would be needed for the network to deny authorization if the chip was not used.