Figure 1 - Brief Overview:
The diagram illustrates the communication flow in both contact and contactless EMV transactions when a card is inserted into, or tapped on, a payment terminal.
During a transaction, messages are exchanged sequentially between each participant in the payment flow, and each step requires mutual agreement before moving to the next stage.
Most EMV chip cards in the market today use Cryptogram Version 18 (CVN18), with CVN10 as its predecessor.
Each message follows a defined specification that determines how the data elements are structured.
A message typically consists of multiple fields, and the primary differences between contact and contactless transactions can be seen in the POS Entry Mode (ISO Field 22) and in the presence of the Form Factor Indicator (Tag 9F6E) within ICC Data Field 55.
The Cryptogram Version (CVN) indicates the algorithm used by the card to generate the cryptogram.
CVN information is carried in Tag 9F10 – Issuer Application Data, one of the standard tags included within Field 55 (ICC Chip Data).
Figure 2 - Brief Overview: This flow highlights the fundamentals of payment tokenization and token-based transactions.
Digital wallets such as Apple Pay (SE), Samsung Pay (HCE), Google Pay (HCE), and issuer-specific HCE wallets enable transactions to originate from a mobile device using NFC technology.
Many of these wallets also extend to wearable devices such as the Apple Watch, Garmin, or Swatch, allowing payments to be performed through a variety of form factors.
Similar to a chip-based transaction—where data is read from the card’s chip profile, for token-based transactions; data is read from the token profile stored within the wallet.
A device-bound token cryptogram is then generated using cryptographic keys stored either in the Secure Element (SE) for SE-based wallets or in the cloud for HCE-based wallets.
The cryptogram version used in SE-based wallets differs from that used by HCE wallets, and only the network scheme can validate a token-based cryptogram.
The token-based cryptogram ensures the integrity of the transaction-specific data.
SE: Secure Element
HCE: Host Card Emulation
NFC: Near Field Communication
Figure 3 - Brief Overview:
This flow outlines the sequence of interactions when a cardholder makes a purchase within a merchant’s mobile application using for example the button1 :
"Buy with [xPay wallet name]". 
This is referred to as an in-app purchase because the merchant app has integrated the wallet provider’s in-app payment APIs,
enabling the use of active payment tokens stored either in the device’s digital wallet or as a cloud-based token.
At the start of the transaction, the merchant must request a token-based cryptogram from the network scheme by submitting the required data elements in an API request.
The network scheme uses this information to generate a cryptogram and return the corresponding Electronic Commerce Indicator (ECI) value (typically ECI 05, 06, or 07).
The cryptogram generated for an in-app transactions is known as the Token Authentication Verification Value (TAVV). It is unique for each transaction.
The algorithm for generating the TAVV is proprietary to the network scheme, and only the network scheme can validate it.
If the transaction contains a valid TAVV, the network will forward it to the issuer for authorization.
If the TAVV has been compromised, it will fail validation, the transaction will be declined in STIP, and depending on the BIN configuration, the issuer may receive a STIP authorization advice (0120 message).
ECI 05 (Visa) or 02 (MC): Authenticated
ECI 06 (Visa) or 01 (MC): Attempted authentication
ECI 07 (Visa) or 00(MC): Not Authenticated
STIP: Stand-In Processing
BIN: Bank Institution Number
0120: A type of message called as Advice that is sent by network scheme to issuers based on the BIN configuration.
1 source: apple pay marketing guidelines