El pedido vive en tu tienda o en tu sistema de ventas. La factura (invoice) vive en BTCPay y tiene su propio identificador. El pago es una transacción con TXID o un pago Lightning. Una factura puede recibir varios pagos (por ejemplo, uno corto y otro que completa el importe), y un pago puede llegar tarde, después de que la factura haya caducado.

Si no relacionas los tres, aparecen los errores clásicos: entregar con una captura de «Enviado», cobrar dos veces el mismo pedido o no saber a qué pedido corresponde un pago. El punto de vista del cliente está en Paga con Bitcoin en un comercio.

Además existen Expired (caducada sin pago completo) e Invalid (marcada como no válida), y estados adicionales que exigen revisión manual: Paid partial (se pagó menos), Paid over (se pagó de más), Paid late (el pago completo llegó tras caducar; el estado base sigue siendo Expired hasta que alguien actúe) y Marked (un usuario de la tienda cambió el estado a mano, lo que no prueba ningún pago).

Una instancia de BTCPay Server con una tienda y al menos un método de cobro configurado: una wallet on-chain (idealmente de solo lectura, con xpub) o un nodo Lightning. Si tienes una instancia de pruebas en testnet o regtest, mejor todavía. Necesitas un usuario con permisos sobre esa tienda.

1. PASO 1 · Revisa la tienda: entra con tu usuario, selecciona la tienda y comprueba en Wallets qué métodos de cobro están activos (Bitcoin on-chain, Lightning o ambos).
2. PASO 2 · Crea la factura: ve a Payments → Invoices y crea una factura nueva con un importe pequeño, la moneda que quieras y un identificador de pedido ficticio, por ejemplo PRUEBA-001.
3. PASO 3 · Anota sus datos: en el detalle de la factura apunta el Invoice ID, el estado (New), la hora de caducidad, el importe en BTC o sats y el tipo de cambio aplicado si la creaste en euros.
4. PASO 4 · Abre el checkout: abre el enlace de pago de la factura y comprueba qué ofrece al cliente: una dirección on-chain, una invoice Lightning o ambas.
5. PASO 5 · Sin pagar: deja pasar el plazo. La factura pasará a Expired. Has demostrado que una factura, por sí sola, no aporta fondos.
6. PASO 6 · Pago real opcional: crea otra factura y págala con un importe pequeño desde otra wallet. En on-chain verás Processing hasta que la transacción alcance las confirmaciones que exige tu tienda y luego Settled; en Lightning pasará a Settled al liquidarse el pago.
7. PASO 7 · Relaciona: comprueba que Invoice ID, identificador de pedido y TXID (o pago Lightning) coinciden, y que el importe recibido es el pedido. Solo entonces marcarías el pedido como pagado.

En la configuración de la tienda puedes decidir cuántas confirmaciones on-chain necesita un pago para que la factura pase a Settled. Menos confirmaciones significan entregas más rápidas y más riesgo; más confirmaciones, más espera y menos riesgo.

Ten en cuenta que, desde Bitcoin Core 28.0, los nodos aceptan por defecto sustituir transacciones no confirmadas aunque no lo señalicen (full-RBF). Eso hace más fácil que un pagador intente reemplazar un pago todavía sin confirmar, así que aceptar cero confirmaciones solo tiene sentido en importes pequeños y cuando aceptas ese riesgo. Lo explicamos en RBF en Bitcoin. En Lightning no hay confirmaciones: el pago se liquida o no.

1. Objetos: distingo pedido, factura y pago.
2. Estados: sé qué significan New, Processing, Settled, Expired e Invalid.
3. Excepciones: sé tratar Paid partial, Paid late, Paid over y Marked.
4. Política: conozco cuántas confirmaciones exige mi tienda y su riesgo.
5. Entrega: solo entrego con la factura en Settled y el pago relacionado.

• BTCPay Server — facturas y estados ↗
• BTCPay Server — guía de uso ↗
• BTCPay Server — devoluciones ↗