Cómo gestionar facturas cripto pagadas de menos o de más

Una factura pagada de menos no debe activar la entrega automática; una pagada de más tampoco debe generar un reembolso automático. Primero confirma red, contrato genuino, destinatario, estado e importe. Después aplica una política escrita que registre la diferencia y produzca una resolución inequívoca.

En GramPayBot el importe esperado es exacto. Una transferencia inferior se clasifica como parcial y una superior como overpaid; ninguna se convierte silenciosamente en una factura pagada con normalidad.

Tabla de decisiones

Resultado verificado	Decisión	Siguiente paso
Importe exacto	Puede coincidir tras confirmación	Entregar cuando quede paid
Importe inferior	Pago parcial/insuficiente	Registrar la diferencia y orientar al comprador
Importe superior	Pago excesivo	Decidir aceptación, crédito o devolución
Varias transferencias relacionadas	Caso ambiguo	Verificar cada hash manualmente
Red, token o destinatario erróneo	No paga esta factura	Seguir el flujo de ruta incorrecta

Si la red es incorrecta, sigue la guía de investigación y recuperación de red equivocada. Si la diferencia afecta a una factura vencida o de sustitución, utiliza el flujo para facturas impagadas, tardías y vencidas antes de pedir otro pago.

BTCPay Server separa los estados parcialmente pagado y overpaid de una factura normalmente liquidada. Stripe también registra saldo restante y exceso por separado. No definen tu política, pero muestran por qué una excepción necesita estado propio.

Causas habituales de pago insuficiente

• redondear en vez de copiar el importe completo;
• interpretar mal la comisión de una wallet o exchange;
• enviar una prueba y suponer que se sumará automáticamente;
• usar instrucciones antiguas o una factura vencida;
• procesar mal los decimales del token;
• varias personas intentando pagar el mismo pedido;
• retener parte por una disputa.

Las comisiones de retiro varían por proveedor y activo. Binance, por ejemplo, indica que son dinámicas y se muestran en la página de retirada. No existe una regla universal según la cual la red siempre descuente la comisión del importe recibido. El comprador debe comprobar el resultado final para el destinatario.

Causas habituales de pago excesivo

Puede copiarse el precio fiat como cantidad de token, sumarse la comisión cuando se cobra por separado, pagarse dos veces, enviarse el total después de una prueba o cometerse un error de unidades.

Aunque la interfaz muestra decimales, la cadena representa importes en unidades mínimas enteras. El ejemplo oficial de Circle muestra USDC con seis decimales. La integración debe convertir unidades de forma determinista y no comparar aproximaciones de coma flotante.

Verifica la transferencia antes de resolver

1. Abre el hash en el explorer de la red de la factura.
2. Confirma éxito y nivel de confirmación.
3. Comprueba contrato o mint, no solo el símbolo.
4. Compara la dirección completa del destinatario.
5. Lee el importe del evento de transferencia o balance change.
6. Compáralo con todos los dígitos del checkout.
7. Comprueba si otra operación está asignada al pedido.
8. Compara la hora de bloque con el vencimiento.

Si el contrato es incorrecto, no es solo una diferencia de importe: es otro activo. Usa la guía de verificación de contratos USDT y USDC.

Después de verificar, vincula cada hash aceptado exactamente con una factura y un pedido. La guía para asociar pagos con pedidos explica cómo conservar esa relación sin depender de capturas ni usernames de chat.

Matching exacto de GramPayBot

GramPayBot define red, token, destinatario e importe antes del pago. El importe actual del checkout utiliza como máximo cuatro decimales y puede incluir un sufijo identificador. Si muestra 180.0134 USDT, hay que enviar todo el número, no 180 USDT redondeados. USDT o USDC puede usar seis decimales de unidad base on-chain; eso no significa que GramPayBot muestre un sufijo de factura con seis cifras.

Una transferencia confirmada exacta puede pagar; una inferior es partial; una superior es overpaid; varias candidatas o una operación reutilizada no forman una coincidencia limpia. El matcher normal no suma una segunda transferencia arbitraria como «complemento». Pide al comprador que no vuelva a enviar hasta recibir una solución concreta.

