Test Paddle webhooks without account verification

You can't test a Paddle subscription cancel webhook until Paddle has verified your business. That takes days.

Paddle's billing API handles subscriptions, payments, and the entire checkout flow. The API is clean and the docs are solid.

The problem is the sandbox.

Verification before testing

To get a Paddle sandbox account, you need to:

• Sign up and create a separate sandbox login
• Wait for Paddle to verify your business (this can take days)
• Set up products and prices in the sandbox dashboard
• Configure webhook URLs
• Use test card numbers for checkout

All of this before you can test whether your code correctly handles a subscription.canceled webhook.

If you're building a billing integration and you want to test the full lifecycle — create subscription, pause, resume, cancel — you're waiting on Paddle's verification process before you can write a single test.

The lifecycle is the hard part

The individual API calls are straightforward. The hard part is the lifecycle:

• Create a subscription → status is active
• Pause it → status changes to paused, webhook fires
• Resume it → status changes back to active, webhook fires
• Cancel it → status changes to canceled, webhook fires

Each transition produces a webhook event. If your handler doesn't process them in the right order, or misses one, your app's subscription state drifts from Paddle's.

You can't test this sequence without a working sandbox. And you can't get a working sandbox without verification.

Testing the lifecycle without waiting

FetchSandbox has a Paddle sandbox with the full subscription lifecycle. No verification, no account setup, no test cards.

The workflow:

1. POST /subscriptions — create a subscription
2. POST /subscriptions/{id}/pause — pause it, webhook fires
3. POST /subscriptions/{id}/resume — resume it, webhook fires
4. POST /subscriptions/{id}/cancel — cancel it, webhook fires

Each step is stateful. The subscription ID chains between requests. The status transitions follow Paddle's actual state machine. Webhooks fire at each step.

Why this matters for billing

Billing bugs are silent. A missed subscription.canceled webhook doesn't throw an error — it just means a cancelled customer keeps access. You find out weeks later when you're reconciling revenue and the numbers don't match.

Testing the full lifecycle — not just the happy path, but pause/resume/cancel — is how you catch these before they cost you money.

Try the Paddle sandbox — no signup, no verification, runs in your browser.