如何为由 Verifi 支持的 RDR 创建规则
RDR 将在争议发生前，根据您在注册过程中设定的规则，自动代表您“受理”预争议案件。规则由反映争议交易属性的条件组成（例如，交易额或购买识别码）。回应（“接受”或“拒绝”责任）将取决于规则求值结果。
- 如果规则条件全部得到满足，则您选择“接受”争议前责任，并授权 Visa 自动将交易金额全额退还给持卡人，以避免撤单。
- 如果规则条件均未得到满足，则您选择“拒绝”争议前责任，而这将导致撤单。
- RDR 将自动对案件进行处理。规则一经设定，您将无需采取任何额外争议预防措施。
本指南将为您介绍如何通过 RDR 正确设定规则，以避免撤单。
理解 RDR 规则
规则主要由下列要素组成：
- 规则名称
- 规则属性
- 规则运算符
- 规则值
规则名称
- 商家创建并在报告中提供的识别码。
- 对申请所涉及的发卡行和收单行可见。
规则属性
属性 |
定义 |
个人账号 BIN |
6 位数发卡行 BIN |
交易日期 |
交易发生的日期 （格式示例：MM/DD/YYYY） |
交易额 |
交易的总金额 （格式示例：10.00） |
交易货币代码 |
交易的 ISO 货币代码 （例如USD） |
购买识别码 |
分配给每笔交易的唯一订单识别码。 由收单行传输给发卡行，用于识别适用自动争议解决流程的客户订单。 |
争议类别 |
Visa 定义的争议分类代码 （例如10- 欺诈，11- 授权，12- 处理错误，13- 消费者争议。请参考下表中的所有“争议类别”） |
争议条件代码 |
进一步划分争议的争议类别子代码
|
规则运算符
运算符 |
定义 |
Contains |
属性必须包括指定值 |
EqualTo |
属性必须等于指定值 |
GreaterThan |
属性必须大于指定值 |
GreaterThanOrEquals |
属性必须大于或等于指定值 |
IsBlank |
属性不包括指定值。可以为 True 或 False。 |
LessThan |
属性必须小于指定值 |
LessThanOrEquals |
属性必须小于或等于指定值 |
NotEqualTo |
属性不等于指定值 |
StartsWith |
属性必须从指定值开始 |
IsIn |
属性必须包含所选定的可能的值。
|
IsNotIn |
属性不得包含所选定的可能的值。
|
规则值
属性 |
格式 |
可能的数值 |
可能的运算符 |
个人账号 BIN |
号码 |
应该为 6 位数 发卡行 BIN。 |
Contains, EqualTo, IsBlank, NotEqualTo, StartsWith |
交易日期 |
日期 |
日期格式：MM/DD/YYYY |
EqualTo, NotEqualTo, GreaterThan, GreaterThanOrEquals, IsIn, IsNotIn, LessThanOrEquals, LessThan |
|
交易货币 代码 |
下拉或自由形式 |
含字母和数字 ISO 4217 货币代码 从下拉列表中 选择交易的 货币。可以为 “IsIn” 和 “IsNotIn” 选择多个数值。 |
Contains, EqualTo, IsBlank, IsIn, IsNotIn, NotEqualTo, StartsWith |
购买识别码 |
含字母和数字 |
应是分配给每笔交易的唯一订单识别码。 |
Contains, EqualTo, IsBlank, IsIn, IsNotIn, NotEqualTo, StartsWith |
争议类别 |
下拉或自由形式 |
从下列选项中选择： 10-欺诈 11-授权 12-处理错误 13-消费者 |
Contains, EqualTo, NotEqualTo, IsBlank, IsIn, IsNotIn |
争议条件代码 |
下拉或自由形式 |
从下表中 选择恰当的代码 |
Contains, EqualTo, NotEqualTo |
设置规则时的考虑因素
在确定规则时，请遵循下列原则：
- 必须针对每个商家 BIN/CAID 组合定义规则。
- 每个 BIN/CAID 最多可以设置 10 条规则。每条规则最多可以有 7 项条件。
- 规则（属性、运算符和值）中的所有字段均为必填字段。切勿留空。
- 部分属性可以使用近似匹配运算符（例如，“StartsWith”或“Contains”）。该等属性的最小值至少是一个字符或数字。
- 推荐最佳做法是：不要将自由格式条目（如有规定）与近似匹配运算符（例如，“Contains”和“IsIn”）搭配使用；否则，可能会导致具有类似匹配项的多个案件被受理。
- 规则将按顺序求值（先对第一条规则求值，然后对第二条规则求值，以此类推）。如果有五条规则，且第一条规则的条件均已得到满足，则无需再对剩余规则进行求值。
- 如果任何规则的条件均已得到满足，则“接受”争议前责任，并向持卡人退款。
- 如果一条规则有多项条件，则必须满足所有规则条件，方可“接受”责任。
- 如果您创建的所有规则条件均未得到满足，则“拒绝”争议前责任，并导致撤单。
- 针对“已受理” RDR 案件，商家收单行和持卡人发卡行将被告知已触发规则的“规则名称”，以便其知晓争议得到解决的原因。
最佳规则管理实践
- 切勿包含相互矛盾的争议类别和条件代码（例如，争议类别＝“10”且争议条件代码＝“12.1”）。
- 规则之间不得彼此冲突（例如，一条规则为“交易日期大于等于 2020 年 1 月 1 日”，另一条规则为“交易日期小于等于 2020 年 1 月 1 日”）。
- 如果交易额是一条规则中的一项条件，则该条规则还应包含对应的交易货币代码条件。
- 使用简洁明了的规则名称，以便在 RDR 通讯中对其进行援引。建议规则名称不超过 30 个字符。
争议类别和条件代码
10.欺诈 |
11.授权 |
12.处理错误 |
13.消费者争议 |
|
10.1 - EMV 责任转移仿冒品欺诈 10.2 - EMV 责任转移非仿冒品欺诈 10.3 - 其他欺诈——有卡环境 10.4 - 其他欺诈——无卡环境 10.5 - Visa 欺诈监控计划 |
11.1 - 银行卡恢复公告 11.2 - 授权被拒绝 11.3 - 无授权 |
12.1 - 延迟请款 12.2 - 交易代码错误 12.3 - 货币错误 12.4 - 账号错误 12.5 - 金额错误 12.6 - 重复处理/已其他方式支付 |
13.1 - 未收到商品/服务 13.2 - 经常性付款被取消 13.3 - 与描述不符或商品/服务有缺陷 13.4 - 假冒商品 13.5 - 虚假陈述 13.6 - 贷记未处理 13.7 - 商品/服务被取消 13.8 - 未批准原始贷记交易 13.9 - 未收到现金或加载交易值 |