RDR will automatically “accept” a Visa pre-dispute on your behalf, based on the rules you define as part of enrolment. Rules are composed of conditions that mirror the attributes of the disputed transaction, such as the transaction amount or purchase identifier. In the rule evaluation process, the outcome will result in either an "accept" or a "decline" response.
- If the conditions of the rules are met, then you are opting to “accept” the liability of the pre-dispute and authorise Visa to automatically refund the full amount of the transaction back to the cardholder, avoiding a chargeback.
- If none of the conditions of the rules are met, then you are opting to “decline” the liability of the pre-dispute, which will result in a chargeback.
- RDR coverage is fully automated. Once your rules are in place, there's no additional action you need to take to prevent a dispute.
This guide will walk you through everything you need to know to properly set up your rules to avoid chargebacks through RDR.
Understanding RDR Rules
Rules are composed of the following major elements:
- Rule Name
- Rule Attributes
- Rule Operator
- Rule Values
Rule Name
- Identifier created by the merchant and made available in reporting.
- Visible to the Issuer and Acquirer involved in the request.
Rule Attributes
Attribute |
Definition |
Personal Account Number BIN |
6-digit Issuer BIN |
Transaction Date |
Date when the transaction occurred (E.g. Format: DD/MM/YYYY) |
Transaction Amount |
Total amount of the transaction (E.g. Format: 10.00) |
Transaction Currency Code |
ISO currency code of the transaction (E.g. GBP) |
Purchase Identifier |
Unique order identifier assigned to every transaction. Transmitted to the Issuer by the Acquirer to identify the customer order for automated resolution. |
Dispute Category |
Code defined by Visa to classify the dispute (E.g. 10- Fraud, 11- Authorisation, 12- Processing Errors, 13- Consumer Disputes. Please refer to table below for all Dispute Categories) |
Dispute Condition Code |
Sub-code of the Dispute Category to further classify the Dispute
|
Rule Operators
Operator |
Definition |
Contains |
Attribute must include the specified value |
EqualTo |
Attribute must be equal to the specified value |
GreaterThan |
Attribute must be greater than the specified value |
GreaterThanOrEquals |
Attribute must be greater than or equal to the specified value |
IsBlank |
Attribute does not include a value. Can be True or False. |
LessThan |
Attribute must be less than the specified value |
LessThanOrEquals |
Attribute must be less than or equal to the specified value |
NotEqualTo |
Attribute is not equal to the specified value |
StartsWith |
Attribute must start with the specified value |
IsIn |
Attribute must contain the chosen possible values.
|
IsNotIn |
Attribute must not contain the chosen possible values.
|
Rule Values
Attribute |
Format |
Possible Values |
Possible Operators |
Personal Account Number BIN |
Number |
Should be the 6-digit Issuer BIN. |
Contains, EqualTo, IsBlank, NotEqualTo, StartsWith |
Transaction Date |
Date |
Date in DD/MM/YYYY |
EqualTo, NotEqualTo, GreaterThan, GreaterThanOrEquals, IsIn, IsNotIn, LessThanOrEquals, LessThan |
|
Transaction Currency Code |
Dropdown or freeform |
Alphanumeric ISO 4217 Currency Codes Select the transaction’s currency from the dropdown. You can select multiple values for “IsIn” and “IsNotIn”. |
Contains, EqualTo, IsBlank, IsIn, IsNotIn, NotEqualTo, StartsWith |
Purchase Identifier |
Alphanumeric |
Should be the unique order identifier assigned to every transaction. |
Contains, EqualTo, IsBlank, IsIn, IsNotIn, NotEqualTo, StartsWith |
Dispute Category |
Dropdown or freeform |
Select from the following: 10-Fraud 11-Authorisation 12-Processing Error 13-Consumer |
Contains, EqualTo, NotEqualTo, IsBlank, IsIn, IsNotIn |
Dispute Condition Code |
Drop down or freeform |
Select the appropriate code from the table below |
Contains, EqualTo, NotEqualTo |
Rule Setup Considerations
Here are some principles to keep in mind when determining your rules:
- Rules must be defined for every Merchant BIN/CAID combination.
- Each BIN/CAID can have up to 10 different rules. A rule can have up to 7 conditions.
- All fields in the rule (Attribute, Operator, Value) are mandatory. Please do not leave any field blank.
- Some Attributes can use approximate match operators such as “StartsWith” or “Contains”. The minimum value for these attributes is at least one character or digit.
- As best practice, it is advised to not use the free-form entry (where provided) along with approximate match operators such as “Contains” and “IsIn”. This may result in multiple cases with similar matches being accepted.
- Rules are evaluated in sequence (rule one is evaluated first, then rule two, etc.). If there are five rules and the conditions of the first rule are met, then the remaining rules are not evaluated.
- If the conditions of any rule are met, then the pre-dispute is “accepted”, resulting in a refund back to the Cardholder.
- If a rule has multiple conditions, all conditions of the rule must be met to “accept” liability.
- If none of the conditions of all the rules you have created are met, then the pre-dispute is “declined” and results in a chargeback.
- For any RDR case that is “accepted”, the Rule Name of the rule that was triggered is shared with the Merchant’s Acquirer and the Issuer of the Cardholder to let them know why the dispute was resolved.
Best Practices for Rule Management
- Do not include contradictory dispute categories and condition codes (e.g. a Dispute Category = “10” and a Dispute Condition Code = “12.1”).
- A rule should not conflict with another rule (e.g. “Transaction Date IsGreaterThan 01/01/2020” in one rule and “Transaction Date IsLessThan 01/01/2020” in another)
- If Transaction Amount is a condition in a rule, it should have a corresponding condition for Transaction Currency Code.
- Keep rule names short, explicit, and clear enough to be referenced in RDR communications. It is recommended to keep the name within 30 characters.
Dispute Category and Condition Codes
10. Fraud |
11. Authorisation |
12. Processing Errors |
13. Consumer Disputes |
|
10.1 - EMV liability shift counterfeit fraud 10.2 - EMV liability shift non-counterfeit fraud 10.3 - Other fraud-card present environment 10.4 - Other fraud-card absent environment 10.5 - Visa fraud monitoring program |
11.1 - Card recovery bulletin 11.2 - Declined authorisation 11.3 - No authorisation |
12.1 - Late presentment 12.2 - Incorrect transaction code 12.3 - Incorrect currency 12.4 - Incorrect account number 12.5 - Incorrect amount 12.6 - Duplicate processing/paid by other means |
13.1 - Merchandise/Services not received 13.2 - Cancelled recurring 13.3 - Not as described or defective merchandise/services 13.4 - Counterfeit merchandise 13.5 - Misrepresentation 13.6 - Credit not processed 13.7 - Cancelled merchandise/services 13.8 - Original credit transaction not approved 13.9 - Non-receipt of cash or load transaction value |