> ## Documentation Index
> Fetch the complete documentation index at: https://waffo.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# リスクによる拒否と 3D Secure

> リスクによる拒否が返すもの、決済手段による拒否との見分け方、3D Secure を強制または省略できるか、貴社の指定が無視される場面、チャレンジが購入者にどう届くか、Portal で拒否・チャージバック・不正率について何が見られるかを説明します。

リスク審査は貴社の注文リクエストと決済手段の間に位置し、3 か所に現れます。レスポンス上のコード、購入者に対する認証ステップ、そして Portal 上の数値です。このページはその 3 つすべてを扱います。コードの全一覧は[エラーコード](/docs/ja/developer-docs/tools-and-references/developer-tools/error-codes)を、どのコードがどの*限度額*に対応するかは[エラーコードと限度額の補足](/docs/ja/support/error-codes-and-limits-supplement)を参照してください。

## リスクによって決済が拒否されたとき、API は何を返しますか？

2 つのコードがあり、どちらも注文リクエスト自体に対して HTTP `406` で返されます。

| コード | 意味 |
| - | - |
| `D0001` | リスクによる拒否 |
| `D0002` | リスクの取引限度額 |

これらはリスクの判断が直接表面化したものです。どちらもその注文については**最終**として扱ってください。再試行可能な通信障害でもなければ、待てば処理される審査キューでもなく、拒否です。`D0001` は Payout、カード、ポイントチャージの各面にも同じ意味で存在するため、1 つのハンドラーでカバーできます。`D0002` は Payin の面に属します。

## コード上でリスクによる拒否と決済手段による拒否をどう見分けますか？

どの面を読んでいるかによります。そしてここが人を引っかける部分です。

| どこで読むか | 見分けられるか |
| - | - |
| 注文作成に対する**同期レスポンス** | **はい。** リスクは `D0001` / `D0002`（HTTP 406）、決済チャネルの拒否は独自のコードと HTTP ステータスを持ちます |
| **注文照会**と**決済通知** | **コードだけでは不可。** リスクによる拒否と、決済手段が報告したリスクによる拒否は同じ汎用の失敗コードで報告され、付随する説明だけが両者を区別します |

具体的には、非同期の面では失敗は `orderFailedReason` として届きます。これは `orderFailedCode` と `orderFailedDescription` を持つ JSON の値です。`orderFailedCode` は**カテゴリ**であり、同期レスポンスで見た固有のコードではありません。また `orderStatus` は通常のクローズ済み注文のステータスであり、リスク専用の注文ステータスは存在しません。

実務上の 2 つのルールが導かれます。

1. **同期コードが得られたときは記録してください。** 区別が機械可読なのはそこだけです。貴社の注文に紐付けて永続化してください。
2. **説明の文字列で分岐しないでください。** これはサポートチケットを読む人間向けの自由記述であり、安定したインターフェースではありません。

リダイレクトはどちらの方向にも証拠になりません。権威のある結果は通知または注文照会です。[決済結果](/docs/ja/support/payment-results-faq)を参照してください。

## 限度額により決済が拒否されました。どの限度額ですか？変更できますか？

限度額はいくつかの場所に由来し、上記のリスクコードとは**異なるコード**を使います。

| コード | 限度額 |
| - | - |
| `A0005` | 加盟店の限度額を超過 |
| `A0008` | 決済金額が許可された範囲の外 |
| `A0020` | 決済金額が 1 回あたりの限度額を超過 |
| `A0021` | 累計金額が 1 日の限度額を超過 |
| `B0002` | ユーザーの限度額を超過 |
| `D0002` | リスクの取引限度額 — 上記のいずれでもなく、リスクの判断 |

これらのうち貴社が影響を与えられるもの、1 日の金額の数え方、枠がいつ解放されるかは、[エラーコードと限度額の補足](/docs/ja/support/error-codes-and-limits-supplement)と[Payin 契約と限度額](/docs/ja/support/payin-agreements-and-limits-faq)で扱っています。要約すると、金額の範囲と上限は貴社アカウントの設定に由来するため、変更するのは Portal の設定ではなく相談事項です。ただし 1 つ例外があります（下記）。

