Build High-Performance Financial Applications
IMB Payments is India's leading API-first infrastructure provider. Integrate Banking APIs, Utilities APIs, Verification Suite, BBPS Utilities, and High-Throughput Recharge Systems with bank-grade security and 24/7 reliability.
curl -X POST https://api.imbpayment.com/v1/verification/upi-verify \
-H "x-client-id: {{client_id}}" \
-H "x-client-secret: {{client_secret}}" \
-H "Content-Type: application/json" \
-d '{
"upi_id": "test1234@ybl"
}'
Core Infrastructure Pillars
🌐 API Endpoints & Environments
| Environment | Base URL | Used For |
|---|---|---|
| Production | https://secure.imbpayment.in/ |
Real money transactions, live KYC, production API calls |
| Sandbox | https://sandbox-api.imbpayment.in/ |
Testing, staging environment, integration QA |
Getting Started
IMB Payments is an Indian leading API-first infrastructure provider. Our mission is to solve digital payments and verification challenges by offering a suite of modular, scalable, and developer-focused APIs.
Integration Steps
Step 1: Sign up on the IMB Payments Dashboard
Create your developer account at https://merchant.imbpayment.in/auth/sign-up
Step 2: Generate API Credentials
Generate your unique x-client-id and x-client-secret keys from the API Credentials section of your dashboard.
Step 3: Review Documentation & API Spec
Review endpoint parameters, copy curl snippets, or import the API collection into Postman/Insomnia.
Step 4: Sandbox Testing & Production Launch
Begin testing in our sandbox environment before switching to production to ensure your integration runs smoothly.
- Always use the Sandbox environment for initial integration, QA, and staging before switching to Production.
- Never share or expose API credentials. Regenerate keys if security is compromised.
- All communications must use HTTPS — connections over HTTP are rejected.
- Version your API endpoints (e.g.
/v1/) to ensure future compatibility.
🔒 Authentication
Security is paramount at IMB Payments. To safeguard every transaction and ensure only authorized applications access our APIs, we use header-based authentication.
How Authentication Works
Every request to IMB Payments APIs must include two mandatory headers:
| Header Name | Type | Required | Description | Example |
|---|---|---|---|---|
| x-client-id | String | Yes | Your unique Client ID assigned via dashboard | client-id: abc123xyz |
| x-client-secret | String | Yes | Your secret key associated with the Client ID | client-secret: s3cr3tK3y! |
| Content-Type | String | Yes | Payload format header | application/json |
Authentication Failure (401 Unauthorized)
When invalid or missing authentication headers are detected, IMB Payments responds with:
{
"response_code": 401,
"error_code": "INVALID_CREDENTIALS",
"message": "Missing API credentials client id & client secret.",
"error": [],
"data": null,
"meta": {
"request_id": "f0ca3884-24da-43df-9c5b-106b9d3e23c4",
"time": "2025-08-30T16:05:17+05:30"
}
}
What is IP Whitelisting?
IP whitelisting (also called allowlisting) is an additional security measure that restricts API access to requests originating only from IP addresses or IP ranges that you explicitly authorize. When enabled, API calls from non-whitelisted IPs will be blocked with a 403 Forbidden response.
{
"response_code": 403,
"error_code": "INVALID_IP",
"message": "IP is not whitelisted.",
"error": [],
"data": null
}
🟢 HTTP Status Codes
Standardized HTTP response status codes returned by IMB Payment API services.
| Code | Meaning | Description & Strategy |
|---|---|---|
| 200 | OK | Successful request. All queries processed as expected. |
| 201 | Created | Resource created successfully. |
| 400 | Bad Request | Invalid request parameters or missing mandatory fields. |
| 401 | Unauthorized | Authentication failed. Missing or invalid x-client-id or x-client-secret. |
| 403 | Forbidden | Access to resource denied. IP address not whitelisted or permission lacking. |
| 404 | Not Found | Resource does not exist or request ID not found. |
| 409 | Conflict | Duplicate or conflicting operation (e.g. duplicate transaction ref). |
| 422 | Unprocessable Entity | Invalid resource state or parameter validation failure. |
| 429 | Too Many Requests | Rate limit exceeded. Exceeded 60 requests per minute limit. |
| 500 | Internal Server Error | Problem on IMB Payments' side or upstream provider. Retry with exponential backoff. |
⏳ Rate Limits
To ensure fair usage and maintain optimal performance for all clients, IMB Payments enforces strict rate limits.
What Happens When You Exceed Limits?
{
"error": true,
"message": "Rate limit exceeded. Please try again after some time."
}
- Implement client-side queuing to manage bursts in API requests.
- Use exponential backoff and retry mechanisms to prevent immediate request floods.
- Monitor your usage via our dashboard and optimize your API calls.
- Contact your account manager for higher volume plans or special arrangements.
🧩 Key Features of IMB Payments APIs
📬 Need Higher Limits or Support?
📧 Email: [email protected] | 💬 Live Chat available on Dashboard
Recharge Callback (Webhook)
POSTThe Recharge Callback API is used to send real-time recharge status updates to the merchant server once the transaction is processed by the operator. Instead of continuously polling the Status API, merchants should implement this webhook to receive automatic transaction updates.
When Callback Is Triggered
- Recharge Successful
- Recharge Failed
- Operator Final Status Update
SUCCESS RECHARGE WEBHOOK PAYLOAD
{
"event": "RECHARGE_SUCCESS",
"status": "success",
"data": {
"request_id": "rechtxn00001",
"number": "99XXXXXX99",
"amount": "22.00",
"operator_id": "11",
"reference_id": "IMBRCH22264720260227_f870fdf4",
"ackno": "1122XXXX65",
"message": "SUCCESS",
"refunded": false
},
"timestamp": "2026-03-01T12:05:21+05:30"
}
FAILED RECHARGE WEBHOOK PAYLOAD
{
"event": "RECHARGE_FAILURE",
"status": "failed",
"data": {
"request_id": "rechtxn00001",
"number": "99XXXXXX99",
"amount": "22.00",
"operator_id": "11",
"reference_id": "IMBRCH22280520260227_8c5ef3a3",
"ackno": "112XXXXX65",
"message": "Failed",
"refunded": true
},
"timestamp": "2026-03-01T12:12:08+05:30"
}
- Always validate callback requests from trusted IMB Payment IP addresses.
- Verify transactions using the Check Status API before updating wallet balance.
- Do not rely solely on frontend success messages.
- Store callback logs for reconciliation and dispute handling.
📥 Merchant Expected Response
After receiving the callback, merchant server must return HTTP 200 response within 3 seconds:
{
"status": 200,
"message": "Transaction completed successfully"
}
NSDL Account Opening Callback
POSTAfter an NSDL account opening request is processed, IMB Payment sends an automated HTTP POST callback to your registered webhook URL with the final status of the request.
⚙️ Setup Instructions
Register your webhook URL in your IMB Payment merchant dashboard under Settings → Webhook Configuration.
Each merchant receives a unique webhook_secret key used to verify the authenticity of incoming webhook payloads.
Request Headers
| Header | Description |
|---|---|
| Content-Type | Must be application/json |
| X-Webhook-Source | Value is IMBPayment |
| X-Webhook-Signature | HMAC SHA-256 signature of the raw request body |
| X-Webhook-Timestamp | Unix timestamp of when the webhook was generated |
Signature Verification
Always verify the X-Webhook-Signature header before processing the webhook payload. IMB Payment signs every webhook request using HMAC SHA-256 with your secret key.
const crypto = require('crypto');
function verifyWebhook(payload, signatureHeader, secret) {
const hmac = crypto.createHmac('sha256', secret);
const digest = hmac.update(payload).digest('hex');
return crypto.timingSafeEqual(Buffer.from(signatureHeader), Buffer.from(digest));
}
Supported Events
| Event | Description |
|---|---|
| NSDL_ACCOUNT_CREATED | NSDL account successfully created for customer |
| NSDL_ACCOUNT_REFUND | Account creation failed, amount refunded to wallet |
Event: NSDL_ACCOUNT_CREATED Payload Example
{
"event": "NSDL_ACCOUNT_CREATED",
"timestamp": "2025-06-28T10:30:00+05:30",
"request_id": "REQ7834HDJK23",
"data": {
"request_id": "REQ7834HDJK23",
"pancard": "ABCDE1234F",
"customer_name": "Rajesh Kumar",
"account_number": "9876543210123456",
"ifsc_code": "NSDL0000001",
"cif_number": "CIF123456789",
"account_type": "Savings",
"bank_name": "NSDL Payments Bank",
"branch": "Mumbai Main Branch",
"profile_pic": "https://example.com/profile/abc123.jpg",
"customer_care": "1800-123-4567",
"account_status": "success",
"is_refunded": false,
"is_completed": true
}
}
Payload Field Explanation
| Field | Type | Description |
|---|---|---|
| request_id | String | Unique account opening request identifier |
| pancard | String | Customer PAN card number |
| customer_name | String | Customer full name as verified by bank |
| account_number | String | Generated NSDL Payment Bank account number |
| ifsc_code | String | Bank IFSC code (e.g. NSDL0000001) |
| cif_number | String | Customer Identification File (CIF) number |
| account_type | String | Savings or Current account type |
| bank_name | String | Issuing Bank name (NSDL Payments Bank) |
| account_status | String | Terminal status: success or failed |
API Reference Explorer
Interactive documentation, request parameters, response schemas, and code generators for all IMB Payment endpoints.
SDKs & Libraries
Official SDKs and integration wrappers maintained by the IMB Payment Engineering team.
Error Handling Standards
Standardized HTTP response error codes and recommended client handling strategies.
| HTTP Status | Error Type | Description & Strategy |
|---|---|---|
| 200 OK | Success | Request completed successfully. Check status or response_code in response body. |
| 400 Bad Request | Invalid Request | Missing mandatory parameters or malformed JSON payload. |
| 401 Unauthorized | Authentication | Invalid or expired API Key / Bearer token in headers. |
| 422 Validation Error | Schema Validation | Payload validation failed. Check specific field error messages returned in the error object. |
| 500 Internal Error | Server Error | Upstream bank or provider timeout. Implement exponential backoff retry logic. |