Test the RizPay bill payment API with Postman
Import the RizPay collection, set sandbox variables safely and test catalogue reads, purchases and recovery without running live payment requests.
Already registered? Open API settings and follow the business-access steps. Sandbox purchases do not deliver real services.
Reviewed
Postman is useful for inspecting the actual request and response before you build a server client. Keep the first session narrow: establish sandbox access, read a product and understand one purchase's lifecycle.
Import the collection and inspect its variables
Download the RizPay Postman collection and import it into your chosen workspace. The checked-in collection uses baseUrl and bearer authentication through bearerToken.
| Variable | Sandbox value |
|---|---|
baseUrl | https://my.rizpay.app/api/partners/sandbox/v1 |
bearerToken | Your own sandbox key, beginning with sk_test_ |
Store the token using your Postman setup's private secret-handling option. Confirm what is shared or synced before adding it. Do not paste a key into the collection description, an exported JSON file or a screenshot.
Check the fully resolved URL and authorization for each request before sending it. A collection-level default can be overridden by an environment or individual request. Keep production testing in a separate, deliberate process.
Begin with requests that do not purchase
Read health, account balance and the relevant product catalogue first. Use a key with the required scopes and inspect the response shape. An example product ID in the collection is a placeholder for your own returned selection, not a universal identifier.
Use pagination where needed and inspect network or service values on the selected product. For electricity, read the distributor and verify the customer's intended meter type; do not infer them from the first catalogue result.
Run one controlled sandbox order
Follow the first-purchase walkthrough. Select a configured fixture, use an amount within the chosen product's limits where applicable, and generate a fresh valid external reference for that new test order. Save the returned transaction ID.
Do not run the entire collection unattended. It contains purchase operations, and repeated runs can submit additional test orders. Repeating the same order to investigate a lost response should use its stored reference, not a newly generated one.
Inspect pending and final statuses separately. For the configured pending-failure scenario, allow its delayed transition; the sandbox query action currently completes any pending transaction as successful, so pressing Query changes that test's outcome.
Keep a useful test record
Record the method, endpoint, expected result and observed status without copying keys or private recipient data. Save sanitized examples for your server integration. Postman success proves a particular request worked in that environment; it does not implement customer authorization, durable orders or reconciliation for your application.
Before moving to code, demonstrate one successful sandbox purchase, one unresolved response path and one deliberate validation failure.