Factura cripto pagada de menos: ¿qué pasa si el cliente envía de menos o de más?

Una factura cripto pagada de menos casi siempre empieza con un mensaje de WhatsApp. El cliente jura que pagó 180 USDT y tu panel dice 179,30. Las dos cifras son correctas: los 0,70 que faltan son la comisión de retiro que el exchange del cliente descontó antes de enviar el dinero.

Un pago también puede llegar largo, por un envío doble o por un complemento redondeado hacia arriba. Cada caso tiene una respuesta correcta, y los más comunes se evitan con una línea de texto en el checkout. Los estados que siguen vienen de la API pública de Payzum, pero la misma lógica sirve para cualquier procesador que emita una factura por pago.

Payzum es un procesador de pagos cripto sin custodia y enfocado en stablecoins: los pagos se liquidan directo en wallets que controla el comercio.

Por qué un pago en stablecoins llega corto o largo

Con tarjeta, el comercio cobra. Pide 180 y el banco emisor aprueba exactamente 180 o rechaza. Con cripto, el cliente paga. Él o su exchange deciden cuánto sale de la cuenta, y la cadena registra lo que llegue. Casi todos los descuadres nacen de esa diferencia, por una de cuatro causas.

El exchange descuenta su comisión del monto enviado

La guía de Binance para retirar cripto, actualizada el 18 de septiembre de 2026, ofrece dos formas de indicar el monto. Con «Receive amount» (monto a recibir), la comisión de red se suma aparte y el destinatario recibe la cifra escrita. Con «Withdrawal amount» (monto de retiro), la comisión se descuenta y el destinatario recibe lo que sobra. Un cliente que escribe 180 en el segundo modo te manda 180 menos la comisión.

Las comisiones son chicas, pero nunca cero. La tabla de comisiones de retiro de Binance, consultada el 11 de noviembre de 2026, marca 0,7 USDT por USDT en Solana y 0,6 USDT en Ethereum. Para USDC: 0,3 en Solana, 0,2 en Base y 1 en Ethereum. El centro de ayuda de Coinbase indica que cobra una comisión según su propia estimación del costo de red cuando el cliente envía a una dirección externa. Cualquiera de esas comisiones deja tu factura abierta.

El cliente escribe mal la cifra

Un cero de menos convierte 1.200 en 120. Quien copia el monto desde un correo puede redondear 180,004 a 180. Las wallets que escanean el QR del checkout completan el monto solas, y ahí este error casi desaparece. Las pantallas de retiro de los exchanges, en cambio, suelen pedir la cifra a mano.

El token viaja por otra red

Una misma stablecoin vive en muchas cadenas. Circle informa que USDC tiene soporte nativo en 38 redes blockchain, dato consultado el 11 de noviembre de 2026. Los datos de transparencia de Tether del mismo día muestran unos 92.000 millones de USDT emitidos en Tron y unos 80.000 millones en Ethereum. Un cliente que tiene sus USDT en Tron puede no tener saldo en la red que pide tu factura, y el exchange le deja elegir cualquiera. La guía de Binance advierte que los fondos enviados por la red equivocada podrían perderse.

El cliente paga dos veces

Un doble toque en la wallet, o un pago completo enviado después de uno parcial, deja la factura larga. Se arregla más fácil que un pago corto, porque muchas veces el cliente se da cuenta primero.

Lo que cuesta un descuadre cuando nadie lo ve

Los montos suelen ser chicos. Lo que cuesta plata es manejar mal el pedido, de alguna de estas formas.

• Despachar con un pago parcial. Una tienda que marca el pedido como pagado con cualquier transferencia entrante algún día entregará 1.200 de mercadería contra 120.
• Dejar vencer un pedido casi completo. Faltar 0,70 sobre 180 es un 0,39%. Si la factura vence con 179,30 adentro, te quedas sin venta y además debes devolver 179,30.
• Quedarse callado con un excedente. El cliente ve el monto extra en su historial del exchange. Un mensaje sin respuesta termina en una reseña pública, y la diferencia también rompe tu conciliación de fin de mes.
• El tiempo de soporte. Cada caso es una conversación con el cliente, a veces con husos horarios distintos, mientras el pedido espera.

Por qué ningún procesador puede cobrar lo que falta

En una red de tarjetas, el comercio fija la cifra al autorizar y el cliente nunca la escribe. Una transferencia bancaria la envía el cliente, igual que cripto, y llega corta por motivos parecidos: un dedo que se equivoca o una comisión bancaria en el camino. Una transferencia en stablecoins sigue el mismo modelo. Payzum no puede sacar los 0,70 que faltan de la wallet del cliente, ni ningún otro procesador, porque solo quien tiene la llave puede firmar una transferencia.

