¿Por qué tu saldo no coincide con tus facturas?

El saldo y el pedido no se mueven a la vez. Ahí se rompe la conciliación de pagos en cripto, y no en la parte criptográfica: una factura puede recibir tres abonos separados, otra se queda abierta con dinero real dentro, y a una tercera le entra una transferencia que no la toca. Paymos anota cada uno de esos movimientos en un libro mayor por partida doble, donde cada apunte toca dos cuentas y el saldo de tu comercio es una de ellas.

Una cifra única no tiene dónde escribir esa diferencia. El libro sí: para cada suceso puede decir qué cuenta se movió, incluidos los que no disparan ningún webhook.

Abajo van seis de ellos, con lo que le hace cada uno al saldo y lo que le hace a la factura en ese mismo instante.

¿Por qué una sola factura genera varios abonos?

Porque cada transferencia paga su propia comisión, calculada sobre lo que trajo y cobrada al confirmarse.

El saldo se mueve, por tanto, varias veces a lo largo de la vida de una factura. Tres transferencias son tres abonos y tres comisiones, cada una calculada sobre el importe que tenía delante cuando se liquidó. La tarifa que la liquida es la que quedó fijada a esa factura el día en que se creó, pase lo que pase después con la lista de precios.

Así que una sola llegada ya son tres números: lo que entró, lo que se llevó la comisión y lo que se quedó el comercio. El redondeo va siempre hacia el mismo lado. La comisión se trunca a la unidad más pequeña del token y el resto es del comercio, de modo que la tarifa real queda en la publicada o por debajo con cualquier importe; una transferencia tan pequeña que su comisión se redondea a cero no paga ninguna.

Para quien lee su propio extracto, esta es la parte que sorprende. Los abonos no van uno a uno con las facturas: van con las transferencias. Y quién carga con la comisión de cada una es otro ajuste distinto.

¿Qué ocurre cuando el importe no coincide?

El abono sigue al dinero y la factura sigue su propia regla, y las dos respuestas no siempre coinciden.

Si el pago viene de más, el excedente se abona entero. No se retiene nada ni se devuelve nada por su cuenta: la factura cierra como pagada y el evento que sale es invoice.paid_over en lugar de invoice.paid, así que tu sistema de pedidos distingue los dos casos sin hacer cuentas con importes.

Si viene de menos, se topa con la tolerancia del proyecto: un deslizador entre el 0 % y el 2 %, que se mueve de décima en décima y que un proyecto nuevo estrena en el 0,1 %. Lo que falte por debajo de esa tolerancia cierra la factura igual y el comercio se queda con lo que llegó, porque nadie inventa el complemento. Bájalo a cero y vuelve la coincidencia exacta.

Por debajo del umbral se separan los dos tipos de factura. La de un solo pago queda marcada como pago insuficiente. La de varios pagos puede seguir abierta mientras quien paga manda el resto, y esa es justo la posición que una cifra única no sabe expresar: dinero real abonado, pedido sin terminar.

¿Adónde va el dinero que no paga ninguna factura?

Al saldo del comercio, con la comisión de procesamiento descontada y el motivo anotado al lado.

A las direcciones de factura les llegan transferencias en momentos incómodos. Una hora después de cerrarse la ventana de pago. Contra una factura pagada o cancelada esa misma mañana. En USDC cuando la factura iba en USDT, o a una dirección que no tiene ninguna factura detrás. En todos esos casos el dinero se abona al comercio.

Lo que no se mueve es la factura. No queda marcada como pagada y no sale ningún webhook, porque un abono de este tipo no tiene evento propio. Una integración que solo escucha el flujo de eventos nunca se entera.

Donde sí aparece es en la página de saldos, en un bloque aparte, con el motivo, el importe, la comisión, la factura cuando la había, y la dirección de origen y el hash de la transacción cuando se conocen. Si no, el origen figura como desconocido. El correo, la campana del panel y un contacto de Telegram enlazado llevan el mismo aviso. Devolver algo de eso es una decisión comercial tuya, porque una devolución es una transferencia corriente que alguien tiene que enviar.

¿Qué anota un libro de partida doble?

Movimientos, y las dos cuentas que toca cada uno.

Un sistema de una sola entrada guarda un importe y lo edita. Uno de partida doble guarda el cambio: de dónde salió el valor, adónde llegó, en una transacción que tiene que cuadrar antes de poder confirmarse. El saldo deja de ser un campo que alguien sobrescribe y pasa a ser una posición que se deduce del histórico. Equipos de pagos muy lejos de las cripto se apoyan en esa misma propiedad, y el diario de ingeniería de Modern Treasury lo dice sin rodeos: un libro se levanta sobre «un registro inmutable de solo anexado», donde «se conservan todos los cambios y cualquier estado anterior se puede reconstruir».

