例外ケースにはどんなものがありますか？注文は成功するのですか？
Waffo は仕様外の送金を以下のいずれかのケースに分類します — このラベルは、お客様がチケットを起票したときにサポートが使うものです。
表全体を貫く 2 つのルールがあります：精算は常に注文金額に基づき、送金された金額には基づきません。
そして、購入者への資金の返還はお客様のアカウント上の返金ではありません — 返金注文は作成されず、返金レポートにも何も現れません。
購入者が過大に支払いました — 超過分は受け取れますか？
いいえ。注文は注文金額で完了し、超過分はお客様のものにはなりません。わずかな超過 — 注文金額の許容範囲内、または 返送コストを下回る額 — は返還されず、お客様に入金されることもありません。それより大きい超過は、その送金コストを差し引いて 支払い元アドレスに返されます。したがって、ステーブルコインの注文をオンチェーンの金額と照合しないでください。購入者の支払いが不足していた、または遅すぎました — それでも履行できますか？
いいえ。どちらのケースも注文の支払いにはならないため、自分で観測したオンチェーンの送金を根拠に商品を引き渡さないでください。 Waffo は受領額から送金コストを差し引いて支払い元アドレスに返します。コストをカバーできない場合は、何も返されません。 購入者には、決済ページ上の支払い期間内に、注文金額全額を 1 回の送金で支払うよう案内してください。誤ったチェーン、誤ったトークン、古いアドレス — 自動で解決しますか？
いいえ。WRONG_TOKEN、WRONG_CHAIN、NO_MATCH_ORDER が自動的に処理されることは決してありません：注文は成功せず、
資金も自動では戻りません。トランザクションハッシュ、チェーン、トークン、注文 ID を添えてサポートチケットを起票してください。
NO_MATCH_ORDER の通常の原因は、受取アドレスの再利用です — アドレスは注文ごとに発行されるため、アドレスをキャッシュしたり、
購入者に 2 回支払わせたりすると、2 回目の送金はどの注文にも一致しません。
購入者が取引所から支払った場合、返還が遅いのはなぜですか？
自動返還はセルフカストディのウォレット（EOA）にのみ行われます。取引所の出金アドレスやコントラクトアドレスから送られた資金は、 そのアドレスが購入者自身のものではないため、そこへ安全に返還することができません — そのためケースは手動対応に回され、 かなり時間がかかります。可能な場合は、取引所アカウントから直接ではなく自分のウォレットから支払うよう購入者に伝えてください。これらの例外ケースを自分で確認できる場所はありますか？
Portal のどこにもありません。これは画面の不足ではなく、率直な回答です：加盟店向けのどの画面にもオンチェーンの詳細は 含まれていません。取引一覧と取引詳細には、チェーンの列、トランザクションハッシュ、コンファメーション数、 受領額と注文金額の比較のいずれもないため、過大支払い、不足支払い、誤チェーン送金を調べることはできません。 確認できるのは注文です：最終的な成功状態に到達したか、しなかったか、のどちらかです。上記のすべては資金がどこへ行ったかの 説明であり、注文についての説明ではありません。そしてこれらのケースはいずれもお客様のアカウントに返金注文を作成しないため、 返金一覧や返金レポートにも現れません。 購入者が支払ったと主張する場合に残る手段は 1 つです：注文 ID を、購入者から得られるトランザクションハッシュ、チェーン、 トークンとともにサポートに提示してください。この 4 つの事実がケースを特定する手がかりです。 唯一の例外は x402 の署名パスで、成功した注文では API 上でトランザクションハッシュを含むオンチェーンの精算レシートが返されます — x402 ステーブルコインアクワイアリング を参照してください。ステーブルコインの注文を返金するとき、何を送る必要がありますか？
すべての USDC および USDT の返金で、返金先アドレスが必須です。/api/v1/order/refund の extendInfo 内に指定してください。外側の extendInfo の値は、
ネストされた JSON オブジェクトではなく、JSON を含む文字列です。
以下は完全なリクエストボディの例です。各プレースホルダーを注文と購入者の実際の値に置き換えてください。
refundAmount には注文の返金可能額の全額を指定してください。返金先アドレスは元の決済チェーンで有効である必要があります。
アドレスを省略すると、リクエストは事前のパラメーター検証で失敗し、A0003 とメッセージ
Parameter validation failed ( missing refund optional field ) が返されます。
msgParams.missingFields には extendInfo.refundAddress が含まれます。この場合、返金注文は作成されません。
したがって、後から照会するものは何もありません。法定通貨の注文では不要で、送信されても無視されます。これはインテグレーションの
変更として扱ってください：すでに返金 API を呼び出していて、後からステーブルコインの受け入れを追加する場合は、
先に返金の経路を更新してください。アドレスは購入者からお客様自身で収集してください — Waffo がお客様の購入者に連絡して
アドレスを尋ねることはできません。
別のチェーンや任意のウォレットに返金できますか？
どちらもできません。チェーンは元の決済から読み取られてロックされます。返金リクエストにチェーンのパラメーターはなく、 指定しようとしても無視されます。チェーンによってどのアドレス形式が受け付けられるかが決まり、アドレスは返金処理時に そのチェーンの形式に対して検証されます。
自社の入力検証に組み込む価値のある形式上の詳細が 2 つあります。実際にチェックされ、かつ人を驚かせるからです。
- 大文字小文字が混在する EVM アドレスはチェックサム検証（EIP-55）されます。 すべて小文字、またはすべて大文字の アドレスはそのまま受理されますが、大文字小文字が混在するものは有効な EIP-55 チェックサムを持つ必要があります。 そのため、手作業で「整えられた」アドレス — 1 文字だけ大文字小文字を変えたもの — は失敗し、同じアドレスをすべて小文字に したものは通ります。
- Tron のアドレスは Base58Check でデコードされ、パターン照合だけではありません。1 文字の打ち間違いは、受理されて後から オンチェーンで失敗するのではなく、チェックサムで失敗します。
INVALID_REFUND_ADDRESS_FORMAT で始まり具体的な理由が続くメッセージで失敗します。
欠落しているアドレスとは異なり、形式が不正なアドレスは 1 段階後 — 返金注文がすでに作成された後 — に検出されるため、
結果は ORDER_REFUND_FAILED の返金注文となり、返金照会と Portal の Refunds 一覧でその理由とともに確認できます。
オンチェーンでは何も動いていません。失敗したレコードがすでに存在するため、修正したアドレスでのリトライは
新しい refundRequestId による新規リクエストになります：古い ID で再送すると、新しい試行ではなく失敗したレコードが返されます。
再送の前に remainingRefundAmount を確認してください。
セルフカストディ（EOA）のウォレットアドレスを使ってください。マルチシグウォレットを含むコントラクトベースのウォレットは
返金先としてサポートされておらず、Portal の返金ドロワーにも同じルールが記載されています。
Portal も同じ制約を適用します：返金ドロワーではチェーンは元の決済チェーンを示す読み取り専用のラベルで、
*「返金は元の決済と同じチェーンを使う必要があります」*と注記されます。アドレス欄は入力しながらそのチェーンの形式に対して
検証され、詳細ページには使用されたアドレスが表示されます。Portal のどの画面にもオンチェーンの詳細 — トランザクションハッシュ、
コンファメーション数、ネットワーク手数料 — は表示されません。
ステーブルコインの注文で一部返金を行えますか？
いいえ。公開されている 決済手段カタログ はUSDC と USDT を全額返金のみとして
記載しており、返金の形のチェックがそれを強制します：全額に満たない返金は拒否され、全額返金後の 2 回目の返金も拒否されます。
お客様自身の契約に適用される形は、Service → Payin の Refundable 列、または設定レスポンスの refundAllowed で
確認してください — 4 つの形とそのコードは
決済手段の設定を読む で説明しています。
したがって、ステーブルコインの返金は注文ごとに 1 回のオール・オア・ナッシングの操作として計画してください。
一部の金額を返す必要が業務上ある場合、それは返金 API の外側にある商取引上の取り決めであり、一部返金ではありません。