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

# チャージバック項目リファレンス

> 加盟店 Portal と精算ステートメントでチャージバックを読み解くための項目辞書：4 種類の CHARGEBACK Event Type とその符号、Compulsory Channel Review フラグ、顧客の異議申し立てとチャージバックのタイムラインの全イベント、未読カウンターを動かすイベント、チャージバック CSV エクスポートの 26 列、Dispute Amount の算出方法、チャージバック手数料の通貨、日次異議申し立てレポートの Alert Status の値。

このページは
[チャージバック・異議申し立て FAQ](/docs/ja/support/chargeback-faq) の背後にある項目辞書です。プロセスの仕組みや対応方法についてはそちらのページを、Portal、CSV、または精算行に表示された値を見てその意味を知りたいときはこのページをご利用ください。証拠の選び方は
[チャージバック証拠ガイド](/docs/ja/support/chargeback-evidence-guide) にあります。

## 精算明細に `CHARGEBACK` の行があります。Event Type にはどのような種類があり、資金はどちらの方向に動きますか？

チャージバックによる資金移動では、`Transaction Type` は常に `CHARGEBACK` です。その行が引き落としなのか返還なのか、また金額・手数料のどちら（または両方）を含むのかは、**`Event Type`**
列で判断します。

| `Event Type` | 発生要因 | 行の注文金額 | 行の手数料 | 精算金額 |
| - | - | - | - | - |
| `FIRST_CB_PRE_DEDUCT` | 貴社に対して第 1 サイクルのチャージバックが開始された | 争議対象金額 | チャージバック手数料 | **マイナス** — `−(amount + fee)` |
| `FIRST_CB_AMOUNT_REFUND` | 第 1 サイクルが貴社有利で終了した | 争議対象金額 | ゼロ | **プラス** — `+amount` |
| `SECOND_CB_PRE_DEDUCT` | 第 2 サイクル（Pre-Arbitration）が開始された | **ゼロ** — 金額の 2 回目の引き落としはなし | チャージバック手数料 | **マイナス** — `−fee` のみ |
| `SECOND_CB_AMOUNT_REFUND` | 第 2 サイクルが貴社有利で終了した | 争議対象金額 | ゼロ | **プラス** — `+amount` |

金額ではなくパターンで読むのが確実な方法です。
`*_PRE_DEDUCT` は常に資金を引き落とし、`*_AMOUNT_REFUND` は常に資金を返還し、手数料が現れるのは `PRE_DEDUCT` 行のみです。したがって、開始・エスカレーション・最終的な勝訴に至ったケースは、異なる精算日にまたがって 3 行または 4 行の個別の `CHARGEBACK` 行を生成します。1 行にネットされることはありません。

どのケースステータスがどのイベントを生成するか：

| 精算イベント発生時のケースステータス | Event Type |
| - | - |
| `ACTION_REQUIRED`、`EVIDENCE_REQUIRED`、`UNDER_REVIEW`、`SECOND_CYCLE_RESPONSE_REQUIRED` | 該当サイクルの `PRE_DEDUCT` |
| `CASE_WON`、`SETTLED`、`CANCELED` | 該当サイクルの `AMOUNT_REFUND` |
| `CASE_LOST` | `PRE_DEDUCT` — 金額はカード保有者側に残り、何も返還されません |

`CASE_LOST` の場合の帰結に注意してください。独立した「敗訴」イベントは存在しません。ケース開始時点で既に引き落とされているため、敗訴しても新しい行は生成されません。`AMOUNT_REFUND` 行が存在しないこと*そのもの*が敗訴を意味します。タイミングと精算日のルールは
[チャージバック・異議申し立て FAQ](/docs/ja/support/chargeback-faq) をご覧ください。

古いレコードでは `Event Type` が空欄の場合があります。これらはこの内訳が導入される前のもので、常に引き落としです。

## チャージバック詳細ページの `Compulsory Channel Review` とは何ですか？

`compulsoryChannelReview` は、ケースに付与され Portal に返される true/false のフラグで、決済側がそのケースについて独自の審査を必須としているかどうかを記録します。チャージバックは **true** で作成され、アプリ内の申し立てフローを通じて提起された顧客の異議申し立ては **false** で作成されます。

