Most AEPS integrations start with cash withdrawal: the customer authenticates with a fingerprint, their bank debits the account, and the retailer hands over cash. Cash deposit runs the other way. The customer gives the retailer cash, and the retailer's platform credits the customer's Aadhaar-linked bank account. For rural customers without a nearby branch, that turns a retail counter into a place to put money into the bank, not only to take it out. This guide explains the flow as it runs on the Payonclick AEPS partner API, and what your platform has to get right.
What AEPS cash deposit does
The Aadhaar Enabled Payment System, run by NPCI, lets a customer bank at a business correspondent's counter with their Aadhaar number and biometrics. Cash deposit is one of its transaction types:
- The customer gives the retailer cash and their Aadhaar number, and chooses their bank.
- The customer authenticates with a fingerprint or iris scan on a registered RD device.
- The amount is debited from the retailer's balance on the platform.
- The customer's bank credits the amount to their Aadhaar-linked account.
The retailer keeps the cash, and their platform balance pays for the deposit. For the retailer, it is the mirror image of a withdrawal, where the platform balance is credited and the drawer pays out cash.
The money flow is the reverse of a withdrawal
That reversal is the most important design point. In a withdrawal, your platform credits the outlet only after the bank confirms, so a failure costs nothing. In a deposit, the money must leave your outlet's balance before the bank is asked to credit the customer, or the outlet could deposit money it doesn't have.
| Step | Cash withdrawal | Cash deposit |
|---|---|---|
| Before the bank call | Nothing moves | The amount is debited from the AEPS wallet |
| Bank success | The AEPS wallet is credited | Nothing more moves; the debit stands |
| Bank failure | Nothing to undo | The debit is refunded |
| No final answer | Stays pending, nothing credited | Stays pending, the debit stays held |
On the Payonclick API, a deposit is debit-first: POST /ext/v1/aeps/cash-deposit debits your AEPS wallet before the bank is called. A confirmed failure refunds exactly that debit. A timeout or an unclear reply never refunds automatically, because the customer's bank may still have credited the account.
Never refund a pending deposit on a guess. If the bank did credit the customer, a refund means the outlet keeps both the cash and the money. Wait for the status check to give a final answer.
Onboarding outlets for cash deposit
Cash deposit uses the same outlet onboarding as the rest of the AEPS API. Each outlet is a merchant under your partner account:
Register the outlet
POST /ext/v1/aeps/merchants with your own merchant_ref.
Outlet eKYC
The outlet's OTP and biometric eKYC.
Bank eKYC
The bank-side eKYC, with send, verify and biometric steps.
Daily authentication
POST /merchants/{merchant_ref}/daily-auth once a day before the outlet transacts.
Deposit
POST /ext/v1/aeps/cash-deposit with the customer's Aadhaar, bank, PID block, amount, your TPIN and your own client_reference.
GET /ext/v1/aeps/merchants/{merchant_ref} returns a next_step field, so your app always knows which onboarding step an outlet is on.
Limits and rules
- Amount. ₹100 to ₹10,000 per deposit, in whole rupees.
- Funding. Your AEPS wallet must hold the amount when you call the API; withdrawals and Aadhaar Pay at your outlets fund it.
- Authentication. Fingerprint or iris on a registered RD device. Face authentication is only for the outlet's daily authentication.
- No Aadhaar OTP. The step-up OTP above ₹5,000 applies to cash withdrawal and Aadhaar Pay, not to deposits.
- Cooling between withdrawal and deposit. A deposit for the same customer and bank shortly after a withdrawal at the same outlet can be refused, which stops a withdraw-and-redeposit loop.
- Customer's bank. The customer's bank must support AEPS cash deposit, and it may apply its own limits.
The API reference lists every field and response code.
Pending deposits and reconciliation
Deposits fail rarely, but some end without a final answer: a network timeout, a bank that replied late, an app that closed mid-call. Plan for them from day one.
- Use your own reference. Every deposit carries your
client_reference. If a request times out, read the deposit back withGET /transaction/by-client-reference/{client_reference}instead of sending a new one. - Follow the status. Poll
GET /transaction/{reference_id}or subscribe to theaeps.success,aeps.pendingandaeps.failedwebhooks. - Tell the customer the truth. A pending deposit means "the bank has not confirmed yet". The customer can check their account or SMS; the retailer should not accept a second deposit for the same money.
- Reconcile daily.
GET /transactionsreturns your history. Match each successful deposit against the debit in your AEPS wallet ledger, and keep pending ones open until they settle.
Our guide to idempotency and reconciliation covers the same pattern across payment APIs.
Compliance points for your network
AEPS is bank-led. From 1 January 2026, RBI's directions on due diligence of AePS touchpoint operators require acquiring banks to complete KYC of every operator, redo it after three months of inactivity and monitor operators by risk. The outlet onboarding, eKYC and daily authentication above give your network the records that support this. Every operator must onboard and authenticate with their own Aadhaar, never with a staff member's.
Payonclick India is a technology and service provider. Every transaction runs on regulated banks and networks.