La mascota oso polar de NordBastion de pie tras un mostrador de comerciante nórdico tallado en piedra, con un panel de checkout holográfico cian flotando encima que muestra un código QR con un símbolo de Bitcoin ámbar y un glifo de rayo, y un único arco ininterrumpido de monedas brillantes que corre desde el panel directo hacia una puerta de bóveda rúnica abierta junto a él, con un rack de servidores y una ventana arqueada iluminada por la aurora detrás
Guía práctica · Pagos en criptomoneda·21 min de lectura · 60 min prácticos

Cobre usted mismo.
Ya no queda nadie que pueda congelarlo.

Todo procesador de tarjetas y toda pasarela de criptomonedas alojada se sitúan entre usted y su cliente, cobran un porcentaje, guardan la lista de quién le pagó qué, y se reservan el derecho a parar. BTCPay Server es el software que los elimina: un procesador de pagos de código abierto, autoalojado y no custodio, donde las monedas van directas a un monedero del que el servidor no puede gastar. Seis pasos hasta un checkout de Bitcoin y Lightning funcionando en una máquina que usted alquila de forma anónima — la forma del nodo que decide el presupuesto, la clave de solo lectura, el problema de la liquidez entrante, y la regla de copias de seguridad que Lightning rompe. La máquina cuesta $7.90 al mes. Probado en Debian 12.

Los seis pasos
  1. 01

    Elegir

    Nodo completo, podado o externo

  2. 02

    Aprovisionar

    Primero el dominio, luego cuatro puertos

  3. 03

    Desplegar

    Un generador, un comando

  4. 04

    Conectar

    Clave de solo lectura, nunca una semilla

  5. 05

    Lightning

    Canales y capacidad entrante

  6. 06

    Publicar

    Checkout, copias de seguridad, actualizaciones

Antes de empezar · Qué es un procesador

Bitcoin eliminó el banco. La mayoría de las tiendas vuelven a poner uno.

Un pago en una cadena de bloques no necesita una empresa en medio. El cliente firma una transacción, la red la confirma, y el dinero es suyo — no hay adquirente, no hay ventana de liquidación y no hay nadie cuya aprobación condicione el pago. Ese es todo el sentido del asunto, y es la razón por la que la tecnología existe.

Después, una tienda necesita cobrar pagos de verdad, y los requisitos prácticos llegan todos a la vez. Cada factura necesita su propia dirección, para poder distinguir los pagos entre sí. Alguien tiene que vigilar la cadena y decidir cuándo se ha pagado una factura. El importe tiene que cotizarse en una moneda en la que piense el cliente, a un tipo de cambio que se mantenga el tiempo suficiente para que pulse enviar. El estado del pedido tiene que fluir de vuelta a la tienda. Y todo esto tiene que funcionar a las dos de la madrugada sin que nadie lo vigile. Construir todo eso es un proyecto; no construirlo es la razón por la que casi todo el mundo se apunta en su lugar a una pasarela alojada — y, en el espacio de un formulario, vuelve a meter un intermediario en un sistema diseñado para no tener ninguno.

Merece la pena decir con claridad lo que retiene ese intermediario, porque es más que la comisión. Retiene las monedas, al menos hasta que se ejecuta un pago saliente, lo que significa que puede retrasarlo. Retiene la lista: cada cliente, cada importe, cada marca de tiempo, cada producto, en una base de datos que usted no puede leer ni borrar. Retiene un expediente de identidad sobre usted, porque una empresa que maneja dinero ajeno está obligada a recopilarlo. Y retiene el interruptor, porque los términos de servicio se reservan el derecho de decidir que su negocio ya no es bienvenido — una decisión que llega por correo electrónico, se aplica tanto al saldo como a la cuenta, y en la práctica no admite apelación.

BTCPay Server es la respuesta a exactamente ese problema, y a ningún otro. Es un procesador de pagos gratuito y de código abierto que usted ejecuta en su propia máquina: deriva una dirección por factura, vigila la cadena, cotiza precios en fiat, expone un checkout y una API, y habla Lightning. Nunca retiene sus monedas, porque el monedero que vigila ya es suyo. Cuatro formas de aceptar un pago en criptomoneda, y lo que cuesta cada una en realidad:

Propiedad Una pasarela de criptomonedas alojada Una dirección en bruto en el pie de página BTCPay en la instancia de otro BTCPay en su propio VPS
Quién controla las monedasLa pasarela, hasta el pago salienteUstedUsted — vigila, no puede gastarUsted — vigila, no puede gastar
Quién puede impedirle comerciarLa pasarela, por correo electrónicoNadieEl operador de la instanciaNadie
Quién ve cada cliente e importeLa pasarela, permanentementeTodo el mundo — una dirección, un total públicoEl operador de la instanciaUsted
Documento de identidad requeridoSí, antes del primer pago salienteNoLo que sea que pida el operadorNo
Coste por transacciónUn porcentaje, para siempreNadaNadaNada — $7.90 al mes, fijos
Distingue una factura de otraSíNo — concilia usted a manoSíSí
Elíjalo cuandoQuiere cero operaciones y acepta los términosDonaciones, un puñado al añoQuiere el software pero no el servidorLa facturación es suya, y también la lista

La segunda columna tampoco es ninguna broma — una sola dirección en un pie de página está genuinamente bien para un enlace de donativos, y fingir lo contrario solo vende software que nadie necesita. Deja de estar bien en el momento en que dos personas pagan el mismo importe el mismo día, o en el momento en que preferiría que su renta anual no fuera una cifra pública que cualquiera puede sumar.

Paso 01 · Elegir

Una decisión fija todo el presupuesto. ¿Cuánta cadena conserva?

Un procesador de pagos tiene que poder responder con honestidad a una sola pregunta: ¿se ha pagado esta factura? Responderla significa vigilar la red de Bitcoin, y vigilarla como es debido significa ejecutar un nodo que valide los bloques por sí mismo en lugar de creer lo que alguien le diga. Ese nodo es todo el presupuesto de hardware de este proyecto — BTCPay en sí, el indexador y la base de datos juntos son un error de redondeo a su lado.

