Motor de tarifas de escrow: una regla, calculada cuando el dinero se mueve
Cómo se calculan y se escriben el pago al vendedor, las partes de la tarifa de plataforma y el reembolso al comprador en cada liberación, reembolso o división, a partir de una única regla para toda la plataforma.
Una transición de escrow que mueve dinero tiene que hacerlo de forma atómica. Si se escribe el pago al vendedor pero no la tarifa de plataforma, queda una inconsistencia que hay que reparar a mano un viernes por la tarde. El motor de tarifas lo evita calculando todas las partes en una sola transacción y escribiendo una fila de liquidación por cada movimiento de dinero antes de permitir que el escrow cambie de estado.
Una regla para toda la plataforma
Hay exactamente una configuración de tarifas, fijada por ReVend. Tiene un tipo —porcentaje, fijo o híbrido (porcentaje más fijo)— y un reparto: paga el comprador, paga el vendedor, 50/50 o una división personalizada entre comprador y vendedor. Los tenants no configuran tarifas: ni por categoría, ni por resultado, ni por tramo de volumen. Lo que un tenant tiene es /escrow/fees: una vista de solo lectura de la regla vigente, las partes de comprador y vendedor, un ejemplo resuelto sobre un acuerdo de muestra y la fecha del último cambio de la regla. Una pantalla de tarifas que todo el mundo pudiera editar sería democrática, enérgica y financieramente catastrófica.
Cuándo se calcula la tarifa
En la liberación, no al crear el escrow. El motivo es el resultado dividido: cuando cumplimiento reparte un importe en disputa, la tarifa tiene que calcularse sobre lo que cada parte recibe de verdad, no sobre el total original. Calcularla antes obligaría a recalcularla después, y recalcular dinero es como nacen las reuniones de conciliación.
El cálculo del reparto
Para una liberación estándar: la tarifa es el importe por el porcentaje, o el importe fijo, o las dos cosas; primero se redondea y después se limita, de modo que nunca puede superar el importe del escrow. La tarifa entera sale del importe que depositó el comprador, y el pago al vendedor es lo que queda. Las partes de comprador y vendedor son atribución contable, no dos cobros distintos: suman la misma tarifa total y existen para que finanzas pueda imputar el ingreso a cada lado. El motor escribe una fila seller_payout, una fila platform_fee_buyer y una fila platform_fee_seller.
Para un reembolso: el comprador recupera el importe completo y no se cobra tarifa alguna. Una fila buyer_refund. Es una decisión deliberada: quien tenía razón no debería pagar por haberla tenido, y una tarifa sobre los reembolsos desanimaría justo las disputas que merecen presentarse. La misma regla se aplica cuando una salida se cancela antes de enviar nada y el escrow retenido se reembolsa automáticamente.
Para una división: la tarifa se calcula solo sobre la parte que se libera al vendedor, y la parte que se reembolsa al comprador no soporta nada de ella. El responsable de cumplimiento ve las dos cifras antes de confirmar la decisión.
A prueba de fallos
Primero se escriben las filas de liquidación, después el cambio de estado, las dos en la misma transacción de base de datos. Si falta la configuración de tarifas, la escritura lanza un error y la transacción entera se deshace: el escrow se queda retenido (o en disputa) y el siguiente intento vuelve a probar cuando la configuración exista. Un escrow bloqueado es una molestia. Un escrow liberado sin fila de pago es un incidente.
Moneda
Los importes llevan la moneda del escrow. Cuando un acuerdo cruza monedas, el tipo de cambio se bloquea en el propio escrow al aceptar —tipo, marca de tiempo y fuente— con los tipos diarios que se refrescan a las 07:00, para que una disputa seis meses después reconstruya el tipo exacto y no el de hoy. En la página de liquidaciones, los pagos en monedas distintas nunca se suman en una sola cifra: finanzas recibe un botón de lote por moneda.