これは 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 は付与されませんでした。請求の支払いには、スワップを経由するものより、自分が管理するウォレットからの直接送金のほうがはるかに安全です。
- 金額の不一致(過払いを含む)。金額が足りなければ請求が未払いのまま残るのは当然です。しかし、プロセッサーの設定によっては過払いも自動反映を壊すことがあります。受領額が想定額と一致しないため、自動決済されずに手動対応としてフラグが立つからです。手数料分を上乗せして少し多めに送るのは、感覚的に安全に思えても実際には安全ではありません。
- 送金が確定する前に請求が期限切れになった。ホスト型の暗号資産請求には有効期限があり、一般的には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行のリマインドを送りましょう。重複したチケットを新規に立ててはいけません。多くのヘルプデスクでは、それをすると待ち行列の順番がリセットされます。
ステップ4:次回以降に回避する
堅実な順から便利な順に、3つのアプローチがあります。
請求が指定するチェーンとトークンを厳密にそのまま使い、それ以外は使わない。ウォレットに触れる前にチェックアウトページを読んでください。ネットワーク名が出金画面の表記と完全に一致することを確認します。取引所のドロップダウンにある USDC という表示だけでは情報として不十分です。切り上げた金額ではなく、正確な金額を送ってください。請求を発行したら1時間後ではなく、すぐに送金してください。
ネットワークを意図的に選べるアカウントから支払う。手持ちの USDC が請求の受け付けないチェーンにしかない場合は、請求を発行する前にブリッジしてください。発行してからではありません。請求を発行してから20分かかるブリッジを始めるのが、期限切れが起きる典型的な流れです。
あるいは、自分が実際に保有している資産を受け付けるチェックアウトを使う。この問題はまさにその類のものです。失敗の原因は受付可能資産のリストが狭いことにあるので、リストが広ければ問題自体がなくなります。checkout.rozo.ai の ROZO Checkout はその選択肢の一つです。OpenRouter の payment link を貼り付け、USDT、Solana・Stellar・BNB Chain 上の USDC、あるいは Lightning 経由の Bitcoin で支払うと、代わりに USDC で決済されます。特定の単一チェーンに合わせることを求められないため、ネットワーク違いという種類の失敗自体が発生しません。
これが唯一の選択肢というわけではなく、トレードオフも明示しておくべきでしょう。加盟店の決済プロセッサーに直接支払うのではなく第三者を経由することになり、ROZO は OpenRouter や Coinbase とは独立した存在です。ネットワークを慎重に選んだうえで直接支払う経路を好む人もいるでしょうし、それはまったく妥当な選択です。一方で、すでに USDT や sats を保有していて、直接支払う手段がまったくない人もいます。その観点で選んでください。
どちらの経路を選ぶにせよ、身につけるべき習慣は同じです。署名する前に、ティッカーと数字だけでなく、ネットワークとトークンのコントラクトを確認すること。