Integration checklist

Phase-by-phase checklist from evaluation through post-launch. Use it as a shared tracker for your engineering, QA, and ops teams. For formal test cases and evidence format, see Certification. For cutover steps, see Go-live.

• Read Seller API overview and Quickstart and confirm the Seller API fits your storefront model
• Confirm you will charge buyers at your payment processor — Avrix never auto-refunds
• Confirm key-delivery fulfilment (deliveryMode: "key") and durable key persistence before buyer UI
• Confirm vendor commercial prerequisites (BMA / share / allocations) with your commercial contact

• Seller company in Console with Integrations → API Keys visible
• Create a sandbox key with least-privilege scopes for checkout
• GET /health returns 200
• GET /whoami returns environment: sandbox, expected scopes, and hasActiveBma as expected for the shared sandbox catalog
• Register a webhook endpoint; verify test.ping signature

• Cold-start sync: snapshot (or products) plus /allocations merge
• Persist sellable set; treat allocation-only SKUs correctly
• Incremental sync via /catalog/changes with tombstones
• Cache / ETag strategy follows Caching and fairness
• Cases 1–6 from Certification pass

• POST /orders/preview before every charge; gate on canFulfill
• Echo expectedUnitPriceCents (and priceCommitmentToken when returned)
• Stable Idempotency-Key per commercial attempt, stored before the request
• Stable orderReference per fulfilment attempt
• Production-shaped integrationOrderContext even in sandbox — Order context
• Never call Seller API from browser or mobile clients
• Cases 7–14 from certification pass, including unknown-outcome recovery

• Persist keys / redemption identifiers before responding to the buyer
• Webhook signature verification on raw body; reject invalid and stale signatures
• Deduplicate on event id; process asynchronously after fast 2xx
• Missed-delivery recovery via delivery list / replay and GET /orders
• Cases 15–23 from certification pass

• Return / refund path uses keyIds from the order response or order.fulfilled webhook
• PSP refunds owned by your storefront on 409 NO_AVAILABLE_KEYS / order.failed
• Structured logging with requestId
• Alerts on error rate by code and webhook failure
• Reconciliation job scheduled
• Cases 24–29 from certification pass

• Certification evidence submitted and approved
• Production key, allowlist, webhooks, and catalog cold-start complete — Go-live
• Controlled live order verified
• Gradual traffic enablement and 24-hour watch window

• Monitor CATALOG_PRICE_MISMATCH, webhook success, reconciliation drift, allocation depletion
• Key rotation rehearsed
• Re-run certification suite after material checkout changes

• Environments
• Partner runbook
• Sandbox to production