Desde Bitcoin Core 28.0, los nodos aceptan por defecto sustituir transacciones no confirmadas aunque no lo hayan señalizado (full-RBF). En la práctica, aceptar pagos con cero confirmaciones es más arriesgado que hace unos años: resérvalo para importes que estés dispuesto a perder o para clientes conocidos. Más contexto en RBF en Bitcoin.

1. PASO 1 · Qué vendes: clasifica tus ventas por riesgo. Un archivo digital entregado al instante, un producto físico que tarda días en enviarse, un servicio presencial y un pedido de alto valor no merecen la misma espera.
2. PASO 2 · Qué métodos aceptas: Lightning, on-chain o ambos. Lightning favorece importes pequeños y entrega inmediata; on-chain, importes mayores con espera de confirmaciones.
3. PASO 3 · Confirmaciones por tramo: escribe cuántas confirmaciones exiges según el importe y configúralo en tu herramienta de cobro. En BTCPay Server se ajusta en la configuración de la tienda.
4. PASO 4 · Plazo y tipo de cambio: si fijas precios en euros, la factura convierte a sats con un tipo de cambio y un plazo. Decide cuánto dura y qué pasa si el cliente paga después.
5. PASO 5 · Pagos cortos: fija una tolerancia pequeña (por ejemplo, diferencias causadas por comisiones del exchange del cliente). Si tu versión de BTCPay lo permite, configúrala como porcentaje. Por encima de esa tolerancia, pide el resto o devuelve.
6. PASO 6 · Pagos tardíos: decide si un pago completo recibido tras caducar la factura (Paid late) se acepta al precio original, se ajusta o se devuelve. No lo ignores: la transacción no se revierte sola.
7. PASO 7 · Pagos de más o duplicados: establece que la diferencia se devuelve, en qué plazo y quién asume la comisión de la devolución.
8. PASO 8 · Devoluciones: define en qué unidad se fija el importe (BTC o euros), cómo se autentica al cliente, que siempre se devuelve a una dirección o invoice nueva que él aporte y nunca a la dirección de origen. Detalle en cómo realizar una devolución.

Tienda Ejemplo · Política de cobros en bitcoin (cifras inventadas, no son una recomendación):

1. Lightning: pedidos de hasta 300 €. Entrega en cuanto la factura figura como pagada.
2. On-chain hasta 100 €: entrega con 1 confirmación.
3. On-chain de 100 € a 2.000 €: entrega con 2 confirmaciones.
4. On-chain de más de 2.000 €: entrega con 6 confirmaciones.
5. Plazo: la factura es válida 30 minutos al tipo de cambio mostrado.
6. Pago corto: se acepta una diferencia de hasta el 1 %; por encima, se pide el resto en el plazo de la factura o se devuelve lo recibido.
7. Pago tardío o de más: se contacta al cliente en 48 horas; la diferencia se devuelve descontando la comisión de red.
8. Devoluciones: en sats o en euros según lo pactado, a una dirección nueva aportada por el cliente a través de un enlace de devolución.

Publica una versión breve en tu página de pago: el cliente sabrá qué esperar y tú tendrás una referencia objetiva si surge un desacuerdo.

Processing significa que el pago cubre el importe pero aún no cumple tus reglas; Settled, que sí las cumple: entrega solo con Settled. Paid partial, Paid late y Paid over se corresponden con los pasos 5, 6 y 7 de tu política, y Marked indica un cambio manual que no prueba ningún pago. Practica cada caso con un cobro de prueba y, si automatizas avisos, con webhooks verificados.

1. Riesgo: sé cuándo es definitivo un pago Lightning y uno on-chain.
2. Confirmaciones: tengo tramos por importe y están configurados en mi herramienta.
3. Excepciones: sé qué hago con pagos cortos, tardíos y de más.
4. Devoluciones: está escrito en qué unidad, a qué destino y quién paga la comisión.
5. Publicación: el cliente puede leer una versión breve antes de pagar.

• BTCPay Server — facturas y estados ↗
• BTCPay Server — devoluciones ↗
• Bitcoin Core 28.0 — full-RBF por defecto ↗