Vous avez envoyé des cryptos à OpenRouter mais les credits ne sont jamais arrivés ? Voici pourquoi, et que faire

C'est l'un des modes de défaillance les plus fréquents et les moins bien documentés de la facturation des API d'IA, et ce n'est pas un bug de votre wallet. C'est un décalage structurel entre ce que les utilisateurs de cryptos croient faire et ce que le prestataire de paiement derrière le checkout accepte réellement. Cette page explique la cause, vous donne une procédure de récupération réaliste, et fixe des attentes honnêtes quant aux délais.

Vérifié le 10 août 2026. Le comportement des prestataires de paiement et la liste des chaînes prises en charge évoluent : confirmez donc le réseau accepté sur la page de checkout en direct avant d'envoyer.

En résumé

OpenRouter ne traite pas lui-même les paiements en cryptos. Il utilise un checkout crypto hébergé — Coinbase Commerce — qui ne crédite un paiement que lorsque le transfert entrant correspond à une combinaison exacte de chaîne et de token que la facture concernée a été créée pour accepter.

Envoyez le bon token sur la mauvaise chaîne, ou le mauvais token sur la bonne chaîne, et l'argent arrive à une adresse réelle contrôlée par un prestataire réel, mais rien dans le système ne le relie à votre facture. Il n'y a aucun écran d'erreur. La transaction réussit. La facture reste impayée jusqu'à son expiration.

Cet écart — un transfert on-chain réussi qui constitue néanmoins un paiement non reconnu — est là où se situent presque tous ces cas.

Ce qui déraille réellement, par ordre de fréquence

1. Bon token, mauvais réseau. De loin le cas le plus fréquent. L'USDC existe sur Ethereum, Base, Polygon, Solana, Arbitrum, Optimism, Avalanche, et d'autres encore. Ce sont des tokens différents, avec des adresses de contrat différentes, qui partagent simplement un nom et un prix. Un cas typique : un utilisateur retire de l'USDC depuis une grande plateforme d'échange, choisit Polygon parce que les frais de retrait y sont les plus bas, envoie un peu moins de 15 $, et le transfert se confirme en quelques secondes. La facture attendait un autre réseau. Les fonds atterrissent sur l'adresse Polygon du prestataire, que la facture ne surveille jamais. Rien n'est crédité, et rien ne signale d'erreur. C'est sur l'écran de retrait de la plateforme que cette décision se prend, et elle se prend presque toujours en fonction des frais, pas de ce que la facture demandait.
2. De l'USDT alors que seul l'USDC est accepté. Les utilisateurs traitent l'USDT et l'USDC comme interchangeables parce que les deux suivent le dollar. Les prestataires de paiement, non. Une facture libellée en USDC n'accepte pas l'USDT, même sur la même chaîne. Un schéma que nous avons vu à plusieurs reprises : un transfert d'USDT via Solana se confirme on-chain, l'expéditeur dispose d'une signature valide et d'une coche verte dans son wallet, et le solde OpenRouter ne bouge jamais. Un autre : un petit montant d'USDT envoyé via Polygon, toujours non crédité une semaine plus tard, sans réponse au ticket.
3. Paiement via un agrégateur ou une route de swap. Payer via un agrégateur de swap ou un routeur DEX plutôt que par un transfert direct depuis un wallet peut changer ce que l'adresse réceptrice voit réellement — l'adresse d'expédition, le chemin du token, et parfois le token lui-même. Un utilisateur a payé environ 15 USDC via un agrégateur Solana ; le swap s'est exécuté, les fonds ont bougé, et aucun credit n'est apparu. Les transferts directs depuis un wallet que vous contrôlez sont bien plus sûrs pour payer une facture que tout ce qui passe par un swap.
4. Montant qui ne correspond pas, y compris en cas de trop-perçu. Si vous payez trop peu, la facture reste ouverte, évidemment. Mais payer trop peut aussi casser le crédit automatique sur certaines configurations de prestataire, car le montant reçu ne correspond pas au montant attendu et le paiement est signalé pour un traitement manuel au lieu d'être réglé automatiquement. Envoyer un peu plus pour couvrir les frais n'est pas le geste sûr qu'on imagine.
5. Facture expirée avant la confirmation du transfert. Les factures crypto hébergées comportent une fenêtre temporelle, généralement de 15 à 60 minutes. Si vous générez la facture, allez faire autre chose et envoyez une heure plus tard — ou si vous envoyez pendant une congestion du réseau — le transfert peut arriver après la fermeture de la fenêtre. L'adresse est toujours réelle. La facture, elle, n'écoute plus.

Étape 1 : confirmez ce que vous avez réellement envoyé

Avant de contacter qui que ce soit, rassemblez les faits. Le support ne peut rien faire sans eux, et vous trouverez peut-être la réponse vous-même en cinq minutes.

Ouvrez l'explorateur de blocs de la chaîne utilisée et affichez votre transaction. Notez :

• Hash de transaction — la chaîne complète, pas une capture d'écran d'une version tronquée.
• Réseau — la chaîne réelle, par exemple Polygon PoS, Solana mainnet, Base.
• Adresse du contrat du token — c'est le champ qui tranche définitivement la question USDC contre USDT.
• Montant exact — avec toute la précision décimale.
• Adresse réceptrice — là où les fonds ont fini.
• Horodatage — en UTC.
• Adresse d'expédition — le wallet depuis lequel vous avez payé.

