Static vs Dynamic Virtual Accounts: One-Time, Reusable and Named

Two businesses can both say they "use virtual accounts" and mean completely different things. One generates a fresh account number for every order, which disappears once it is paid. The other gives each customer a permanent number they can save in their banking app and pay every month. Both are virtual accounts. The difference, along with whose name appears on the account, shapes how your customers pay, how your finance team reconciles, and what can go wrong.

The short version

• Dynamic (one-time): a new account number for each payment, often with a fixed amount and an expiry time. Best for checkouts, bookings and one-off invoices.
• Static (reusable): one permanent number per customer, or for your whole business. Best for repeat billing, B2B customers and being paid by clients who save your details.
• Named vs unnamed: a separate question. A named account shows your business name to the payer; an unnamed one shows the provider's name. Static and dynamic accounts can each be either.
• The rule of thumb: use dynamic numbers when each payment is a separate event, static numbers when the relationship is ongoing, and named accounts wherever the payer's bank is likely to check who they are paying.

Two questions define every virtual account

Every virtual account can be described by answering two questions:

1. How long does the number live? For one payment (dynamic), or indefinitely (static)?
2. Whose name does the payer see? Yours (named), or your provider's (unnamed or pooled)?

Most confusion comes from treating these as a single choice. They are not. A one-time account can be named, and a reusable account can be unnamed. The table below shows all four combinations.

Dynamic (one-time) virtual accounts

A dynamic virtual account is generated on demand for a single transaction, then retired. The typical flow looks like this:

1. A customer checks out, books, or receives an invoice.
2. Your system (or your provider's) generates a unique account number for that order, usually tied to the exact amount due and set to expire after a few hours or days.
3. The customer pays that number from their banking app, internet banking or an ATM.
4. The payment arrives already linked to the order, and a notification tells your system to confirm it.

This model is the backbone of bank-transfer checkout in several Asian markets. In Indonesia, a gateway creates a temporary number for each transaction and the merchant is notified and reconciled in real time when it is paid, which removes the need for customers to send screenshots as proof of payment. In South Korea, real-time bank transfer to a virtual account is a common way to pay, particularly for larger purchases and B2B invoices.

• Lifetime: one payment, then expires or closes
• Amount: usually fixed to the order value
• Best for: online checkout, bookings and deposits, one-off invoices, event tickets
• Main benefit: every payment maps to exactly one order, with no reference field to get wrong
• Main risk: late or incorrect payments after expiry need a manual process

Strengths. Reconciliation is as precise as it gets. There is no reliance on the customer typing a reference correctly, and each order has its own audit trail. Because numbers expire, an old number can't be reused by mistake months later.

Weaknesses. Customers can't save the details for next time, so every purchase means a new number. Expiry is a double-edged sword: a customer who pays a day late may find their money held in suspense or returned. And because amounts are often fixed, partial payments, overpayments and payments that combine two orders all need special handling.

Static (reusable) virtual accounts

A static virtual account is assigned once and stays the same. It might belong to your business as a whole (so all clients pay one account in your name) or be assigned per customer (so each customer has their own number to pay you).

• Lifetime: indefinite, until you close it
• Amount: any amount, any number of times
• Best for: recurring invoices, wholesale and B2B customers, tenants, students, clients paying a freelancer, marketplace sellers
• Main benefit: customers save the details once and pay repeatedly
• Main risk: with one shared number, you are back to matching by amount and reference

Strengths. Payers set up your details once, and can pay by standing order or scheduled transfer. It feels like dealing with a normal local business account, which builds trust with B2B customers and suppliers. Assigned per customer, a static account still gives automatic reconciliation: whatever arrives in customer A's number belongs to customer A.

Weaknesses. A single shared static number (one account for all clients) reintroduces manual matching, because the only way to tell payments apart is the amount and whatever the customer typed in the reference. A per-customer static account that is never closed can keep receiving money after the relationship ends, so you need a process for unexpected deposits.

Named virtual accounts: why the name matters

A named virtual account is titled in your registered business name. When your customer enters the account details, their bank shows your name, not your provider's. That matters for three reasons.

Name checks are becoming standard. Banks increasingly check the payee's name against the account before a payment goes through. The UK's Confirmation of Payee has done this for years. In the EU, from 9 October 2025 euro-area payment providers must offer Verification of Payee on both instant and standard credit transfers, and payment providers in EU countries outside the euro area must comply by 9 July 2027. A payment to an unnamed account can return a "no match" or "close match" warning, which makes careful payers hesitate and some abandon the payment.

Platforms and counterparties often require it. Marketplaces, app stores, payment platforms and large corporate buyers commonly require that payouts go to an account in the recipient's own name. An unnamed account may simply be rejected at onboarding.

It is a trust signal. A supplier or customer who sees your business name on the account has one less reason to worry about fraud or misdirected money.

The trade-off is that named accounts involve more verification at opening, because the provider is attesting to who you are. For most businesses, that is time well spent.

Side-by-side comparison

Edge cases worth planning for

Whichever model you choose, decide up front how you will handle the payments that don't behave:

• Late payment into an expired number. Will it be held, credited anyway, or returned? How long does a return take?
• Wrong amount. Underpayments and overpayments into fixed-amount dynamic accounts need a rule: accept and chase the difference, refund the excess, or reject.
• Duplicate payment. Customers sometimes pay the same number twice. Have a refund path ready.
• Refunds. If the original account was one-time, refunds usually go back to the payer's source account, which you need to capture.
• End of relationship. For per-customer static accounts, close or flag the number when a customer leaves.

Which should you use?

A related idea: dynamic QR codes

Many markets' QR payment standards do a similar job to dynamic virtual accounts. A dynamic QR code can embed the amount and a unique reference for a single order, so the payment arrives pre-labelled, the same principle as a one-time account number. Indonesia's national QRIS standard and Thailand's PromptPay QR are everyday examples. For in-person and small-ticket payments, QR often plays the role that a dynamic virtual account plays for online and higher-value transfers.

How DSGPay handles this

DSGPay offers both models on the same account infrastructure. Named virtual accounts are reusable accounts opened in your business name in each of our core markets. One-time, single-use virtual accounts can be generated per order or per customer for high-volume collections. Through the DSGPay GraphQL API, you can create one-time or named virtual accounts per customer or per order and receive a real-time event the moment a deposit lands; through DSGPay OneWeb, every deposit is matched and logged automatically.

Sources

1. Juspay — An overview of Indonesia's payment ecosystem (Apr 2026) — juspay.io
2. PayAtlas — Accepting payments in Korea (Jan 2026) — payatlas.com
3. CBI — Verification of Payee (EU Instant Payments Regulation) — www.cbi-org.eu
4. Regulation (EU) 2024/886 — Instant Payments Regulation (Official Journal of the EU) — eur-lex.europa.eu