Un pago insuficiente deja un saldo pendiente; un pago en exceso genera un importe sobrante que hay que resolver. Ninguno justifica improvisar un reembolso ni solicitar otro pago completo. Primero verifica lo recibido, vincúlalo a la compra y decide por separado si entregar el pedido y cómo saldar la diferencia.
Esta guía presupone que el activo, la red y el destino son correctos. Si no coinciden, consulta la guía de actuación ante pagos en la red equivocada. Aquí, el problema es el importe, el momento de recepción o la asignación de un pago cuyos demás datos sí coinciden.
Los controles siguientes son recomendaciones operativas y técnicas para comercios, no una lista de funciones automáticas de Yolfi. Los ejemplos son ilustrativos y no corresponden a incidentes de clientes.
Determina el importe antes de decidir la solución
Conserva la solicitud original: referencia del pedido, cantidad solicitada del token, red, destino, base de la cotización y cualquier regla de caducidad. Compárala con los abonos verificados de forma independiente que cumplan tu política de confirmaciones, no con una captura de la billetera del cliente ni con una estimación de su saldo.
Mantén separadas tres cifras:
- Importe solicitado: lo que exigían las instrucciones de pago.
- Abonos verificados: transferencias coincidentes que se han recibido realmente y pueden asignarse.
- Saldo sin resolver: lo que falta o sobra tras las asignaciones, los créditos y los reembolsos anteriores.
No restes tus propios gastos de transferencia posteriores del importe pagado por el cliente. Mantén las comisiones del proveedor y los ajustes contables separados de las pruebas de lo recibido.
Un retiro desde una plataforma de intercambio puede entregar menos de lo que pretendía el cliente si el servicio descuenta una comisión. Comprueba el abono en lugar de hacer suposiciones. En cambio, una transferencia estándar de USDC o USDT en Ethereum no paga el gas de Ethereum descontando USDC o USDT: las comisiones de gas de Ethereum se pagan en ETH. No aconsejes al cliente añadir una cantidad estimada de monedas estables para el gas.
En la implementación, compara unidades mínimas enteras exactas o valores decimales exactos usando la precisión verificada del activo. Evita las comparaciones con números binarios de coma flotante y nunca elimines una diferencia por redondeo solo porque la página de pago muestre menos decimales.
Tabla de decisiones para discrepancias de importe
Úsala como plantilla de política interna. Son clasificaciones de negocio, no estados de la API de Yolfi.
| Situación verificada | Decisión de entrega | Acción para resolver el importe | Control antes del cierre |
|---|---|---|---|
| Se recibe el importe completo dentro del plazo aplicable | Entregar una sola vez tras cumplir los requisitos de confirmación | Asignar el abono al pedido | Comprobar asignaciones y entregas anteriores |
| Se recibe menos de lo solicitado | Retener la entrega salvo que se autorice una concesión | Aprobar una solicitud trazable del saldo pendiente, una concesión o un reembolso | Registrar el saldo restante y la persona responsable |
| Se recibe más de lo solicitado | Entregar una sola vez, únicamente si se cumplen las reglas de aceptación del pago | Revisar el exceso para reembolsarlo o conceder un crédito acordado | Separar lo asignado al pedido del exceso |
| Varias transferencias alcanzan el total exigido | Retener la entrega hasta verificar que se pueden sumar y que está permitido | Asignar cada transferencia admisible una sola vez | No dar por hecho que el proveedor agrupa los pagos |
| El importe completo llega después de la caducidad | Revisar los plazos, la cotización y la disponibilidad del pedido | Aceptar según la política o acordar otra solución | Comprobar las solicitudes de sustitución vinculadas |
| Tanto la solicitud original como la de sustitución reciben fondos | Nunca entregar dos veces | Conciliar ambos abonos y resolver el excedente | Bloquear las acciones duplicadas sobre el pedido |
Asigna a cada incidencia una persona responsable y un plazo para la próxima actualización. Un abono no debe quedar sin asignar porque atención al cliente y finanzas den por hecho que el otro equipo se está ocupando.
Pagos insuficientes: solicita solo el siguiente paso aprobado
Supongamos que una solicitud exige 100 USDC, pero el abono verificado es de 98 USDC. Faltan 2 USDC. Conserva el registro del abono original; no lo sustituyas silenciosamente por uno nuevo que indique 100.
Elige una solución documentada:
- Cobrar el saldo pendiente. Verifica que tu integración pueda conciliar abonos separados. Emite una solicitud trazable por el importe pendiente, vinculada al mismo pedido y con instrucciones de pago vigentes.
- Aceptar una concesión. Una persona autorizada registra el importe condonado y su tratamiento contable. No afirmes que una concesión del comercio cambia las reglas con las que el proveedor reconoce los pagos.
- Devolver el abono parcial. Acuerda las condiciones y el destino del reembolso antes de ejecutar el pago de salida por separado.
Las preguntas frecuentes de Yolfi sobre pagos parciales indican que los pagos incompletos no se confirman y piden a los clientes que contacten con el comercio. Condicionan los pagos complementarios a la misma dirección a que el sistema del comercio los admita. Por tanto, no prometas que enviar la diferencia completará automáticamente la solicitud original de Yolfi.
Si no se ha verificado el tratamiento de pagos divididos, deriva el caso a la persona responsable antes de indicar al cliente que envíe más. Pedir otro pago completo mientras se retiene el primer abono parcial provoca un exceso de pago previsible.
Define cualquier política sobre pequeñas diferencias antes de que se produzcan incidentes. Por ejemplo, establece un límite de autorización, las compras admisibles y un motivo que quede registrado para auditoría. No existe un porcentaje de tolerancia universal: BTCPay Server documenta su propia tolerancia configurable para pagos insuficientes, pero eso no demuestra que Yolfi ofrezca el mismo ajuste.
Pagos en exceso: separa la venta del sobrante
Un cliente debe 100 USDT y envía 105 USDT. Si el pago cumple los demás requisitos de aceptación, asigna 100 USDT a la compra y registra 5 USDT como exceso sin resolver. No trates la diferencia como ingresos adicionales ni como derecho a más productos por defecto.
Pide al cliente que elija una solución disponible y conforme a la política: un reembolso o un crédito acordado expresamente. Explica las comisiones aplicables antes de llegar a un acuerdo y comprueba las obligaciones locales de consumo y contabilidad. Que el importe sea pequeño no autoriza a retener fondos en silencio.
Distingue también una transferencia por un importe excesivo de un pago duplicado. Dos transferencias de 100 USDT para una compra de 100 USDT son dos abonos, no uno corregido. Conserva ambos registros de transacción, entrega una sola vez y revisa por separado los 100 USDT adicionales.
Pagos tardíos: la caducidad no resuelve qué hacer con los fondos recibidos
Registra por separado el plazo de la solicitud de pago, el momento de detección de la transferencia y el de confirmación. Un pago detectado antes de la caducidad pero confirmado después no es lo mismo que una transferencia recibida por primera vez una vez caducada la cotización. Aplica la regla documentada; no inventes un plazo de gracia universal.
Para los abonos tardíos, revisa:
- si el precio original sigue siendo válido;
- si siguen disponibles las existencias, la capacidad o el acceso;
- si otra solicitud ya pagó el mismo pedido;
- si ya se aprobó un reembolso, un crédito o una concesión.
Una solicitud de 100 USDC denominada en el propio token y una solicitud denominada en moneda fiduciaria y convertida a cripto no tienen por qué seguir la misma política de pagos tardíos. Conserva la cotización original y comunica cualquier cotización nueva en lugar de modificar el precio del registro histórico.
Si hace falta una solicitud de sustitución, vincúlala al pedido original en tus registros y advierte al cliente que no pague ambas. Sigue supervisando el intento anterior. Cerrar una consulta de atención al cliente no impide que una transferencia ya enviada se confirme más tarde.
Reembolsa de forma segura sin provocar un segundo incidente
Un reembolso es un pago de salida independiente, no una modificación de la transferencia entrante. La explicación del servicio sin custodia de Yolfi indica que los pagos van directamente a la billetera configurada por el comercio. No des por hecho que Yolfi mantiene un saldo reembolsable ni que devuelve automáticamente los excesos.
Antes de autorizar un reembolso:
- Confirma el abono original, la reclamación del cliente y el importe que aún puede reembolsarse.
- Autentica al solicitante a través del canal habitual del cliente.
- Obtén y verifica el activo, la red y el destino previstos para el reembolso. No devuelvas los fondos a ciegas al remitente de la transacción: puede pertenecer a una plataforma de intercambio o a otro intermediario.
- Acuerda el reembolso bruto, el tratamiento de las comisiones y el importe neto previsto, con sujeción a las obligaciones aplicables.
- Exige aprobación conforme a tu política de seguridad de billeteras; registra el motivo y quién lo aprueba.
- Registra la referencia de la transacción de salida y verifica su resultado antes de dar el reembolso por completado.
Nunca solicites una frase de recuperación ni una clave privada. Si se agota el tiempo de espera al enviar un reembolso, investiga el estado de la transacción antes de volver a enviarlo. Una respuesta incierta no demuestra que el pago no se haya difundido a la red.
Haz que cada resolución sea idempotente
La idempotencia significa que los reintentos no pueden repetir una acción de negocio. La guía de Stripe sobre webhooks documenta los eventos duplicados y la ausencia de garantía de orden en Stripe; es una referencia técnica útil, no una descripción de las garantías de entrega de Yolfi.
Para tu propia integración:
- Autentica las notificaciones con el procedimiento de verificación documentado por el proveedor.
- Guarda los eventos entrantes de forma duradera y elimina duplicados mediante los identificadores documentados.
- Identifica cada abono por su red y referencia de transacción, además de un índice de transferencia o evento cuando una transacción contenga varias transferencias pertinentes.
- Impón una sola asignación por abono y una sola entrega por pedido mediante restricciones de base de datos o controles transaccionales equivalentes.
- Reserva una operación de reembolso aprobada antes de enviarla para impedir que procesos concurrentes la ejecuten dos veces.
Un webhook repetido no es otro pago. Una segunda transferencia válida sí es otro abono, pero tampoco autoriza un segundo envío del pedido. Antes del cierre, concilia las incidencias tanto con las pruebas de la billetera como con los registros comerciales.
Preguntas frecuentes
¿Debemos aceptar un pago al que le falta una cantidad mínima?
Solo si lo permite una política aprobada del comercio. Registra la concesión por separado y verifica cómo se reconoce el pago; no des por hecho que existe una tolerancia automática.
¿Un pago en exceso debe activar un reembolso automático?
No sin verificar la titularidad, el destino, el importe y los controles contra duplicados. Pon el exceso en revisión, salvo que un proceso probado y autorizado lo gestione de forma segura.
¿Pueden dos transferencias parciales pagar un pedido?
Tus registros pueden asignar varios abonos si tu política lo permite. Debes verificar por separado si el proveedor de pagos los reconoce conjuntamente.
Conclusión: salda el importe pendiente, no cierres solo la consulta
Empieza con un enlace de pago de Yolfi claro y mantén un registro de incidencias del comercio junto al registro del pago. Cierra un caso solo cuando la asignación al pedido, la decisión de entrega, el saldo restante y cualquier reembolso o crédito cuadren entre sí. Así evitarás que una pequeña discrepancia de importe se convierta en un segundo pago, una entrega duplicada o un reembolso inseguro.
