After the Payment

Payment Response Analysis

Merchant Advice Code

Not all acquirers return this value; however, if it is returned, it should be analyzed.

The parameter merchant_advice_code provides additional information on a given transaction response decline. Merchant Advice Codes are supported by Mastercard to enable issuers to communicate insights to acquirers and merchants and thus let them optimize their subsequent retry strategies for declined transactions.

01 New account information available
02 Cannot approve at this time, try again later
03 Do not try again
04 Token requirements not fulfilled for this token type
21 Payment Cancellation

Merchant advice code values 03 and 21 are intended to send a clear message that a transaction should not be resubmitted for approval:

  • Value 03 is sent by issuers to indicate that an account is closed or fraudulent, and that no further approvals will be forthcoming;
  • Value 21 is sent by Mastercard Payment Cancellation Service (PCS) to indicate a cardholder canceled the agreement and instruct the merchant and acquirer to not retry the transaction.

In order to avoid unnecessary declines, pay close attention to the returned merchant advice code value.


AVS Response Codes

If you are using Address Verification System, then in the response you will receive avs_status object:

{
    "avs_status": {
                "description": "Street address and ZIP code do not match",
                "avs_status": "N",
                "avs_status_timestamp": "2022-10-26T07:17:17Z"
                }
}
avs_statusdescription
AStreet address matches ZIP code does not match
BStreet address matches. ZIP code not verified (incorrect format)
CStreet address and ZIP code not verified (incorrect format)
DStreet address and ZIP code match
FStreet address and ZIP code match. Applies to UK-issued cards
GNot verified or not supported
IStreet address and ZIP code not verified
MStreet address and ZIP code match
NStreet address and ZIP code do not match
PZIP code matches. Street address not verified (incorrect format)
RService unavailable
SNot supported
TNine-digit zip code matches address does not match
UAddress not verified due to lack of issuer support or system malfunction
WZIP code matches street address does not
XZIP code and address match
YCardholder street address and ZIP code match
ZZIP code matches

Cardaq Gate does not make any automatic decisions based on the AVS response codes! These codes are merely informative and merchants themselves must analyze the returned codes in order to take appropriate actions (e.g., reverse or refund the payment).


Electronic Commerce Indicator

An Electronic Commerce Indicator (ECI) is a code within the 3D Secure protocol to indicate the level of authentication performed during a transaction. It acts as a status code, providing information about the success or failure of authentication attempts. The ECI guides merchants on how to proceed with the transaction.

Our getaway provide merchants with two ECI-related values. In the order response transaction_details object, you can find eci value within the three_d_secure_status object as it was received directly from the 3DS provider during the authentication step and forwarded to the payment provider:

{
    "transaction_details": {
        "three_d_secure_status": {
            "eci": "05"
        }
    }
}

The second ECI-related field is called auth_eci and can be found directly in the order response transaction_details object. This value is returned to the gateway by the payment provider after the authorization step and it reflects the actual ECI value assigned by the card scheme:

{
    "transaction_details": {
        "auth_eci": "07"
    }
}

The auth_eci value is of importance because it reflects whether the card scheme or issuer has performed a downgrade or upgrade. Namely, they may decide that the authentication has not been strong enough and hence return a different, most likely, lower ECI value. Chargeback liability is thus shifted back to the merchant. We suggest merchants to compare the original (eci) and the final (auth_eci) ECI values and then take action (for example, reverse the payment) to avoid potential chargebacks.