What the DMT API covers
The DMT API gives your platform the sender, beneficiary and transfer steps of a domestic money transfer. It uses the same API key, request signature and response format as our BBPS and verification APIs, so one integration pattern covers all three.
| Group | Endpoints | What they do |
|---|---|---|
| Sender | POST /sender/check, POST /sender/verify-otp, POST /sender/register, GET /sender/{mobile} |
Send and verify the sender's OTP, register a new sender, read a sender with their beneficiaries |
| Beneficiary | POST /beneficiary/verify, POST /beneficiary/add, DELETE /beneficiary/{id}, GET /banks |
Verify an account by penny drop, add or remove a beneficiary, list the supported banks |
| Transfer | POST /charges, POST /transfer, GET /transfer/{request_id}, GET /transfer/by-client-reference/{ref} |
Preview the charge, create a transfer, read its status by our ID or by yours |
| Account | GET /transactions, GET /balance |
Transfer history, and your balance with the limits in force |
Every path sits under /ext/v1/dmt on payonclick.in. The API reference documents each field, with request samples that compute the signature for you.
How a transfer flows
Check the sender
POST /sender/check sends an OTP to the sender's mobile number.
Verify the OTP
POST /sender/verify-otp returns a sender_token valid for 30 minutes. A new sender is registered with POST /sender/register.
Verify the beneficiary
POST /beneficiary/verify runs a penny drop, so you can compare the name at the bank with the name your user gave.
Add the beneficiary
POST /beneficiary/add saves the account against the sender.
Create the transfer
POST /transfer sends the sender_token, the beneficiary, the amount, your account TPIN and your own client_reference.
Follow the status
GET /transfer/{request_id} returns the transfer as pending, successful with the bank UTR, or failed.
Service windows, supported banks and pending transfers
Read this before you design your customer experience. The DMT API is not an instant payout rail.
- Supported banks only. Transfers can go only to the banks returned by
GET /banks. Show that list to your users before they add a beneficiary. - Bank service windows. Each supported bank has service hours and working days, and a transfer is accepted only inside them.
- Completed by a transfer operator. Each transfer is assigned to a transfer operator on the Payonclick platform, who completes it and records the bank UTR. Until then the status stays pending.
- Money is held, not lost. The amount is held in your wallet when the transfer is created. If the transfer fails, the hold is released back to you.
Pending is normal for this API. Poll GET /transfer/{request_id}, or look up your own client_reference, and never create a second transfer for the same payment under a new reference. The DMT API sends no webhooks, so the status endpoints are your source of truth.
If your business needs to pay out its own funds straight away, a DMT API is the wrong tool. See our payout engine, and the guide to DMT versus payout APIs.
Limits and controls
- Limits from the API.
GET /balancereturns the minimum and maximum amount per transfer and the daily limit per beneficiary currently in force, so your app can validate an amount before sending it. - TPIN on every transfer. Each
POST /transfercarries your account TPIN, with a central lockout after repeated wrong attempts. - Scoped keys. A key needs the
transferpermission to verify beneficiaries and move money. Only whitelisted server IPs are accepted, and each key has its own rate limit, 60 requests a minute by default. - Signed requests. Every call carries a Bearer key and a timestamp accepted within five minutes of server time. Every POST and DELETE is signed with HMAC-SHA256 over the method, the path, the timestamp and the SHA-256 of the body.
Only a hash of your API key is stored on our side, and every call to the partner API is recorded in an audit trail with secrets redacted.
Idempotency and reconciliation
Networks time out, so every transfer carries your client_reference, up to 48 characters. If a request times out, send it again with the same reference. The API returns the original transfer with duplicate: true instead of creating a new one. If two identical requests race, only one transfer survives, and the other request's wallet hold is rolled back.
For daily reconciliation, GET /transactions returns your transfer history, and every transfer can be read back by our request_id or by your client_reference. Match successful transfers against their UTRs, and keep pending ones open until they settle.
Use one client_reference per business payment, such as PAY-<your order id>. It makes a retry safe and gives your support team one reference to search for.
Compliance: who is responsible for what
Cash-based domestic money transfer in India follows RBI's framework for domestic money transfer, most recently revised by RBI/2024-25/52 with effect from 1 November 2024. It sets expectations on registering the remitter, an additional factor of authentication for each transaction, and the remitter details carried with each remittance.
Payonclick India is a technology and service provider, not a bank. If you serve walk-in customers through this API, confirm your own obligations with your legal adviser before launch, including how you verify senders, record consent and handle complaints. Our guide to RBI's cash remittance rules for DMT APIs explains the framework.
Getting access
Register and complete KYC
Create a Payonclick account, complete business KYC and tell our team you want DMT API access.
Create an API key
Under Developer, API Keys, grant the transfer permission and whitelist your server IP.
Build against the read endpoints
Start with GET /balance, GET /banks and the sender lookup. They move no money.
Fund and go live
Add balance to your wallet and send your first small transfer to a supported bank.
There is no sandbox host, so keys are issued live. Commercial terms depend on your use case and volume, and our team shares them after you send the enquiry below.