# Платёжные провайдеры Южной Кореи: виртуальные счета и выплаты в KRW

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

## Числа для предметного сравнения провайдеров

Мы разобрали исторические платёжные предложения, связанные только с этой страной. **Всего уникальных записей: 54**. Приём платежей: 32; выплаты: 22. На их основе можно предметно сравнить стоимость платежей, доступность денег и операционные требования. Предложения с несколькими странами исключены из расчётов: таких записей 70.

Источник — выгрузка PayStar от 14 сентября 2026 года с данными, предоставленными платёжными шлюзами. Агрегаты пересчитаны, но коммерческие заявления независимо не подтверждены. Это историческая выборка, а не обзор рынка, число PSP или методов, доказательство действующих подключений или текущей доступности. Условия могут меняться еженедельно и чаще. Независимые связи страны, валюты и метода не подтверждают все возможные платёжные маршруты. Число предложений по направлениям и график расчётных сроков охватывают все записанные валюты. Только сравнение процентов ниже ограничено записями комиссий в KRW.

Уникальные предложения только этого GEO по всем записанным валютам: 54. Это не методы, провайдеры или действующие подключения. [Скачать SVG](https://paystar.uk/south-korea-payment-solutions/media/2026-10-08-v2/charts/offers-ru-desktop-download.svg)

## Что показывают записанные процентные компоненты в KRW

Мы считаем среднее арифметическое явно указанных процентных компонентов в KRW, с одинаковым весом каждого сопоставимого предложения. Запись включена только при совпадении структурированного процента с одним однозначным процентом в исходном описании комиссии. Другая валюта комиссии, пропущенный процент и неоднозначное описание исключены.

Также исключены проценты с оговорками «от», диапазонами, тарифными ступенями и явно ограниченными категориями клиентов. Точный номинальный процент может остаться в выборке при фиксированном минимуме или максимуме комиссии; эти ограничения всё равно влияют на итоговое списание.

| Направление | n | Среднее | Медиана | Диапазон |
| --- | --- | --- | --- | --- |
| Приём | 25 | 8,59% | 8,3% | 4,5–14% |
| Выплаты | 20 | 3,56% | 3,5% | 2–6% |

Только явно указанные процентные компоненты в KRW. n — сопоставимая выборка направления; пропуски исключены, а не приняты за нулевую комиссию. [Скачать SVG](https://paystar.uk/south-korea-payment-solutions/media/2026-10-08-v2/charts/fees-ru-desktop-download.svg)

**Это процентные компоненты, а не полная цена платежа.** Отдельно нужно учитывать фиксированные комиссии, FX, налоги, резервы, минимумы, возвраты и другие нестандартные операции. Выборка не взвешена по обороту, не содержит измеренной конверсии и не позволяет ранжировать качество провайдеров. Малые или недостаточно независимые группы не публикуются.

### Условный расчёт для одного платежа

Возьмём условный платёж 20 000 KRW; это не типичный чек рынка. Применение округлённых средних из таблицы даёт:

- Приём: 20 000 KRW × 8,59% = **1 718 KRW**.
- Выплаты: 20 000 KRW × 3,56% = **712 KRW**.

Каждая строка — отдельное направление, а не общая цена комплексной услуги. Расчёт показывает только процентную часть. До расчёта чистой выручки запросите актуальные условия для вашего чека, оборота, модели бизнеса и валюты расчётов.

## Важно, когда деньги становятся доступны

Предложения приёма по всем записанным валютам. T/D сохранены как в источнике: календарные или рабочие дни не предполагаются. «Другие» включает сложные обозначения и объединённые группы менее 3 записей. Это не гарантия сроков расчётов. [Скачать SVG](https://paystar.uk/south-korea-payment-solutions/media/2026-10-08-v2/charts/timing-ru-desktop-download.svg)

Успешное уведомление об оплате и деньги, доступные бизнесу, — разные события. Используйте записанные сроки как вопросы к провайдеру: что запускает отсчёт, какой действует cut-off, учитываются ли выходные, на какой счёт приходят средства и могут ли резерв или проверка отложить доступность?

Для выплат согласуйте предфинансирование, проверку получателя, обработку отказов и отражение вернувшихся денег в остатке. Срок расчётов по приёму не доказывает время завершения выплаты.

### Пример планирования денежного буфера

Если бизнес должен ежедневно финансировать обязательства на 2 000 000 KRW, разрыв в один день требует 2 000 000 KRW, в три дня — 6 000 000 KRW. Дополнительный буфер составляет 4 000 000 KRW. Это условная модель постоянного потока без комиссий, резервов и колебаний, а не наблюдаемое обещание сроков расчётов.

## Начните со сценария, который стоит за названием способа оплаты

Виртуальный счёт — определённый сценарий банковской оплаты. Покупатель получает реквизиты, затем до установленного срока переводит сумму заказа. В публичном [руководстве по виртуальным счетам](https://docs.tosspayments.com/resources/glossary/virtual-account) различаются счета для отдельных заказов и постоянные счета, связанные с клиентом. Уточните, допускает ли услуга разных покупателей и отправителей денег и какие сведения идентифицируют каждого. Описанная структура относится к этому конкретному продукту; правила другого PSP нужно проверять отдельно.

Для выбора решения в Южной Корее это существенное различие. Привязка к заказу отвечает на вопрос «что оплачено?», а сведения о плательщике — «кто отправил деньги?». Попросите PSP показать оба ответа в тех полях, которые действительно получит ваш бизнес. Имя, введённое при оформлении, не должно незаметно превратиться в учёте в подтверждённые банковские данные отправителя.

Начните со своего сценария: разовые покупки, повторные счета на оплату или маркетплейс с выплатами продавцам. Для каждого нужны свои правила выдачи виртуальных счетов и платёжных идентификаторов.

## Проверьте привязку к заказу до выбора провайдера

До сравнения основных комиссий запросите образец записи об оплате и отчёта о расчётах на синтетических либо надлежащим образом обезличенных данных. Команда должна связать номер заказа, выданный счёт, ожидаемую сумму, подтверждённое поступление и последующий возврат, если он был.

Используйте простой условный тест: у покупателя два неоплаченных заказа по **40 000 KRW**, а перевод один. PSP должен показать, к какому заказу отнесена оплата и как ваша система получает это решение. Если счёт можно использовать повторно, проверьте новый заказ после истечения срока предыдущего. Согласуйте порядок действий, если покупатель скопирует старые реквизиты.

| Требование | Что запросить |
| --- | --- |
| Правильная привязка к заказу | Запись об оплате, связанная с одним заказом, включая правило для заказов с одинаковой суммой |
| Сведения о плательщике | Источник и значение каждого поля о покупателе, отправителе денег и владельце счёта |
| Истечение срока | Срок, показанный покупателю, и итоговое состояние заказа и оплаты |
| Разбор исключений | Прослеживаемый процесс для переводов без найденного заказа, неверных сумм и спорной привязки |

Это проверочные сценарии, а не предположения о возможностях провайдера. По результатам станет понятнее, сможет ли финансовая команда сверять платежи автоматически или потребуется отдельная очередь ручного разбора.

## Подтвердите поступление до исполнения заказа

Выдача реквизитов и завершение оплаты — разные события. Официальная [документация по webhook](https://docs.tosspayments.com/guides/v2/webhook) предусматривает уведомления о поступлении на виртуальный счёт и отмене поступления наряду с отдельными обновлениями платежей и выплат. Решение об исполнении заказа должно учитывать смысл этих событий в выбранной интеграции.

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

Для [сверки платежей](https://paystar.uk/reconciliation) сохраняйте три отметки времени: создание запроса на оплату, подтверждение поступления и перечисление средств от PSP вашему бизнесу. Оплаченный заказ и деньги, доступные казначейству, нужны для разных операционных решений.

## Рассматривайте возврат как отдельную операцию с банковскими реквизитами

Возврат платежа с виртуального счёта может требовать реквизиты, которые сообщает клиент. Например, публичный [API отмены платежа](https://docs.tosspayments.com/en/api-guide) для этого способа возврата требует указать банк, номер счёта и зарегистрированное имя его владельца.

Уточните, кто собирает и проверяет эти сведения, какие изменения получателя требуют дополнительного контроля и как неуспешный возврат попадает к операторам. Если покупатель и отправитель денег различаются, согласуйте политику возвратов с провайдером до первого обращения в поддержку. Сохраните связь возврата с исходным платежом, а одобренные реквизиты назначения учитывайте отдельно.

## Проверяйте выплаты в KRW по назначению и получателю

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

В местной инфраструктуре есть конкретные функции, о которых стоит спросить. [Сервис проверки получателя KFTC](https://openapi.kftc.or.kr/openapi/openbanking/receiveInquiry) позволяет участвующим организациям заранее узнать имя получателя и возможность зачисления на счёт. Уточните, предоставляет ли ваш PSP подходящую проверку и что делать, если ответ отличается от сохранённых данных.

Публичная [документация выплат продавцам](https://docs.tosspayments.com/en/integration-payouts) также показывает, почему нужно разделять регистрацию получателя, доступный остаток и итог выплаты. Она описывает состояния регистрации и проверки продавца и предупреждает, что выплата может завершиться ошибкой после первоначально успешного запроса. Этот пример не устанавливает доступность услуги для всех компаний и назначений.

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

## Роль PayStar

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

Вы выбираете платёжного провайдера и заключаете с ним прямой договор. Провайдер обрабатывает платежи и выполняет расчёты по этому договору. Доступность услуги, необходимые разрешения и коммерческие условия проверяются для вашей компании и задачи. Описание метода в статье не означает, что он доступен через PayStar именно вашему бизнесу.

Информация о платёжных вариантах бесплатна. Обработка платежей и согласованные технические услуги имеют отдельные коммерческие условия.

## Официальные источники и рамки исследования

- [Toss Payments: virtual-account guide](https://docs.tosspayments.com/resources/glossary/virtual-account)
- [Toss Payments: webhooks](https://docs.tosspayments.com/guides/v2/webhook)
- [Toss Payments: Payment APIs](https://docs.tosspayments.com/en/api-guide)
- [KFTC: recipient inquiry](https://openapi.kftc.or.kr/openapi/openbanking/receiveInquiry)
- [Toss Payments: seller payouts](https://docs.tosspayments.com/en/integration-payouts)

Проверка источников: 8 октября 2026. Дата выгрузки остаётся 14 сентября 2026. Описания местных систем дают контекст, а не подтверждение возможностей конкретного провайдера.