Comparez ensuite avec la facture : quelle chaîne et quel token la page de checkout demandait-elle, et quelle était l'heure d'expiration de la facture ? Si vous avez encore la page de facture ou l'e-mail, l'information s'y trouve. À ce stade, vous savez généralement laquelle des cinq causes vous concerne.

Étape 2 : vérifiez si les fonds sont déjà visibles quelque part

Deux choses méritent d'être vérifiées avant d'escalader.

Le paiement apparaît-il comme en attente ou non résolu dans le checkout ? Les checkouts crypto hébergés ont souvent un état « sous-payé », « trop-payé » ou « retardé » qu'un humain peut résoudre. Si votre paiement y apparaît d'une quelconque manière, votre dossier est bien plus solide.

Avez-vous reçu un e-mail du prestataire de paiement ? Coinbase Commerce envoie ses propres notifications, indépendamment d'OpenRouter. Cherchez dans votre boîte de réception — y compris les spams — la facture.

Si les fonds ont atterri sur une chaîne que la facture ne surveillait pas, ils n'apparaîtront nulle part dans le checkout. C'est un cas plus difficile, et l'honnêteté impose de le dire : des fonds envoyés sur un réseau non pris en charge vers l'adresse d'un prestataire ne sont récupérables qu'à la discrétion de celui-ci. Il n'existe aucun mécanisme au niveau du protocole pour les rappeler. Certains prestataires les récupèrent ; c'est un processus manuel, lent, sans garantie de résultat.

Étape 3 : contactez le support correctement

La différence entre un ticket résolu et un ticket qui traîne une semaine tient presque entièrement à la façon dont le premier message est rédigé. Envoyez un seul message contenant tout, plutôt qu'un message court suivi de cinq clarifications.

Incluez, dans cet ordre :

1. L'e-mail de votre compte OpenRouter.
2. Une phrase énonçant le problème : transfert on-chain confirmé, credits non appliqués.
3. L'identifiant de la facture ou du payment link.
4. Hash de transaction, réseau, adresse du contrat du token, montant exact, horodatage en UTC.
5. Une URL d'explorateur de blocs pointant vers la transaction.
6. Ce que vous voulez : des credits appliqués, ou un remboursement vers l'adresse d'expédition.

Contactez les deux parties lorsque c'est pertinent. Le support d'OpenRouter gère le volet credits ; le prestataire de paiement détient les fonds. Si votre transfert est parti vers un réseau que la facture ne couvrait pas, c'est le prestataire qui peut réellement localiser l'argent.

Délais réalistes, d'après les cas que nous avons suivis : les cas simples, où le paiement est visible dans le checkout comme sous-payé ou retardé, se résolvent généralement en quelques jours ouvrés. Les cas de mauvais réseau ou de mauvais token prennent régulièrement une à trois semaines, et certains restent sans réponse. Plusieurs utilisateurs ont signalé une semaine entière sans première réponse sur ce type de ticket. Planifiez en conséquence : si du trafic en production dépend de ce solde, n'attendez pas le ticket. Approvisionnez le compte autrement et traitez le transfert bloqué comme un effort de récupération distinct.

Escalader poliment fonctionne mieux qu'escalader bruyamment. Répondez sur votre propre ticket tous les trois à quatre jours ouvrés par une relance d'une ligne rappelant le hash de transaction. N'ouvrez pas de tickets en double ; sur la plupart des helpdesks, cela réinitialise votre position dans la file.

Étape 4 : éviter le problème la prochaine fois

Trois approches, de la plus prudente à la plus pratique.

Utilisez exactement la chaîne et le token que la facture indique, et rien d'autre. Lisez la page de checkout avant de toucher à votre wallet. Vérifiez que le nom du réseau correspond exactement à celui de votre écran de retrait — « USDC » dans le menu déroulant de votre plateforme n'est pas une information suffisante. Envoyez le montant exact, pas un montant arrondi à la hausse. Envoyez immédiatement après avoir généré la facture, pas une heure plus tard.

Approvisionnez depuis un compte qui vous laisse choisir le réseau délibérément. Si votre seul USDC se trouve sur une chaîne que la facture n'accepte pas, faites le bridge avant de générer la facture, pas pendant. Générer une facture puis lancer un bridge de 20 minutes, c'est ainsi que surviennent les expirations.

Ou utilisez un checkout qui accepte ce que vous détenez réellement. C'est la catégorie à laquelle appartient le problème : la défaillance est causée par une liste d'actifs acceptés trop étroite, donc une liste plus large la supprime. ROZO Checkout, sur checkout.rozo.ai, est une option possible : vous collez votre payment link OpenRouter et payez en USDT, en USDC sur Solana, Stellar ou BNB Chain, ou en Bitcoin via Lightning, et le règlement se fait en USDC pour votre compte. La classe de défaillance liée au mauvais réseau ne se présente pas, puisqu'on ne vous demande pas de correspondre à une chaîne unique et précise.

Ce n'est pas la seule option, et le compromis mérite d'être énoncé : vous passez par un tiers plutôt que de payer directement le prestataire du marchand, et ROZO est indépendant d'OpenRouter et de Coinbase. Certains préféreront la voie directe avec une sélection soigneuse du réseau, et c'est un choix parfaitement raisonnable. D'autres détiennent déjà de l'USDT ou des sats et n'ont aucune voie directe. Choisissez sur cette base.

Quelle que soit la voie retenue, la bonne habitude durable est la même : avant de signer, vérifiez le réseau et le contrat du token, pas seulement le ticker et le montant.