これは結果に対する期待値を設定するものとして読んでください。true の場合、ケースは審査側が判断し、貴社の提出物はその審査へのインプットであって、ケースの解決そのものではありません。false の場合、顧客と直接ケースを解決することが現実的な選択肢となり、異議申し立てをクローズすることでその解決が記録されます。

**Close** アクションを実際に制御するのは、このフラグではなくケースステータスです。クローズは `EVIDENCE_REQUIRED`、`ACTION_REQUIRED`、`UNDER_REVIEW` から可能で、`ESCALATED` のケースはクローズできません。Close がグレーアウトしている場合は、まずステータスを確認してください。

## 顧客の異議申し立てのタイムラインにある各イベントは何を意味しますか？

タイムラインには 11 種類のイベント値が記録されます。この一覧にないものはタイムラインイベントではありません。

| イベント | 表示されるタイミング | 貴社の対応 |
| - | - | - |
| `CREATE_DISPUTE` | 決済に対して異議申し立てが開始された | 理由を読み、抗弁するか、返信するか、返金するかを判断する |
| `MERCHANT_SUBMIT_EVIDENCE` | 貴社の証拠提出が受理され、ケースが `UNDER_REVIEW` に移行した | 何もしない — 審査を待つ |
| `MORE_EVIDENCE_REQUIRED` | 追加資料が求められ、ケースが `EVIDENCE_REQUIRED` に戻った | 追加資料をアップロードする |
| `DISPUTE_ESCALATED` | 同じ決済に対してチャージバックが提起され、このレコードの進行が停止した | 代わりにリンクされたチャージバックを対応する |
| `CLOSE_DISPUTE` | ケースがクローズされた — 貴社または審査側による | 顧客が再度申し立てない限り、何もしない |
| `NOTIFY_OVERDUE` | ケースが証拠提出期限の接近としてフラグ付けされた | 期限前に提出する |
| `EXPIRED` | 証拠提出期限が経過した | ケースは**まだ対応可能** — 下記の期限切れに関する質問を参照 |
| `USER_RESPONSE` | 顧客が異議申し立ての会話で返信した | 読む。有用であれば返信する |
| `PLATFORM_RESPONSE` | 審査側から応答が届いた | 読む。不足している内容が明記されていることが多い |
| `MERCHANT_RESPONSE` | 貴社自身の返信が投稿された | 何もしない |
| `USER_CREATE_COMPLAINT` | 顧客がさらに申し立てを行った — これが `CLOSED` のケースを再開する要因 | 対応する。ケースはオープン状態に戻る |

## チャージバックのタイムラインにある各イベントは何を意味しますか？

14 種類のイベント値があり、顧客の異議申し立てとは異なるセットです。

| イベント | 表示されるタイミング | 貴社の対応 |
| - | - | - |
| `CREATE_DISPUTE` | チャージバックが作成された | `reasonCode`、`reason`、`expiryDateTime` を読み、抗弁か受諾かを判断する |
| `MERCHANT_SUBMITS_EVIDENCE` | 貴社の証拠提出が受理された | 待つ |
| `AUTO_SUBMITS_EVIDENCE` | 設定済みの処理戦略に基づき、貴社に代わって証拠が自動提出された | 提出内容を確認する — 貴社が抗弁したと記録されている |
| `MORE_EVIDENCE_REQUIRED` | 審査後に追加資料が求められた | 期限前にアップロードする |
| `NOTIFY_OVERDUE` | ケースが期限の接近としてフラグ付けされた | 提出または受諾する |
| `MERCHANT_ACCEPTED_DISPUTE` | 貴社がケースを受諾した | 何もしない — これは取り消せない |
| `MERCHANT_WON_DISPUTE` | 貴社有利の裁定 | `AMOUNT_REFUND` の精算行を待つ |
| `MERCHANT_LOST_DISPUTE` | 貴社不利の裁定 | このサイクルではこれ以上何もない。第 2 サイクルが続く場合がある |
| `CHARGEBACK_SETTLED` | ケースが通常フロー外で解決された | 金額は返還、手数料は保持 |
| `CHANNEL_CLOSE_DISPUTE` | 提起側でケースが撤回された | 金額は返還、手数料は保持 |
| `CHARGEBACK_EXPIRED` | 期限までに応答がなかった | 何もしない — 金額は返還されない |
| `ESCALATED_TO_2ND_CYCLE` | ケースが Pre-Arbitration にエスカレーションされた | 新しい第 2 サイクルのレコードが存在する。そちらを対応する |
| `CREATE_SECOND_CYCLE_DISPUTE` | 第 2 サイクルのレコードが作成された | 抗弁または受諾する。第 2 サイクルでは**証拠ファイルは受け付けられない** |
| `MERCHANT_DEFENDS_SECOND_CYCLE` | 貴社が第 2 サイクルの抗弁を選択した | 実行前に仲裁のリスクを理解する |

