Cryptogram and EMV Transaction Flow

Owned by IT-ADMIN G (Deactivated)
Last updated: Jan 15, 2024 by Yan Mu
3 min read

3 types of cryptograms can be generated by the card:
- An AAC is generated whenever a card declines a transaction.
- An ARQC is generated whenever a card requests online authorization.
- A TC is generated whenever a card approves a transaction.



Here’s part of what I’ve learned from EMV Book 3.

  • The data object list for Gen AC 1 is in 8C.

  • The CDOL for Gen AC 2 is in 8D.

  • The CDOL data is (are) gathered by the kernel. You do not request these tags in the SDK.

  • If Gen AC 1 gives ‘ARQC’, you’re supposed to go online. (If it gives TC or AAC, you’re done.)

  • If you go online, you will get back tag 89 (auth code, typically printed on the receipt), 8A (ARC), optionally tag 91, and optionally 71 and/or 72.

  • If you can’t go online, you need to manually set 8A to ‘Z3’ for the 2nd Gen AC and proceed to Completion.



  • Tag 91 (Issuer Authentication Data) can be 8 to 16 bytes of stuff. (It varies because it allows for discretionary data.) It will contain the decision of the issuer plus flags indicating things to do or not do before completion. (Has nothing to do with scripts.) The decision of the issuer is in the top bit of Byte 2 (bit ON==Approved Online). See Annex C8 of Book 3.



DISCUSSION

Issuer Authentication is optional, so Tag 91 is optional. (Obviously, it never happens in Quick Chip.) If tag 91 is available, you pass it to the chip in the 2nd Gen AC (along with 8A and 71/72, if available). The complete CDOL list for Gen AC 2 (which may include additional tags beyond 8A, 91, 71, or 72) is handled by the kernel, not the SDK. You do not need to request nor gather up CDOL tags. The kernel does this for you. What the kernel can’t do (because it doesn’t know what you received online) is supply 8A or 91 for you. You have to pass those in.



From the SDK doc (my comments in yellow):

RETURN_CODE IDTechSDK.IDT_Augusta.emv_completeTransaction ( bool commError,

byte[ ] authCode, /* 8A */

byte[ ] iad,   /* 91 */

byte[ ] tlvScripts, /* 71, 72 */

byte[ ] tlv )  /* RFU? Jason, what goes here? */



The second argument, “authCode,” is a bit misleading. It should probably be called ARC. It is not Tag 89 (which is the Authorization Code). It’s actually 8A.



Also note: Don’t confuse tag 91  with issuer scripts. Scripts (if present) will be in tags 71 or 72. The former is for scripts that should be executed BEFORE the 2nd Gen AC; the latter (tag 72) is for scripts that execute AFTER the 2nd Gen AC. (This is again something that never happens in Quick Chip. Issuer scripts are out of scope for QC.) The script tags get passed to the chip at completion time.



MY CONCLUSION

The chip does not need any cryptographic data from the issuer to generate the second cryptogram. (Tag 91 is optional. Issuer Verification is optional.) The point of having a chip on the card is to attest to the presence of a legitimate card. The issuer needs to validate the card. It’s immaterial whether the card can validate the issuer. So, the 2nd cryptogram is just another attestation (based on CDOL data hashed with the chip’s private key) that the card is legit.



Kas Thomas
Technical Writer
www.idtechproducts.com
10721 Walker Street
Cypress, CA 90630