---
name: sezzle-go-live
description: >
  Move a Sezzle integration from sandbox to production — production account setup,
  key cutover, re-provisioning webhooks and allowlists per environment, and a safe
  production smoke test that does not capture real money. Use when: "take my Sezzle
  integration live", "switch Sezzle to production", "Sezzle go-live checklist", "test
  Sezzle in production safely", "my sandbox integration works, what now". Requires a
  working sandbox integration — use sezzle-checkout
  (or the relevant integration skill) first.
metadata:
  author: Sezzle
  version: "1.0.0"
---

# Take a Sezzle Integration Live

Sandbox and production are fully separate: separate accounts, separate keys, separate
Sezzle-side configuration. Going live is not a URL swap — it is a re-provisioning pass
plus a careful first transaction.

**In production, a completed checkout charges real money.** The quickest
environment check is the checkout URL: if it does not contain `sandbox`, it is real.

## Step 0: Code check

Run this while Step 1 waits on the human. Each item passes silently in sandbox and costs
real money or real data in production:

- **The private key and bearer tokens must stay server-side.** Grep what ships to the
  browser (build it first if needed) for `sz_pr_` and `/v2/authentication` tokens; none may
  appear. `sz_pub_` is fine there when you use the JS Checkout or Virtual Card SDK.
- **Capture, release, and refund must reuse the same `Sezzle-Request-Id` on retry.** A
  fresh one per call charges or refunds a real shopper twice.
- **If you use webhooks, the handler must return 200 fast and dedupe on the webhook `uuid`.** Retries
  and out-of-order deliveries are normal; a handler that 500s for days loses the
  subscription.
- **AUTH orders must capture before `authorization.expiration`** under real fulfillment
  timing. Production has its own window setting; don't assume the sandbox one.
- **Nothing may capture on its own when the shopper completes an AUTH checkout** (return
  page, webhook handler, background job), or the Step 4 test charges real money. Search for
  `capture` broadly, since the URL is often built in pieces or wrapped in a helper, and
  confirm none of it runs on the completion path.
- **Errors must be logged whole**, not just the status code.

## Step 1: Production account

The sandbox account does not carry over. The user must:

1. Sign up at https://dashboard.sezzle.com/merchant/signup and submit the merchant
   application — with **real** business information this time (sandbox allowed fake data;
   production validates it).
2. Wait for application approval.
3. Complete the Setup Checklist payment steps that sandbox skipped. API keys cannot be
   generated until they are done.

This is browser-only and human-only. Hand it off and resume when they confirm.

## Step 2: Production API keys

Dashboard → Settings → API Keys (Admin users only). Save as new values (for example
`SEZZLE_PUBLIC_KEY` / `SEZZLE_PRIVATE_KEY`) — do not overwrite the sandbox keys, the user
will want both. Keep `.env` gitignored.

**There is no way to tell sandbox and production keys apart by looking at them** — both
are `sz_pub_…` / `sz_pr_…`. Label them clearly at storage time; the base URL is what tells
them apart at runtime.

## Step 3: Cutover checklist

Walk every item; each one is a silent failure if missed.

| Item | Change |
|---|---|
| API base URL | `https://sandbox.gateway.sezzle.com/v2` → `https://gateway.sezzle.com/v2` |
| API keys | Production keys from Step 2 |
| JS Checkout SDK / Virtual Card SDK | `apiMode: "sandbox"` → `"live"` (note: `live` is the **default** — an SDK config that never set `apiMode` was already pointing at production) |
| Webhooks | **Re-subscribe in production.** Subscriptions are per-environment; sandbox ones do not fire for production orders. Use the production webhook URL and verify signatures with the production private key. See `sezzle-webhooks`. |
| Iframe checkout / Virtual Card | **Re-request domain allowlisting for production domains.** Allowlists are per-environment. Same Account Manager request as sandbox, production domains this time. Your own CSP must allow `*.sezzle.com`, not just the sandbox host. |
| Widgets | No change — widgets always used the production Merchant ID. |
| `complete_url` / `cancel_url` | Point at production pages, not staging hosts. |

## Step 4: Safe production smoke test

Do one real transaction, but never capture it:

1. Create a session with `intent: "AUTH"` and a **small** amount (tiny orders may not qualify for any plan).
2. Confirm the checkout URL does **not** contain `sandbox` — this proves you are in
   production — then have the user complete it as a real shopper with a real
   payment method and OTP. Completion must not trigger a capture (see Step 0).
3. `GET /v2/order/{order_uuid}` → verify `authorization.approved: true`. Do steps 3 to 5
   promptly: authorizations expire after a short window (see `auth-and-capture`). If the
   order is gone, it expired and was released, so start over with a new session.
4. If you subscribed to webhooks, verify the production webhook arrived and its signature checks out.
5. **`POST /v2/order/{order_uuid}/release`** for the full amount. Do not capture.
   The shopper may briefly see a hold from checkout.

If something goes wrong after an accidental capture: refund, then contact Sezzle Support.
For any other failure in this step, use the `sezzle-troubleshoot` skill.

## Step 5: Confirm and clean up

- Check the order in the production dashboard and confirm nothing was captured:
  https://dashboard.sezzle.com/merchant/orders
- Make sure no sandbox values survive in production config: base URL, keys, `apiMode`,
  webhook URLs.
- Remind the user: only one dashboard environment can be logged in at a time — a sandbox
  login in another tab ends the production session, which looks like a mystery logout.

## Rules

- **Never capture the smoke test.** AUTH → verify → release.
- **Never run sandbox test data against production.** It will not work, and trying it with
  a real card would charge it.
- **Never print or inline key values.** Reference env vars.
- **Re-provision everything per environment.** Webhooks, allowlists, dashboard settings
  (for example the authorization expiration window) all reset to defaults in production.

## Source docs
- /docs/api/environments • /docs/guides/auth-and-capture • /docs/api/core/orders