During a contact EMV transaction, when are the ARQC, AAC, AC, and their corresponding CDOL1 generated?
Answer:
Begin a transaction with "startTransaction" command. "authenticateTransaction" is the next step, which may or may not be called automatically. authenticateTransaction is a step that allows you, to "pause" the transaction, if desired, to understand what card is being processed in case you want to make any changes, like changing the amount if a store card is being used. At the end of the authenticateTransaction step (or the end of the start transaction step (if using auto-authentication), the card must make a decision. It uses the CDOL1 to give the ICC the tags it needs to generate an Application Cryptogram (AC). There are three types of AC:
ARQC: this is the card telling you it needs to know the host's decision before it can give you its final decision (GO_ONLINE); the transaction is still in progress waiting for that data.
AAC: this is the card telling you it made its final decision, which is declined, and that you don't need to contact the host (DECLINE_OFFLINE); the transaction is now over
TC: this is the card telling you it made its final decision, which is approved, and that you don't need to contact the host (APPROVE_OFFLINE); the transaction is now over.
If you got ARQC, you send that AC and other relevant tags to a host for a decision. You may get up to three pieces of information from the host. The decision (Tag 8A), the Issuer Authentication Data (Tag 91) and issuer scripts (Tags 71 and 72). Feed this information back to the card with a "completeTransaction" call.
The ICC then uses tags in CDOL to generate the second application AC. This is the card making the final decision, it can be either AAC (declined) or TC (approved). The transaction is now over.
Remember that in a standard EMV transaction, it is the card that makes the final decision, not the host. There may be cases where the host approves the transaction, but the card still declines it.