これは AI API の課金まわりで最もよく起こり、かつ最も情報が整備されていない失敗パターンの一つであり、あなたのウォレットの不具合ではありません。暗号資産ユーザーが「こうしているつもり」の内容と、チェックアウトの背後にある決済プロセッサーが実際に受け付ける内容との、構造的なズレが原因です。このページでは、その原因、現実的な回収手順、そして所要期間についての正直な見通しを説明します。
2026年8月10日時点で確認済みです。決済プロセッサーの挙動や対応チェーンの一覧は変更されるため、送金前に必ず実際のチェックアウトページで受付可能なネットワークを確認してください。
結論を先に
OpenRouter は暗号資産決済を自社で処理していません。ホスト型の暗号資産チェックアウトである Coinbase Commerce を利用しており、入金がその請求（invoice）で受け付けるよう設定されたチェーンとトークンの組み合わせに厳密に一致した場合にのみ、支払いとして計上されます。
正しいトークンを誤ったチェーンで送る、あるいは正しいチェーンで誤ったトークンを送ると、資金は実在するプロセッサー管理下のアドレスに到着しますが、それをあなたの請求に結び付ける仕組みはどこにもありません。エラー画面は出ません。トランザクションは成功します。請求は未払いのまま期限切れになります。
このギャップ、つまり「オンチェーンでは成功しているのに、決済としては認識されない送金」こそが、この種のケースのほぼすべてが発生している場所です。
実際に何が起きているのか（発生頻度順）
- トークンは正しいが、ネットワークが違う。圧倒的に多いケースです。USDC は Ethereum、Base、Polygon、Solana、Arbitrum、Optimism、Avalanche など複数のチェーンに存在します。名前と価格が同じなだけで、コントラクトアドレスの異なる別々のトークンです。典型例：ユーザーが大手取引所から USDC を出金する際、出金手数料が最も安いという理由で Polygon を選び、15ドル弱を送金し、数秒で着金が確定する。しかし請求が想定していたのは別のネットワークだった。資金はプロセッサーの Polygon アドレスに着金しますが、請求はそのアドレスを監視していません。何も反映されず、何のエラーも出ません。この選択がなされるのは取引所の出金画面であり、その判断はほぼ常に「手数料」を基準に行われ、「請求が何を求めているか」を基準には行われていません。
- USDC しか受け付けないところに USDT を送る。ユーザーはどちらもドルに連動しているという理由で USDT と USDC を交換可能なものとして扱いますが、決済プロセッサーはそう扱いません。USDC 建ての請求は、同じチェーン上であっても USDT を受け付けません。繰り返し確認されているパターン：Solana 経由の USDT 送金がオンチェーンで確定し、送信者の手元には有効な署名とウォレット上の緑のチェックマークがあるのに、OpenRouter の残高は動かない。別の例：Polygon 経由で少額の USDT を送金し、1週間経っても未反映のまま、チケットにも返信がない。
- アグリゲーターやスワップ経路を通じて支払った。ウォレットからの直接送金ではなく、スワップアグリゲーターや DEX ルーター経由で支払うと、受取アドレス側から見える内容（送信元アドレス、トークンの経路、場合によってはトークンそのもの）が変わることがあります。あるユーザーは Solana のアグリゲーター経由でおよそ 15 USDC を支払いました。スワップは実行され、資金は動きましたが、credits は付与されませんでした。請求の支払いには、スワップを経由するものより、自分が管理するウォレットからの直接送金のほうがはるかに安全です。
- 金額の不一致（過払いを含む）。金額が足りなければ請求が未払いのまま残るのは当然です。しかし、プロセッサーの設定によっては過払いも自動反映を壊すことがあります。受領額が想定額と一致しないため、自動決済されずに手動対応としてフラグが立つからです。手数料分を上乗せして少し多めに送るのは、感覚的に安全に思えても実際には安全ではありません。ROZO Checkoutで支払って金額が足りなかった場合は、対処はもっと簡単です。注文の期限が切れる前に、差額を同じアドレスへ、同じチェーン、同じ通貨で送れば注文は進みます。詳しくはこちら：ROZO Checkoutに請求額より少なく送金してしまいました。どうなりますか？
- 送金が確定する前に請求が期限切れになった。ホスト型の暗号資産請求には有効期限があり、一般的には15〜60分です。請求を発行してから別の作業をして1時間後に送金した場合、あるいはネットワークが混雑している時に送金した場合、期限が過ぎてから着金することがあります。アドレスは依然として実在しますが、請求はもう待っていません。
ステップ1：実際に何を送ったのかを確認する
誰かに連絡する前に、事実を集めてください。それがなければサポートも対応できませんし、5分で自分で答えにたどり着けることもあります。
使用したチェーンのブロックエクスプローラーを開き、自分のトランザクションを表示します。次の項目を書き出してください。
- トランザクションハッシュ：省略表示のスクリーンショットではなく、完全な文字列で。
- ネットワーク、実際のチェーン名（例：Polygon PoS、Solana mainnet、Base）。
- トークンのコントラクトアドレス：USDC か USDT かを決定的に判別できるのはこの項目です。
- 正確な金額：小数点以下まで完全に。
- 受取アドレス：資金が最終的に届いた先。
- タイムスタンプ：UTC で。
- 送信元アドレス：支払いに使ったウォレット。
次に、請求と照合します。チェックアウトページが求めていたチェーンとトークンは何か、請求の有効期限はいつだったか。請求ページやメールが残っていれば、そこに記載されています。この時点で通常は、5つの原因のどれに当たったかが分かります。
ステップ2：資金がすでにどこかで見えていないか確認する
エスカレーションの前に、確認しておく価値のあることが2つあります。
チェックアウト上で支払いが pending または未解決として表示されていないか。ホスト型の暗号資産チェックアウトには、支払い不足・過払い・遅延といった状態があり、担当者が解消できる場合が多くあります。そこに支払いが表示されているだけでも、あなたの主張はずっと通りやすくなります。
決済プロセッサーからメールが届いていないか。Coinbase Commerce は OpenRouter とは独立して独自の通知を送ります。迷惑メールフォルダも含めて、受信箱を請求で検索してください。
請求が監視していないチェーンに資金が着金した場合、チェックアウト上のどこにも表示されません。これはより難しいケースであり、正直に言えば、非対応ネットワークでプロセッサーのアドレスに送られた資金は、プロセッサーの裁量によってのみ回収され得ます。プロトコルレベルで引き戻す仕組みは存在しません。回収に応じるプロセッサーもありますが、それは手作業で、時間がかかり、ベストエフォートの対応です。
ステップ3：正しい方法でサポートに連絡する
解決するチケットと1週間放置されるチケットの差は、ほぼすべて最初のメッセージの書き方で決まります。短いメッセージを送ってから5回追加説明をするのではなく、必要な情報をすべて含んだ1通を送ってください。
次の順序で記載します。
- OpenRouter アカウントのメールアドレス。
- 問題を1文で：オンチェーン送金は確定済みだが credits が付与されていない。
- 請求または payment link の識別子。
- トランザクションハッシュ、ネットワーク、トークンのコントラクトアドレス、正確な金額、UTC でのタイムスタンプ。
- そのトランザクションのブロックエクスプローラー URL。
- 希望する対応：credits の付与、または送信元アドレスへの返金。
該当する場合は両方に連絡してください。OpenRouter サポートは credits 側を担当し、資金を保持しているのは決済プロセッサーです。請求が対象としていないネットワークに送金してしまった場合、実際に資金を特定できるのはプロセッサーの側です。
私たちが追跡してきたケースに基づく現実的な所要期間：チェックアウト上で支払い不足や遅延として支払いが見えている単純なケースは、通常数営業日で解決します。ネットワーク違い・トークン違いのケースは1〜3週間かかることが多く、返答がないまま終わるものもあります。この種のチケットについては、最初の返信がないまま丸1週間経過したという報告が複数のユーザーから出ています。そのつもりで計画してください。その残高に依存する本番トラフィックがあるなら、チケットを待たないことです。別の方法でアカウントに入金し、止まっている送金は別途の回収作業として扱ってください。
強く迫るより、丁寧にエスカレーションするほうがうまくいきます。自分のチケットに3〜4営業日ごとに返信し、トランザクションハッシュを再掲した1行のリマインドを送りましょう。重複したチケットを新規に立ててはいけません。多くのヘルプデスクでは、それをすると待ち行列の順番がリセットされます。
最近の 2 つの事例と、その解決方法
2026 年 10 月、OpenRouter のコミュニティ Discord に寄せられた 2 件のサポートスレッドは、2 種類の失敗と、それぞれ解決までにかかった時間をよく示しています。
ネットワークは正しく、トークンが違った。あるユーザーは 10 月 14 日、Polygon 上の Stripe 暗号資産チェックアウトで $10.80 をチャージしました。送金は USDT でしたが、このチェックアウトは Polygon では USDC しか受け付けないため、自動では反映されませんでした。残高はわずかにマイナスになり、作業が止まりました。サポートが支払いを特定し、6 日後に手動でクレジットを付与しました。
手数料分が不足していた。別のユーザーは 8 月 4 日、Solana で 19 USDC を送金しました。チェックアウトが求めていたのは 20.05 USDC、つまり $19 のクレジットと処理手数料です。不足していたため決済代行会社は支払いを完了せず、セッションは期限切れになりました。4 件のチケットと約 2 か月半を経て、サポートが $19 を手動で追加し、重複チケットを 1 件にまとめました。
2 件の共通点：お金は届いており、サポートはトランザクションハッシュから見つけられ、解決策は手動のクレジット付与でした。時間の差は主に問い合わせ方の違いから生じています。最初からハッシュとネットワークを書いたスレッドは 1 週間以内に解決し、同じ支払いに複数のチケットを立てたケースは数か月かかりました。
OpenRouter が示しているルール：該当する暗号資産の支払いが 2 時間たっても反映されない場合は、サポートによる手動付与が必要です。新しいチケットを作らず、既存のチケットにトランザクションハッシュ、ネットワーク、正確な金額、請求書を添えて返信してください。
Polygon の USDT で支払いたい場合は、OpenRouter の支払いリンクを ROZO Checkout（checkout.rozo.ai）に貼り付けてください。Polygon の USDT を受け付け、請求書は USDC で代わりに決済します。
最近の 2 つの事例と、その解決方法
2026 年 10 月、OpenRouter のコミュニティ Discord に寄せられた 2 件のサポートスレッドは、2 種類の失敗と、それぞれ解決までにかかった時間をよく示しています。
ネットワークは正しく、トークンが違った。あるユーザーは 10 月 14 日、Polygon 上の Stripe 暗号資産チェックアウトで $10.80 をチャージしました。送金は USDT でしたが、このチェックアウトは Polygon では USDC しか受け付けないため、自動では反映されませんでした。残高はわずかにマイナスになり、作業が止まりました。サポートが支払いを特定し、6 日後に手動でクレジットを付与しました。
手数料分が不足していた。別のユーザーは 8 月 4 日、Solana で 19 USDC を送金しました。チェックアウトが求めていたのは 20.05 USDC、つまり $19 のクレジットと処理手数料です。不足していたため決済代行会社は支払いを完了せず、セッションは期限切れになりました。4 件のチケットと約 2 か月半を経て、サポートが $19 を手動で追加し、重複チケットを 1 件にまとめました。
2 件の共通点：お金は届いており、サポートはトランザクションハッシュから見つけられ、解決策は手動のクレジット付与でした。時間の差は主に問い合わせ方の違いから生じています。最初からハッシュとネットワークを書いたスレッドは 1 週間以内に解決し、同じ支払いに複数のチケットを立てたケースは数か月かかりました。
OpenRouter が示しているルール：該当する暗号資産の支払いが 2 時間たっても反映されない場合は、サポートによる手動付与が必要です。新しいチケットを作らず、既存のチケットにトランザクションハッシュ、ネットワーク、正確な金額、請求書を添えて返信してください。
Polygon の USDT で支払いたい場合は、OpenRouter の支払いリンクを ROZO Checkout（checkout.rozo.ai）に貼り付けてください。Polygon の USDT を受け付け、請求書は USDC で代わりに決済します。