Environments

Payward Services has two environments: the sandbox and production. You build and test against the sandbox, then switch to production when you launch.

​

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: The two environments are fully separate. Accounts, API keys, balances, method IDs, funding addresses, and webhooks don’t carry over between them.

​

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: 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. 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
2. Hosted testing
3. Production

Each stage runs your code in a different place. 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 walks through it.

​

Hosted testing

Deploy your build to your own dev or staging infrastructure, and point it at the sandbox API base URL. 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 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, and test conversion rules with simulated conversion deposits. 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. Before you switch:

1. Test every flow your application depends on, including transactions that stay in_progress 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.