For home services
Home-services platforms: cancellations and partial refunds are your biggest leak
Home-services marketplaces live in refund volatility: quotes become final bills, jobs shrink in scope, customers cancel when rain cancels the roofer. Every one of those adjustments is a partial refund against a transfer already sent to a contractor — and partials are precisely where Connect leaks survive code review. Modelled against typical volumes below, the annual figure explains why this vertical feels busy and profitable while margins quietly leak.
Your transaction shape
Deposits collected at booking, balances on completion, occasional scope changes mid-job. Each payment is its own destination charge; each adjustment is a partial refund needing both flags. Cancellation windows add same-day races — refund requested before the job-transfer settles, which is exactly the ordering case that produces both missed recoveries and phantom findings.
The modelled arithmetic
Take a mid-sized regional platform: 200 bookings weekly, average completed value $85, platform fee 20%, cancellation-plus-adjustment incidence around 18% — mostly partials. That is roughly $3,000 weekly flowing through refund paths, of which typical leakage rates strand hundreds weekly in contractor accounts. Annualised before anyone notices: four figures. Label it modelled, then replace it with your own scan output.
- Bookings × avg value
- 200 × $85 = $17,000
- Refunding share
- ~$3,060
- Seller-side transfers at risk
- ~$2,450
- Stranded at typical leak rates
- $150–400/wk
Where the flag goes missing here specifically
Dispatch software issuing courtesy credits. Phone-support reps refunding through dashboards. Same-day cancellation logic written before transfers existed in the flow. Contractor no-show policies refunding deposits manually. None of these paths went through the review your main checkout got — which is why the main path audits clean and the money still leaves.
Same-day races need serialisation
Cancellation and completion can land within seconds of each other; charge.refunded and the transfer events race in either order. Without per-charge locking, monitoring reports phantoms and gets switched off. FeeGuard delays refund processing five seconds and locks per charge — boring engineering that exists purely so findings stay believable.
What FeeGuard does about it
Detectors handle the deposit-balance structure natively, findings attribute cause per event so dispatch bugs identify themselves, and the free scanner accepts pasted refund exports so you can baseline before any integration conversation happens.
Common questions
Are deposits refunded before job completion a special case?
Liability follows merchant-of-record status regardless of timing — the platform on destination charges. Timing changes only whether funds are reachable for recovery.
Do same-day cancellations produce false alarms?
Not in a correctly ordered pipeline. Races are handled by delay plus lock; anything flagged remains genuinely missing money.