Collecting money gets most of the attention in payments, but plenty of businesses move as much money out as in: marketplaces paying sellers, lenders disbursing loans, insurers settling claims, employers paying staff, online stores refunding by bank transfer. Doing that from a bank's net banking screen works for ten payments a day. At a thousand, you need software to send them, track them and prove they arrived. That's what a payout API is for.
This guide explains how payout APIs generally work in India, for developers and finance teams planning an integration. Field names and endpoints differ between providers, so it describes concepts; your provider's documentation has the specifics.
What businesses use payout APIs for
The same API serves very different jobs, and each puts weight on different parts of the flow:
| Use case | Typical pattern | What matters most |
|---|---|---|
| Customer refunds by bank transfer | One-off, small to medium amounts | Speed, and linking each refund to its order |
| Vendor and supplier payments | Scheduled runs, medium to large amounts | Beneficiary validation, approvals, UTRs for proof |
| Salaries and reimbursements | Large monthly batches | Bulk handling, partial failures, timing |
| Marketplace seller payouts | Frequent, many beneficiaries | Reconciliation against collected funds and fees |
| Loan disbursals and insurance claims | Individual, often large | Validation of the borrower's or claimant's account, audit trail |
| Cashbacks, rewards and gig-worker payments | High volume, small amounts | Cost per payout, UPI support, instant credit |
How the pieces fit together
A payout passes through several systems between your database and the recipient's account:
- 1Your systemDecides who to pay, how much and why
- 2Payout API providerChecks the request, your balance and the beneficiary
- 3Banking partnerSends the transfer on a payment rail
- 4RailIMPS, NEFT, RTGS or UPI
- 5Beneficiary's bankCredits the account and confirms, with a UTR
The provider's job is to turn one consistent API into transfers across banks and rails, and to turn the banks' different responses back into one set of statuses for you.
Funding: where the money comes from
A payout can only go out if money is available to send. Providers handle this in a few ways, and the choice affects your operations:
- A prefunded payout balance: you move money into an account or balance with the provider, and payouts draw it down. You need to top it up before large runs.
- Your own current account, connected through the provider and its banking partner, so payouts debit it directly.
- For marketplaces and platforms, payouts from collected funds are subject to the payment aggregator's rules on escrow and settlement; take advice on the right structure.
Whatever the model, set a low-balance alert well above a typical day's payouts. An unfunded balance is one of the commonest reasons payouts stall.
Beneficiaries: validate before you pay
A transfer to the wrong account is hard to recover, so the most valuable step in a payout flow happens before any money moves: checking the beneficiary.
- Collect the account number and IFSC, or a UPI ID.
- Validate the account. A penny drop sends a very small credit to confirm the account exists and returns the name held by the bank; our penny drop verification page explains how it works. For RTGS and NEFT, RBI has also required banks since April 2025 to offer their own customers a free beneficiary name look-up before sending.
- Compare the returned name with the name you hold, with sensible rules for initials and spacing, and send mismatches to a person to review.
- Store the validated beneficiary, and re-validate if the details change.
The payout request
A payout request typically carries the beneficiary, the amount, the rail (or an instruction to choose one), a narration or purpose, and a unique reference from your system. Treat that reference as sacred:
- Generate it before sending, store it with the payout, and use it as an idempotency key, so a retry after a timeout can't pay twice. Confirm how your provider handles a repeated reference.
- Put something meaningful in the narration, such as an invoice number, so the recipient can match the credit too.
- Save every reference that comes back: the provider's payout ID and, on success, the UTR.
Choosing the rail
Each rail has its own limits and timing. Some providers choose automatically; if you choose, these are the rules that matter:
| Rail | Limit | Speed | If the credit fails |
|---|---|---|---|
| IMPS | ₹5 lakh per transaction (most channels) | Instant, 24x7 | Reversed to the sender by T + 1 |
| UPI | ₹1 lakh per payment to a person in most cases | Instant, 24x7 | Reversed by T + 1 for transfers to a person |
| NEFT | No limit set by RBI | Credit within 2 hours of the half-hourly batch, 24x7 | Returned within 2 hours of the batch |
| RTGS | ₹2 lakh minimum, no maximum | Credit within 30 minutes, 24x7 | Returned within 1 hour |
Banks and providers can set lower limits of their own. Our comparison of IMPS, NEFT, RTGS and UPI explains the trade-offs for each kind of payment.
Statuses and webhooks
A payout rarely completes inside the API call that creates it. Design for a lifecycle:
| Status | Meaning | Your system should |
|---|---|---|
| Queued or created | Accepted by the provider, not yet sent to the bank | Hold the amount as committed |
| Processing | Sent to the banking system; final result unknown | Wait; never resend |
| Success | The beneficiary's bank confirmed the credit, usually with a UTR | Mark paid; store the UTR; notify the recipient |
| Failed | Didn't go through; money stays with you or comes back | Record the reason; fix and send a new payout |
| Reversed or returned | Sent, then returned by the beneficiary's bank | Match the return to the original; fix details; resend |
Take statuses from the provider's signed webhooks, verify every signature, and handle duplicates and out-of-order events; our guide to payment gateway webhooks covers the techniques, which apply equally to payouts. Back them up with a scheduled status check for payouts still processing after a set time. When one sits at processing for a while, our guide to payouts stuck in pending explains what's happening and what not to do.
Why payouts fail, and what to do
Map your provider's failure codes into groups you can act on:
| Group | Typical cause | Action |
|---|---|---|
| Invalid beneficiary | Wrong account number, IFSC or UPI ID | Re-validate with the beneficiary |
| Account can't be credited | Account closed, frozen, dormant or of a type that can't receive this transfer | Ask the beneficiary for another account |
| Limit | Above the rail's limit, or a bank's own limit | Use another rail or split where appropriate |
| Bank unavailable or timed out | The beneficiary's bank or a partner was down | Wait for the final status; don't resend with a new reference |
| Insufficient balance | Payout balance not funded | Top up; alert earlier next time |
| Returned after success | The beneficiary's bank returned the funds | Match the return; contact the beneficiary |
Bulk payouts
Salaries, seller settlements and claim runs mean hundreds or thousands of payouts at once. Whether you send them one API call at a time or as a batch, each payout needs its own reference and its own status, because some will fail while the rest succeed. Build for partial success: report each item, retry only the failed ones after fixing them, and never re-run a whole batch. Our bulk payout page describes batch payouts on our platform.
Controls that keep payouts safe
A payout API can move a lot of money quickly, which makes access control as important as code:
- Keep API keys on servers, never in apps or browsers; use separate keys for test and live; rotate them when people with access leave.
- Use maker-checker approval for payouts above a threshold and for any change to beneficiary details.
- Set daily and per-payout limits that match your business, so a bug or a compromised key can't drain your balance.
- If your provider offers it, restrict API access to your servers' IP addresses.
- Keep an audit log of who created, approved and changed what.
Reconciliation
Every successful payout should match a debit from your payout balance or bank account, and the recipient's credit, by its UTR. Every failure should show the money back with you, and every return should match its original payout. Do it daily: payouts that are out by a day are easy to fix; payouts that are out by a month are a project. Our reconciliation guide has a routine, and our guide to UTR and RRN numbers explains the references you'll be matching.
A test plan before going live
Test the unhappy paths in the provider's test environment:
| Scenario | Expected behaviour |
|---|---|
| Successful payout | Marked paid once, with a UTR |
| Invalid account | Fails before money moves; clear reason |
| Processing, then success by webhook | Stays processing; completes once |
| Webhook never arrives | Scheduled status check resolves it |
| Timeout, retried with the same reference | No second payout |
| Returned after success | Return matched to the original; balance credited |
| Batch with some failures | Per-item statuses; only failures retried |
| Balance runs out mid-batch | Remaining items fail cleanly; alert raised |
Questions to ask a payout API provider
Get clear answers before you build:
- Which rails do you support, and do you choose the rail or do we?
- How is the payout balance funded, and what alerts do you offer?
- How do you validate beneficiaries, and what does validation cost?
- What statuses do you return, and how are webhooks signed and retried?
- How do you treat a repeated reference?
- How quickly do payouts reach a final status on each rail, and how are returns reported?
- What approval workflows, limits and access controls does your dashboard support?
- What reports do you provide for reconciliation?
Our payouts page describes LILPE Payouts, including the rails supported and payout statuses on the dashboard and by webhook.
Frequently asked questions
What is a payout API?
An interface that lets a business's systems send money to bank accounts or UPI IDs automatically, over IMPS, NEFT, RTGS or UPI, and receive each transfer's status and UTR.
Which payment rail should a payout use?
IMPS or UPI for urgent, smaller amounts (IMPS up to ₹5 lakh), NEFT for routine transfers with no RBI limit, and RTGS for large amounts of ₹2 lakh or more. All four run 24x7.
How do I avoid paying someone twice?
Send a unique reference with every payout and reuse it on retries, so the provider can reject a duplicate. Never resend a payout that's still processing; wait for its final status.
Why validate a bank account before a payout?
Because a transfer to the wrong account is hard to recover. Validation confirms the account exists and returns the account holder's name, so you can catch typos and mismatches before money moves.
Can a payout API send money to UPI IDs?
Many can. A UPI payout credits the account linked to the UPI ID instantly, within UPI's limits, typically ₹1 lakh per payment to a person. Check which rails your provider supports, and validate the UPI ID before the first payout.
What is maker-checker for payouts?
A control where one person creates or changes a payout or beneficiary and a second person approves it before money moves. It's one of the most effective protections against both mistakes and fraud such as changed vendor bank details.
What is a UTR in a payout?
The unique transaction reference the banking system gives a successful transfer. Store it with the payout; the recipient's bank can find the credit with it.
Official sources
- NPCI — IMPS overview and FAQsIMPS per-transaction limit ₹5 lakh for all channels except SMS and IVR; 24x7.
- RBI — FAQs on NEFT24x7 in half-hourly batches; no RBI limit; credit within two hours; return within two hours.
- RBI — FAQs on RTGS₹2 lakh minimum, no maximum; credit within 30 minutes; return within one hour.
- RBI — Harmonisation of Turn Around Time and customer compensation for failed transactions (20 Sep 2019)IMPS and UPI P2P: reversal by T + 1 where the beneficiary isn't credited.
- RBI — Introduction of Beneficiary Bank Account Name Look-up Facility for RTGS and NEFT Systems (30 Dec 2024)Free name look-up for remitters by 1 April 2025.
- RBI — Reserve Bank of India (Regulation of Payment Aggregators) Directions, 2025Escrow and settlement rules that apply where payouts are made from collected funds.
Last reviewed . Examples, amounts and screens marked illustrative are not LILPE figures.
