Payment pattern
Authorize the cap. Capture what was earned.
A card rail can authorize a maximum before work starts, then let the buyer’s payment stack capture only the amount a signed Outcome Receipt says was earned.
The cleanest card-rail pattern separates a spending limit from the final charge, and it splits three roles. Authorization sets the ceiling. Spoolis determines what was earned and records it in a signed Outcome Receipt. The buyer’s payment stack decides whether and how to capture that amount, then the issuer releases the rest of the authorization.
The worked example: the buyer’s payment stack authorizes $500.00 for 50 units at $10.00 each. Spoolis accepts 47 units, so the Outcome Receipt records $470.00 earned. The stack captures $470.00 and the issuer releases the remaining $30.00.
See the simulated card-rail walk →
Authorization sets the ceiling
An authorization is not a verdict on the work. It asks the issuer to reserve spending capacity up to a maximum amount. In this example, that cap is $500.00.
The cap matters because the seller can see the maximum available before starting, while the buyer does not have to decide the final amount before the outcome exists.
Verification supplies the earned amount
The agreement defines the work and its acceptance rules before delivery. After the work arrives, Spoolis runs the agreed verification plan. Deterministic checks and named human confirmation are live today. AI-assisted evaluation is planned and not live.
The result is a signed Outcome Receipt recording $470.00 earned from a possible $500.00. Its signature lets another system check that the receipt is genuine and unaltered. It does not grant payment authority, prove the evidence was true, or prove that a capture occurred.
The buyer’s payment stack captures the receipt amount
Once the buyer’s payment stack verifies the receipt and applies its own policy, it can read $470.00 as the capture amount. The stack, not Spoolis, sends the capture instruction through the card rail. The issuer then releases the unused $30.00 from the original authorization.
- Authorize: the buyer’s payment stack requests a $500.00 cap.
- Verify: Spoolis checks the delivered work against the agreed criteria.
- Read: the signed Outcome Receipt records $470.00 earned.
- Capture: the buyer’s payment stack requests a $470.00 capture and the issuer releases $30.00.
The stack owns the rail integration, replay protection, amount checks, timing, and failure handling.
Why the remainder is explicit
Calling the $30.00 remainder “not earned” keeps the economic result clear. Calling it “refunded” would imply it had already been captured. In this pattern, the buyer’s stack captures $470.00 from the $500.00 authorization, and the issuer releases the uncaptured $30.00.
The distinction also keeps the receipt honest. It records the verified earned value, not a claim about the issuer’s final ledger state. A downstream integration must observe its own payment result before it can say the capture or release completed.
What is live and what is illustrative
Spoolis can compile acceptance criteria, run deterministic checks, record named human confirmation, calculate earned value, and sign an Outcome Receipt. Spoolis is non-custodial. It does not hold funds, authorize spending, capture charges, release authorizations, or move money.
The generic card-rail flow on this site is a sandbox illustration only. It has no real rail integration and names no issuer. AI-assisted verification remains planned and not live. The card-rail walkthrough shows the boundary end to end without presenting simulated payment state as a real transaction.