Sent Crypto to OpenRouter But Credits Never Arrived? Here's Why, and What to Do

This is one of the most common and least well-documented failure modes in AI API billing, and it is not a bug in your wallet. It is a structural mismatch between what crypto users think they are doing and what the payment processor behind the checkout actually accepts. This page explains the cause, gives you a realistic recovery procedure, and sets honest expectations about timelines.

Verified on 10 August 2026. Payment processor behaviour and supported chain lists change, so confirm the accepted network on the live checkout page before sending.

The short version

OpenRouter does not process crypto payments itself. It uses a hosted crypto checkout — Coinbase Commerce — which credits a payment only when the incoming transfer matches an exact combination of chain and token that the specific invoice was created to accept.

Send the right token on the wrong chain, or the wrong token on the right chain, and the money arrives at a real address that a real processor controls, but nothing in the system connects it to your invoice. There is no error screen. The transaction succeeds. The invoice sits unpaid until it expires.

That gap — a successful on-chain transfer that is nonetheless an unrecognised payment — is where almost every one of these cases lives.

What actually goes wrong, in order of frequency

1. Right token, wrong network. By far the most common. USDC exists on Ethereum, Base, Polygon, Solana, Arbitrum, Optimism, Avalanche, and more. They are different tokens with different contract addresses that happen to share a name and a price. A typical case: a user withdraws USDC from a major exchange, picks Polygon because the withdrawal fee is lowest, sends just under $15, and the transfer confirms in seconds. The invoice was expecting a different network. The funds land in the processor's Polygon address, which the invoice never watches. Nothing is credited, and nothing errors. The exchange withdrawal screen is where this decision gets made, and it is almost always made on the basis of fee, not on the basis of what the invoice asked for.
2. USDT where only USDC is accepted. Users treat USDT and USDC as interchangeable because they both track a dollar. Payment processors do not. An invoice denominated in USDC does not accept USDT even on the same chain. A pattern we have seen repeatedly: a USDT transfer over Solana confirms on-chain, the sender has a valid signature and a green checkmark in their wallet, and the OpenRouter balance never moves. Another: a small USDT amount sent over Polygon, still uncredited a week later, with no response yet on the ticket.
3. Paid through an aggregator or swap route. Paying via a swap aggregator or DEX router rather than a direct wallet transfer can change what the receiving address actually sees — the sender address, the token path, and sometimes the token itself. One user paid roughly 15 USDC through a Solana aggregator; the swap executed, the funds moved, and no credits appeared. Direct transfers from a wallet you control are far safer for invoice payments than anything routed through a swap.
4. Amount mismatch, including overpayment. Underpay and the invoice stays open, obviously. But overpaying can also break automatic crediting on some processor configurations, because the received amount does not match the expected amount and the payment is flagged for manual handling rather than auto-settled. Sending a bit extra to cover fees is not the safe move it feels like.
5. Invoice expired before the transfer confirmed. Hosted crypto invoices carry a time window, commonly 15 to 60 minutes. If you generate the invoice, go do something else, and send an hour later — or if you send during network congestion — the transfer can land after the window closed. The address is still real. The invoice is not listening anymore.

Step 1: Confirm what you actually sent

Before contacting anyone, gather the facts. Support cannot help without them, and you may find the answer yourself in five minutes.

Open the block explorer for the chain you used and pull up your transaction. Write down:

• Transaction hash — the full string, not a screenshot of a truncated one.
• Network — the actual chain, e.g. Polygon PoS, Solana mainnet, Base.
• Token contract address — this is the field that settles the USDC-versus-USDT question definitively.
• Exact amount — to full decimal precision.
• Receiving address — where the funds ended up.
• Timestamp — in UTC.
• Sending address — the wallet you paid from.

Then compare against the invoice: which chain and token did the checkout page ask for, and what was the invoice's expiry time? If you still have the invoice page or email, this is in it. At this point you usually know which of the five causes you hit.

Step 2: Check whether the funds are already visible somewhere

Two things are worth checking before escalating.

Is the payment showing as pending or unresolved in the checkout? Hosted crypto checkouts often have an underpaid, overpaid, or delayed state that a human can resolve. If your payment appears there at all, your case is much stronger.

Did you receive any email from the payment processor? Coinbase Commerce sends its own notifications independently of OpenRouter. Search your inbox — including spam — for the invoice.

If the funds landed on a chain the invoice never watched, they will not appear anywhere in the checkout. That is a harder case, and honesty demands saying so: funds sent on an unsupported network to a processor's address are recoverable only at the processor's discretion. There is no protocol-level mechanism to pull them back. Some processors do recover them; it is a manual, slow, best-effort process.

Step 3: Contact support properly

The difference between a resolved ticket and a ticket that sits for a week is almost entirely in how the first message is written. Send one message containing everything, rather than a short message followed by five clarifications.

Include, in this order:

1. Your OpenRouter account email.
2. One sentence stating the problem: on-chain transfer confirmed, credits not applied.
3. The invoice or payment link identifier.
4. Transaction hash, network, token contract address, exact amount, timestamp in UTC.
5. A block explorer URL to the transaction.
6. What you want: credits applied, or a refund to the sending address.

Contact both parties where relevant. OpenRouter support handles the credit side; the payment processor holds the funds. If your transfer went to a network the invoice did not cover, the processor is the party who can actually locate the money.

Realistic timelines, based on cases we have tracked: straightforward cases where the payment is visible in the checkout as underpaid or delayed typically resolve in a few business days. Wrong-network and wrong-token cases regularly run one to three weeks, and some go unanswered. Multiple users have reported a full week with no first response on this category of ticket. Plan accordingly — if you have production traffic depending on that balance, do not wait on the ticket. Fund the account another way and treat the stuck transfer as a separate recovery effort.

Escalating politely works better than escalating loudly. Reply on your own ticket every three to four business days with a one-line bump that re-states the transaction hash. Do not open duplicate tickets; on most helpdesks that resets your queue position.

Step 4: Avoid it next time

Three approaches, from most conservative to most convenient.

Use exactly the chain and token the invoice specifies, and nothing else. Read the checkout page before you touch your wallet. Confirm the network name matches your withdrawal screen exactly — USDC in your exchange's dropdown is not enough information. Send the exact amount, not a rounded-up one. Send immediately after generating the invoice, not an hour later.

Fund from an account that lets you choose the network deliberately. If your only USDC is on a chain the invoice does not take, bridge it before generating the invoice, not during. Generating an invoice and then starting a 20-minute bridge is how expiries happen.

Or use a checkout that accepts what you actually hold. This is the category the problem belongs to: the failure is caused by a narrow accepted-asset list, so a wider one removes it. ROZO Checkout at checkout.rozo.ai is one option here — you paste your OpenRouter payment link and pay with USDT, USDC on Solana or Stellar or BNB Chain, or Bitcoin over Lightning, and it settles to USDC on your behalf. The wrong-network class of failure does not arise because you are not asked to match a single specific chain.

It is not the only option, and the tradeoff is worth stating: you are routing through a third party rather than paying the merchant's processor directly, and ROZO is independent of OpenRouter and Coinbase. Some people will prefer the direct path with careful network selection, and that is a perfectly reasonable choice. Others already hold USDT or sats and have no direct path at all. Pick on that basis.

Whichever route you choose, the durable habit is the same: before you sign, check the network and the token contract, not just the ticker and the number.