Flujo para pago insuficiente

1. Calcula la diferencia verificada

Calcula en unidades del token:

diferencia = importe exacto de la factura − importe recibido verificado

2. Mantén la entrega en espera

No marques el pedido como pagado solo porque haya llegado la mayor parte. Así evitas decisiones distintas para casos equivalentes.

3. Elige una resolución escrita

Elige una opción:

• aceptar manualmente la diferencia como descuento o pérdida;
• crear una factura nueva y separada por el saldo;
• cancelar y reembolsar el importe confirmado;
• escalar a soporte o compliance.

Si cobras el saldo, vincula la nueva factura al pago original. No prometas que la antigua sumará automáticamente ambas transferencias.

4. Comunica el resultado al comprador

Indica el importe recibido, la diferencia, la decisión y la referencia de la nueva factura o del reembolso.

Flujo para pago excesivo

1. Descarta un duplicado o una transferencia ajena

Descarta primero un duplicado o una operación de otro pedido.

2. Separa el importe de la factura del exceso

Registra:

exceso = importe recibido verificado − importe exacto de la factura

No cambies el importe original retroactivamente.

3. Aplica una política

Según tus condiciones, devuelve el exceso, conviértelo en crédito acordado, acéptalo como propina/compra adicional o devuelve todo y vuelve a facturar.

La documentación de pagos parciales de Stripe ofrece un ejemplo no cripto de por qué saldos y excesos necesitan reglas formales.

4. Verifica por separado la dirección de reembolso

No reembolses automáticamente al remitente on-chain. Una exchange puede usar una wallet compartida. Autentica al cliente mediante el pedido, confirma una dirección de devolución en la misma red, explica las comisiones y registra el hash nuevo. El reembolso es otra transferencia, no una reversión.

Política que conviene definir antes

• si existe tolerancia de pago insuficiente y cómo se calcula;
• si se permiten facturas de saldo;
• mínimo económico de reembolso tras comisiones;
• soporte de crédito del cliente;
• responsables de aceptación manual y devoluciones;
• tratamiento de duplicados;
• retención del registro de excepciones.

Si existe tolerancia, aplícala de forma coherente y no la ocultes dentro del matching exacto si la integración no la soporta.

Instrucciones preventivas para el comprador

Abre la factura actual, elige token y red exactos, copia todos los decimales, comprueba si la exchange reduce el importe del destinatario, envía una sola vez y guarda el hash. Si ya hiciste una prueba o venció la factura, detente y contacta al comercio.

Consulta cómo pagar una factura con USDT o USDC.

Plantilla de registro de la excepción

Para cada pago insuficiente o excesivo, conserva:

• IDs de factura y pedido;
• red, token, destinatario e importe exacto esperados;
• todos los hashes relacionados;
• importe verificado y estado de confirmación por hash;
• diferencia o exceso en unidades del token;
• vencimiento y horas de bloque;
• método de autenticación del cliente;
• resolución, aprobador y marcas temporales;
• referencia de factura de saldo, crédito o reembolso.

Este registro evita contar una transferencia dos veces y permite que otra persona reproduzca la decisión.

Preguntas frecuentes

¿Un segundo pago completa automáticamente una factura parcial?

No lo supongas. El matcher normal espera una transferencia exacta y no suma pagos parciales arbitrarios. Espera una nueva factura de saldo o instrucciones claras.

¿Puedo redondear el importe del checkout?

No. Envía todos los dígitos; el sufijo puede identificar la factura.

¿Una factura pagada de más queda paid automáticamente?

No. Es una excepción para revisión manual.

¿Devuelvo al remitente on-chain?

No automáticamente. Confirma al cliente y una dirección adecuada, sobre todo si el pago llegó desde una exchange.

¿Una transferencia USDT real demuestra que el pedido está pagado?

No por sí sola. La red, el contrato del token, el destinatario, el importe, la ventana de pago y la identidad de la operación deben coincidir con la factura, y la transferencia debe estar confirmada.