Blog
Tres cuencos de cerámica con distinta cantidad de fichas; una mano con pinzas lleva una ficha hacia un sobre.

19 de octubre de 20267 min de lecturaАдминистратор

Pagó de menos, pagó de más, abrió una disputa: ¿quién se queda con la diferencia?

Analizamos el pago insuficiente, la transferencia de más y la devolución después de la liquidación. Quién confirma el hecho, asume la pérdida y ajusta la garantía del trader.

El sobrepago y el pago insuficiente suelen empezar con un error simple: en lugar de 10 000, el cliente transfirió 10 400. Soporte ve un pago completo, el trader ve 400 de más y el comercio espera la liquidación habitual. Si el excedente pasa a ingresos, desaparece de la conciliación o se devuelve a los datos de pago de un interlocutor cualquiera, un pequeño error se convierte en un incidente financiero aparte.

En la resolución P2P hay que responder a tres preguntas a la vez. ¿Qué hecho monetario está probado? ¿Qué acción le corresponde al cliente según las condiciones de la operación? ¿A cargo de quién se ejecuta esa acción? Probar el ingreso no resuelve automáticamente la cuestión de la responsabilidad, y la decisión «devolución aprobada» todavía no confirma que el dinero se haya enviado.

La disputa abre un caso, no reescribe el pasado

El caso recibe su propio número, la orden y los ingresos bancarios vinculados, el importe reclamado, la moneda y el motivo. El operador registra la distribución actual del dinero: qué tiene el trader, qué ya se transfirió al operador y qué recibió el comercio. Por separado se indica qué importe está retenido temporalmente y con qué fundamento. Abrir una disputa no es, por sí mismo, un reconocimiento definitivo de culpa.

Las reglas públicas de los exchanges muestran hasta qué punto los procedimientos dependen del producto. En el FAQ de Bybit, el pago de más y el pago de menos están excluidos de la revisión simplificada Fast-Track. Las condiciones de Binance prevén el uso de la garantía en determinadas situaciones y según la evaluación de responsabilidad. Estos ejemplos no le dan a cualquier procesador el derecho de debitar el depósito ajeno a partir de un solo mensaje en un chat.

En los ejemplos siguientes se asume un modelo contractual de recaudación con participantes admisibles y reglas de devolución definidas. Una operación habitual de 10 000 deja al comercio 9 600, al trader 150 y al operador 250 antes de gastos. Son cifras convencionales. Permiten ver dónde nace una nueva obligación cuando el importe real difiere del esperado.

Pago insuficiente: primero el saldo, después la decisión

Se recibieron 9 600 en lugar de 10 000. Los 400 que faltan no son la comisión del comercio: el cliente debía enviar el importe completo, y la comisión se retiene en el siguiente nivel de liquidación. Si se confunden estos conceptos, la tienda recibirá el estado de pago completo aunque el fondeo de la operación ya tenga un hueco.

El operador registra el ingreso real de 9 600 y la diferencia de 400. Si las reglas permiten un pago complementario, se recibe y se verifica como un registro aparte, y después ambos importes cancelan la obligación del cliente. Si el pago complementario está prohibido o el cliente se niega, se aplica la resolución prevista. No se puede convencer a nadie de enviar dinero desde un tercero para conseguir una cifra final bonita.

Si se cancela, en nuestro ejemplo se le devuelven al cliente los 9 600 efectivamente recibidos. Supongamos que el costo bancario de la devolución es de 20 y que el contrato lo asigna al operador. Entonces el cliente recibe 9 600, el ejecutor gasta 9 620 en la devolución y recibe aparte un reembolso de 20 del operador. La comisión de una operación exitosa no se cobra aquí, según las condiciones del ejemplo. Otro contrato puede repartir los gastos de otra manera, pero eso debe verse antes de mover el dinero.

Si el comercio acepta conscientemente el pago insuficiente y entrega igualmente el producto al cliente, surge una concesión comercial. El registro debe indicar quién otorga el descuento o cubre el importe faltante. Soporte no puede crear esa decisión con un simple cambio de estado, porque altera el dinero de un participante concreto.

Pago de más: el dinero sobrante no aumenta los ingresos

Cuando llegan 10 400, al pedido se imputan 10 000. Los 400 restantes se registran por separado como importe pendiente de resolución. En nuestro escenario, el trader devuelve el excedente verificado al pagador original mediante un procedimiento admisible. Después transfiere al operador los 9 850 habituales, conservando su remuneración de 150, y el operador paga al comercio 9 600.

