入金不足では未払残高が残り、過払いでは処理すべき超過入金が発生します。どちらも、その場の判断で返金したり、再度全額の支払いを求めたりしてはいけません。 まず実際の入金を確認して購入記録と照合し、注文を履行するかどうかと、差額をどう精算するかを分けて判断します。
このガイドは、資産、ネットワーク、送金先が正しいことを前提としています。一致しない場合は、ネットワーク誤選択時の対応ガイドを参照してください。ここで扱うのは、それ以外は一致している入金の金額、時期、充当に関する問題です。
以下は事業者の運用とシステム実装に関する推奨事項であり、Yolfiの自動機能の一覧ではありません。例は説明用であり、実際の顧客事例ではありません。
対応を決める前に金額を確定する
元の支払い依頼について、注文番号、指定したトークン数量、ネットワーク、送金先、見積もりの根拠、有効期限の規則を保存します。比較対象は、独立に検証され、自社の承認要件を満たす入金です。顧客のウォレットの画面画像や残高の推定値ではありません。
次の3つの数値は分けて管理してください。
- 請求額: 支払い案内で指定した金額。
- 確認済み入金: 実際に受け取り、条件が一致し、充当に使用できる送金。
- 未解決の差額: 過去の充当、顧客残高への計上、返金を反映した後の不足額または超過額。
事業者が後から送金する際の費用を、顧客の支払額から差し引かないでください。決済事業者の手数料や会計上の調整は、実際の入金を示す証拠と分けて管理します。
取引所からの出金では、サービス側が手数料を差し引くと、顧客が意図した額より入金が少なくなる場合があります。推測ではなく入金記録を確認してください。一方、Ethereum上の通常のUSDCやUSDT送金では、USDCやUSDTからEthereumのガス代が差し引かれるわけではありません。Ethereumのガス代はETHで支払われます。ガス代として推測した数量のステーブルコインを上乗せするよう顧客に案内しないでください。
実装では、確認済みの資産の桁数に基づき、最小単位の整数または正確な十進数で比較します。二進浮動小数点数による比較は避け、決済ページの表示桁数が少ないという理由だけで不足額を丸めて消してはいけません。
金額例外への対応判断表
社内規程のひな型として利用してください。これは業務上の分類であり、Yolfi APIの状態ではありません。
| 確認済みの状況 | 履行の判断 | 金額を解決するための対応 | 完了前の確認 |
|---|---|---|---|
| 適用される期限規則の範囲内で全額を受領 | 承認要件を満たしてから1回だけ履行 | 入金を注文に充当 | 過去の充当と履行を確認 |
| 請求額より少ない | 権限者による減免がない限り保留 | 追跡可能な差額請求、減免、返金のいずれかを承認 | 未払残高と担当者を記録 |
| 請求額より多い | 入金の受入条件を満たす場合のみ1回履行 | 超過分の返金または合意済みの顧客残高への計上を審査 | 注文への充当と超過分を分離 |
| 複数の送金で必要額に到達 | 合算が許可され、検証されるまで保留 | 対象の各送金を1回だけ充当 | 決済事業者が合算すると決めつけない |
| 期限後に全額を受領 | 時期、見積もり、注文の履行可能性を確認 | 規程に沿って受け入れるか別の解決策に合意 | 関連する代替の支払い依頼を確認 |
| 元の依頼と代替の依頼の両方に入金 | 絶対に二重履行しない | 両方の入金を照合し、余剰分を処理 | 注文をロックして重複操作を防止 |
すべての例外に担当者と次回連絡期限を設定してください。顧客対応部門と経理部門が互いに相手の担当だと思い込み、入金が未充当のまま放置される状態を防ぎます。
入金不足:承認済みの次の対応だけを依頼する
100 USDCの支払い依頼に対して、確認できた入金が98 USDCだったとします。不足額は2 USDCです。元の入金記録を残し、100を受領した記録に黙って置き換えてはいけません。
次のいずれかを選び、記録します。
- 差額を回収する。 連携システムで別々の入金を照合できることを確認します。同じ注文に紐付け、最新の支払い案内を添えて、未払額の追跡可能な支払い依頼を発行します。
- 減免を認める。 権限を持つ担当者が免除額と会計処理を記録します。事業者の減免によって決済事業者の入金認定規則が変わるとは説明しないでください。
- 一部入金を返金する。 独立した出金を実行する前に、返金条件と送金先について合意します。
Yolfiの一部入金に関するよくある質問では、不完全な支払いは確定されず、顧客は事業者に連絡するよう案内されています。同一アドレスへの追加送金も、事業者のシステムが対応していることが条件です。したがって、差額を送れば元のYolfiの支払い依頼が自動的に完了すると約束してはいけません。
分割入金の処理を検証していない場合は、追加送金を案内する前に責任者へ確認してください。最初の一部入金を保持したまま再度全額を求めれば、過払いにつながることは容易に予想できます。
小額の不足に関する規程は、問題が起きる前に定めます。たとえば承認限度額、対象となる購入、監査用の理由を定義します。共通の許容率はありません。BTCPay Serverは独自の設定可能な入金不足許容値を文書化していますが、それはYolfiにも同じ設定がある証拠にはなりません。
過払い:売上と超過分を分ける
100 USDTを支払うべき顧客が105 USDTを送金したとします。その他の受入要件を満たす場合は、100 USDTを購入に充当し、5 USDTを未解決の超過分として管理します。差額を自動的に追加売上や追加の商品利用権とみなしてはいけません。
利用可能で規程に適合する解決策として、返金、または明示的な合意に基づく顧客残高への計上を顧客に選んでもらいます。合意前に適用される手数料を説明し、現地の消費者保護と会計上の義務も確認してください。小額であることは、無断で資金を保持してよい理由にはなりません。
また、1件の多額送金と重複送金を区別します。100 USDTの購入に対する100 USDTの送金が2件あれば、それは2件の入金であり、修正済みの1件の入金ではありません。両方の取引記録を残し、履行は1回にとどめ、追加の100 USDTは別に審査します。
期限後の入金:期限が切れても受領資金は未解決のまま
支払い依頼の期限、送金の検知時刻、承認時刻は別々に記録します。期限前に検知し、期限後に承認された支払いと、見積もりの期限が切れた後に初めて受領した送金は異なります。文書化された規則を適用し、共通の猶予期間があると決めつけないでください。
期限後の入金では、次の点を確認します。
- 元の価格がまだ有効か。
- 在庫、提供能力、利用権を引き続き確保できるか。
- 別の支払い依頼ですでに同じ注文が支払われていないか。
- 返金、顧客残高への計上、減免がすでに承認されていないか。
100 USDCのようにトークン建てで請求する場合と、法定通貨建ての金額を暗号資産に換算する場合では、期限後の入金規程が同じとは限りません。元の見積もりを保存し、新しい見積もりが必要なら明示してください。過去の価格を書き換えてはいけません。
代替の支払い依頼が必要な場合は、記録上で元の注文と紐付け、両方に支払わないよう顧客に注意を促します。古い支払い試行の監視も続けてください。問い合わせを完了扱いにしても、すでに送信された送金が後から承認されることは防げません。
二次的な問題を起こさず安全に返金する
返金は独立した出金であり、入金済み取引の編集ではありません。Yolfiの非カストディ型サービスの説明では、支払いは事業者が設定したウォレットに直接届くとされています。Yolfiが返金可能な残高を保持している、あるいは超過分を自動返金すると考えないでください。
返金を承認する前に、次を実施します。
- 元の入金、顧客の申告、残りの返金可能額を確認します。
- 既存の顧客連絡経路を通じて申請者の本人確認を行います。
- 返金に使う資産、ネットワーク、送金先を取得し、検証します。取引の送信元へ機械的に返金してはいけません。取引所などの仲介業者のアドレスである可能性があります。
- 適用される義務を踏まえ、返金総額、手数料の扱い、予想される差引受取額について合意します。
- ウォレットのセキュリティ規程に従って承認を得て、理由と承認者を記録します。
- 出金の取引番号を記録し、結果を検証してから返金を完了扱いにします。
シードフレーズや秘密鍵を求めてはいけません。返金の送信処理がタイムアウトした場合は、再送前に取引状態を調査します。応答が不明確だからといって、送金がネットワークに送信されていない証拠にはなりません。
すべての解決処理に冪等性を持たせる
冪等性とは、再試行しても業務上の操作が重複実行されないことです。StripeのWebhookガイドでは、Stripeでイベントが重複し、配信順序も保証されないことが説明されています。実装上の参考にはなりますが、Yolfiの配信仕様を示すものではありません。
自社の連携では、次を実施します。
- 決済事業者が文書化した検証手順で通知の真正性を確認します。
- 受信イベントを永続保存し、文書化された識別子で重複を排除します。
- ネットワークと取引番号で各入金を識別します。1取引に複数の対象送金が含まれる場合は、送金またはイベントのインデックスも用います。
- データベース制約または同等のトランザクション制御により、入金ごとの充当と注文ごとの履行をそれぞれ1回に制限します。
- 承認済みの返金処理は送信前に排他的に確保し、並行処理による二重送金を防ぎます。
同じWebhook通知が再度届いても、別の支払いではありません。2件目の有効な送金は別の入金ですが、2回目の発送を認めるものではありません。完了前に、ウォレット上の証拠と業務記録の両方に照らして例外を照合してください。
よくある質問
ごくわずかな入金不足は受け入れるべきですか?
事業者が承認した規程の範囲内でのみ受け入れます。減免を別途記録し、入金がどのように認定されるかを確認してください。自動の許容設定があるとは考えないでください。
過払いは自動返金すべきですか?
資金の権利者、送金先、金額、重複防止策の検証なしには行いません。検証済みで承認された手順が安全に処理できる場合を除き、超過分を審査待ちにします。
2回の一部送金で1件の注文を支払えますか?
自社の規程が認めるなら、記録上は複数の入金を充当できます。ただし、決済事業者がそれらを合算して認定するかは別途確認が必要です。
まとめ:問い合わせだけでなく差額を解決する
まず分かりやすいYolfi決済リンクを用意し、支払い記録と併せて事業者側の例外管理台帳を維持します。注文への充当、履行判断、未解決残高、返金や顧客残高への計上がすべて整合して初めて案件を完了します。これにより、小さな金額の不一致が追加の支払い、重複した商品提供、危険な返金につながることを防げます。
