Diagnostica un pago Lightning fallido sin pagarlo dos veces
Tu wallet dice «pendiente» o «fallido» y el comercio no confirma el cobro. Aprende a localizar la invoice y su payment hash, consultar el estado real del intento y decidir si esperar, reintentar la misma invoice o pedir una nueva sin pagar dos veces.
Cuatro piezas de un pago Lightning
Invoice (BOLT11): la solicitud de cobro, con importe, descripción, destinatario y caducidad. Empieza por lnbc en mainnet.
Payment hash: el identificador del pago, incluido en la invoice. Es lo que debes usar para buscar el pago en emisor y receptor. No es una TXID: un pago Lightning ordinario no crea una transacción on-chain.
Intento de pago: uno o varios envíos (HTLC) por rutas de la red; un pago puede repartirse en varias partes. El emisor ve estados como en curso, completado o fallido.
Preimage: el secreto que el receptor revela al cobrar. Si tu wallet la muestra, es la prueba criptográfica de que el pago se completó. Repasa las diferencias entre invoice y QR en Invoice, Lightning Address y QR.
Pendiente no es fallido
Pending / In flight
Hay saldo bloqueado en un HTLC por la ruta. Terminará pagándose o devolviéndose; en casos raros puede tardar horas hasta que venza su plazo.
Complete / Succeeded
El receptor liquidó la invoice y tu nodo tiene la preimage. No vuelvas a pagar ese pedido.
Failed
Ningún intento llegó y el saldo volvió. Si la invoice sigue vigente, puedes reintentar la misma.
Que la app cierre una ventana, tarde o muestre un error temporal no demuestra que el pago falló. La decisión se toma con el estado final, no con la animación.
Siete pasos antes de volver a pagar
- PASO 1 · Reúne los datos: invoice original (la cadena
lnbc…), importe, hora del intento y referencia del pedido. No envíes semillas, contraseñas ni tokens a nadie para «revisarlo». - PASO 2 · Decodifica la invoice: en Core Lightning,
lightning-cli decode INVOICE; en LND,lncli decodepayreq INVOICE. Anota elpayment_hashy la caducidad. - PASO 3 · Estado en Core Lightning:
lightning-cli listpays bolt11=INVOICEolightning-cli listpays payment_hash=HASH. El estado serápending,completeofailed; si escomplete, aparece la preimage. - PASO 4 · Estado en LND:
lncli trackpayment HASHsigue un pago concreto;lncli listpaymentsmuestra el historial con estadosIN_FLIGHT,SUCCEEDEDoFAILEDy, si falló, un motivo (failure_reason). - PASO 5 · Wallet móvil: si no tienes línea de comandos, abre el detalle del pago en el historial de la app y busca su estado y, si la ofrece, la preimage o «prueba de pago».
- PASO 6 · Pregunta al receptor: pide que busque esa invoice concreta (por payment hash o referencia) y te diga si figura pagada, pendiente o caducada.
- PASO 7 · Decide: completado → comparte la prueba y no pagues más. En curso → espera; no pidas otra invoice. Fallido con invoice vigente → reintenta la misma. Fallido y caducada → pide una nueva que cite la anterior.
¿Tienes el payment hash y el estado final del emisor y del receptor antes de volver a pagar?
Un pedido de 15.000 sats que se queda «pendiente»
Pagas el pedido A-12 (15.000 sats) y la app se queda en «pendiente». El comercio dice que no le ha llegado y te ofrece una invoice nueva.
Lo correcto: no aceptas todavía la nueva. Consultas el pago por su payment hash: estado en curso. Esperas. Media hora después pasa a fallido y el saldo vuelve a tu canal. La invoice original caducaba a los 60 minutos y ya ha vencido, así que pides una nueva y le indicas al comercio el hash del primer intento para que conste.
Lo arriesgado: pagar la invoice nueva mientras la primera seguía en curso. Si la primera hubiera terminado liquidándose, habrías pagado dos veces el mismo pedido y dependerías de una devolución. Datos inventados para ilustrar la decisión.
Cinco situaciones habituales
🐥 La app dice «fallido» pero el comercio sí cobró
Algunas interfaces muestran el fallo de un intento parcial aunque otro haya llegado. Consulta el estado final del pago completo en tu nodo o en el historial: si es completado y hay preimage, el pago se hizo.
🐥 El motivo del fallo es «no route»
No se encontró camino con capacidad y comisiones aceptables. Puede deberse a tu liquidez saliente, a la entrante del receptor o a tu límite de comisión. Si el receptor eres tú, revisa la liquidez entrante de tus canales.
🐥 El error dice que la invoice ya está pagada
Es la protección contra pagar dos veces: ese payment hash ya figura como completado o en curso. Comprueba el historial antes de buscar otra explicación.
🐥 Llevo horas con el saldo bloqueado
Un HTLC atascado en un nodo intermedio se resuelve cuando se liquida o cuando vence su plazo. El saldo no se pierde por esperar. No cierres canales a la desesperada para «recuperarlo».
🐥 Me piden la seed para «desbloquear» el pago
Es una estafa. Ningún diagnóstico Lightning necesita tus palabras de recuperación. Usa solo la documentación oficial de tu wallet o nodo.
¿Puedes decidir sin pagar dos veces?
- Identificador: uso el payment hash, no una TXID.
- Emisor: distingo en curso, completado y fallido.
- Receptor: confirmo con él el estado de esa invoice concreta.
- Reintento: sé que reintentar la misma invoice no se cobra dos veces.
- Nueva invoice: solo la pido cuando el primer intento tiene estado final.
Un pago se cierra con un estado final, no con una espera
Ya sabes buscar un pago por su payment hash, leer su estado en emisor y receptor y elegir entre esperar, reintentar o pedir otra invoice. Esa secuencia evita los pagos duplicados.
Verifica los comandos en tu versión
Siguiente práctica: prepara una copia de recuperación Lightning sin confundirla con la seed. Para el lado del comercio, repasa cómo pagar en un comercio y guardar el justificante.
Hay más piezas que encajan con esta
Continúa por contenidos relacionados con el tema que acabas de estudiar.
Recibe tu primer pago Lightning y verifica el resultadoWallets y pagos Lightning
Qué comprobar antes de enviar un pago con BitcoinWallets y pagos Lightning
Invoice Lightning, Lightning Address y QR: no son lo mismoWallets y pagos Lightning
Prepara una copia de recuperación Lightning sin confundirla con la seedNodos y liquidez
Comprueba la liquidez de un canal Lightning antes de recibirNodos y liquidez
Liquidez en Lightning: entrante y saliente sin confusionesNodos y liquidez
¿Qué es un canal Lightning?Fundamentos de LightningOn-chain o Lightning: qué cambia realmenteFundamentos de Lightning
Haz un pago Lightning y compáralo con on-chainPrácticas guiadas