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. Se você pagou pelo ROZO Checkout e enviou a menos, a solução é mais simples: antes de o pedido expirar, envie a diferença para o mesmo endereço, na mesma rede e na mesma moeda, e o pedido continua. Detalhes: Enviei menos do que o valor da fatura para o ROZO Checkout. E agora?
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.

Dois casos recentes e como foram resolvidos

Dois tópicos de suporte do Discord da comunidade OpenRouter em outubro de 2026 mostram os dois tipos de falha e quanto tempo cada um levou.

Token errado na rede certa. Um usuário recarregou US$ 10,80 pelo checkout cripto da Stripe na Polygon em 14 de outubro. A transferência foi em USDT, mas esse checkout aceita apenas USDC na Polygon, então nada foi creditado automaticamente. O saldo da conta ficou levemente negativo e bloqueou o trabalho. O suporte localizou o pagamento e o creditou manualmente seis dias depois.

Faltou a taxa de processamento. Outro usuário enviou 19 USDC na Solana em 4 de agosto. O checkout exigia 20,05 USDC: os US$ 19 de crédito mais a taxa. Como o pagamento ficou abaixo do valor, o processador não o concluiu e a sessão expirou. Depois de quatro tickets diferentes e cerca de dois meses e meio, o suporte adicionou os US$ 19 manualmente e juntou os tickets duplicados em um só.

O que os dois têm em comum: o dinheiro chegou, o suporte conseguiu encontrá-lo pelo hash da transação e a solução foi um crédito manual. A diferença de tempo veio principalmente da forma como cada caso foi aberto. Um tópico com o hash e a rede informados logo de início foi resolvido em menos de uma semana. Vários tickets para o mesmo pagamento levaram meses.

A regra informada pela OpenRouter: um pagamento cripto correspondente que continue sem crédito após duas horas precisa de crédito manual do suporte. Responda no ticket existente com o hash, a rede, o valor exato e a fatura, em vez de abrir um novo.

Se quiser pagar com USDT na Polygon, cole o link de pagamento da OpenRouter no ROZO Checkout, em checkout.rozo.ai. Ele aceita USDT na Polygon e quita a fatura em USDC por você.

Dois casos recentes e como foram resolvidos

Dois tópicos de suporte do Discord da comunidade OpenRouter em outubro de 2026 mostram os dois tipos de falha e quanto tempo cada um levou.

Token errado na rede certa. Um usuário recarregou US$ 10,80 pelo checkout cripto da Stripe na Polygon em 14 de outubro. A transferência foi em USDT, mas esse checkout aceita apenas USDC na Polygon, então nada foi creditado automaticamente. O saldo da conta ficou levemente negativo e bloqueou o trabalho. O suporte localizou o pagamento e o creditou manualmente seis dias depois.

Faltou a taxa de processamento. Outro usuário enviou 19 USDC na Solana em 4 de agosto. O checkout exigia 20,05 USDC: os US$ 19 de crédito mais a taxa. Como o pagamento ficou abaixo do valor, o processador não o concluiu e a sessão expirou. Depois de quatro tickets diferentes e cerca de dois meses e meio, o suporte adicionou os US$ 19 manualmente e juntou os tickets duplicados em um só.

O que os dois têm em comum: o dinheiro chegou, o suporte conseguiu encontrá-lo pelo hash da transação e a solução foi um crédito manual. A diferença de tempo veio principalmente da forma como cada caso foi aberto. Um tópico com o hash e a rede informados logo de início foi resolvido em menos de uma semana. Vários tickets para o mesmo pagamento levaram meses.

A regra informada pela OpenRouter: um pagamento cripto correspondente que continue sem crédito após duas horas precisa de crédito manual do suporte. Responda no ticket existente com o hash, a rede, o valor exato e a fatura, em vez de abrir um novo.

Se quiser pagar com USDT na Polygon, cole o link de pagamento da OpenRouter no ROZO Checkout, em checkout.rozo.ai. Ele aceita USDT na Polygon e quita a fatura em USDC por você.