EMVCo Authorization Flow with Technical Details

Step	Entity Involved	Process Description	Technical Details & Message Elements
1. Transaction Initiation	Cardholder → Merchant	The cardholder selects items and proceeds to payment.	Cardholder enters card details on the merchant’s checkout page.
2. Authentication Trigger (3DS Request)	Merchant → Directory Server (DS)	If 3D Secure (3DS) is enabled, the merchant initiates authentication.	- AReq (Authentication Request) is sent.  - Key Fields: 3DSRequestorID, AcctNumber, TransAmount, TransCurrency
3. Authentication Processing	Directory Server → ACS (Issuer’s ACS)	The ACS (Access Control Server) authenticates the cardholder (OTP, biometrics, etc.).	- ARes (Authentication Response) is sent.  - Key Fields: TransStatus, TransStatusReason, ACSURL (if challenge required)
4. Authentication Challenge (if required)	ACS → Cardholder	If risk is high, a challenge (OTP, Biometric, App Notification) is presented to the cardholder.	- CReq (Challenge Request) is sent.  - CRes (Challenge Response) is received from the cardholder.
5. Authentication Completion	ACS → Merchant	The authentication result (pass/fail) is returned to the merchant.	- TransStatus = Y (Success) or N (Failed).
6. Authorization Request (Financial Transaction Initiation)	Merchant → Acquirer	The merchant submits the transaction for authorization.	- Message: ISO 8583 Authorization Request (0100 message).  - Key Fields: PAN, ExpiryDate, Amount, Currency, MerchantID, POS Entry Mode.
7. Transaction Routing via Network	Acquirer → Card Network (Visa, Mastercard, RuPay, etc.)	The acquirer forwards the transaction to the appropriate payment network.	- Network forwards ISO 8583 0100 message to the issuer.
8. Authorization Decision by Issuer	Issuer → Card Network	The issuer evaluates the request (available balance, fraud checks, past transactions, etc.).	- Issuer’s risk engine checks:  - Available credit/debit balance  - Authentication outcome from 3DS (if available)  - Past transaction behavior  - ISO 8583 0110 (Response) is generated.
9. Authorization Response Sent Back	Card Network → Acquirer → Merchant	The issuer’s decision (approved/declined) is sent back through the network.	- Message: ISO 8583 0110 Authorization Response.  - Key Fields: ResponseCode (00 = Approved, 05 = Declined), AuthIDResponse, Issuer Script (if any).
10. Transaction Completion	Merchant → Cardholder	The merchant receives the authorization response and completes the transaction.	- If approved, order confirmation is displayed.  - If declined, the user may be asked to retry or use another payment method.

Key Message Elements Used in the Authorization Flow

Message Type	Description	Key Fields
AReq (Authentication Request)	Sent from merchant to ACS via DS	AcctNumber, TransAmount, MerchantID, 3DSRequestorID
ARes (Authentication Response)	Sent from ACS to merchant	TransStatus, ACSReferenceNumber, AuthenticationValue
CReq (Challenge Request)	Sent from ACS to cardholder’s device	ChallengeWindowSize, ACSURL
CRes (Challenge Response)	Sent back to ACS after cardholder interaction	ChallengeStatus, ChallengeDataEntry
ISO 8583 0100 (Authorization Request)	Sent from merchant to acquirer, then to issuer	PAN, Amount, CurrencyCode, ExpiryDate, POS Entry Mode
ISO 8583 0110 (Authorization Response)	Sent from issuer back to merchant via network	ResponseCode, AuthIDResponse, Issuer Script

Summary of the EMVCo Authorization Flow

• The Authentication phase ensures the cardholder’s identity is verified before authorization.

• The Authorization phase involves financial verification by the issuer.

• Networks like Visa, Mastercard, and RuPay facilitate transaction routing.

• The issuer ultimately decides whether to approve or decline the transaction.