Escrow is a trust problem before it is a payments problem

The easy version of escrow is a payments feature: hold the money, release the money, take a cut in between. That version is straightforward to build and almost useless, because the hard part of escrow was never moving the money. It was convincing two strangers that moving the money first is safe.

Most commerce in Nigeria happens between people who have never met and will probably never meet again: a buyer replying to an Instagram post, a seller taking a deposit over WhatsApp for a job that starts next week. There is no shared history, no mutual acquaintance to vouch for either side, and no institution that either party trusts by default. Someone has to move first. That single fact, someone has to move first, is the entire design problem.

The money has to be visibly held, not just technically held

It is not enough for Zorva to actually hold the funds correctly on the backend. If a buyer cannot easily tell, at a glance, that their money is sitting in a neutral place rather than already in the seller's account, the product has failed at its actual job. The interface has to make the holding state impossible to miss: the transaction status, the amount, the fact that neither party can touch it, all visible before anyone is asked to act.

This sounds obvious once said out loud, but it is easy to build the correct backend state machine and a merely adequate UI, and end up with a product that is safe but does not feel safe. Feeling safe is not a cosmetic layer on top of the real product. For an escrow product specifically, it is close to the whole product.

Auto-release timers exist because ghosting is a real strategy

A buyer who receives goods and simply stops responding is not a hypothetical edge case, it is a predictable behaviour once you accept that some fraction of people will always take the path of least resistance when there is no cost to doing so. If confirming delivery is the only way funds ever release, a buyer who never confirms has effectively taken the goods for free while the seller's money sits frozen indefinitely.

The fix is a delivery window with an auto-release timer: once a seller marks an order shipped and a reasonable window passes with no dispute raised, funds release automatically. This is not a punishment aimed at buyers. It is a recognition that silence has to resolve to something, and leaving it unresolved is itself a decision, one that quietly favours whoever benefits from delay. In a two-sided trust product, neutrality means neither side can win by simply doing nothing.

Disputes need a human, not a flowchart

It is tempting to automate dispute resolution the same way you automate everything else: rules, evidence thresholds, an algorithm that decides who was right. We chose not to do this for Zorva. Disputes are exactly the situations where the inputs are messy, the photos are ambiguous, and the real question is usually about intent, not fact. A rules engine trained on clean cases will handle the easy 80 percent fine and get the hard 20 percent wrong in ways that erode trust in the platform faster than slow resolution ever would.

A human mediator is slower and more expensive to run than a flowchart. It is also the only approach that can hold two contradictory-sounding stories at once and ask the follow-up question that actually resolves them. For a product whose entire value proposition is trust, we would rather be slower and right than fast and wrong.

Instant payout on confirmation is not a nice-to-have

Once a buyer confirms, the seller's money needs to move immediately, by direct bank transfer, not after a settlement cycle measured in days. The reasoning connects back to the same trust problem from the other direction: if sellers learn that confirmation does not actually mean immediate payment, the platform starts to feel like it is holding their money hostage too, just with extra steps. Trust has to run in both directions or it does not really exist in either.

None of this is about technology being clever

It would be easy to write a version of this piece about the technical mechanics of holding funds safely: idempotent transactions, ledger consistency, the usual list. None of that is uninteresting, but it is not what determines whether Zorva actually works for the person deciding whether to send ₦45,000 to a stranger's escrow link. What determines that is whether the product visibly, legibly, repeatedly proves that moving first is safe. Everything else is implementation detail in service of that one sentence.