Parking-Space Asset Custody

Context

A parking space is a silent asset: the owner has one but does not use it, the property manager wants to operate it but lacks a system. Custody turns this into a three-party arrangement — the owner entrusts the space, the platform operates it and splits revenue, the tenant pays monthly.

Party	What they care about	What the system holds
Owner (principal)	Is the space rented, how much is paid out monthly	Custody contract, bills, split records
Platform (operator)	Listing efficiency, fulfilment risk, reconcilable books	Space pool, lease contracts, bills and reconciliation
Tenant	Price, term, deposit, renewal	Lease contract, renewal, move-out and deposit refund

All three share one copy of the space and contract data but see different slices — that is where most of the permission and presentation work on this line goes.

What the system does

Stage	Capability
Custody	Contract entry, review and activation; bind space and owner
Listing	Available spaces; rules for price, minimum term, deposit
Signing	Online signing; rent + deposit + service + property + space-management fees in one payment
Fulfilment	Renewal (extending), move-out request, admin review, deposit refund
Settlement	Split recipients and ratios, per-transaction split, bills and reconciliation

What I built

Signing is the most error-prone stage: one payment splits into five fee types going to different accounts; a renewal must extend the original expiry rather than restart today; a move-out must pass review before a refund fires. I consolidated the state transitions and amount calculations into one explicit state machine on the backend, so the frontend only renders and navigates instead of recomputing.

On the console I added split-recipient and ratio configuration, the deposit-refund review entry, and unified maintenance of contract details (counterparty, agreement name, brand).

Money and states

Custody money is not “one order, one amount”; five fee types each keep their own books:

Signing payment ──split──┬─ rent            → apportioned to bills by lease period
                         ├─ deposit         → refunded after move-out review
                         ├─ service fee     → platform revenue
                         ├─ property fee    → belongs to the property manager
                         └─ space fee       → belongs to the lot

Each type has its own refund and reconciliation rules, which is why the system keeps three layers — contract, order, bill — instead of piling fields into one table. State machines are layered too: a contract is pending / active / expired / terminated, a bill is unpaid / paid / refunded, an order is pending / succeeded / closed. Any change in one layer must explain why the other two did not change.

Engineering notes

• Every amount is traceable: any split traces back to contract, order and payment record
• State machines, not scattered checks: contract, order and bill each own their state
• Configured settlement: ratios and recipients live in the console, so business changes need no release
• Three-party view isolation: owner, platform and tenant see different slices of the same data, trimmed by the API rather than hidden in the UI

Team and scope

The team owns the space pool and listing, custody contract review, bills and reconciliation reports, and payment and split integration. I own the signing and renewal endpoints and mini-program flow, move-out review linkage, the split configuration page, and unified contract details.