> ## Documentation Index > Fetch the complete documentation index at: https://docs.services.payward.com/llms.txt > Use this file to discover all available pages before exploring further. # Environments > Move your integration from local development to your hosted test deployment, and then to production. Payward Services has two environments: the sandbox and production. You build and test against the sandbox, then switch to production when you launch. > [!TIP] > > **Recommended approach:** build and test against the sandbox, fund test accounts with simulated deposits, and save > testnet transfers for manual checks of the on-chain flows you depend on. ## Environments **Sandbox** * API base URL: `https://api.sandbox.services.payward.com` * Console: `https://console.sandbox.services.payward.com` **Production** * API base URL: `https://api.services.payward.com` * Console: `https://console.services.payward.com` The environments also differ in what they hold and who can reach them: | | Sandbox | Production | | - | - | - | | Funds | Test balances you add with a [simulated deposit](/tabs/developer-documentation/testing/deposits-and-withdrawals.md#fund-your-account-with-a-simulated-deposit) | Real funds | | Crypto | Selected testnets. See [test networks](/tabs/developer-documentation/testing/networks.md). | Mainnets | | Credentials | API keys you create in the sandbox Console | API keys you create in the production Console, after Payward enables production access | | Access | IP addresses allowlisted for the sandbox | IP addresses allowlisted for production | The two environments are fully separate. Accounts, API keys, balances, method IDs, funding addresses, and webhooks don't carry over between them. > [!WARNING] > > Code examples elsewhere in these docs use the production base URL. Replace it with the sandbox base URL while you > test. ### What you can test in the sandbox Most of an integration runs end to end in the sandbox, with test balances instead of real funds: | Flow | How to test it | | - | - | | Authenticated requests | [Check your credentials](/tabs/developer-documentation/testing/setup.md#check-your-credentials) with three read-only calls. | | Test balances | Add them with a [simulated deposit](/tabs/developer-documentation/testing/deposits-and-withdrawals.md#fund-your-account-with-a-simulated-deposit). No testnet transfer is needed. | | Quotes and swaps | Fund the account with a [simulated deposit](/tabs/developer-documentation/testing/deposits-and-withdrawals.md#fund-your-account-with-a-simulated-deposit) first. A new account is empty. See [Swaps](/tabs/developer-documentation/trade/swap.md). | | Conversions | Trigger rules with simulated deposits. See [Testing conversions](/tabs/developer-documentation/payments/testing-conversions.md). | | Transfers between your accounts | Create a second account, and fund the source account. See [Transfers](/tabs/developer-documentation/payments/transfers.md). | | Crypto deposits and withdrawals | Use the [sandbox test networks](/tabs/developer-documentation/testing/networks.md). See [Test deposits and withdrawals](/tabs/developer-documentation/testing/deposits-and-withdrawals.md). | | Hosted verification (KYC) | Ask your Payward contact to enable it for your sandbox account. | | Webhooks | Register sandbox endpoints, separate from your production ones. | If a sandbox call returns `403`, the capability may not be enabled for your account or API key yet. Send the request's path and the response to your Payward contact. ### What you test in production A few flows need real banks or production data, so you test them in production with small real amounts. Ask your Payward contact for a production test account. | Flow | Why it needs production | | - | - | | Fiat deposits and bank payouts | The sandbox isn't connected to banks. | | Settlement reports | Reports are generated from production data only. | | Ramp | Ramp isn't available in the sandbox; its endpoints return `503`. | For other products, such as Auto Earn, price trigger swaps, on-chain swaps, and bank links, ask your Payward contact whether to test in the sandbox or in production. ## Testing stages Move your integration through three stages: 1. [Local development](#local-development) 2. [Hosted testing](#hosted-testing) 3. [Production](#production) Each stage runs your code in a different place. | Stage | Where your code runs | Payward environment | Use it to | | - | - | - | - | | Local development | A developer's machine, with a debugger | Sandbox | Build and debug individual calls and webhook handlers | | Hosted testing | Your own dev or staging infrastructure | Sandbox | Run end-to-end flows on deployed code | | Production | Your production infrastructure | Production | Serve your users after launch validation | Each stage needs its own API key and secret, allowlisted IP addresses, and webhook endpoint, and production needs its own base URL. Keep these values in configuration, not in code, so you can switch stages without code changes. ### Local development Run your application on your machine against the sandbox. To step through webhook handling in your debugger, expose your local server through a tunnel, a service such as ngrok that forwards a public HTTPS URL to your machine. [Set up local development](/tabs/developer-documentation/testing/setup.md) walks through it. ### Hosted testing Deploy your build to your own dev or staging infrastructure, and point it at the [sandbox API base URL](#environments). Unlike local development, requests now come from your servers, and webhooks go to a public URL instead of a tunnel. That changes what you need to set up: * Ask your Payward contact to allowlist your deployment's static egress IP addresses for the sandbox. * Register a webhook endpoint for the deployment. It must be reachable over public HTTPS. * Give each deployment that runs at the same time its own API key. Each key needs an [`API-Nonce`](/tabs/developer-documentation/get-started/authentication#setting-the-api-nonce-parameter) larger than the last one sent with that key, so deployments that share a key can reject each other's requests. * For automated tests, use flows that don't need testnet transfers. Fund test accounts with a [simulated deposit](/tabs/developer-documentation/testing/deposits-and-withdrawals.md#fund-your-account-with-a-simulated-deposit), and test conversion rules with [simulated conversion deposits](/tabs/developer-documentation/payments/testing-conversions.md). Testnet transfers are slow, and testnets aren't always available, so keep them for manual checks. ### Production Deploy to your production infrastructure, and point it at the [production API base URL](#environments). Before you switch: 1. Test every flow your application depends on, including transactions that stay [`in_progress`](/api-reference/portfolio/list-portfolio-transactions#response-data-items-status) for a while or end `failed`. 2. Share your test results with Payward for a launch-readiness review. If you use hosted verification, Payward reviews your verification test cases before you open trading to users. 3. Get production API keys with the permissions your flows need, and allowlist your production IP addresses. 4. Register your production webhook endpoint. 5. Switch the base URL, credentials, account ID, and webhook configuration together. Rediscover method IDs and funding addresses in production; sandbox values don't work there. 6. Agree on a small live transaction, its expected outcome, and an escalation contact. Payward can set up a production test account for this.