---
title: "Platform SDK going-live checklist"
description: "Verify charts, live credentials, external checkout recovery, inventory webhooks, accessibility, and operations before taking real money."
---

Run this checklist before directing real buyers through a Platform/SDK
integration. Your platform owns payment, commercial Orders, tickets, delivery,
refunds, scanning, and support; this checklist verifies how that system commits
SeatLayer inventory. Direct organizers using Managed Ticketing need the managed
gateway and hosted-surface readiness checks as well, and must have staff-approved
access with Hosted Checkout (`hosted_checkout`) enabled.

This checklist covers the production-ready **single-event** Platform/SDK
contract. Fixed multi-performance checkout is separately released through
[Performance Groups](/integrations/performance-groups); complete that guide's
compatibility and live-readiness checks when you use it. Fixed Renewable Seasons
have their own [Plan, buyer-rehearsal, sales, booking, renewal, and operational
contract](/server-api/seasons/). Do not launch an integration that depends on
buyer-created or ad hoc event bundles, partial Seasons, first-class resale
listings, arbitrary custom inventory statuses, or true partial-GA channel
allocation: those capabilities are not part of the current release.

<Aside type="caution" title="An Event keeps its mode and commerce owner">
  Test/live mode and Platform/Managed commerce ownership are fixed when an Event
  is created. Create production Events with the intended live key and product
  boundary; reuse the Chart and create a new Event rather than trying to convert
  an existing Event.
</Aside>

## Application readiness

<Steps>
  <Step title="Secure live credentials">
    Store `sk_live_…` only in the production server secret manager. Confirm it is absent from browser bundles, mobile binaries, logs, and public configuration.
  </Step>
  <Step title="Verify browser access">
    For ordinary Platform Public sale, confirm the mount supplies a matching
    `pk_live_…` and its exact production origin is registered under Embed
    domains. For login, presale, partner, or channel inventory, confirm the mount
    instead receives a `buyerAccessTokenProvider` backed by your authenticated
    server and the same exact origin. A test-only key, missing origin, or missing
    applicable credential deliberately produces `404 not_found`.
  </Step>
  <Step title="Complete the trusted checkout">
    Verify the browser sends only the hold id, the server inspects authoritative hold items, and your order id becomes `bookingRef`.
  </Step>
  <Step title="Test payment compensation">
    Deliberately expire a hold after payment authorization. Confirm a booking `409` moves the order into reselection and voids/refunds correctly.
  </Step>
  <Step title="Prove idempotent recovery">
    Simulate a booking response timeout and retry with the same order id. Confirm no duplicate sale, credit usage, or payment capture.
  </Step>
  <Step title="Configure signed webhooks">
    Verify the [webhook signature](/server-sdk/webhooks/) against the raw body, deduplicate deliveries, acknowledge quickly, and separate test/live processing.
  </Step>
  <Step title="Verify the buyer experience">
    Complete checkout and your own ticket delivery on desktop and mobile, with
    keyboard navigation, accessible inventory, color/zoom constraints, and a
    browser without 3D support.
  </Step>
</Steps>

## Event readiness

- [ ] The chart is published.
- [ ] The event was created with a live key.
- [ ] Event name, date, venue, currency, prices, and ticket tiers are correct.
- [ ] Capacity matches the authoritative venue plan.
- [ ] Accessible and companion seats are correctly related.
- [ ] Obstructed views, booths, tables, GA, sections, zones, and floors were reviewed.
- [ ] Intended sections are on sale and reveal rules are correct.
- [ ] Test holds, blocks, and bookings are absent from live inventory.
- [ ] The account has sufficient booking credits.
- [ ] Operations staff can access the intended control surface.
- [ ] Independent Events are not presented as a Season or renewal right unless
      they belong to a published Fixed Renewable Season Plan.
- [ ] If checkout uses a Performance Group, its fixed member Events pass the
      [Performance Groups compatibility and test checklist](/integrations/performance-groups#1-create-compatible-performances).
- [ ] If checkout uses the released Season baseline, its Plan is published,
      buyer rehearsal is recorded, sales are open, the session is origin-bound,
      and the host can reconcile every accepted or partial-terminal operation.
- [ ] Each private channel has the intended allocation, sale route, and sparse
      price overrides; a real scoped buyer session was used to verify both the
      visible inventory and the authoritative hold price.

## Environment checks

| Check | Expected production value |
|---|---|
| SDK/API origin | `https://api.seatlayer.io` unless SeatLayer supplied another |
| Secret key | `sk_live_…` in server secret storage |
| Event mode | Live |
| Webhook environment | Production routing tag or intentional wildcard |
| `livemode` handling | Production logic accepts `true`; test traffic is isolated |
| Logs | Event, hold, order, and payment correlated without secrets |

The `order` and payment in this table are your platform's records. SeatLayer
stores the inventory booking and your `bookingRef`, not a second commerce Order.

## Failure rehearsal

Before launch, rehearse:

1. two buyers competing for the same final seat;
2. hold expiry on the payment page;
3. payment authorization followed by booking conflict;
4. successful booking with a lost HTTP response;
5. delayed and duplicate webhook delivery;
6. realtime disconnect and reconnect;
7. event sold out while a buyer is viewing it; and
8. an operator blocking inventory during active sales.

## Launch evidence

Record:

- the production event key and your business event id;
- the chart version reviewed;
- the live credential/environment used, without the secret;
- automated check output;
- the successful manual order/booking reference;
- webhook delivery evidence; and
- the owner of rollback or buyer-support decisions.

## Final decision

Do not launch when any of these remain unknown:

- who owns payment compensation;
- how an expired hold returns to selection;
- whether booking retries reuse the same reference;
- whether webhook signatures are verified;
- whether tenant/workspace ownership is enforced; or
- whether accessible inventory was validated.

Use [Integration best practices](/integrations/best-practices) for the complete production standard and the [complete checkout example](/examples/complete-checkout) as the reference flow.