Hay tres disposiciones que tienen sentido, y una que no. Un nodo de archivo guarda todos los bloques jamás minados: bien por encima de 700 GB en 2026, y creciendo unos 50 GB al año. Es lo que quiere si además piensa ejecutar un explorador de bloques o hacer análisis histórico, y es excesivo para una tienda. Un nodo podado descarga y valida completamente cada bloque exactamente de la misma forma, y luego descarta los antiguos y mantiene una ventana móvil. El modelo de seguridad es idéntico — esta es la parte que la gente entiende mal, porque "podado" suena a "parcial" y no lo es — y el generador de despliegue incluye fragmentos ya preparados para ello.

Un nodo externo es la tercera: apunte la pila a un nodo de Bitcoin que ya opere usted, a través de un enlace privado. Si ya siguió la guía del nodo Lightning no hay motivo para mantener una segunda copia de la cadena, y una VPN de malla entre las dos máquinas es la forma limpia de conectarlas. La disposición que no tiene sentido es apuntar una tienda al nodo público de un desconocido: aprende todas las direcciones que usted vigila —es decir, sus ingresos— y está en posición de mentir sobre si una factura se pagó.

Despliegue Cadena en disco Volumen total necesario Lo que renuncia
Podado, la ventana más pequeña~5–25 GB~40 GBReescaneos, y cualquier margen de error. La opción más pequeña no es recomendable.
Podado, ventana de ~50 GB~50 GB~80 GBNada que una tienda note. El mínimo sensato.
Podado, ventana de ~100 GB~100 GB~140 GBNada. La opción cómoda por defecto, con margen para Lightning.
De archivo, historial completo700 GB +~960 GBNada — pero lo paga usted cada mes, para siempre.
Nodo externo que ya opera ustedNinguno en esta máquina~40 GBIndependencia — el checkout se cae cuando se cae la otra máquina.
Lo único que la poda le cuesta de verdad

Un nodo podado no puede reescanear bloques que ya ha descartado. En la práctica eso significa que no puede reconstruir el historial de un monedero cuyas transacciones son anteriores al despliegue — el indexador escanea hacia adelante desde el día en que conecta la clave, así que los pagos antiguos a esa cuenta simplemente no aparecerán en la tienda. Esto no es un problema si hace lo que recomienda el paso 04 y le da a la tienda una cuenta recién creada; es una tarde genuinamente confusa si conecta un monedero que lleva tres años usando y falta la mitad de su historial. Decida cuál de las dos cosas va a hacer antes de instalar, no después.

Aquí toca una decisión más, y no más tarde, porque cambia lo que construye el instalador: si quiere Lightning desde el primer día. Solo on-chain es una configuración completa y un punto de partida perfectamente respetable. Añadir Lightning más tarde está soportado y no es doloroso, pero es un segundo demonio con sus propios fondos y sus propias reglas de copia de seguridad, y hay mucho que decir a favor de demostrar que el dinero real llega por el camino simple antes de introducir el complicado.

Paso 02 · Aprovisionar

El dominio tiene que existir primero. El instalador pedirá un certificado.

Encargue la máquina. En el panel: Order → VPS → Garrison, imagen Debian 12, en el bastión en el que quiera que vivan los registros de la tienda — Helsinki, Stockholm, Oslo o Reykjavík. Garrison es la opción por defecto adecuada porque aloja una cadena podada de 100 GB, un nodo Lightning y la base de datos sin que tenga que volver a pensar en el disco durante años. Sentinel funciona con una poda más ajustada; Bulwark es el nivel para un nodo de archivo. No se requiere ninguna dirección de correo para abrir la cuenta, y la factura se liquida en Monero, Bitcoin, Lightning o cualquier otro activo admitido — que es la parte agradable de este proyecto en concreto, ya que está construyendo una máquina para aceptar pagos en criptomoneda y pagándola con una de ellas.

Después, aplique la lista de verificación de refuerzo de la primera hora antes que nada — SSH solo con clave en un puerto distinto del habitual, actualizaciones desatendidas, un cortafuegos que deniega por defecto. Esta máquina acabará guardando el registro de todos sus clientes y el material de claves de un nodo Lightning con fondos activos dentro. No es una máquina para dejar con autenticación por contraseña durante una semana.

Ahora el registro DNS, y hágalo antes de ejecutar el instalador, no después. Elija el nombre de host en el que vivirá el checkout — shop.example.com, pay.example.com, lo que le encaje — y apunte un registro A a la dirección del VPS, más un AAAA si quiere que sea accesible por IPv6. Deje que se propague. El proxy inverso que configura el instalador intentará obtener un certificado para ese nombre exacto durante su primer arranque, usando un desafío HTTP que exige que el nombre ya resuelva a esta máquina. Con diferencia, un registro que todavía no está activo es la forma más habitual en que una primera instalación termina en un error confuso.

El nombre de host no es del todo permanente, pero trátelo como si lo fuera

El despliegue incluye un script para cambiar el dominio más adelante, así que esto es recuperable y no fatal. Lo que no es recuperable en un solo comando es todo lo que viene después: el certificado se reemite, cada botón de pago y URL de webhook que ha repartido sigue apuntando al nombre antiguo, una dirección Lightning es un nombre en un dominio y se traslada con él, y cualquier plugin de tienda necesita reconfigurarse. Elija un nombre que esté dispuesto a mantener en el membrete durante años, y prefiera un subdominio de un dominio que ya publique antes que uno nuevo que describa lo que hace la máquina.

Después, escriba las reglas del cortafuegos mientras todavía no escucha nada. Cuatro puertos, y solo cuatro. El checkout es por necesidad un endpoint HTTPS público — el navegador de un cliente tiene que poder alcanzarlo — y el puerto 80 se queda abierto porque la renovación del certificado lo usa. El puerto entre pares de Lightning solo hace falta si quiere que otros nodos puedan abrir canales hacia usted, algo que el paso 05 argumentará que le conviene. El puerto entre pares de Bitcoin no necesita estar abierto en absoluto: su nodo hace conexiones salientes perfectamente bien, y abrirlo de forma entrante solo lo hace más fácil de encontrar.