Lo que sí puede hacer un procesador es facilitar el monto correcto. EIP-681, un estándar de Ethereum en estado Final creado el 1 de agosto de 2017, define una URL de solicitud de pago que lleva el token, el destinatario y el monto. Puesta en un QR, la wallet que la escanea completa los tres datos. Solana Pay y el BIP-21 de Bitcoin hacen lo mismo en sus cadenas. El punto débil es la cuenta del exchange, donde el cliente pega la dirección y escribe la cifra.

Cómo sigue Payzum una factura cripto pagada de menos

Cada pago en Payzum corre sobre su propia factura, con un monto fijo, una dirección de depósito y un vencimiento. Según la documentación del checkout alojado, la página de pago muestra la cadena, el monto exacto, una cuenta regresiva y un estado en vivo que se actualiza con cada confirmación. Después de un pago parcial, la página y su QR piden solo lo que falta.

La API para comercios reporta cinco estados: waiting, partially_paid, finished, expired y failed. La referencia del ciclo de vida de la factura agrega los detalles que importan cuando el monto no cuadra.

• Un pago corto pasa la factura a partially_paid. Queda abierta hasta que un pago adicional la complete o hasta que venza el plazo.
• Hoy no se dispara ningún webhook con un pago parcial. La pantalla del comprador se actualiza, pero tu backend tiene que consultar GET /v1/payment/:id, o tú revisas el panel. El webhook de pago parcial está en la hoja de ruta.
• Un excedente por encima de la tolerancia del comercio, un 5% por defecto, queda como overpaid en la página del comprador. La API y el webhook firmado igual dicen finished.
• Tres avisos informativos llevan el estado actual de la factura sin cambiarlo: wrong_token_received, suspicious_token_received y late_deposit_received.

O sea, el control del sobrepago vive en tu propio handler. Una versión mínima, después de verificar la firma, se ve así:

if (p.payment_status === 'finished') {
  fulfil(p.order_id);
  const excess = Number(p.actually_paid) - Number(p.pay_amount);
  if (excess > 0) queueExcessReturn(p.order_id, excess);
}

El dinero nunca espera en un saldo de Payzum. Los fondos se liquidan en tu wallet y Payzum se queda con el 0,5% de cada venta procesada, descontado de lo que recibes. En una venta de 180 USDT son 0,90 USDT, y te quedan 179,10. El gas de red va aparte y cuesta centavos en Solana, Base o Polygon. Los detalles están en la página de precios.

En cadenas EVM y en Solana, la página alojada también ofrece un botón «Pay with wallet». Le pide a la wallet del cliente que firme exactamente la transferencia que la factura espera, así que el monto, el token y la red no se pueden desviar.

Un molino de 180 USDT que llegó con 0,70 de menos, minuto a minuto

Una tienda online de Ciudad de México vende molinos de café con precio en USDT. Una clienta compra uno por 180 USDT en Solana y paga desde Binance.

El mínimo de retiro de las 10:15 es fácil de pasar por alto. La tabla de Binance, consultada el 11 de noviembre de 2026, fija en 5 USDT el retiro más chico de USDT en Solana, así que una clienta a la que le faltan 0,70 y paga desde ese exchange no puede mandar 0,70. O paga de más, o completa desde una wallet propia. Tu proceso tiene que contemplar las dos salidas.

Los 4,30 son de la clienta, y la tienda los devuelve completos con una transferencia nueva. La guía sobre cómo reembolsar un pago cripto explica cómo confirmar la dirección y qué registro guardar. Una frase sobre la comisión del exchange en el checkout le habría ahorrado a la tienda esos correos.

Qué hacer con un pago corto, paso a paso

1. Detéctalo. Consulta GET /v1/payment/{order_id} cada pocos minutos para los pedidos abiertos, o filtra en el panel. No esperes un webhook.
2. Dile al cliente el saldo exacto, el token y la red, con el link de la factura. La página ya muestra solo lo que falta.
3. Retén el pedido. Nada sale con partially_paid, sea cual sea la diferencia.
4. Cuando el estado pase a finished, compara actually_paid con pay_amount. Devuelve o acredita el excedente según tu política escrita.
5. Si la factura vence con fondos adentro, no entregas nada. Devuelve lo recibido con un pago nuevo a una dirección que el cliente confirme.

De menos, de más, tarde o con otro token: la tabla de decisión

La página del comprador y tu API nombran distinto el mismo estado, así que la tabla da los dos, con la respuesta que corresponde a cada caso.