`AUTO_SUBMITS_EVIDENCE` と `CREATE_SECOND_CYCLE_DISPUTE` は、貴社の操作なしに現れる可能性のある 2 つのイベントです。一括の処理戦略を設定している場合、それが発動したことはここで分かります。

## どのタイムラインイベントが未読カウンターを増やしますか？

ちょうど 3 つで、いずれもステータス変更ではなく受信メッセージです。

* `USER_RESPONSE`
* `PLATFORM_RESPONSE`
* `USER_CREATE_COMPLAINT`

貴社自身の `MERCHANT_RESPONSE` はカウンターを増やさず、ステータス変更、証拠提出、期限イベントのいずれも増やしません。したがって、未読件数は常に*誰かが貴社に何かを伝えた*ことを意味し、*ケースに何かが起きた*ことは意味しません。ケースはカウンターがまったく動かないまま最終ステータスまで進むことがあります。カウンターをアクティビティの指標として使わず、タイムラインを使ってください。

## チャージバック明細をエクスポートするにはどうすればよいですか？Reports タブを経由しますか？

Chargebacks 一覧には独自のエクスポートがあり、ほとんどの Portal エクスポートと異なり**同期的な直接ダウンロード**です。クリックするとファイルがブラウザにストリーミングされ、**どの Reports タブにもタスク行は表示されません**。
[エクスポートとレポートのダウンロード](/docs/ja/support/export-center-faq) で探しても見つかりません。そのページはキュー処理されるエクスポートを扱っており、これはキュー処理されないためです。

ファイル名は次のとおりです。

```
chargebacks_{merchant id}_{from}_{to}.csv
```

両方の日付は UTC+8 の `YYYYMMDD` で、適用していた作成日時フィルターから取られます。エクスポートは現在の一覧フィルターに従うため、先にフィルターし、その後エクスポートしてください。

## チャージバック CSV エクスポートにはどのような列がありますか？

26 列で、順序は次のとおりです。

| # | ヘッダー | 内容 |
| - | - | - |
| 1 | `Chargeback Id` | ケース ID |
| 2 | `Life Cycle` | `FIRST_CYCLE` または `SECOND_CYCLE` |
| 3 | `Relevant Chargeback Id` | もう一方のサイクルのケース ID |
| 4 | `Original Order Id` | 争議対象注文の Waffo 側 ID |
| 5 | `Original Payment Request id` | その注文の貴社側決済リクエスト ID |
| 6 | `Subscription Request` | 貴社側サブスクリプションリクエスト ID（サブスクリプションのケース） |
| 7 | `Related Subscription Id` | Waffo 側サブスクリプション ID（サブスクリプションのケース） |
| 8 | `Merchant User Id` | 購入者の貴社側 ID |
| 9 | `Merchant Order Id` | 貴社の注文 ID |
| 10 | `Merchant Id` | 貴社の MID |
| 11 | `Sub Merchant Id` | サブ MID（使用している場合） |
| 12 | `Chargeback Amount` | **貴社に対して**争議となった金額（注文通貨） — 下記参照 |
| 13 | `Chargeback Currency` | 12 列目の通貨 |
| 14 | `Chargeback Reason Code` | ケースの理由コード |
| 15 | `Chargeback Reason` | 理由テキスト |
| 16 | `Transaction Type` | `CHARGEBACK` |
| 17 | `Country/Region` | 決済の国 |
| 18 | `Payment Method Type` | 例：`CREDITCARD` |
| 19 | `Payment Method` | 使用された具体的な決済手段 |
| 20 | `Chargeback Status` | ケースステータス |
| 21 | `Settlement Status` | 資金移動が精算に反映済みかどうか — 下記参照 |
| 22 | `Created Datetime(UTC+8)` | ケースの作成日時 |
| 23 | `Updated Datetime(UTC+8)` | ケースの最終更新日時 |
| 24 | `Expiry Datetime(UTC+8)` | 証拠提出期限 |
| 25 | `Chargeback Fee Amount` | ケースに計上されたチャージバック手数料 |
| 26 | `Chargeback Fee Currency` | 25 列目の通貨 — 貴社に設定された手数料通貨、下記参照 |

