Introduction

DMT v2 supports domestic transfers after outlet onboarding, remitter registration and KYC, and the required beneficiary and transaction verification steps.

Connection and prerequisites

Use the base URL https://pay2new.in/apis/dmt/v2 and the exact method and path shown on each endpoint page. Every request requires these headers:

Header	Value
secret	Your Pay2New-issued API secret.
outletId	Active Pay2New customer/outlet ID from customer onboarding.
Content-Type	application/json for POST requests.

📘

Before you begin

Send requests from a registered source IP. Your account, KYC, wallet, API access and DMT service must be active, and the outlet must be enabled for remittance. Use the customer/outlet ID issued by Pay2New, rather than an identifier obtained directly from another provider.

Integration flow

1. Complete customer/outlet onboarding and retain the Pay2New outlet ID.
2. Call Remitter Profile with the remitter's mobile number. Read the current registration/KYC state and the returned reference or action.
3. If registration is needed, call Remitter Registration with the mobile number, Aadhaar number and current reference. Complete Remitter Registration Verify with the OTP issued for that request.
4. Complete Remitter KYC when required, using customer consent, fresh biometric PID data and the current reference.
5. Use Bank Details to obtain bank identifiers. Register the beneficiary with Beneficiary Registration, then complete Beneficiary Registration Verify when OTP verification is requested. Existing beneficiaries can be obtained from the remitter profile.
6. Request Transaction OTP for the remitter and intended amount. Retain the reference associated with this authorization.
7. Submit Fund Transfer with the account number, IFSC, configured DMT product code, amount, transfer mode, location, end-user IPv4 address, OTP and current reference. Supply your own request_id of at least eight characters.
8. Retain your request_id and the returned Pay2New order_id. Reconcile uncertain results through Transaction Status before initiating another transfer.

For beneficiary removal, call Beneficiary Deletion and complete Beneficiary Delete Verify if an OTP is issued.

Use each referenceKey with the remitter and operation that produced it. A reference from an earlier or different verification step may no longer be valid. Request and response field names are case-sensitive.

Request formats

POST bodies are JSON objects. Use strings for mobile numbers, Aadhaar, OTPs and account numbers so leading zeroes are preserved. Send decimal amount and location values in the format shown by the endpoint. bankId and product_code must use the numeric codes available to your account.

DMT v2 uses the beneficiary account number and IFSC for the transfer. The supported request values for transferMode are IMPS, RTGS and NEFT; the selected product and bank determine availability. Use the v2 request fields shown on each page.

Interpret the result for the current step

Status	Meaning
1	The current operation succeeded or was accepted. Check the response for any remaining KYC or verification action.
2	Rejected or failed. Read message and, when returned, errors.
3	An unresolved/pending transfer result. On nonfinancial operations it can have another meaning, including remitter not found during profile lookup.
4	OTP sent. Complete the matching verification step.

The HTTP status alone does not establish the application result. Read the JSON body. Nonfinancial response data depends on the operation and outcome, and not every response includes the same nested fields.

🚧

Reconcile an uncertain transfer

After a timeout or an unresolved transfer result, keep the original references and check Transaction Status. Do not immediately create another transfer or assume that resending the original request is idempotent.

Complete endpoint directory

Operation	Method and path
Bank Details	GET /apis/dmt/v2/bankList
Remitter Profile	POST /apis/dmt/v2/remitterProfile
Remitter Registration	POST /apis/dmt/v2/remitterRegistration
Remitter Registration Verify	POST /apis/dmt/v2/remitterRegistrationVerify
Remitter KYC	POST /apis/dmt/v2/remitterKyc
Beneficiary Registration	POST /apis/dmt/v2/beneficiaryRegistration
Beneficiary Registration Verify	POST /apis/dmt/v2/beneficiaryRegistrationVerify
Beneficiary Delete	POST /apis/dmt/v2/beneficiaryDelete
Beneficiary Delete Verify	POST /apis/dmt/v2/beneficiaryDeleteVerify
Transaction OTP	POST /apis/dmt/v2/generateTxnOtp
Fund Transfer	POST /apis/dmt/v2/fundTransfer

📘

Use the current v2 contract

These 11 pages describe DMT v2. Legacy /apis/dmt/v1 routes have a different registration/OTP contract and must not be mixed into this flow. The current v2 suite does not expose separate remitterLimit, remitterUpdate or refund-OTP endpoints; profile supplies the available limits.

Keep references separate

Reference	Correct use
Profile referenceKey	Current remitter journey/authorization context. Refresh after registration or KYC.
Registration / beneficiary referenceKey	Only the matching OTP-verification operation.
Transaction OTP referenceKey	Fund Transfer with its OTP, remitter and intended amount.
request_id	Your own transfer reference (minimum 8 characters). Status lookup uses client_txn_id with this value.
order_id	Pay2New transaction reference. Nonfinancial management calls normally return null; KYC/transfer can create a reference.

A status 3 profile response can mean remitter not found; a status 3 transfer is unresolved. Read the operation, message and data together. status: 4 means OTP sent and never establishes that money moved.

Transfer reconciliation

Use Transaction Status and MONEY_TRANSFER webhooks. The synchronous transfer response has data.request_id and data.bank_reference; a webhook instead uses top-level client_request_id and operator_reference. Both refer to the stored transaction; match order and amount before applying an update.

Profile limits and bank capability flags are dynamic. The sample limits and bank/product IDs are not entitlements or routing defaults. This Pay2New implementation supports FINGER remitter KYC; a provider face-auth flag does not add a face-auth request mode.