> ## 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 の決済レコードや返金レコードの各フィールドが実際に何を意味するのか：返金に表示される 2 つの加盟店注文 ID、Initiation Type（CIT/MIT）とそれが通常空である理由、カード情報とカード番号のマスク方法、金額がダッシュで表示される理由、返金ボタンが表示されない・グレーアウトしている理由。

本ページは、Portal 上の 1 件の決済レコードまたは返金レコードについてのフィールドごとのリファレンスです —
各列が何を意味するのか、そして値があるはずなのに空になっている理由を説明します。返金の*ルール*（回数、金額、
異なる通貨間、返却される手数料）は [返金 FAQ](/docs/ja/support/refund-faq)、ダッシュボードの指標は
[Portal ダッシュボードと分析](/docs/ja/support/portal-analytics-faq)、エクスポートしたファイルの取得は
[エクスポートとレポートのダウンロード](/docs/ja/support/export-center-faq) を参照してください。

## 決済にはどの識別子があり、どれを伝えればよいですか？

4 つあり、互いに置き換えることはできません：

| 列 | 誰の識別子か | 用途 |
| - | - | - |
| `Order Id` | Waffo | Waffo サポートに取引を伝える際 — 送るべきはこれです |
| `Merchant Order Id` | お客様 | 自社の注文レコードとの照合 |
| `Payment Request Id` | リクエスト | 注文を作成した特定の試行の追跡 |
| `Merchant User Id` | お客様 | 注文作成時に渡したユーザー参照 |

チケットを起票する際は、`Order Id` を先頭に記載してください。お客様自身の注文 ID はクロスチェックには有用ですが、
プラットフォーム全体で一意ではないため、それだけでは追跡に時間がかかります。

返金には独自の識別子セットがあります — 下記を参照してください。

## 決済にはどのタイムスタンプがあり、なぜ 3 つあるのですか？

| 列 | 示すもの |
| - | - |
| `Created Datetime` | 注文が作成された時刻 |
| `Payment Date` | 決済が帰属する日付 |
| `Payment Time` | 決済自体の時刻 |

これらは意図的に分けられています。深夜 0 時の直前に作成され、直後に支払われた注文は、作成タイムスタンプが
ある日、決済日付が翌日になります。入金との照合には `Payment Date` を、注文件数や上限による拒否の調査には
`Created Datetime` を使用してください — [Payin 契約と取引上限](/docs/ja/support/payin-agreements-and-limits-faq)
で説明しているとおり、日次取引上限は作成時点から数えます。

未設定のタイムスタンプは `-` と表示されるため、未払いの注文は作成時刻が表示され、他の 2 つはダッシュになります。

## 返金に加盟店注文 ID が 2 つ表示されます。どちらがどちらですか？

これらは異なるオブジェクトであり、混同することが最もよくある照合エラーです：

| 列 | 属する対象 | 内容 |
| - | - | - |
| `Merchant Order Id` | **返金** | *お客様が*返金リクエストに割り当てた注文 ID |
| `Merchant Original Order ID` | **元の決済** | 返金対象の決済にお客様が割り当てた注文 ID |

したがって、返金から販売まで遡るには `Merchant Original Order ID` を使用します。お客様自身の返金指示を
追跡するには `Merchant Order Id` を使用します。

`Merchant Original Order ID` は、返金一覧、返金詳細の加盟店情報ブロック、返金エクスポートに表示されます。
値がない場合、Portal は `-` を表示します。

Waffo 側の識別子はそれらと並んで表示されます：返金自体のアクワイアリング注文 ID、返金リクエスト ID、
そして — 返金が一括処理から生じた場合 — `Refund Batch ID`（単独の返金では `-`）です。

## 元の決済の注文 ID で返金を検索できますか？

はい。`merchantOriginalOrderId` は返金一覧の複合検索セレクターのフィールドの 1 つで、前方一致や部分一致ではなく
**完全一致**で照合されます。元の注文 ID を丸ごと貼り付けてください。

何も返されない場合は、返金自体の ID ではなく元の*決済*の ID を検索しているか、値の末尾に空白がないかを
確認してください。

## 返金ボタンが表示されない、またはグレーアウトしているのはなぜですか？

3 つの状態があり、それぞれ意味が異なります：

| 状態 | 意味 |
| - | - |
| ボタンが**表示されない** | この注文は Portal から一切返金できません — ステータスが決済成功ではない、または契約が返金をまったく許可していない |
| ボタンが**グレーアウト** | この種類の注文では返金が可能ですが、この特定の注文は現在条件を満たしていない |
| ボタンが**有効** | 返金できます |

