Why can a virtual account payment have the wrong amount?
Amount validation depends on the payment route. Xendit distinguishes open-amount and closed-amount virtual accounts in its documentation. It also notes that some payments can differ from the expected amount even in a closed-amount setup, including particular interbank journeys. Confirm the behavior of the route your merchant has actually been approved to use. Xendit VA amount guidance
Start the investigation with the order total, the provider-confirmed received amount and the merchant settlement amount as separate records. A settlement deduction needs its own explanation under your fee agreement. Compare the provider-confirmed customer payment with the invoice before attributing a difference to fees.
Six checks before crediting or fulfilling the order
- Find the original instruction. Retrieve the merchant order reference, invoice currency and total, bank route, VA reference and instruction expiry. Check whether that VA belongs to one order or is reused across customer payments.
- Verify what was received. Use your approved server-side status query, authenticated notification or provider reconciliation record. Retain the provider payment reference, received amount, currency and timestamp with timezone. Ask the provider to resolve missing or conflicting values.
- Match the payment to the invoice. Check the reference and currency together with the amount. If a VA is reusable, confirm which invoice the payment belongs to before allocating it. Keep the original invoice total intact in your records.
- Classify the difference. Separate an underpayment, an overpayment, an exact payment, an unmatched payment and two distinct payments for one order. Distinguish a second payment reference from a repeated notification of the same payment.
- Approve a resolution. Follow the merchant's agreed exception procedure. For an underpayment, confirm whether a balance payment is supported and how it will be linked before asking the customer to pay again. For an overpayment, establish whether to refund or apply credit under the agreed policy, with customer agreement where required. Confirm the available refund process and timing with the provider.
- Record and close the case. Link the invoice, each confirmed payment, any approved allocation and any refund reference. Make each credit or fulfilment action idempotent. Retain the decision, operator and time in the audit trail.
When notifications are missing or delayed, reconcile against the provider's current status. Midtrans documents its Get Status API as a fallback for that situation. Use the equivalent procedure in your own approved integration. Midtrans notification and reconciliation guidance
A hypothetical IDR reconciliation example
The following cases are invented to illustrate an internal review workflow. Each row is a separate scenario for an invoice of IDR 250,000. The amounts describe assumed confirmed receipts. Resolution options require approval under the merchant's operating policy.
| Confirmed payment | Difference | Review before fulfilment |
|---|---|---|
| IDR 245,000 | IDR 5,000 short | Keep the invoice open for review. Confirm a supported balance-payment or return process. |
| IDR 255,000 | IDR 5,000 extra | Record the extra amount separately and approve its refund or allocation. |
| IDR 250,000 reported twice with one payment reference | Potential duplicate notification | Verify one receipt and one ledger credit. |
| Two separate IDR 250,000 receipts with distinct references | Potential duplicate payment | Verify both receipts and resolve the extra payment through the agreed process. |
If no received payment can be verified, retain the case as unresolved while support investigates. A customer receipt can help locate the transfer. Obtain provider confirmation before applying the payment to the invoice.
What should the team test and record?
- Exact amount, underpayment and overpayment under the route's documented rules, including rejection where applicable.
- A reusable VA with more than one outstanding invoice, if that configuration is supported.
- One payment notification delivered twice and two genuinely separate payments.
- A late payment or a payment-status query that disagrees with your local record.
- A case closed by another operator while a retry or reconciliation job is running.
Use an approved test environment or provider-arranged test procedure. For a live investigation, prepare the invoice reference, expected and confirmed amounts, currency, VA route, provider payment reference, payment time with timezone and sanitized status evidence. Submit requested evidence through your agreed support channel.
For launch planning, agree who owns amount exceptions and refunds, how cases are tracked and which evidence lets finance close the invoice. Confirm the current route-specific rules with PAYJN during onboarding.
Continue planning your Indonesia collections
- Indonesia virtual account API and merchant review
- Compare QRIS and virtual account payment journeys
- Prevent duplicate payment webhook credits
- Investigate Indonesia payment exceptions
Discuss your Indonesia collection workflow
Official supplier documentation checked on 7 November 2026. The supplier examples describe their own products. PAYJN route availability, amount rules, fees, settlement and refund handling are confirmed for each approved merchant setup.