Whose money moves, and who may move it
Before you choose payout software, answer one question: whose money is being paid out?
- Your own money, from your own current account. A business paying its vendors, staff or customers from its own account through its bank's API is using a banking product. The software only instructs the bank.
- Other businesses' money, pooled and paid out. Collecting funds for merchants and paying them out is payment aggregation. RBI's Payment Aggregator Directions of 15 September 2025 require a non-bank aggregator to be authorised, to hold those funds in an escrow account with a bank, and to use that account only for purposes the Directions list, such as settling merchants and paying refunds.
This is general information, not legal advice. If your model pools money that belongs to others, have a lawyer map it against the 2025 Directions before you build. Payout software does not make an unregulated fund flow compliant.
Payonclick India is a technology and service provider. It is not a bank or a payment aggregator. In a white-label or custom build, the payout engine runs on your platform, against payout providers and bank accounts you contract for, and Payonclick India does not hold your funds.
How you can use the payout engine
| Route | What it means | Status |
|---|---|---|
| White-label platform | Retailer settlements and money transfer payouts inside your own branded platform | Available |
| Custom development | The payout engine added to your existing software for vendor, staff or customer payouts | Scoped per project |
| Payonclick partner payout API | Call Payonclick to pay out from your servers | Not offered |
For API transfers to supported banks from your own servers today, see the DMT API. It is a different product with different rules, explained in our guide to DMT versus payout APIs.
How the engine chooses a provider
Each kind of payout, such as money transfer, retailer settlement or UPI, has its own pool of payout providers in a set order. For every payout, the engine walks that pool:
Filter the pool
It skips a provider that is inactive or marked down, doesn't support the mode, can't take the amount, has reached its daily cap or isn't configured.
Send to the first eligible provider
The payout goes out under a unique reference.
Stop on success or pending
A success or a pending answer ends the walk. A pending payout is never sent to a second provider.
Move on after a failure
A failure sends the payout to the next eligible provider. UPI payouts can fall back to the money transfer pool.
Track provider health
Repeated failures mark a provider degraded and then down, so later payouts skip it.
If no provider is configured at all, the payout stays pending instead of being refunded. A configuration mistake can't turn into a false failure and a second payment.
Offline mode, re-hit and re-open
Not every payout can go out through an API the moment it is requested. The engine includes tools for your operations team.
Offline mode
Route a pool to the offline provider and every payout is held as processing, not failed, until your team acts on it.
Re-hit with a fresh reference
An admin re-hit claims the payout so no one else can act on it, sends it to a provider under a new reference such as <id>-R1, and returns it to offline if the provider rejects it.
Re-open a closed payout
An offline payout that was closed without a UTR can be re-opened for another attempt.
One person at a time
Manual actions such as check status, mark success or failed and re-hit take a short lock that shows who is working on the payout.
Accounts verified before money moves
- Penny drop. A very small credit to the account confirms it is valid and returns the name registered at the bank. The same verification serves money transfer beneficiaries and settlement accounts.
- Name match for settlement accounts. A retailer's settlement account is approved automatically only when the penny drop succeeds and the bank name matches at least 80%. Anything else waits for an admin.
- Unique references and a cooldown. Settlement requests carry a unique client reference and a short cooldown, so a double tap can't create two payouts.
Watching for stuck and wrong-status payouts
- Scheduled status checks. Pending money transfer payouts are re-checked every minute. A refund happens only when the provider confirms the failure, and a payout still unresolved after 72 hours moves to manual review.
- Provider notifications as hints. An incoming notification from a provider triggers a status check with that provider. It is never treated as proof on its own.
- Exposure watch. A watch job can re-ask providers about payouts marked failed, to catch a failure that later turns into a success.
- Admin consoles. Stuck payouts, disputes with refund and commission reversal, provider switching and settlement reports.
Rails and limits
The engine sends IMPS and UPI payouts. It doesn't offer NEFT or RTGS.
- IMPS. RBI raised the IMPS per-transaction limit to ₹5 lakh in its policy statement of 8 October 2021, as reported by Business Standard. Banks and providers can set lower limits.
- UPI. Person-to-person UPI payments stay capped at ₹1 lakh a day, according to News On AIR, and your bank or provider may apply a lower limit.
Configure each provider's amount limits and daily cap in the admin panel, so the engine never sends a payout a provider will refuse.