There is a question you can answer in a sentence, and it will quietly determine six months of engineering. When a buyer pays on your marketplace, who holds the money until the work is delivered?

Founders usually answer "us, obviously" and move on to the catalogue. It is worth stopping there a little longer, because that sentence has a build cost, a legal shape and a support load attached to it, and they are all different depending on the answer.

Escrow, agency, or direct: the three ways to hold marketplace payments

The money never touches you. Buyer pays seller directly, you take a fee or a subscription. Cheapest to build and the least useful to your users, because the marketplace stops being a guarantee. The first time someone pays and receives nothing, they learn your platform was a directory.

You hold it until the work is accepted. The buyer pays, the funds sit, the seller delivers, the buyer approves, and only then does the balance move. This is what people picture when they say marketplace, and it is the one that carries real obligations — you are holding other people's money, which is a regulated activity almost everywhere and needs an agency or escrow arrangement your provider and your accountant both agree with.

Something in between, usually via a payment provider that supports split payments or nominal accounts, where the money is technically never yours but the release is triggered by you.

The technical work differs less than you would expect between the second and third. The legal and operational work differs enormously. Decide it with your accountant present, not with your developer.

Why it changes the build

Once money is held, your order stops being a record and becomes a state machine. In a marketplace we built, an order moves through pending, awaiting payment, in progress, review, and then one of done, revision or dispute. Every transition needs a rule about two things: what happens to the funds, and what happens to file access.

That sounds tidy written down. The difficulty is the edges nobody demos:

  • The buyer taps pay twice on a slow connection.
  • The seller uploads the work and immediately deletes their account.
  • Either party gets banned while an order is paid and in progress. This one deserves its own test suite, and got one — a ban that quietly strands a paid order does more damage than no ban at all.
  • The payment succeeds but the buyer's phone dies before the app hears about it.

That last one is worth its own section, because it is the single most common way marketplace payments go wrong.

The phone is not allowed to say the payment worked

The intuitive flow is: buyer pays, the payment screen returns success, the app tells your backend to start the order. It works in testing every time, and it is wrong.

The app may be backgrounded, killed by the operating system, or simply out of signal at the moment the payment completes. If starting the order depends on the app reporting back, then some percentage of your buyers will pay and see nothing happen — and they will be the ones who tell everyone.

The correct source of truth is the payment provider, talking to your server directly. The provider posts a webhook, your backend verifies it and moves the order into progress, and the seller gets a notification. The app finding out is a nice-to-have that happens next.

Building it that way means treating duplicates and out-of-order deliveries as ordinary traffic rather than as errors, because providers retry, and retries arrive whenever they arrive. It is more work than trusting the screen. It is the difference between a marketplace that holds money and one that loses it.

Delivered work has to be worthless until it is paid for

If your marketplace trades in files — video, design, photography, documents — you have the mirror-image problem. The buyer will not release payment until they have seen the work. The seller will not hand over the work until they are paid.

The way out is to deliver something real but unusable. In the marketplace above, the seller uploads a video and the server produces a watermarked copy. The buyer reviews only that. The clean original is released the moment the work is accepted, and the watermarked version stays in the order archive, because if a dispute is opened three weeks later, somebody has to be able to see what was actually delivered.

The useful principle underneath: file access is not a permission attached to a person. It is a function of the order state.

What to decide before anyone writes code

  • Who holds the funds, confirmed with your accountant and your payment provider, not assumed.
  • What "delivered" means precisely enough to be a database value.
  • What a buyer can see before paying, and what changes at the moment they pay.
  • What happens to an in-flight order when an account is suspended.
  • How long dispute evidence is kept, and who can look at it.

None of these are technical questions, which is exactly why they get postponed. They are also the five that will cost the most to change once the product has real orders in it.

Answer them on one page and most of the argument is over — the build becomes a matter of typing. Get them wrong and you will be refunding strangers by hand at eleven at night, which is a thing we would rather you never learn first-hand.

If you are weighing up a marketplace, send us that page. We do mobile and marketplace builds, and you will get a range, the assumptions under it, and a straight answer on whether the idea is worth building at all.