Going Live

Moving an Agentic Commerce integration from sandbox to production. The universal launch checklist lives at For Destinations → Going Live; the list below adds the agentic-specific requirements — consent, protocol wiring, and autonomous-purchase checks. Review both end-to-end before pointing real buyer traffic at Firmly.

​​ Before you ask for production access

Run through each of these against your sandbox build. Anything you can’t check off is a launch blocker.

​​ Credentials & authentication

• You can swap the sandbox App ID for the production ID without code changes — the ID is config, not hardcoded
• Authentication strategy chosen (browser session or server-to-server) and your client correctly handles token expiry (browser sessions ~1 hour)
• Session tokens are stored server-side, never in client JavaScript or URLs
• No sandbox card numbers (4111111111111111, etc.) hardcoded — production rejects these

​​ Cart lifecycle handling

• Your code reads cart_status on every cart response and branches on active, checkout_blocked, item_not_shippable, submitted — see Cart Lifecycle
• You renew the session token when it expires (~1 hour) and re-bootstrap cleanly; idle carts are garbage-collected after ~7 days of inactivity, so your code rebuilds the cart if it’s gone
• You handle the case where stock changes between discovery/search and complete-order — see Errors → Stock changed mid-conversation

​​ Error handling & recovery

• You’ve integrated against the full Errors & Conventions catalog — not just happy-path responses
• You do not silently retry CreditCardDeclined (payment declines) with the same card — surface the failure to the user and offer alternatives
• You map technical errors to natural language for the user — “the medium is sold out — small or large?” not “NotEnoughStockError”
• You send idempotency keys on complete-order and other mutating writes — and on the core REST endpoints (which don’t deduplicate on the key today) you re-read cart_status before any retry
• Retries use exponential backoff, respect Retry-After headers, and have a maximum attempt count

​​ Rate limits & throughput

• You understand the rate limits for each endpoint you call
• Your destination handles 429 responses gracefully — back off, don’t hammer
• If you’re doing large-scale discovery (e.g. price-monitoring), coordinate throughput with Firmly ahead of launch

​​ Consent & disclosure

• Consent & Disclosure requirements are wired into your agent’s flow — the user reviews and confirms order details (item, price, total, shipping, payment) before you call complete-order
• The merchant’s identity is surfaced to the user before checkout — they know who they’re buying from
• Your privacy policy and terms reference Firmly as the commerce backend where applicable

​​ Production data hygiene

• No customer or partner names appear in your logs, prompts, or telemetry without their consent
• PII (names, addresses, card data) handled per your jurisdiction’s rules — Firmly tokenizes card data; your destination should never see raw card numbers
• Sandbox test data (test merchant domain, test cards, test addresses) doesn’t leak into your production prompts or test fixtures

​​ Protocol-specific

If you’re using a structured protocol rather than direct REST:

• UCP, MCP, or ACP wired against the sandbox host api.firmly.work — repoint to the production base URL Firmly provides at go-live
• Your agent stack’s tool definitions reference the current schema — see Schemas

​​ Autonomous agent purchases (if applicable)

If you’re using Agentic Pay for autonomous (cardholder-not-present) purchases:

• Mandate scope is per-merchant, per-amount, with an expiry — not unbounded
• Network-token enrollment is sandbox-verified for each card you intend to use in production
• You have a recovery path for intent-challenge responses — a network step-up (additional cardholder verification) the card network can require before authorizing an autonomous purchase

​​ What changes between sandbox and production

The host and SDK don’t change. The only operational change is your App ID — your code paths against the API surface should already work identically.

​​ Your first production call

1. Swap the sandbox _appId for the production _appId in your config
2. Run a single end-to-end test against a real merchant with a real card (your own, not the user’s). For a physical-goods SKU, run the full sequence: browser-session → discovery/search → add-line-item → set-shipping-info → set-shipping-method (picking from the shipment’s shipping_method_options; optionally call get-availability first for scheduled-delivery dates / time slots) → get-consents / set-consents (if the merchant requires them — skipping required consents makes complete-order return RequiredConsentsNotSigned (412)) → get-payment-public-key → complete-order (this sequence builds the cart, so it finalizes with complete-order; use place-order only for the one-shot create-cart-and-order call). For a digital SKU with no shipping, the shipping steps can be omitted — see the single-product flow for the canonical tail
3. Verify the order lands in the merchant’s system (Firmly will help confirm)
4. Roll out to buyer traffic incrementally — canary first, then full ramp

If anything fails the first end-to-end test, fall back to sandbox immediately and reach out to Firmly before retrying production.

​​ When to talk to Firmly

You don’t have to wait until everything’s checked off to engage. Reach out for:

• Production App ID provisioning
• Merchant set scoping (which merchants you’re routing to)
• Throughput planning if you expect bursty traffic
• Custom protocol behavior or non-standard error handling needs
• A pre-launch review walkthrough — Firmly’s team can sanity-check your integration before you flip

See Contact for the support email.

​​ Related

• Sandbox setup — the prerequisite before any of this
• Errors & Recovery — agentic-specific patterns
• Errors & Conventions — full error catalog
• Cart Lifecycle — cart_status state machine
• Idempotency — required for production-grade writes
• Rate Limits — what to expect under load
• Consent & Disclosure — user-facing requirements
• Agentic Pay — for autonomous (cardholder-not-present) purchases