What a Delayed Payout Model Teaches You About Designing for Trust Between Strangers

We worked on a property maintenance platform that put landlords, tenants and tradespeople in the same place. A job spec gets uploaded, someone accepts it, turns up, does the work, geotags the progress, and then money has to move between two people who have never met and have no particular reason to believe each other. That last part turned out to be the whole design problem.

Money that sits still for a few days is doing emotional work, not just financial work.

The brief said escrow, because escrow is what everyone says when they mean "hold the money until the work is finished". We investigated third-party escrow services and then walked away from them, because they brought legal complications the client had no appetite for. What we built instead was Stripe Connect with delayed payouts, treating the product as a marketplace app, which gave us the same end result while Stripe carried the regulatory weight.

That choice changed more than the integration. It changed what we had to show people, when, and in what order, because money held in the middle of a transaction creates a gap in time that both sides can feel. This article is about how we designed that gap, what we got wrong on other projects before it, and what payment timing teaches you about trust between strangers.

Who Is Actually Taking the Risk

On the property platform, the obvious answer is the landlord, because they are the one with money leaving their account. Spend an hour with a tradesperson and the answer flips. They are the ones giving up a day of paid work, buying materials, driving across a city and hoping the person at the other end pays up afterwards. Both sides are exposed, and both sides are exposed at different moments.

Whoever moves first carries the risk. That is the part worth designing around, and it shows up well outside payments.

Sequencing before stakes

On a dating product we worked on, the flow asked people to share their precise location early, before they had any reason to trust the person they were sharing it with. We reordered it so you could see a profile, have a conversation through the inbuilt messaging, and only then, once you felt confident enough, share where you wanted to meet. Same feature, different position in the sequence, far less drop-off.

Payment timing works the same way. If the tradesperson has to start work with no evidence that money exists, the platform has asked them to move first with nothing in return. If the landlord has to pay in full before anyone turns up, the platform has done the same thing to them. Holding the money is how you stop either person going first alone.

Why Escrow Was the Obvious Answer, and the Wrong One

Escrow has a clean story. A neutral party holds the cash, both sides relax, work happens, money moves. We looked hard at third-party escrow providers for the property maintenance platform and the story stopped being clean once the lawyers got involved.

Holding other people's money is a regulated activity. Plugging in a third-party escrow service meant the client sat closer to the middle of that than they wanted to be, with contracts, licensing questions and a dependency on a provider whose rules we did not control. For a product still proving its market, that is a lot of legal surface area to take on for a behaviour, rather than a feature.

The question underneath the request

So we went back to what the client actually wanted, which was simpler than escrow. They wanted a tradesperson to see that funds existed before starting, and a landlord to keep control until the job was signed off. Nobody in the building cared whether a licensed escrow agent was involved. They cared about the feeling of the thing.

Once we framed it that way, the question stopped being "which escrow provider" and became "how long can money sit inside a payment processor we already trust". That question had a much better answer.

How Delayed Payouts Produce an Escrow-Shaped Outcome

Stripe Connect lets a marketplace take a payment from a customer, hold the funds in the platform balance, and release them to the seller later. We used delayed payouts so the tradesperson's money only moved once the job was marked complete. The landlord pays up front, the tradesperson can see the job is funded, and nothing lands in anyone's bank until both sides agree the work is done.

The behaviour people experience is escrow. The legal structure is a marketplace app using a payment processor exactly as that processor intends, which is why Stripe absorbed the financial regulation rather than our client.

Stripe held the money, Stripe held the regulatory burden, and we kept the behaviour we wanted.

Holding funds back is ordinary once you look outside your own category. JustAttend describes event management platforms withholding 20% to 40% of ticket earnings until after an event finishes, with payouts every two weeks, which tells you that sellers already live with money sitting still for a while.

What people will not accept is a hold they did not know about. The difference between the property platform and a bad experience of the same mechanic is entirely in what each side was told, and when. Delay is fine. Silence during the delay is what does the damage.

Account Types, Control and the Cost of Customisation

