> ## 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.

# 失敗したカード取引への課金

> 成功しなかったカード決済が精算請求に現れうる理由：どの失敗ステージが課金対象か、Event Type 列の仕組み、失敗行に注文金額がない理由、Merchant Portal でこれらの取引を見つけてエクスポートする方法。

多くのマーチャントは、\*「失敗した取引の手数料が請求に載っている」\*で始まるサポートチケットを通じてこのトピックに
出会います。これは一部の契約では想定された動作であり、このページではいつ、どのように発生するかを説明します。

精算行の各金額がどのように計算されるかは
[精算計算の解説](/docs/ja/support/settlement-calculation-explained)を参照してください。
レポート自体については
[精算レポートとエクスポート](/docs/ja/support/settlement-reports-faq)を参照してください。

## 失敗したカード取引に対して課金されることはありますか？

はい。該当する失敗に対して貴社の契約に手数料が設定されている場合です。

失敗した取引への課金は**契約ごと・決済手段ごとの設定**であり、プラットフォーム全体のポリシーではありません。
Waffo は精算時に、特定の失敗ステージに対する手数料を貴社の契約に照らして検索します。

* **手数料が設定されている** → 失敗した試行は精算に入り、課金されます。
* **手数料が設定されていない** → 何も作成されず、何も課金されません。その取引は精算行として現れることはありません。

したがって、2 つのマーチャントがまったく同じ失敗取引を持っていても、一方にだけ請求が表示されることがあります。
どちらが貴社に当たるか分からない場合は、精算明細に `Event Type`（下記参照）を持つ行があるかどうかを確認してください。
なければ、失敗に対して課金されていません。

手数料の設定にかかわらず、さらに 2 つの範囲制限が適用されます。

| 制限 | 詳細 |
| - | - |
| 取引タイプ | `PAYMENT` 取引のみ。返金とチャージバックには失敗ステージの課金はありません。 |
| 失敗の発生場所 | **決済ネットワークとのやり取り**で発生した失敗のみ。ネットワークに到達する前に Waffo 自身のバリデーションで拒否されたリクエストは課金対象ではなく、失敗ステージも持ちません。 |

## どの失敗ステージが課金対象で、その違いは何ですか？

ちょうど 2 つあります。

| ステージ | 何が失敗したか | 典型的なケース |
| - | - | - |
| `AUTHENTICATION_FAILURE` | カード保有者認証のステップ | 3-D Secure が完了しなかった、または一致しなかった |
| `AUTHORIZATION_FAILURE` | 認証通過後のオーソリのステップ | カードが拒否された、期限切れだった、または試行がエラーになった |

これらは契約上、別々の手数料項目です。一方だけが課金され、他方は課金されないこともあり、金額も異なりえます。
この区別は商業的に重要です。2 つのステージは上流で異なるコストを伴うためです。認証失敗はオーソリ失敗より
早い段階で止まります。

順序の含意に注意してください。オーソリに失敗した試行はすでに認証を正常に通過しているため、`AUTHORIZATION_FAILURE`
としてのみ課金されます。1 回の試行が 2 つの失敗手数料を生むことはありません。

## どの取引が失敗として課金されたかを見分けるにはどうすればよいですか？

**`Event Type`** 列で見分けます。`Transaction Type` の直後にあり、精算明細エクスポート、精算見積エクスポート、
Portal の一覧に表示されます。

| `Event Type` の値 | 意味 |
| - | - |
| `PAY_SUCCESS` | 通常の成功した決済 |
| `AUTHENTICATION_FAILURE` | 認証ステージでの課金対象の失敗 |
| `AUTHORIZATION_FAILURE` | オーソリステージでの課金対象の失敗 |

この列でフィルターまたは並べ替えれば、その期間の失敗課金取引の完全なリストが得られます。別途リクエストするレポートはありません。

## 失敗行に注文金額がないのはなぜですか？

注文がなかったからです。何も回収されていないため、報告する金額はありません。金額を報告すれば、動いていない資金を
示唆することになります。