## カードごと、ユーザーごとの制限を自分で設定できますか？

はい。取引限度額ルール API を通じてできます。これが貴社自身で操作できる唯一のリスク関連の制御です。API 専用で、Portal の画面はありません。エンドポイント、リクエストの形、ルールが何をキーにできるか、ルールの読み取りや停止の方法は[取引限度額ルール](/docs/ja/support/transaction-limit-api-faq)にあります。

ルールを有効にする前に知っておくべきことが 3 つあります。

* **ルールが発動すると、決済はリスクの判断として拒否されます。** 購入者の決済は「貴社のルールが発動した」という独自のコードではなく、上記のリスクコードで失敗します。したがって非同期の面では、拒否を自社のルールに帰属させることはできません。何を制限したかは自社で記録しておいてください。
* **ルールはすでに存在する注文にも影響し得ます。** リスクは注文を作成した時点ではなく、購入者が実際に支払う時点で照会されます。したがって、ルールを有効にする前に作成され、その後に支払われた注文はそのルールで評価されます。すでに成功した決済のみが影響を受けません。
* **制限を加えることしかできません。** カードやユーザーを審査から除外するルールの方向は存在しません。

## 3D Secure はいつ発生しますか？貴社側で決められますか？

カード情報内の `threeDsDecision` を使って、注文に希望を表明できます。

| 値 | 貴社の指定 |
| - | - |
| `3DS_FORCE` | この決済を 3D Secure に通す |
| `NO_3DS` | この決済では 3D Secure を省略する |

それ以外の値は無効なカード情報として拒否されます。ただしこのフィールドは**スイッチではなく希望**であり、その上位に 3 つのものがあります。

1. **リスクの判断。** 貴社の値はリスクへの入力の 1 つであり、実際に使われる判断を返すのはリスクです。
2. **決済手段にできること。** 判断は、決済が通る経路で満たせるものでなければなりません。何も満たせない場合、注文は静かに格下げされるのではなく失敗します。
3. **イシュアー。** 3D Secure の決済であっても、購入者が*チャレンジ*を受けるか、操作なしで通過するかを決めるのはイシュアーであり、Waffo でも貴社でもありません。

したがって `3DS_FORCE` は「これを省略しないでください」、`NO_3DS` は「許されるなら省略してください」と読むのが最も適切です。

## `NO_3DS` を送ったのに購入者が認証を求められました。送り方が間違っていたのですか？

おそらく違います。上記の順序を踏まえると、リスクの判断または決済経路が認証を必要としたために、認証ステップが現れることがあります。このフィールドは検証されるため、本当に不正な値であれば無視されるのではなく、無効なカード情報のエラーでリクエストが失敗していたはずです。注文が受理されたのであれば、値は理解されています。

もう 1 つ除外すべきケースは適用範囲です。このフィールドが効果を持つのは、購入者が同席している**カード、Apple Pay、Google Pay** の決済のみです。それ以外の決済手段では何もしません。

## サブスクリプションの更新など、加盟店起点の課金に 3D Secure の指定を設定できますか？

いいえ。そしてこれが「無視されているように見える」理由です。この値は加盟店起点のカード取引に対して**受理・検証されますが適用されません**。サブスクリプションの更新は加盟店起点なので、そこに `threeDsDecision` を設定しても効果はなく、エラーも発生しません。

継続課金の一連の取引における認証が行われるのは、購入者が同席している時点、つまり最初の決済かマンデートの設定時です。[サブスクリプション](/docs/ja/support/subscription-faq)と[トークン化](/docs/ja/developer-docs/integration/tokenization/overview)を参照してください。

## チャレンジは購入者にどのように届きますか？自社フロントエンドで何を処理する必要がありますか？

追加のステップが必要になると、注文は「認証が必要」を意味するステータスと、購入者をどこへ送るかを記述した `orderAction` とともに返ってきます。

| `actionType` | 何をするか |
| - | - |
| `WEB` | 購入者を `webUrl` へ送る |
| `DEEPLINK` | 購入者を `deeplinkUrl` へ送る |