The integration work was less about code and more about picking a shape. Stripe's Express accounts, for instance, push you towards near-immediate payouts, which is sensible for most marketplaces and useless when the entire point is to hold money until a job is finished. Express would have been quick to build and wrong for the product.

Here is how the three options compared on the questions the client actually asked.

The trap sits in that last row. As Simon puts it, "the more control you have over the payments, the more complex the flows become", so it was about finding the balance between getting exactly what we needed and going so far into customisation that we lost the benefits of Stripe's default payment handling. Every piece of behaviour you override is a piece you now maintain, including the error states, the edge cases and the parts that break quietly at two in the morning.

Deciding What Counts as "Done"

Holding money until the work is complete sounds simple until someone has to define complete. A tradesperson thinks the job is done when they pack up. A landlord thinks it is done when they have seen it. A tenant, who is often the only person in the building, thinks it is done when the leak stops.

On the property maintenance platform we used geotagged progress against the original job spec, so completion had evidence attached to it rather than being one person's word. On a logistics platform we built for transport deliveries and removals, we had the same problem with third-party drivers and solved it with swappable codes or QR codes scanned at the door, giving a double confirmation from the customer and the driver. On a separate gig economy product, money was held in advance and released only after a double sign-off from both parties.

Write the definition of "done" as a sentence a nine-year-old could check before you write a line of payment code. If you cannot, your dispute queue is already full.

The pattern across all three is that completion needs two signals, not one, and each signal needs to be cheap to give. A code swap at the door takes four seconds. A form with six fields at the end of a long shift does not get filled in, and then the money sits there annoying everybody.

Disputes, Refunds and Partial Release

The moment you hold money, you own the argument about it. That is the cost of the escrow-shaped outcome, and it arrives on the days when a tradesperson says the job is finished and a landlord says half of it is.

Delayed payouts give you something third-party escrow does not, which is a short, defined window where the money is still yours to direct. The design job is deciding what happens inside that window before anyone needs it. These are the questions worth settling early.

• How long does a hold last if nobody signs off at all
• Who can release funds besides the two parties, and on what evidence
• Whether partial release exists, and who sets the split
• What the customer sees the day a dispute is opened
• Where the platform fee sits if a refund happens

That last one catches people out. A refund that quietly keeps the fee feels like a small charge for a service nobody received, and small charges do disproportionate damage to trust when they are unexplained.

Partial release is where teams consistently over-build. Full release and full refund cover the overwhelming majority of cases, and a human on support can handle the rest for a long time before the volume justifies an automated split.

Showing the Fee: Why Hiding Costs Breaks Trust

On a travel booking product, we decided to wrap the platform's Stripe booking fee into the total price. The logic was reasonable. Travellers want one clean number, so give them one clean number. What we found was the opposite of what we expected. People expected to see a platform fee broken out as a line, because that matches how they think apps work, and by not showing it we created a fear that a hidden fee was coming later.

Breaking every fee out on screen gave travellers more confidence than one clean total ever did.

We switched to showing everything, and confidence went up even though there was more information on the page. On a marketplace checkout project we saw the same dynamic from the other direction, where confusion about whether a fee was added on top or already included in the price produced visible hesitation and drop-off. As Simon describes it, "even though the numbers can be quite small, if there is any confusion around whether that fee is added, whether that fee is already included in the price, that's where you start to see some hesitation".

The amount was never the problem. Ambiguity was. A fee someone understands is a cost, and a fee someone cannot account for is a warning sign.

What Each Party Needs to Know While the Money Is Held

A hold creates dead time, and dead time fills with worry unless you put something in it. The tradesperson wants to know the job is funded before they load the van. The landlord wants to know their money has not vanished. Both want to know what happens next and roughly when.

We had already learned how to handle that kind of drip-feed on a concierge app we built for residents moving into a new block of flats. Rather than dumping recycling locations, emergency procedures and local guides on people the day they arrived, we sent each piece when it became relevant. The timing was dynamic rather than fixed, based on what time someone arrived at the property and how many people lived there, because somebody who gets the keys at eight in the evening is not unpacking that night, and one person takes longer than three.