`Event Type` が `AUTHENTICATION_FAILURE` または `AUTHORIZATION_FAILURE` の行では、次の 3 列は**意図的に空白**です。

* `Order Amount`
* `Order Currency`
* `Order Amount (Settlement Currency)`

その行が*持っている*のは手数料側です。

| レポート | 失敗行で値が入る列 |
| - | - |
| 精算明細 | `Fee Amount`、`Fee Currency`、`Fee Amount (Settlement Currency)`、`Settlement Amount` |
| 精算見積 | `Est Fee Amount`、`Est. Tax Amount`、`Tax Currency`、`Est Settlement Amount` |

したがって、そのような行の `Settlement Amount` は**負**です。相殺する注文金額のない手数料だからです。これは正しい
読み方であり、データエラーではありません。また、精算期間の純額が成功決済の合計から想定されるより低くなる理由の 1 つです。

`Order Amount` を合計して `Settlement Amount` と比較する方法で照合すると、失敗行は説明のつかない差額のように見えます。
手数料列も合計して照合してください。

## 失敗手数料は何かに対する割合ですか？

いいえ。失敗手数料は**固定金額**です。割合を適用する注文金額がありません。

このことから 1 つの制約が導かれ、時に人々を驚かせます。失敗手数料の通貨は、その決済手段における**貴社の決済手数料の
通貨と同じでなければなりません**。失敗手数料は、隣り合う成功決済の手数料と異なる通貨で課金することはできません。

## 顧客がリトライして最終的に決済が成功しました。失敗分も課金されたのですか？

各**試行**は個別に記録され、評価されます。失敗した試行の後に成功した決済は、成功した試行に対する成功決済行を生み、
貴社の契約がその失敗ステージに価格を設定している場合は、失敗した各試行に対する失敗行も生みます。

したがって答えは契約次第ですが、構造は明確です。最終的な成功が以前の失敗を遡って取り消すことはありません。
それらは同じ注文上の別々のイベントであり、それぞれ独自のシーケンス番号を持ち、注文単位ではなく試行単位で重複排除されます。

これが想定外の失敗手数料合計の最大の要因です。素早い再試行を促すチェックアウトフローや、短時間に複数の試行を発火する
カード保存型のリトライスケジュールは、1 件の最終的な売上に対する失敗回数を増やします。失敗課金が貴社に適用される場合、
リトライのコストはゼロではなく、リトライ戦略は純粋なコンバージョンの判断ではなく商業的な判断になります。

## 精算日より前に失敗手数料を確認できますか？

はい。**精算見積**データで確認できます。同じ `Event Type` 列があります。失敗した試行は取り込まれるとすぐに見積手数料
とともにそこに現れるため、精算日に発見するのではなく、事前に計上できます。

同じ金額抑制ルールが適用されます。失敗した試行の見積行には注文金額がなく、`Est Fee Amount`、`Est. Tax Amount`、
`Tax Currency`、`Est Settlement Amount` のみが表示されます。見積エクスポートの制限と数値の見積方法は
[手数料と税の取り扱い](/docs/ja/support/fee-and-tax-treatment-faq)を参照してください。

## 失敗手数料を減らすにはどうすればよいですか？

失敗手数料は試行回数によって決まるため、レバーはすべて Waffo の上流にあります。

| レバー | 効果がある理由 |
| - | - |
| 送信前にカードを検証する | クライアント側で捕捉されたカード番号、有効期限、CVV の形式エラーはネットワークに到達しないため、課金対象になりません |
| 注文ごとの再試行回数に上限を設ける | 各試行は個別に課金対象となるため、無制限の「再試行」ボタンは 1 件の失われた売上を複数の手数料に変えます |
| 保存済みカードへのリトライ間隔を空ける | 直前に拒否されたカードへの即時再試行で結果が変わることはまれで、その 1 回ずつがカウントされます |
| 特に認証失敗率を監視する | `AUTHENTICATION_FAILURE` の割合が高い場合、真の拒否ではなく、修正可能な連携またはユーザー体験の問題を示していることが多いです |

