Going Live

Going live for a destination is a clean cutover, not a code rewrite. Your integration uses the same API shapes and follows the same flow. What changes is the App ID you send, the merchants you’re transacting against, and that real money starts moving. Production also runs on different hosts than the sandbox, so the base URLs change too — Firmly provides them at go-live.

This page covers what you should validate before going live, what Firmly reviews, and what to expect in the first hours and weeks of production traffic.

​​ What “going live” actually means

​​ How the cutover works

The cutover is a configuration change on your side — the new App ID. The base URL stays the same; the same Firmly platform serves both environments. What changes is your configuration and the merchants you’re scoped to, not your code.

​​ Pre-launch checklist

Before requesting your production App ID, confirm you have these working in sandbox:

​​ Auth and credentials

• App ID is read from configuration, not hard-coded in source
• Token renewal is implemented — browser sessions expire after ~1 hour; your code handles renewal without dropping user flows
• Server-to-server secrets (if used) are stored in your secrets manager, not in source
• The App ID is never logged or surfaced in error messages

​​ Order placement

• Duplicate-order safety is handled: the core REST endpoints do not deduplicate on Idempotency-Key today, so guard client-side (re-read cart_status before any retry of a cart mutation or the order-placement call — complete-order for a cart built across calls, or place-order for the one-shot path). Send Idempotency-Key on the endpoints that do accept it (UCP bridge). See Errors & Conventions
• Idempotency keys are stable for retry windows — same logical operation, same key
• Order success is validated against the response’s cart_status field (submitted indicates success)
• The merchant’s order identifier is captured for reconciliation

​​ Error handling

• 4xx errors are surfaced to the user with appropriate messaging
• 5xx errors trigger retry with exponential backoff (cap at ~30 seconds — see Errors & Conventions)
• Specific error codes — ucp_disabled, DomainNotFound, decline codes — have specific handling, not generic catch-all
• Payment declines distinguish between hard declines (don’t retry) and soft declines (offer alternative payment)

​​ Observability

• Request IDs are logged so you can correlate with Firmly’s logs during incident review
• Order placement attempts are logged with the idempotency key, merchant domain, and outcome
• A dashboard or log query exists for “orders attempted vs orders completed” so you can spot regressions

​​ Cart and checkout flow

• Multi-shipment carts are handled — shipping method is set per shipment, not globally
• Shipping methods are read from each shipment’s inline shipping_method_options (populated by set-shipping-info), not from get-availability
• get-availability (delivery dates / time slots / pickup) is optional; merchants that don’t support it return 501 NotImplemented, which your code tolerates and skips
• The user’s chosen shipping address is validated client-side before submission to reduce 4xx on /shipping-info

​​ Production readiness

• Your monitoring is wired up — alerts on elevated error rates, failed orders, or auth failures
• Your team knows where to find Firmly request IDs in logs for incident triage
• Rate limits are documented and your code respects them — see Rate Limits
• Outbound network allows the sandbox hosts api.firmly.work and cc.firmly.work. Production uses different hosts — allowlist the production base URLs Firmly gives you at go-live before you cut over

​​ What Firmly reviews

The pre-launch review (Onboarding Phase 3) walks the same checklist from Firmly’s side. Common items the review surfaces:

• Idempotency not being sent on all mutations
• Token renewal not implemented (manifests as 401 errors after ~1 hour of activity)
• Retry storms on 503 — backoff missing or too aggressive
• Test cards still hard-coded — sandbox-only credentials present in code paths that will run in production
• Order success determined by HTTP status alone, not by the response body (a payment decline surfaces as a 422 CreditCardDeclined error, so confirm success against cart_status: "submitted" rather than assuming any 2xx means the order was placed)

​​ After going live

​​ Day 1

Smoke-test with one real production order. Confirm the merchant’s order shows up in their order management system. Watch your error rates for the next hour.

​​ First week

Ramp traffic gradually. Watch order success rates, payment decline rates, and average time-to-order-placement.

​​ First month

Review your funnel and attribution in the Destination Dashboard — your destination identifier should be on every order. Reconcile against Firmly’s reporting if discrepancies appear.

​​ When something goes wrong

​​ What stays stable after go-live

After go-live, your integration is stable. The same App ID continues to work. Firmly may add new merchants to your scope (you get an email; no code change needed) or add capabilities behind feature flags — both are additive. Breaking changes go through advance notice and a deprecation window.

​​ Related

• Onboarding — the full handshake, especially Phase 3 pre-launch review
• Destination Dashboard — track your funnel, orders, and attribution post-launch
• Authentication — auth model details
• Errors & Conventions — error catalog and retry patterns
• Rate Limits — production rate-limit posture