Payment paths

How a path is chosen

The referee first validates that the amount is a non-negative safe integer and the currency is a three-letter uppercase code. It then considers the actor, configured adapters, adapter readiness, and the buyer's declared machine capabilities.

• In demo mode, it chooses the simulated adapter. Demo is a mode, not a rail, and no money moves.
• For a person, it chooses a configured production adapter that supports human payment methods.
• For an agent, it requires a configured machine adapter whose declared capability matches the buyer and whose readiness is production.

valid input + compatible configured production path -> choose path
no qualifying path -> return refusal + reasons

Honest refusal

The referee does not switch actors, custody models, or environments to make a transaction appear supported. It refuses when no machine adapter is configured, the buyer did not declare a matching capability, a matching adapter is not production ready, or no production adapter supports the person's payment method. Simulated settlement is never a fallback outside demo mode.

The payment layer model

1. Outcome Receipt: the signed Spoolis record of what was earned.
2. Authorization: the buyer or payment authority decides what may be spent.
3. Execution: the buyer's wallet, marketplace, payment rail, or configured adapter moves or records value according to its own rules.

The lower-level in-band attestation is an implementation detail that supports the Outcome Receipt. Spoolis is non-custodial. It does not hold funds or become the wallet, payment provider, or settlement network.

How payment acts on the result

External systems can verify or read the Outcome Receipt and act on the result themselves. Where supported, configured adapters may automate execution. Unsupported flows fail closed, with no silent substitution of another payment rail.