上記の `Event Type` の内訳を使って、2 つのステージのどちらが支配的かを確認してください。両者は原因も対処法も異なり、
その比率は通常偏っています。

## Merchant Portal のどこでこれらの取引を見つけられますか？

**Settlements → Settleable Transactions** です。精算可能取引を個別取引レベルで一覧表示し、失敗課金分も含まれます。
「何に対して請求されているのか」という問いの実務上の出発点です。

利用できるフィルター：

| フィルター | 備考 |
| - | - |
| Order Id / Merchant Order Id / Payment Request Id / Merchant User Id | 複合検索 — 識別子のタイプを選び、値を入力 |
| Sub Merchant Id | サブマーチャントがある場合のみ表示 |
| Order Currency | |
| Transaction Type | `PAYMENT` / `REFUND` / `CHARGEBACK` / `CHARGEBACK_ALERT` |
| Settlement Status | `UNSETTLED` / `SETTLED` |
| **Event Type** | `PAY_SUCCESS` / `AUTHENTICATION_FAILURE` / `AUTHORIZATION_FAILURE` |
| **Payment Date** | 日付範囲。**上限 31 日** — ピッカーではそれより広い範囲を選択できません |

`Sub Merchant Id` は結果テーブルの最初の列でもあります。

一覧は**エクスポート**に対応しています。エクスポートされたファイルは一覧と同じフィールドレイアウトに従い、
完成したファイルは即時ダウンロードされるのではなく同じページのダウンロード一覧に表示されます。エクスポートタスクの
動作は[エクスポートとレポートのダウンロード](/docs/ja/support/export-center-faq)を参照してください。

## 決済 API で失敗ステージを取得できますか？

専用のフィールドとしては取得できません。注文 API は失敗した注文に対して `orderFailedReason` を返し、*なぜ*失敗したかを
教えてくれますが、認証とオーソリを区別するステージのマーカーは別途返しません。

ステージが見えるのは**下流の精算データ**です。上記のレポートと Portal 一覧の `Event Type` 列として表示されます。
照合で失敗手数料を特定の試行に帰属させる必要がある場合は、決済レスポンスにステージがあることを期待するのではなく、
精算明細の注文識別子で結合してください。

## 取引一覧では失敗が見えるのに精算には何もありません。何か欠けているのですか？

いいえ。その失敗が貴社に課金されない場合には、それが想定される結果です。取引一覧と精算データは異なる問いに答えています。

| 見る場所 | 表示されるもの |
| - | - |
| 取引一覧 | 成功・失敗を問わずすべての試行。活動の記録だから |
| 精算データ | 資金に影響するもののみ — 成功した取引と、**貴社の契約が価格を設定した**失敗 |

したがって、取引一覧に見えて精算にない失敗は、次の 3 つのいずれかを意味し、いずれも正常です。

1. 貴社の契約で、そのステージと決済手段に対する**失敗手数料が設定されていない**。何も課金されないため、何も作成されない。
2. **その失敗がネットワークとのやり取りでの失敗ではなかった** — ネットワークに到達する前にバリデーションで拒否され、
   失敗ステージを持たない。
3. **その取引がまだ精算に取り込まれていない。** 存在しないと結論する前に、精算見積データを確認してください。

その逆、つまり取引一覧に見つからない精算行は、提起する価値のある真の不一致です。精算行のない失敗はそうではありません。

## 失敗した取引は手数料以外に何かに影響しますか？

手数料行のみです。失敗課金された試行は：

* 注文金額を作成しないため、`Order Amount` の合計には入りません。
* 注文金額に対する決済手数料、VAT、WHT を作成しません。失敗手数料が請求のすべてです。
* 上記のとおり、精算金額にマイナスとして寄与します。
* 他の精算可能取引と同様に、取引日に対応する通常の精算日に精算されます。


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