# Testing and go-live

> Validate the Transfer integration in Sandbox and prepare the final production checklist.

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
- `beneficiaryId` creation, 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

1. Verify environment, whitelist, and secret configuration
2. Confirm the payout method for the target country, currency, and entity type
3. Query the required fields for that combination
4. Create a test beneficiary
5. Submit a payout via `beneficiaryId`
6. Receive the webhook and update the order status
7. Run active queries for unresolved orders
8. 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.

<tip>

If your business will submit payouts at scale, also validate batch queries, monitoring alerts, and reconciliation workflows before go-live.

</tip>

## Continue Reading

- [Setup](/transfer/get-started)
- [Request signing](/transfer/get-started/request-signing)
- [Integration flow](/transfer/get-started/integration-flow)
- [Change log](/transfer/get-started/change-log)