Payonclick Developer Docs
v1

Initiate Transfer

POST https://payonclick.in/ext/v1/dmt/transfer
Requires transfer Signed request Counts toward your 60 req/min

Initiate an IMPS transfer


Body Params

NameTypeDescription
sender_token required string
beneficiary_id required int From /beneficiary/add
amount required number Within the limits returned by GET /balance (currently ₹100 – ₹50,000)
tpin required string Your account TPIN
client_reference optional string Your unique id — the idempotency key. Optional, but send it: it is what makes a retry safe. Max 48 chars, letters/digits/hyphen/underscore
remarks optional string

Responses

StatusDescription
201 Created Initiate an IMPS transfer — see the example on the right.
200 OK · replayed Alternate outcome for the same call — the second Response tab.
4xx / 5xx { "success": false, "error": { "code": "…", "message": "…" } } — every code is listed under Error Codes.
🔏
This call must be signed

POST carries an X-Signature header over POST\n/ext/v1/dmt/transfer\n{TIMESTAMP}\n{BODY_SHA256}. The samples on the right compute it for you; the rules are in Request Signing.

📘
Good to know

request_id is our identifier for the transfer — the literal string we return, currently 24 characters like VVN178645657668598151B51. Store it as opaque text and do not parse or pattern-match it; the shape is not part of the contract.

Send a client_reference and a timeout becomes safe to retry. Re-sending the same value returns the original transfer with duplicate: true and moves no further money — the uniqueness is enforced by a database index inside the same transaction as the wallet debit, so even two genuinely simultaneous requests can only ever produce one transfer. The reference is scoped to your account: another partner using the same string does not affect you. Omitting it still works for backwards compatibility, but then a retry will send money twice — recover with GET /transfer/by-client-reference/{client_reference} or GET /transactions instead of resending.