Южная Корея: виртуальные счета, банковские переводы и кнопки KakaoPay/Toss

В корейском платёжном интерфейсе кнопка может скрывать принципиально разные обязательства. Банковский перевод, виртуальный счёт для оплаты заказа и easy-pay через KakaoPay или Toss Pay не стоит сводить к общей категории «локальный P2P». Они по-разному инициируются, подтверждаются и возвращаются. Для процессинга это прежде всего вопрос жизненного цикла платежа.

Ещё одно полезное различие: потребительский сервис Toss Pay и платёжный шлюз Toss Payments — не одно и то же название метода. В API шлюза отдельно представлены TRANSFER, VIRTUAL_ACCOUNT и EASY_PAY. Нельзя по слову Toss определить, использовал ли покупатель банковский счёт, карту внутри удобного интерфейса или другой согласованный инструмент.

Virtual account: сначала реквизиты, потом деньги

В интеграции виртуальных счетов Toss Payments вызов подтверждения выдаёт счёт, а не завершает оплату. До внесения денег сохраняется WAITING_FOR_DEPOSIT; после поступления правильной суммы — DONE. Это документированная особенность данного продукта. Если разработчик переносит логику обычной карточной оплаты и выдаёт товар сразу после успешного API-ответа, он может выдать его за неоплаченные реквизиты.

Поля paymentKey и orderId нужно сохранять раздельно. В virtualAccount доступны accountNumber, bankCode, customerName, dueDate; отдельно описаны refundStatus и settlementStatus. Поэтому один флаг paid не способен выразить весь цикл. Подтверждённая покупка, возврат в обработке и незавершённый расчёт с мерчантом могут одновременно относиться к одному заказу.

Внутренний реестр должен связывать выданный счёт с точной суммой, сроком и попыткой оплаты. Рекомендуется хранить время в исходном часовом поясе и в единой внутренней шкале, чтобы дедлайны не смещались при ночной смене. Если заказ отменён до внесения денег, это ещё не возврат: возвращать пока нечего. Пользователь должен видеть именно отмену инструкции, а не обещание несуществующего refund.

Необычная деталь из документации: статус может вернуться назад

Toss Payments предупреждает об ошибках внесения средств, при которых DONE меняется обратно на WAITING_FOR_DEPOSIT. Также подписка одновременно на PAYMENT_STATUS_CHANGED и DEPOSIT_CALLBACK создаёт два события об одном платеже. Описание событий. Это достаточная причина не строить обработку по принципу «однажды увидели DONE — больше ничего не читаем».

Операционный вывод — проверять подлинность webhook по действующей инструкции, сохранять историю переходов и направлять исключительный обратный переход на разбор. Не следует автоматически просить покупателя внести деньги ещё раз только по одному несогласованному событию. Сначала уточняют текущее состояние у провайдера и объясняют клиенту подтверждённую ситуацию, иначе исключение превращается в двойное списание и конфликт.

Отдельно задокументировано, что при правильной сумме имя покупателя и имя вносящего средства могут различаться без технического отказа virtual-account оплаты. Это не разрешение игнорировать установление плательщика в бизнесе с такими обязанностями. Успешное сопоставление поступления по счёту и сумме не доказывает, что источник денег принадлежит зарегистрированному клиенту.

Возврат на счёт: здесь действительно нужны дополнительные данные

При возврате уже оплаченного виртуального счёта Toss Payments требует данные refundReceiveAccount: банк, номер счёта и имя владельца. До внесения денег эти реквизиты для отмены не нужны. В документации также указано ограниченное окно получения refundReceiveAccount через соответствующий сценарий интерфейса: 30 минут после открытия платёжного окна. Полученные сведения следует обрабатывать по согласованным требованиям защиты данных.

Имя владельца — не декоративная строка. В руководстве по методам оплаты отдельно отмечены проблемы проверки имён корпоративных счетов и латинских имён с пробелами. Поэтому форма возврата должна объяснять, что требуется банковское написание, а служба поддержки — различать ошибку имени, неверный номер и технический сбой. Нельзя «исправлять» не прошедший проверку счёт подстановкой чужого получателя.

Практический тест состоит из двух самостоятельных сценариев: отменить выданный, но неоплаченный счёт и вернуть разрешённую сумму после подтверждённого поступления. Затем проверить отчёт и фактический результат. Если команда продемонстрировала только первый сценарий, способность делать денежные возвраты ещё не доказана.

KakaoPay: возвращение с токеном ещё требует approve

В однократной оплате KakaoPay сначала вызывается ready с данными заказа и CID, затем сохраняется tid. После пользовательской аутентификации приходит pg_token; сервер вызывает approve, связывая его с tid, partner_order_id и partner_user_id. Ответы различают tid платежа и aid конкретного запроса. Это позволяет не терять связь при отмене и разборе. Single-payment API.

Для разработчика важен не только happy path. Пользователь может закрыть страницу, открыть второй заказ или вернуться после задержки. Сопоставление токена с правильным сохранённым контекстом должно происходить на сервере. Нельзя выбирать «последний заказ этого телефона». Устройство и сессия помогают интерфейсу, но не заменяют однозначную связь финансовой попытки с заказом.

Договор определяет доступные методы и расчёт

KakaoPay описывает проверку мерчанта перед выдачей торгового кода. Toss Payments также направляет к проверке договорно подключённых методов. Тестовые credentials и установленный SDK не означают, что предприятие получило право включить любой способ. В карте запуска фиксируют юридическое лицо, разрешённую категорию, MID/CID, методы и расчётный счёт.

Отдельный settlement report нужен даже при аккуратных webhook. В API Toss Payments предусмотрена информация о расчётах и выплатах; фактический график и удержания проверяются по вашему договору. Сверяйте заказы, успешные поступления, отмены и net к выплате. Это позволяет отличить технически завершённую покупку от обязательства PSP, которое ещё не погашено банковским перечислением.

Корейский платёжный рынок не является общим разрешением на гемблинг

Уголовное законодательство Республики Корея отдельно регулирует азартные игры и организацию мест или пространств для них. Нельзя выводить допустимость конкретного онлайн-казино из возможности получить виртуальный счёт или провести KakaoPay-платёж. Иностранная лицензия не заменяет применимое местное основание и одобрение провайдера; маскировка категории не является допустимым решением.

Хороший корейский checkout требует меньшего количества догадок, а не большего количества кнопок. Покупатель должен понимать следующий шаг, оператор — видеть авторитетный статус, бухгалтер — находить расчёт, а возврат — завершаться по проверенному основанию и на согласованные реквизиты. Именно это отличает управляемый торговый приём от случайного набора переводов.