Become a Paddle partner
Join the Paddle partner program to read this content. You'll also get access to our partner API and agent tooling. Let us know a few details about your business to get started. Already a partner? Log in to view this page.
Paddle has two environments with completely separate credentials, data, and dashboards:
- Sandbox accounts for building and testing integrations.
- Live accounts for accepting real payments.
They largely behave in the same way, so you can be sure an integration against sandbox works when you go live, with some differences on sandbox for testing.
For partners, the key thing to know is that everything you create is scoped to one environment. This includes sellers that you onboard. We recommend creating a sandbox and live account for each seller, then creating and updating data in both environments.
Separate base paths
The Paddle API has two separate base paths for sandbox and live:
| Environment | Base URL |
|---|---|
| Sandbox | https://sandbox-api.paddle.com |
| Live | https://api.paddle.com |
Both environments expose the same API and endpoints. You select one by the base URL you call.
Sellers exist per environment
You can use the partner API to create an account for a seller in your platform. A seller you create in sandbox isn't visible in live, and the reverse is true too.
To onboard a new seller, we recommend creating a sandbox and live account for them at the same time by making two successive calls to the Paddle API: one to sandbox, and one to live. For example:
- POST
https://sandbox-api.paddle.com/accountsto create a sandbox account - POST
https://api.paddle.com/accountsto create a live account
Paddle returns an id for the seller in each response. You should create a record for this seller in your database and store both the sandbox and live IDs against this record.
Email must be unique in an environment, but not across environments. We don't recommend using it as an identifier because it may change.
Frame sandbox as test mode
Testing is an important part of a seller integration. Sellers need to be able to open a pricing page, complete a checkout, and make sure their integration works end to end. They can use test cards, so they're not spending any real money.
We recommend framing sandbox as "payments test mode" in your platform UI. For example, you might let sellers toggle between test and live mode for payments, swapping the API keys and data they're using when they do.
Sandbox doesn't require verification, so sellers can start integrating and testing right away. For live accounts, sellers need to provide some information about who they are and what they sell before they can start accepting real payments.
Sync data across environments
Since data in each environment is isolated, you need to create and update entities in both environments to keep them in sync. For an optimal experience, we recommend syncing:
- Products and prices
- Discounts
- Seller account settings
In your platform, we recommend presenting one set of products, prices, and discounts to sellers. This means they don't need to think about data in Paddle because they see one catalog that they maintain in your platform.
When you create products, prices, or discounts, create or update them both in sandbox and live by making two successive calls.
Products, prices, and discounts have a different Paddle ID in each environment. To match sandbox and live entities, attach your own identifier using the import_meta field when creating or updating entities. For example:
{ "data": { "id": "pro_01gsz4t5hdjse780zja8vvr7jg", "name": "AeroEdit Pro", "tax_category": "standard", "type": "standard", "description": "Designed for professional pilots, including all features plus in Basic plus compliance monitoring, route optimization, and third-party integrations.", "image_url": "https://paddle.s3.amazonaws.com/user/165798/bT1XUOJAQhOUxGs83cbk_pro.png", "custom_data": null, "status": "active", "import_meta": { "imported_from": "your-platform-name", "external_id": "your-internal-id" }, "created_at": "2026-02-23T12:43:46.605Z", "updated_at": "2026-04-05T15:53:44.687Z" }, "meta": { "request_id": "ccb21d76-1e13-4a5e-afb8-0f4c9f20ac07" }}You should create a record for each product, price, and discount in your database and store both sandbox and live Paddle IDs against them.
Your external_id stays constant across environments, so you can resolve a Paddle entity back to your own records by listing products, prices, and discounts using the external_id query parameter. For example:
/products?external_id=your-internal-id Return entities that match the import_meta.external_id passed. Use a comma-separated list to specify multiple values.
Differences between sandbox and live
Core functionality is the same in both environments, with some differences in sandbox for testing:
| Area | Sandbox | Live |
|---|---|---|
| Website approval | No approval required. | Approval required. |
| Default payment link | Any domain, no verification. | Verified, approved domain. |
| Card payments | Test cards only, no real money. | Real cards, real money. |
| Checkout appearance | 'Test Mode' watermark. | No watermark. |
| Hosted checkouts | No approval required. | Approval required. |
| Adjustment approvals | Refunds auto-approved every 10 minutes. | Paddle approval needed for most refunds. |
| Webhook retries | 3 retries in 15 minutes. | 60 retries in 3 days. |
| Email delivery | Sent to your account's domain; others forwarded to your main email. | Sent to the customer's email or the email provided. |
| Paddle Retain | Not available. May be simulated. | Available. |
For a full list of differences, see Sandbox.