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
- 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.
- 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.
- 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.
- 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. Si pagaste con ROZO Checkout y enviaste de menos, la solución es más sencilla: antes de que caduque el pedido, envía la diferencia a la misma dirección, en la misma red y en la misma moneda, y el pedido continúa. Detalles: Envié menos del importe de la factura a ROZO Checkout. ¿Qué pasa ahora?
- 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:
- El correo de tu cuenta de OpenRouter.
- Una frase que enuncie el problema: transferencia on-chain confirmada, credits no aplicados.
- El identificador de la factura o del payment link.
- Hash de la transacción, red, dirección del contrato del token, monto exacto, marca de tiempo en UTC.
- Una URL del explorador de bloques que apunte a la transacción.
- 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.
Dos casos recientes y cómo se resolvieron
Dos hilos de soporte del Discord de la comunidad de OpenRouter en octubre de 2026 muestran los dos tipos de fallo y cuánto tardó cada uno.
Token equivocado en la red correcta. Un usuario recargó 10,80 $ mediante el checkout cripto de Stripe en Polygon el 14 de octubre. La transferencia fue en USDT, pero ese checkout solo acepta USDC en Polygon, así que no se acreditó nada automáticamente. El saldo de la cuenta quedó ligeramente negativo y bloqueó su trabajo. Soporte localizó el pago y lo acreditó manualmente seis días después.
Faltaba la comisión de procesamiento. Otro usuario envió 19 USDC en Solana el 4 de agosto. El checkout pedía 20,05 USDC: los 19 $ de crédito más la comisión. Como el pago fue insuficiente, el procesador no lo completó y la sesión caducó. Tras cuatro tickets distintos y unos dos meses y medio, soporte añadió los 19 $ manualmente y fusionó los tickets duplicados en uno.
Lo que tienen en común: el dinero llegó, soporte pudo encontrarlo con el hash de la transacción y la solución fue un crédito manual. La diferencia de tiempo vino sobre todo de cómo se presentó cada caso. Un hilo con el hash y la red indicados desde el principio se cerró en menos de una semana. Varios tickets por el mismo pago tardaron meses.
La regla que indica OpenRouter: un pago cripto coincidente que siga sin acreditarse tras dos horas necesita un crédito manual de soporte. Responde en tu ticket existente con el hash, la red, el importe exacto y la factura, en lugar de abrir uno nuevo.
Si quieres pagar con USDT en Polygon, pega tu enlace de pago de OpenRouter en ROZO Checkout, en checkout.rozo.ai. Acepta USDT en Polygon y liquida la factura en USDC por ti.
Dos casos recientes y cómo se resolvieron
Dos hilos de soporte del Discord de la comunidad de OpenRouter en octubre de 2026 muestran los dos tipos de fallo y cuánto tardó cada uno.
Token equivocado en la red correcta. Un usuario recargó 10,80 $ mediante el checkout cripto de Stripe en Polygon el 14 de octubre. La transferencia fue en USDT, pero ese checkout solo acepta USDC en Polygon, así que no se acreditó nada automáticamente. El saldo de la cuenta quedó ligeramente negativo y bloqueó su trabajo. Soporte localizó el pago y lo acreditó manualmente seis días después.
Faltaba la comisión de procesamiento. Otro usuario envió 19 USDC en Solana el 4 de agosto. El checkout pedía 20,05 USDC: los 19 $ de crédito más la comisión. Como el pago fue insuficiente, el procesador no lo completó y la sesión caducó. Tras cuatro tickets distintos y unos dos meses y medio, soporte añadió los 19 $ manualmente y fusionó los tickets duplicados en uno.
Lo que tienen en común: el dinero llegó, soporte pudo encontrarlo con el hash de la transacción y la solución fue un crédito manual. La diferencia de tiempo vino sobre todo de cómo se presentó cada caso. Un hilo con el hash y la red indicados desde el principio se cerró en menos de una semana. Varios tickets por el mismo pago tardaron meses.
La regla que indica OpenRouter: un pago cripto coincidente que siga sin acreditarse tras dos horas necesita un crédito manual de soporte. Responde en tu ticket existente con el hash, la red, el importe exacto y la factura, en lugar de abrir uno nuevo.
Si quieres pagar con USDT en Polygon, pega tu enlace de pago de OpenRouter en ROZO Checkout, en checkout.rozo.ai. Acepta USDT en Polygon y liquida la factura en USDC por ti.