ボタンがグレーアウトしている場合、次の 5 つの条件のいずれかを満たしていません：

| 条件 | ブロックされる理由 |
| - | - |
| 返金の形態がまだ利用可能 | 契約が返金を 1 回のみ、または全額のみ許可している場合 — それが使用済みであれば、これ以上の返金は当てはまりません |
| 返金期間内 | 返金は契約の返金期間内にのみ受け付けられます。注文作成から数え、初日と最終日を含みます |
| 注文に異議申し立てによる保留がない | 異議申し立て中の注文は保留され、Portal から返金できません |
| 最大返金回数未満 | 注文が保持できる返金レコード数には上限があり、成功したものと処理中のものの両方を数えます |
| 残り返金可能額がゼロより大きい | 全額返金済み — または全額返金がまだ処理中 — の場合、返金できるものは残りません |

処理中の返金は最後の 2 つに数えられることに注意してください。数秒前に提出した返金は、すでに枝数と金額の
両方を消費しているため、何も確定していない段階でボタンがグレーアウトすることがあります。

返金パネルと注文詳細のどちらにも `Remaining Refundable Amount` が表示されるため、3 番目の数値を直接確認できます。
どの決済手段が返金に対応しているかは、[Payin 契約ページ](/docs/ja/support/payin-agreements-and-limits-faq)
にあります。

返金権限のないユーザーには、上記にかかわらずボタンは表示されません — [Merchant Portal の操作](/docs/ja/support/portal-operations-faq)
を参照してください。

## Initiation Type 列とは何ですか？

`Initiation Type` は、カード取引を誰がトリガーしたかを分類します：

| 値 | 意味 |
| - | - |
| `CIT` | カード保有者起点 — 初回決済や手動での再購入のように、ユーザーが実際に操作していた |
| `MIT` | 加盟店起点 — サブスクリプションの更新のように、保存済みのオーソリに対してお客様がトリガーした |

これは**取引ごと**の属性であるため、決済一覧に存在し、集計ビューには存在しません。

## Initiation Type が常にダッシュで表示されるのはなぜですか？

値は**それでフィルターしたとき**にのみ設定されるためです。これは仕様であり、データの欠落ではありません：

| 操作 | 列の表示 |
| - | - |
| 決済一覧を通常どおり開く | すべての行で `-` |
| `Initiation Type` = `CIT` でフィルター | 返された行で `CIT` |
| `Initiation Type` = `MIT` でフィルター | 返された行で `MIT` |

つまりこの列は**フィルターの確認**であり、閲覧可能な属性ではありません。内訳を見るには、フィルターなしの一覧を
眺めるのではなく、値ごとに 1 回ずつ計 2 回クエリを実行してください。

またこの列は、サブスクリプションを契約しているアカウントにのみ存在します。この区別が意味を持つのはそこだからです。
一覧にまったく表示されない場合、それが理由です。

## 決済レコードにはどのカード情報が表示されますか？

決済手段がカードの場合、決済詳細の決済情報ブロックに：

| フィールド | 備考 |
| - | - |
| `Cardholder name` | 決済時に提供されたもの |
| `Card number` | マスク済み。カードブランドのロゴ付き |
| `Card expiry date` | 決済時に提供されたもの |
| `Issuing country` | カードの発行国 |
| `Issuing bank` | カードの発行会社 |
| `Order Failure Code` | 失敗した注文のみに表示 |
| `Order Failure Description` | 失敗した注文のみに表示 |

これらの行はいずれも**値がない場合は省略されます** — ブロックは空のラベルを表示しません。
したがって `Issuing bank` の行がないということは、その取引ではそのデータが利用できなかったことを意味し、
フィールドが削除されたわけではありません。カード以外の決済手段ではカード関連の行は一切表示されません。

値はその取引に対して記録されたものです。後から更新されることはないため、同じカードで別の時点に行われた
2 つの取引で値が異なることは正当にあり得ます。

`Cardholder name` はユーザーの個人データです。エクスポートや保存の際はそれに応じた取り扱いをしてください。

## カード番号はどのようにマスクされますか？

**先頭 6 桁、次にアスタリスク、最後に末尾 4 桁** — たとえば 16 桁の番号は、6 桁、6 個のアスタリスク、4 桁で
表示されます。短い値も安全に処理されます：6〜9 文字の値は先頭 6 文字を表示し残りをアスタリスクにします。
それより短いものはそのまま表示されます。