Match the rhythm of your payment notifications to the rhythm of the job, not to a fixed number of hours. A two-day paint job and a twenty-minute tap repair need different silences.

Apply that to a payment hold and the messages almost write themselves. Funds confirmed when the job is accepted, a quiet period while work happens, a prompt to sign off when completion is logged, and confirmation the moment money moves. Four moments, each one answering the question the person is actually asking at that point.

Compliance as a Design Constraint, Not a Legal Afterthought

We learned this one the hard way on a peer-to-peer currency exchange product. The idea was good. People with leftover foreign currency could swap it with other travellers at interbank rates and skip the commission a bank or bureau takes. We built the transfer mechanism well and did not factor in anti-money laundering rules.

Apple flagged the product as a possible vehicle for money laundering, because the transfer capability had no ceiling on it. We went back and retrofitted several layers of compliance, including more stringent know your customer checks, tighter transfer security, and hard limits on how many transfers any two parties could make between them. Partway through we also found that direct peer-to-peer transfers of that kind were not permitted at all, which forced the product to become location-based and in person, where people meet up and exchange currency physically.

That is a pivot nobody budgets for. It happened because compliance arrived after the design rather than inside it.

Which is exactly why the property maintenance platform went the way it did. Choosing Stripe's delayed payouts and the marketplace model meant staying inside financial regulation by default, with Stripe handling the legal and regulatory requirements, while we still got the end result the client wanted.

Why Testing Payment Flows in a Lab Flatters You

Put a checkout flow in front of a usability participant and they will tell you it is clear. They are reading it, not paying with it. Nobody in a test session is handing over four hundred pounds of their own money to a tradesperson they have never met, so they assess the screen functionally and rationally and give you a pleasant score.

Simon's line for this is "people are feeling okay with stuff until they're not", and the point underneath it is that emotional state does the deciding. The person in the lab is a detached observer. The person at the real checkout is a participant with something to lose, and their tolerance for anything odd drops sharply.

Treat strong lab results on a payment screen as a signal that your test was too comfortable, and go and read the drop-off data from the live flow instead.

Live analytics tell a different story from the session recordings every time you compare them on a money flow. Something that looked perfectly fine in testing turns out to be the thing that erodes trust just enough for people to bail out. That is the behaviour to design against, and a lab will not show it to you. Watch where real people stop, then go and look at what was on the screen when they did.

A Framework for Designing Payment Timing

Everything above collapses into a sequence we now run before touching an integration. The order matters, because each answer narrows the next one.

1. Name who moves first and what they are risking at that moment
2. Define "done" as something two parties can both confirm cheaply
3. Decide the behaviour you need, then find the least customised way to get it
4. Write the dispute rules before you write the happy path
5. Show every fee as its own line, including the one you were going to absorb
6. Plan the messages that fill the holding period, timed to the job

Step three is the one teams skip, and it is the one that saved the property maintenance client a great deal of money. They asked for escrow. What they needed was for money to sit still until a job was signed off, and a standard marketplace setup with delayed payouts delivered that without putting them in the middle of a regulated activity.

Start from the feeling you want each party to have at each moment. Then work backwards into the mechanism, and take the simplest one that produces it.

Conclusion

Trust between strangers is built out of small, boring certainties. The tradesperson knowing the money is there. The landlord knowing it has not gone anywhere. Both of them knowing what counts as finished, what the fee is, and who to speak to if something goes wrong. None of that is exciting, and all of it is the product.

What the delayed payout work taught us is that the mechanism matters far less than people assume. Users of the property maintenance platform never knew whether a licensed escrow agent or a Stripe balance was holding their money, and they never asked. They cared whether the timing matched their sense of fairness, and whether the screen in front of them told the truth about costs.

So the design questions come first. Who goes first, what does done mean, what does each side see while they wait, and what does the fee line say. Get those settled and the technical choice usually makes itself, which is how a marketplace app with delayed payouts ended up doing the job escrow was asked to do.

If you are working through payment timing, proof of completion or fee transparency on a marketplace product, let's talk about designing for trust between strangers.

Frequently Asked Questions