The customer pays the fee, so the worker gets every penny

At the top of TipBop’s money code there is a sentence that every other line in the file has to obey: a tap must be indistinguishable from handing someone a tenner.

Hand a waiter a ten-pound note and they have ten pounds. Nobody takes 50p off it on the way. So when a customer taps a TipBop badge and chooses £10, the worker receives £10.00, to the penny, and the fee goes on top for the customer to see before they pay. That is the whole model, and it was not where we started.

Why a cut out of the tip cannot work

The obvious way to run a tipping app is the way most of them do it: the worker receives the tip minus a percentage, and the platform pays its card processor out of that percentage. Our own first brief said the same.

The trouble is the card fee. Stripe charges a standard UK card 1.5% plus a fixed 20p. The percentage scales with the tip. The 20p does not, and on a small tip it eats everything.

Take a 5% cut. On a £3 tip the platform keeps 15p, and Stripe charges 4.5p plus 20p, so 24.5p. The platform loses 9.5p every time someone is generous. The break-even point is where the cut finally covers the fixed fee: 20p divided by the 3.5 points left after Stripe’s percentage, which is £5.71. Every tip below that loses money.

That would be fine if tips were big. They are not. In our early conversations, personal tips looked likely to cluster between £1 and £5, which is exactly the range where a percentage cut is insolvent. The workers we asked put the most they would accept at about 1.5%, which is less than Stripe charges before its 20p. There is no rate that a worker will accept and a business can survive on. That is not a pricing problem we could tune our way out of. It is structural.

And even where the numbers work, the worker notices. A tip that arrives as £4.75 is a transaction. A tip that arrives as £5.00 is a gift.

The fee we chose: 40p plus 4%, on top

The customer pays 40p plus 4% of the tip, rounded to the nearest penny. It is shown plainly before payment, never pre-ticked, never hidden and never dressed up as a tip to us. On a £5 tip that is 40p plus 20p, so the customer pays £5.60 and the worker gets £5.00.

Here is what TipBop keeps on a standard UK card. Stripe’s percentage applies to the whole charge, not just the tip, so on a £5 tip it is 1.5% of £5.60, which is 8.4p, rounded to 8p, plus 20p: 28p. The fee was 60p, so we keep 32p. The same sum at other sizes:

The last row is honest: on a big tip a percentage cut earns more. We think that is the right trade. Big tips are rare, small ones are the product, and the fee on top is profitable at every size.

It used to have a cap. Until 21 August the fee stopped at £2.00, which sounds customer-friendly and is a liability. Past a point the capped fee stops covering what Stripe charges. Measured across every card type, the cap made three of the four lose money on a large tip: a UK premium card by 14p, an EEA card by 75p, an international card by £1.52. Without the cap every card type is positive at every size, because 4% grows faster than Stripe’s worst case of 3.25%. The margin at the bottom is thin, 8p on a £3 tip from an international card with fraud screening and 3D Secure, but it is never negative. The test that guards this is literally named “has NO ceiling”.

Two limits that moved today

The minimum tip came down from £3 to £2 today, and the reason matters. It is not an economic floor. Even a £1 tip nets us 19p to 22p across every card type. It is about how the fee looks. On £1 the fee is 44p, which is 44% of the tip, and that is the kind of number that gets screenshotted. On £2 it is 48p, or 24%, which we can defend. And since we expect tips to cluster from £1 to £5, a £3 floor was shutting out the bottom of our own market.

The maximum went up from £100 to £250. The old ceiling existed because the capped fee made big tips lose money. With the cap gone, the only reason left for a ceiling is fraud: TipBop carries a disputed payment, not the worker, so a tip paid on a stolen card and charged back costs us the whole amount. One £250 chargeback would wipe out what roughly 95 good £100 tips earn us, at about £2.63 each after Stripe’s fee. £250 covers a large table or a wedding and caps what one bad card can cost. We will raise it on dispute data, not on a hunch.

We also took the percentage off the customer’s page today. It was accurate, which is the problem: 40p on a small tip reads as a big percentage, and the pence were already on the same line. The worker is still told the rate in full, as 40p plus 4%, in their own app.

The bug on the very first tip

The model above is right now. On 25 August it was not.

The first tip we ran end to end was £10.00. The customer was charged £10.80. The worker received £10.36.

Our code set TipBop’s share of the charge to the customer fee minus our estimate of Stripe’s fee, 80p minus 36p, so 44p. That formula is correct when Stripe takes its fee from the worker’s side of the payment. Our accounts are set up the other way: the platform is billed for Stripe separately. So nothing else came off the worker’s side, the worker was 36p up, and we were 36p down, on every tip.

All 65 invariant tests passed. The simulator they ran against modelled the wrong formula, so the tests agreed with the code and both were wrong. Our reconciliation did not catch it either, because reconciliation only ever tops a worker up. An overpayment is ours to absorb by design.

The fix made the promise arithmetic instead of an estimate. TipBop’s share is now the whole customer fee, so the worker receives the total minus the fee, which is the tip, exactly, for every amount and every card. Reconciliation stays, because it checks that sentence against Stripe’s ledger rather than against our own code.

Update, 9 November 2026

These two App Store screenshots come from a later build than the one this post describes.