Secure bill payment API keys across your application
Choose least-privilege API scopes, separate sandbox and production secrets, and prepare a key replacement process that preserves unresolved purchases.
Already registered? Open API settings and follow the business-access steps. Sandbox purchases do not deliver real services.
Reviewed
Your mobile app needs to request a top-up; it does not need the secret that lets your business buy top-ups. Keep that secret on your server and have the client call an authenticated endpoint in your own application.
Separate the credentials and their purpose
Use sandbox credentials with the sandbox API base URL during development. Production keys belong only in the server environment that processes authorized live orders. The documented prefixes are sk_test_ and sk_live_; keep them as literal strings when validating environment configuration.
Choose scopes for the work a key needs to perform. A catalogue-only process can use view_products. An airtime integration needs product discovery, the relevant purchase permission and transaction reads for recovery. Add read_balance only to a process that needs the balance endpoint.
| Secret | Where it belongs | What it should not become |
|---|---|---|
| Partner API key | Your server's secret configuration | A browser bundle, mobile constant or public example |
| Webhook signing secret | Your webhook receiver | An API bearer token |
| Sandbox test key | An isolated testing environment | A shared screenshot or exported collection |
| Customer session credential | Your own application boundary | Authority to choose another customer's order |
Protect the server endpoint as well
Hiding a key is only one part of the boundary. Authenticate the customer, authorize access to their order and calculate the accepted product and amount on your server. A client should not be able to submit an arbitrary product ID with another user's order reference.
Keep authorization headers out of request logs and exception reports. Redact secrets before support screenshots or shared request examples leave your team. Keep only the operational identifiers needed to investigate a problem.
Plan a replacement before an incident
The authentication reference says regenerating a secret invalidates the old value immediately. Prepare the configuration change and worker rollout before using that action. For a planned replacement, confirm the supported key-management path, test the replacement with a harmless read and revoke or disable the old credential when the transition is complete.
If exposure is suspected, stop using the exposed key and follow your incident process. Preserve unresolved order references while changing credentials. A new key does not make it safe to recreate a purchase whose outcome is unknown.
IP restrictions can help when your servers have known outbound addresses. The interactive API reference sends requests from RizPay's server, so its source address differs from your own server. Test that distinction without weakening the restrictions on production credentials.
Before launch, verify that your built client assets contain no partner secret and that a read-only key cannot initiate a purchase.