すべてのヘッダーは一意であるため、ヘッダーテキストをキーにするパーサーは安全です。同じ値について、Portal の詳細ページでは **Dispute** と表示されるのに対し、エクスポートでは **Chargeback** と表示される点に注意してください。12 列目と 25 列目はそれぞれ争議対象金額と手数料であり、2 つの金額ではありません。

## 21 列目にケースがまだ精算されていないと表示されています。資金は引き落とされたのですか、それともまだですか？

それこそが `Settlement Status` の目的であり、ケースステータスと銀行残高が一致しないときに確認すべき列です。

`Chargeback Status` と `Settlement Status` は異なる質問に答えるもので、動くタイミングも異なります。

| 列 | 答える質問 |
| - | - |
| `Chargeback Status` | 審査側でケースがどの段階にあるか |
| `Settlement Status` | 結果として生じる資金移動が既に精算を経たかどうか |

チャージバックはケース開始時に貴社に対して計上されますが、精算ステートメントに反映されるのは**元の決済注文が精算された後**です。これは、その注文の精算為替レートを再利用するためです。したがって、ケースが `ACTION_REQUIRED` にあり金額が既に計上されていても、`Settlement Status` は未精算のまま表示されることがあります。引き落としは、元の注文の精算日、またはその後の次の精算日に行われます。特定の `CHARGEBACK` 行を照合するには、この列と上記の `Event Type` 表を組み合わせてください。

## `Dispute Amount` がカード保有者の争議金額と異なるのはなぜですか？

それらは 2 つの異なる数値であり、Portal に表示されているのは貴社側の数値だからです。

決済側で提起された金額は、元の取引の**決済通貨**建てです。貴社に表示される `Dispute Amount`（実際に引き落とされる金額）は、**注文通貨で表した加盟店負担分**です。

1. 元の決済における購入者側の手数料は、貴社ではなく Waffo が負担するもので、貴社の争議対象残高からは除外されます。
2. 争議対象金額のうち貴社の負担分は、購入者が支払った金額に対する貴社の取り分の比率に応じて算出され、残りは Waffo が負担します。
3. その負担分は注文通貨に換算され、\*\*小数第 2 位で切り捨て（FLOOR）\*\*られるため、貴社に不利な方向に切り上げられることはありません。セント未満の端数は Waffo 側に残ります。

知っておくべき帰結：

* 通貨をまたぐ注文では、貴社の `Dispute Amount` は決済側で提示された数値と一致しませんが、その差異はエラーではありません。
* 注文が既に一部または全額返金されている場合、貴社の残りの争議対象残高は低くなり、貴社の負担分はその範囲内に制限されます。
* 貴社の `Dispute Amount` が注文金額を超えることはありません。

比例配分そのもの（特定の争議のうちどれだけが貴社に、どれだけが Waffo に帰属するか）は資金負担ルールであり、セルフサービスの設定ではありません。特定のケースが照合できない場合はサポートにお問い合わせください。

## チャージバック手数料はどの通貨ですか？USD ではありません。

チャージバック手数料の通貨は、グローバルなデフォルトではなく**貴社**の加盟店設定に基づき、ケース上で `feeAmount` と併せて `feeCurrency` として返されます。貴社の精算通貨と一致することも、USD であることも保証されません。

手数料通貨が精算通貨と異なる場合、手数料は精算時に、その精算の精算側レートで精算通貨に換算されます。これはその精算の他の部分と同じレート基準であり、ケース開始日に取得されたレートではありません。2 つの通貨が同じ場合、換算は行われません。

したがって、ステートメントに予期しない通貨のチャージバック手数料が表示されている場合、それは貴社に設定された手数料通貨が現れているものです。手数料の金額自体は契約条件です。
[チャージバック・異議申し立て FAQ](/docs/ja/support/chargeback-faq) をご覧ください。

## 期限が迫っているケースを見つけるにはどうすればよいですか？

