Escrow: sept étapes de "deal agreed" a "money in the bank"

Chaque deal B2B a un moment où l'une des parties doit avancer en premier. Soit le seller ship avant d'être payé, soit le buyer paie avant d'avoir vu les goods. Sans un tiers qui tient le filet, quelqu'un prend un risque qu'il ne devrait probablement pas prendre avec €45,000 d'argent appartenant à des inconnus.

Le flow escrow est ce tiers. Ce n'est pas un third-party service — il fait partie de la plateforme — mais fonctionnellement il fait ce qu'un escrow agent fait : garder les funds, les release quand les deux côtés sont satisfaits, et adjudicate lorsque ce n'est pas le cas.

Les sept steps

1. Deal Agreed. Un market deal se clôture (negotiation accepted) ou une auction settles (winner determined, deposit captured). Le trigger H2 se déclenche quand le deal passe à closed_won et crée l'escrow row, la deposit address et un escrow ID numéroté (ESC-YYYY-NNNNN). Le buyer reçoit une payment request avec IBAN et structured reference.

2. Funds Held. Le buyer wired les funds. La plateforme réconcilie le transfer entrant avec la escrow reference, marque l'escrow comme held et notifie le seller. Le seller voit alors que les funds sont confirmed et peut procéder au shipping.

3. Goods Shipped. Le seller ship. Le H3b ship-guard empêche le seller de marquer l'order comme shipped tant que l'escrow n'est pas held — fini les "j'ai shipped, puis le buyer a dit qu'il paierait demain, puis il ne l'a pas fait." Le tracking s'attache à l'order et est visible des deux côtés.

4. Goods Received. Le buyer marque delivery received. Cela lance l'inspection clock — l'auto-release window, configuré par tenant sur la H7 policies page (default: 7 days).

5. Inspection. Le buyer inspecte. Il a trois options : accept (release funds early), ne rien faire (auto-release à l'expiry du window), ou ouvrir une dispute. La plupart des cas passent par l'option 2 : le buyer est satisfait, la clock expire, la plateforme release les funds.

6. Dispute (if raised). Si le buyer ouvre une dispute, le cron H4 auto-release pause et le flow H5 dispute prend le relais. Le buyer file la claim avec photos et references à la grading originale. Le seller répond avec son evidence. Un adjudicator (platform staff) review et décide : full release to seller, full refund to buyer, ou split. La decision écrit des settlement rows avec le fee snapshot calculé par le H6 fees engine.

7. Funds Released. Que ce soit par acceptance, auto-release ou dispute resolution, l'état final est le même : une settlement row, une fee deduction, un seller payout, un buyer refund (si applicable) et un audit trail de chaque event dans escrow_events. L'escrow row passe à released / refunded / split. Le deal se ferme. Les deux parties passent à la suite.

Ce qui est recorded

Chaque state transition écrit une immutable row dans escrow_events. Les triggers empêchent updates et deletes — une fois qu'un event arrive, il reste pour l'audit. Le endpoint H9 evidence-package regroupe tous les events d'un escrow dans un ZIP téléchargeable : timestamps, amounts, deposit reference, ship-guard release, inspection acceptance, settlement breakdown. Si le compliance officer du buyer demande "que s'est-il passé sur cette transaction", la réponse est en un clic.

Mutual waiver

Certains deals entre long-time partners ne veulent pas d'escrow. Le PDF H10 mutual-escrow-waiver existe pour ces cas. Les deux parties signent dans la deal room, le waiver s'attache au deal, et le flow escrow est bypassed pour cette transaction. C'est l'exception rare — la documentation existe pour que le flow escrow reste strict partout ailleurs.