ufw default deny incoming
ufw allow 47222/tcp                  # administrative SSH, moved off 22
ufw allow 80/tcp                     # ACME HTTP-01 challenge and the redirect
ufw allow 443/tcp                    # the checkout
ufw allow 9735/tcp                   # Lightning peer-to-peer, only if you want inbound channels
ufw enable
ufw status numbered

Dos notas sobre recursos antes de continuar. Déle swap a la máquina si no tiene — la descarga inicial de bloques es la hora hambrienta de memoria de este proyecto, y 4 GB de RAM con 2 GB de swap se comporta mucho mejor que 4 GB solos. Y compruebe la aritmética de disco del paso 01 contra el nivel que realmente encargó, porque un nodo que llena su volumen a mitad de sincronización no falla educadamente; corrompe su propio índice y vuelve a empezar.

fallocate -l 2G /swapfile && chmod 600 /swapfile
mkswap /swapfile && swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
df -h /                              # confirm the volume matches step 01
Paso 03 · Desplegar

Un generador, no un archivo de Compose. Usted lo describe; él lo ensambla.

El despliegue oficial no es un docker-compose.yml que usted edite. Es un generador: usted describe el despliegue que quiere mediante variables de entorno, y un script ensambla el archivo de Compose a partir de una biblioteca de fragmentos — uno para Bitcoin Core, uno para el indexador, uno para PostgreSQL, uno para la aplicación BTCPay, uno para cada implementación Lightning, uno para el proxy inverso, y una larga cola de extras opcionales. Este es un diseño mejor de lo que parece a primera vista, porque las actualizaciones regeneran el archivo en lugar de pedirle que fusione los cambios de otra persona con los suyos. También significa que el bloque de entorno de más abajo es la configuración real de su despliegue, y merece la pena guardarlo en el mismo sitio que sus otras notas de infraestructura.

Clone el repositorio y exporte el entorno. Cada línea de abajo corresponde directamente a una decisión del paso 01: el nombre de host es el dominio que apuntó en el paso 02, el fragmento de almacenamiento es la ventana de poda que eligió, y la variable de Lightning es o bien una implementación, o se omite por completo para un lanzamiento solo on-chain.

mkdir BTCPayServer && cd BTCPayServer
git clone https://github.com/btcpayserver/btcpayserver-docker
cd btcpayserver-docker

export BTCPAY_HOST="pay.example.com"          # exactly the name you pointed in step 02
export NBITCOIN_NETWORK="mainnet"
export BTCPAYGEN_CRYPTO1="btc"
export BTCPAYGEN_REVERSEPROXY="nginx"
export BTCPAYGEN_LIGHTNING="clightning"       # or "lnd", or omit for on-chain only
export BTCPAYGEN_ADDITIONAL_FRAGMENTS="opt-save-storage-s"   # ~50 GB pruned window
export BTCPAY_ENABLE_SSH=true
export LETSENCRYPT_EMAIL="you@example.com"

. ./btcpay-setup.sh -i

Dos detalles de ese bloque merecen una frase cada uno. El punto inicial de . ./btcpay-setup.sh -i no es un error tipográfico — el script se ejecuta con source en lugar de ejecutarse directamente, así que el entorno que configura permanece en su shell y los comandos auxiliares funcionan después. Y el nombre del fragmento de almacenamiento es sensible a la versión: el generador ha publicado variantes que podan hasta aproximadamente 100, 50, 25 y 5 GB, con nombres que se han ajustado entre versiones. Lea la lista de fragmentos en el repositorio que acaba de clonar, en lugar de confiar en un valor copiado de una entrada de blog, incluida esta.

El instalador tardará unos minutos, descargará muchas imágenes, obtendrá el certificado y lo pondrá todo en marcha. Después empieza la espera: el nodo tiene que descargar y validar la cadena antes de que la tienda pueda confirmar un pago, lo cual son horas y no minutos incluso podado, porque podar descarta los bloques después de validarlos y no se salta el trabajo. La interfaz web está disponible de inmediato y le mostrará un aviso de sincronización. No emita una factura real hasta que desaparezca.

./bitcoin-cli.sh getblockchaininfo | grep -E 'blocks|headers|verificationprogress|pruned'
docker ps --format '{{.Names}}\t{{.Status}}'
Reclame la cuenta de administrador en los próximos cinco minutos

Una instancia recién creada no tiene usuarios, y la primera cuenta en registrarse se convierte en administradora. Hasta que la reclame, cualquiera que llegue a la URL puede hacerlo — y la URL no es secreta: en el momento en que se emitió el certificado, el nombre de host quedó publicado en los registros públicos de transparencia de certificados, que se indexan y escanean continuamente por gente que busca exactamente esto. Abra el sitio y regístrese antes que nada, y luego revise los Ajustes del servidor y confirme que el registro no está abierto a desconocidos. Esta es una ventana de cinco minutos que la gente deja abierta durante días porque la tienda "todavía no está en producción".

Merece la pena conocer dos fragmentos opcionales mientras todavía está en la configuración. Uno añade un servicio oculto de Tor, así que el checkout es accesible en una dirección onion v3 además de en la de clearnet — útil para clientes que prefieran no resolver su dominio, y la misma idea que la guía del servicio onion. Otro añade una segunda criptomoneda. Ambos se configuran de la misma forma, añadiéndolos a la variable additional-fragments y volviendo a ejecutar el script de configuración; el generador reconstruye el archivo de Compose y reinicia solo lo que cambió.

Paso 04 · Conectar

Déle una clave pública. Nunca le dé una semilla.

Cree una tienda, y luego tome la única decisión de esta página que realmente importa. BTCPay le ofrecerá dos formas de vincular un monedero de Bitcoin: conectar uno existente, o dejar que genere uno nuevo y guarde la semilla en el servidor. La primera es de solo lectura, y es lo que usted quiere. La segunda convierte una máquina pública y expuesta a internet en un monedero caliente que guarda sus ingresos, y ningún nivel de refuerzo hace que eso sea un buen trato para una máquina cuyo único trabajo es ser alcanzable por desconocidos.

