Virtual Bank Accounts

We issue a virtual account — an Indian account number your buyer can pay into. They transfer rupees by NEFT, RTGS, or IMPS, the same way they pay any local supplier. No SWIFT, no international wire, no forex on their side. Shortened to VBA in field names and API responses. The account sits on EximPe’s master account. You do not need a bank account in India, and there is nothing for you to open or maintain. You get a webhook the moment money lands.

Before you start

An approved merchant account with virtual accounts enabled
Your X-Client-ID and X-Client-Secret, and X-API-Version: 3.0.0 on every call
A webhook URL on your account

PSPs also send X-Merchant-ID naming the sub-merchant the account belongs to.

Step 1: Create the account

The name, email, and phone come from the merchant account, so the request body can be empty.

curl -X POST 'https://api-pacb-uat.eximpe.com/pg/vba/' \
  -H 'X-Client-ID: <client_id>' \
  -H 'X-Client-Secret: <client_secret>' \
  -H 'X-Merchant-ID: <sub_merchant_id>' \
  -H 'X-API-Version: 3.0.0' \
  -H 'Content-Type: application/json' \
  -d '{}'

You can lock the account when you create it:

Remitter lock — only accept money from bank accounts you list.
Amount lock — only accept transfers within a range.

Both are optional and independent. Leave them out and the account accepts anything.

Create VBA API

Full request and response.

Step 2: Give the details to your buyer

The response gives you vba_account_number and vba_ifsc. Send those two to your buyer. That is all they need.

Account numbers follow a fixed pattern, and the IFSC is always the same for your client code. Take both from the response rather than constructing them yourself.

Step 3: Handle the money arriving

When a credit lands we record the amount, the sender’s account and IFSC, their name, and the UTR. Then we create a payment and send you a webhook. The payment status is ACTION_REQUIRED. We have the money but not the paperwork.

The sender on the credit does not identify the payment. You tell us who paid, and what for, in the next step.For LRS payments there is an extra rule: the money must come from the remitter’s own account, and we check the sending account’s name against the PAN you give us. Other payment types have no such restriction.

Next, send us the compliance details so the payment can settle.

LRS Verification

Verify the buyer’s PAN, quote the tax, upload documents, submit.

Step 4: Test it without a real transfer

In sandbox, simulate an incoming transfer. This runs the whole flow — webhooks, payment creation, verification — with no real money. Each utr must be unique.

curl -X POST 'https://api-pacb-uat.eximpe.com/pg/vba/simulate-transfer/' \
  -H 'X-Client-ID: <client_id>' \
  -H 'X-Client-Secret: <client_secret>' \
  -H 'X-Merchant-ID: <sub_merchant_id>' \
  -H 'X-API-Version: 3.0.0' \
  -H 'Content-Type: application/json' \
  -d '{
    "virtual_account_id": "24586202",
    "vba_simulation": {
      "amount": 150000,
      "utr": "TESTUTR0001",
      "remitter_name": "John Doe",
      "remitter_account": "123456789012",
      "remitter_ifsc": "YESB0CMSNOC",
      "remarks": "Invoice INV-2025-0091"
    }
  }'

Sandbox only. This endpoint does not exist in production.

You get back the payment the credit created:

{
  "success": true,
  "message": "VBA transfer simulation processed",
  "data": {
    "payment_id": "PR6115489451",
    "order_id": "OD6767097620",
    "reference_id": "VBA-864042420509",
    "status": "captured",
    "settlement_status": "action_required",
    "status_message": null
  }
}

captured with action_required is the happy path — the money is in, and the compliance details are what is missing. A credit that breaks a rule on the account is still recorded. We never drop real money, so instead of rejecting it we keep it for reconciliation and tell you why:

{
  "status": "failed",
  "settlement_status": "not_applicable",
  "status_message": "Amount outside allowed range"
}

status_message is the only place that reason appears. It is one of:

`status_message`	What happened
`VBA is inactive`	The account was deactivated before the money arrived.
`Remitter not in allow-list`	The account has a remitter lock and this sender is not on it.
`Amount outside allowed range`	The account has an amount lock and this amount falls outside it.
`Amount exceeds 25 lacs limit`	Above the per-credit ceiling.

Anything that stops a payment being created is an error status, not a 200: a repeated utr is 409, a malformed amount is 400.

The same rules apply to real credits. Simulating one is the way to see what a locked account does to a transfer before a buyer sends money into it.

Finding payments

What you want	API
All payments on an account	List VBA Payments
One payment, by bank reference	Get Payment by UTR
All your accounts	List VBAs
One account	Get VBA

Create as many accounts as you want — there is no limit. By default each one accepts money from any number of buyers; use a remitter lock if you want to tie an account to specific buyers.

Get Started

Collecting Payments

LRS (Education & Travel Payments from Individuals)

Virtual Bank Accounts

Before you start

Step 1: Create the account

Create VBA API

Step 2: Give the details to your buyer

Step 3: Handle the money arriving

LRS Verification

Step 4: Test it without a real transfer

Finding payments

​Before you start

​Step 1: Create the account

Create VBA API

​Step 2: Give the details to your buyer

​Step 3: Handle the money arriving

LRS Verification

​Step 4: Test it without a real transfer

​Finding payments

Before you start

Step 1: Create the account

Step 2: Give the details to your buyer

Step 3: Handle the money arriving

Step 4: Test it without a real transfer

Finding payments