Set up a workspace and go live
The admin playbook: workspaces and applications, environments, connecting a processor, inviting your team, and the four checks that gate going live.
This is the path from a fresh account to taking real money. Do it in order — going live has preconditions, and every one of them is something you set up earlier.
Workspaces and applications
Two levels, and the distinction matters for both billing and access:
- A workspace is the billing and membership boundary. One company, one workspace.
- An application is a storefront or product inside it. A workspace can hold several.
Operational data — orders, customers, subscriptions — belongs to an application, not to the workspace. So if you run two brands that should never see each other’s orders, those are two applications. If they should never share a bill or a team, those are two workspaces.
Environments
Every workspace gets exactly one production environment, created with the workspace. You cannot create, archive, or delete it.
Everything else is a custom non-production environment — test, uat, staging, as many as you want. They all use sandbox provider credentials and are fully isolated: data written in one is invisible from another.
Two rules worth knowing before you name anything:
live, and anything starting withlive-orproduction-, is reserved. This stops a sandbox environment minting a key that looks like a production key.- Creating an environment immediately seeds settings for every application in the workspace. It starts from safe defaults rather than copying an existing environment, so configure it deliberately.
Connect a payment processor
Until a processor is connected, nothing can take money. Connect one per environment — a sandbox connection for your test environments, and a production connection before you go live.
The production connection is one of the four go-live preconditions, and it must be active, not merely present.
Invite your team
Access is two-tier, and people are often given more than they need because the tiers aren’t obvious.
Workspace roles decide who you are across the whole workspace:
| Role | Means |
|---|---|
owner | The creator. One per workspace. Owns billing, transfer, and deletion. |
workspace_admin | Implicit admin on every application. |
member | No application access by default — must be granted per application. |
Application roles decide what someone can do in one application: admin, developer, finance, or viewer. Owners and workspace admins don’t need these; they already have admin everywhere.
The useful pattern is member plus explicit application roles. A finance person who needs invoices for one brand should be a workspace member with the finance role on that application — not a workspace_admin, which silently grants them everything in every application you ever create.
Mint API keys
Keys are minted into one environment and stay there permanently. There is no promoting a test key to production — going live means minting a new key.
sk_keys are server-side and can hold any scope.pk_keys are browser-safe and can hold exactly two: request a shipping quote, and calculate tax. Nothing else, ever.
Keys are revealed once. Grant the narrowest scope set that works — a leaked key is worth exactly what it can reach. See API keys and environments.
Go live
Going live is gated on four checks, and the API returns a requirements array naming exactly which ones you failed:
| Requirement | Meaning |
|---|---|
subscription_active | An active or past-due subscription, or partner status |
production_provider_connection | An active processor connection in the production environment |
application_exists | At least one application in the workspace |
production_terms_recent | Production terms accepted within the last 5 minutes |
That last one catches people. The terms acceptance timestamp has a five-minute freshness window, so accepting terms and then going to fix a missing connection will invalidate it — sort everything else out first, accept last.
If you have live-mode credentials but no entitlement, calls return 402 workspace_not_entitled_for_live rather than failing quietly.
After you’re live
- Sandbox environments keep working. They stay pointed at sandbox provider credentials, so you can keep testing against a live workspace.
- Losing entitlement freezes production rather than deleting it. A cancelled or unpaid subscription sets the production connection inactive — no new live transactions, nothing destroyed. Re-subscribing reactivates it.
- Rotate keys by minting then deleting. Deletion is immediate, so deploy the replacement first.