Virtual Account
Overview
Virtual Account (VA) is a payment instrument supported by the Charge API for bank-to-bank transfers. The customer pays the merchant by transferring funds from their own bank account to a merchant-assigned virtual account reference. VA is well suited to business-to-business (B2B) flows and large lump-sum payments where the customer prefers a bank transfer.
DB acts as the PSP for the transfer. The Charge API initiates the transaction and returns the remittance details that the customer uses in their banking app; reconciliation back to the original charge happens through CAMT52 ingestion in the settlement engine.
Configurations
Two VA configurations are available, set at merchant onboarding via the Operations Portal:
| Configuration | Routing |
|---|---|
| Direct to Merchant | Funds route directly to the merchant's nominated account. |
| Direct to Pool | Funds route to the DB Pool account and are subsequently settled out to the merchant by DMG. |
The integration surface for a merchant is the same for both configurations. The difference is in downstream settlement and reporting.
Payer ID
Every VA transaction is identified by a Payer ID. The leading digits — the Static Payer ID — are assigned to the merchant at onboarding and identify the merchant within DB's core banking platform. The remaining digits are appended per transaction in one of two styles:
| Style | How the Payer ID is composed |
|---|---|
| Dynamic Payer ID | Static ID + a 12-digit unique identifier generated by DMG. |
| Custom Payer ID | Static ID + a merchant-configured identifier (for example, customer email or phone number). |
Static ID and Payer ID style are configured by DMG Operations and are not supplied per-request by the merchant.
Integration model
Virtual Account charges are initiated through the Charge SDK. The merchant backend creates an order via /order_token and the merchant frontend mounts the SDK with the resulting order token. The customer selects Virtual Account on the payment form; the SDK orchestrates the charge with the platform and exposes the remittance details to the merchant frontend for rendering.
The underlying Charge API authorisation call is not exposed for direct merchant integration. The SDK populates the VA instrument payload from the merchant's onboarding configuration, so merchant code never constructs a VA charge request.
Remittance details
When the SDK completes the VA charge, it exposes the following values to the merchant frontend. The merchant renders these to the customer, who then initiates the bank transfer from their banking app.
| Field | Description |
|---|---|
account_name | The receiving account name to be quoted on the transfer. |
static_id | The Static Payer ID assigned to the merchant at onboarding. |
account_number | The per-transaction suffix appended to the Static ID — generated dynamically by DMG, or composed from a merchant-configured identifier where Custom Payer ID is in use. Together with static_id this forms the full Payer ID the customer quotes on the transfer. |
reference | The DMG-generated payment reference used to reconcile the inbound funds against this charge. |
The amount to transfer is the order amount; the receiving bank details are tied to the merchant's onboarding configuration and rendered by the SDK alongside the fields above.
Until the transfer is reconciled, the charge sits in Pending state.
Transaction lifecycle
The charge status moves through the following states for a VA payment:
| Status | When it applies |
|---|---|
| Pending | Charge has been authorised; remittance details have been issued; DMG is waiting for the bank transfer to arrive. |
| Approved | Funds have arrived at DB and the inbound CAMT54 (transaction notification) has matched the charge. Settlement processing has not yet completed. |
| Paid-In | The CAMT52 (settlement statement) confirms the funds are reconciled against the charge for the full transaction amount. For Direct-to-Merchant, this is the terminal status. |
| Partial Paid-In | The CAMT52 confirms partial reconciliation. The remaining amount is tracked and reconciles to Paid-In once subsequent CAMT52 entries close it out. |
| Unreconciled | A CAMT52 entry was identified against the merchant Static ID but the amount exceeded the original transaction. The overpaid amount is flagged for resolution. |
| Paid-Out | The merchant has been settled for this transaction. Direct-to-Pool only — Direct-to-Merchant funds reach the merchant directly and the lifecycle terminates at Paid-In. |
| Rejected | The transaction failed validation or was not completed within the configured expiry. |
For merchants configured with Precredit Notification, the SDK receives a server-sent event when the inbound CAMT54 is matched, allowing the merchant frontend to show success without waiting for the full settlement cycle. Precredit Notification applies only to full-amount transactions.
Operational constraints
A few VA-specific constraints to be aware of when integrating:
- No refunds. Refunds are not supported on the Virtual Account instrument.
- No chargebacks. DB is the PSP for the transfer; chargebacks are not applicable to VA transactions.
- Partial payments. Partial payments are accepted. Each inbound CAMT52 is reconciled independently against the original transaction amount; the charge moves to Paid-In once the running total reaches the original amount.
- Overpayments. Amounts exceeding the original transaction amount are marked Unreconciled and held pending operational resolution.
Settlement
VA transactions appear in the Settlement API alongside card and wallet transactions. For Direct-to-Pool merchants, the settlement report groups all VA transactions captured in a day into a single Paid-In event; the corresponding Paid-Out event covers the disbursal to the merchant. See Settlement API for the response shape.
Related references
- Payment Instrument endpoints — base Charge API instrument structure.
- Order endpoint — base order creation flow.
- Settlement API — settlement response shape and transaction records.