In Part I of this post, we talked a bit about EMV transactions and how they’re structured. We saw that:

• Unlike MSR (magstripe) transactions, an EMV transaction occurs in multiple stages.
• Most of the back-and-forth talk between the chip card and the reader happens at the kernel level, outside the control of application logic.
• Transaction results are returned in TLVs (“tags”).
• A cryptogram (a unique 8-byte piece of data produced by the card, using a private key known only to the card) is produced before the Completion stage of the transaction; and a second cryptogram is produced after the call to complete the transaction.
• The cryptogram comes back from the card in tag 9F26 (an EMVCo-defined tag, not a proprietary ID TECH tag).

Generally, you’ll package up the first cryptogram (and any other TLV data your back-end processor requires) to send to the processor, over the wire, in real time, to obtain an authorization code (in tag 89), before issuing the call to begin the Completion phase. It’s your responsibility to carry out the online authorization request (because neither the reader nor our SDK will do this part for you), using your gateway’s web APIs. Most gateways have their own SDKs to make this part easier.

The gateway (or “back end processor”) will respond to your authorization request with tags 89, 8A, 91, and (optionally) 71 or 72. To complete the transaction, you’ll pass these TLVs to the Universal SDK’s emv_completeTransaction() method. Your code will be notified of the results via a callback. In the callback, you’ll get a handle to the transaction data, which will include a group of TLVs. Among the TLVs will be the second and final cryptogram (mentioned above), which — once again — will be in tag 9F26.

Types of Cryptograms

The cryptogram returned in tag 9F26 is opaque. You can’t tell, by inspecting it directly, what kind of cryptogram it is. However, you can inspect tag 9F27 (which is also returned, along with 9F26) to tell what kind of cryptogram you’ve been given. The top nibble of 9F27 will contain the information you need. The bits can be deciphered as follows (this information comes from EMV Book 3):

b8	b7	b6	b5	b4	b3	b2	b1	Meaning
0	0							AAC
0	1							TC
1	0							ARQC
1	1							AAR
		x	x					Payment System-specific cryptogram
				0				No advice required
				1				Advice required
					x	x	x	Reason/advice/referral code
					0	0	0	No information given
					0	0	1	Service not allowed
					0	1	0	PIN Try Limit exceeded
					0	1	1	Issuer authentication failed
					1	x	x	Other values RFU

Generally speaking, 9F27 will have a (hex) value of 80, 40, or 00, which translates (respectively) to ARQC, TC, or AAC. These, in turn, mean “go online,” “approved,” or “declined.”

It’s important to understand that these values only represent the card’s advice. It’s not always the case that this advice is binding. For example, the card is required to return AAC in the second cryptogram (at Completion) if the original cryptogram was ARQC, yet the payment app was unable to go online. The AAC , in this case, doesn’t automatically mean your transaction is declined; that decision rests with the online authority (the issuer, ultimately). In the special EMV scenario known as Quick Chip (or Faster EMV), you will always get an AAC, because the online request happens later. That’s okay! You can still submit the transaction for settlement. The card’s advice is simply advice. The online authority makes the final decision.

Note that in the U.S. (which is considered an online-only market), you will nearly always get an ARQC in the first cryptogram. An exception to this would be if the card is expired or there is some other reason why the transaction needs to be declined outright, in which case you could (theoretically) see an AAC after the first “Gen AC” request.

Obtaining TLV Data

In the Universal SDK, which takes care of communicating with your ID TECH reader, for you, via USB, RS-232, Bluetooth, audio jack, or Ethernet (as appropriate to the type of reader), all transaction-related communications to and from the reader are asynchronous, which means you need to register one or more custom callback routines with the SDK in order to “hear back” from the reader. Instructions for doing this are provided not only in the SDK documentation but in the sample code that comes with the SDK. There’s nothing mysterious about using callbacks. We suggest you spend some time studying the SDK’s sample code to see what the flow looks like.

The important thing to remember is that an EMV transaction occurs in phases, and you get different TLVs back at the end of each phase. A common misconception is that you’ll simply get all the tags you might ever want at once, at the end of the Completion phase. That’s not true. You will find that you need to collect TLVs at each phase.

Which tags can you expect to get at each phase? Here are the most typical tags, by phase of transaction:

Start Transaction:
4F
50
57
5A
5F20
5F24
5F25
5F2D
5F34
84
9F20
DFEE12
DFEE23

Authenticate Transaction:
95
9B
9F02
9F03
9F10
9F13
9F26
9F27
9F34
9F36
9F37
9F4D
9F4F

Complete Transaction:
95
99
9B
9F02
9F03
9F10
9F13
9F26
9F27
9F34
9F36
9F37
9F4D
9F4F
9F5B

Almost all of these are standard industry-defined EMVCo tags. The ones that begin with ‘DF’ are ID TECH proprietary tags. For a complete listing of ID TECH proprietary tags and their meanings, you should refer to document 80000503-001, ID TECH TLV Tag Reference Guide, available for download at our Knowledge Base.

Not seeing the tag you need? No problem. You can use the Universal SDK to request additional tags at transaction time. Details for doing this are described not only in the SDK documentation but also in our white paper on EMV Transactions with the Universal SDK.

Which Tags Are Encrypted?

If your reader has been key-injected, with encryption turned on, tags containing sensitive data will have their contents encrypted. This obviously includes any tags containing track data (e.g. tag 57) or PAN data (5A). For the full list of encrypted tags, see  document 80000502-001-F, ID TECH Encrypted Data Output. If you’re using a demo unit (injected with a demo key), you can decrypt the data manually using our online tool. Generally speaking, though, you should never need to decrypt data yourself, in production code, since you’ll be passing the data straight through to your processor.

Encryption is a big topic. We won’t discuss it more right now, but if you’re curious about it, be sure and see our earlier posts on this.

Have Questions?

By now, you’ve probably got lots of questions. Don’t sweat it! We have a ton of free resources available for you at our Knowledge Base, and if you still have questions, our technicians are only a phone call away.

Toll Free Number
1-800-984-1010