For equipment rental
Equipment-rental platforms: deposits, damage claims, and late-return disputes
Rentals are structurally partial-refund businesses: nearly every booking ends with some adjustment — damage deductions, late returns, early returns, fuel and cleaning line items. Every adjustment is a partial refund against a transferred payout, frequently issued by operations staff through dashboards rather than by the payment code anyone reviewed. That combination — structural partials plus human refund paths — produces leak profiles that surprise platforms precisely because each individual deduction looks routine.
Deposit architecture decides recovery paths
Deposits held inside the main charge follow destination-charge rules with everything reversible; deposits as separate charges enter separate-charges territory — manual levers, ordering hazards, and damage-deduction flows that skip Connect math when settled off-platform. Neither is wrong; mixing them without documentation guarantees findings nobody can attribute.
The dashboard-refund path is your primary leak
Ops teams assessing damage photos issue deductions from admin screens. Those flows bypass the reviewed payment code entirely — flags unset, proportions eyeballed, idempotency absent. FG-19’s secondary-paths argument is not theoretical here; it is Tuesday afternoon. Inventory every screen capable of issuing refunds, then audit each one’s parameters.
Modelled against a regional fleet
600 rentals monthly at $380 average, 18% platform fee, 22% of rentals producing adjustments averaging $60. Roughly $7.9k monthly in deduction flows; typical stranding puts three figures weekly into renter-side accounts — concentrated among repeat commercial renters who notice patterns eventually and churn quietly.
- Rentals × value
- 600 × $380 = $228k
- Adjustment incidence
- ~22% → 132 rentals
- Deduction flow (avg $60)
- ~$7,900
- Typical stranding band
- $160–630/mo
Extension charges create second transfers
Late returns billed as supplemental charges create fresh transfers carrying identical flag risks — and pairing them mentally with the original booking means reconciliation logic written once gets reused where it does not apply. Treat every supplemental charge as its own first-class object with its own reversal expectations.
What FeeGuard does about it
Both deposit architectures handled natively; per-object attribution separates original bookings from extensions; and dashboard-path refunds produce findings like any other source, which is how ops workflows finally get the same scrutiny as checkout code.
Common questions
Staff issue deductions from the dashboard — really a problem?
It is usually the largest single leak source in this vertical. Dashboard refunds carry default flags unless deliberately configured otherwise, and defaults strand transfers.
Can deductions exceed what was transferred?
Then they become platform receivables against renters instead — different problem, negative-balance mechanics on the other side of the ledger.