South Korea: virtual accounts, bank transfers and KakaoPay/Toss checkout

A Korean checkout button can represent fundamentally different obligations. Bank transfer, a virtual account issued for an order, and easy-pay through KakaoPay or Toss Pay should not all be labelled “local P2P.” They differ in initiation, confirmation and refund behavior. For processing, this is primarily a payment-lifecycle question.

Another useful distinction: the consumer service Toss Pay is not the same thing as the Toss Payments gateway. The gateway API distinguishes TRANSFER, VIRTUAL_ACCOUNT and EASY_PAY. The word Toss alone cannot identify whether the buyer used a bank account, a card inside a convenient interface or another approved instrument.

Virtual account: instructions first, money later

In Toss Payments’ virtual-account integration, the confirmation call issues an account rather than completing payment. WAITING_FOR_DEPOSIT applies until funding; receipt of the correct amount leads to DONE. This is a documented product characteristic. A developer copying ordinary card-payment logic and fulfilling immediately after a successful API response may fulfil an unpaid instruction.

Retain paymentKey and orderId separately. virtualAccount includes accountNumber, bankCode, customerName and dueDate, with refundStatus and settlementStatus described separately. One paid flag cannot represent the entire lifecycle. A confirmed purchase, refund in progress and outstanding merchant settlement can all concern the same order.

The internal ledger should link the issued account to the exact amount, deadline and payment attempt. Keep original time-zone information as well as a consistent internal timeline, so overnight operations do not shift deadlines. Cancelling an unfunded order is not yet a refund: there is nothing to return. The customer should see cancellation of an instruction, not a promise of a nonexistent refund.

An unusual documented detail: status can move backward

Toss Payments warns of deposit errors that move DONE back to WAITING_FOR_DEPOSIT. Subscribing to both PAYMENT_STATUS_CHANGED and DEPOSIT_CALLBACK also produces two events concerning the same payment. Event documentation. That is enough reason to reject a design that stops listening forever after its first DONE event.

The operational implication is to authenticate webhooks using current guidance, retain transition history and route an exceptional backward transition for investigation. Do not automatically demand another deposit based on one inconsistent event. First establish current provider status and explain the verified situation; otherwise an exception can become a duplicate payment and customer dispute.

The documentation separately states that, with the correct amount, a virtual-account payment may succeed even when the purchaser’s name and depositor’s name differ. That is not permission to ignore payer identification where the business has such obligations. Matching a receipt by account and amount does not prove that the funding source belongs to the registered customer.

Account refunds really do need additional information

For refunds of funded virtual-account payments, Toss Payments requires refundReceiveAccount details: bank, account number and holder name. Those details are unnecessary when cancelling before funding. Documentation also limits retrieval of refundReceiveAccount through the relevant checkout flow to 30 minutes after the payment window opens. Handle the collected information under the agreed data-protection requirements.

The holder name is not decorative text. The payment-method guide highlights validation difficulties with corporate account names and Latin-script names containing spaces. The refund form should explain that the bank’s registered spelling is required; support should distinguish name mismatch, incorrect account number and technical failure. Substituting someone else’s recipient account is not an acceptable repair.

A practical test has two independent scenarios: cancel an issued but unfunded account, and return an approved amount after confirmed funding. Then inspect the report and actual outcome. Demonstrating only the first scenario does not prove that monetary refunds work.

KakaoPay: returning with a token still requires approve

KakaoPay’s single-payment flow starts with ready using order information and CID, then stores tid. After customer authentication, pg_token arrives; the server calls approve with the saved tid, partner_order_id and partner_user_id. Responses distinguish payment tid from request-specific aid, preserving links for cancellation and investigation. Single-payment API.

Developers must cover more than the happy path. A customer may close the page, open a second order or return after a delay. Token matching to the correct saved context belongs on the server. Do not choose “the latest order for this phone.” Device and session data assist the interface, but cannot replace a unique link between financial attempt and order.

The contract defines available methods and settlement

KakaoPay describes merchant review before issuing a merchant code. Toss Payments similarly directs merchants to check contracted payment methods. Sandbox credentials and an installed SDK do not establish permission to activate every option. The launch record should identify the legal entity, accepted category, MID/CID, methods and settlement account.

A separate settlement report remains necessary even with clean webhooks. Toss Payments exposes settlement information; verify actual timing and deductions against your contract. Reconcile orders, successful receipts, cancellations and net payable. This distinguishes a technically completed purchase from a PSP obligation still outstanding until the bank transfer arrives.

Korean payment access is not general gambling permission

South Korean criminal legislation separately addresses gambling and establishing places or spaces for it. The ability to obtain a virtual account or complete a KakaoPay payment does not establish permission for a particular online casino. An overseas licence does not replace the applicable local legal basis and provider approval; disguising the category is not a valid solution.

A good Korean checkout reduces guesswork rather than merely adding buttons. The buyer understands the next step, operations see authoritative status, finance finds the settlement, and refunds finish on an approved basis using verified details. That is what distinguishes controlled merchant acceptance from an incidental collection of transfers.