リスクによって決済が拒否されたとき、API は何を返しますか？
2 つのコードがあり、どちらも注文リクエスト自体に対して HTTP406 で返されます。
これらはリスクの判断が直接表面化したものです。どちらもその注文については最終として扱ってください。再試行可能な通信障害でもなければ、待てば処理される審査キューでもなく、拒否です。
D0001 は Payout、カード、ポイントチャージの各面にも同じ意味で存在するため、1 つのハンドラーでカバーできます。D0002 は Payin の面に属します。
コード上でリスクによる拒否と決済手段による拒否をどう見分けますか？
どの面を読んでいるかによります。そしてここが人を引っかける部分です。
具体的には、非同期の面では失敗は
orderFailedReason として届きます。これは orderFailedCode と orderFailedDescription を持つ JSON の値です。orderFailedCode はカテゴリであり、同期レスポンスで見た固有のコードではありません。また orderStatus は通常のクローズ済み注文のステータスであり、リスク専用の注文ステータスは存在しません。
実務上の 2 つのルールが導かれます。
- 同期コードが得られたときは記録してください。 区別が機械可読なのはそこだけです。貴社の注文に紐付けて永続化してください。
- 説明の文字列で分岐しないでください。 これはサポートチケットを読む人間向けの自由記述であり、安定したインターフェースではありません。
限度額により決済が拒否されました。どの限度額ですか？変更できますか？
限度額はいくつかの場所に由来し、上記のリスクコードとは異なるコードを使います。
これらのうち貴社が影響を与えられるもの、1 日の金額の数え方、枠がいつ解放されるかは、エラーコードと限度額の補足とPayin 契約と限度額で扱っています。要約すると、金額の範囲と上限は貴社アカウントの設定に由来するため、変更するのは Portal の設定ではなく相談事項です。ただし 1 つ例外があります（下記）。
カードごと、ユーザーごとの制限を自分で設定できますか？
はい。取引限度額ルール API を通じてできます。これが貴社自身で操作できる唯一のリスク関連の制御です。API 専用で、Portal の画面はありません。エンドポイント、リクエストの形、ルールが何をキーにできるか、ルールの読み取りや停止の方法は取引限度額ルールにあります。 ルールを有効にする前に知っておくべきことが 3 つあります。- ルールが発動すると、決済はリスクの判断として拒否されます。 購入者の決済は「貴社のルールが発動した」という独自のコードではなく、上記のリスクコードで失敗します。したがって非同期の面では、拒否を自社のルールに帰属させることはできません。何を制限したかは自社で記録しておいてください。
- ルールはすでに存在する注文にも影響し得ます。 リスクは注文を作成した時点ではなく、購入者が実際に支払う時点で照会されます。したがって、ルールを有効にする前に作成され、その後に支払われた注文はそのルールで評価されます。すでに成功した決済のみが影響を受けません。
- 制限を加えることしかできません。 カードやユーザーを審査から除外するルールの方向は存在しません。
3D Secure はいつ発生しますか？貴社側で決められますか？
カード情報内のthreeDsDecision を使って、注文に希望を表明できます。
それ以外の値は無効なカード情報として拒否されます。ただしこのフィールドはスイッチではなく希望であり、その上位に 3 つのものがあります。
- リスクの判断。 貴社の値はリスクへの入力の 1 つであり、実際に使われる判断を返すのはリスクです。
- 決済手段にできること。 判断は、決済が通る経路で満たせるものでなければなりません。何も満たせない場合、注文は静かに格下げされるのではなく失敗します。
- イシュアー。 3D Secure の決済であっても、購入者がチャレンジを受けるか、操作なしで通過するかを決めるのはイシュアーであり、Waffo でも貴社でもありません。
3DS_FORCE は「これを省略しないでください」、NO_3DS は「許されるなら省略してください」と読むのが最も適切です。
NO_3DS を送ったのに購入者が認証を求められました。送り方が間違っていたのですか？
おそらく違います。上記の順序を踏まえると、リスクの判断または決済経路が認証を必要としたために、認証ステップが現れることがあります。このフィールドは検証されるため、本当に不正な値であれば無視されるのではなく、無効なカード情報のエラーでリクエストが失敗していたはずです。注文が受理されたのであれば、値は理解されています。
もう 1 つ除外すべきケースは適用範囲です。このフィールドが効果を持つのは、購入者が同席しているカード、Apple Pay、Google Pay の決済のみです。それ以外の決済手段では何もしません。
サブスクリプションの更新など、加盟店起点の課金に 3D Secure の指定を設定できますか？
いいえ。そしてこれが「無視されているように見える」理由です。この値は加盟店起点のカード取引に対して受理・検証されますが適用されません。サブスクリプションの更新は加盟店起点なので、そこにthreeDsDecision を設定しても効果はなく、エラーも発生しません。
継続課金の一連の取引における認証が行われるのは、購入者が同席している時点、つまり最初の決済かマンデートの設定時です。サブスクリプションとトークン化を参照してください。
チャレンジは購入者にどのように届きますか？自社フロントエンドで何を処理する必要がありますか？
追加のステップが必要になると、注文は「認証が必要」を意味するステータスと、購入者をどこへ送るかを記述したorderAction とともに返ってきます。
Waffo がホストするチェックアウトを使う場合は自動的に処理され、購入者は認証ページへ送られて戻ってきます。自社でフロントエンドを構築する場合は次を行う必要があります。
- 作成レスポンス（および照会）で認証が必要なステータスを検出する。
orderActionをパースし、actionTypeで分岐する。- ページ全体の遷移を行う。小さなフレーム内で試みないでください。認証ページはフレーム内での描画を拒否することが多く、購入者は空の枠を見つめることになります。
- 戻ってきたとき、戻ってきたこと自体を結果として扱わないでください。注文照会をポーリングするか、決済通知を待ってください。
actionData が他に何を運べるかを含む）は、注文作成フィールドガイドとリダイレクトとアクションタイプにあります。
リスクはすべての取引でリアルタイムに評価されますか？
はい。評価は決済リクエストの内部で、決済が試みられる前に行われ、結果はその注文に即座に適用されます。バッチ処理はなく、すでに通過した決済を後から再スコアリングすることもありません。 これは一見矛盾して見えるパターンも説明します。ある購入者の最初の決済が成功し、2 回目が拒否されるのはまったく正常です。各決済はそれ自体の文脈（金額、決済手段、履歴、その間に何が起きたか）で個別に評価されるため、同じ人の数分違いの 2 件の決済で結果が異なり得ます。リスクで拒否された取引は Portal のどこで見られますか？
カテゴリとしてではなく、注文ごとに見られます。
したがってワークフローは、failure analysis で件数を把握し、その後は自社の記録から個別の注文を引き出す、という流れになります。Payments 一覧が提供するフィルターはPortal の一覧フィルターと期間指定にあります。
failure analysis は何を教えてくれますか？注文まで掘り下げられますか？
何件となぜを、次のようにグループ化して教えてくれます。決済手段側に起因する失敗、顧客側に起因する失敗、貴社側に起因する失敗で、それぞれが個別の失敗説明とその件数・割合に展開されます。 注文までは掘り下げられません。このパネルの背後にあるリクエストは、プロダクト、サブスクリプションの段階、国、決済手段、期間でパラメータ化されており、注文でパラメータ化されることはありません。またレスポンスは注文の識別子ではなく件数を含みます。失敗理由をフィルターとして Payments 一覧に持ち込むリンクもありません。 このパネルが何を数えているか、なぜ分析の数値が一覧の件数と厳密に一致しないかは、Portal のダッシュボードと分析にあります。拒否された取引は成功率に算入されますか？
はい。成功率は成功した注文÷作成された注文であるため、作成された後に拒否された注文は、理由がリスクを含め何であれ分母に残ります。Portal はこれと並んで、より狭い 2 つの比率も表示します。作成された注文のうち決済ステップに到達した割合と、そのうち成功した割合です。 リスクによる拒否は決済ステップで発生するため、全体の比率だけでなく、狭い方の比率の分母にも入ります。実務上の帰結：注文を作成する前にトラフィックを事前選別すれば比率は改善しますが、作成した後に拒否しても改善しません。自社のチャージバック率と不正報告率を確認できますか？
はい。Chargeback Analytics で確認できます。そこでは 1 つの合成値ではなくカードスキームごとに報告されます。スキームによって定義が異なるためです。
どちらの分子も「期間内に受領したもの」であり、「期間内に行われた決済に属するもの」ではないことに注意してください。チャージバックは決済から数か月後に届くため、この比率はコホートの指標ではなく期間の指標です。この画面ではチャージバックの件数と金額、トレンド、理由コードの分布、期限が近づいているケースも確認できます。データは 1 日遅れで、選択できる期間には上限があります。
各比率のカードが何を測っているか、どの期間を報告しているかもPortal のダッシュボードと分析にあります。ケースへの対処はチャージバックとチャージバックの証拠にあります。
不正報告はチャージバックと同じものですか？別々に照会できますか？
同じものではありません。不正報告は、イシュアーがスキームに対して取引が不正であったと伝えるものであり、チャージバックが後続しないまま届くこともあります。だからこそ上記で独自の比率として現れるのです。 個々の不正報告は、Reported Fraud 一覧 API（/api/v1/fraud-report/list、報告日、スキーム、または単一の注文でフィルタ）を通じて別々に照会できます。Portal にはそのための一覧ページはなく、Chargeback Analytics 内の集計のみが表示されます。フィールドごとの内容は理由コードと Reported Fraudを参照してください。
決済が拒否されましたが、そうあるべきではないと思います。異議申し立てやカードの許可リスト登録はできますか？
どちらについてもセルフサービスの仕組みはありません。異議申し立てのエンドポイントも、カード・購入者・範囲に対する許可リストや除外もなく、そのための Portal の画面もありません。加盟店が操作できる唯一のリスク制御は限度額ルール API であり、それは制限を加えることしかできません。 したがって経路は、注文の識別子を添えてサポート担当に連絡することです。決済を再試行のループとして組み直さないでください。拒否された決済手段への繰り返しの試行は、それ自体がリスクのシグナルです。 IP 許可リストは別の機能であり、こちらはセルフサービスです。これは貴社のどのサーバーが API を呼べるかを制限するもので、購入者の審査とは関係ありません。Portal のセルフサービスセキュリティ設定を参照してください。サンドボックスでリスクによる拒否や 3D Secure のチャレンジをテストできますか？
直接はできません。サンドボックスのシミュレーターは注文金額で結果を制御し、生成できる結果は、作成・キャンセル・返金の各パスにおける決済失敗、システムエラー、不明ステータスです。サンドボックスシミュレーターに一覧があります。いずれもリスクによる拒否のコードを生成せず、認証チャレンジを強制することもできません。 代わりにできること、そしてすべきこと：- トリガーではなく処理の方を試してください。 拒否された注文と認証が必要な注文に対する貴社のコードパスは、どの理由で生じたかに関わらず同じなので、失敗と認証ステップをシミュレートして処理を検証してください。
- リハーサルができない以上、本番では初日からリスクコードを防御的に処理してください。