Verifi 提供の RDR のルールを作成する方法

RDR は、登録時に定義されたルールに基づき、お客様の代理として Visa の不審請求の申請前段階を自動的に「承認」します。ルールは、取引額や購入 ID など、不審請求が申請された取引の属性と等しい条件で構成されます。ルールの評価プロセスでは、結果が「承認」または「拒否」のいずれかの応答になります。

ルールの条件に一致する場合、不審請求の申請前段階の支払い義務を「承認」することになり、Visa が取引の全額を自動的にカード保有者に返金することを認証して、チャージバックを回避します。
どのルールの条件にも一致しない場合、不審請求の申請前段階の支払い義務を「拒否」することになり、チャージバックが発生します。
RDR の対応範囲は全面的に自動化されています。ルールが適用された後で、不審請求の申請を防止するために必要なアクションはありません。

このガイドでは、ルールを適切に設定して RDR 経由のチャージバックを回避するために知っておく必要があることを、手順を追って説明します。

RDR ルールについて

ルールは次の主要な要素で構成されます。

ルール名
ルール属性
ルール演算子
ルール値

ルール名

加盟店によって作成され、レポートに使用できる ID。
リクエストに関係するカード発行会社とアクワイアラーに表示されます。

ルール属性

属性	定義
個人の口座番号の BIN	6 桁のカード発行会社の BIN
取引日	取引の発生日 (例: 形式: MM/DD/YYYY)
取引金額	取引の合計額 (例: 形式: 10.00)
取引通貨コード	取引の ISO 通貨コード (例: USD)
購入 ID	それぞれの取引に割り当てられた一意の注文 ID。自動解決を行う購入者の注文を特定するために、アクワイアラーからカード発行会社に送信されています。
不審請求の申請のカテゴリー	Visa によって定義された、不審請求の申請を分類するためのコード (例: 10 - 不正利用、11 - 承認、12 - 処理エラー、13 - 消費者による不審請求の申請。不審請求の申請のすべてのカテゴリーについては、以下の表をご覧ください)
不審請求の申請の条件コード	不審請求の申請をさらに分類する、不審請求の申請カテゴリーのサブコード (例: 10.4 - その他の不正利用: カード非提示の環境、13.3 - 商品 / サービスが説明と異なるまたは欠陥がある

ルール演算子

演算子	定義
Contains (次を含む)	属性には指定した値が含まれている必要があります
EqualTo (次に等しい)	属性と指定した値が一致している必要があります
GreaterThan (次より大きい)	属性は指定した値より大きい必要があります
GreaterThanOrEquals (次の値以上)	属性は指定した値以上である必要があります
IsBlank (空白である)	属性には値が含まれていません。True または False を指定できます。
LessThan (次より小さい)	属性は指定した値より小さい必要があります
LessThanOrEquals (次の値以下)	属性は指定した値以下である必要があります
NotEqualTo (次と等しくない)	属性と指定した値が一致していません
StartsWith (次で始まる)	属性は指定した値で開始している必要があります
IsIn (次の範囲内)	属性には選択した指定可能な値が含まれている必要があります。注: 取引日について、使用可能な値は 30、60、90 日です。
IsNotIn (次の範囲外)	属性には選択した指定可能な値が含まれていない必要があります。注: 取引日について、使用可能な値は 30、60、90 日です。

ルール値

属性	形式	使用可能な値	使用可能な演算子
個人の口座番号の 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
購入 ID	英数字	それぞれの取引に割り当てられた一意の注文 ID である必要があります。	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」などの近似一致演算子を使用できます。これらの属性の最低値は、1 文字または 1 桁です。
ベストプラクティスとして、「Contains」や「IsIn」などの近似一致演算子とともに、自由形式の入力 (提供されている場合) を使用しないことをお勧めします。類似する一致の複数のケースが承認される可能性があるためです。
ルールは順番に評価されます (ルール 1 が最初に評価され、ルール 2 などが続く)。5 つのルールがあり、最初のルールの条件に一致した場合、残りのルールは評価されません。
いずれかのルールの条件に一致した場合、不審請求の申請前段階は「承認済み」になり、カード保有者に返金されます。
ルールに複数の条件が含まれる場合、支払い義務を「承認」するには、ルールのすべての条件に一致する必要があります。
作成したすべてのルールのどの条件にも一致しない場合、不審請求の申請前段階は「拒否」され、チャージバックが発生します。
「承認済み」の RDR ケースでは、不審請求の申請が解決された理由を知らせるために、引き金となったルールの名前が加盟店のアクワイアラーとカード保有者のカード発行会社に共有されます。

ルール管理のベストプラクティス

不審請求の申請カテゴリーと条件コードが矛盾しないようにしてください (例: 不審請求の申請カテゴリー = 「10」で、条件コード = 「12.1」)。
ルールを別のルールと競合させることはできません (例:「取引日 IsGreaterThan 01/01/2020」が 1 つ目のルールで、「取引日 IsLessThan 01/01/2020」が別のルールで指定される)
取引金額がルール内の条件である場合は、対応する取引通貨コードの条件も含まれている必要があります。
ルール名は、RDR のコミュニケーションで参照できるように、短く、明示的で、分かりやすいものにします。名前は 30 文字以内にすることをお勧めします。