Authorization reversal and advise
Reverse advise (420) can be use if the authorization result is unknown due to technical reasons (such as network failure). An reverse advise will not be rejected even if the orginal authorization request does not succeed.
Visa:
Full reversal:
Request:
ISO 2 Primary Account Number, ISO 3 Processing Code, ISO 18 Merchant Type, ISO 19 Acquiring Institution Country Code, ISO 22 POS Entry Mode, ISO 25 POS Condition Code, ISO 32 Acquring Instition ID, ISO 42 Card Acceptor ID, ISO 43 Card Acceptor Name, ISO 49 Currency Code must be the same as the original auth request
ISO 11 System Trace Audit Number: must be the same as the original auth request
ISO 37 Retrieval reference Number: must be the same as the original auth request
ISO 38 Auth code: Contains auth code from initial auth response
ISO 62.2 Transaction id: Contains transaction id from initial auth response
ISO 63.3 Message reason code: Populated with reversal message reason code: (2501, 2502 or 2503) 2501(Transaction voided by customer) will be initiated by customer. 2502 (Transaction not completed) or 2503 (No confirmation from point of service) can be initiated by system on time out. In this case field 38 and 62.2 may not have value since no response is received for the first auth request
ISO 90 Original data elements:
Subfield 1: original message type (0100)
Subfield 2: original trace number (ISO 11) from original auth request
Subfield 3: original transmission date time (ISO 7) from original auth request
Subfield 4: original acquirer id (ISO 32) from original auth request
Subfield 5: original forwarding institute id (ISO 33) from original auth request
Partial reversal:
Request:
ISO 11 System Trace Audit Number: must be the same as the original auth request
ISO 37 Retrieval reference Number: must be the same as the original auth request
ISO 38 Auth code: Contains auth code from initial auth response
ISO 62.2 Transaction id: Contains transaction id from initial auth response
ISO 63.3 Message reason code: Populated with reversal message reason code: (2504)
ISO 90 Original data elements:
Subfield 1: original message type (0100)
Subfield 2: original trace number (ISO 11) from original auth request
Subfield 3: original transmission date time (ISO 7) from original auth request
Subfield 4: original acquirer institution id (ISO 32) from original auth request
Subfield 5: original forwarding institution id (ISO 33) from original auth request
ISO 95 Replacement amounts: contains the corrected amount of an authorization transaction, must be less than original auth amount.
Mastercard
Full reversal:
Request:
DE 2 Primary account number, DE 3 Processing code, DE 18 Merchant Type, DE 22 POS Entry Mode, DE 32 Acquiring Institution ID Code, DE 37 Retrieval Reference Number, DE 49 Currency Code, DE 61 POS Data, value must be the same as original auth transaction
DE 38 Authorization ID response: Contains auth code from initial auth response
DE 39 Response Code:
DE 48.63 Trace id: contains data in DE 63 (Network Data), subfield 1
(Financial Network Code) and subfield 2 (Banknet Reference Number) and DE 15 (Date,
Settlement) that is in the original Authorization Request
DE 48.20 Cardholder Verification Method: value = S (Can signify signature)
DE 90 Original data elements:
Subfield 1: original message type (0100)
Subfield 2: original trace number (DE 11) from original auth request
Subfield 3: original transmission date time (DE 7) from original auth request
Subfield 4: original acquirer institution id (DE 32) from original auth request
Subfield 5: original forwarding institution id (DE 33) from original auth request
Partial reversal:
Request:
Same as full reversal, except for an additional field:
DE 95 Replacement amounts: contains the corrected amount of an authorization transaction, must be less than original auth amount.
Reference: mastercard CustomerInterfaceSpecification -- ReversalRequest section
Incremental Authorization:
Merchant does not know final authorization amount when transaction begins, it only sends estimated amount. Incremental auth allows merchant to increase total amount authorized if the amount of estimated/initial authorization is insufficient.
Incremental auth adds to total amount authorized
Incremental auth can only be used for certain MCC codes
Incremental authorizations do not extend authorization validity periods. If the authorization exceed validity periods, it must be closed, and a new re-authorization request is required.
Incremental authorizations must not be used once the original transaction has been submitted for clearing. In such a scenario, a new authorization for the delayed charge must be requested.
Visa:
Initial authorization request: as per normal
Subsequent authorization request:
ISO 63.3 Message reason code: Populated with 3900 (incremental auth)
Mastercard:
Initial authorization request: as per normal
Subsequent authorization request:
DE 48.63 Trace id: contains data in DE 63 (Network Data), subfield 1
(Financial Network Code) and subfield 2 (Banknet Reference Number) and DE 15 (Date,
Settlement) that is in the original Authorization Request
Recurring/Credential on file payment:
Strong customer authentication (SCA) is a requirement for EU region to enforce 3DS on card transaction. There are some exemption cases which are related to recurring payment:
For recurring payment: SCA (3DS) is required for the customer’s first payment—subsequent charges however may be exempted from SCA
Merchant initiated payment (Stored card): Authenticate the card either when it’s being saved or on the first payment. Finally, you need to get an agreement from the customer (also referred to as a “mandate”), in order to charge their card at a later point.
For subsequent payment that is initiated by customer, usually exemption is not allowed unless the transaction amount is really small.
Visa:
Initial authorization request:
ISO 22 POS Entry Mode: value must be 01 (key entry) (For credential on file case only)
ISO 60.8 Mail/ phone/electronic commerce and payment indicator: 02 (recurring payment) or 03 (installment) (mandatory for US region)
ISO 63.3 Message reason code: Used for merchant intiated transaction
- 3900 Incremental authorization
- 3901 Resubmission
- 3902 Delayed charges
- 3903 Reauthorization
- 3904 No show
ISO 126.13 Pos environment: C (Credential on file) R (Recurring payment) I (Installment) (mandatory for NON US region)
Subsequent authorization request:
ISO 22 POS Entry Mode: value must be 10 (credential on file)
ISO 25 POS Condition code: value must be 08 (Mail, telephone, recurring, advance, or installment order) or 59 (E-commerce request through public network) (For credential on file case only)
ISO 60.8 present (For credential on file case only and only if ISO 25=59)
ISO 62.2 Transaction id: Contains transaction id from initial auth response
Subsequent authorization response:
ISO 62.2 Transaction id: Generate a fresh transaction id
ISO 126.13 Pos environment: C (Credential on file) R (Recurring payment) I (Installment) (mandatory for NON US region)
| First transaction setting | First transaction | Subsequent transaction CIT | Subsequent transaction MIT |
|---|---|---|---|
| Environment = face to face <br/> Store credential by merchant or PF | POS Entry Mode = 01, 07, 90 or 91 <br/> POS Environment = C if UCOF <br/> R if recurring <br/> I if installment | POS Entry Mode = 10 <br/> POS Environment is not present | POS Entry Mode = 10 <br/> POS Environment = C if UCOF <br/> R if recurring <br/> I if installment |
| Environment = face to face <br/> Credential not stored | POS Entry Mode = 01, 07, 90 or 91 <br/> POS Environment is not present | No subsequent transaction with stored credential | POS Entry Mode = 01<br/> POS Environment is not present |
| Environment = card absent <br/> Store credential by merchant or PF | POS Entry Mode = 01<br/> POS Environment = C if UCOF <br/> R if recurring <br/> I if installment | POS Entry Mode = 10 <br/> POS Environment is not present | POS Entry Mode = 10 <br/> POS Environment = C if UCOF <br/> R if recurring <br/> I if installment |
| Environment = card absent <br/> Credential not stored | POS Entry Mode = 01 <br/> POS Environment is not present | POS Entry Mode = 01 <br/> POS Environment is not present | POS Entry Mode = 01 <br/> POS Environment is not present |
| Environment = card absent <br/> Store credential by SDWO (Staged Digital Wallet Operators) | POS Entry Mode = 01<br/> POS Environment = C if UCOF <br/> R if recurring <br/> I if installment | POS Entry Mode = 10 <br/> POS Environment is not present | POS Entry Mode = 10 <br/> POS Environment = C if UCOF <br/> R if recurring <br/> I if installment |
Note: A special case will be visa returning response code: R3. It indicates that recuring payment should not happen further for the account number.
Mastercard:
Initial authorization request:
DE 22 POS Entry Mode: value must be 10 (credential on file)
DE 48.22 Multi-Purpose Merchant Indicator ->
Subfield 01—Low-Risk Merchant Indicator value = 01 (Merchant Initiated Transaction)
DE 61 Point of service data
Subfield 4 Pos cardholder presence value = 4 (Standing order/recurring transactions)
Subsequent authorization request:
DE 22 POS Entry Mode: value must be 10 (credential on file)
DE 48.22 Multi-Purpose Merchant Indicator ->
Subfield 01—Low-Risk Merchant Indicator value = 03 (Recurring Payment)
DE 48.63 Trace id: contains data in DE 63 (Network Data), subfield 1
(Financial Network Code) and subfield 2 (Banknet Reference Number) and DE 15 (Date,
Settlement) that is in the original Authorization Request
DE 48 More 3DS related data like dsTransactionId, cavv etc
DE 61 Point of service data
Subfield 4 Pos cardholder presence value = 4 (Standing order/recurring transactions)
Subfield 5 Pos card presense value = 1 (Card not present)
Partial authorization:
Partial authorization occurs when there are not enough funds in cardholder’s account to cover full payment amount. Instead of reject the transaction immediately, Payer can opt to use partial authorization to cover the payment with remaining funds in the account and then combined with some other form of payment.
Visa:
Initial authorization request: as per normal except that ISO 60.10 Additional authorization indicator = 1 to indicate request for authorization of estimated amount. Otherwise, if issuer's partial approval response will be rejected by visa with code 0733
Initial authorization response:
ISO 39 Response code: Code 10 to indicate partial approval for the initial auth request.
ISO 54 Additional amount: contains the original authorization amount
ISO 4 Transaction amount: contains approved amount for single currency
ISO 6 Cardholder billing amount: contains approved amount for multi currency
The acquirer can optionally reverse the authorization with partial approved amount
Reference: https://usa.visa.com/dam/VCOM/global/support-legal/documents/visa-partial-authorization-service.pdf
Mastercard:
Initial authorization request: as per normal except that DE 48 (Additional Data Private Use), Subelement 61 (POS Data Extended Condition Codes), subfield 1 (Partial approval terminal indicator) value = 1 (Merchant terminal supports receipt of partial approvals)
DE 39 Response code: Code 10 to indicate partial approval for the initial auth request.
DE 54 Additional amount:
Subfield 1 Acount type: Same as DE 3 Processing code
Subfield 2
DE 4 Amount transaction: contains approved amount for single currency
DE 6 Amount cardholder billing: contains approved amount for multi currency
Account verification (ZERO dollar auth):
This feature allows acquirer to request initial checks for estimated purchase amounts
Visa:
Authorization request:
ISO 4 Transaction amount: value = 0
ISO 25 Pos condition code: value = 51
zero dollar auth can be combined with CVV verification
Authorization response:
ISO 39 Response code: Code 00 or 85 to indicate successful verification.
ISO 44.10 CVV2 Result code: contains account verification result
Mastercard
Authorization request:
DE 4 Amount Transaction: value = 0
DE 61 Point-of-Service [POS] Data -> subfield 7 POS Transaction Status: value = 8 (Account status inquiry service)
Authorization response:
ISO 44.10 CVV2 Result code: contains cvv verification result
Address verification:
This feature allows acquirer to verifying cardholders' billing addresses for Card Not Present (CNP) transactions.
Visa:
Authorization request:
ISO 25 Pos condition code: value cannot be 51 (use 59 instead)
ISO 123 Verification data: contains card holder's postal code and address
Authorization response:
ISO 44.2 Address Verification Result Code: contains address verification result
Note:
For visa: US region address verification is mandatory. For other regions, address format may not be standard. AVS may fail as a result
Mastercard
Authorization request:
DE 48 Transaction category code: must be a valid TCC Eg. value = T (Phone, Mail, or Electronic Commerce Order)
DE 48.82 Address verification request: value = 52 (AVS and Authorization)
DE 120 Record Data: Contains postal code (9 digits) and address
Authorization response:
DE 48.83 Address verification service response: contains address verification result
CVV verification:
CVV verification service verifies card’s cvv value to reduce possibility of fraud. The result can be a valuable input to fraud system
Usually CVV is not a mandatory field on creditcard auth transaction
CVV verification can be added to normal auth request or account verification request
Visa:
Authorization request:
ISO 126.10 CVV2 Authorization Request Data: byte 1,2 are control flags, bytes 3-6 contains card cvv number
Note: If CVV value is missing, we usually still need ISO 126.10 field value present in auth request, with first byte value = 0 (CVV2 value not provided) and bytes 3-6 with space filled.
Authorization response:
ISO 44.10 CVV2 Result code: contains cvv verification result
Mastercard
Authorization request:
DE 48 Transaction category code: must be a valid TCC Eg. value = T (Phone, Mail, or Electronic Commerce Order)
DE 48.92 CVC2: contains card cvv number
Authorization response:
DE 48.87 Card Validation code result: contains cvv verification result.
3D secure transaction
Visa
Authorization request:
ISO 25: Pos condition code: value = 59
ISO 60.8 Mail/Phone/Electronic Commerce and Payment Indicator (ECI): 05 (Secure electronic commerce transaction) 06 (Non-authenticated security transaction at a 3-D secure-capable merchant, and merchant attempted to authenticate the cardholder using 3-D secure) 07 (Non-authenticated security transaction). Value of this field is based on paRes and CAVV from 3D security provider.
ISO 126.8 Transaction ID: provided by 3D security provider
ISO 126.9 CAVV Data:
Authorization response:
ISO 44.13 CAVV Result Code: contains cavv verification result
Mastercard
Authorization request:
DE 48.42 Electronic commerce indicator -> Subfield 1 Electronic Commerce Security Level Indicator and UCAF Collection Indicator ->
position 1(Security protocol): value = 2 (Channel),
position 2 (Cardholder authentication): value = 1 (Ecommerce / Identity check) ,
position 3 (UCAF Collection Indicator): if value =0, then UCAF cannot have value, if value = 1, 2, 3, 5, then UCAF must have value, mapped from ECI value returned by 3DS provider like cybersource
DE 48.43 Universal cardholder authentication field (UCAF): CAVV Data for mastercard
DE 48.66 Authentication data: -> Subfield 1 Program Protocol (3DS 1.0 or 2.0) Subfield 2 Directory Server Transaction ID
Authorization response:
3DS downgrade: if 3D transaction is downgraded to 2D, then
DE 48.42 Electronic commerce indicator ->
Subfield 2 Original Electronic Commerce Security Level Indicator and UCAF Collection Indicator: contains the corrected
Subfield 3 Reason for UCAF Collection Indicator Downgrade: 0 (Missing UCAF), 1 (Invalid UCAF)
Reference: https://www.mastercard.de/content/dam/mccom/de-de/PDF/ATNGE_Manual_v1_2.pdf
SCA Exemption
Strong authentication (3DS) is mandatory in european region. However, under certain scenarios, a transaction may be exempted from 3DS (Eg. small value transaction). In this case acquirer perform a 2D card transaction without merchant's liability shift with SCA exemption flag turned on. Card scheme/issuer may still reject the transaction though.
Visa
Authorization request:
ISO 25: Pos condition code: value = 59
ISO 34 Electronic commerce data (TLV)
If exemption type = trusted merchant exemption
Tag 84: Trusted merchant exemption indicator value = 1 (Trusted merchant exemption
claimed/requested)
ISO 126.5 Visa merchant identifier: contains the merchant id for exemption
If exemption type = low value exemption
Tag 87: Low Value exemption indicator value = 1 ()
If exemption type = transaction risk analysis
Tag 89: Transaction risk analysis (TRA) exemption indicator value = 1 (Transaction risk analysis exemption claimed/requested)
Authorization response:
ISO 34 Electronic commerce data (TLV)
ISO 39 Response code: Code 1A indicates that the exemption is soft declined
If exemption type = low value exemption
Tag 84: Trusted merchant exemption indicator value = 2 (Trusted merchant exemption
validated/hornored) or value = 3 (Trusted merchant exemption failed validation/not honored)
Tag 8C: Reasons For not honoring exemptions if Tag 84 = 3
If exemption type = transaction risk analysis
Tag 89: Transaction risk analysis (TRA) exemption indicator value = 2 (Transaction risk analysis exemption validated/honored) or value = 3 (Transaction risk analysis exemption failed validation/not honored)
Mastercard
Authorization request:
DE 48.22 Multi-Purpose Merchant Indicator ->
Subfield 01—Low-Risk Merchant Indicator
If exemption type = low value exemption
value = 02 Acquirer Low-Fraud and Transaction Risk Analysis
If exemption type = transaction risk analysis
value = 04 Low-Value Payment
Authorization response:
DE 39 Response code: Code 65 indicates that the exemption is soft declined