A payment is a chain of evidence.
From intent to settlement: what each state means, who can confirm it, and how uncertain outcomes recover.
Merchant request
The merchant records 2,500.00 HTG for a synthetic order. Identity, membership, amount and asset are checked before the request is accepted.
Intent → attempt → verified outcome
A payment intent represents the merchant’s requested amount, asset and order reference. A payment attempt binds execution to a provider connection and a stable provider reference. A redirect can authorize the customer journey; it cannot confirm success.
An authenticated provider lookup or verified event establishes an outcome after account, reference, amount and asset checks. Confirmation updates the attempt and intent, records the journal and receipt, and queues downstream work within the service’s transaction.
Unknown is a real state.
A timeout after a mutating provider request may mean that the provider acted but the response was lost. The result stays unknown. An unresolved attempt blocks another charge until lookup or reconciliation resolves it. A retry must not quietly switch rails.
Late confirmation after cancellation or expiry is surfaced for review. Duplicate verified events must not create duplicate journals. Reversals are represented explicitly and preserve original history.
Paid and settled are separate facts.
A confirmed customer payment can still await provider settlement. Statement matching may produce matched, short, over or exception states. A short settlement does not rewrite the original customer payment.