> ## Documentation Index
> Fetch the complete documentation index at: https://docs.eximpe.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Virtual Bank Accounts

> Collect rupees from Indian buyers via local bank transfers into a dedicated virtual account — no SWIFT, no forex hassle for your customers.

# 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.

<CardGroup cols={3}>
  <Card title="Local for the buyer" icon="building-columns" href="#how-it-works">
    Buyers pay by familiar domestic transfer — no SWIFT, no intermediary banks
  </Card>

  <Card title="Real-time tracking" icon="bolt" href="#step-3-track-payments">
    Instant webhook notifications on every incoming credit
  </Card>

  <Card title="Compliance built in" icon="shield-check" href="/integration-guide/v3/web-integration/lrs-compliance">
    LRS eligibility, TCS, and documents are handled through the API
  </Card>
</CardGroup>

## 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.

<Note>
  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.
</Note>

## 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.

```bash theme={null}
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.

<Card title="📚 API Reference" href="/api-reference/v3/vba/create">
  **Create VBA API** — full request/response and error codes.
</Card>

## 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.

<Note>
  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.
</Note>

## 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](/integration-guide/v3/web-integration/lrs-verification) to make the payment compliant.

<Warning>
  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.
</Warning>

<CardGroup cols={2}>
  <Card title="📚 List VBA Payments" href="/api-reference/v3/vba/list-payments">
    Paginated list of payments collected on a VBA.
  </Card>

  <Card title="📚 Get Payment by UTR" href="/api-reference/v3/vba/get-payment-by-utr">
    Fetch a single credit by its bank UTR.
  </Card>
</CardGroup>

## 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.

```bash theme={null}
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"
    }
  }'
```

<Warning>This endpoint is available only in the sandbox environment, not in production.</Warning>

<Card title="📚 API Reference" href="/api-reference/v3/vba/simulate-transfer">
  **Simulate VBA Transfer API** — simulate a payment to a VBA in sandbox.
</Card>

## Managing VBAs

EximPe provides APIs to manage the lifecycle of your virtual bank accounts:

* **[Create VBA](/api-reference/v3/vba/create)** — create a new VBA, optionally with remitter and/or amount locks.
* **[List VBAs](/api-reference/v3/vba/list)** — paginated list, filterable by `vba_status` and `vba_provider`.
* **[Get VBA Details](/api-reference/v3/vba/get)** — fetch details of an existing VBA.
* **[List VBA Payments](/api-reference/v3/vba/list-payments)** — list all payments for a VBA.
* **[Get Payment by UTR](/api-reference/v3/vba/get-payment-by-utr)** — get a single payment by UTR.
* **[Simulate VBA Transfer](/api-reference/v3/vba/simulate-transfer)** — simulate an incoming transfer to a VBA in sandbox.

<Info>
  Next: make the collected payment compliant in [LRS Verification](/integration-guide/v3/web-integration/lrs-verification).
</Info>