Sending money out: how business payouts work

A payment gateway brings money in. A payout sends money out: from your business to a customer, a supplier, an employee, a borrower or a partner. The two look similar on a bank statement, but they're run very differently. When you collect, the customer approves the payment. When you pay out, you do, so the checks, controls and records are yours to get right.

Before you can pay out, the money has to be available. Depending on the setup, payouts are funded from a balance you top up in advance or directly from your own current account. Which model applies to you is settled during onboarding.

Every payout passes the same seven steps. Most take seconds on a real-time rail. Knowing them tells you where a stuck or rejected payout actually is, and who can move it.

A beneficiary is whoever receives the money. You identify them in one of two ways: a bank account number with its IFSC, which works on IMPS, NEFT and RTGS, or a UPI ID, which works on UPI.

Validation catches mistakes before the money leaves. The two common methods differ in how they check. Penny drop sends a real ₹1 credit and reads back the name the bank holds. Penny-less verification confirms the account without moving money. Both return the account holder's name where the bank provides it, which you then compare with the name you expect.

India has four ways to move money between bank accounts. They differ in speed, in how they settle, in the amounts they carry, and in what happens when the credit can't be made. NEFT and RTGS are run by RBI; IMPS and UPI are run by NPCI.

The rail is usually picked from the amount and the beneficiary, and you can name one on a request. Which rails are available to you depends on your banking setup.

"24×7" means the rails accept transfers at any hour, including weekends and bank holidays. It doesn't mean every payout lands instantly. A NEFT payout waits for the next half-hourly batch. Real-time rails usually complete in seconds but can stall when a bank is slow. And your own approvals and funding can hold a payout before it's ever sent.

When you tell a beneficiary when to expect money, count from the moment the payout is sent, on the rail it's sent on, not from when it was approved.

A payout moves through a few states. Providers name them differently; what matters is which states are final. Processed, failed and reversed are final. Pending is not, however long it lasts.

Most payouts go straight through. The ones that don't fall into three groups, and each needs a different response. A failedpayout never left, so it's safe to fix and send again. A reversed payout left and came back. A pending payout is the dangerous one: the bank accepted it, but nobody knows yet whether the beneficiary was credited.

Some systems call these transfers "deemed" or "in doubt". The rule is the same: wait for the final status or ask for it, and don't resend. RBI's turnaround-time framework requires IMPS and UPI transfers that debited the sender without crediting the beneficiary to be reversed by the next day (T+1).

The mechanics are the same for every payout. What changes is who you're paying, how many at once, and what has to be true before the money goes.

Payouts move your money on your say-so, so the controls around them matter as much as the rails. These are the controls finance and risk teams usually insist on. Whether each is built into your setup or run in your own systems is worth confirming before you go live.

Payout pricing is usually per transfer rather than a percentage. The components are a fee per payout, which can vary by rail, a fee per beneficiary check if you validate accounts, and GST on those fees. Peneu pricing is quoted per business, so the numbers here are illustrative, or your own.

Separately, RBI has told banks not to charge savings-account holders for NEFT transfers made online (from 1 January 2020). Business current accounts are priced by the bank.

Reconciling payouts proves three things: every payout you intended was sent once, every debit on your statement belongs to a payout, and every returned or reversed payout was noticed. It's the same idea as reconciling collections, in the other direction.

Payouts can be sent one at a time from a dashboard, in bulk, or from your own systems through an API. For system-to-system payouts, a few rules decide whether the integration is safe on a bad day.

• Give every payout your own unique reference, and never reuse it for a different obligation. It's what makes a retried request safe.
• Store the payout's ID and status as soon as the request is accepted, before anything else happens.
• Treat a status notification as a prompt: fetch the payout's current status before acting on it.
• Retry only after a definite failure, and as a new payout. Never retry a pending one.
• Reconcile every day, including returns and reversals.

The same rails serve very different businesses. Here is where payouts usually fit, and where to read more.