Enviou cripto para a OpenRouter e os credits nunca chegaram? Veja por quê e o que fazer

Esse é um dos modos de falha mais comuns e menos documentados no faturamento de APIs de IA, e não é um bug na sua carteira. É um descompasso estrutural entre o que os usuários de cripto acham que estão fazendo e o que o processador de pagamentos por trás do checkout realmente aceita. Esta página explica a causa, dá um procedimento realista de recuperação e estabelece expectativas honestas sobre prazos.

Verificado em 10 de agosto de 2026. O comportamento do processador de pagamentos e as listas de redes suportadas mudam, então confirme a rede aceita na página de checkout ao vivo antes de enviar.

A versão curta

A OpenRouter não processa pagamentos em cripto por conta própria. Ela usa um checkout de cripto hospedado — o Coinbase Commerce — que credita um pagamento apenas quando a transferência recebida corresponde a uma combinação exata de rede e token que aquela fatura específica foi criada para aceitar.

Envie o token certo na rede errada, ou o token errado na rede certa, e o dinheiro chega a um endereço real controlado por um processador real, mas nada no sistema o conecta à sua fatura. Não há tela de erro. A transação é bem-sucedida. A fatura fica sem pagamento até expirar.

Essa lacuna — uma transferência on-chain bem-sucedida que, ainda assim, é um pagamento não reconhecido — é onde vive quase todo caso desse tipo.

O que de fato dá errado, em ordem de frequência

1. Token certo, rede errada. De longe o mais comum. USDC existe em Ethereum, Base, Polygon, Solana, Arbitrum, Optimism, Avalanche e mais. São tokens diferentes, com endereços de contrato diferentes, que por acaso compartilham um nome e um preço. Um caso típico: o usuário saca USDC de uma grande exchange, escolhe Polygon porque a taxa de saque é a menor, envia pouco menos de US$ 15, e a transferência confirma em segundos. A fatura esperava outra rede. Os fundos caem no endereço Polygon do processador, que a fatura nunca observa. Nada é creditado, e nada dá erro. É na tela de saque da exchange que essa decisão é tomada, e ela quase sempre é tomada com base na taxa, não no que a fatura pediu.
2. USDT onde só USDC é aceito. Os usuários tratam USDT e USDC como intercambiáveis porque ambos acompanham o dólar. Os processadores de pagamento, não. Uma fatura denominada em USDC não aceita USDT nem na mesma rede. Um padrão que vimos repetidamente: uma transferência de USDT pela Solana confirma on-chain, o remetente tem uma assinatura válida e um check verde na carteira, e o saldo da OpenRouter nunca se move. Outro: um valor pequeno de USDT enviado pela Polygon, ainda não creditado uma semana depois, sem resposta no ticket.
3. Pagamento feito por um agregador ou rota de swap. Pagar por um agregador de swap ou roteador DEX em vez de uma transferência direta da carteira pode mudar o que o endereço recebedor realmente enxerga — o endereço remetente, o caminho do token e, às vezes, o próprio token. Um usuário pagou cerca de 15 USDC por um agregador na Solana; o swap foi executado, os fundos se moveram e nenhum credit apareceu. Transferências diretas de uma carteira que você controla são muito mais seguras para pagar faturas do que qualquer coisa roteada por um swap.
4. Valor divergente, incluindo pagamento a mais. Pagar a menos deixa a fatura aberta, obviamente. Mas pagar a mais também pode quebrar o crédito automático em algumas configurações de processador, porque o valor recebido não corresponde ao valor esperado e o pagamento é marcado para tratamento manual em vez de liquidação automática. Enviar um pouco a mais para cobrir taxas não é a jogada segura que parece ser.
5. A fatura expirou antes de a transferência confirmar. Faturas de cripto hospedadas têm uma janela de tempo, comumente de 15 a 60 minutos. Se você gera a fatura, vai fazer outra coisa e envia uma hora depois — ou se envia durante congestionamento da rede — a transferência pode chegar depois de a janela fechar. O endereço continua real. A fatura já não está escutando.

Passo 1: confirme o que você realmente enviou

Antes de falar com alguém, junte os fatos. O suporte não consegue ajudar sem eles, e você pode encontrar a resposta sozinho em cinco minutos.

Abra o block explorer da rede que você usou e localize sua transação. Anote:

• Hash da transação — a string completa, não um print de uma versão truncada.
• Rede — a rede de fato, por exemplo Polygon PoS, Solana mainnet, Base.
• Endereço do contrato do token — este é o campo que resolve em definitivo a questão USDC versus USDT.
• Valor exato — com precisão decimal completa.
• Endereço recebedor — onde os fundos foram parar.
• Data e hora — em UTC.
• Endereço remetente — a carteira de onde você pagou.