El mecanismo detrás de la recomendación es lo bastante elegante como para merecer la pena entenderlo. Los monederos modernos son jerárquicos: una semilla deriva un árbol de claves, y existe una clave pública extendida — un xpub, o su variante zpub para segwit nativo — a partir de la cual se puede calcular cada dirección de recepción de una cuenta sin ninguna capacidad de firmar. Déle eso a la tienda y podrá generar una dirección nueva para cada factura, vigilar la cadena en busca de pagos a cada una, y mostrarle el saldo. No puede mover ni un satoshi. La mitad privada se queda en su monedero, o en su dispositivo de hardware, y nunca viaja.

Así que: abra Sparrow, Electrum, o la aplicación de escritorio de su monedero de hardware, cree una cuenta nueva dedicada a esta tienda, y exporte su clave pública extendida. En los ajustes de monedero de la tienda, elija conectar un monedero existente, pegue la clave, y compruebe las primeras direcciones que deriva BTCPay contra las que muestra su monedero. Si coinciden, la ruta de derivación es correcta y la conexión está hecha. Si no coinciden, ha elegido el tipo de script equivocado — la diferencia entre un xpub y un zpub es la diferencia entre dos conjuntos de direcciones completamente distintos.

Una clave pública extendida no es una cadena de texto inofensiva

No puede gastar, que es lo que se busca — pero sí puede enumerar. Cualquiera que la obtenga puede derivar todas las direcciones que la cuenta llegue a usar, y por tanto leer todos los pagos que haya recibido y vaya a recibir, mientras usted use esa cuenta. Eso es una divulgación permanente e irrevocable de la facturación de su tienda, y es la razón por la que la cuenta que conecte debería estar dedicada a la tienda y no ser la que guarda sus ahorros. Trate la clave como confidencial, manténgala fuera de capturas de pantalla y tickets de soporte, y si llega a filtrarse, mueva la tienda a una cuenta nueva en lugar de confiar en que no pase nada.

Ahora los ajustes de la factura, que son donde realmente se afina una tienda. Caducidad viene por defecto en unos quince minutos, y es un bloqueo de precio y no un límite técnico: es cuánto tiempo está usted dispuesto a mantener un precio en fiat frente a un activo volátil. Acórtela para un mercado volátil, alárguela si sus clientes son lentos. Confirmaciones decide cuándo una factura cuenta como liquidada — cero confirmaciones es instantáneo y adecuado para un café, una confirmación es el valor habitual por defecto, y seis es para importes en los que una hora de espera sale más barata que la alternativa. Tolerancia de pago insuficiente le permite aceptar una factura que llega un poco corta, algo que pasa constantemente cuando el monedero de un cliente descuenta su comisión del importe en lugar de sumarla; un pequeño porcentaje aquí elimina toda una categoría de correos de soporte.

Después, pruébelo con dinero real, no con testnet. Emita una solicitud de pago por un importe insignificante, páguela desde un monedero del móvil, y observe cómo la factura pasa de nueva a en proceso a liquidada. Esa única transacción demuestra que el nodo está sincronizado, que la ruta de derivación es correcta, que el proveedor de tipo de cambio funciona, que el certificado es válido en un navegador móvil, y que el dinero llegó a un monedero que usted controla. Nada más demuestra las cinco cosas a la vez.

Paso 05 · Lightning

Los canales son la parte fácil. Ser cobrable es la parte difícil.

Bitcoin on-chain liquida de maravilla una factura de $400 y mal una de $4: el cliente espera una confirmación y paga una comisión que puede ser una fracción notable de la compra. Lightning invierte ambas cosas — liquidación en unos dos segundos, comisiones medidas en fracciones de céntimo — por lo que una tienda que vende cosas pequeñas lo necesita, y una que vende cosas grandes puede que no. Si configuró una implementación Lightning en el paso 03, el demonio ya está en marcha y BTCPay ya se ha conectado a él; los ajustes de la tienda solo necesitan habilitar Lightning como método de pago.

Qué implementación eligió tiene consecuencias que merece la pena nombrar. Core Lightning es la opción conservadora y ligera, con una arquitectura de plugins limpia. LND es la más desplegada, y tiene el ecosistema más grande de herramientas de gestión a su alrededor. Ahora también existe un tercer tipo de opción — un demonio ligero que externaliza la gestión de canales a un proveedor de servicios mientras mantiene las claves en su máquina — que cambia algo de independencia por la desaparición de todo lo descrito en los tres párrafos siguientes. Esa es una elección legítima para una tienda que quiere Lightning pero no quiere convertirse en operadora de un nodo; simplemente es un trato distinto, no uno gratuito.

Un nodo recién creado no puede recibir pagos, y nada se lo indica

Un canal Lightning contiene una cantidad fija de dinero, repartida entre los dos extremos. Cuando abre un canal y lo financia, todo ese dinero está en su lado — lo cual es capacidad para enviar, y exactamente cero capacidad para recibir. Una tienda necesita lo contrario. Así que un nodo recién financiado con tres canales sanos puede seguir fallando en cada factura entrante, y el fallo parece un error de enrutamiento en lugar de un error de configuración. Esta es, con diferencia, la razón más habitual por la que un checkout Lightning autoalojado parece roto el primer día.

Hay tres formas honestas de conseguir capacidad entrante, y no son mutuamente excluyentes. Puede abrir canales salientes y luego gastar a través de ellos — comprar algo, pagar una factura, mover dinero a un exchange — lo cual empuja su saldo hacia el otro lado y convierte capacidad de envío en capacidad de recepción. Puede pedirle a un nodo bien conectado que abra un canal hacia usted, lo cual es una petición normal en la comunidad Lightning y gratuita salvo por la comisión on-chain del par. O puede comprar liquidez entrante a uno de los varios servicios que la venden, lo cual cuesta un pequeño porcentaje y tarda minutos en lugar de semanas. No hay ninguna recomendación de afiliado en esta página, y no la va a haber; elija por reputación y precio actual.