Supongamos que el costo de la devolución, 20, lo asume otra vez el operador. Tras reembolsarlo al ejecutor, al operador le quedan 230 antes de los demás gastos. El importe se desglosa por completo: 400 devueltos al cliente, 9 600 a la tienda, 150 al trader, 230 al operador y 20 de gastos bancarios suman los 10 400 originales. Esta verificación ayuda a detectar si alguien retuvo por error una comisión sobre el excedente o reembolsó un gasto dos veces.

Devolver dinero a nuevos datos de pago enviados en un mensaje es peligroso: es otro destinatario y quizá otra operación. Hay que confirmar la titularidad del pago original y verificar la ruta de devolución prevista por el banco o el proveedor y los permisos necesarios. Si el canal original no admite devoluciones, el caso se resuelve con el procedimiento establecido. La comodidad del interlocutor no sustituye la verificación del destino del dinero.

Devolución total después del pago al comercio

Supongamos que los 10 000 habituales ya se repartieron: la tienda recibió 9 600, el trader ganó 150 y el operador 250. Ahora se aprueba una devolución total al cliente. El dinero no aparecerá al pulsar un botón: hay que recomponer el fondeo de 10 000 y decidir qué pasa con las comisiones.

Si el acuerdo prevé devolver ambas comisiones, 9 600 se devuelven a cargo del comercio, 150 a cargo del trader y 250 a cargo del operador. Así se obtiene el importe necesario antes de gastos bancarios. Si la remuneración del ejecutor no es reembolsable, otra parte debe cubrir esos 150 según el contrato o una decisión acordada por separado. No se puede prometer al cliente una devolución total y registrar solo el saldo después de las retenciones.

El derecho de cobro frente al comercio y la transferencia real al cliente se llevan por separado. El operador puede financiar la devolución antes de recibir la compensación de la tienda, pero entonces surge su derecho de cobro temporal y un consumo de liquidez. Una devolución al cliente completada no significa que las cuentas entre todos los participantes ya estén cerradas.

La garantía se aplica a una obligación establecida

Supongamos que por una disputa se retuvieron temporalmente 2 000, y que la pérdida final confirmada fue de 1 600 más 50 de gastos acordados. Si ambos conceptos están dentro de la cobertura contractual, se aplican 1 650 y se liberan los 350 restantes. Se conservan la decisión, las pruebas, la fórmula del importe y el vínculo con la obligación concreta. Si los gastos no están previstos en la cobertura, retenerlos no puede justificarse solo porque haya depósito libre.

Más adelante, la contraparte puede compensar voluntariamente los 1 600 o el banco puede devolver parte de los fondos. Es un evento de recuperación aparte. Reduce el derecho de cobro pendiente y activa el ajuste previsto de la garantía aplicada antes. Un esquema automático de «disputa cerrada, depósito debitado para siempre» crea el riesgo de cobrar dos veces.

Ante una sospecha de fraude, una restricción de la cuenta o un requerimiento de las autoridades competentes, una devolución ordinaria puede no ser admisible sin una aprobación adicional. Estos casos se trasladan a los responsables de banca y compliance. Una transferencia rápida a una cuenta alternativa puede empeorar la situación de todos los participantes, aunque soporte quiera cerrar el ticket cuanto antes.

Cuándo el caso está realmente cerrado

El cierre consta de varias confirmaciones: la acción para el cliente está ejecutada, el resultado bancario está verificado, los importes están distribuidos, la garantía está ajustada y las deudas internas están cerradas o quedan explícitamente en gestión de cobro. Cada cambio monetario tiene un fundamento y un autor de la decisión; cada transferencia externa está vinculada al caso.

El historial debe permitir que un empleado nuevo explique el movimiento de cada unidad sin recurrir a la correspondencia personal del responsable de turno anterior. Así la disputa no se convierte en una negociación sobre quién tiene la posición más fuerte. Sigue siendo una secuencia verificable de hechos, decisiones y cálculos, en la que ni el excedente del cliente ni la pérdida confirmada de nadie se diluyen en el saldo general.

Fuentes

  1. 1.bybit.com/en/help-center/article/FAQ-P2P-Order-Appeals
  2. 2.binance.com/en/support/faq/detail/7afd4bd989014ad19467b413fe8db14d
  3. 3.docs.moderntreasury.com/ledgers/docs/transaction-status-and-balances

Comentarios · 0

Aún no hay comentarios — sé el primero.

Entrar · inicia sesión para comentar.