What Exactly Is a Virtual Account?
Virtual account types, how account issuance works, and the full flow from deposit to notification.
"I Can't Tell Which Deposit Belongs to Which Order"
Anyone who's managed a shared bank account for order payments knows the pain.
"The order name is 'John Smith', but the sender name is 'jsmith92'. Is this the same person?" "'John Smith' sent 50,000 KRW twice. Which order is which?"
Matching deposits to orders by sender name alone is error-prone and manual. Customers transpose digits, use nicknames, or deposit the wrong amount. You end up making phone calls to reconcile transactions that should be automatic. Virtual accounts exist to eliminate exactly this problem.
Virtual Account = Real Bank Account + Validation Logic
A virtual account is a non-existent account number that the banking network treats as a valid account. The key difference from a regular corporate account is built-in validation: virtual accounts can enforce the exact deposit amount, reject deposits after an expiry time, and trigger an instant server notification the moment funds arrive.
Regular Account vs. Virtual Account
| Regular Corporate Account (bank transfer) | Virtual Account | |
|---|---|---|
| Account number | Actual bank account | Virtual number mapped to a real account |
| Deposit matching | Manual name/amount reconciliation | Automated via deposit notification (webhook) |
| Amount enforcement | None (over/under payments happen freely) | Can require an exact amount match |
The Core Idea
How It Works
The virtual account lifecycle has three stages: Issue → Deposit → Notify.
Note: "Issue" (채번) means activating a virtual account number so it can receive deposits.
Hecto Financial supports three issuance types:
| Type | Account managed by | Behavior |
|---|---|---|
| Rotating | PG | A deposit-ready account is allocated from the pool at the time of issuance |
| Fixed | Merchant | The merchant requests that a specific account from their pool be activated for a given order |
| Fixed Unlimited (pre-issued / merchant-issued) | Merchant | Notifies on any deposit regardless of amount (requires one-time activation) |
Stage 1: Issue the Virtual Account
When a customer selects "Virtual Account" at checkout, your server requests a virtual account from the PG for that order. This is the issuance (채번) step.
Stage 2: Customer Makes the Deposit
The customer transfers 50,000 KRW to the issued account number (e.g., 56211123456789) via their banking app or ATM. The bank's system runs three checks before accepting the deposit:
- Is the account valid? (Deposits are rejected after the account expires)
- Is the amount correct? (49,900 KRW or 50,100 KRW won't go through)
- Is the deposit window still open? (Deposits are rejected after the expiry time set at issuance)
Stage 3: Deposit Notification (Webhook)
The moment the deposit clears, the PG fires a real-time notification to your server. This is the noti (deposit notification).
Your server receives the signal and immediately transitions the order from awaiting payment → payment complete, then triggers fulfillment.
Why Virtual Accounts Are Worth It
Virtual accounts aren't just another payment method — they're an operations automation tool.
- Accuracy: Wrong amounts are rejected at the bank, not by your ops team.
- Speed: Deposit confirmation reaches your server in real time.
- Reliability: Each virtual account maps 1:1 to an order, so there's no ambiguity about who paid.
If you're still manually reconciling bank deposits against orders, virtual accounts are the straightforward fix.
Need technical support?
Code Samples
HectoFinancial GitHub