Skip to main content
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.
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.
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.
Sandbox only. This endpoint does not exist in production.
You get back the payment the credit created — captured with action_required is the happy path, meaning the money is in and the compliance details are what’s missing. A credit that breaks a rule on the account (the VBA is inactive, a remitter lock, an amount lock, the 25 lac ceiling) is still recorded rather than rejected — we never drop real money — and comes back failed with the reason in status_message.
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.

Simulate VBA Transfer API

Every field, every status_message, and the full response shape.

​
Finding payments

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.