Sandbox vs Live

Hilt is currently a live-first product.

That is the most important thing to understand before you build around it: the hosted checkout, membership activation, receipts, and payment confirmation model are designed around real Solana settlement.

The practical environment split

Surface	Recommended environment	Notes
Merchant app	Local + production	Use local for layout and workflow checks, then move to live domains.
Hosted checkout	Local tunnel + production	Phone and wallet flows usually need a reachable HTTPS origin.
Buyer payments	Tiny-value live payments	There is not yet a separate public sandbox checkout rail for end-customer payments.
Merchant billing via Stripe	Stripe test mode + live mode	Stripe already has a clean test/live split for Hilt’s own SaaS billing.
OAuth	Separate local and production callbacks	Keep local and production callback URLs explicit.
Webhooks	Local public tunnel or production HTTPS	Helius and Stripe both need publicly reachable HTTPS endpoints.

What “sandbox” means today

You will see sandbox on some API key and dashboard surfaces.

Today that means:

• a key can be marked sandbox for operational separation
• you can keep local and production workspace behavior separate
• you can build staging checks without publishing them as your live merchant setup

It does not mean:

• a second public Solana checkout network maintained by Hilt
• a full duplicate buyer-facing sandbox with fake receipts and fake memberships
• a separate Hilt-hosted “test merchant” environment for the entire product

Safe testing pattern for launch

The safest launch sequence is:

1. build and brand the template locally
2. test buyer identity and wallet behavior locally or through a public HTTPS tunnel
3. publish the flow on the real domains
4. run tiny-value live payments, for example 0.20 USDC
5. verify payment, membership, receipt, and support history
6. only then scale the price and traffic

That pattern matches the actual Hilt surface better than pretending there is a fully separate public sandbox.

Local development checklist

For local work:

• use http://localhost:3001 for the merchant app
• use http://localhost:3002 for admin
• use a public HTTPS tunnel when a wallet app or webhook provider needs a reachable URL
• keep OAuth callback URLs explicit for local and production

Example local callbacks:

http://localhost:3001/api/auth/oauth/google/callback
http://localhost:3001/api/auth/oauth/github/callback

Production checklist

For production:

• https://www.hilt.so for hosted checkout links
• https://app.hilt.so for the merchant app
• https://api.hilt.so for API, OAuth callbacks, and provider webhooks

Example production callbacks:

https://app.hilt.so/api/auth/oauth/google/callback
https://app.hilt.so/api/auth/oauth/github/callback
https://api.hilt.so/v1/products/connect/discord/callback
https://api.hilt.so/v1/products/connect/telegram/webhook
https://api.hilt.so/v1/products/webhook/helius
https://api.hilt.so/v1/billing/webhooks/stripe

When to use test mode in Stripe

Stripe is only used for Hilt’s own merchant billing, not the buyer’s on-chain checkout.

So the Stripe guidance is simpler:

• use Stripe test keys and test webhook secrets while validating Hilt plan billing
• switch to live keys, live prices, and live webhooks only when you are ready to charge merchants for Hilt itself

Honest launch guidance

If you are looking for a “perfectly fake” end-to-end environment, Hilt is not there yet.

If you are looking for a safe way to launch:

• local for product shaping
• tiny-value live payments for real checkout validation
• production domains for the final smoke pass

That is the most accurate and least surprising way to work with the current Hilt launch surface.