Chargebacks と Customer Disputes の両方の一覧に **expiring soon** フィルターがあり、証拠提出期限が今後 **3 日**以内に到来するオープンなケースを返します。これが期限によるトリアージのサポートされた方法です。各ケースには引き続き独自の
`expiryDateTime` があり、個々のケースについてはその値が正となります。

## 証拠提出期限が過ぎるとどうなりますか？

2 つのケースタイプは異なる動作をし、これは両者の間で最も誤読されやすい違いです。

| | 顧客の異議申し立て | チャージバック |
| - | - | - |
| 期限時に変わるもの | 独立した **Expire Status** 列のみが `ACTIVE` から `EXPIRED` に切り替わる | **ケースステータスそのもの**が `EXPIRED` になる |
| 期限後のケースステータス | 変化なし — `EVIDENCE_REQUIRED` / `ACTION_REQUIRED` / `UNDER_REVIEW` のまま | `EXPIRED`（最終ステータス） |
| まだ提出できるか？ | **はい** — ケースは対応可能なまま | いいえ |
| 資金 | 期限切れ自体による影響なし | 争議対象金額は返還されない |

つまり、期限切れの顧客の異議申し立ては閉ざされた扉ではなく、催促にすぎません。遅れて資料を提出し、ケースの対応を続けてください。期限切れのチャージバックは敗訴です。時間的な制約の中でキューの優先順位を付ける際、チャージバックの期限こそが厳格なものです。

各ケースの期限は決済側で設定され、`expiryDateTime` としてケースに届きます。Waffo 全体で単一の期限が存在するわけではなく、取引日から導出されるものでもないため、計算するのではなく常にケースごとに読み取ってください。

## 日次異議申し立てレポートの `Alert Status` の値は何を意味しますか？

Chargeback Alert が有効になっている場合、日次異議申し立てレポートにはアラートの添付ファイルが含まれます。`Alert Status` はアラートケースの全体的な段階です。

| `Alert Status` | 意味 | 貴社の対応が必要か？ |
| - | - | - |
| `PROCESSING` | ケースは処理中 | いいえ |
| `MANUAL PROCESSING` | ケースが例外に該当し、**Waffo 側で**手動対応中 | **いいえ** — 名前に反して |
| `PROCESSED` | 返金が開始され、アラートに応答済み。最終確認はまだ保留中 | いいえ |
| `FAILED` | 最終：ケースを完了できなかった | Waffo から連絡があった場合のみ |
| `EXPIRED` | 最終：受信から 72 時間以内に最終状態に到達しなかった | いいえ |

**`MANUAL PROCESSING` は「貴社による手動処理」を意味しません。** これはこのレポートで最も誤読される値です。Waffo がケースを自動処理の経路から外したことを意味します。貴社からの対応が実際に必要な場合は、直接連絡があります。

添付ファイルはアラートケースの段階とその返金を報告するもので、`MANUAL PROCESSING` のケースの背後にある内部処理ステップは公開しません。したがって、この値から「自動化されておらず、対応中」以上のことを読み取る必要はありません。

## `Refund Status` とは何ですか？Alert ID はどのような形式ですか？

同じ添付ファイル内の `Refund Status` は、アラートがトリガーした返金のみを追跡します。

| `Refund Status` | 意味 |
| - | - |
| `PROCESSING` | 返金は提出済みで、まだ確認されていない |
| `SUCCESS` | 返金が完了した |
| `FAILED` | 返金が完了しなかった |

`FAILED` の返金はアラートが無視されたことを意味しません。まさにそれが手動で取り上げられるケースであり、`MANUAL PROCESSING` と `FAILED` の返金が同じ行に並ぶことが多い理由です。

Alert ID は `CBA-00-20251125-00003` のような形式です。固定の `CBA` プレフィックス、2 桁のセグメント、日付、連番で構成されます。特定のアラートについてサポートに連絡する際は、文字列全体を伝えてください。アラートがサブスクリプションに関連する場合、添付ファイルにはサブスクリプション ID も含まれます。

アラートが注文を返金した後は、その注文に対する貴社自身の返金リクエストは `A0039` で却下されます。その意味とアラート手数料の請求方法については
[チャージバック・異議申し立て FAQ](/docs/ja/support/chargeback-faq) をご覧ください。


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