DMT and payout products both move money out through IMPS or UPI, and vendors often market them on the same page as if they were variations of one thing. They are not. Each answers a different question about whose money is moving and who is the regulated party behind it, and confusing the two leads either to an unlicensed platform pooling other businesses' funds, or to a simple business payment over-engineered as if it needed a banking correspondent network it does not.
Two different money flows
DMT: a walk-in customer hands over cash at a shop counter, wanting it credited to someone else's bank account. The remitting bank is the regulated party; the shop is a touchpoint inside that bank's business correspondent network. Our DMT API and RBI's cash remittance rules covers the framework the bank must apply.
Payout: a business that already holds funds, in its own account or in a pool it is licensed to run, wants to pay them out: salaries, vendor bills, refunds, winnings or reimbursements. There is no walk-in customer handing over cash; the "customer" is the payee receiving a disbursal the business initiates.
Comparison table
| DMT | Payout | |
|---|---|---|
| Whose money moves | A walk-in customer's cash, deposited at a BC counter | The business's own funds, or funds it holds under an escrow or aggregator arrangement |
| Who the "customer" is | The remitter handing over cash, and the beneficiary receiving it | The payee receiving a disbursal the business initiates |
| KYC obligation | The bank KYCs the remitter (verified mobile plus OVD) before the first transfer | The business KYCs the payee to whatever extent its own onboarding requires; no RBI-mandated remitter KYC applies |
| Typical limits | ₹5,000 / ₹25,000 for cash pay-in, ₹10,000 / ₹25,000 for cash pay-out, per RBI's 2011 circular | Rail limits apply, for example IMPS up to ₹5 lakh per transaction (RBI, 8 Oct 2021); UPI follows standard person-to-person limits, and a bank may set its own ceiling on either rail |
| Rails used | IMPS or NEFT, tagged as cash-based remittance | IMPS or UPI, chosen by the business or its provider |
| Who is regulated | The remitting bank, as principal of its business correspondent | The business's own bank, if paying from its own account, or an authorised payment aggregator, if pooling client funds |
| Typical user | A retail shop offering cash-to-account transfer to walk-in customers | A business paying its own vendors, staff, gig workers or customers |
Pooled funds and the 2025 Payment Aggregator Directions
The following is our own reading of how these categories apply, not a restatement of the Direction's text; confirm it with your legal adviser before relying on it. If a payout platform collects money from more than one business into one pooled account and pays it out on their behalf, that pooling is payment aggregation, not a service the paying business can run on its own current account. RBI's Payment Aggregator Directions, 2025 apply once pooling is involved: PA-P covers cases where the device and the payment instrument are physically close together, PA-O covers remote or online payments, and a payment gateway that never handles funds itself needs no such licence at all. Our fuller treatment is in RBI's Payment Aggregator Directions 2025 explained.
When your own bank's current-account API is enough
If every rupee a payout moves is the business's own money, paid from the business's own current account through a bank's own payout or corporate-API product, no aggregator arrangement is needed. The business is simply using its bank's product on its own account. This is the simplest and least regulated path, and it is the right one whenever no pooling of other businesses' money is involved.
When you need an authorised payment aggregator instead
A marketplace, a gig-economy platform paying many small counterparties, or any business that pools client funds before disbursing them, sits in payment-aggregation territory and needs an authorised payment aggregator behind the flow, either as the licence holder itself or as its technology partner. Position software here as running on top of an authorised aggregator's arrangement, never as a substitute for one.
Payonclick angle: the DMT API vs the payout engine
Payonclick offers two different things under these two names, and they are not interchangeable.
Our DMT API is a partner REST API for money transfer to supported banks, completed inside each bank's service window. The rules around cash remittance are covered in DMT API and RBI's cash remittance rules.
Our payout engine is not a public API. It is a module inside a white-label platform or a custom build, for a client that already holds its own bank relationship or aggregator arrangement. It routes each payout through a pool of providers, moving on only after a failure and never while a payout is pending. It has an offline mode in which an admin re-sends a held payout under a fresh reference, and it verifies beneficiary and settlement accounts by penny drop. Payouts move only by IMPS or UPI; NEFT and RTGS are not offered.