DMT — On Behalf of Your Merchants

Every DMT endpoint below is a real, callable route — POST {baseUrl}/process/dmt/... — encrypted with your partner API key (see Authentication & Security). Generated and cross-checked against BucksBox-Vendor.postman_collection.json.

Base URLs

e.g. production Customer Registration is POST https://api.bucksbox.in/gateway/process/dmt/customer/onboarding.

merchantId is required on every call

paymentSystem resolves the acting merchant as req.user?.merchantId ?? req.body.merchantId. Your partner API key resolves only req.vendorId, never req.merchantId — every request body below carries "merchantId" to say which of your merchants the call is for. Forget it and the call fails outright.

All bodies below are the plaintext you AES-256-GCM-encrypt into { "payload": "..." } — see Authentication & Security.

DMT Customer Registration (Remitter Onboarding)

This is the flow that registers a new customer as a DMT "remitter" — /process/dmt/customer/* — one-time KYC, run in order.

1. Get Detail — check if the customer already exists

POST https://api.bucksbox.in/gateway/process/dmt/customer/GetDetail
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{ "merchantId": "MERCHANT123", "mobile_number": "9876543210" }

{ "statusCode": "00", "message": "success", "data": { "referenceid": "REF-...", "...": "remaining fields are NSDL's customer record, not independently confirmed here" } }

statusCode: "00" with data means an existing, KYC'd remitter — skip to Remitter — Details. Not-found means run Registration below.

2. Registration — create the customer record

POST https://api.bucksbox.in/gateway/process/dmt/customer/onboarding
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{
  "merchantId": "MERCHANT123",
  "name": "Ravi Kumar",
  "mobile_no": "9876543210",
  "email_id": "ravi@example.com",
  "city": "Mumbai",
  "state": "Maharashtra"
}

{ "statusCode": "00", "message": "success", "data": { "referenceid": "REF-a1b2c3d4" } }

email_id is optional; name, mobile_no, city, state are required. This is the call that actually registers the customer — capture referenceid from the response, every step below needs it.

3. Request OTP

POST https://api.bucksbox.in/gateway/process/dmt/customer/request_otp
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{ "merchantId": "MERCHANT123", "referenceid": "REF-a1b2c3d4" }

{ "statusCode": "00", "message": "success", "data": { "otpreqid": "OTPREQ-..." } }

4. Validate OTP

POST https://api.bucksbox.in/gateway/process/dmt/customer/validate_otp
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{ "merchantId": "MERCHANT123", "otp": "123456", "otpreqid": "OTPREQ-...", "referenceid": "REF-a1b2c3d4" }

{ "statusCode": "00", "message": "success" }

5. Verify UID (Aadhaar)

POST https://api.bucksbox.in/gateway/process/dmt/customer/verify_UID
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{ "merchantId": "MERCHANT123", "aadhaarno": "999999999999", "referenceid": "REF-a1b2c3d4" }

{ "statusCode": "00", "message": "success" }

6. Update Biodetail

POST https://api.bucksbox.in/gateway/process/dmt/customer/updatebiodetail
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{ "merchantId": "MERCHANT123", "PidData": "<PidData XML from the RD service>", "aadhaarno": "999999999999", "referenceid": "REF-a1b2c3d4" }

{ "statusCode": "00", "message": "success" }

7. Submit — finalize registration

POST https://api.bucksbox.in/gateway/process/dmt/customer/submit
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{ "merchantId": "MERCHANT123", "referenceid": "REF-a1b2c3d4" }

{ "statusCode": "00", "message": "success", "data": { "...": "NSDL confirmation response, passed through" } }

NSDL confirmation — the customer is a usable DMT remitter once this succeeds.

8. Status Check

GET https://api.bucksbox.in/gateway/process/dmt/customer/statusCheck
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{ "merchantId": "MERCHANT123", "referenceid": "REF-a1b2c3d4" }

{ "statusCode": "00", "message": "success", "data": { "...": "NSDL onboarding-status response, passed through" } }

GET, but referenceid still travels in the encrypted body — query strings can't carry the encrypted envelope.

Remitter & Beneficiaries

/process/dmt/txn/v1/*. A first-time customer has no remitter yet — call Remitter Details, and if it comes back not-found, call Remitter Register then retry Remitter Details.

9. Remitter — Register

POST https://api.bucksbox.in/gateway/process/dmt/txn/v1/remitter/register
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{ "merchantId": "MERCHANT123", "sender_mobilenumber": "9876543210" }

{ "statusCode": "00", "message": "success", "data": { "senderid": "686a3388-78c4-4897-8590-f3c5b2faade2", "registrationFeeCharged": 5 } }

Send sender_mobilenumber or senderId — name/address/DOB come from the customer record created during Registration, not this call.

10. Remitter — Details

POST https://api.bucksbox.in/gateway/process/dmt/txn/v1/remitter/details
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{ "merchantId": "MERCHANT123", "sender_mobilenumber": "9876543210" }

{
  "statusCode": "00",
  "message": "sender found",
  "data": {
    "senderId": "686a3388-78c4-4897-8590-f3c5b2faade2",
    "status": true,
    "remitter": true,
    "TransactionDone": 0,
    "AviableLimit": 25000,
    "AviabledayLimit": 25000,
    "beneficiarydetail": [
      {
        "beneficiaryid": 16731,
        "beneficiaryname": "Balamurugan",
        "beneficiarymobilenumber": 0,
        "beneficiaryemailid": "",
        "bank": "DBS BANK LTD",
        "state": "KARNATAKA",
        "city": "BANGALORE URBAN",
        "branch": "INDIRANAGAR",
        "address": "GROUND FLOOR & FIRST FLOOR...",
        "ifscode": "DBSS0IN0753",
        "accountnumber": 8753210000020554,
        "beneficiarystatus": 1,
        "impsstatus": 1
      }
    ]
  }
}

AviabledayLimit = today's transfer ceiling; AviableLimit = what's still available right now (derive "used today" as the difference). The beneficiary list is embedded here — there's no separate list endpoint. beneficiarystatus: 1 means usable for a transfer.

11. Beneficiary — Add

POST https://api.bucksbox.in/gateway/process/dmt/txn/v1/beneficiary/add
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{
  "merchantId": "MERCHANT123",
  "senderId": "686a3388-78c4-4897-8590-f3c5b2faade2",
  "receivername": "Priya Sharma",
  "receivermobilenumber": "9876500000",
  "receiveremailid": "priya@example.com",
  "receiverIfscCode": "HDFC0001234",
  "receiver_account_no": "1234567890",
  "address": "123 MG Road",
  "city": "Mumbai",
  "state": "Maharashtra",
  "branch_contact": ""
}

{ "statusCode": "00", "message": "success", "data": { "beneficiaryid": 16731 } }

senderId, receivername, receiverIfscCode, receiver_account_no required; rest optional.

12. Beneficiary — Account Verification (Penny-Drop)

POST https://api.bucksbox.in/gateway/process/dmt/txn/v1/beneficiary/accountVerification
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{
  "merchantId": "MERCHANT123",
  "sender_mobilenumber": "9876543210",
  "senderId": "686a3388-78c4-4897-8590-f3c5b2faade2",
  "receiver_account_no": "1234567890",
  "receiverIfscCode": "HDFC0001234",
  "receivername": "Priya Sharma",
  "receivermobilenumber": "9876500000",
  "receiveremailid": "priya@example.com"
}

{ "statusCode": "00", "message": "success", "data": { "status": 1 } }

data.status: 1 = verified (proceed to Beneficiary — Add), 0 = failed, -1/91 = ambiguous/unknown (requery after 30s).

13. Beneficiary — Get

POST https://api.bucksbox.in/gateway/process/dmt/txn/v1/beneficiary/get
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{ "merchantId": "MERCHANT123", "senderId": "686a3388-78c4-4897-8590-f3c5b2faade2", "receiverIfscCode": "HDFC0001234", "receiver_account_no": "1234567890" }

{ "statusCode": "00", "message": "success", "data": { "beneficiaryid": 16731, "beneficiarystatus": 1, "...": "same per-beneficiary shape as remitter/details#beneficiarydetail" } }

14. Beneficiary — Delete

POST https://api.bucksbox.in/gateway/process/dmt/txn/v1/beneficiary/delete
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{ "merchantId": "MERCHANT123", "senderId": "686a3388-78c4-4897-8590-f3c5b2faade2", "receiver_account_no": "1234567890", "receiverIfscCode": "HDFC0001234" }

{ "statusCode": "00", "message": "Beneficiary deleted successfully" }

Transactions

15. Transaction — OTP

POST https://api.bucksbox.in/gateway/process/dmt/txn/v1/transaction/otp
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{ "merchantId": "MERCHANT123", "senderId": "686a3388-78c4-4897-8590-f3c5b2faade2", "amount": 500, "receiver_account_no": "1234567890", "receiverIfscCode": "HDFC0001234" }

{ "statusCode": "00", "message": "OTP sent successfully" }

Triggers NSDL to send an OTP to the customer's registered mobile — the code itself isn't returned to you.

16. Transaction — Instant Transfer

POST https://api.bucksbox.in/gateway/process/dmt/txn/v1/transaction/instant
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{
  "merchantId": "MERCHANT123",
  "senderId": "686a3388-78c4-4897-8590-f3c5b2faade2",
  "BeneficiaryId": 16731,
  "amount": 500,
  "refId": "REF-your-own-idempotency-key",
  "otp": "123456",
  "receiver_account_no": "1234567890",
  "receiverIfscCode": "HDFC0001234",
  "account_holder_name": "Priya Sharma",
  "receiverMobilenumber": "9876500000",
  "remarks": "Rent"
}

{ "statusCode": "00", "message": "Transaction successful", "data": { "rrn": "407812345678", "transactionId": "TXN-uuid", "amount": 500, "status": "SUCCESS" } }

otp comes from Transaction — OTP above. Combines OTP verification and the actual debit in one call — a wrong OTP and a genuine bank-side decline surface the same way (non-"00" statusCode).

17. Transaction — Charges

POST https://api.bucksbox.in/gateway/process/dmt/txn/v1/transaction/charges
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{ "merchantId": "MERCHANT123", "senderId": "686a3388-78c4-4897-8590-f3c5b2faade2", "amount": 500 }

{ "statusCode": "00", "message": "success", "data": { "charge": 5, "totalAmount": 505 } }

Fee preview before actually sending Instant Transfer.

18. Transaction — Requery

POST https://api.bucksbox.in/gateway/process/dmt/txn/v1/transaction/requery
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{ "merchantId": "MERCHANT123", "refId": "REF-your-own-idempotency-key" }

{ "statusCode": "00", "message": "success", "data": { "status": "SUCCESS", "rrn": "407812345678" } }

Use when Instant Transfer came back pending/ambiguous.

19. Transaction — Refund OTP

POST https://api.bucksbox.in/gateway/process/dmt/txn/v1/transaction/refundOTP
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{ "merchantId": "MERCHANT123", "refereanceId": "TXN-uuid" }

{ "statusCode": "00", "message": "OTP sent for refund" }

⚠️ Field name is genuinely spelled refereanceId (typo) in dmt.txn.controller.js#refundOTP — not a mistake here, that's what the backend reads.

20. Refund

POST https://api.bucksbox.in/gateway/process/dmt/txn/v1/refund
X-Client-Id: <your apiKey>

Plaintext body — encrypt with AES-256-GCM using your SaltAESKey (64-char hex or 44-char base64, both decode to 32 bytes) before sending as { "payload": "..." }:

{ "merchantId": "MERCHANT123", "transactionId": "TXN-uuid", "refId": "REF-...", "otp": "123456" }

{ "statusCode": "00", "message": "Refund processed successfully", "data": { "refundId": "RFD-uuid", "amount": 500 } }

otp comes from Transaction — Refund OTP above.

What's actually vendor-only — BC onboarding

DMT has one sub-area that runs the other direction: BC (business correspondent) onboarding acts on your own vendor/aggregator identity, not a merchant's:

These don't take merchantId and aren't proxied through the gateway's /process/* mirror in this documentation set — call them directly against paymentSystem with your own JWT if your account needs them.

Aggregator-only (not reachable by a partner credential)

POST /dmt/txn/v1/transaction/balance is restricted to the aggregator role — the aggregator's own NSDL settlement balance, not a customer/remitter balance. POST /dmt/txn/v1/login (merchant/vendor) exists but isn't part of the flow above — it bootstraps a separate NSDL BC session, analogous to AEPS's automatic Req Auth.

Supported Biometric (RD Service) Devices

PidData in Update Biodetail (both the customer-registration step and the beneficiary/remitter steps that need it) comes from the same UIDAI-certified RD service Intent contract AEPS uses — any UIDAI-certified device should work, since it's a standardized spec, not a proprietary one. One vendor has actually been built and tested against; the rest are named in the codebase but not yet confirmed on real hardware.

Full detail on the Intent contract itself — the actions, extras, and capture flow every RD service (any vendor) implements the same way — is on Merchant API → AEPS → RD Service Integration.