From a RizPay sandbox integration to production
Prepare a RizPay integration for live orders with business access, separate keys, tested recovery paths, verified webhooks and a clear reconciliation process.
Already registered? Open API settings and follow the business-access steps. Sandbox purchases do not deliver real services.
Reviewed
A successful sandbox purchase confirms part of an integration. It does not establish live biller availability, production latency, the cost of handling support or how a partner's own checkout behaves when something goes wrong.
Complete the account steps
Create or sign in to your RizPay account and open API settings. Complete the business-access steps required for your account before creating keys. Do not tell your own development team that simply registering a consumer account guarantees immediate production access.
Use separate keys and base URLs for sandbox and production. Sandbox uses /api/partners/sandbox/v1 and sk_test_ keys. Production uses /api/partners/v1 and sk_live_ keys. Keep keys in server-side secret configuration and grant only the permissions needed for the tested workflow.
Exercise the outcomes you will support
| Product | Success fixture | Pending fixture | Failure fixture |
|---|---|---|---|
| Airtime | 08011111111 | 08022222222 | 08044444444 |
| Data | 08011111111 | 08033333333 | 08044444444 |
| Cable TV | 1212121212 | 2020202020 | 3030303030 |
| Electricity | 11111111111 | 33333333333 | 44444444444 |
These are configured sandbox recipient identifiers. They simulate outcomes and must not be reused as real customer recipients in production. Check the current sandbox reference when testing; configuration can evolve. Arbitrary numbers can produce a default failure.
Verify your application's controls
Before a live order, your server must authenticate the customer, authorize the purchase, validate the selected product and confirm the amount. A request from a mobile app is not permission to spend a partner balance. Keep customer collection and the RizPay purchase as separate, reconcilable records.
Persist an order and reference before submitting. Test concurrent clicks, duplicate jobs, lost responses and a worker restart. Confirm that a pending result remains unresolved, a duplicate reference triggers lookup and a repeated webhook cannot cause another financial effect.
Prepare operations
Make the current product catalogue and final transaction status accessible to the people supporting the integration. Give them a way to investigate an existing order without manually creating a replacement purchase. Define who handles a missing receipt, a pending order and a mismatch between your ledger and the partner account.
Track rate-limit responses and use bounded retry policies for reads. Keep live secrets, raw webhook bodies and customer identifiers out of ordinary application analytics. Rotate a disclosed credential and investigate its use.
Enable live traffic deliberately
Use a separate deployment configuration for live credentials. Verify current catalogue prices and your commercial terms, then perform your own controlled live acceptance checks under an approved operating process. A passing test fixture is not permission to advertise a measured uptime or delivery-speed guarantee.
Measure the time to a first successful production purchase and whether the partner continues transacting. Keep sandbox activity out of production revenue and retention reports.