Storage payment software: automated billing over a ledger nobody can edit.

It has to be a document with lines, not a balance with a date on it. Rent for a period, a stage fee raised by the past-due process, a manual charge from the site catalogue and a prorated adjustment are separate obligations, and a customer disputing one of them is not disputing the others.

Invoices carry line items and allocations, so the answer to what this money was against survives being asked six months later. Proration covers the case spreadsheets get wrong most often: a change on the eleventh of the month is not a full month and is not free. Manual fees are raised from the catalogue the site already maintains rather than typed as free text, which is what keeps a fee reportable rather than anecdotal.

• Invoice a customer with itemised lines rather than a running total.
• Prorate a mid-period change instead of rounding it to a whole month.
• Raise a manual fee from the catalogue the site already maintains.
• Take a manual payment or a Stripe card payment against the same record.
• Save a card and run autopay, with the consent recorded separately.

Explicitly, across the lines it settles, and the allocation is stored rather than inferred. A tenant who owes rent for two periods and a late fee, and who pays part of it, has produced a fact the system has to be able to reconstruct: which obligation is now satisfied, and which is still outstanding.

The alternative, subtracting the payment from one balance figure, feels simpler until somebody asks whether the rent for last month was ever paid. It also turns arrears work into guesswork, because a past-due process needs to know what is unpaid and since when, not merely that a number is greater than zero.

Every payment attempt is a recorded operation with its own key, and the key is what the system charges against: not the click, not the webhook delivery. A staff member who presses the button twice, a background job that runs again after a crash and a gateway that re-delivers the same event all converge on the operation that already exists.

Webhook deliveries are claimed durably, so a crashed worker reclaims its own work rather than a second worker processing the same event alongside it. Double-charging a storage tenant is not a rounding error. It is a refund, an apology, and a customer who checks every statement from then on.

The decline becomes visible work with a category attached, so a card reported lost is not treated like a card with no funds this morning. Failures land beside the customer, invoice and rental context in the operations queue that computes the day of work, rather than sitting in a gateway dashboard nobody opens.

Restarting collection is an act by a person, and there are exactly two ways it happens: a member of staff deliberately restarts automatic collection, or the tenant saves a new card in the portal, which is their own way of asking for collection to resume. Both are recorded with the actor, and with how many consecutive failures were set aside. The nightly worker never writes one, which is the point.

An invoice describes an intention; the ledger records what happened. Ledger entries cannot be edited or deleted, and that is enforced at the database as well as in the application, so a correction has to be a further entry rather than a quiet amendment to an old one. Four financial test files are frozen by checksum precisely so that no future build can weaken those guarantees invisibly.

Closed accounting periods finish the picture. Once a period is closed, postings into it are refused and who closed it is recorded, so the figures for last quarter do not move after they have been reported. That is slightly less convenient than editing history, and considerably easier to defend.

What the accountant receives follows the same caution. Financial delivery to Xero gets one automatic initial attempt and no automatic retries, so a failure becomes manual review rather than a queue draining quietly in the wrong direction.

No, and treating the two as synonyms is the most common misunderstanding in this part of a storage stack. Autopay here is a scheduled attempt against a card the customer has saved, with their consent recorded separately. Direct Debit is a bank mandate with its own scheme rules, its own failure semantics and its own notice obligations. A card attempt on a schedule is not a mandate and does not behave like one.

So the boundary is stated rather than blurred. There is no Direct Debit, because no charging adapter exists for one. There is no card-account updater and no network tokens, so a card that expires or is reissued stops working until the customer saves a new one; that instrument lifecycle work is in development and is kept deliberately separate from autopay consent, since consent to be charged and the ability to charge are different questions. There is no retry optimisation and no gateway failover: one gateway, and a decline is handled as work.