Skip to main content

​
Introduction

Collecting money from India is hard. Your buyers face SWIFT fees, complex forex processes, and unfamiliar international wire workflows — all of which create friction, delay payments, and increase drop-off. Virtual Bank Accounts (VBAs) solve this by giving a settling entity a dedicated Indian bank account. The buyer simply transfers rupees using methods they already know and trust — NEFT, RTGS, or IMPS — just like paying any local vendor. EximPe handles the regulatory compliance, currency conversion, and settlement to your preferred currency.

Local for the buyer

Buyers pay by familiar domestic transfer — no SWIFT, no intermediary banks

Real-time tracking

Instant webhook notifications on every incoming credit

Compliance built in

LRS eligibility, TCS, and documents are handled through the API

​
How It Works

  1. You get an Indian bank account — EximPe issues a virtual bank account with a unique account number and IFSC for the settling entity.
  2. Your buyer pays locally — they initiate a standard domestic transfer (NEFT, RTGS, or IMPS) to the VBA. No international wires, no SWIFT.
  3. You get notified instantly — EximPe creates a payment from the credit and sends a real-time webhook.
  4. Compliance is handled — you assert the LRS details (remitter, purpose, documents) via API to meet RBI’s cross-border rules.
  5. Settlement in your currency — cleared funds are converted and settled to your international bank account.
A VBA is not bound to a single buyer — it can receive credits from many remitters. From v2.0.0 onwards, a settling entity can have multiple ACTIVE VBAs at once.

​
Prerequisites

Before you begin, ensure you have:
  • Merchant account: an active, approved settling entity (sub-merchant or direct merchant) with the VBA feature enabled.
  • Credentials: your X-Client-ID and X-Client-Secret (PSP callers also send X-Merchant-ID for the settling sub-merchant).
  • Webhook URL: a secure endpoint to receive VBA payment notifications, configured on your credentials.

​
Integration Steps

  1. Create VBA — issue a virtual bank account for the settling entity.
  2. Share account details — pass the account number and IFSC to the buyer.
  3. Track payments — list payments or fetch by UTR, or use webhooks for real-time updates.
  4. Simulate a transfer (sandbox) — test the end-to-end flow without a real bank transfer.

​
Step 1: Create VBA

Create a Virtual Bank Account for the settling entity. The account name, email, phone, and virtual_account_id are derived from the merchant account, so the request body is minimal — you optionally supply lock rules. 
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 optionally lock a VBA at creation time:
  • Remitter lock — restrict the VBA to accept transfers only from a specific list of remitter bank accounts (each identified by account number and IFSC).
  • Amount lock — restrict the VBA to accept transfers within an amount range.
Both locks are optional and independent; when omitted they return as null and impose no restriction.

📚 API Reference

Create VBA API — full request/response and error codes.

​
Step 2: Share Account Details

The response returns vba_account_number, vba_ifsc, vba_bank_code, vba_status, and vba_provider. Share the account number and IFSC with the buyer so they can initiate a NEFT, RTGS, or IMPS transfer into the virtual account.
For ICICI-provider VBAs, the account number is a 16-character number in a fixed pattern: the INRACC prefix + a 3-character partner shortcode + a 7-digit identifier — e.g. INRACCNEX1234567. The IFSC is fixed per client code.

​
Step 3: Track Payments

When a credit lands in the VBA, EximPe creates a payment and sends webhooks to your registered URL so you can process it in real time:
  1. EximPe records the credit (amount, sender account + IFSC, payer name, UTR).
  2. A payment is created in Action Required — the remitter’s PAN is not derived from the credit.
  3. You receive a payment webhook. Proceed to LRS Verification to make the payment compliant.
The sender bank account on a credit is the payer instrument, not the remitter identity. You must assert the remitter (by PAN) during LRS verification — do not assume the bank sender is the PAN holder.

📚 List VBA Payments

Paginated list of payments collected on a VBA.

📚 Get Payment by UTR

Fetch a single credit by its bank UTR.

​
Step 4: Simulate a Transfer (Sandbox)

In the sandbox environment, you can simulate an incoming bank transfer to a VBA to test the end-to-end flow — webhooks, payment creation, and the LRS flow — without a real bank transfer. It works for both Cashfree and ICICI VBAs (for ICICI it runs the real credit-posting processor). The utr must be unique across simulations. 
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"
    }
  }'
This endpoint is available only in the sandbox environment, not in production.

📚 API Reference

Simulate VBA Transfer API — simulate a payment to a VBA in sandbox.

​
Managing VBAs

EximPe provides APIs to manage the lifecycle of your virtual bank accounts:
Next: make the collected payment compliant in LRS Verification.