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 - 消費者による不審請求の申請。不審請求の申請のすべてのカテゴリーについては、以下の表をご覧ください) |
不審請求の申請の条件コード |
不審請求の申請をさらに分類する、不審請求の申請カテゴリーのサブコード
|
ルール演算子
演算子 |
定義 |
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 |
購入 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 文字以内にすることをお勧めします。
不審請求の申請のカテゴリーと条件コード
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 - 現金または読み込み取引額を受領していない |