IMB PAYMENT PLATFORM Enterprise Financial Infrastructure

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.

POST /api/v1/verification/upi-verify
POST
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

Banking & NSDL Account Opening
BC Agent onboarding pipelines, NSDL Payment Bank account creation, and real-time status webhooks.
Instant Verification Suite
Verify Bank Accounts, UPI VPAs, PAN Cards, GSTINs, DigiLocker, and Aadhaar OTPs instantly.
BBPS & Utility Infrastructure
Access 20,000+ Bharat BillPay billers, fetch live bills, and execute high-throughput recharge orders.

🌐 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

1

Step 1: Sign up on the IMB Payments Dashboard

Create your developer account at https://merchant.imbpayment.in/auth/sign-up

2

Step 2: Generate API Credentials

Generate your unique x-client-id and x-client-secret keys from the API Credentials section of your dashboard.

3

Step 3: Review Documentation & API Spec

Review endpoint parameters, copy curl snippets, or import the API collection into Postman/Insomnia.

4

Step 4: Sandbox Testing & Production Launch

Begin testing in our sandbox environment before switching to production to ensure your integration runs smoothly.

💡 Frictionless Onboarding
For a frictionless start, IMB Payments provides quick-code snippets, ready-to-use SDKs, and dedicated onboarding support. Every account comes with sandbox access and a comprehensive testing suite.
💡 Best Practices Checklist
  • 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:

HTTP/1.1 401 Unauthorized
{
  "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.

HTTP/1.1 403 Forbidden
{
  "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.

⏱️
Limit: 60 requests per minute per client
Exceeding this threshold will temporarily throttle incoming API calls for your client ID.

What Happens When You Exceed Limits?

HTTP/1.1 429 Too Many Requests
{
  "error": true,
  "message": "Rate limit exceeded. Please try again after some time."
}
💡 Recommendations for Handling Rate Limits
  • 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

🔐 End-to-End Security
Encrypted credentials, HTTPS enforcement, and fraud prevention protocols.
⚡ Lightning-Fast
RESTful APIs, instant sandbox testing, and lightweight JSON payloads.
🧩 Modular API Suite
Use only the APIs you need with transparent pay-as-you-go pricing.

📬 Need Higher Limits or Support?

📧 Email: [email protected] | 💬 Live Chat available on Dashboard

Recharge Callback (Webhook)

POST

The 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
{
  "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
{
  "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"
}
🔒 Webhook Security Recommendations
  • 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:

HTTP/1.1 200 OK
{
  "status": 200,
  "message": "Transaction completed successfully"
}

NSDL Account Opening Callback

POST

After 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
{
  "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.

Node.js SDK
npm install @imb/payment-sdk
TypeScript ready, Promise based API client with automated retry handling.
Python SDK
pip install imb-payment
Full support for Python 3.8+ asyncio & synchronous requests pipelines.
Laravel Package
composer require imb/laravel
Includes ServiceProviders, Artisan commands, and webhook signature validators.

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.