Prepayments Explained: Deposits, Advances, and the Trust Problem Hiding Inside Every 'Pay First'

·4 min read

A prepayment is money paid before delivery — deposits, retainers, advances, subscriptions. Useful everywhere, and always carrying the same hidden question: who holds the money, and what protects the payer? The full map of prepayment types, the trust mechanics under each, and the architecture that finally split 'committed' from 'surrendered'.

Contents
  1. 1The prepayment family, sorted by what they secure
  2. 2The trust mechanics under each rail
  3. 3The fourth posture: committed but not surrendered
  4. 4FAQ

The short answer: a prepayment is money paid before the goods or service arrive — deposits securing a booking, retainers securing availability, advances funding work, subscriptions paying the month ahead. Commerce runs on them, because they solve the seller's risk: commitment before cost. But every prepayment carries a mirrored question nobody prices explicitly: the payer's risk — the money is gone now, the delivery is a promise, and between the two sits whoever holds the funds. Traditional rails answer with reversibility (cards) or trust (everything else). The interesting recent development: an architecture that splits "committed" from "surrendered" — funds locked for a purpose but still under the payer's control until each delivery earns its charge. The full map below.

The prepayment family, sorted by what they secure

Deposits secure a slot — the booking, the table, the custom order — partial payment as proof of seriousness, with the balance following delivery. Retainers secure availability — professional time reserved whether used or not. Advances fund the work itself — manufacturing runs, project mobilization. Subscription prepayment buys the period ahead — the month you're always one payment into. Accounting sees them all as the same object (payment recognized before delivery — the prepaid expense on one side, deferred revenue on the other, with the public ledger making both trivially auditable); commerce sees four different trust postures — which is where rails start to matter.

The trust mechanics under each rail

Prepay by card, and the payer's protection is the chargeback — real but blunt: it protects by making every settlement provisional, which merchants pay for across the board. Prepay by bank transfer, and the money is simply gone until delivery or goodwill — pure counterparty trust, which is why large advances travel with contracts and escrow agents. Prepay by crypto transfer, and finality applies: the deposit is final, the refund is the merchant's deliberate act — cleaner for honest parties, demanding the usual upstream diligence. Three rails, three postures: provisional everything, trust everything, final with diligence. For decades those were the only seats at the table.

The fourth posture: committed but not surrendered

Here's the structural news worth the article: vault-based subscriptions create a prepayment class that didn't exist before — the payer funds a vault they control; the terms are welded into the vault's on-chain address; each period's charge executes automatically; and cancellation returns every unspent cent, deposit included. Read it against the family above: it's a prepayment (the service sees committed funds and charges without asking), and it isn't (the payer never surrendered custody of the unearned balance). The seller gets what deposits were invented for — commitment; the payer keeps what prepayment always cost — control. The trust problem doesn't get managed; it gets removed. That's the difference between a policy and an architecture, and it's the reason "pay first" stops being a leap.

FAQ

What is a prepayment, simply?

Money paid before delivery — deposits, retainers, advances, subscription periods. The seller's commitment device, the payer's trust exposure, in one transaction.

What's the difference between a deposit and a prepayment?

A deposit is one member of the family — partial prepayment securing a slot, balance to follow. All deposits are prepayments; prepayments also include full advances and period billing.

Are prepayments refundable?

By policy, not by nature — the rail decides the mechanics: card prepayments can be disputed, bank prepayments rely on goodwill, crypto refunds are merchant-initiated, and vault balances return automatically on cancellation — the one class where refund is structural.

How do businesses account for prepayments?

Received prepayment is deferred revenue until earned; paid prepayment is a prepaid expense until consumed. On-chain settlement gives both sides a timestamped, auditable record — the bookkeeping's raw material, public.

How do I take a deposit in crypto?

Two payment links — deposit and balance — each with its own address and clean record: staged invoicing with reconciliation built in.

Is a subscription a prepayment?

Classically yes — you're always one period ahead. The vault version inverts the custody: committed funds, payer-controlled, charged per period — prepayment's benefits without its surrender.

What protects me when I prepay a stranger?

Rail-dependent: dispute rights on cards, contracts on bank rails, upstream diligence on final rails — and where the seller offers it, the vault posture protects structurally: unearned money never leaves your control.

Why do merchants ask for prepayment at all?

Because their risk is real too: custom work, reserved capacity, no-show costs. The deposit is the honest price of commitment — the question was only ever who holds it in the meantime.

Do prepayments earn interest for the merchant?

Held prepayments are float — the same working-capital asymmetry as settlement delays, tilted toward whoever holds. Vault architecture returns the float to the payer, where unspent money arguably belongs.

What happens to my prepayment if the business fails?

On held-funds rails: you're a creditor in a queue — the custody risk in its starkest form. On vault rails: the unspent balance was never theirs to lose — the failure case is precisely what the architecture was built for.

Can prepayment terms be enforced automatically?

That's the vault's defining trick: terms live in the on-chain address itself — charge size, cadence, cancellation — enforced by the settlement layer, not by policy. The contract and the rail become the same object.

Prepayment was always a good idea wearing a bad trade: commitment for the seller, surrender for the payer, trust holding the gap. The family map above sorts the classic postures — and the fourth one retires the trade: committed but not surrendered, terms in the address, unspent money always yours. If your business runs on deposits, retainers, or periods paid ahead: the architecture is fifteen minutes away, and the trust problem doesn't come with it.

Related reading