Una vez que puede recibir pagos, dos funciones convierten el nodo en un escaparate de tienda. Una dirección Lightning — con la misma forma que una dirección de correo, en su propio dominio — permite que cualquiera le envíe dinero desde cualquier monedero moderno sin que exista una factura previa, lo cual es el mecanismo de donativos y propinas más amigable que existe. Y el código QR de la página de checkout puede ofrecer ambos rieles a la vez, así que un cliente con monedero Lightning paga en segundos y uno sin él paga on-chain, desde la misma pantalla y sin que usted tenga que decidir nada.

Antes de que llegue el primer pago por Lightning, haga el paso de copia de seguridad que tiene que ocurrir ahora y no después. Cada implementación mantiene un pequeño archivo que describe el estado actual de sus canales — LND lo llama copia de seguridad estática de canal — y es el artefacto que le permite recuperar los fondos si se pierde la máquina. Cambia cada vez que se abre o se cierra un canal, así que cópielo fuera de la máquina de forma automática y no a mano. Lea la advertencia del paso 06 antes de asumir que su archivo nocturno ya cubre esto, porque en el caso concreto de Lightning no lo hace.

Paso 06 · Publicar

Ahora, póngalo delante de los clientes. Después, manténgalo aburrido.

Elija la superficie de checkout más pequeña que encaje con lo que ya tiene. Una solicitud de pago es un enlace que le envía a alguien — sin necesidad de sitio web, y la forma más rápida de facturar a un cliente. Una aplicación de punto de venta convierte la misma instancia en una caja con lista de productos, que funciona desde un teléfono en un puesto de mercado. Un botón de pago es un fragmento de HTML para un sitio estático. Un plugin de tienda añade Bitcoin como método de pago a una tienda real y escribe el estado del pedido de vuelta automáticamente. Y la API REST emite facturas, informa de su estado y llama a un webhook cuando una se liquida, que es la integración que mejor envejece porque no depende de nada más que HTTP y un secreto compartido.

Elija lo que elija, conecte el webhook y luego compruebe que se dispara. Una factura que se liquida y nunca notifica a su aplicación es el modo de fallo que nadie detecta, porque todo parece correcto a ambos lados por separado: el dinero llegó, el cliente vio una página de confirmación, y el pedido se queda sin completar. Envíese a propósito un webhook de factura liquidada, confirme que su endpoint lo recibió, y verifique la firma en lugar de confiar en el contenido — ese endpoint es público y cualquiera puede enviarle datos.

Una copia de seguridad nocturna no es una vía de recuperación para Lightning

Esta es la única advertencia de esta página que puede costarle dinero en lugar de tiempo, y la propia documentación del proyecto lo dice con las mismas palabras: un estado de canal Lightning antiguo es tóxico. Restaurar la copia de anoche de una base de datos de canales y dejar que el nodo se ejecute significa difundir un estado que su contraparte ya ha superado — algo que el protocolo trata como un intento de fraude y castiga otorgándole todo el saldo del canal. Así que el archivo es adecuado para la base de datos de la tienda, la configuración y el historial de facturas, y no es un plan de recuperación para los canales. Copie la copia de seguridad estática de canal fuera de la máquina de forma continua, conserve la más reciente, y si alguna vez restaura un servidor entero desde un archivo, hágalo sabiendo que el lado de Lightning necesita el procedimiento de recuperación documentado y no una restauración directa.

Entendido esto, la rutina es corta. El despliegue incluye un script de copia de seguridad que archiva los volúmenes y vuelca la base de datos sin incluir los datos de la cadena de bloques, y acepta una frase de contraseña para que el archivo quede cifrado antes de salir de la máquina. Ejecútelo con un temporizador, y luego empuje el resultado a una máquina en una jurisdicción distinta tal como describe la guía de copias de seguridad — un repositorio de solo anexado merece aquí los diez minutos extra, porque un servidor de pagos comprometido no debería poder borrar el registro de lo que procesó.

cd ~/BTCPayServer/btcpayserver-docker
export BTCPAY_BACKUP_PASSPHRASE="a long passphrase you keep elsewhere"
./btcpay-backup.sh                   # archives volumes + database, skips the chain
# then ship the archive offsite, and keep the channel backup separately

Las actualizaciones vienen después, y una máquina de pagos es la única en la que "actualizarla más tarde, a propósito" es la política correcta. El despliegue tiene su propio script de actualización que regenera el archivo de Compose y descarga las imágenes nuevas; ejecútelo cuando haya leído las notas de la versión, no cuando le apetezca a un cron job. Haga primero el archivo. Suba una versión cada vez. Y mantenga anotada la versión anterior, porque poder revertir en un minuto es lo que hace que todo esto tenga poco riesgo.

./btcpay-update.sh                   # deliberate, after reading the release notes
df -h /                              # the check that should be an alert, not a habit

Por último, configure una alerta y un recordatorio. La alerta es sobre el uso de disco — un nodo de blockchain es el único proceso de la máquina que crece por sí solo, y un volumen lleno tumba el checkout de una forma lenta de diagnosticar porque nada más ha cambiado. Actívela al ochenta por ciento, no al noventa y cinco. El recordatorio es mensual, y consiste en abrir la tienda y mirar dos cosas: que las facturas se siguen liquidando, y que los canales Lightning que abrió siguen vivos. Un procesador de pagos falla en silencio, y la forma en que se entera es porque un cliente le dice que no pudo pagar.

La parte honesta · Lo que esto no hace

Usted eliminó al intermediario. No se volvió invisible.

Autoalojar el procesador es una mejora real y concreta, y no es un truco de desaparición. Cinco cosas siguen siendo ciertas después de hacer todo lo anterior, y conocerlas es la diferencia entre una defensa real y un cuento reconfortante.

El libro mayor de Bitcoin es público y permanente. Quitar la pasarela eliminó la base de datos privada de una empresa; no cifró la cadena. Todos los pagos que recibe su tienda son visibles para cualquiera que conozca una dirección, para siempre, y las direcciones se agrupan: un monedero que combina dos pagos en un solo gasto acaba de decirle al mundo que esos dos clientes pagaron a la misma tienda. Esto es una propiedad del activo, no del software, y es la razón por la que un negocio con una necesidad real de privacidad también mira hacia Monero.

