The Sandbox Channel¶

The sandbox is a simulated marketplace plugged into the real fulfillment path. It holds no marketplace account, needs no credentials, costs nothing and charges nobody — and it exercises the same workflow, the same signatures and the same state machine that Suger does.

Every contract it produces carries isSimulated, which keeps it out of every revenue rollup by construction rather than by each query remembering to exclude it.

Connecting It¶

Open FinOps Center → Marketplace Channels and connect the Sandbox card. The drawer is the same one Suger uses, minus the credentials section — there is no marketplace account to authenticate against.

The fields¶

Omnistrate landing URL — shown, but there is nothing to register it with. A simulated channel has no listing and no upstream console, so this URL is only ever opened from the sandbox page.

Billing provider — locked to Sandbox. Settling through the sandbox means settling nowhere: usage is written to the ledger and no external API is ever called.

ISV portal callback URL (required) — where a simulated buyer lands after onboarding, with ?code= appended. Use your real portal callback here. Following the redirect chain in a browser is how you certify that endpoint, because the redeem you make there is the redeem production will make.

Receiver URL (optional) — set it and rehearsals deliver signed webhooks there instead. Leave it empty and the credential rides the browser redirect to your callback URL.

Signing secret (required) — at least 32 bytes. What rehearsal deliveries are signed with, using the identical scheme production uses. Verify against this and you have verified against production.

Synthetic email domain — buyer root users are derived from it, because several marketplaces return no buyer email at all. Use a domain you control or an obviously fake one such as buyers.example.invalid.

Map a listing¶

The sandbox publishes a small catalog of its own — a standard plan, an enterprise plan and a draft one — with references derived from your organization ID, so they are stable for you and different for everyone else.

Map at least one to a SaaS Product and Plan of yours. A channel with nothing mapped cannot be enabled, because a purchase would resolve to no plan.

The sandbox page¶

FinOps Center → Marketplace Sandbox is where rehearsals are driven from.

Where deliveries go¶

Shows the receiver the channel is configured with, read from the channel rather than as an editable copy of it — so there is one place a receiver is set, and this page cannot disagree with it.

If no receiver is set, this says so plainly: "No receiver is set, so nothing a rehearsal produces will reach you." That is the callback-only setup, and it is a perfectly valid one — see Rehearsing with a callback URL only below.

Signing secret — held by the server and never shown again after it is created. Rotate to mint a new one, which invalidates the current one immediately.

Model a purchase¶

What the buyer bought — which of the channel's listings, and therefore which of your plans the contract resolves to.

Seats — the quantity on the contract.

Arming a purchase creates it on the simulated marketplace and nothing in Omnistrate, exactly as a real marketplace holds a checkout a buyer has not completed. There is no contract yet, because a real purchase has none either until the buyer's browser reaches the landing route.

Rehearsing with a callback URL only¶

This is the simplest integration and the one most ISVs should start with. No webhook endpoint, no signature verification, no receiver to host.

Set up: connect the sandbox with your portal's callback URL, leave Receiver URL empty, and map a listing.

Rehearse:

1. On the sandbox page, choose a listing and a seat count, then Run.

2. The checkout dialog opens. This is the marketplace's Subscribe button, standing in for a page you do not control.

   

3. Press Simulate checkout. A new tab opens and follows the real redirect chain: the checkout, then the landing route that creates the contract and starts fulfillment, then on to your callback URL with ?code= appended. That tab ends on your own page, exactly where your buyer will end up.

4. The dialog waits for the contract the arrival created, then links straight to it.

   

5. Your portal redeems the code, provisions the tenant, and calls confirm.

What you have certified by doing this is the whole path a real buyer takes, including your own callback handler and your own redeem call.

Rehearsing with a receiver¶

Set Receiver URL and every rehearsal delivers a signed webhook there instead of putting the credential on the redirect. This is the path to certify if your integration is server-to-server, and it is required for anything after the purchase.

The sandbox signs with the same scheme production uses, so verifying a sandbox delivery is verifying a production one. See Verifying a delivery.

What the sandbox can do that Suger cannot¶

The sandbox is the only channel whose capabilities are an input rather than a fact. It starts on the most permissive matrix so that nothing is blocked until you deliberately narrow it:

Narrow them to mimic the channel you actually sell through, and the rehearsal tells you what your integration does when a capability is missing.