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

# 返金の資金はどこから来るのか

> 返金が実際にどの Waffo 残高から、どの順序で引き落とされるのか、精算で支払われた直後に残高不足で返金が失敗するのはなぜか、返金Reserve口座がそれをどう防ぐのか、そしてこれらが返金 API を一切変えない理由。

返金は Waffo の残高から資金を**外へ**動かすため、元の注文とは無関係の理由で失敗することがあります。
引き落とす元がない、という理由です。このページでは、どの残高がどの順序で使われるのか、
そして資金不足で返金が拒否されたときに何をすべきかを説明します。

返金に関するその他すべて — 一部返金、再試行、クロスカレンシーの金額、手数料の返還 — は
[返金 FAQ](/docs/ja/support/refund-faq) を参照してください。各残高が何であるかは
[残高とアカウント履歴](/docs/ja/support/balance-and-account-history-faq) を参照してください。

## 返金はどの残高から引き落とされますか？

次の順序です。返金を賄える最初の資金源が使用され、探索はそこで止まります。

| 順序 | 資金源 | 条件 |
| - | - | - |
| 1 | **精算待ち残高** | **そのアカウントの当座貸越枠を含む**利用可能残高が返金を賄える |
| 2 | **返金Reserve口座** | その加盟店アカウント、事業体、通貨について有効な返金 Reserve の取り決めがあり、**かつ**そのアカウント自身の当座貸越枠を含む利用可能残高が返金を賄える |
| — | どちらも不可 | 返金は `A0012` — *Insufficient merchant account balance* で拒否される |

実際のケースの大半を決める 3 つの詳細：

* **当座貸越はステップ 1 の一部であり、独立したステップではありません。** 精算待ちアカウントには当座貸越枠があり、
  ステップ 1 の判定ですでにそれが考慮されています。そのため、返金が成功して残高がマイナスになることがあります。
  これは設計どおりの動作で、マイナスは次の入金取引によって解消されます。
* **返金Reserve口座はフォールバックであり、優先される資金源ではありません。** 精算待ち残高とその当座貸越枠の
  両方を使い切った後にのみ参照されます。
* **返金 Reserve のステップは、有効な取り決めがあることが前提です。** その通貨について有効な返金 Reserve の取り決めがなければ
  ステップ 2 は存在せず、ステップ 1 で賄えない時点で返金は失敗します。

## どの通貨の残高が確認されますか？

返金の通貨です。残高確認は**通貨ごと**に、お客様の加盟店アカウントと法人がその通貨で保有するアカウントに対して行われます。

複数の通貨で取引している場合、これは重要です。ある通貨の残高が健全でも、別の通貨の返金には何の役にも立ちません。
返金を賄うために通貨間で資金が振り替えられることはなく、上記の選択にはクロスカレンシーのフォールバックもありません。
残高が空の通貨での返金は、他の通貨に十分な資金があっても失敗します。

返金Reserve口座にも同じことが当てはまります。有効な取り決めの確認はその特定の通貨について行われるため、
ある精算通貨をカバーする返金 Reserve の取り決めは、別の通貨には及びません。

## 精算の翌日に、返金が残高不足で失敗したのはなぜですか？

精算が、返金の引き落とし元となる残高を空にするためです。

お客様の資金は精算日まで精算待ち残高にあり、その後、精算アカウントへ、さらに銀行へと移動します。精算が実行されると、
精算待ち残高は**ゼロ**またはそれに近い状態になることがあります。その時点で要求された返金は、当座貸越枠以外に引き落とす元がありません。

これが、返金の失敗が精算支払いの直後に集中する理由であり、元の注文が数週間前に正常に精算されているのに不可解に見える理由です。
注文には問題がなく、残高が空なのです。

選択肢：

| 選択肢 | 効果 |
| - | - |
| 新しい取引を待つ | 入金により精算待ち残高が回復し、再試行で返金が成功する |
| 精算待ち残高に入金する | 古典的な対処法 — ただし、タイミングが悪いたびに資金振込が必要になる |
| **返金Reserve口座**を設定する | 返金専用のアカウントに事前入金しておけば、上記のステップ 2 が個別対応なしにカバーする |

返金Reserve口座は、まさに「待つか入金するか」の選択をなくすために存在します。前払いで、返金にのみ使用され、
独自の当座貸越枠を持ちます。お客様の返金量に対して設定する意味があるかどうかは、Waffo のアカウントマネージャーにご相談ください。

## 返金が資金不足で失敗しました。単純に再試行してよいですか？

はい。資金不足による拒否は、事前チェックとして**返金注文が作成される前**に発生します。そのため、何も記帳されておらず、
途中の状態もなく、片付けるべき状態もありません。元の注文は変更されず、返金可能金額も変わりません。

したがって再試行は安全であり、通常の解決方法です。資金が利用可能になったら再試行してください。曖昧なレスポンスの後の
再試行が二重返金にならないよう、他の返金の再試行と同じ冪等性の実践に従ってください。
[返金 FAQ](/docs/ja/support/refund-faq) を参照してください。

