Cómo funciona un pago en cripto, de inicio a fin

Un pago cripto mueve un activo aceptado desde la billetera de quien paga hasta el saldo de un comercio. El negocio crea una factura, quien paga envía los fondos a su dirección de cobro, la red incluye la transacción en un bloque y el procesador aplica una política de confirmaciones antes de abonarle el importe al comercio.

Ver una transacción no es lo mismo que tenerla liquidada. La propagación por la red, la inclusión en un bloque y la finalidad son eventos separados, así que conviene que un comercio entregue a partir del resultado confirmado del procesador y no de un temporizador de billetera o de una promesa fija.

¿Cómo empieza un pago cripto?

El backend o la tienda del comercio crea una factura antes de mostrar la página de pago. La creación de facturas en Paymos usa un external_order_id que envía quien llama a la API y que une el pedido del comercio con la solicitud de pago. Si se reutiliza el mismo identificador, Paymos devuelve la factura existente.

Ese comportamiento da a ambos sistemas una única referencia de negocio estable. Conviene que el comercio conserve la relación entre su pedido y la factura de Paymos correspondiente para poder conciliar después.

Trata una petición de transporte repetida como otro intento del mismo pedido. Reutiliza el valor original tras un tiempo de espera agotado y asigna uno distinto solo cuando el cliente empieza una compra nueva.

¿Por qué cada factura recibe su propia dirección?

Paymos deriva una dirección determinista propia para cada factura. Una transferencia que llega a esa dirección se puede asociar así a la factura sin depender solo del importe. Las direcciones separadas también aclaran la conciliación en cadena cuando dos clientes deben el mismo valor.

Las transacciones salientes de Paymos se firman en infraestructura aislada y solo pueden ir a direcciones de destino controladas por el comercio e incluidas en su lista blanca. El pago entrante lo sigue firmando quien paga con su propia billetera.

¿Qué ocurre cuando quien paga envía la transacción?

La billetera construye una transferencia hacia la dirección de la factura y la firma con la clave privada de quien paga. Después difunde la transacción firmada a los pares de la red elegida. La billetera de quien paga cubre la comisión de red necesaria para enviar el pago.

Esa comisión sigue las reglas de la red elegida y cambia con las condiciones del momento. Es independiente de la comisión de procesamiento de Paymos. Paymos liquida al comercio en el activo aceptado en lugar de forzar una conversión a BTC, ETH o moneda fiduciaria.

¿Qué pasa en las redes que usan mempool?

En las redes que exponen un mempool, este es la vista local que un nodo tiene de las transacciones válidas que aún no entraron en un bloque. Los nodos intercambian transacciones con sus pares, pero la propagación lleva tiempo y las políticas locales de admisión pueden diferir. Dos nodos pueden mostrar por tanto conjuntos pendientes distintos en el mismo momento. Otras redes exponen el trabajo pendiente con mecanismos diferentes, así que esta etapa no es universal.

La distinción importa cuando una billetera informa de que difundió una transacción. Difundir significa que la billetera la envió a sus pares; no demuestra que todos los nodos la hayan recibido, que un validador la haya incluido ni que el pago haya alcanzado la finalidad.

¿Qué cambia cuando la transacción entra en un bloque?

La inclusión en un bloque coloca la transacción en la historia de cadena que observa la red. Es una prueba más fuerte que una vista pendiente local, aunque inclusión y finalidad no son lo mismo. Cada red usa reglas de consenso y señales de confirmación distintas.

Un procesador sigue la red elegida y asocia la transferencia incluida a la dirección de la factura. El comercio sigue esperando a la política de confirmaciones del procesador antes de entregar el pedido. El primer aviso de inclusión de una billetera no debería sustituir a esa regla de negocio.

Mantener esas etapas separadas evita que una notificación de bloque acabe disparando una entrega sin querer.

¿Cómo decide Paymos cuándo abonar al comercio?

La política de confirmaciones de Paymos depende de la red y del importe del pago. Los pagos pequeños pueden necesitar menos confirmaciones, mientras que los grandes pueden exigir un umbral de finalidad más fuerte. El estado actual de la blockchain determina cuánto se tarda en alcanzar ese umbral.

No hay, por tanto, un tiempo de liquidación ni un recuento de bloques universales para todos los pagos. La regla operativa es directa: deja el pedido sin entregar hasta que Paymos comunique el pago como confirmado y concílialo después contra la factura original.

Esta regla mantiene coherente la entrega del comercio sin copiar los tiempos de una red a otra vía de pago.

¿Cómo debería proteger el comercio sus notificaciones?

Tras la confirmación, Paymos abona el activo aceptado en el saldo del comercio. Para las notificaciones de la integración, Paymos ofrece webhooks autenticados con HMAC-SHA256 mediante la cabecera X-Webhook-Signature. Quien recibe puede verificar que la notificación se firmó con su secreto de webhook.

Un ciclo de entrega de Paymos hace 11 intentos en total a lo largo de unas 16 horas, con reintentos cada vez más espaciados hasta las ocho horas. Si un evento sigue sin entregarse, se puede reenviar a mano. Estos datos de entrega describen alcance y recuperación sin dar por hecho una cola interna ni un diseño de base de datos concretos.

¿Qué pasa cuando quien paga envía de menos?

El tratamiento del pago insuficiente sigue la tolerancia porcentual del proyecto. Un proyecto nuevo nace con un 0,1 % y el rango va del 0 % al 2 %; con 0 % la coincidencia es estricta. Un pago dentro de la tolerancia configurada completa la factura y el comercio recibe el importe realmente pagado.

Por debajo del umbral, una factura de pago único queda como pago insuficiente. Una factura de varios pagos puede seguir abierta mientras quien paga envía el resto. Esta es una regla confirmada de Paymos; el artículo no da por hechos resultados sin documentar para pagos de más, transferencias tardías o reorganizaciones de la cadena.

Conviene que el comercio conserve el importe recibido de verdad y el resultado de la factura, para que la entrega siga la regla configurada y no el importe que se esperaba al principio.

¿Qué debería garantizar la integración del comercio?

La integración debería mantener tres fronteras explícitas. Primera: reutiliza el external_order_id del pedido y conserva la relación entre ese pedido y su factura de Paymos. Segunda: trata la difusión desde la billetera y la inclusión en un bloque como avances, no como liquidación definitiva. Tercera: verifica el HMAC del webhook antes de actuar sobre la notificación.

La entrega del pedido debería seguir el resultado de pago confirmado y aguantar sin daños si el comercio reintenta su propio trabajo. Si la entrega de un webhook necesita recuperación, Paymos ofrece intentos repetidos y reenvío manual en lugar de obligar al negocio a deducir la liquidación del tiempo transcurrido.

¿En qué se diferencia esto de un pago con tarjeta?

Un pago con tarjeta pide a un emisor y a una red de tarjetas que autoricen un cargo y después sigue el calendario de liquidación del adquirente. Un pago cripto transfiere un activo aceptado en cadena, y sus tiempos siguen a la red elegida, al importe del pago, a las condiciones del momento y a la política de confirmaciones.

Cuando un pago en cadena alcanza la finalidad, ya no se puede revertir con un contracargo de una red de tarjetas. Un reembolso es una transacción nueva de salida en la blockchain que inicia el comercio. Paymos liquida además en el activo recibido y no ofrece una vía de conversión a cuenta bancaria.