Add bill payments to an existing Nigerian app
Evaluate and integrate RizPay bill payments inside an existing app while keeping customer authorization, payment collection and transaction reconciliation clear.
Already registered? Open API settings and follow the business-access steps. Sandbox purchases do not deliver real services.
Reviewed
An existing app already has something valuable: a relationship with its users. Bill payments can be useful when those users have a reason to return for airtime, data or household bills. Start by validating that use case with your own customers.
Choose a relevant first journey
A membership app might begin with airtime or data for its existing users. A platform whose users manage premises might investigate electricity payments. These are product choices to validate, not guaranteed demand. Interview users and identify the service they currently leave your app to purchase.
Select one category and map the full journey: product choice, payment, confirmation, delivery state and support. Avoid adding all categories at once if your team cannot yet investigate a single unresolved order.
Keep ownership of the customer experience
Your app authenticates its users and controls what they can buy. Your server calls RizPay with partner credentials. Never embed a partner secret in a React Native bundle or web browser; those clients are distributed to users and cannot hold a shared secret safely.
Keep existing account permissions and spending checks in force. A logged-in user should not be able to change another user's recipient or use a manipulated request to spend from an unauthorized account.
Fit the purchase into your ledger
A customer payment and an external bill purchase are related but different events. Store both with a durable order reference. If you already maintain balances, ensure the purchase and refund workflows use the same accounting rules as your other transactions.
A timeout is not a refund decision. A duplicate reference is not a fulfillment decision. Resolve the existing order and use the final transaction state to decide what to show and which financial effect is due.
Use the existing interface where it helps
Reuse your app's sign-in, order history and support entry points. Give bill payments their own product-specific confirmation fields. A prepaid electricity receipt needs a token; a data receipt needs the selected bundle and validity; a postpaid electricity receipt should not promise a token.
Show unavailable or pending states as normal operating states your app can handle. Do not leave the customer on a spinner indefinitely or remove the order when they close the screen.
Measure adoption and retention
Track the proportion of existing users who complete a first bill purchase and then purchase again. Review contribution by category after direct costs. If people browse the new menu but abandon at confirmation, investigate the product selection, total price and trust signals before adding more acquisition pages.
Use a controlled rollout and inspect unresolved orders during the initial launch. The aim is an additional service that your existing users can rely on.