Skip to main content

Go-live checklist

Work through this before switching hosts. Items marked blocking will cause a production incident if missed.

Credentials and access​

  • Blocking — Production CHANNELID issued, and distinct from your UAT value if they differ
  • Blocking — Production key pair generated, separate from UAT
  • Blocking — Your production certificate exchanged with Cheggout
  • Blocking — Cheggout's production certificate loaded into your configuration
  • Blocking — Production egress IPs whitelisted, including any NAT or load-balancer addresses
  • Production APP_KEY/SEC_KEY issued, if you use the Deals Store
  • All secrets stored in a secret manager, not in configuration files or images
  • UAT credentials cannot reach production, and vice versa

Configuration​

  • Blocking — Every host is environment-configurable, not hardcoded
  • Production hosts confirmed per product line — see Environments
  • SDK build or widget script pinned to a known version
  • Hosted launch URLs confirmed with Cheggout, if you use a microsite
  • A config change can be deployed without an app release

Authentication​

  • Blocking — Signing verified end to end against production credentials in a smoke test
  • Response signature verification enabled
  • Unsigned failure bodies handled without throwing
  • Reference token refreshed on a schedule with a margin, not per request
  • Token refresh is single-flight
  • 401 triggers one re-mint and one retry, then fails cleanly
  • No token, key or secret appears in any client, log or URL

Identity​

  • Blocking — virtualId derived from your authenticated session, never from client input
  • virtualId contains no personal data
  • virtualId is stable and never reassigned
  • extTransactionId is globally unique, persisted, and reconcilable to a real transaction

Per module​

Scratch cards​

  • Blocking — Reveal responses persisted before rendering
  • Empty rewards renders nothing and raises no alert
  • BETTER LUCK NEXT TIME has a designed UI state
  • Both couponType variants render correctly
  • Reveal timeouts reconcile via reward history rather than retrying
  • Card issuance happens from your backend after transaction verification

Deals and coupons​

  • Blocking — Coins burned before delivery is requested
  • Blocking — Every delivery failure path retries with the same reference or refunds
  • Catalogue cached with a scheduled refresh
  • Inventory checked within its TTL before the buy action
  • Coupons persisted at delivery
  • Reconciliation job runs against your delivery ledger

Marketplace​

  • Session minted only after your own authentication
  • virtualId and sessionId passed together
  • Return handshake behaves correctly from both back and home
  • Deep payment relaunch tested with a real payment result, if applicable
  • Placement IDs confirmed for production
  • Pre-login and logged-in states both handled
  • Empty placement responses degrade gracefully

Tracking​

  • Blocking — Impressions fire when items become visible
  • Blocking — Clicks fire on tap or scratch
  • Copy and redeem tracking fire where the reward provides them
  • Tracking failures do not block the user journey
  • Fire rates are observable in your monitoring

Tracking is how attribution, reporting and settlement work. Verify it explicitly rather than assuming it.

Error handling​

  • All four response shapes parse without throwing
  • Business "no" outcomes are not treated as errors
  • Unrecognised bodies are logged with the endpoint and extTransactionId, then fail safely
  • No error path leaves a user with burned coins and no coupon
  • User-facing messages are written for the failure states, not just the happy path

Security​

  • Authorization headers redacted in logs
  • No credentials in source control, images or client bundles
  • Rewards issued server-side after verification
  • Alerting on signature-failure and auth-failure rates
  • Incident contact and rotation path agreed with Cheggout

Operations​

  • Named Cheggout technical contact and escalation path agreed
  • Expected peak volumes shared with Cheggout — TBD no published rate limits
  • Monitoring in place for latency, error rate, tracking fire rate and reward issuance rate
  • Rollback plan documented and tested
  • Reconciliation process defined and owned
  • The SDK build, widget build and document revision you certified against are recorded

What Cheggout needs from you​

Confirm these are complete on their side before switching:

  • Production campaigns configured for your channel
  • Trigger event codes registered
  • Placement IDs issued
  • Production IP whitelist applied
  • Certificates exchanged in both directions
  • Hosted launch URLs provisioned, if applicable

Final smoke test​

In production, before opening traffic:

  1. Mint a reference token.
  2. Create a card for a test user against a real transaction.
  3. Confirm the impression fired.
  4. Reveal it and confirm the reward persists.
  5. Confirm the click fired.
  6. Check the card appears in reward history.
  7. If you use deals: read the catalogue, check inventory, deliver one coupon, confirm it appears in the user's coupons.

Next​