Go-live checklist

Work through this before the first live payment. Each item links to the page that fixes the details.

Identity and configuration

• An organization and a merchant exist, and you have stored the merchant_id. See Organization and merchant.
• An active receiving profile records your primary settlement wallet for each chain you accept. See Receiving profile and whitelist.

Authorisation and whitelist

• A factory authorisation is signed for every chain you accept, bound to that chain's factory by the domain separator. See Factory authorisation.
• The signed allowed_destination_whitelist is final and contains every address you may ever return as sweep_to or refund_to. A target outside it is rejected on-chain. Adding an address later requires signing a new authorisation that supersedes the current one.
• allowed_action_types includes both deploy_sweep and deploy_refund if you intend to both settle and refund.

KYT endpoint

• Your KYT endpoint is registered and active, and answers within sla_seconds (default 60). See KYT endpoint setup.
• Your endpoint verifies X-Tekmerion-KYT-Signature (v1=<hex>) and X-Tekmerion-KYT-Timestamp before acting, using constant-time comparison. See Verifying requests.
• On approve you return a sweep_to that is in the whitelist; on reject you return a refund_to that is in the whitelist. See Response contract.
• You have chosen default_on_timeout deliberately and understand its consequence — auto_approve_to_main and auto_refund finalize a payment without your review; hold finalizes nothing. See SLA and timeouts.

Notifications and credentials

• At least one notification endpoint is enabled, with an active signing secret. See Notification endpoints and API keys.
• Your receiver verifies X-Tekmerion-Signature (v1=<hex>) and X-Tekmerion-Timestamp before processing the payload, using constant-time comparison. See Signature verification.
• You deduplicate notifications by delivery_record_id and acknowledge quickly. Delivery is at-least-once and unordered. See Delivery semantics.
• One merchant API key is active and stored securely. See Authentication.

Reconciliation and edge cases

• You treat a notification as a prompt to reconcile, never as the source of truth. The authoritative outcome is the signed Proof of Payment, cross-checked against the on-chain transaction. See Proof of Payment and Verifying a PoP.
• You handle every finality_outcome on a payment_finalized notification: paid, refunded, and failed. See Event catalog.
• You handle the duplicate-payment case correctly. A duplicate deposit on a payment_intent_id that is already PAID produces a separate duplicate_payment_incident notification — reconcile it, do not treat it as a new settlement. Independently, the API status projection can show an attempt as FAILED carrying finality_outcome duplicate_payment: this is not a failed payment — it means a losing attempt was deduplicated while the intent is already PAID. Resolve the intent's true state from the Proof of Payment. See Statuses and projections.