Moteur de frais escrow : une règle, calculée au moment où l’argent bouge

Une transition escrow qui déplace de l’argent doit le faire atomiquement. Si le paiement vendeur s’écrit mais pas les frais de plateforme, vous avez une incohérence à réparer à la main un vendredi après-midi. Le moteur de frais l’évite en calculant toutes les parts dans une seule transaction et en écrivant une settlement row par mouvement d’argent avant d’autoriser l’escrow à changer de statut.

Une règle pour toute la plateforme

Il existe exactement une configuration de frais, fixée par ReVend. Elle a un type — pourcentage, montant fixe ou hybride (pourcentage plus fixe) — et une répartition : à charge de l’acheteur, du vendeur, 50/50, ou une part acheteur/vendeur personnalisée. Les tenants ne configurent pas les frais, ni par catégorie, ni par issue, ni par palier de volume. Ce qu’un tenant obtient, c’est /escrow/fees : une vue en lecture seule de la règle en vigueur, des parts acheteur et vendeur, un exemple chiffré sur un deal type et la date du dernier changement de règle. Un écran de frais que tout le monde pourrait modifier serait démocratique, énergique et financièrement catastrophique.

Quand les frais sont calculés

À la libération — pas à la création de l’escrow. La raison, c’est le split : quand la compliance partage un montant contesté, les frais doivent être calculés sur ce que chaque partie reçoit réellement, pas sur le total d’origine. Calculer trop tôt reviendrait à recalculer plus tard, et recalculer de l’argent, c’est ainsi que naissent les réunions de rapprochement.

Le calcul de la répartition

Pour une release standard : les frais valent le montant fois le pourcentage, ou le montant fixe, ou les deux ; arrondis d’abord, puis plafonnés pour ne jamais dépasser le montant de l’escrow. La totalité des frais est prélevée sur le montant déposé par le buyer, et le paiement du vendeur est ce qui reste. Les parts acheteur et vendeur relèvent de l’affectation comptable, pas de deux prélèvements distincts : leur somme fait le même total de frais, et elles existent pour que la finance puisse imputer le revenu de chaque côté. Le moteur écrit une ligne seller_payout, une ligne platform_fee_buyer et une ligne platform_fee_seller.

Pour un refund : le buyer récupère la totalité du montant et aucun frais n’est prélevé. Une seule ligne buyer_refund. C’est un choix délibéré — un acheteur qui avait raison ne devrait pas payer pour avoir eu raison, et des frais sur les remboursements décourageraient précisément les litiges qui méritent d’être déposés. La même règle s’applique quand un outbound est annulé avant tout envoi et que l’escrow retenu est remboursé automatiquement.

Pour un split : les frais sont calculés uniquement sur la part libérée au vendeur, et la part remboursée à l’acheteur n’en porte aucun. Le responsable compliance voit les deux montants avant de confirmer sa décision.

Fail-closed

Les settlement rows sont écrites d’abord, le changement de statut ensuite, les deux dans la même transaction de base de données. Si la configuration de frais manque, l’écriture lève une erreur et toute la transaction est annulée : l’escrow reste held (ou en litige), et la tentative suivante réessaie une fois la configuration en place. Un escrow bloqué est agaçant. Un escrow libéré sans ligne de paiement est un incident.

Devise

Les montants portent la devise de l’escrow. Quand un deal traverse deux devises, le taux de change est figé sur l’escrow lui-même à l’acceptation — taux, horodatage et source — à partir des taux quotidiens rafraîchis à 07:00, pour qu’un litige six mois plus tard reconstruise le taux exact plutôt que celui du jour. Sur la page settlements, des paiements en devises différentes ne sont jamais additionnés en un seul chiffre ; la finance obtient un bouton de lot par devise.