El nombre de host del checkout se publica en el momento en que existe. Los registros de transparencia de certificados son públicos y se indexan continuamente, así que el nombre que eligió en el paso 02 es descubrible aunque nunca lo enlace desde ningún sitio. Por eso la cuenta de administrador tiene que reclamarse en los primeros minutos y no en la primera semana, y por eso la página de inicio de sesión merece una contraseña fuerte y un segundo factor desde el primer día.

La salida hacia el fiat es donde vuelve la identidad. Nada en esta pila le exige identificarse para aceptar un pago. Convertir lo recaudado en dinero bancario casi siempre sí, porque esa conversión ocurre en un exchange o bróker regulado. Autoalojar traslada el requisito de identidad del punto de venta al punto de salida — una mejora genuina en exposición, que no es lo mismo que su ausencia.

Sus obligaciones de declaración no se trasladaron con el servidor. Dónde está registrado un negocio y dónde vive su propietario deciden lo que se debe y lo que hay que declarar. La jurisdicción de la máquina que emite las facturas no entra en la ecuación. En la mayoría de los lugares, recibir cripto a cambio de bienes o servicios es un ingreso ordinario al valor del día, y su enajenación posterior es de nuevo un hecho imponible aparte. Una instancia autoalojada es un mejor registro que una cuenta de procesador que podría perder — no es una forma de no tener ninguno.

No hay contracargos, y eso corta en ambas direcciones. Un pago confirmado es definitivo, y esa es exactamente la propiedad que hace casi imposible el fraude contra un comerciante y la razón por la que la comisión es cero. También es la razón por la que un cliente insatisfecho no tiene ningún mecanismo más allá de su buena voluntad. Publique una política de reembolsos, use la función de pagos salientes para cumplirla, y entienda que ha asumido usted mismo la resolución de disputas que antes pagaba el porcentaje.

Lo que ha comprado en realidad, con precisión: el dinero llega a un monedero del que solo usted puede gastar, nadie puede impedir la venta, nadie se lleva una comisión, y la lista de quién le pagó qué existe solo en una máquina que usted alquila sin un nombre en particular. Es una afirmación estrecha y real a la vez. Solo vale lo que cuesta si el paso 06 está hecho — un procesador de pagos autoalojado sin una restauración probada no es una mejora del negocio, es un único punto de fallo que retiene sus ingresos.

Dimensionado · Qué pedir

La aplicación es diminuta. La cadena es toda la factura.

Nivel Mensual Recursos Qué ejecuta con holgura
Sentinel$3.902 vCPU · 4 GB · 120 GB · 1 GbpsUn nodo podado de 25–50 GB con Lightning. Añada swap; vigile el disco.
Garrison$7.904 vCPU · 8 GB · 240 GB · 1 GbpsUn nodo podado de 100 GB, Lightning y años de margen. La opción por defecto.
Ravelin$16.908 vCPU · 16 GB · 480 GB · 2.5 GbpsLo mismo, más una segunda cadena o una tienda concurrida con plugins.
Bulwark$32.9016 vCPU · 32 GB · 960 GB · 5 GbpsUn nodo de archivo con margen para seguir creciendo. Solo si necesita el historial.

BTCPay, el indexador y PostgreSQL juntos ocupan unos pocos gigabytes y casi nada de CPU una vez que el nodo está sincronizado; una tienda que reciba cien pagos al día no pondrá en apuros al nivel más pequeño en cómputo. En lo que difieren los niveles es en el disco, y el disco lo decide enteramente el paso 01. La sincronización es la única hora genuinamente pesada del proyecto — está limitada por E/S y no por CPU, que es por lo que aquí importa el NVMe y no el número de núcleos. El ancho de banda no tiene límite en ningún nivel, así que un nodo Lightning accesible públicamente no cuesta nada extra de ejecutar.

Notas de campo · Seis trampas

Seis maneras en que esto sale mal. Dos de ellas cuestan dinero.

Trampa 01 · Fatal

La cuenta de administrador que nadie reclamó

La primera persona en registrarse en una instancia recién creada se convierte en la administradora, y el nombre de host quedó publicado en los registros de transparencia de certificados en el momento en que se emitió el certificado. Regístrese en los minutos siguientes a que termine la instalación, y luego confirme en los Ajustes del servidor que el registro no está abierto a desconocidos.

Trampa 02 · Fatal

El monedero caliente en la máquina pública

Dejar que el servidor genere el monedero es un solo clic, y pone la semilla en una máquina cuyo trabajo es responder a desconocidos. Conecte en su lugar una clave pública extendida: la tienda vigila, deriva y concilia, y no puede gastar. Guarde la mitad privada en un monedero o en un dispositivo de hardware.

Trampa 03 · Tóxica

Restaurar el estado de Lightning de anoche

Una base de datos de canales de ayer describe un estado que su contraparte ya ha superado. Ponerla de nuevo en marcha puede entregarle todo el saldo del canal como penalización. El archivo nocturno cubre la tienda; los canales necesitan el procedimiento de recuperación documentado y una copia de seguridad del canal copiada de forma continua.

Trampa 04 · Silenciosa

Facturas Lightning que nadie puede pagar

Financiar un canal le da capacidad para enviar, no para recibir. Un nodo nuevo con dinero dentro sigue fallando en todos los pagos entrantes, y el error parece un problema de enrutamiento. Consiga liquidez entrante antes de anunciar la opción Lightning, no después de la primera queja.

Trampa 05 · Confusa

Un nodo podado y un monedero con un pasado

Conecte una cuenta de tres años de antigüedad a un nodo podado y sus transacciones antiguas nunca aparecerán, porque los bloques que las contenían fueron descartados. Nada está roto y nada lo indica. Déle a la tienda una cuenta recién creada, o ejecute un nodo de archivo.

Trampa 06 · Evitable

El volumen que se llenó durante la sincronización

Un nodo es el único proceso que crece por sí solo, y un disco lleno corrompe el índice en lugar de detenerse educadamente — lo que significa volver a empezar la descarga. Haga la aritmética del paso 01 contra el nivel que encargó, y active la alerta al ochenta por ciento en lugar de al noventa y cinco.

