Versions Compared

Version Old Version 3 New Version Current
Changes made by

Kas Thomas (Deactivated)

IT-ADMIN G (Deactivated)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Premise:

This is a FAQ for what QuickChip Keyboard is, how the implementation typically goes, and several certification related scenarios.

This is intended for more technical related folks.

For more information, please consult our support team at support@idtechproducts.com 



What is QC KB? 

QC KB = Quickchip keyboard emulation. This allows a traditional POS that uses keyboard input to be compatibale with some of IDTECH's newer device offerings that can output both magstripe and EMV compliant data as keyboard strokes. 

This is typically used in conjunction with a VPOS - virtual POS. These types of POS usually exist in the form of a web page served from a web browser.


Why QC KB?

This reduces the amount of complexity required for integration, and also reduces the time needed for cert. The solution complexity and time complexity drop, and the user experience / setup is easier. 


What products support QC KB today?

As of  , the Augusta and VP 3300 devices support QC KB - quickchip keyboard emulation.


How do we deal with the scenario that an ICC card is swiped?

...

When the MSR data is received (but not yet displayed), the Virtual Terminal would have to look through the returned data for an ICC flag (which will be either 0 or 1). This is reflected in Bit 5 of Field 8 of the Enhanced Encrypted MSR data. (Check this document for details about that data format, and its various fields.) If the bit is set, indicating that the card has a chip, the Virtual Terminal application would have to stop at that point (before any more of the data is processed and/or sent), and then display a message to the user indicating that he/she should use the ICC slot instead. 

...

The user won't be able to make a choice, as this decision is handled by the device kernel. At a high level, the card and the terminal would each go down their priority lists, and the transaction would terminate early should there not be the appropriate application supported, for example.There is not an option for a customer to choose which of the supported CVMs they want to use.  The card brands determine which CVMs to attempt, the order to attempt them, and whether additional (remaining CVMs) should be attempted if the current CVM is not supported or fails. This process only sets bits in the TVR to indicate pass/failure. 

Notet that, in general, the ID TECH implementation of Quick Chip and M/Chip Fast for Augusta in keyboard mode is predicated on the card reader using what we call Terminal Configuration 5C. (See this article for info about terminal configs.) This configuration is for no-special-user-interaction scenarios. When user interaction is required (such as for configuration 2C, also supported in Augusta, but not in keyboard mode), you need to set the configuration manually (in the U-Demo app) or programmatically using the SDK, then implement the Quick Chip choreography yourself, in USB HID mode. 

...

The terminal setting 5C that we use for the KB QC will defer to the card's highest priority. As the Augusta and VP 3300 doesn't support PIN entry, if the card's highest priority is Debit, the kernel will instead select the next possible priority, which would be Credit, and proceed onward with that. So to fully answer that question: When the Augusta is in Keyboard Quick Chip mode, there won't need to be a trigger for user interaction as the choice is made by the Augusta's kernel before the data is output to, for example, a Virtual Terminal Application. Bottom line, there is no easy, built-in way to support PIN debit with Augusta. We have other products that can handle PIN debit more conveniently.

...

At a high level - if you require cardholder confirmation, you will need to instead do your own implementation of Quick Chip from the application layer, which all of ID Tech's devices with our L2 Common Kernel do support, in configuration 2C.


 

 

Contributors:

Randy Palermo, Eric Lecesne (Deactivated), Kas Thomas (Deactivated), Jason C (Deactivated)