Depois compare com a fatura: qual rede e qual token a página de checkout pediu, e qual era o horário de expiração da fatura? Se você ainda tem a página da fatura ou o e-mail, essa informação está lá. A essa altura você normalmente já sabe qual das cinco causas atingiu você.

Passo 2: verifique se os fundos já aparecem em algum lugar

Duas coisas valem a checagem antes de escalar.

O pagamento aparece como pendente ou não resolvido no checkout? Checkouts de cripto hospedados costumam ter um estado de pagamento a menos, a mais ou atrasado que um humano pode resolver. Se o seu pagamento aparece ali de alguma forma, seu caso fica muito mais forte.

Você recebeu algum e-mail do processador de pagamentos? O Coinbase Commerce envia suas próprias notificações, independentemente da OpenRouter. Procure na sua caixa de entrada — inclusive no spam — pela fatura.

Se os fundos caíram em uma rede que a fatura nunca observou, eles não vão aparecer em lugar nenhum do checkout. Esse é um caso mais difícil, e a honestidade exige dizer: fundos enviados em uma rede não suportada para o endereço de um processador só são recuperáveis a critério do processador. Não existe mecanismo em nível de protocolo para trazê-los de volta. Alguns processadores conseguem recuperá-los; é um processo manual, lento e de melhor esforço.

Passo 3: fale com o suporte do jeito certo

A diferença entre um ticket resolvido e um ticket que fica parado uma semana está quase inteiramente em como a primeira mensagem é escrita. Mande uma única mensagem com tudo, em vez de uma mensagem curta seguida de cinco esclarecimentos.

Inclua, nesta ordem:

1. O e-mail da sua conta na OpenRouter.
2. Uma frase dizendo o problema: transferência on-chain confirmada, credits não aplicados.
3. O identificador da fatura ou do payment link.
4. Hash da transação, rede, endereço do contrato do token, valor exato, data e hora em UTC.
5. Uma URL do block explorer para a transação.
6. O que você quer: credits aplicados ou reembolso para o endereço remetente.

Fale com as duas partes quando fizer sentido. O suporte da OpenRouter cuida do lado dos credits; o processador de pagamentos é quem está com os fundos. Se a sua transferência foi para uma rede que a fatura não cobria, o processador é a parte que consegue de fato localizar o dinheiro.

Prazos realistas, com base em casos que acompanhamos: casos simples, em que o pagamento aparece no checkout como pago a menos ou atrasado, normalmente se resolvem em alguns dias úteis. Casos de rede errada e token errado costumam levar de uma a três semanas, e alguns ficam sem resposta. Vários usuários relataram uma semana inteira sem a primeira resposta nessa categoria de ticket. Planeje-se de acordo — se você tem tráfego em produção dependendo desse saldo, não fique esperando o ticket. Recarregue a conta por outro caminho e trate a transferência travada como um esforço de recuperação separado.

Escalar com educação funciona melhor do que escalar aos gritos. Responda no seu próprio ticket a cada três ou quatro dias úteis com um lembrete de uma linha que repita o hash da transação. Não abra tickets duplicados; na maioria dos helpdesks isso zera a sua posição na fila.

Passo 4: evite o problema da próxima vez

Três abordagens, da mais conservadora à mais conveniente.

Use exatamente a rede e o token que a fatura especifica, e nada mais. Leia a página de checkout antes de encostar na carteira. Confirme que o nome da rede bate exatamente com a sua tela de saque — USDC no menu da sua exchange não é informação suficiente. Envie o valor exato, não um valor arredondado para cima. Envie logo depois de gerar a fatura, não uma hora depois.

Use uma conta que permita escolher a rede de forma deliberada. Se o seu único USDC está em uma rede que a fatura não aceita, faça a ponte antes de gerar a fatura, não durante. Gerar uma fatura e só então começar uma ponte de 20 minutos é como as expirações acontecem.

Ou use um checkout que aceite o que você realmente tem. É a essa categoria que o problema pertence: a falha é causada por uma lista estreita de ativos aceitos, então uma lista mais ampla a elimina. O ROZO Checkout, em checkout.rozo.ai, é uma opção aqui — você cola o seu OpenRouter payment link e paga com USDT, USDC na Solana, na Stellar ou na BNB Chain, ou Bitcoin pela Lightning, e ele liquida em USDC por você. A classe de falha de rede errada não surge, porque não pedem que você acerte uma única rede específica.

Não é a única opção, e vale explicitar o trade-off: você está roteando por um terceiro em vez de pagar direto ao processador do comerciante, e a ROZO é independente da OpenRouter e da Coinbase. Algumas pessoas vão preferir o caminho direto com uma seleção cuidadosa de rede, e essa é uma escolha perfeitamente razoável. Outras já têm USDT ou sats e não têm caminho direto nenhum. Decida com base nisso.

Seja qual for a rota escolhida, o hábito duradouro é o mesmo: antes de assinar, confira a rede e o contrato do token, não só o ticker e o número.