¿Enviaste cripto a OpenRouter y los credits nunca llegaron? Por qué pasa y qué hacer

Este es uno de los fallos más comunes y peor documentados de la facturación de APIs de IA, y no es un error de tu billetera. Es un desajuste estructural entre lo que los usuarios de cripto creen que están haciendo y lo que realmente acepta el procesador de pagos que hay detrás del checkout. Esta página explica la causa, te da un procedimiento realista de recuperación y plantea expectativas honestas sobre los plazos.

Verificado el 10 de agosto de 2026. El comportamiento del procesador de pagos y las listas de cadenas soportadas cambian, así que confirma la red aceptada en la página de checkout en vivo antes de enviar.

La versión corta

OpenRouter no procesa los pagos en cripto por sí mismo. Usa un checkout cripto alojado — Coinbase Commerce — que acredita un pago solo cuando la transferencia entrante coincide con una combinación exacta de cadena y token que esa factura concreta fue creada para aceptar.

Envía el token correcto en la cadena equivocada, o el token equivocado en la cadena correcta, y el dinero llega a una dirección real controlada por un procesador real, pero nada en el sistema lo conecta con tu factura. No hay pantalla de error. La transacción tiene éxito. La factura se queda impaga hasta que caduca.

Ese hueco — una transferencia on-chain exitosa que aun así es un pago no reconocido — es donde vive casi cada uno de estos casos.

Qué sale mal en realidad, por orden de frecuencia

1. Token correcto, red equivocada. De lejos, lo más común. USDC existe en Ethereum, Base, Polygon, Solana, Arbitrum, Optimism, Avalanche y más. Son tokens distintos, con contratos distintos, que casualmente comparten nombre y precio. Un caso típico: un usuario retira USDC de un exchange grande, elige Polygon porque la comisión de retiro es la más baja, envía algo menos de 15 dólares y la transferencia se confirma en segundos. La factura esperaba otra red. Los fondos aterrizan en la dirección de Polygon del procesador, que la factura nunca vigila. No se acredita nada y no falla nada. La pantalla de retiro del exchange es donde se toma esa decisión, y casi siempre se toma en función de la comisión, no de lo que pedía la factura.
2. USDT donde solo se acepta USDC. Los usuarios tratan USDT y USDC como intercambiables porque ambos siguen al dólar. Los procesadores de pago no. Una factura denominada en USDC no acepta USDT ni siquiera en la misma cadena. Un patrón que hemos visto repetidamente: una transferencia de USDT por Solana se confirma on-chain, el emisor tiene una firma válida y un tick verde en su billetera, y el saldo de OpenRouter nunca se mueve. Otro: una cantidad pequeña de USDT enviada por Polygon, todavía sin acreditar una semana después, y aún sin respuesta en el ticket.
3. Pago hecho a través de un agregador o una ruta de swap. Pagar vía un agregador de swaps o un router DEX en lugar de una transferencia directa desde la billetera puede cambiar lo que la dirección receptora ve realmente: la dirección del emisor, la ruta del token y a veces el token mismo. Un usuario pagó unos 15 USDC a través de un agregador de Solana; el swap se ejecutó, los fondos se movieron y no aparecieron credits. Las transferencias directas desde una billetera que controlas son mucho más seguras para pagar facturas que cualquier cosa enrutada por un swap.
4. Monto que no coincide, incluido el pago de más. Si pagas de menos, la factura sigue abierta, obviamente. Pero pagar de más también puede romper la acreditación automática en algunas configuraciones del procesador, porque el monto recibido no coincide con el esperado y el pago queda marcado para gestión manual en vez de liquidarse solo. Enviar un poco de más para cubrir comisiones no es la jugada segura que parece.
5. La factura caducó antes de que la transferencia se confirmara. Las facturas cripto alojadas tienen una ventana de tiempo, normalmente de 15 a 60 minutos. Si generas la factura, te pones a hacer otra cosa y envías una hora después — o si envías durante congestión de red — la transferencia puede llegar cuando la ventana ya cerró. La dirección sigue siendo real. La factura ya no está escuchando.

Paso 1: Confirma qué enviaste exactamente

Antes de contactar a nadie, reúne los datos. Soporte no puede ayudarte sin ellos, y puede que encuentres la respuesta tú mismo en cinco minutos.

Abre el explorador de bloques de la cadena que usaste y busca tu transacción. Anota:

• Hash de la transacción — la cadena completa, no una captura de pantalla de una versión truncada.
• Red — la cadena real, por ejemplo Polygon PoS, Solana mainnet, Base.
• Dirección del contrato del token — este es el campo que resuelve definitivamente la duda entre USDC y USDT.
• Monto exacto — con toda la precisión decimal.
• Dirección receptora — dónde acabaron los fondos.
• Marca de tiempo — en UTC.
• Dirección emisora — la billetera desde la que pagaste.

