Payment lifecycle
The canonical flow from intent to Proof-of-Payment, seen from the merchant.
A payment in Tekmerion moves through a fixed sequence: a merchant's business request becomes a deterministic deposit address, a customer deposits, the deposit is observed and screened, the merchant's decision is executed on-chain, and the result is finalized and proven. Each stage is observable. None of the intermediate states is the source of truth — the blockchain is, and the signed Proof-of-Payment derives from it.
The intent
A payment begins with a payment intent: a merchant's request to be paid for an order. An intent is not a payment. At creation, a deterministic deposit address is computed and fixed — it is known before any contract exists at that address. One intent has exactly one deposit address, identified by its payment_intent_id. Every attempt to pay the same intent resolves to the same deposit address.
Checkout and deposit
The customer selects a chain and token; a payment attempt fixes the expected amount for that selection against a price snapshot. The deposit address is then presented, either for a direct transfer from the customer's own wallet or for an in-checkout transfer from a connected wallet. Both paths converge on the same deposit address, and the flow downstream is identical.
Tekmerion never holds the funds. The deposited balance rests at the deposit address — an address that carries no contract code until the moment of settlement.
Observation and confirmation
The deposit is observed on-chain and accumulates confirmations. At the network's observed threshold, the compliance pipeline begins. At the network's finality threshold, the outcome becomes canonical. Until finality is reached, observations are reorg-sensitive and may be corrected. Confirmation thresholds are per-chain — see Supported chains and tokens.
Compliance
Once the deposit is confirmed, a fixed compliance sequence runs — sanctions screening, then the merchant's transaction-level decision (which receives the session-level geoblock result as context). The decision to sweep or refund is structurally the merchant's; Tekmerion screens but does not override. See Compliance pipeline.
Settlement or refund
On the merchant's decision, Tekmerion relays the merchant's signed authorization and the blockchain executes it through a one-shot proxy at the deposit address: a sweep to the merchant's approved destination, or a refund to a merchant-supplied destination. See Sweep and refund.
Finality and proof
At the finality threshold, a canonical finality_outcome is published — paid, refunded, failed, or duplicate_payment. A paid outcome produces a signed Proof-of-Payment; a refund, failure, or duplicate does not. A payment_finalized notification is delivered as a side effect of this outcome.
A notification is not the truth. Reconcile a payment through the API and the Proof-of-Payment artifact, never solely through receipt of a webhook. See Statuses and projections and the Event catalog.
On-chain truth has priority
Expiry bounds the expected flow, not on-chain truth. A deposit observed after an intent has expired is still processed through the same pipeline, and a late, confirmed, approved payment can still settle. A payment status that reads EXPIRED is therefore a statement about the expected window, not a guarantee that no payment will arrive.