Bitcoin Point of Sale es una caja para cobrar en bitcoin en ventas presenciales. Ayuda a calcular el precio, solicitar el pago y comprobar su llegada. Puede ser una aplicación en un teléfono o una tableta, o un terminal independiente. El aparato no dice por sí solo si el comercio controla el dinero o un proveedor lo guarda por él.
El personal elige el café o introduce el precio y comprueba la moneda, la propina y el total. BTCPay Server, por ejemplo, ofrece catálogo, carrito o teclado numérico. Después crea una invoice: una solicitud de pago vinculada a esa compra. La relación permite saber por qué llegó cada pago. Recargar la pantalla no debe añadir otro café a las ventas. El pedido y su registro de pago deben seguir siendo localizables. [1] [2]
La cafetería puede fijar el precio en coronas checas y convertirlo a bitcoin mediante la fuente de cotización elegida. Antes de enviar, el cliente debe ver el importe y la vigencia de la solicitud, y comprobar destinatario y red. BOLT 11 es un formato de solicitud para Lightning. Incluye un hash de pago, una huella criptográfica relacionada con la prueba del pago, y un vencimiento; el importe puede quedar sin especificar. Por eso, escanear no basta: hay que revisar la cantidad realmente solicitada para esa compra. Mostrar coronas no significa que la cafetería vaya a recibir coronas en su cuenta bancaria. [3] [4]
Un código QR transmite datos de pago, no una prueba de recepción. Una captura del cliente no sustituye la comprobación de la cafetería. En BTCPay Server, Processing indica que se pagó todo el importe, pero faltan condiciones de liquidación, como las confirmaciones requeridas en bloques. Settled indica que se cumplieron. También existe el marcado manual, que no crea un pago ni una confirmación reales. Un pago Lightning exitoso normalmente no espera un bloque. Entrega el producto según la recepción comprobada y las reglas del comercio, no por el color de una pantalla ajena. [2]
La caja puede recibir en la cartera del comercio o usar un servicio que custodia los fondos. Importan las claves privadas que permiten gastar, los permisos y las condiciones de retirada, no el logotipo Bitcoin. Los datos públicos de una cartera pueden bastar para generar direcciones de recepción. Aun así, una caja comprometida puede mostrar la dirección de un atacante para pagos futuros. El personal no necesita los mismos permisos que el administrador: vender café no es lo mismo que cambiar el destinatario o aprobar una devolución. [5] [6] [7]
Lightning envía pagos por canales conectados. Un nodo propio, el programa que participa en esa red, debe estar disponible y tener liquidez entrante: espacio en los canales para recibir fondos. Un proveedor puede asumir parte del trabajo, pero cambia los costes y en quién confías. No encontrar una ruta o carecer de liquidez no equivale a pagar. Antes de probar otro método, el personal verifica el resultado del primer intento para evitar cobrar dos veces el mismo café. [7] [4]
La tableta puede perder internet, el servidor dejar de responder o la cotización no cargar. Quizá no se pueda crear una solicitud ni verificar la recepción. Un QR impreso sigue siendo legible, pero eso no demuestra que el sistema funcione. Hace falta un procedimiento acordado: conexión alternativa, aplazar la venta o localizar el pago después. Una interrupción no demuestra que el cliente no pagó. Los pagos parciales, excesivos o posteriores al vencimiento se valoran individualmente; cambiar un registro a mano no reescribe la historia de la red. [2] [3]
Un reembolso es otro pago vinculado a la compra original. Hay que acordar importe y moneda, verificar el destino y obtener autorización. BTCPay Server separa, por ejemplo, crear una solicitud de reembolso de enviar el desembolso. Dar un enlace al cliente no significa que ya recibió el dinero. El personal distingue una solicitud preparada, un envío pendiente y una devolución completada; la transferencia original permanece en el historial. [8]
Al terminar el turno, concilia pedidos, cobros, comisiones, devoluciones y posibles liquidaciones del proveedor. BTCPay Server exporta pagos, productos vendidos y movimientos de la cartera on-chain, la que opera directamente con la cadena de Bitcoin. Los informes ayudan, pero no cumplen por sí solos todas las obligaciones contables y fiscales locales. Antes de abrir el servicio, ensaya una venta normal, una interrupción y la recuperación. Limita el acceso a datos de clientes y cuenta con los costes de equipos, conexión y mantenimiento. [9] [1] [6]
Un café, un teléfono pagado y una tableta desconectada
En el pedido ilustrativo POS-497, el cliente muestra un pago exitoso justo cuando la tableta pierde conexión. El personal no crea enseguida otra solicitud ni marca la compra como impagada. Recupera la conexión, busca la invoice original y contrasta el importe con la recepción real. Según el resultado, termina la venta o gestiona otro intento. Todo queda ligado al mismo pedido para no contabilizar dos veces ni el pago ni la venta.
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 QR sobre el mostrador?+
El código transmite datos, pero no sabe si llegó el dinero ni a qué compra corresponde. El personal necesita verificar la recepción de forma fiable y saber qué hacer ante un importe incorrecto, una solicitud vencida o falta de conexión.
02¿Lightning significa que la cafetería custodia su dinero?+
No automáticamente. Puede operar su nodo o usar un servicio con otros permisos, incluida la custodia por un proveedor. Comprueba quién controla claves y saldo, quién recibe los pagos y bajo qué condiciones puede retirar el comercio.