Waffo がホストするチェックアウトを使う場合は自動的に処理され、購入者は認証ページへ送られて戻ってきます。自社でフロントエンドを構築する場合は次を行う必要があります。

1. 作成レスポンス（および照会）で認証が必要なステータスを検出する。
2. `orderAction` をパースし、`actionType` で分岐する。
3. **ページ全体**の遷移を行う。小さなフレーム内で試みないでください。認証ページはフレーム内での描画を拒否することが多く、購入者は空の枠を見つめることになります。
4. 戻ってきたとき、戻ってきたこと自体を結果として扱わないでください。注文照会をポーリングするか、決済通知を待ってください。

アクションのエンベロープ（コード、QR、銀行情報が必要な決済手段のために `actionData` が他に何を運べるかを含む）は、[注文作成フィールドガイド](/docs/ja/support/order-create-field-guide)と[リダイレクトとアクションタイプ](/docs/ja/support/cashier-redirect-and-action-type-faq)にあります。

## リスクはすべての取引でリアルタイムに評価されますか？

はい。評価は**決済リクエストの内部**で、決済が試みられる前に行われ、結果はその注文に即座に適用されます。バッチ処理はなく、すでに通過した決済を後から再スコアリングすることもありません。

これは一見矛盾して見えるパターンも説明します。ある購入者の最初の決済が成功し、2 回目が拒否されるのはまったく正常です。各決済はそれ自体の文脈（金額、決済手段、履歴、その間に何が起きたか）で個別に評価されるため、同じ人の数分違いの 2 件の決済で結果が異なり得ます。

## リスクで拒否された取引は Portal のどこで見られますか？

カテゴリとしてではなく、注文ごとに見られます。

| 画面 | 得られるもの |
| - | - |
| Payments 一覧 | 注文とそのステータス。**失敗理由のフィルターはありません** — 「リスクで拒否されたすべて」を一覧にすることはできません |
| Payment の詳細 | その注文の `Order Failure Code` と `Order Failure Description` |
| Payments Analytics → failure analysis | カテゴリと説明で**グループ化・集計された**拒否 |

したがってワークフローは、failure analysis で件数を把握し、その後は自社の記録から個別の注文を引き出す、という流れになります。Payments 一覧が提供するフィルターは[Portal の一覧フィルターと期間指定](/docs/ja/support/portal-list-filters-and-date-ranges-faq)にあります。

## failure analysis は何を教えてくれますか？注文まで掘り下げられますか？

**何件**と**なぜ**を、次のようにグループ化して教えてくれます。決済手段側に起因する失敗、顧客側に起因する失敗、貴社側に起因する失敗で、それぞれが個別の失敗説明とその件数・割合に展開されます。

注文までは**掘り下げられません**。このパネルの背後にあるリクエストは、プロダクト、サブスクリプションの段階、国、決済手段、期間でパラメータ化されており、注文でパラメータ化されることはありません。またレスポンスは注文の識別子ではなく件数を含みます。失敗理由をフィルターとして Payments 一覧に持ち込むリンクもありません。

このパネルが何を数えているか、なぜ分析の数値が一覧の件数と厳密に一致しないかは、[Portal のダッシュボードと分析](/docs/ja/support/portal-analytics-faq)にあります。

## 拒否された取引は成功率に算入されますか？

はい。成功率は**成功した注文÷作成された注文**であるため、作成された後に拒否された注文は、理由がリスクを含め何であれ分母に残ります。Portal はこれと並んで、より狭い 2 つの比率も表示します。作成された注文のうち決済ステップに到達した割合と、そのうち成功した割合です。

リスクによる拒否は決済ステップで発生するため、全体の比率だけでなく、狭い方の比率の分母にも入ります。実務上の帰結：注文を作成する前にトラフィックを事前選別すれば比率は改善しますが、作成した後に拒否しても改善しません。

## 自社のチャージバック率と不正報告率を確認できますか？

