How a B2B mobile recharge reaches the operator
A prepaid recharge sold by a business travels one of two roads.
- Operator distribution. A recharge API provider holds distribution arrangements with telecom operators and sells recharge to businesses through its API. Your platform sends the mobile number, the operator, the circle where the provider asks for it, the amount and your own reference. The provider answers
success,pendingorfailed, then confirms the final result by callback or through a status check. - Bharat Connect. RBI's BBPS Master Direction counts a notice for recharge of prepaid services as a bill, so Mobile Prepaid is a Bharat Connect category. A recharge paid this way carries a Bharat Connect transaction reference and uses the network's complaint process, but only operators live in the category can be paid.
| Operator distribution | Bharat Connect Mobile Prepaid | |
|---|---|---|
| Your contract | With a recharge API provider | With a platform or operating unit that reaches Bharat Connect |
| Operator coverage | Whatever the provider distributes | Operators live in the category |
| Final status | Provider callback or status API | Bharat Connect transaction status |
| Complaints | The provider's support process | A Bharat Connect complaint with the transaction reference |
Many platforms use both: operator distribution for everyday volume, and Bharat Connect where the operator is live and the customer needs a traceable reference.
Ways to offer recharge with Payonclick India
Be clear about what you are buying. Payonclick India does not sell a separate operator-distribution recharge API. Recharge is live for the retailers on the Payonclick app, and the same recharge module is part of our white-label and custom builds.
| Route | What it means | Status |
|---|---|---|
| White-label platform | Your own branded admin panel, retailer and distributor portal and Android app, with the recharge module connected to the providers you sign with | Available |
| Custom development | Recharge added to your existing software, or recharge features built to your specification | Scoped per project |
| BBPS API, Mobile Prepaid and DTH categories | Pay prepaid recharges as Bharat Connect bills from your own servers, for operators live in those categories | Live API |
| Operator-distribution recharge API from Payonclick | A recharge endpoint on the Payonclick partner API | Not offered |
| Distributor account | Sell recharge through shops you onboard on the Payonclick app | Available on payonclick.in |
What the recharge module does
The module runs live recharge for Payonclick retailers on the web portal and in the Android app. Everything below is in that production code today.
Several providers, one flow
Each recharge provider sits behind one common interface with its own operator code mapping. Admins set the primary provider for prepaid and for DTH.
Failover that won't double-charge
An optional failover pool tries the next provider only when the first request provably never reached the operator. A pending or timed-out recharge is never sent to a second provider.
Provider health
Repeated failures mark a provider degraded and then down, and the router skips it while it cools off. Admins can reorder providers and reset their health.
Checked callbacks
Every transaction gets its own HMAC token in its callback URL, checked together with the provider's IP allowlist. A wrong token is rejected even from an allowed address, and rejections alert the admins.
Scheduled status checks
A job re-checks pending recharges every two minutes, from two minutes to 24 hours after they were sent, within each provider's query limits.
Complete API logs
Every stage of every provider call is logged with credentials masked, and admins can open the log for any transaction.
Pending is not failed
The most expensive recharge bug is treating a slow answer as a failure. An operator can confirm a recharge seconds or minutes after the provider first replies pending. If the platform refunds the retailer and the customer tries again, the number can be recharged twice, and the platform absorbs the loss.
The module is built around that risk:
- The wallet is locked before the provider call. The recharge amount is held under a unique reference before the request leaves the platform.
- Pending stays pending. A pending recharge is never re-sent and never moved to another provider. Only the provider's callback or a status check settles it.
- Refunds follow a confirmed failure. The held amount is released only when the provider confirms the recharge failed, and only once, under its own reference.
- Late reversals are handled. If a provider turns a success into a failure later, the transaction and the wallet are reversed automatically.
Never add an automatic retry for a pending recharge, in an app or in an API client. Show the pending status, and let the callback or the status check settle it.
Our guide to pending status and callbacks in recharge APIs walks through the full state model.
What you need before you launch
- Provider contracts in your company's name. For a white-label or custom build, you sign with the recharge providers you choose and pay their onboarding costs and transaction charges directly. We connect their keys to your platform.
- A reviewed wallet design. Retailers usually recharge from a prepaid wallet. Under RBI's Master Direction on prepaid payment instruments, a closed-system instrument can only buy the issuer's own goods and services. A wallet that pays third parties or can be cashed out falls in a different category. Have your wallet design reviewed by a legal adviser.
- KYC of your network. Decide how retailers and distributors are verified before they transact. The platform includes KYC review, DigiLocker document fetch and eSign agreements.
- Daily reconciliation. Match your platform's recharges against each provider's statement every day, and investigate every mismatch before it ages.
Getting started
Tell us your model
White label, custom build or Bharat Connect categories, plus the operators and the volume you plan for.
Share your provider plans
Which recharge providers you have signed or plan to sign. Contracts and credentials stay in your name.
Receive the scope
We send the scope, the delivery phases and a commercial proposal for your build.
Build, test and go live
We connect your provider keys, run acceptance testing with your team and train your admins.