Indonesia virtual account API.
Bank payments, matched to your orders.

Virtual account collections for international merchants

A virtual account payment flow gives your customer bank payment instructions associated with an account number or reference. Your application must connect those instructions to the correct order and verify the final result through the approved integration.

For an overseas business, the first step is merchant review: company jurisdiction, website, product and customer journey. A bank listed on this page does not automatically become available to every merchant, and PAYJN does not claim a direct partnership with each named bank.

BNI, Mandiri, Permata, BRI and CIMB VA routes

These ranges reproduce PAYJN coverage reviewed on 30 October 2026. They describe pay-in routes, not payout limits or a guarantee of availability. Confirm the current bank list, amount range and operating terms for your approved merchant before launch.

How to plan a virtual account API integration

1. Agree the route: confirm eligible banks and whether the account or reference is order-specific, reusable or otherwise configured.
2. Create the payment instruction: follow the current approved API documentation for amount, currency, references and expiry.
3. Present bank instructions: show the customer the destination, amount and reference they must use.
4. Verify the result: apply the documented callback verification and order-query process.
5. Reconcile: match merchant and provider references, confirmed amounts and final order states.

Do not assume every route uses the same instruction lifetime or matching rule. Confirm how incorrect amounts, late payments and interrupted requests should be handled.

For a payment that differs from the invoice total, follow the Indonesia VA underpayment and overpayment reconciliation guide to verify the received amount, match payment references and record an approved resolution.

What if a virtual account payment is not credited?

Start with the merchant order number, provider reference where available, bank route, amount and payment time. A payment receipt can help an investigation, but a screenshot alone should not cause your application to mark an order paid.

Check the documented order status and whether your system received and processed the callback. If the result remains unresolved, contact PAYJN support through the agreed channel with the relevant references and a redacted receipt if requested. Further evidence depends on the case and provider requirements.

How Indonesian customers pay a virtual account

A virtual account looks like an ordinary bank account number to the customer, but it exists to identify one payer or one payment. Customers usually complete the payment in their bank's mobile app, internet banking or at an ATM, using the bank's virtual account or bill-payment menu rather than a normal account-to-account transfer screen. The exact menu names and steps differ by bank.

This has two practical consequences for an international merchant. First, your payment page should show bank-specific instructions for the route the customer chose, including the destination bank, the virtual account number, the exact amount and the expiry time. Second, some customers will try to pay from a different bank than the one shown. Whether an interbank transfer to a given virtual account is accepted depends on the bank route, so confirm this per route with the team and tell customers which bank they should pay from when it matters.

• Show the virtual account number in a format that is easy to copy, without extra spaces or characters.
• Display the exact IDR amount and state clearly whether the customer must pay that exact amount.
• Show the expiry time in the customer's local time (WIB, WITA or WIT) and in your support system.
• Keep instructions for each enabled bank on the page instead of linking to a generic help article.

Closed amount, open amount and reusable virtual accounts

Virtual accounts can be configured in different ways, and the configuration decides how your system must match payments. Before integration, agree which of the following models is available for your approved routes and which one fits your customer journey.

Availability of each model depends on the bank route and merchant approval; this table describes common industry configurations, not a commitment that every model is offered on every route.

Expiry and payments made after expiry

A short expiry reduces the number of open orders but increases the share of customers who pay too late; a long expiry does the opposite. Choose an expiry that matches how your customers actually pay. A customer paying by ATM after work needs more time than a customer paying in a mobile banking app during checkout.

Decide in advance what happens when a payment arrives after the order has expired. Depending on the route, a late payment may be rejected by the bank or may still be received and need review. Your policy should state whether you credit the order, create a new order, or refund through the agreed process, and who approves the decision. Never reuse an expired order reference for a new payment instruction.

Callback handling checklist for virtual account payments

Callback handling is one of the first places to check when a payment is not credited. Treat the callback as a notification that must be verified, not as an instruction to credit blindly.

1. Verify authenticity: check the signature or other verification method in your approved documentation before reading the payload.
2. Make processing idempotent: store the provider reference and ignore a callback you have already processed, so a repeated notification cannot credit an order twice.
3. Compare amount and currency: confirm the received IDR amount against the order before marking it paid.
4. Acknowledge quickly: return the documented acknowledgement first and run slow work, such as delivering goods, in a queue.
5. Keep a fallback: query the order status when a callback is late or missing instead of waiting indefinitely.
6. Log the raw payload: keep the original callback, headers and processing result so support investigations can be traced.

The duplicate payment webhook guide covers idempotent processing in more detail.

Daily reconciliation for virtual account collections

Reconcile every day, not only when a customer complains. Compare your order records with the provider's transaction records and settlement report, and investigate each difference by type.

When a virtual account is the better choice than QRIS

Virtual accounts tend to suit higher order values, customers who prefer paying from a bank account, and B2B invoices that need a clear bank record. QRIS suits fast mobile checkouts with smaller amounts. Many merchants offer both and let customers choose. The QRIS versus virtual accounts comparison walks through the customer journey of each.

Request an Indonesia virtual account payment proposal

Share your company website, registration jurisdiction, business model, preferred banks, average IDR order amount and expected monthly collection volume. Explain whether customers pay one invoice at a time or make repeat payments so the team can review the required reference-matching workflow.

• Confirm merchant eligibility and the bank routes available to your business.
• Request collection charges, current limits, settlement arrangements and the handling of unmatched payments.
• Agree reference use, expiry, callback verification and reconciliation tests before production.

Request a VA collection review. For sending funds, review the Indonesia payout service separately.

Compare QRIS and bank virtual accounts

Use QRIS versus virtual accounts to compare customer journeys, and the Indonesia payment troubleshooting guide to plan exception handling. Return to Indonesia payment gateway coverage for QRIS and wallet collections.