Bitcoin Payment Processor es un programa o servicio que crea solicitudes de pago, sigue los pagos entrantes y los relaciona con pedidos. Ayuda a completar ventas y conservar registros. No establece las reglas de la red Bitcoin ni necesariamente custodia el dinero: quién controla las claves y quién abona los fondos depende de la configuración.
Imaginemos que alguien compra un libro por internet. La tienda pide al procesador una invoice, una solicitud de pago con importe y moneda, y guarda su identificador junto al número de pedido. El cliente abre la página de pago o escanea un código QR y paga. La relación guardada permite saber a qué compra corresponde el dinero. Sin ella, detectar que ha llegado bitcoin a alguna dirección no basta. Volver a una página de agradecimiento tampoco demuestra que la tienda haya recibido el pago. [1]
BTCPay Server puede generar direcciones de recepción a partir de los datos públicos de una cartera existente, sin obtener las claves privadas que permiten gastar. Es distinto de una cartera caliente con claves en el servidor o del acceso a fondos de un nodo Lightning que gestiona pagos rápidos. En un servicio, el proveedor puede controlar los fondos antes del abono. Por eso no basta la etiqueta non-custodial, que indica que las claves no se confían al proveedor. Hay que comprobar permisos reales, quién puede enviar el dinero y si recuperarlo requiere autorización ajena. [2] [6]
El libro puede tener un precio en moneda convencional mientras el cliente envía bitcoin. BTCPay Server fija el importe y el tipo de cambio de la solicitud durante un plazo limitado. El vencimiento no impide que llegue una transferencia posterior; la tienda debe gestionarla correctamente. Lo mismo ocurre con pagos insuficientes o excesivos. El importe y el cambio originales se conservan para la conciliación. Una solicitud nueva con otro cambio puede exigir una cantidad distinta de satoshis, las unidades más pequeñas de bitcoin, aunque el precio del libro siga igual. [3]
En BTCPay Server, Processing significa que se ha pagado el importe solicitado, pero aún faltan condiciones de finalización, como confirmaciones de la transacción en bloques. Settled indica que se cumplen; los pagos Lightning normalmente no esperan confirmaciones en bloques. Otros servicios definen sus propios estados. BitPay advierte expresamente que paid no garantiza el pago. La regla de envío debe ajustarse a la documentación del servicio y al método elegido. Marcar manualmente un pedido como pagado no sustituye la comprobación del pago real. [3] [5]
El procesador comunica cambios mediante un webhook, un mensaje automático entre servidores. La tienda debe verificar su origen y contenido. En BTCPay, HMAC-SHA256 se calcula sobre los bytes originales del mensaje y un secreto compartido: es un código de autenticación, no una confirmación de la red Bitcoin. BitPay no firma su aviso IPN; solo debe provocar una consulta del estado real mediante la API, la interfaz con la que se comunican los programas. Los mensajes pueden repetirse. La tienda registra el cumplimiento del pedido para evitar otro envío, y tras una interrupción concilia sus estados con los del procesador. [4] [5]
Recibir el pago del cliente y recibir el abono del servicio son hechos distintos. BitPay permite configurar una moneda de liquidación admitida y una cuenta bancaria o dirección de criptomonedas; los cambios pueden necesitar aprobación. También hay que comprobar plazos, límites, comisiones y quién controla los fondos hasta el abono. Recibir directamente en una cartera propia puede evitar ese paso intermedio. El sistema de ventas debe distinguir ambos modelos para que “pagado” no dé una impresión falsa del dinero disponible. [6] [2]
El reembolso no borra la transacción original de Bitcoin. La tienda atiende primero la solicitud, determina importe y moneda, verifica al destinatario y dispone un nuevo pago. Un enlace para reclamar el reembolso todavía no significa que el dinero se haya enviado. Se conservan pedido, solicitud de pago, cobro, cambio aplicado, comisiones y devolución. Los informes exportados ayudan a la contabilidad, pero no satisfacen por sí solos todas las obligaciones locales. La confirmación de la red tampoco resuelve una disputa de entrega ni elimina deberes contractuales o legales ante una reclamación. [7] [8] [10]
Una compra de prueba correcta no basta antes del lanzamiento. Hay que ensayar pagos insuficientes, tardíos, avisos repetidos y recuperación tras una interrupción. Una clave API es la credencial de acceso de un programa: recibe solo los permisos necesarios para esa tienda. Los datos adjuntos no deben incluir información personal innecesaria. La gestión propia exige alojamiento, actualizaciones y soporte; Lightning también requiere gestionar liquidez, es decir, fondos y espacio en canales para pagar. Software gratuito no equivale a operación gratuita. Disponibilidad, protección de claves e integración correcta se revisan por separado. [1] [9]
Un libro pagado y un mensaje repetido
La tienda vincula la solicitud de pago al pedido OBJ-101. Verifica el pago, cumple las condiciones de envío, manda el libro y registra la entrega al transportista. Más tarde llega el mismo aviso. El sistema reconoce el pedido ya atendido y no crea otro paquete. Abrir únicamente la página de agradecimiento no habría bastado para iniciar el envío.
Para obtener la imagen más completa, lee esta entrada junto con BTCPay Server, Bitcoin Point of Sale, Merchant Adoption, Lightning Network, Bitcoin. También enlazan con esta entrada Pago con Bitcoin en Alza, Merchant Adoption, BTCPay Server, Bitcoin Point of Sale.
01¿Tengo que confiar bitcoin al procesador?+
No siempre. El programa puede seguir pagos a tu cartera sin claves para gastar. Una cartera caliente en el servidor, acceso a un nodo Lightning o un servicio con abono posterior implican condiciones diferentes. Evalúa el control real del dinero y los permisos, no solo la etiqueta non-custodial.
02¿Puedo enviar cuando el cliente vuelva a la tienda?+
No. El regreso en el navegador es solo una acción en la página. La tienda necesita el estado verificado del pago concreto y una regla de cumplimiento apropiada para ese método. Los avisos repetidos sobre un mismo pago tampoco deben provocar varios envíos.