← All guides · JSON · Observatory
Merchant-Hosted Checkout Path
Decision guide for discovery-first integration where merchants retain checkout control.
Audience: Commerce architecture and payments teamsUpdated: 2026-03-25Pivot signal: 2026-03-24
Default architecture
- Use AI surfaces for discovery and qualification, then route users to merchant checkout for transaction completion.
- Treat checkout as a controlled, merchant-governed trust boundary.
- Keep checkout policy enforcement (fraud, KYC, tax, loyalty, returns) in merchant-owned systems.
Checkout lifecycle (implementation reference)
- Use a deterministic session lifecycle: create -> update -> retrieve -> complete -> cancel.
- Apply idempotency keys on create/complete operations to prevent duplicate charges.
- Emit webhook events for status transitions and reconcile asynchronously.
- Persist a correlation ID linking discovery event -> checkout session -> final order.
Decision tree
- If your existing checkout already handles identity, loyalty, fraud, and tax, keep merchant-hosted checkout as primary.
- If discovery conversion is low, improve catalog/feed quality first before changing transaction architecture.
- If settlement or compliance complexity is high, harden policy and observability before enabling expanded checkout paths.
- If SLA requirements are strict, isolate checkout endpoints from content endpoints and monitor independently.
Readiness signals
- Stable product IDs and canonical URLs.
- Reliable availability and pricing freshness.
- Documented attribution path from discovery event to checkout completion.
- Session-level idempotency and replay-safe webhook processing.
- Runbook for cancellation, timeout, and inventory re-lock edge cases.