Las dos últimas filas son las únicas donde el resultado no depende de ti. Junta el hash, la red y el monto antes de escribir a soporte, y dile al cliente que lo estás revisando en vez de darle una fecha.

El texto del checkout que evita la mayoría de los pagos cortos

La solución más barata llega antes de que el cliente pague. La llamada que crea la factura en Payzum acepta un order_description de hasta 2.000 caracteres que aparece en el checkout. Una versión para adaptar:

Envía exactamente 180,00 USDT por la red Solana. ¿Pagas desde un exchange? Elige la opción que fija el monto a recibir, o suma la comisión de retiro, para que lleguen 180,00. Usa solo Solana: una transferencia por otra red no llegará a este pedido. Si envías un poco menos, esta página te muestra lo que falta; págalo antes de que termine el tiempo. Devolvemos cualquier excedente a una dirección que nos confirmes por correo.

Cada frase te ahorra una conversación de soporte:

• El monto y la red van primero y juntos.
• La comisión del exchange aparece con el nombre que el cliente ve en pantalla. En Binance la opción se llama «Receive amount».
• La regla del faltante le dice al cliente qué hacer sin escribirte.
• La regla del excedente evita que un cliente asustado abra un reclamo con su exchange.

Dos ajustes ayudan tanto como el texto. Limita los tokens aceptados a las redes que tus clientes de verdad usan, porque menos opciones significan menos envíos por la red equivocada. Y fija precios bien por encima de los retiros mínimos de los exchanges, para que nadie tenga que pagar de más para cerrar una diferencia chica.

Cuatro negocios y el descuadre que le toca a cada uno

Los mismos estados se viven muy distinto según lo que vendas.

• Un distribuidor de Bogotá le factura 4.800 USDC en Ethereum a una cadena de tiendas. El área de finanzas del cliente retira desde Binance en modo «Withdrawal amount» y llegan 4.799 tras la comisión de 1 USDC. La solución es una línea en las condiciones de pago: enviar en modo «Receive amount». El distribuidor la suma a cada factura, y así la siguiente puede cerrarse con la primera transferencia. Para el lado documental, mira cómo enviar una factura en cripto.
• Un estudio de diseño de Buenos Aires factura 1.200 USDC en Base y el cliente manda 120. La factura queda en partially_paid con 1.080 pendientes. El estudio retiene los archivos finales y reenvía el link. El cliente escanea el QR desde una wallet propia, el monto se completa solo y la factura se cierra.
• Una creadora de cursos de Lima vende un programa de 89 USDC en Polygon. Un alumno toca «enviar» dos veces y llegan 178. El excedente es del 100%, así que la página del comprador muestra overpaid mientras el webhook dice finished. El handler marca 89 USDC y la creadora los devuelve el mismo día.
• Una cafetería usa el punto de venta de Payzum, con un QR nuevo por cada venta. Un cliente paga desde la app de un exchange en Solana y el pago llega 0,70 USDT corto por la comisión. La cajera ve que la venta no se completó, pide el resto sobre la misma venta y entrega el pedido cuando aparece como pagado.

Tarjeta, transferencia bancaria y factura cripto: quién puede equivocar el monto

Frente a la tarjeta, una factura cripto pierde el monto que fija el comercio y gana pagos finales, sin ventana de contracargos. El texto del checkout y los controles de estado cubren lo que pierdes.

Las dudas de los comercios sobre pagos de menos y de más

¿Puedo aceptar faltantes chicos de forma automática?

No con el flujo de estados. La documentación de Payzum describe una tolerancia del 5% solo para el sobrepago. Cualquier monto por debajo del total deja la factura en partially_paid. Evitar el faltante en el checkout ahorra más trabajo que resolverlo después.

¿Tengo que devolver un excedente chico?

Es plata del cliente, así que devuélvelo u ofrécelo como crédito, y deja dicho cuál de las dos cosas haces antes de la venta. Un umbral claro, por ejemplo devolver todo lo que pase de 1 USDT, saca la decisión de cada conversación.

¿No se van a confundir los clientes?

Casi toda la confusión nace en la pantalla del exchange. Quien escanea el QR desde una wallet recibe el monto ya cargado. Quien paga desde un exchange necesita una frase sobre la comisión, y la plantilla de arriba se la da.

Fuentes consultadas el 11 nov 2026

• Binance Support: cómo retirar cripto de Binance (actualizado el 18 sep 2026)
• Binance: comisiones y mínimos de retiro por red
• Tether: transparencia, USDT emitidos por cadena
• Circle: USDC multicadena
• EIP-681: formato de URL para solicitudes de transacción
• Documentación de Payzum: ciclo de vida de la factura