Skip to main content

Paddle

Paddle Sandbox: A Better Alternative for Developer Testing

Paddle's developer sandbox is great for end-to-end checkout testing. It is the wrong tool for everything else.

Apr 10, 2026FetchSandbox Engineering

If you have ever tried to test a Paddle Billing integration, you know the dance.

You sign up. You wait for merchant approval. You configure a test environment. You generate an API key. You read 11 different doc pages. You write your subscription handler. You test it once. It fails. You guess why. You wait for the next webhook. It does not come. You realize the sandbox is shared with two teammates and someone canceled the subscription you were about to activate.

Most of that pain has nothing to do with Paddle being a bad product. Paddle is great. The pain comes from one specific thing: developer testing and end-to-end checkout testing are not the same problem, and Paddle's developer sandbox tries to be both.

What Paddle's sandbox is good at

Paddle's real sandbox shines when you need to do end-to-end checkout testing with real card flows. It supports the full Paddle Checkout overlay, real payment method capture, real subscription billing cycles in compressed time. If you want to test what your customer will actually see when they hit your pricing page, the official sandbox is the only thing that gives you that.

For about 5 percent of integration work, that's exactly what you need.

What Paddle's sandbox is bad at

The other 95 percent looks like this:

  • You are writing a webhook handler for subscription.activated
  • You want to verify your idempotency logic actually deduplicates retried events
  • You want to test what happens when subscription.canceled arrives before your subscription.activated handler finishes
  • You want a CI test that creates a subscription, pauses it, resumes it, cancels it, and asserts that your local database state matches Paddle's after each step
  • You want a brand-new engineer to be able to run npm test on day one without giving them production secrets

For all of that, the official Paddle sandbox is the wrong tool. Not because it's broken — it's just not designed for this. It requires merchant approval (so your CI cannot self-serve a fresh environment). It rate limits (so a parallel test suite hits 429s). It shares state across your team (so tests interfere with each other). It still calls Paddle's servers (so your CI run depends on Paddle's uptime). And it still requires a real Paddle test API key (so you cannot give it to a brand-new engineer on day one).

The result is that most teams end up doing one of three things:

  1. Skip integration testing entirely and hope production catches the bugs
  2. Hand-roll a fragile mock with hardcoded responses that drift from Paddle within a quarter
  3. Run real tests against the shared sandbox and accept the flakiness

None of these are good. All of them are common.

What a developer-grade Paddle sandbox actually needs

The version of this that would actually make integration work pleasant has a few obvious requirements:

  • Spin up in seconds, no merchant approval, no signup
  • Stateful — when you create a subscription, the next read returns it
  • Real state machine — subscriptions actually walk through trialing → active → paused → canceled
  • Real webhook events — every state transition fires the matching event so your handler gets to react
  • Ephemeral and isolated — your CI run doesn't collide with your colleague's
  • No quota — you can hit it as hard as you want without rate limiting
  • Same wire format as the real Paddle API — so your client code is unchanged

That is what we built. It is called FetchSandbox for Paddle, and it covers all 87 endpoints in Paddle's public OpenAPI spec.

How it actually works

The whole thing is one HTTP call away. Spin up a sandbox:

curl -X POST https://fetchsandbox.com/api/sandboxes \
  -H "Content-Type: application/json" \
  -d '{"spec_id":"paddle"}'

You get back a sandbox URL and a test API key:

{
  "id": "a1b2c3d4e5",
  "base_url": "/sandbox/a1b2c3d4e5",
  "credentials": [{ "api_key": "sandbox_..." }]
}

Now point your existing Paddle client at the sandbox URL instead of api.paddle.com. Use the sandbox API key in place of your real PADDLE_API_KEY. Same routes, same payloads, no other code changes.

curl https://fetchsandbox.com/sandbox/a1b2c3d4e5/products \
  -H "Authorization: Bearer sandbox_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Pro Plan",
    "tax_category": "standard"
  }'

That product now exists in your sandbox. The next GET returns it. The next POST to /prices can reference it. The next POST to /subscriptions can use that price. And every state transition along the way fires the matching webhook event.

The full subscription lifecycle, in CI

The thing that broke for me on real Paddle's sandbox was running the full subscription lifecycle as one repeatable test. Create the customer. Create the product. Create the price. Create the subscription in trialing. Activate it. Pause it. Resume it. Cancel it. Verify the final state. Replay each webhook into your handler. Confirm your database matches.

That is a single test in FetchSandbox. It runs in under 2 seconds. You can run it on every commit.

We actually built a tiny demo app that does exactly this and ships with a downloadable integration guide: see the Paddle billing showcase on GitHub. The README walks through the lifecycle test, the webhook handler, and how to wire it into your own app.

What about real card flows?

Use the real Paddle sandbox for that. They are the only ones who can give you that. FetchSandbox is for everything else: webhook handler tests, idempotency tests, retry tests, lifecycle tests, parser tests, CI integration runs, onboarding new engineers, debugging at 3am without burning a real test environment.

The two tools complement each other. Real Paddle sandbox for the last 5 percent of testing that needs real card flows. FetchSandbox for the 95 percent of testing that does not.

Where to start

If you have a Paddle integration to test, the fastest way to see what this looks like:

No signup. No merchant approval. No credit card. Sandboxes spin up in seconds and run in your browser.