Edge cases

The payment model holds at its edges because it rests on on-chain truth rather than on the expected flow. Late deposits, amount discrepancies, duplicates, and chain reorganizations are not errors — they are defined conditions with deterministic handling. In every case, what a deposit is on-chain governs the outcome; what was expected does not override it.

Late payments

expires_at bounds the expected window of an intent, not on-chain truth. A deposit confirmed after the intent has expired is observed and processed through the same pipeline as any other, and a late, confirmed, approved payment can still settle.

A status of EXPIRED therefore states that the expected window elapsed without a confirmed deposit — not that no payment will ever arrive. On-chain truth has priority after expiry. See Statuses and projections.

Overpayment and underpayment

Amount is never a matching criterion. A deposit is correlated to a payment by address, chain, and token — not by how much arrived. Matching succeeds whether the amount is more, less, or exactly the expected amount.

• Overpayment. Settlement acts on the full balance at the deposit address, so the merchant receives the entire deposited amount, including any excess. Tekmerion does not return the excess on its own.
• Underpayment. Matching still succeeds, and the deposit is presented to the merchant for a compliance decision like any other. The merchant decides whether to accept or reject it.

In both cases the discrepancy is informational and merchant-owned: it is surfaced to the merchant, and how a shortfall or overage is reconciled against fulfillment is the merchant's policy. Tekmerion does not split, withhold, or auto-correct amounts.

Duplicate payments

An intent settles at most once. When more than one finalized, matched payment exists for the same payment_intent_id, exactly one is the canonical winner. The winner is chosen deterministically — independent of arrival order, delivery order, or timing — so the same set of payments always yields the same winner.

The winning payment settles the intent. Every other finalized match is recorded with finality_outcome duplicate_payment and is not an additional settlement. There is no automatic refund of a duplicate; returning a duplicate is a merchant-directed action.

A duplicate surfaces on the status projection as FAILED with finality_outcome duplicate_payment. This does not mean the payment failed — it lost winner selection for an intent that is already PAID. Correlate by payment_intent_id, not by a per-attempt status. This caveat is detailed in Statuses and projections.

Reorganizations

A chain can reorganize, changing what was observed. The finality threshold is the line that divides corrective handling from canonical handling:

• Before finality. Observations are reorg-sensitive. If a reorg alters the chain, the observed data is corrected, and no outcome has yet been fixed.
• After finality. The outcome is canonical. A reorg occurring after a payment has finalized does not silently roll the outcome back; it is detected and recorded for resolution rather than reversed automatically.

The confirmation thresholds that define this line are per-chain and documented in Supported chains and tokens.