Lightning permite pagos a través de canales y otros mecanismos compatibles. Una invoice BOLT11 suele codificar destino, importe si está fijado, identificador del pago (payment hash), condiciones de caducidad y una descripción o su referencia. No se entrega una seed ni una dirección on-chain para cobrarla.

Una Lightning Address es una forma cómoda de solicitar pagos a través de un servicio; normalmente la wallet pagadora obtiene una invoice concreta en el proceso. Un QR solo transporta esos datos. La diferencia está explicada en Invoice, Lightning Address y QR: no son lo mismo.

El resultado relevante es que la invoice figure como pagada o liquidada en la wallet receptora y el sistema de pago deje constancia compatible. Para un negocio, además, debes relacionar ese estado con el pedido correspondiente.

Necesitas una wallet o servicio que permita recibir Lightning. Para una prueba real opcional puedes usar una segunda wallet que pueda pagar una pequeña cantidad de sats, pero no necesitas enviarlos para aprender los pasos.

1. Identidad: abre la cuenta receptora correcta y verifica su estado sin compartir seeds ni contraseñas.
2. Modelo: descubre si el saldo lo custodia un proveedor, un LSP u operas tus propios canales.
3. Red: comprueba que la función dice Lightning y que vas a generar una invoice, no una dirección Bitcoin on-chain.
4. Liquidez: si usas canales propios, estudia si puedes recibir el importe previsto. Tener 10.000 sats en un canal no garantiza poder recibir otros 10.000 sats.

1. PASO 1 · Recibir: en la wallet destinataria elige Receive / Recibir → Lightning. Los nombres cambian según la aplicación.
2. PASO 2 · Importe: indica una cantidad pequeña y claramente expresada en sats. Si creas una invoice sin importe, recuerda que es el pagador quien deberá fijarlo; para aprender es más claro comenzar con importe definido.
3. PASO 3 · Concepto: añade una descripción breve si la herramienta lo permite. No pongas información confidencial: puede viajar incluida o asociada al pago.
4. PASO 4 · Generar: obtén una invoice nueva. No la confundas con una dirección on-chain y observa su caducidad.
5. PASO 5 · Verificación previa: si tienes una segunda wallet, decodifica o previsualiza la invoice antes de autorizar el pago. Compara importe, descripción y destinatario cuando estén disponibles.
6. PASO 6 · Prueba opcional: solo si deseas gastar una cantidad pequeña y ambas wallets están preparadas, paga la invoice una vez. Si no dispones de fondos o no quieres utilizarlos, detente aquí: ya puedes practicar la creación y lectura sin mover nada.
7. PASO 7 · Resultado: vuelve a la wallet receptora y comprueba que esa invoice concreta aparece como pagada o liquidada, no simplemente creada. Compara el identificador o registro de recepción con el de la operación pagadora.

Una wallet emisora puede mostrar in flight, éxito o fallo. Si un intento está aún en curso, no repitas indiscriminadamente el pago. Primero consulta su estado final y el historial de la invoice para evitar solicitudes o pagos duplicados.

Core Lightning ofrece estados como unpaid, paid, expired para consultar invoices; otros sistemas usan terminología equivalente. El pago Lightning no requiere esperar a que un bloque on-chain confirme esa invoice.

Si la invoice es válida pero el pago no llega, comprueba: caducidad, importe, disponibilidad de la wallet receptora, estado del proveedor o nodo, rutas y, en canales propios, liquidez entrante. Una falla en cualquier tramo puede impedir la liquidación aunque el destinatario tenga una dirección Lightning válida.

Si tu wallet es custodial, el saldo de la app y la promesa del proveedor están ligados a su operación; pregunta por el estado específico al servicio. En autocustodia Lightning, además de claves pueden importar backups de canal, conectividad y política de recepción.

Profundiza en Liquidez entrante y saliente en Lightning.

Una invoice concreta puede identificar un pago, su importe o descripción, y datos asociados al receptor. No publiques solicitudes de cobro de clientes ni identificadores sin necesidad. Una Lightning Address puede depender de un servicio que conoce actividad y dirección de usuario.

El payment hash identifica el pago; la preimage puede constituir prueba criptográfica de su liquidación en flujos compatibles. Sin embargo, no necesitas divulgar la preimage ni otro dato interno para demostrar a un comercio que su propio sistema registró el pago. La comparación con el pedido y el recibo del proveedor es lo más práctico.

Si guardas un recibo, conserva lo mínimo necesario: importe, estado, referencia del pedido y fecha, sin adjuntar semillas, cookies, tokens de sesión ni copias de seguridad.

1. Solicitud: distingo invoice Lightning de dirección on-chain.
2. Contenido: reviso importe, descripción y caducidad.
3. Recepción: compruebo el estado de la invoice concreta.
4. Incidencia: sé investigar expiración, rutas y liquidez entrante.
5. Privacidad: no comparto secretos ni recibos innecesarios.

• Lightning Labs — ciclo de pagos ↗
• Lightning Labs — recepción de pagos ↗
• Core Lightning — consultar invoices ↗