Bitcoin Payment Processor crea solicitudes de pago, asigna los pagos recibidos a pedidos y facilita su registro. Puede alojarse por cuenta propia u ofrecerse como servicio. No es una regla del consenso de Bitcoin y la denominación procesador no indica quién controla los fondos.
La tienda crea un pedido y su servidor solicita al procesador una factura con importe y moneda. Guarda la relación entre el número interno del pedido y el identificador de la factura. El cliente recibe una página de pago o un código QR y el procesador vigila la recepción. Sin esa relación no puede determinarse con fiabilidad qué pedido satisface el pago; volver al navegador no demuestra por sí solo que se haya pagado. [BTCPay Server — eCommerce integration]
BTCPay Server puede derivar direcciones de recepción a partir de los datos públicos de una cartera existente sin su clave privada. Esto difiere de una cartera caliente almacenada en el servidor y del acceso a los fondos de un nodo Lightning. Un proveedor puede retener los fondos hasta el abono al comercio. Examine quién posee realmente las claves, los permisos y la capacidad de retirar fondos, no solo el nombre del producto o la expresión non-custodial. [BTCPay Server — General FAQ] [BitPay — Configuring settlements]
Una factura habitual de BTCPay Server fija el tipo de cambio durante un tiempo limitado. Su vencimiento no impide que llegue una transferencia posterior. Los pagos insuficientes, excesivos y tardíos tienen estados distintos y requieren procedimientos posteriores. Conserve el importe original y el tipo de cambio aplicado; si cambia el precio, una nueva solicitud puede exigir una cantidad diferente de satoshis. [BTCPay Server — Invoice lifecycle]
BTCPay Server distingue Processing, que espera las confirmaciones configuradas, de Settled; los pagos Lightning correctos pasan a Settled sin esperar un bloque. Los nombres de estado de otros proveedores no son equivalentes automáticamente: BitPay advierte expresamente que paid no garantiza el pago. La tienda necesita una regla de entrega para cada estado y método de pago concreto. Cambiar manualmente un estado no genera una confirmación de la red. [BTCPay Server — Invoice lifecycle] [BitPay — Invoice webhooks]
BTCPay verifica el webhook mediante HMAC-SHA256 sobre los bytes originales del cuerpo y un secreto compartido. BitPay describe IPN sin firma: la notificación sirve para iniciar una consulta del estado de la factura por API, no es por sí misma una prueba fiable. Las notificaciones pueden repetirse. Por ello, la integración debe reconocer de forma segura un evento reenviado e impedir un segundo envío del mismo pedido; después de una interrupción hay que conciliar los estados guardados con el procesador. [BTCPay Server — Webhook validation example] [BitPay — Invoice webhooks]
La confirmación del pago del cliente puede no coincidir con el abono del proveedor. BitPay permite configurar la moneda de liquidación y una cuenta bancaria o dirección de criptomonedas; un cambio puede requerir aprobación. Compruebe las monedas disponibles, límites, plazos, comisiones y quién controla los fondos hasta el abono. La recepción directa en una cartera propia no utiliza automáticamente este modelo de pago por parte del proveedor. [BitPay — Configuring settlements] [BTCPay Server — General FAQ]
Un reembolso requiere otro pago y verificar al destinatario; no modifica la transacción original de bitcoin. Separe la reclamación del pedido, la decisión sobre el importe a devolver y el envío efectivo del dinero. Conserve los vínculos pedido–factura–pago, tipos de cambio, comisiones y reembolsos. Exportar un informe ayuda al registro, pero no resuelve por sí solo todas las obligaciones contables locales ni una disputa sobre la entrega. Ni siquiera una transferencia confirmada resuelve por sí sola la firmeza jurídica de la operación: compruebe reclamaciones, posibles mecanismos de chargeback y obligaciones según la vía de pago, el contrato y la jurisdicción. [BTCPay Server — Refunds] [BTCPay Server — Reporting] [BitPay — Merchant and shopper terms]
Pruebe pagos correctos, incompletos, tardíos y notificados repetidamente, además de la recuperación tras una interrupción. Conceda a la clave API solo los permisos necesarios y limítela a la tienda correspondiente. No incluya datos innecesarios del cliente en los metadatos. Tenga en cuenta alojamiento, actualizaciones, liquidez y soporte; un programa gratuito no implica costes operativos nulos. La disponibilidad del servicio, la custodia de claves y la corrección de la integración son requisitos distintos. [BTCPay Server — eCommerce integration] [BTCPay Server — Lightning operations]
La misma notificación no es otra compra
En una integración hipotética, el pedido OBJ-101 tiene guardado el identificador de su factura. Tras verificar su liquidación, el sistema crea el envío una sola vez. Si después llega una notificación repetida del mismo evento, la asocia al pedido ya atendido y no crea otro envío. Mostrar una página de agradecimiento no debe activar por sí solo esa transición.
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 Pagos Bitcoin en Alza, Merchant Adoption, BTCPay Server, Bitcoin Point of Sale.
01¿Todos los procesadores de pagos custodian mis bitcoins?+
No. Algunas soluciones solo crean solicitudes y vigilan la recepción en su cartera; otras administran los fondos hasta el abono. Incluso un mismo programa puede utilizar distintos modelos de cartera. Lo decisivo son las claves, los permisos y el flujo real de fondos, no la denominación procesador.
02¿Puede la tienda enviar el pedido cuando el cliente vuelve de la página de pago?+
El regreso por sí solo no basta. La tienda debe verificar la factura correspondiente y su estado mediante el procedimiento del procesador. Las notificaciones se verifican según la documentación y su repetición no debe generar otra entrega. La entrega de productos sigue las condiciones elegidas de confirmación del pago.