The marketplace payments guide

Escrow is only as good as the event that releases it. Delivery confirmed by the buyer, by a courier webhook, or by a timer after dispatch are three different products with three different dispute profiles.

Pick one, write it into your terms, and make it the same rule for every order. Marketplaces get into trouble when release is decided case by case by whoever is on support that day.

A percentage of the order, a flat fee, or a subscription the seller pays separately. The first is most common and the easiest to explain. Whatever you choose, record it per order rather than deriving it later: rates change, and last quarter’s orders must keep last quarter’s rate.

Show the seller their net at the moment of sale. A seller who has to compute what they will receive will compute it wrong and then be annoyed with you.

Taking payment into your own account and paying sellers from it makes you a money transmitter in most jurisdictions, with the licensing that implies. Onboarding sellers so each has their own account, and splitting at the point of payment, keeps that risk where it belongs.

This is a legal question as much as a technical one. Ask it early, because the answer shapes your architecture.

A buyer in Kenya paying a seller in Tanzania is a normal order here: the buyer pays in KES on their own network, the seller is credited in TZS, and the rate is shown before the buyer confirms.

Store the rate on the order. When someone asks in three months why a seller received what they received, the answer has to be on the record, not recalculated at today’s rate.