Preguntas frecuentes · Pagos en Bitcoin autoalojados

Preguntas, respondidas.

Once preguntas que surgen al construir esto — empezando por las dos que deciden si deberías construirlo siquiera.

¿Es BTCPay Server realmente gratis, o hay truco?

Es genuinamente gratis, y la forma de esa gratuidad importa más que el precio. BTCPay Server es software de código abierto publicado bajo una licencia permisiva y mantenido por una fundación y no por una empresa con un objetivo de ingresos; no hay comisión por transacción, ni porcentaje, ni volumen mínimo, ni cuenta que abrir ni contrato que firmar, porque no hay ninguna contraparte — usted está ejecutando un programa en su propio servidor, igual que ejecuta un servidor web. Lo que paga en su lugar es real, pero distinto: unos pocos dólares al mes por la máquina, una tarde para configurarlo, y la obligación permanente de mantener parcheado un servicio que maneja pagos. La comparación que la gente debería hacer en realidad no es "gratis frente a un uno por ciento". Es "una tarea operativa que usted posee frente a una dependencia que no posee", y la respuesta honesta es que una tienda que recibe veinte pagos al año probablemente esté mejor servida por algo alojado, mientras que una que recibe veinte a la semana sale aquí más barata y más libre a la vez.

¿Es custodio? ¿Quién controla realmente las monedas?

Usted, y el mecanismo merece la pena entenderlo en lugar de simplemente confiar en él. La configuración recomendada le da a BTCPay una clave pública extendida de un monedero que ya controla usted. A partir de esa clave, el servidor puede derivar una dirección de recepción nueva para cada factura y vigilar la cadena en busca de pagos a ella — y no puede construir un gasto válido, porque la mitad privada nunca sale de su monedero. El dinero se mueve del cliente directo a una dirección que solo usted puede vaciar; nada se retiene nunca en el servidor, así que no hay nada que retener, congelar o perder en una brecha. BTCPay también le ofrecerá generar un monedero por usted y guardar la semilla en el servidor, lo cual es cómodo y es la única configuración contra la que argumenta esta guía para cualquier cosa que guarde ingresos reales: convierte una máquina pública y expuesta a internet en un monedero caliente. Lightning es la excepción genuina — los fondos del canal tienen que estar activos para poder enrutar — que es la razón por la que el saldo de Lightning debería tratarse como una caja y no como una caja fuerte.

¿Cuánto disco necesito en realidad?

Depende enteramente de una decisión, y el rango abarca dos órdenes de magnitud. Un nodo de Bitcoin Core de archivo guarda todos los bloques jamás minados: bien por encima de 700 GB en 2026, y sumando aproximadamente 50 GB al año, así que necesita un nivel dimensionado para eso, y seguirá necesitando más. Un nodo podado valida todos los bloques exactamente de la misma forma y luego descarta los antiguos, manteniendo una ventana móvil — el generador de despliegue incluye fragmentos que podan hasta unos 100, 50, 25 o 5 GB, y cualquier cifra a partir de 50 GB es una opción de producción perfectamente seria para un comerciante. Añada entre 10 y 20 GB aproximadamente para el indexador, la base de datos, el nodo Lightning y el sistema operativo, y la aritmética sale sola: un nivel de 120 GB soporta un despliegue podado de 25–50 GB, uno de 240 GB soporta uno de 100 GB con años de margen, y el de archivo pide 960 GB. Elija podado salvo que tenga una razón específica para no hacerlo; el modelo de seguridad es idéntico.

¿Puedo ejecutar BTCPay sin mi propio nodo de Bitcoin?

En parte, y merece la pena saber exactamente dónde está la línea. La pila se puede apuntar a un nodo de Bitcoin que ya ejecute usted en otro sitio — una máquina en el mismo tailnet, o una detrás de un túnel — y eso es una disposición totalmente soportada que le ahorra una segunda copia de la cadena si ya ha hecho el trabajo en la guía del nodo Lightning. Lo que no puede hacer con sensatez es ejecutar un procesador de pagos contra el nodo público de otra persona, y la razón no es de licencias sino de privacidad y confianza: quien responda a sus consultas aprende todas las direcciones que vigila su tienda, que es lo mismo que aprender sus ingresos, y además puede mentirle sobre si una factura se pagó. Hay una tercera opción a la que la gente recurre — usar una instancia de BTCPay alojada y operada por un tercero — y es una forma perfectamente razonable de empezar. Solo tenga claro que eso traslada los datos de la tienda a un operador que puede verlos, que es la mayor parte de para lo que servía autoalojar.

¿Tengo que hacer la parte de Lightning?

No, y es perfectamente razonable saltársela el primer día. Solo on-chain es una configuración completa y funcional: las facturas se pagan, el cliente espera una confirmación, la tienda liquida. Lo que Lightning compra es la diferencia entre "unos diez minutos y una comisión que duele en importes pequeños" y "dos segundos y una fracción de céntimo", que es la diferencia entre un checkout que funciona para una factura de $400 y uno que también funciona para una de $4. El coste es que Lightning es un segundo demonio con sus propios fondos, sus propios modos de fallo y su propia disciplina de copias de seguridad — incluyendo el problema de liquidez entrante del paso 05 y el aviso de estado tóxico del paso 06. Un orden sensato es lanzar on-chain, confirmar que toda la cadena funciona con dinero real, y añadir Lightning como un segundo proyecto deliberado en lugar de acoplarlo la misma tarde.

¿Qué monedero debería conectar a la tienda?

Cualquier monedero que pueda exportar una clave pública extendida para una sola cuenta — Sparrow, Electrum, BlueWallet, o un monedero de hardware a través de uno de ellos — y lo importante no es la marca, sino que sea una cuenta dedicada y no la que guarda sus ahorros. Dos razones. La primera es la privacidad, y es permanente: una clave pública extendida es un índice maestro de todas las direcciones que llegará a derivar, así que cualquiera que la obtenga puede enumerar todos los pagos que esa cuenta ha recibido y recibirá. Darle a la tienda su propia cuenta significa que una filtración expone la facturación de la tienda y nada más. La segunda es operativa: una cuenta dedicada hace legibles los ingresos de la tienda sin que tenga que hacer forense sobre un historial mezclado, y hace que trasladar los fondos a almacenamiento en frío sea una decisión única y aburrida. Un monedero de hardware que guarda la clave privada, con la tienda vigilando la pública, es la disposición a la que aspirar.