Luego compáralo con la factura: ¿qué cadena y qué token pedía la página de checkout, y cuál era la hora de caducidad de la factura? Si todavía tienes la página de la factura o el correo, ahí está. A estas alturas normalmente ya sabes cuál de las cinco causas te tocó.

Paso 2: Comprueba si los fondos ya se ven en algún sitio

Vale la pena revisar dos cosas antes de escalar.

¿El pago aparece como pendiente o sin resolver en el checkout? Los checkouts cripto alojados suelen tener un estado de pago de menos, pago de más o retrasado que una persona puede resolver. Si tu pago aparece siquiera ahí, tu caso es mucho más sólido.

¿Recibiste algún correo del procesador de pagos? Coinbase Commerce envía sus propias notificaciones, independientes de OpenRouter. Busca en tu bandeja de entrada — incluido el spam — la factura.

Si los fondos aterrizaron en una cadena que la factura nunca vigiló, no aparecerán en ninguna parte del checkout. Ese caso es más difícil, y la honestidad obliga a decirlo: los fondos enviados por una red no soportada a la dirección de un procesador solo son recuperables a discreción del procesador. No existe ningún mecanismo a nivel de protocolo para traerlos de vuelta. Algunos procesadores sí los recuperan; es un proceso manual, lento y de mejor esfuerzo.

Paso 3: Contacta a soporte como corresponde

La diferencia entre un ticket resuelto y un ticket que se queda una semana parado está casi por completo en cómo está escrito el primer mensaje. Envía un solo mensaje que lo contenga todo, en vez de un mensaje corto seguido de cinco aclaraciones.

Incluye, en este orden:

1. El correo de tu cuenta de OpenRouter.
2. Una frase que enuncie el problema: transferencia on-chain confirmada, credits no aplicados.
3. El identificador de la factura o del payment link.
4. Hash de la transacción, red, dirección del contrato del token, monto exacto, marca de tiempo en UTC.
5. Una URL del explorador de bloques que apunte a la transacción.
6. Qué quieres: que se apliquen los credits, o un reembolso a la dirección emisora.

Contacta a ambas partes cuando corresponda. El soporte de OpenRouter se ocupa del lado de los credits; el procesador de pagos tiene los fondos. Si tu transferencia fue a una red que la factura no cubría, el procesador es quien realmente puede localizar el dinero.

Plazos realistas, según los casos que hemos seguido: los casos sencillos, en los que el pago se ve en el checkout como pago de menos o retrasado, suelen resolverse en unos pocos días hábiles. Los casos de red equivocada y token equivocado se van con frecuencia a una a tres semanas, y algunos quedan sin respuesta. Varios usuarios han reportado una semana entera sin una primera respuesta en este tipo de ticket. Planifica en consecuencia: si tienes tráfico en producción que depende de ese saldo, no esperes al ticket. Recarga la cuenta por otra vía y trata la transferencia atascada como un esfuerzo de recuperación aparte.

Escalar con educación funciona mejor que escalar a gritos. Responde en tu propio ticket cada tres o cuatro días hábiles con un recordatorio de una línea que repita el hash de la transacción. No abras tickets duplicados; en la mayoría de los helpdesks eso reinicia tu posición en la cola.

Paso 4: Evítalo la próxima vez

Tres enfoques, del más conservador al más cómodo.

Usa exactamente la cadena y el token que especifica la factura, y nada más. Lee la página de checkout antes de tocar tu billetera. Confirma que el nombre de la red coincide exactamente con el de tu pantalla de retiro — ver USDC en el desplegable de tu exchange no es información suficiente. Envía el monto exacto, no uno redondeado hacia arriba. Envía justo después de generar la factura, no una hora más tarde.

Paga desde una cuenta que te deje elegir la red de forma deliberada. Si tu único USDC está en una cadena que la factura no acepta, haz el bridge antes de generar la factura, no durante. Generar una factura y ponerse entonces a hacer un bridge de 20 minutos es como ocurren las caducidades.

O usa un checkout que acepte lo que realmente tienes. A esta categoría pertenece el problema: el fallo lo causa una lista estrecha de activos aceptados, así que una más amplia lo elimina. ROZO Checkout, en checkout.rozo.ai, es una opción aquí: pegas tu payment link de OpenRouter y pagas con USDT, con USDC en Solana, Stellar o BNB Chain, o con Bitcoin por Lightning, y él liquida en USDC por ti. La clase de fallo por red equivocada no aparece porque no se te pide acertar con una única cadena concreta.

No es la única opción, y conviene decir el tradeoff: estás pasando por un tercero en vez de pagar directamente al procesador del comercio, y ROZO es independiente de OpenRouter y de Coinbase. Habrá quien prefiera la vía directa con una selección cuidadosa de la red, y esa es una elección perfectamente razonable. Otros ya tienen USDT o sats y no tienen ninguna vía directa. Elige con ese criterio.

Sea cual sea la ruta que elijas, el hábito duradero es el mismo: antes de firmar, revisa la red y el contrato del token, no solo el ticker y el número.