En Paymos el saldo de cada comercio es una cuenta aparte dentro de ese libro, por activo. Las transacciones que se escriben contra esas cuentas son inmutables, llevan al menos dos lados y cuadran por token: una anotación descuadrada se rechaza, no se guarda para arreglarla luego.

¿Por qué un retiro queda retenido antes de salir?

Porque entre la petición y la transacción el dinero ni se puede gastar ni se ha ido.

Pedir un retiro saca de disponible el importe más la comisión de red que costará esa ruta, y deja las dos cosas retenidas. Por eso la página de saldos separa las dos cifras, y por eso solo la disponible financia el siguiente retiro. Aquí no hay reserva ni reserva rotativa: lo retenido es dinero tuyo que todavía no ha salido.

Si el retiro termina sin que la transacción salga, fallido o cancelado, el dinero vuelve a disponible sin descontar nada, ni siquiera la comisión de red que se había apartado. Un retiro que no salió no cuesta nada. Cancelar solo funciona en los primeros instantes, antes de que empiece a ejecutarse; después la petición se rechaza.

Un retiro publica siete estados y tres de ellos son finales. Cada payload trae is_final, así que nadie tiene que mantener a mano una lista de nombres. Hay un estado no final que conviene reconocer a la primera: el retiro que la red todavía no ha confirmado, con su importe aún retenido debajo.

¿Quién asume la pérdida cuando la cadena se reorganiza?

La plataforma.

La profundidad de confirmación se fija por red y por importe, una decisión deliberada frente a esperar a la finalidad absoluta, y deja una ventana estrecha: una transferencia ya abonada todavía puede quedar huérfana si la cadena se reorganiza. Cuando ocurre, el abono del comercio se queda donde está y el agujero se anota contra las cuentas de la plataforma.

El apunte es lo interesante aquí. Quien lleva los dos lados de cada anotación puede nombrar la cuenta que se comió el golpe; quien lleva una sola cifra por comercio tiene un único sitio de donde sacarlo, y el comercio está de pie encima. Qué le hace una reorganización a un pedido ya entregado explica la mecánica, y por qué la espera cambia con la red, de dónde sale esa ventana.

¿Se puede cuadrar el saldo solo con los webhooks?

Solos no. Un flujo de eventos describe transiciones, y una transición no es un registro de dinero.

Sus 16 tipos cubren facturas, retiros y depósitos de canales de pago, y cada uno anuncia que un recurso cambió de estado. Eso hace del flujo una forma fiable de enterarte pronto de que algo pasó; el contrato de entrega explica hasta dónde insiste.

Que esté completo es otra pregunta. Un abono que no paga ninguna factura no produce ningún evento, y un retiro fallido dispara un webhook pero no manda correo ni aviso en el panel. Suma webhooks para obtener un saldo y los dos casos se te van en silencio.

El feed que publica los depósitos de canales de pago parte de lo contrario. Va en orden detrás de un cursor que siempre avanza, así que quien guarda su posición no se salta un pago liquidado, y una página sin nada dentro también devuelve cursor, en lugar de marcar un final. Ese cursor caduca a las 24 horas de emitirse: lee el feed al menos una vez al día. Trata el evento como un aviso para ir a leer, y deja que tu contabilidad se crea el feed y el saldo.

¿Qué conviene anotar en tu contabilidad?

Transferencias, con la factura como atributo y no como clave.

Ese único cambio absorbe casi todo lo anterior. Tres abonos contra una factura dejan de ser una anomalía, y un abono sin factura tiene dónde vivir en vez de acabar en un hilo de soporte. Una retención revertida se lee como un apunte que deshace otro y que puedes mirar, en lugar de una resta que hay que reconstruir.

Dos costumbres menores van detrás. Ramifica por is_final allí donde importe el estado de un retiro. Y guarda los saldos por activo, que es como se llevan aquí: un único saldo de USDT cubre todas las redes por las que llegó ese USDT, y por cuál sale se decide luego, al crear el retiro.

Nada de esto pide un libro mayor propio, y casi ningún comercio necesita montarlo. Lo que pide es una decisión tomada antes del primer cierre de mes: qué fila de tu contabilidad representa el dinero. Si la respuesta es la factura, el primer abono raro te costará una tarde.