Payment modes

Hold now, take later

Plenty of purchases do not know their final amount when they are authorised. The pattern for that is older than agents: reserve funds, take up to the reserved amount later, release the rest. We use the card networks' own vocabulary for it rather than inventing a parallel one, and add the governance a raw processor API does not have.

• The hold and every capture pass the same decision, not just the hold.
• A capture cannot exceed its hold. That is structural, not a validation rule somebody could skip.
• Every transition is signed into the record.

A hold moves through held, partly captured, captured, voided or expired. Expiry is checked before anything else and releases the remainder automatically. Refusals name the reason: an over-capture, an expired hold, a mismatched asset. Captures are final unless you say otherwise.

Paying as it accrues

Continuous and per-request payment already exist in several forms, so we build neither. What none of them carries is a statement of how a metered spend is bounded, and a decision over the accruing obligation that holds those bounds while value is flowing.

We read accrual off the rail, clamp it, and can stop it. We never hold a key and never move money per second ourselves.

A meter is either fixed or open: a fixed one has a duration, an open one must have a ceiling, and setting both is refused. Exposure counts every live stream at its full ceiling rather than at what it has accrued so far, because the question a limit answers is what could happen, not what has. The instruction to close is declared at the moment the stream opens, so stopping never depends on us being available later.

One payment, several parties owed

An agent that assembles a service from a model, a data provider, some compute and a human reviewer takes one payment and owes four parties. Left private, that arithmetic belongs to whoever is holding the money.

Shares are expressed in basis points and must total exactly one hundred percent. Every share rounds down and the whole remainder goes to a party named in advance, so rounding dust cannot quietly become somebody's margin. A share whose delivery is unproven, or which is owed to a related party, is parked rather than redistributed: withheld value stays withheld instead of enriching whoever is left standing.

All of it, or none of it

A set of payments that only makes sense together has to clear together. Inside one backend that is solved. Across different rails it is not, because no backend is a party to every leg, and a set that half-executes leaves value stranded.

The coordinator sequences a dependency-ordered set across rails, holds each settled leg rather than releasing it, and unwinds in reverse off the signed chain when a later leg fails. The inverses are declared before anything is submitted, so failure is a lookup rather than an improvisation.

The declared order and the stated dependencies have to agree. A set whose order contradicts its own dependency arcs is refused rather than quietly re-sorted, and a cycle is refused outright. Rollback reads which legs actually settled from the signed record, never from the coordinator's own memory of what it thought it did. Where a forward action has no declared inverse, the result is a named residual liability rather than a silent one.

Agreed rather than quoted

Where the price is negotiated between agents, each round is bounded against the mandate and the agreed terms are sealed, so what settles can be compared against what was agreed. We bound the envelope. The bargaining is yours.

Buying before paying

Extending credit to an agent is a different question from allowing one payment. It is answered from the agent's own append-only economic record rather than from an assertion by its operator, because "we do a million a year" is not a refutable statement and a ledger is.