再試行が**行わない**のはキューイングです。資金を確保できなかった返金に保留状態はありません。即座に拒否され、
後で残高が回復しても自動的には何も起こりません。資金が到着した時点で返金を出したい場合は、自分で再発行する必要があります。

## 当座貸越枠があれば、返金は決して失敗しないのですか？

いいえ。当座貸越枠は上限であり、上限がないことではありません。

各ステップの判定は、*残高とそのアカウントの当座貸越枠の合計*を返金額と比較するものです。そのため、その合計額より大きい返金は
やはり失敗し、同じように `A0012` で失敗します。この枠が与えてくれるのは、精算で空になった直後の残高という
よくあるケースへの許容であり、無制限の与信ではありません。

2 つの結果：

* 同じアカウントで小さな返金が成功する一方、大きな返金は失敗することがあります。判定は返金ごとに全額に対して行われ、
  返金が一方の資金源から一部、もう一方から残りという形で賄われることはありません。
* 精算待ち残高がマイナスになると残りの枠は小さくなるため、後続の返金の余地は減ります。空の残高に対する返金の連続は、
  一斉にではなく途中から失敗し始めます。

## これらは精算や出金に影響しますか？

直接的には影響しませんが、精算待ち残高のマイナスには知っておくべき波及効果があります。

* **精算**：返金は、どのアカウントが資金を供給したかにかかわらず、`REFUND` 取引として精算計算にネットされます。
  ある期間の返金が決済を上回れば、その期間はマイナスとなり繰り越されます。
  [精算計算の解説](/docs/ja/support/settlement-calculation-explained) を参照してください。
* **出金**：出金は精算待ち残高ではなく精算アカウントから行われるため、返金は今日出金できる金額を直接減らしません。
  減るのは、後でそのアカウントに精算される金額です。

## 返金の引き落とし元の残高を選べますか？

いいえ。その必要もありません。選択は完全にサーバー側で行われます。

* 返金 API の**リクエストフィールドは変わりません** — 資金源のパラメーターはなく、連携に追加すべきものもありません。
* 返金 API の**レスポンスフィールドは変わりません** — 選択された資金源は、返金作成レスポンスにも返金照会にも返されません。
* API 経由、一括返金ファイル経由、Merchant Portal からのいずれで返金しても、動作は同じです。

実務上の結果：**すでに返金を連携済みであれば、返金Reserve口座にコード変更はまったく不要です。** 変わるのは
お金の出所であり、要求の仕方ではありません。

返金 API に*存在*し、これと混同しやすいフィールドがひとつあります。`refundSource` は返金を**誰が開始したか**
（お客様か、お客様の代わりに自動返金できる異議申し立て防止サービスのいずれか）を表します。どの残高が資金を供給するかとは
無関係です。

資金源が見えるようになるのは事後の照合データです。精算とレジャーのレコードでは、精算待ち残高から資金供給された返金と
返金Reserve口座から供給された返金が区別されるため、照合時に見分けることができます。

## 一括返金では残高の確認方法が異なりますか？

いいえ。一括返金でも、返金注文が作成される前に行ごとに同じ確認が実行されます。資金を確保できない行は、後回しにキューイング
されるのではなく、同じ資金不足の条件で拒否されます。

一括処理の計画上の結果として、バッチの規模は返金対象の注文の総額ではなく、**アップロード時点の精算待ち残高 + 当座貸越枠 +
返金Reserve残高**に対して見積もる必要があります。拒否された行がバッチの残りに与える影響は
[返金 FAQ](/docs/ja/support/refund-faq) を参照してください。

## 契約上の Reserve から返金を出すことはできますか？

**契約に基づいて保持されるローリングまたは固定の Reserve**は、名前は似ていますが返金Reserve口座とは別物です。

| | 返金Reserve口座 | 契約上の Reserve（ローリング / 固定） |
| - | - | - |
| 目的 | 返金のための事前入金された資金源 | 契約に基づき留保されるリスクカバー |
| 誰が入金するか | お客様が入金する | 各精算から自動的に控除される |
| 自動的に引き出されるか | はい、返金のフォールバックとして | いいえ |
| 確認場所 | 返金の照合レコード | Portal の **Reserve Account** モジュール |

契約上の Reserve については [Reserve口座](/docs/ja/support/reserve-faq) を参照してください。サポートチケットでは
この 2 つが混同して問われることが多いため、「Reserve で返金を賄える/賄えない」と言われた場合は、まずどちらを指しているのかを
確認してください。

## チャージバックはどこから資金を取りますか？

チャージバックとそのチャージバック手数料は、**精算時に精算待ち残高に対して**引き落とされ、両方とも同じ経路を通ります。
手数料の資金供給方法が金額と異なることはありません。

その残高は当座貸越可能であるため、チャージバックは返金のように残高が空でもブロックされません。残高をマイナスにすることが許され、
マイナスは後の入金で解消されます。精算期間全体がマイナスになった場合、その日に資金は動かず、金額は繰り越されます。
[精算計算の解説](/docs/ja/support/settlement-calculation-explained) を参照してください。

契約上の Reserve は、チャージバックに対しても引き当てられません。


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