Visa System Integrity Fees
Visa System Integrity Fees Overview
The Visa Rules require the correct management and usage of declined transaction response codes. This serves not only to reduce fraud but to improve approval rates in general. Issuers can decide to decline a transaction for a variety of reasons. Some declined transactions will never be approved on a re-attempt, while others may be approved if the decline condition is addressed.
In order to further improve the payment ecosystem, Visa has introduced System Integrity Fees to incentivise the desired behaviour, and restate core requirements regarding authorisation best practices. Merchants must be aware of these requirements and prepare their systems accordingly.
Visa Rules for System Integrity
Merchants must be aware of the following Visa rules, and prepare to take actions to address any gaps in their systems:
- Familiarise yourselves with the decline code categories and adapt your system to address any gaps or undesirable behaviour with your authorisation retry strategy
- Refrain from excessive authorisation reattempts for specific decline response codes
- Maintain consistent data elements in authorisation reattempts
- Be aware of specific regional thresholds for response codes indicating fraud
Specific information on each of the above can be found in the next section.
Visa Decline Codes and Categories
Visa has required Issuers to use descriptive response codes in order to help merchants and acquirers identify decline reasons and optimise authorisation retry strategies. When merchants utilise the combination of response code and category correctly, issuers will benefit from the reduction of authorisation reattempts – for example, those transactions which will never be approved.
In addition to descriptive response codes, merchants are reminded of the requirement to provide accurate and consistent data when reattempting transactions.
Original ISO Response must be enabled
Merchants should ensure that they are configured to receive the
OriginalISOResponseCodefield ininitiatePaymentResponse. This will ensure they have the most accurate information in order to query and categorise all types of declines.
The full mapping of response codes to response code categories is shown below.
Decline Response Codes | Issuer Requirements | Merchant Reattempts |
|---|---|---|
Category 1: Issuer will never approve 04 (Pick up card [no fraud]) 07 (Pick up card, special condition [fraud account]) 12 (Invalid Transaction) 14 (Invalid account number [no such number]) 15 (No such issuer [first 8 digits of account number do not relate to an issuing identifier]) 41 (Lost card, pick up) 43 (Stolen card, pick up) 46 (Closed account) 57 (Transaction not permitted to cardholder) R0 (Stop payment order) R1 (Revocation of authorization order) R3 (Revocation of all authorizations order) | Limit use to transactions that will never be approved | Reattempt not permitted |
Category 2: Issuer cannot approve at this time 03 (Invalid merchant) | Use to indicate the decline condition | Reattempt permitted up to 20 attempts in 30 days |
Category 3: Data quality (Revalidate payment information before reattempt) 54 (Expired card or expiration date missing) | Use to indicate the decline condition/ data element in need of correction | Revalidate payment information Reattempt permitted up to 20 attempts in 30 days |
Category 4: Generic response codes All other Decline Response codes | Limit use to transactions where no other value applies | Reattempt permitted up to 20 attempts in 30 days |
Notes:
- Some of the above codes apply only to Card Present transactions. Card Not Present merchants can ignore these
Updated 8 days ago