Production hosts

API base URL: https://nineteenapis.online — use this for all /api/, /pay/, and /webhooks/ calls.

Documentation only: https://public.nineteenapis.online — this host serves these HTML pages and Swagger; it does not proxy API traffic.

API V1 — legacy integration

Use this section if your credentials and integration use paths without /api/v2/.

V1 authentication

Send these headers on every V1 call:

  • X-API-KEY — your integration key (per pipe)
  • X-API-SALT — your integration secret
-H "X-API-KEY: YOUR_KEY" -H "X-API-SALT: YOUR_SALT"

API V1 — Native V1

Paths: /api/payments/nineteenpay-native/.... This is only Native V1 — not Native V2 and not the V2 /api/v2/payments/collect route. Gateway fields go inside a payload object. Amounts are typically in paise as strings unless your onboarding docs say otherwise.

POST /api/payments/nineteenpay-native/collect

Collect / intent / DQR

Required: payload with PAY_ID, ORDER_ID, AMOUNT (paise string), CURRENCY_CODE, TXNTYPE, MOP_TYPE, PAYMENT_TYPE, CUST_EMAIL, CUST_PHONE. Optional UPI_INTENT, PAYER_ADDRESS, etc.

Typical success (200)

{"success":true,"transactionId":"TSP_TXN_ID","status":"PENDING","intentUrl":"upi://pay?...","raw":{},"decrypted":{}}
POST /api/payments/nineteenpay-native/validate-vpa

Validate VPA

payload must include PAYER_ADDRESS.

Typical success (200)

{"success":true,"raw":{},"decrypted":{}}
POST /api/payments/nineteenpay-native/status

Status enquiry

payload.TXNTYPE must be STATUS.

Typical success (200)

{"success":true,"status":"SUCCESS","raw":{},"decrypted":{}}
POST /api/payments/nineteenpay-native/refund

Refund

payload requires PAY_ID, ORDER_ID, AMOUNT; PG_REF_NUM when applicable.

Typical success (200)

{"success":true,"status":"PENDING","raw":{},"decrypted":{}}
POST /api/payments/nineteenpay-native/refund-status

Refund status

payload requires PAY_ID, ORDER_ID.

Typical success (200)

{"success":true,"status":"SUCCESS","raw":{},"decrypted":{}}
POST /api/payments/nineteenpay-native/static-qr

Static QR

payload: PAY_ID, IDENTIFIER, RETURN_URL.

Typical success (200)

{"success":true,"raw":{},"decrypted":{}}

V1 — JPSL

POST /api/payments/jpsl/initiate-sale

Initiate hosted sale

amount, returnURL required.

Typical success (200)

{"success":true,"transactionId":"...","merchantTxnNo":"...","status":"PENDING","redirectURI":"https://...","tranCtx":"...","raw":{}}
POST /api/payments/jpsl/generate-qr

Generate UPI QR

amount required.

Typical success (200)

{"success":true,"transactionId":"...","qrString":"upi://pay?...","raw":{}}
POST /api/payments/jpsl/status

Status

merchantTxnNo, originalTxnNo, amount.

Typical success (200)

{"success":true,"status":"SUCCESS","raw":{}}
POST /api/payments/jpsl/refund

Refund

merchantTxnNo, originalTxnNo, amount.

Typical success (200)

{"success":true,"status":"PENDING","raw":{}}

V1 — Paytm Escrow

POST /api/payments/paytm/collect

Create collect / intent link

amount (number) required.

Typical success (200)

{"success":true,"transactionId":"...","collectRef":"...","status":"PENDING","crn":"...","link":"https://...","feeAccountBalance":0,"raw":{}}
POST /api/payments/paytm/status

Status (DB)

collect_ref_arr: array of collect references.

Typical success (200)

{"success":true,"results":[...]}

V1 — Payouts

POST /api/payments/payoutnp/balance

Balance

Optional environment.

Typical success (200)

{"success":true,"balance":123.45,"raw":{}}
POST /api/payments/payoutnp/verify-account

Verify account

number, accountNo, ifscCode, clientOrderId.

Typical success (200)

{"success":true,"status":"SUCCESS","beneficiaryName":"...","orderId":"...","clientOrderId":"CO-1","utr":"...","raw":{}}
POST /api/payments/payoutnp/transfer

Transfer

transferMode: IMPS|NEFT|RTGS|UPI; vpa required for UPI.

Typical success (200)

{"success":true,"transactionId":"...","status":"PENDING","orderId":"...","clientOrderId":"PO-1","raw":{}}
POST /api/payments/payoutnp/status

Payout status

orderId or clientOrderId.

Typical success (200)

{"success":true,"status":"SUCCESS","utr":"...","raw":{}}

V1 — Inbound webhooks (payment providers → NineteenPay)

These URLs receive callbacks from banks/gateways. You normally configure your merchant callback in the dashboard; NineteenPay forwards a normalized or raw payload to you (see V2 outbound section). This section documents how we verify inbound posts.

Native V1 gateway inbound (HASH)

If HASH is present and pipe has a salt: build tilde-separated field string (gateway order), append salt, SHA256 hex uppercase; compare to HASH.

JPSL S2S

If secureHash and salt configured: HMAC-SHA256 over sorted keys, values concatenated in key order, hex digest vs secureHash.

Escrow channel (inbound)

RSA-SHA256: verify signature over JSON body (without signature) using the configured escrow public key (server-side).

Payout status (inbound webhook)

If webhook secret configured: AES-128-CBC checksum in Checksum field vs encrypted JSON (without Checksum).

Hosted PG add-money (header checksum)

Header xverify / x-verify: HMAC-SHA256 over sorted JSON keys with key derived from user id; compare hex.