3 ms·

As has already been pointed out, EMV transaction flows go through many steps. From what I understand, the protocol was designed with a focus on flexibility, and

by phlo 9y ago

As has already been pointed out, EMV transaction flows go through many steps. From what I understand, the protocol was designed with a focus on flexibility, and little attention was paid to low latency. Until some years ago, most terminals would mirror that. Most prominently, they used to have separate "enter pin" and "verify transaction amount" steps, and included longer delays for displayed status codes. Recent devices have started combining these steps ("Amount: xy. Enter PIN to confirm") and status messages. Newer use-cases like the contactless qVDSC application have been tuned for better performance, limiting the amount of communication between reader and card. For more details, have a look at this guide from VISA: https://www.visa.com/chip/merchants/grow-your-business/payment-technologies/credit-card-chip/docs/visa-emv-merchant-tadg.pdf https://www.visa.com/chip/merchants/grow-your-business/payme...

Symbiote 9y ago
That would make sense if the USA was an early adopter, but it's the latest adopter. They should have jumped straight to the latest systems. Also, I don't remember EMV being slow in the UK, and that was an early adopter of the modern protocol (2004).
- cbhl 9y ago
  The USA was an early adopter of Point of Sale systems. I'm under the impression that retailers haven't upgraded the computer systems attached to credit card chip readers.
  - zeta0134 9y ago
    Aye, in South Texas at least, I've noticed that newer terminal systems seem to process things just as fast as card swipes, if not more so. But older systems that have obviously been retrofitted with the technology are hit and miss. I often feel like it's the user interface slowing things down more than the transaction itself though, I can't recall any recent instances of delays waiting on the authorization to happen that were longer than a few seconds.
  - VLM 9y ago
    "upgraded the computer systems attached to credit card chip readers" A quarter century ago the way grocery retailers implemented credit and debit card payment was a physically separate unconnected terminal, you swiped and entered the amount on the separate terminal, and the only modification to the cash registers or workflow was hitting the "credit" button instead of "cash" when recording a transaction (there was already functionality for a "check" button). So there was no connection. Before credit/debit terminals you'd balance your register at the end of a shift using data from the "check" or "cash" button, afterwards you had a third column the "credit" button transactions, and that figure should match the terminal printout. Its possible that connecting the systems results in slower speeds for an end user, although not having the cashier hand enter charge amounts saves enough cashier time that the overall system is faster although the end user feels its slower. What I don't understand is beyond some manner of witchcraft why connecting the register to the terminal would be assumed to slow down the process. Unless architecture has staggeringly changed in the last quarter century, the CPU in the cash register is not doing the crypto or running some kind of dialup winmodem, its in sleep mode awaiting an "Ack" or "Nack" while the terminal is doing whatever crypto magic that terminals do.

by phlo 9y ago

Symbiote 9y ago

That would make sense if the USA was an early adopter, but it's the latest adopter. They should have jumped straight to the latest systems. Also, I don't remember EMV being slow in the UK, and that was an early adopter of the modern protocol (2004).

cbhl 9y ago
The USA was an early adopter of Point of Sale systems. I'm under the impression that retailers haven't upgraded the computer systems attached to credit card chip readers.
- zeta0134 9y ago
  Aye, in South Texas at least, I've noticed that newer terminal systems seem to process things just as fast as card swipes, if not more so. But older systems that have obviously been retrofitted with the technology are hit and miss. I often feel like it's the user interface slowing things down more than the transaction itself though, I can't recall any recent instances of delays waiting on the authorization to happen that were longer than a few seconds.
- VLM 9y ago
  "upgraded the computer systems attached to credit card chip readers" A quarter century ago the way grocery retailers implemented credit and debit card payment was a physically separate unconnected terminal, you swiped and entered the amount on the separate terminal, and the only modification to the cash registers or workflow was hitting the "credit" button instead of "cash" when recording a transaction (there was already functionality for a "check" button). So there was no connection. Before credit/debit terminals you'd balance your register at the end of a shift using data from the "check" or "cash" button, afterwards you had a third column the "credit" button transactions, and that figure should match the terminal printout. Its possible that connecting the systems results in slower speeds for an end user, although not having the cashier hand enter charge amounts saves enough cashier time that the overall system is faster although the end user feels its slower. What I don't understand is beyond some manner of witchcraft why connecting the register to the terminal would be assumed to slow down the process. Unless architecture has staggeringly changed in the last quarter century, the CPU in the cash register is not doing the crypto or running some kind of dialup winmodem, its in sleep mode awaiting an "Ack" or "Nack" while the terminal is doing whatever crypto magic that terminals do.