完全な番号は Portal でもエクスポートでも決して取得できず、それを表示する設定もありません。取引をまたいで
カードを照合する必要がある場合は、完全な番号を期待するのではなく、マスク済みの値と有効期限、カードブランドを
組み合わせて使用してください。

## 金額がダッシュで表示されるのはなぜですか？

Portal は、金額の数値と通貨の**両方**がある場合にのみ金額を表示します。いずれかが欠けている場合、セルには `-`
が表示されます。

これを知っておく価値があるのは、したがって `-` はゼロを意味しないからです。本当のゼロは通貨コード付きの
書式化された `0.00` として表示されます。ダッシュはペアが利用できなかったことを意味します。

## 金額と通貨はどのように書式化されますか？

| ルール | 動作 |
| - | - |
| 順序 | **金額が先、通貨コードが後** — `USD 1,234.56` ではなく `1,234.56 USD` |
| 桁区切り | 選択したインターフェース言語にかかわらず、`en-US` 慣習の桁区切りと小数点 |
| 記号 | 通貨**記号は取り除かれ**、3 文字のコードのみ表示されます |
| 方向 | レコードに方向がある場合、入金には `+`、出金には `-` が前置され、赤で表示されます |

エクスポートした数値を解析する場合は、記号ではなくコードに対して解析し、区切り文字の慣習が Portal の
言語設定に従うとは想定しないでください。

## 決済一覧に精算ステータス列がないのはなぜですか？

main にはありません。決済一覧には注文自体のステータス、作成と決済のタイムスタンプ、および — 該当する場合 —
サブスクリプション ID がありますが、精算状態はありません。

精算ステータスは異議申し立て一覧では**利用可能**で、列とフィルターの両方として存在します。
決済単位の精算情報については、取引一覧ではなく精算レポートから確認してください：
[精算レポート](/docs/ja/support/settlement-reports-faq) と [精算サイクル](/docs/ja/support/settlement-cycle-faq) を参照してください。

## Order Failure Code と Order Failure Description とは何ですか？

失敗した注文にのみ表示され、同じ答えの 2 つの半分です：自社システムで分岐に使える安定したコードと、
それを人が読める形にした説明です。ロジックにはコードを、サポートとの会話には説明を使用してください。

よくある失敗原因とその対処は [エラーとトラブルシューティング](/docs/ja/support/errors-troubleshooting-guide) に、
上限による拒否については特に [Payin 契約と取引上限](/docs/ja/support/payin-agreements-and-limits-faq) にまとめられています。

## 決済レコードにサブスクリプション ID が表示されるのはなぜですか？

その決済がサブスクリプションの下で行われたためです。決済一覧には関連するサブスクリプション ID が含まれており、
1 件の課金からそれを生み出した契約まで遡ることができます。単発の決済では `-` になります。

逆方向 — サブスクリプションからその課金へ — については、
[サブスクリプションのライフサイクル管理](/docs/ja/support/subscription-lifecycle-management) を参照してください。

## 決済レコードにはどの手数料の数値が表示されますか？

決済詳細には `Fees` ブロックがあり、その取引に課された手数料が金額と手数料通貨で表示されます。手数料の**算定基準**
— 料率、固定額、下限・上限 — は取引上にはなく、
[Payin 契約ページ](/docs/ja/support/payin-agreements-and-limits-faq) にあります。

部分返金を含め、決済が返金された場合の手数料の動作については、[返金 FAQ](/docs/ja/support/refund-faq) を参照してください。

## ドキュメントに記載されているフィールドが Portal ではダッシュになっています。データが欠けていますか？

通常は欠けていません。Portal は 3 つの異なる状況で、`N/A` や空セル、ゼロではなく意図的に `-` を表示します。
これらを見分けることでサポートチケットを 1 件節約できます：

| 原因 | 例 |
| - | - |
| その属性がこのレコードに該当しない | 単独の返金における `Refund Batch ID`；単発の決済におけるサブスクリプション ID |
| その属性が特定のクエリでのみ設定される | CIT/MIT フィルター外の `Initiation Type` |
| この取引でその値が利用できなかった | カードデータに含まれていなかった発行会社 |

3 つのいずれも、レコードを再度開いても回復しません。2 番目に該当する場合は、該当するフィルターを付けて
クエリを再実行してください。


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