Testing and go-live
Complete the full payout lifecycle in Sandbox before switching to Production. Validate environment setup, the four-stage flow, and callback handling before go-live.
Why complete validation in Sandbox first
Validate at least these baseline capabilities:
- whether the whitelist and environment domain are correct
- whether merchant credentials and signing work
- whether beneficiary data can be prepared according to the field template
- whether transfer requests can enter processing
- whether final results can be closed through webhooks or query APIs
If only part of this flow is tested, it is easy to reach production with requests that can be sent but not fully closed.
What to validate
- Request signing works consistently
beneficiaryIdcreation, reuse, and query flows behave correctly- Webhook notifications arrive after payout submission
- Active queries can recover unresolved orders
- Successful orders can download vouchers when needed
Additional checks worth including
Beyond simply proving that the happy path works, it is also worth validating:
- idempotent handling under repeated notifications
- recovery logic for exceptional states
- how failure reasons are stored and surfaced internally
- whether the mapping between
payer,beneficiary, and business order IDs is complete - whether voucher download, archiving, and later access meet your internal requirements
Recommended test sequence
- Verify environment, whitelist, and secret configuration
- Confirm the payout method for the target country, currency, and entity type
- Query the required fields for that combination
- Create a test beneficiary
- Submit a payout via
beneficiaryId - Receive the webhook and update the order status
- Run active queries for unresolved orders
- Download the voucher for successful orders
If your business will use both the beneficiaryId flow and the direct beneficiary-details flow, test both paths separately instead of validating only one.
Pre-launch checklist
- Production domain and whitelist configuration are confirmed
- Production secrets are stored securely
- Callback endpoints are publicly reachable
- The server supports signature verification, idempotency, and retry-safe handling
- The business system has a clear status lifecycle and exception recovery flow
- The final closure model is confirmed, whether webhook only, active query only, or both together
Common questions
When should merchantNo, keys, and callback URLs be confirmed
Ideally before joint testing starts, not at the last moment before go-live. Otherwise the integration often gets blocked by basic issues such as signature failures, whitelist drift, or unreachable callbacks.
What is most often missed before go-live
The most common gap is exception closure: webhook retries, active-query recovery, failure-reason persistence, and scheduled inspection for unresolved orders.
Is a successful synchronous response enough
No. A successful synchronous response does not mean the transaction has finished. You still need to validate the final status path through webhooks or query APIs.