理由コードはどのように整理されていますか？
認識されるすべてのコードは、1 つのカードスキームと 5 つのカテゴリのいずれか 1 つに属します。役に立つのはカテゴリです。コードの文言を読む前に、そのケースが 3 つの抗弁の軸のどれに関わるかを教えてくれます。
下の表にないコードを受け取った場合は、
0000/00 / Not available として届きます。このページの最後の質問を参照してください。
Visa の理由コード
Fraud-related
10.4 はオンライン加盟店が最もよく目にするコードです。カード保有者がカード非提示取引を否認しています。
Authorization Errors
Processing Errors
12.6 は、カード保有者が二重に請求されたと言っている場合に最初に確認すべきコードです。多くの場合、2 件のオーソリ記録だけで回答できます。
Customer Disputes
13.2 と 13.7 はサブスクリプションとキャンセルに関するコードです。これらを決めるのは配送の証明ではなく、貴社のキャンセル記録と購入者が同意したポリシーです。
Mastercard の理由コード
Fraud-related
4837 は Chargeback Analytics の Mastercard 不正率カードを動かすコードです（Portal の分析を参照）。したがって、金銭的な影響だけでなくコンプライアンス上の影響が付随するコードです。
Authorization Errors
Processing Errors
Customer Disputes
Miscellaneous
2 つのスキームが似た見た目のコードを使っています。自分のコードを正しく読むには？
コードは必ずケースのカードスキームと一緒に読んでください。コードはスキーム内でのみ一意であり、Waffo はまさにこの曖昧さを避けるためにスキーム別にコードを解決しています。誤ったスキームで調べたコードは、誤った主張と誤った証拠に導く可能性があります。ケースの記録には両方が含まれています。両方を使ってください。ケースに不明な理由、または役に立たない理由が表示されています。どうすればよいですか？
Waffo が認識しないコード、またはコードなしで届いたケースは、理由 Not available とともに0000/00 として表現されます。これはデータエラーではなく実際の状態です。一部の申立側はコードを渡してきません。
期限も、抗弁できるかどうかも変わりません。変わるのは提出物の組み立て方です。狙うべきコードがないため、チャージバック証拠ガイドにあるフォールバックの組み合わせを送り、可能であれば提出前に実際の主張が何かを確認してください。
Reported Fraud とは何ですか？チャージバックと同じものですか？
いいえ。両者は別々の記録であり、一方が他方を意味することはありません。
取引は、不正として報告されてもチャージバックされないこともあれば、チャージバックされても報告されないこともあります。どちらもコンプライアンス比率に関わり、比率カードの 1 つは意図的に両者を合算しています。どのカードが何をカウントするかはPortal の分析を参照してください。
実務上のポイント：Reported Fraud はシグナルであり、負債ではありません。直接のコストはかからず、個々の記録に対して取るべきアクションもありませんが、件数の増加はチャージバックと監視プログラムの問題が迫っていることの早期警告です。トレンドとして読んでください。
Reported Fraud はどのように照会しますか？
/api/v1/fraud-report/list を通じて行います。ページングされた POST です。Portal に Reported Fraud の一覧ページはないため、個々の記録を取得できるのは API だけです。
日付範囲は不正が報告された日時でフィルタします。これは取引が発生した日時より後、多くの場合かなり後です。不正があったと分かっている期間で空に見える範囲は、たいてい取引日を狙って指定してしまった範囲です。
各 Reported Fraud の記録には何が含まれますか？
これに対して実装する際に注意すべき点が 2 つあります。
fraudReasonCode はスキームの不正分類であり、このページのチャージバック理由コードとは異なるコード空間です。一方を他方の表で調べないでください。また、どの識別子が設定されているかで、取引がどのフローから来たかが分かります。subscriptionId が設定され paymentRequestId が空の記録はサブスクリプションの課金であり、通常は有用な証拠は単一の注文ではなくサブスクリプションの同意と課金履歴になります。
ケースの 1 つに Defend ボタンがないのはなぜですか？
異議申し立ての行のアクションは、次の両方が成り立つ場合のみ Defend と表示され、それ以外は View と表示されます。- ケースが応答を受け付けるステータスにある —
EVIDENCE_REQUIRED、ACTION_REQUIRED、SECOND_CYCLE_RESPONSE_REQUIREDのいずれか。最終ステータスのケース、期限切れのケース、まだUNDER_REVIEWのケースはすべて View と表示されます。 - 貴社の Portal ユーザーが異議申し立て更新の権限を持っている。 これがないと、状態に関わらずすべてのケースが View と表示されます。これが見落とされがちな原因です。同僚は抗弁できるのに自分はできないケースがあれば、それはケースではなく権限の問題です。アカウント管理者に依頼してください。
INCOMPLETE に置かれます。INCOMPLETE は応答可能なステータスではないため View と表示されます。ケースは貴社が何もしなくても ACTION_REQUIRED に移って抗弁可能になるか、クローズされます。不完全な間は期限の時計は動き始めません。
顧客の異議申し立てを自分でクローズできるかどうかは何で決まりますか？
2 つの条件で、どちらもケース側にあります。- ステータスがまだアクションを受け付けるもの —
UNDER_REVIEW、または応答が必要なステータスのいずれか。 - Compulsory Channel Review が false である。 申立側がケースを自身のレビューに通すことを要求している場合、貴社が自分でクローズすることはできず、Close アクションは提供されません。Compulsory Channel Review の意味はチャージバックのフィールドリファレンスにあります。
UNDER_REVIEW、応答が必要なステータス、さらにケース自体が返信を許可している場合は CLOSED でも返信できます。クローズ済みの顧客の異議申し立てに未読件数が表示され得るのはこのためです。
見つからないコードや、注文に紐づけられない Reported Fraud の記録がありますか？
acquiringOrderId を添えてサポートにお問い合わせください。