はい。Chargeback Analytics で確認できます。そこでは 1 つの合成値ではなく**カードスキームごと**に報告されます。スキームによって定義が異なるためです。

| 指標 | 構成 |
| - | - |
| チャージバック率（一方のスキーム） | 期間内に受領した不正報告とチャージバックの合計を、期間内の成功決済で割ったもの |
| 不正率（そのスキーム） | 期間内に受領した不正報告に、**そのスキームの不正理由コードを持つチャージバック**を加えたものを、期間内の成功決済で割ったもの |
| チャージバック率（もう一方のスキーム） | 期間内のファーストチャージバックを、期間内の成功決済で割ったもの |
| 不正率（そのスキーム） | 不正報告を成功決済で割ったもの |

どちらの分子も「期間内に**受領**したもの」であり、「期間内に行われた決済に属するもの」ではないことに注意してください。チャージバックは決済から数か月後に届くため、この比率はコホートの指標ではなく期間の指標です。この画面ではチャージバックの件数と金額、トレンド、理由コードの分布、期限が近づいているケースも確認できます。データは 1 日遅れで、選択できる期間には上限があります。

各比率のカードが何を測っているか、どの期間を報告しているかも[Portal のダッシュボードと分析](/docs/ja/support/portal-analytics-faq)にあります。ケースへの対処は[チャージバック](/docs/ja/support/chargeback-faq)と[チャージバックの証拠](/docs/ja/support/chargeback-evidence-guide)にあります。

## 不正報告はチャージバックと同じものですか？別々に照会できますか？

同じものではありません。不正報告は、イシュアーがスキームに対して取引が不正であったと伝えるものであり、チャージバックが後続しないまま届くこともあります。だからこそ上記で独自の比率として現れるのです。

個々の不正報告は、Reported Fraud 一覧 API（`/api/v1/fraud-report/list`、報告日、スキーム、または単一の注文でフィルタ）を通じて**別々に照会できます**。Portal にはそのための一覧ページはなく、Chargeback Analytics 内の集計のみが表示されます。フィールドごとの内容は[理由コードと Reported Fraud](/docs/ja/support/chargeback-reason-codes-and-reported-fraud)を参照してください。

## 決済が拒否されましたが、そうあるべきではないと思います。異議申し立てやカードの許可リスト登録はできますか？

どちらについても**セルフサービスの仕組みはありません**。異議申し立てのエンドポイントも、カード・購入者・範囲に対する許可リストや除外もなく、そのための Portal の画面もありません。加盟店が操作できる唯一のリスク制御は限度額ルール API であり、それは制限を加えることしかできません。

したがって経路は、注文の識別子を添えてサポート担当に連絡することです。決済を再試行のループとして組み直さないでください。拒否された決済手段への繰り返しの試行は、それ自体がリスクのシグナルです。

IP 許可リストは別の機能であり、こちらは*セルフサービスです*。これは貴社のどのサーバーが API を呼べるかを制限するもので、購入者の審査とは関係ありません。[Portal のセルフサービスセキュリティ設定](/docs/ja/support/portal-security-config-faq)を参照してください。

## サンドボックスでリスクによる拒否や 3D Secure のチャレンジをテストできますか？

直接はできません。サンドボックスのシミュレーターは**注文金額**で結果を制御し、生成できる結果は、作成・キャンセル・返金の各パスにおける決済失敗、システムエラー、不明ステータスです。[サンドボックスシミュレーター](/docs/ja/developer-docs/tools-and-references/developer-tools/sandbox-simulator)に一覧があります。いずれもリスクによる拒否のコードを生成せず、認証チャレンジを強制することもできません。

代わりにできること、そしてすべきこと：

* **トリガーではなく処理の方を試してください。** 拒否された注文と認証が必要な注文に対する貴社のコードパスは、どの理由で生じたかに関わらず同じなので、失敗と認証ステップをシミュレートして処理を検証してください。
* リハーサルができない以上、**本番では初日からリスクコードを防御的に処理してください**。

本番稼働前に特定の分岐を再現する必要がある場合は、それを引き起こす金額を探すのではなく、連携サポートに依頼してください。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.