Testing a payment integration: a sandbox-to-live checklist
The happy path is the easy part. A payment integration is ready for real money when it behaves correctly on declines, time-outs, duplicates and late confirmations — and you have proved it in the sandbox first.
How do you test a payment integration before going live?
Use the provider's sandbox to test every path, not just success: declined payments, abandoned and timed-out payments, late confirmations, refunds and duplicate webhook deliveries. Confirm your system records the correct final status in each case, that retries use idempotency keys, and that live keys are stored securely. Then go live with monitoring in place and a small, watched first batch of real payments.
- Test failure paths as thoroughly as the success path.
- Your system's final recorded status must match the provider's in every scenario.
- Keep sandbox and live keys separate, and never ship keys in client-side code.
- Go live gradually and watch closely.
Why the sandbox matters
A sandbox is a test environment that behaves like the live system but moves no real money. It lets you create payments, trigger outcomes and receive webhooks safely. Everything in this checklist should pass in the sandbox before a live key is used. Start at the Paynancial Sandbox.
Payment scenarios to test
| Scenario | What should happen in your system |
|---|---|
| Successful payment | Order marked paid once; confirmation sent once. |
| Declined payment | Order stays unpaid; customer sees a clear message and a way to retry. |
| Customer abandons checkout | Order stays pending, then expires or is followed up; nothing is marked paid. |
| Time-out, then success | Status shown as pending, then updated to paid when confirmed — no duplicate order. |
| Customer closes the browser after paying | Order still marked paid, via webhook or status check. |
| Customer pays twice | Duplicate detected and refunded; order not fulfilled twice. |
Webhook scenarios to test
- a valid webhook is accepted and processed once;
- a webhook with an invalid signature is rejected;
- the same webhook delivered twice has no extra effect;
- events arriving out of order do not move an order backwards;
- your endpoint being unavailable for a while is recovered by retries or your scheduled status check.
Details in Webhooks 101.
Refunds and payouts
- full and partial refunds update the order and your records correctly;
- a refund request retried after a time-out does not refund twice (see idempotency keys);
- for payouts: success, failure (for example invalid account details) and pending outcomes are each handled, and failed payouts are surfaced to a person.
Security checks
- API keys and webhook secrets live in server-side configuration, never in source code, mobile apps or browser code;
- sandbox and live credentials are separate and cannot be mixed up by configuration mistakes;
- access to live keys is limited to the people and systems that need them;
- logs do not record full card numbers, secrets or other sensitive data;
- amounts and currency are set on your server, never trusted from the browser.
Monitoring before you launch
- alerts for a drop in payment success rate or a rise in errors;
- alerts for webhook delivery failures and a growing processing backlog;
- a daily view of payments still pending after a reasonable time;
- a named person on call for the first days after launch.
Go-live day
- switch to live keys through configuration, not code changes;
- make a small real payment yourself and follow it end to end — order, webhook, settlement report;
- refund it and confirm the refund end to end;
- open to customers gradually if you can, and watch the first real payments closely;
- keep a simple rollback plan — for example, a switch back to your previous payment method.
Frequently asked questions
What is a payment sandbox?
A test environment provided by a payment provider that behaves like the live system but uses no real money, so you can build and test an integration safely.
What should I test besides successful payments?
Declines, abandoned checkouts, time-outs followed by late success, duplicate payments, refunds, and webhook edge cases such as invalid signatures, duplicates and out-of-order events.
Where should API keys be stored?
In server-side configuration or a secrets manager, never in source code, browser code or mobile apps. Keep sandbox and live keys separate.
How do I know my integration is ready to go live?
When every scenario in your test plan passes in the sandbox, your recorded statuses always match the provider's, secrets are handled securely and monitoring is in place.
This article is general information to explain concepts and good practice. It is not legal, tax, accounting or financial advice. Last updated 23 Sep 2026. Found something unclear or out of date? Tell us.