First order in 10 minutes

A runnable sandbox example from test key to verified webhook delivery.

First order in 10 minutes

Start with one dummy card and follow a simulated order through payment, production, shipment and webhook processing. The built-in demo receiver works immediately: no receiver hosting, signing-secret setup or smoke-test environment variables are needed.

Open your widget in test mode
Copy your personalized script from the dashboard and change data-mode="live" to data-mode="test". Keep the same public partner key and use an allowed website origin. Or create a cart using your server-side tcgp_test_ API key and the sandbox API.
Add a dummy card
Wait for artwork validation, then choose Open simulated checkout. API users open the returned checkout_url.
Complete simulated checkout
Use the sample details and confirm the simulation. The order and built-in demo receipt are saved. Expand the paid event to see its payload, demo signature verification, simulated 503 → 200 retry and one state application.
Follow production and shipping
Click Simulate production, then Simulate shipment. The order and demo receiver state advance together. Receipts remain visible when you reload the checkout while its link is valid.
Try failure cases
Replay duplicate increases delivery attempts without applying the event again. Try invalid signature demonstrates a 401 rejection without changing receiver state. Cancellation is available before shipment.

Optional: verify delivery to your own receiver

When you are ready to test an external integration, use the example below. This advanced path needs your HTTPS receiver and the platform delivery worker; queued delivery alone is not success.

Get your test key
Complete partner setup and accept the current terms in the dashboard. Create a tcgp_test_ key. Use the API host belonging to that dashboard; staging keys and production keys are not interchangeable by assumption.
Start the test receiver
Download the runnable Node.js 24 sandbox example. It includes dummy artwork, a signature-verifying receiver, durable SQLite storage and a test runner. Put its receiver behind HTTPS on your registered website origin. In Dashboard → Order webhooks → Test, save https://your-test-site.example/webhooks/tcgplaytest. Store the displayed signing secret on the receiver server.
The receiver is only for test fixtures. It rejects live events and unknown runs. Keep its control token server-side, use a persistent disk, and proxy both /webhooks/tcgplaytest and /runs to its localhost port 8788.

Receiver server environment · replace placeholders

# Node.js 24; run in the extracted example directory.
# Put these values in your server's secret environment, not a public repository.
TCGP_TEST_WEBHOOK_SECRET=whsec_YOUR_TEST_WEBHOOK_SECRET
SMOKE_RECEIVER_TOKEN=YOUR_RANDOM_TOKEN_AT_LEAST_32_CHARACTERS
SMOKE_RECEIVER_DB=/persistent-volume/smoke-receiver.sqlite

node receiver.mjs

Use your host's environment settings, or a private environment file with node --env-file=.env.receiver receiver.mjs. The secret is the dashboard's Test webhook signing secret, not your API key.

Run your first sandbox order
Set the following environment on your terminal/server. The example uploads the included dummy PNG, creates a one-card cart, waits for validation, completes simulated checkout, verifies the order, and waits for actual webhook delivery.

Test runner environment

SMOKE_PARTNER_ORIGIN=https://partner.tcgplaytest.com
SMOKE_TEST_API_KEY=tcgp_test_YOUR_KEY
SMOKE_RECEIVER_ORIGIN=https://your-test-site.example
SMOKE_RECEIVER_TOKEN=THE_SAME_PRIVATE_CONTROL_TOKEN

node --env-file=.env.runner first-order.mjs

On production, use https://partner.tcgplaytest.com with a tcgp_test_ key and the Test webhook from that dashboard. Test mode still simulates payment and fulfillment on the production host. For a staging-only run, use https://partner-test-two.vercel.app with its own key and Test webhook; its matching commerce site is https://testing123-prof.vercel.app.

Check the proof
The runner prints a test_order_… ID. The receiver checks the raw-body HMAC signature and timestamp, intentionally returns 503 on the first paid delivery, and waits for the platform's actual retry. The paid event must be applied once. Three duplicate deliveries must leave its update count unchanged. Invalid signatures must return 401 without changing state. Simulated production/shipping events then update it to shipped. Only then does the runner print PASS.
Connect your own cart
Save the cart ID and the purchased item snapshot against your authenticated customer before checkout. After a verified webhook or server-side order lookup, atomically mark that revision processed and remove only its purchased quantities. A redirect alone is never confirmation. See the cart-clearing pattern and browser simulator.

Common mistakes

What the sandbox proves

The default walkthrough exercises real uploads, artwork validation, cart ownership, simulated order creation and a persistent demo inbox with signature verification and duplicate protection. Its retry is simulated locally. Only the optional external receiver path tests network delivery and worker retries. Neither proves your store's cart-clearing implementation until you connect and test that code.

It does not charge a card, validate actual Stripe totals, discounts, tax, payment authentication or Connect transfers, consume printing credit, print or ship. Its simulated shipping data is not a carrier shipment. Live iframe policy is a separate check. Run Stripe test-mode payment tests and a controlled launch review before accepting live customer payments.

Next: partner launch checklist, then webhook reference for event details and retry behavior.

TCGPlaytest · Cardify LLC Partner terms Support