¿Puedo aceptar Monero, u otras monedas, en la misma instancia?

Sí, con la salvedad de que cada cadena adicional es todo un nodo adicional, con su propio disco, su propio tiempo de sincronización y su propio mantenimiento. El generador soporta directamente una segunda y una tercera criptomoneda, y hay una integración de Monero disponible como fragmento adicional — el mismo despliegue le presenta entonces al cliente una elección de rieles en el checkout. Lo que la gente subestima es la factura de recursos: cada cadena que activa es otro demonio indexando otro libro mayor en el mismo volumen, y dos cadenas en un nivel dimensionado para una es cómo una máquina de pagos se queda sin disco un domingo. Si Monero es importante para su tienda, lea primero la guía del nodo de Monero y valore darle su propia máquina; un procesador de pagos caído porque un demonio ajeno llenó el disco es peor que uno que solo acepte Bitcoin.

¿Cómo se conecta esto a una tienda real?

Cuatro formas, en orden creciente de cuánto software tiene usted ya. Si no tiene nada, BTCPay incluye una página alojada de punto de venta y de solicitud de pago que puede enviar como enlace — eso basta para facturar a un cliente o cobrar en un puesto de mercado sin ningún sitio web. Si tiene un sitio estático, un botón de pago es un fragmento de HTML. Si tiene una tienda real, existen plugins mantenidos para las plataformas de comercio electrónico habituales que convierten Bitcoin en un método de pago más en el checkout, con el estado del pedido actualizado automáticamente. Y si tiene su propia aplicación, la API REST emite facturas, informa de su estado, y llama a un webhook que usted especifique cuando una se liquida — que es la integración que mejor envejece, porque no depende de nada más que de HTTP. Empiece con una solicitud de pago, compruebe que el dinero llega, y luego intégrelo.

¿Qué pasa si el VPS muere — pierdo dinero?

Para on-chain, no, y esta es la recompensa silenciosa del diseño de solo lectura: las monedas nunca estuvieron en el servidor. Las direcciones se derivan de una clave pública, así que una instalación nueva con la misma clave pública extendida redescubre todos los pagos; lo que se pierde en un fallo total es la configuración de la tienda y su historial de facturas, que es para lo que sirve el script de copia de seguridad. Lightning es una respuesta genuinamente distinta y merece su propia frase: los fondos del canal están vivos, el estado del canal cambia con cada pago, y restaurar una copia antigua de ese estado puede costarle directamente el saldo del canal, porque publicar un estado superado es exactamente lo que el protocolo castiga. Así que la postura correcta es asimétrica. Haga copia de seguridad de la base de datos y la configuración con regularidad, cífrela, envíela a algún sitio que no sea esta máquina — y trate la copia de seguridad estática de canal de Lightning como un artefacto aparte, copiado de forma continua, y no como una línea más del archivo nocturno.

¿Autoalojar el procesador significa que no tengo obligaciones de declaración?

No, y merece la pena ser directo al respecto porque calladamente se asume lo contrario. Quitar el procesador de pagos elimina a un intermediario, una comisión y una parte que podría congelar sus fondos. No cambia lo que usted debe, a quién, ni si una venta está sujeta a impuestos — eso depende de dónde estén usted y su negocio, no de dónde esté el servidor ni de qué software emitió la factura. En la mayoría de las jurisdicciones, recibir criptomonedas a cambio de bienes o servicios es un ingreso ordinario de la actividad, valorado el día en que se recibió, y su enajenación posterior es otro hecho imponible aparte; que el registro viva ahora en su propia base de datos y no en la de un procesador no lo vuelve opcional, y una instancia autoalojada es en la práctica un mejor rastro de auditoría que una captura de pantalla de una cuenta que ya no tiene. Donde sí hay una ganancia de privacidad honesta, y más acotada, es aquí: ningún tercero guarda una lista continua de sus clientes e importes. Pregunte a un asesor fiscal de su propia jurisdicción por el resto.

¿NordBastion permite un procesador de pagos en un VPS?

Sí — una instancia de BTCPay es una aplicación web corriente, con una base de datos corriente y un demonio de blockchain corriente, y no hay nada en la política de uso aceptable que la trate de forma distinta a una tienda o un blog. Las notas prácticas tienen que ver con los recursos, no con la política: un nodo en sincronización es pesado en disco y en E/S durante su primer día y luego está casi inactivo, el ancho de banda no tiene límite en ningún nivel, así que un nodo Lightning público no está limitado, y los puertos entrantes para conexiones entre pares son suyos para abrir. La parte que encaja con el resto del sitio es la simetría: la cuenta no necesita su nombre legal, la factura se liquida en Monero, Bitcoin o Lightning, y la máquina que ahora conoce a todos sus clientes está alquilada a una empresa que no sabe quién es usted. Un procesador que autoaloja en una cuenta identificada ha trasladado el libro de cuentas, no la exposición.

Obtener la máquina

Un checkout propio, en una cuenta que no lleva su nombre. Sin KYC, pago en criptomoneda.

Garrison — 4 vCPU, 8 GB y 240 GB de NVMe por $7.90 al mes, en Helsinki, Stockholm, Oslo o Reykjavík. Suficiente para un nodo de Bitcoin podado, un demonio Lightning, el indexador y la tienda, con margen para años. Sin correo al darse de alta, sin documento de identidad, y sin ninguna empresa que guarde la lista de todos los que le han pagado alguna vez.

Última revisión · 2026-10-12 · Fuentes · Documentación de BTCPay Server (despliegue con Docker, fragmentos de almacenamiento, copia de seguridad y restauración, ajustes de la tienda), documentación de Bitcoin Core sobre la poda, documentación de la implementación Lightning sobre copias de seguridad estáticas de canal · Cadencia · anual

Alojamiento privado, construido en el Norte.