Покупатель получает банковские реквизиты при оформлении, позже переводит воны и ждёт исполнения нужного заказа. Операционной команде важно знать, какой заказ оплачен, какие сведения подтверждают личность плательщика и на какой счёт пойдёт возврат. С этих вопросов полезно начинать сравнение платёжных провайдеров Южной Кореи.
Числа для предметного сравнения провайдеров
Мы разобрали исторические платёжные предложения, связанные только с этой страной. Всего уникальных записей: 54. Приём платежей: 32; выплаты: 22. На их основе можно предметно сравнить стоимость платежей, доступность денег и операционные требования. Предложения с несколькими странами исключены из расчётов: таких записей 70.
Источник — выгрузка PayStar от 14 сентября 2026 года с данными, предоставленными платёжными шлюзами. Агрегаты пересчитаны, но коммерческие заявления независимо не подтверждены. Это историческая выборка, а не обзор рынка, число PSP или методов, доказательство действующих подключений или текущей доступности. Условия могут меняться еженедельно и чаще. Независимые связи страны, валюты и метода не подтверждают все возможные платёжные маршруты. Число предложений по направлениям и график расчётных сроков охватывают все записанные валюты. Только сравнение процентов ниже ограничено записями комиссий в KRW.
Что показывают записанные процентные компоненты в KRW
Мы считаем среднее арифметическое явно указанных процентных компонентов в KRW, с одинаковым весом каждого сопоставимого предложения. Запись включена только при совпадении структурированного процента с одним однозначным процентом в исходном описании комиссии. Другая валюта комиссии, пропущенный процент и неоднозначное описание исключены.
Также исключены проценты с оговорками «от», диапазонами, тарифными ступенями и явно ограниченными категориями клиентов. Точный номинальный процент может остаться в выборке при фиксированном минимуме или максимуме комиссии; эти ограничения всё равно влияют на итоговое списание.
| Направление | n | Среднее | Медиана | Диапазон |
|---|---|---|---|---|
| Приём | 25 | 8,59% | 8,3% | 4,5–14% |
| Выплаты | 20 | 3,56% | 3,5% | 2–6% |
Это процентные компоненты, а не полная цена платежа. Отдельно нужно учитывать фиксированные комиссии, FX, налоги, резервы, минимумы, возвраты и другие нестандартные операции. Выборка не взвешена по обороту, не содержит измеренной конверсии и не позволяет ранжировать качество провайдеров. Малые или недостаточно независимые группы не публикуются.
Условный расчёт для одного платежа
Возьмём условный платёж 20 000 KRW; это не типичный чек рынка. Применение округлённых средних из таблицы даёт:
- Приём: 20 000 KRW × 8,59% = 1 718 KRW.
- Выплаты: 20 000 KRW × 3,56% = 712 KRW.
Каждая строка — отдельное направление, а не общая цена комплексной услуги. Расчёт показывает только процентную часть. До расчёта чистой выручки запросите актуальные условия для вашего чека, оборота, модели бизнеса и валюты расчётов.
Важно, когда деньги становятся доступны
Успешное уведомление об оплате и деньги, доступные бизнесу, — разные события. Используйте записанные сроки как вопросы к провайдеру: что запускает отсчёт, какой действует cut-off, учитываются ли выходные, на какой счёт приходят средства и могут ли резерв или проверка отложить доступность?
Для выплат согласуйте предфинансирование, проверку получателя, обработку отказов и отражение вернувшихся денег в остатке. Срок расчётов по приёму не доказывает время завершения выплаты.
Пример планирования денежного буфера
Если бизнес должен ежедневно финансировать обязательства на 2 000 000 KRW, разрыв в один день требует 2 000 000 KRW, в три дня — 6 000 000 KRW. Дополнительный буфер составляет 4 000 000 KRW. Это условная модель постоянного потока без комиссий, резервов и колебаний, а не наблюдаемое обещание сроков расчётов.
Начните со сценария, который стоит за названием способа оплаты
Виртуальный счёт — определённый сценарий банковской оплаты. Покупатель получает реквизиты, затем до установленного срока переводит сумму заказа. В публичном руководстве по виртуальным счетам различаются счета для отдельных заказов и постоянные счета, связанные с клиентом. Уточните, допускает ли услуга разных покупателей и отправителей денег и какие сведения идентифицируют каждого. Описанная структура относится к этому конкретному продукту; правила другого PSP нужно проверять отдельно.
Для выбора решения в Южной Корее это существенное различие. Привязка к заказу отвечает на вопрос «что оплачено?», а сведения о плательщике — «кто отправил деньги?». Попросите PSP показать оба ответа в тех полях, которые действительно получит ваш бизнес. Имя, введённое при оформлении, не должно незаметно превратиться в учёте в подтверждённые банковские данные отправителя.
Начните со своего сценария: разовые покупки, повторные счета на оплату или маркетплейс с выплатами продавцам. Для каждого нужны свои правила выдачи виртуальных счетов и платёжных идентификаторов.
Проверьте привязку к заказу до выбора провайдера
До сравнения основных комиссий запросите образец записи об оплате и отчёта о расчётах на синтетических либо надлежащим образом обезличенных данных. Команда должна связать номер заказа, выданный счёт, ожидаемую сумму, подтверждённое поступление и последующий возврат, если он был.
Используйте простой условный тест: у покупателя два неоплаченных заказа по 40 000 KRW, а перевод один. PSP должен показать, к какому заказу отнесена оплата и как ваша система получает это решение. Если счёт можно использовать повторно, проверьте новый заказ после истечения срока предыдущего. Согласуйте порядок действий, если покупатель скопирует старые реквизиты.
| Требование | Что запросить |
|---|---|
| Правильная привязка к заказу | Запись об оплате, связанная с одним заказом, включая правило для заказов с одинаковой суммой |
| Сведения о плательщике | Источник и значение каждого поля о покупателе, отправителе денег и владельце счёта |
| Истечение срока | Срок, показанный покупателю, и итоговое состояние заказа и оплаты |
| Разбор исключений | Прослеживаемый процесс для переводов без найденного заказа, неверных сумм и спорной привязки |
Это проверочные сценарии, а не предположения о возможностях провайдера. По результатам станет понятнее, сможет ли финансовая команда сверять платежи автоматически или потребуется отдельная очередь ручного разбора.
Подтвердите поступление до исполнения заказа
Выдача реквизитов и завершение оплаты — разные события. Официальная документация по webhook предусматривает уведомления о поступлении на виртуальный счёт и отмене поступления наряду с отдельными обновлениями платежей и выплат. Решение об исполнении заказа должно учитывать смысл этих событий в выбранной интеграции.
Попросите показать задержанное уведомление, повторную доставку одного уведомления и последующую корректировку статуса. Ваша система заказов должна сохранять исходный идентификатор платежа и последовательно применять результаты. Согласуйте способ получить достоверное состояние операции, если уведомление не пришло.
Для сверки платежей сохраняйте три отметки времени: создание запроса на оплату, подтверждение поступления и перечисление средств от PSP вашему бизнесу. Оплаченный заказ и деньги, доступные казначейству, нужны для разных операционных решений.
Рассматривайте возврат как отдельную операцию с банковскими реквизитами
Возврат платежа с виртуального счёта может требовать реквизиты, которые сообщает клиент. Например, публичный API отмены платежа для этого способа возврата требует указать банк, номер счёта и зарегистрированное имя его владельца.
Уточните, кто собирает и проверяет эти сведения, какие изменения получателя требуют дополнительного контроля и как неуспешный возврат попадает к операторам. Если покупатель и отправитель денег различаются, согласуйте политику возвратов с провайдером до первого обращения в поддержку. Сохраните связь возврата с исходным платежом, а одобренные реквизиты назначения учитывайте отдельно.
Проверяйте выплаты в KRW по назначению и получателю
Начните требования к выплатам с реального обязательства бизнеса: возврат покупателю, расчёт с продавцом или другой согласованный платёж. Возможность принимать деньги не доказывает поддержку любого исходящего назначения.
В местной инфраструктуре есть конкретные функции, о которых стоит спросить. Сервис проверки получателя KFTC позволяет участвующим организациям заранее узнать имя получателя и возможность зачисления на счёт. Уточните, предоставляет ли ваш PSP подходящую проверку и что делать, если ответ отличается от сохранённых данных.
Публичная документация выплат продавцам также показывает, почему нужно разделять регистрацию получателя, доступный остаток и итог выплаты. Она описывает состояния регистрации и проверки продавца и предупреждает, что выплата может завершиться ошибкой после первоначально успешного запроса. Этот пример не устанавливает доступность услуги для всех компаний и назначений.
Сравните поддерживаемые категории получателей, финансирование, рабочие окна, накопительные лимиты и подтверждения окончательного статуса. Попросите пример неуспешной выплаты и соответствующей записи для сверки, включая момент повторной доступности денег.
Роль PayStar
PayStar предоставляет информацию для сравнения платёжных решений и, если это согласовано, технический слой для подключения и управления ими. PayStar не является банком или поставщиком платёжных услуг и не принимает, не хранит и не осуществляет расчёты по средствам клиентов или бизнеса от своего имени.
Вы выбираете платёжного провайдера и заключаете с ним прямой договор. Провайдер обрабатывает платежи и выполняет расчёты по этому договору. Доступность услуги, необходимые разрешения и коммерческие условия проверяются для вашей компании и задачи. Описание метода в статье не означает, что он доступен через PayStar именно вашему бизнесу.
Информация о платёжных вариантах бесплатна. Обработка платежей и согласованные технические услуги имеют отдельные коммерческие условия.
Официальные источники и рамки исследования
- Toss Payments: virtual-account guide
- Toss Payments: webhooks
- Toss Payments: Payment APIs
- KFTC: recipient inquiry
- Toss Payments: seller payouts
Проверка источников: 8 октября 2026. Дата выгрузки остаётся 14 сентября 2026. Описания местных систем дают контекст, а не подтверждение возможностей конкретного провайдера.