BTCPay Server es un procesador de pagos libre con licencia MIT, que puede ejecutarse en una instancia propia o mediante un alojamiento de terceros. El proyecto proporciona software, no una cuenta universal de custodia ni un servicio de arbitraje para disputas con comerciantes. La confianza depende de cómo se conectan realmente servidor, cartera y servicios de pago.
El comercio conecta una caja o tienda en línea con una factura y el método de recepción elegido. BTCPay Server crea direcciones de pago on-chain y solicitudes Lightning, sigue los pagos y ofrece una vista de las facturas. Incluye aplicaciones de punto de venta y donaciones e interfaces de integración. El código abierto permite inspeccionar y modificar el programa, pero no demuestra por sí solo la seguridad de una instalación concreta. [BTCPay Server — Source repository]
Una cartera on-chain existente puede conectarse mediante una clave pública extendida: el servidor deriva direcciones de recepción sin necesitar su clave privada. Una cartera caliente creada en el servidor tiene otro modelo de riesgo. Los permisos de un nodo Lightning también pueden permitir disponer de sus fondos. Separe las claves de recepción, firma y administración; la palabra self-hosted no determina por sí sola quién puede gastar el dinero. [BTCPay Server — Wallet setup] [BTCPay Server — General FAQ]
Un tercero opera el servidor mientras el usuario puede recibir directamente en su propia cartera. Esto no elimina la confianza: un servidor malicioso o comprometido puede sustituir la clave pública y desviar pagos futuros. Las monedas ya recibidas en su cartera y los nuevos datos de pago mostrados son asuntos distintos. Compruebe la recepción también de forma independiente de la caja. El mismo ataque puede afectar a una instancia propia comprometida; el alojamiento también influye en disponibilidad y privacidad. [BTCPay Server — Third-party hosting risks]
El comercio configura moneda, fuente del tipo de cambio, vencimiento y confirmaciones requeridas. Processing en un pago on-chain espera la condición configurada; Settled indica que se ha cumplido. Un pago Lightning correcto no necesita esperar un bloque. Atienda pagos insuficientes, excesivos, tardíos y cambios manuales de estado, que no generan confirmaciones de red. Convertir un precio a bitcoin no equivale a vender por moneda fiat: un plugin o proveedor de conversión añade sus propias comisiones y requisitos de confianza. [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies] [BTCPay Server — General FAQ]
La tienda en línea debe conservar el vínculo entre el pedido y el identificador de su factura. Greenfield API permite delimitar permisos por tienda; no conceda a la clave más acceso del necesario. Verifique los webhooks según la documentación y procese eventos repetidos sin un segundo envío. El regreso del cliente a una página de agradecimiento no prueba por sí solo el pago. Después de una interrupción, concilie los registros locales con los estados reales de facturas y pagos. [BTCPay Server — eCommerce integration]
Un nodo propio requiere disponibilidad, gestión de canales y liquidez entrante. Un servicio de liquidez, un swap o una cartera con custodia resuelven partes distintas del problema y no constituyen el mismo modelo. En un servicio con custodia, el proveedor conserva el control de los fondos; en las demás variantes deben verificarse permisos y riesgos concretos. El logotipo de BTCPay Server no garantiza que todos los pagos se completen ni que no haya comisiones. [BTCPay Server — Lightning options]
Respalde datos de tiendas, facturas, configuración y los datos necesarios de las carteras según el despliegue; una semilla no sustituye la base de datos de pedidos. La documentación de Docker exige comprobar la restauración de la copia. Un estado antiguo de un canal Lightning puede causar pérdida de fondos si se restaura incorrectamente. Una migración planificada con el nodo original detenido correctamente difiere de la recuperación tras un desastre; una vez arrancado el sustituto, no inicie la copia original del mismo nodo. El procedimiento debe corresponder al backend utilizado. [BTCPay Server — Backup and restore]
Planifique actualizaciones, protección del acceso administrativo, exposición de red, supervisión de disponibilidad y copias verificadas. Alojamiento, hardware, comisiones de red, liquidez y soporte pueden costar dinero aunque el programa no cobre un porcentaje de cada pago. Reduzca los datos guardados de clientes. El comerciante gestiona reembolsos y disputas de entrega, no los desarrolladores del proyecto; exportar facturas no garantiza cumplir todas las obligaciones contables. [BTCPay Server — Maintenance] [BTCPay Server — General FAQ] [BTCPay Server — eCommerce integration]
Una caída de la caja no significa perder monedas ya recibidas
En una tienda hipotética, el servidor solo conoce los datos públicos de una cartera externa. Si falla el alojamiento, las monedas on-chain ya recibidas siguen controladas por sus claves, pero la caja puede dejar de crear facturas o notificar pagos. El operador restaura el servicio, comprueba la configuración de recepción y concilia los pedidos con la cartera. Este ejemplo no se aplica a una cartera caliente alojada en el servidor perdido ni a un estado obsoleto de canales Lightning.
Para obtener la imagen más completa, lee esta entrada junto con Bitcoin Payment Processor, Bitcoin Point of Sale, Autocustodia, Lightning Network, Merchant Adoption, Bitcoin. También enlazan con esta entrada Bitcoin Coffee, Bitcoin Payment Processor, Bitcoin Point of Sale, Bitcoin Donations.
01¿BTCPay Server implica automáticamente autocustodia?+
No. Depende de la cartera conectada, el servicio Lightning y los permisos reales. Recibir en una cartera externa solo mediante una clave pública difiere de una cartera caliente en un servidor ajeno o un backend con custodia. Además, debe confiar en la corrección de los datos de pago mostrados.
02¿Basta una copia de la semilla para recuperar el sistema?+
La semilla puede restaurar la cartera on-chain correspondiente, pero no automáticamente las facturas, la configuración de tiendas ni el estado de los canales Lightning. Cada parte tiene sus propias copias y procedimientos. La recuperación debe probarse; una copia obsoleta de un nodo Lightning activo no puede tratarse de forma segura como un respaldo ordinario de archivos.