Bitcoin Point of Sale es una interfaz de caja para ventas presenciales: calcula el precio de la compra, crea una solicitud de pago, asocia el pago recibido y conserva un registro. Puede funcionar en un teléfono, una tableta o un terminal; el aspecto del dispositivo no determina quién controla las monedas.
El personal selecciona productos o introduce un importe y comprueba la moneda, la propina y el total final. BTCPay Server ofrece catálogo, carrito y teclado numérico. Cada compra debe poder rastrearse mediante un pedido y una factura; volver a abrir la pantalla no debe crear un segundo registro de venta. [BTCPay Server — Point of Sale app] [BTCPay Server — Invoice lifecycle]
El precio en moneda local se convierte según la fuente de cotización configurada; la caja debe mostrar el importe esperado en bitcoin y la vigencia de la oferta. BOLT 11 contiene los datos de la factura Lightning, incluidos el hash de pago y la caducidad; el importe puede ser opcional. Para una compra concreta hay que verificar el importe real, la red y el destinatario. Calcular el precio no equivale a vender bitcoin por moneda fiduciaria. [BTCPay Server — Store rates and policies] [Lightning BOLTs — Invoice protocol]
Un código QR solo transmite los datos de pago. Una captura de la pantalla del cliente no sustituye al estado en el sistema del comercio. En BTCPay Server, Processing espera las confirmaciones on-chain elegidas; Settled indica que se cumplió la política, pero también puede establecerse manualmente. Un pago Lightning exitoso no espera confirmación de bloque. Por tanto, la entrega se basa en un pago verificado, no solo en el color de una pantalla. [BTCPay Server — Invoice lifecycle]
Una misma tableta puede dirigir los cobros a una cartera propia o utilizar un proveedor custodial. Lo determinante son las claves, los permisos y las condiciones de liquidación, no el logotipo Bitcoin. Ni siquiera recibir mediante una clave pública descarta que una caja o un servidor comprometidos sustituyan una dirección futura. Separe los permisos del personal de los que permiten cambiar el destinatario, administrar la cartera o aprobar reembolsos. [BTCPay Server — Wallet setup] [BTCPay Server — Third-party hosting risks] [BTCPay Server — Lightning setup]
Un nodo Lightning propio exige operación, canales y liquidez entrante. Un proveedor puede asumir parte del trabajo, pero cambia los costes y la confianza. Un fallo de enrutamiento o la falta de liquidez no constituyen un pago exitoso. Antes de cambiar de método de pago, el personal verifica el resultado del intento original para evitar dos pagos por una compra. [BTCPay Server — Lightning setup] [Lightning BOLTs — Invoice protocol]
La falta de internet, del backend o de la fuente de cotización puede impedir una nueva solicitud o verificar la recepción. Un código mostrado o impreso puede seguir siendo legible sin un estado actualizado. El procedimiento debe definir una conexión alternativa, el aplazamiento de la venta y la búsqueda posterior del pago. Evalúe por separado pagos insuficientes, excesivos y posteriores a la caducidad; un cambio manual de estado no cambia la historia de la red. [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies]
Devolver fondos requiere vinculación con la compra original, importe y moneda acordados, destino verificado y aprobación autorizada. BTCPay Server separa la creación de una solicitud de reembolso del envío de los fondos. La transferencia original no se borra. El personal debe distinguir entre una solicitud creada, un envío pendiente y una devolución efectivamente completada. [BTCPay Server — Refund workflow]
Al terminar el turno, concilie pedidos, pagos recibidos, comisiones, reembolsos y posibles liquidaciones del proveedor. BTCPay Server exporta informes de pagos, productos vendidos y cartera on-chain; la exportación por sí sola no garantiza cumplir los requisitos contables y fiscales locales. Pruebe los procedimientos del personal, las interrupciones y la recuperación, limite el acceso a los datos de clientes y contemple los costes del dispositivo, la conexión y la operación. [BTCPay Server — Reporting] [BTCPay Server — Point of Sale app] [BTCPay Server — Third-party hosting risks]
Dos pantallas, una compra
En el pedido hipotético POS-497, el cliente muestra un pago exitoso, pero la tableta del personal pierde la conexión. El personal no marca automáticamente la compra como impagada ni emite inmediatamente otra solicitud. Restablece la conexión, busca la factura original y verifica su importe y el estado real de recepción. Solo entonces decide si entrega los productos o inicia otro intento y registra el resultado en el mismo pedido.
Para obtener la imagen más completa, lee esta entrada junto con Merchant Adoption, BTCPay Server, Bitcoin Payment Processor, BOLT 11, Confirmación, Bitcoin. También enlazan con esta entrada Merchant Adoption, Bitcoin Payment Processor, BTCPay Server, BTC Map.
01¿Basta un código QR en la caja?+
El código transmite datos de pago, pero no verifica por sí mismo la recepción ni asocia el pago con la compra. La caja necesita un estado de pago fiable y un procedimiento para importes incorrectos, caducidad y falta de conexión.
02¿Pagar por Lightning implica siempre autocustodia del comercio?+
No. La caja puede utilizar un nodo propio, otro modelo de servicio o un proveedor custodial. Verifique quién controla las claves y el saldo, quién gestiona la recepción y bajo qué condiciones se pueden retirar los fondos.