Upload a file or call the API. Every recipient gets their own record, their own status and their own reason code if something fails — instead of one bank statement line you spend a morning unpicking.
How it works
Drop a CSV into the dashboard, or POST the batch to the API. No integration is required to run your first payout.
Account numbers, IFSC codes and UPI IDs are validated up front. Bad rows are flagged for correction rather than failing silently halfway through the run.
Where maker-checker is enabled, a second authorised user approves the run before funds leave the account. One compromised credential cannot move money.
Each payout has its own lifecycle — queued, processing, processed, failed, reversed — with a webhook on every change and a reason code on anything that fails.
Capabilities
Upload a file or call the API. Payouts go to bank accounts or UPI IDs, with a webhook on every state change so your ledger stays current without polling.
For teams paying vendors, partners, contractors or refunds in volume, who need an audit trail per transaction rather than a bank statement to unpick.
CSV in, itemised result out, with per-row status
REST endpoints with idempotency keys
Pay to a UPI ID without collecting bank details
Recurring payouts for payroll and retainers
Callbacks on queued, processed, failed and reversed
Maker-checker before funds leave the account
Every payout request accepts an idempotency key. If your service times out and retries, or a deploy replays a queue, the second request returns the original result instead of sending the money again.
This is the single most important property of a payout API and the one most often missing. Double-paying a vendor is recoverable. Double-paying two thousand of them is a very bad week.
A payout can be returned by the beneficiary bank after it has left — a closed account, a name mismatch, a frozen account. That reversal arrives as a webhook and a distinct status, not as an unexplained credit appearing in your account days later.
Your ledger can then reflect what actually happened, rather than what you assumed happened at the point of submission.
Scheduled runs handle the payments that repeat — salaries, retainers, partner commissions. Set the schedule once and the run executes on the date, with the same approval and validation applied.
Where the recipient list changes month to month, upload the revised file and the schedule uses it.
Questions
Batch limits depend on your account configuration and risk profile rather than being fixed for everyone. Tell us the size of run you need and we will confirm what your account supports before you build against it.
No. Uploading a CSV from the dashboard runs payouts without any code. The API exists for when you want payouts triggered by your own systems rather than by a person.
It is flagged during validation and excluded from the run. The rest of the batch proceeds. You get an itemised result file showing which rows went through and why any were rejected.
A payout can be cancelled while it is queued and awaiting approval or processing. Once it has been submitted to the banking network it cannot be recalled — at that point the only route is a return from the beneficiary bank.
One authorised user creates the run, a second approves it. The two cannot be the same person. It is optional, and worth enabling for any account where more than one person has access.
TrustPay is built so these work together. Money in, money out, and the ledger in between.
Your volume, category, payment methods and settlement cycle. Four answers and you have a rate.