Go-live checklist

Work through this list before you switch your integration to production keys.

Keys#

• Every production key is stored in a secret manager or environment variable, never in code.
• Each system has its own key with only the scopes it uses.
• You have a written procedure for rotating a key without downtime: create the new key, deploy it, confirm traffic, then revoke the old one.
• Test catalogue items created with sandbox keys are deleted — the catalogue is shared between environments.

Requests#

• Your code branches on the error code, never on message.
• You log the X-Request-Id of every failed call.
• You retry 429, 500, 503 and network errors with backoff, and honour Retry-After.
• You do not retry 400, 401, 403 or 404 without changing the request.

Payments#

• Your checkout reads the amount from GET /payments/sessions/{id}, never from the browser.
• You report every outcome — SUCCEEDED and FAILED — with a fresh Idempotency-Key, and reuse a key only to resend the identical request. See Idempotency.
• You check data.status in the response to every result you report.
• A 409 payment_amount_mismatch alerts someone: the customer was charged, but the order is not paid.
• Refunds made in your gateway are recorded with /refund.
• The production checkout URL is saved and enabled in the portal.

Webhooks#

• Your endpoint verifies the signature against the raw body and rejects timestamps older than five minutes.
• You de-duplicate on X-Localoy-Event-Id.
• You answer 2xx within 10 seconds and do slow work afterwards.
• You watch the portal's delivery log, and know how to re-enable an endpoint that was switched off after repeated failures.

Inventory checks#

• Your endpoint answers 200 within 1.5 seconds, including when sold out.
• It verifies the signature and rejects stale timestamps.
• It is monitored — an unreachable endpoint refuses bookings of linked items.