The short answer
A payment’s paid or failed status should come only from the payment provider’s confirmation — the webhook — never from a human clicking “mark as paid”. A manual mark records revenue no one collected: it inflates your income, corrupts investor payouts computed from it, and hides money you are still owed. Money that genuinely arrives outside the system gets recorded with evidence attached — a receipt, a bank statement line — not by flipping a status.
Every fleet management tool eventually faces the same feature request: “just let me mark this payment as paid.” It sounds harmless — the renter transferred the money, you saw it land, why shouldn’t you tick the box? Carz refuses to build that button, and this post is the reasoning. It is one of the few hills worth dying on in rental software, because the button quietly destroys the one thing your books are for: telling you the truth.
What does “provider-derived payment status” mean?
It means exactly one party gets to say a payment is paid: the party that moved the money. When your system charges a card or debits a bank account, the provider — Stripe, Square, the PayTo rail — confirms the outcome asynchronously (a webhook: “this charge succeeded” / “this charge failed”), and that confirmation is what flips the payment’s status. Not the admin who initiated the charge, not the renter’s screenshot, not a promise on WhatsApp.
In practice the rule has three parts:
- Paid and failed are provider verdicts. No screen in the system offers a human a paid/failed toggle. The only manual status action that exists is cancelling a stale pending charge — cleanup, not an assertion that money moved.
- A pending charge is pending, not failed. Bank debits like PayTo settle asynchronously; treating in-flight as failed is the mirror-image error, producing double-charges and false alarms.
- Out-of-band money is recorded with evidence, as its own event — never by editing a provider charge’s status (more below).
How do the books drift when humans mark payments paid?
One optimistic click at a time. Each manual mark is a small, well-intentioned lie, and they compound in a predictable sequence:
- Week 1 — the accommodating mark. A renter’s card declines. He calls: “I transferred it, check your bank tonight.” You mark the week paid so the account looks clean. The transfer arrives short, or Thursday, or never — but your system already says paid, so nothing chases it.
- Week 4 — the invisible arrear. Marked-paid weeks appear in revenue and disappear from every failed-payments list. Your collections process — retries, pay-links, escalation (see the rental collections process) — never fires, because as far as the system knows there is nothing to collect. Unmanaged payment failure is already how subscription businesses lose ~9% of revenue (Baremetrics); manual marks make the losses unfindable on top of unmanaged.
- Month 3 — reconciliation breaks. Your system says $61,000 collected; the bank says $58,400. The $2,600 gap is spread across a dozen optimistic clicks nobody remembers, with no marker distinguishing real collections from hopeful ones. The only fix is re-checking every payment against bank lines by hand — the exact work the system existed to eliminate.
- Month 6 — decisions on fiction. Utilisation and revenue-per-car reports include the phantom weeks, so cars look more profitable than they are, and pricing and fleet decisions inherit the error.
Why is fabricated revenue worse than missing revenue?
Because other people’s money is computed from yours. A missed payment is a known hole; a fabricated one is an error that propagates outward:
| Downstream consumer | What a manual “paid” does to it |
|---|---|
| Investor payouts | Payouts are net revenue × share. A phantom $350 week on an investor’s car pays out ~$210 of money that never arrived — from your pocket, or clawed back later with an awkward conversation. |
| Tax (GST) | Consumer-facing rental totals are GST-inclusive; every dollar recorded as revenue carries an extractable GST component on its invoice. Fabricated revenue means remitting tax on money you never collected. |
| Collections | The debt vanishes from arrears lists, so nothing and no one chases it. The renter learns declines carry no consequence. |
| Audit trail | A provider-confirmed payment has an external record — a charge ID, a settlement, a bank line. A manual mark has a click. In a renter dispute or a tax review, one is evidence and the other is an assertion. |
The investor row deserves emphasis if you grow with outside capital. The entire investor profit-share model rests on the operator’s revenue numbers being verifiable — and a payout ledger contaminated by manual marks is unverifiable by construction. You cannot offer transparent per-vehicle reporting on top of a status field anyone can edit.
What about money that genuinely arrives outside the system?
Record it — with evidence, as its own event. This is the legitimate case behind the feature request: renters do sometimes pay by bank transfer or cash, and refunds do sometimes happen through a provider dashboard or a bank. The answer is not a status toggle; it is an evidence-attached record:
- Out-of-band income: recorded as a distinct offline payment against the booking, with the proof attached — the bank statement line, the deposit receipt — plus who recorded it and when. The invoice it generates looks like any other; the difference is the record says “here is the proof”, not “trust the click”.
- Out-of-band refunds: the original payment stays paid (it was collected); the refund is recorded as a manual refund with a mandatory evidence file and a reason. In Carz this is enforced structurally: the manual-refund flow requires an uploaded evidence document and is only available when an automatic provider refund isn’t possible — it can never become the lazy shortcut around a real refund.
- Money you will never collect: a write-off — an explicit, dated, attributed decision to stop pursuing a debt. Painful and honest, unlike marking it paid, which is painless and false.
The pattern across all three: every deviation from the normal rails leaves a separate, evidenced record, and no one ever edits history. Your books stay append-only where money is concerned.
How do you run an operation this way in practice?
The discipline only holds if the system makes the right thing the easy thing. Four checks for your own setup — or for software you are evaluating:
- No paid/failed toggle exists. Not “discouraged” — absent. If the button exists, a busy Friday will find it.
- Webhooks drive status, end to end. Charges settle when the provider says so, including async rails where the verdict arrives later (Stripe and Square both report this way; your system has to actually listen).
- Failed stays visible until money moves. Arrears remain on collection lists until a real settlement clears them — a recovered arrear is settled by a new confirmed payment, not by editing the failed one.
- Offline money demands evidence. Manual payment and refund records require an attachment and an author. If your current tool lets you record cash with no proof, your future self is the one who pays.
This is precisely how the payments layer in Carz is built — status from webhooks only, evidence-gated manual records, write-offs as explicit events — because reconciliation you can trust is not a reporting feature you bolt on later; it is a property of never having let the data lie.
The bottom line
“Mark as paid” feels like a convenience and is actually a hole in the hull. Paid means the provider confirmed money moved; anything else is hope wearing a status. Let webhooks own the verdict, record out-of-band money with evidence, write off what you truly cannot collect — and your revenue, your investor payouts and your tax numbers stay something you can stand behind without re-checking a single bank statement.
Frequently asked questions
- What does “provider-derived payment status” mean?
- The payment provider — Stripe, Square, your bank rail — is the only party that knows whether money actually moved. Provider-derived status means your system sets a payment to paid or failed exclusively from the provider’s confirmation (its webhook), and no screen anywhere offers a human a “mark as paid” button.
- How do I record a renter who paid me in cash or by bank transfer?
- As an out-of-band payment with evidence attached: the deposit slip, the bank statement line, a receipt — stored against the booking with who recorded it and when. The record says “money arrived, here is the proof”, which is categorically different from flipping a provider charge to paid.
- What is wrong with marking a failed charge as paid if the renter promises to pay?
- A promise is not money. Marking it paid removes the debt from every list that would remind you to collect it — the arrear becomes invisible, ages silently, and typically surfaces months later as an unexplained shortfall. Keep it failed until money confirmably moves.
- Does this apply to refunds too?
- Yes. A refund processed outside the provider should be recorded as a manual refund with mandatory evidence (proof the money went back), never by editing the original payment’s status. The original stays paid; the refund is its own documented event against it.
Cristobal Galilea
Co-founder, Carz
Cristobal builds Carz alongside the operators who use it — fleet software for independent car-rental businesses leasing weekly to gig drivers in Australia.