Augusta QC KB - Implementation & Integration FAQ

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

In the case that an EMV (ICC) card is swiped, we recommend the following way to address the scenario:

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). If it's true, indicating that the card has EMV, 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 they should use the chip insert slot instead.

Implementation wise, the Virtual Terminal Application would first need be able to differentiate between MSR or EMV tag data (they are formatted very differently). Then should the incoming data be MSR data, the Terminal application would then look for the status flag to see whether ICC is supported on the card or not, and then make the decision.

How is the user going to be able to make a choice / select the appropriate application to handle the card?

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 CVM’s they want to use. The card brands determine which CVMs to attempt, the order to attempt them, and if additional (remaining CVM’s) should be attempted if the current CVM is not supported or fails. This process only sets bits in the TVR to indicate pass/failure.

How will a terminal deal with combo cards (containing credit AID + debit pair)? How does the data coming from the reader trigger this type of user interaction (to select credit/debit)

The terminal setting 5C that we use for the KB QC will defer to the card's highest priority. As the Augusta 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 - while the Augusta in in Keyboard Quickchip 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.

What are the list of supported AIDs for the device? What is actually going on in the background, then?

There is no concept of “supported AIDs” as far as the device kernel is concerned. An AID file is just a configuration file, or a data file, with a file name representing an AID name (either partial or full match), and data that will override terminal data or add to terminal data for that transaction. Our kernel as of 20 Mar 2017 supports up to 16 of these files (future rev’s will support more slots).

The kernel doesn’t review or make decision on any AID file nor have any mechanism to know if an AID file is meant for debit, credit or some other function.

Once the device loads the highest priority AID, it will then have the CVM list for that application. After CVM is complete, the TVR (Terminal Verification Results) will have the outcome, if CMV passed/failed and which CVM this happened on. These results are compared to the Terminal Actions Codes to determine if it should decline/approve offline (assuming an offline capable terminal) or go online for host approval.

What if the card requires cardholder confirmation?

Any card that requires cardholder confirmation will be terminated by the device kernel while the Augusta is in QC KB mode.

This means that QuickChip KB cannot support cards under Durbin requirements, and the user will need to use another card that does not require cardholder confirmation.

However, Quickchip (by itself, without ID TECh's implementation of QC KB) can allow for card holder confirmation. In that case, it’s not as quick as you need to wait for the confirmation but it is not prevented. It is similar to CVMs. You can have quick chip and support offline pin.

Our implementation of Quick chip with Augusta in KB mode cannot support any card holder confirmation, as there is no way for a response to go back to the reader. The kernel configuration that we use is 5C to match the capabilities of the reader.

To support Quick Chip WITH card holder confirmation, our customers can use Augusta in HID mode, with configuration 2C. This allows card holder confirmation (Language, what application to pick [Credit or Debit, Common AID or Card brand AID for Debit], …) when there is a need for it.

At a high level - if you require cardholder confirmation, you will need to instead do your own implementation of quickchip from the application layer, which all of ID Tech's devices that are on the common kernel do support, in configuration 2C.

Contributors:

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