Перейти к содержанию

Типы операций (operationType)

Обзор одиннадцати бизнес-операций, которые Payment Manager умеет обрабатывать. Каждый тип отвечает на простой вопрос: «кто, кому, за что и каким способом передаёт деньги». В этом документе нет ни одной строки кода и ни одного имени поля — только бизнес-смысл, инициатор, получатель, типичный пример и сводка о применяемых правилах (комиссии, лимиты, верификации). Технические детали (парсеры, валидация, реестры) живут в dev-разделе.

На 2026-05-29 в системе ровно одиннадцать типов операций. Список закрыт: ни IPPS_DEPOSIT, ни MINIAPP_PAYMENT, ни какие-либо иные имена, не приведённые ниже, в системе не существуют. Если клиент пытается прислать незнакомый код — запрос будет отклонён ещё до обращения к балансам.

Один и тот же тип может обслуживаться разной «трубой» (внутренний перевод между кошельками, межбанковский шлюз IPPS, мерчантский инвойс) — но бизнес-смысл всегда определяется именно типом операции, а не способом доставки.

Краткий обзор: одиннадцать операций на одной странице

Тип операции Куда движутся деньги Кто запускает
P2P_TRANSFER Клиент → клиент внутри OneWallet Мобильное приложение клиента
IPPS_WITHDRAWAL Клиент → внешний банк через IPPS Мобильное приложение клиента
THAI_QR_PAY Клиент → продавец через PromptPay QR Мобильное приложение клиента (сканер QR)
WITHDRAWAL Клиент → внешний счёт с привязкой к заявке Партнёрский сервис или Auth Center
QP_TOPUP Внешний банк / партнёр → клиент Внутренний шлюз пополнений
MINIAPP_CHARGE Клиент → мерчант мини-приложения Мини-приложение в OneWallet
MINIAPP_CREDIT Мерчант мини-приложения → клиент Мини-приложение мерчанта
SERVICE_DEPOSIT Служебный счёт системы → клиент Сервисный модуль (например, крипто-вебхук)
ADMIN_TRANSFER Любой счёт → любой счёт (ручная корректировка) Сотрудник OneWallet через админ-панель
INVOICE_PAYMENT Клиент → мерчант по выставленному инвойсу Мерчант создаёт, клиент подтверждает
NFC_CHARGE Клиент → мерчант при касании NFC-метки POS-терминал мерчанта

Группируя смысл, в системе можно выделить четыре крупных семейства:

  • Внутренние переводы клиент ↔ клиент / клиент ↔ мерчант: P2P_TRANSFER, MINIAPP_CHARGE, MINIAPP_CREDIT, NFC_CHARGE. Деньги остаются внутри OneWallet, операция исполняется быстро и без посредников.
  • Внешние выводы: IPPS_WITHDRAWAL, THAI_QR_PAY, WITHDRAWAL. Деньги уходят во внешние банки, мобильных операторов или сервисы оплаты счетов. Здесь обязательно участие государственного платёжного шлюза.
  • Внешние пополнения: QP_TOPUP. Деньги приходят извне — с банковского счёта клиента или партнёрской платформы.
  • Служебные / административные: SERVICE_DEPOSIT, ADMIN_TRANSFER, INVOICE_PAYMENT. Это не «обычные» клиентские платежи: сюда входят выплаты от партнёров, ручные корректировки бухгалтера, мерчантские инвойсы со сложным двух-шаговым подтверждением.

Дальше — карточка на каждый тип.

P2P_TRANSFER — перевод между пользователями

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

Кто инициирует. Мобильное приложение клиента (через Auth Center) — отправитель сам выбирает получателя из контактов или вводит идентификатор.

Кто получает. Другой пользователь OneWallet — обычный клиент, либо мерчант / агент, если перевод адресован им напрямую.

Типичный сценарий. Сосед перевёл другу 500 THB за совместный ужин: открыл приложение, выбрал контакт, ввёл сумму, подтвердил — друг получил деньги через секунду.

Комиссии и лимиты. Базовая комиссия — 1,5% от суммы перевода, удерживается до зачисления получателю (т. е. сумма у получателя совпадает с тем, что увидел отправитель в чеке «перевод 500 THB, комиссия 7,5 THB»). VIP-клиенты платят сниженную ставку — 0,5%. Пользователям с тегом «освобождён от комиссии» (например, в рамках акций, программ лояльности или внутренних переводов между собственными счетами) перевод обходится бесплатно. Жёстких сумм-лимитов на тип не зафиксировано — действуют общие лимиты кошелька клиента, зависящие от уровня KYC.

IPPS_WITHDRAWAL — вывод на внешний банковский счёт

Бизнес-смысл. Списание денег с кошелька OneWallet и зачисление их на внешний счёт получателя через государственный платёжный шлюз Таиланда (IPPS). Получателем может быть банковский счёт, e-wallet другой системы, мобильный номер или Biller ID.

Кто инициирует. Мобильное приложение клиента (через Auth Center). Пользователь сам выбирает банк-получатель и вводит реквизиты.

Кто получает. Внешний банк, мобильный оператор или сервис, подключённый к IPPS. С точки зрения OneWallet деньги уходят в государственный шлюз и оттуда — конечному получателю.

Типичный сценарий. Клиент выводит 8 000 THB на свой счёт в банке Bangkok Bank, чтобы оплатить аренду — выбирает «Вывод в банк», указывает номер счёта, подтверждает; через несколько минут перевод приходит в Bangkok Bank.

Комиссии и лимиты. Сумма одной операции — от 1 THB до 200 000 THB. Перед выводом проверяется, что пользователь зарегистрирован в IPPS (если нет — операция отклоняется с понятной ошибкой). Также обязателен корректно указанный тип получателя — мобильный номер, ID или номер счёта в зависимости от выбранного направления. Комиссии задаются тарифной сеткой и могут зависеть от размера и направления вывода.

THAI_QR_PAY — оплата по тайскому QR-коду (PromptPay)

Бизнес-смысл. Оплата товара или услуги сканированием QR-кода продавца. Технически — это тот же поток, что и IPPS_WITHDRAWAL, но инициируется иначе: клиент не выбирает банк вручную, а сканирует QR на чеке, наклейке, экране POS.

Кто инициирует. Мобильное приложение клиента — пользователь подносит камеру к QR-коду PromptPay.

Кто получает. Магазин, ресторан, такси, рынок — любая точка, принимающая PromptPay. По сути — внешний счёт, как и в IPPS-выводе.

Типичный сценарий. Покупатель в кафе сканирует QR-наклейку на стойке, видит сумму 180 THB, подтверждает — официант видит уведомление о поступлении на терминал.

Комиссии и лимиты. Тот же коридор, что и у IPPS-вывода: от 1 THB до 200 000 THB за одну операцию. Те же требования по регистрации в IPPS и заполненности реквизитов получателя. Отдельный код операции нужен бизнесу для аналитики (доля QR-оплат, поведение в торговле) и для возможности назначить QR-платежам собственную тарифную сетку, отличную от обычного банковского вывода.

WITHDRAWAL — обобщённый вывод средств

Бизнес-смысл. Универсальный канал вывода денег с кошелька с обязательной привязкой к внешнему идентификатору операции — например, к номеру заявки, заведённой на стороне Auth Center или партнёрской системы. Используется в сценариях, где IPPS — лишь один из возможных способов доставки, а ключевую роль играет именно сверка с внешним учётом.

Кто инициирует. Auth Center или партнёрский сервис, у которого уже есть собственный идентификатор заявки на вывод.

Кто получает. Внешний счёт получателя — банк, кошелёк другой системы, мерчант-партнёр.

Типичный сценарий. Клиент через партнёрский сайт оформил вывод денег на свой банковский счёт; партнёр создаёт заявку у себя, присваивает ей номер и передаёт его в OneWallet — чтобы потом можно было сверить статусы с обеих сторон.

Комиссии и лимиты. Сумма-коридор задаётся в момент исполнения через ту же шину вывода, что и IPPS. Главное обязательное условие — наличие внешнего идентификатора заявки; без него операция отклоняется. Комиссии — по общей тарифной сетке вывода. На стороне OneWallet эта операция аккуратно отделена от обычного IPPS-вывода именно потому, что обязательная привязка к внешней заявке меняет правила сверки и поддержки: при разборе спора оператор всегда начинает поиск по этому идентификатору.

QP_TOPUP — пополнение кошелька через Quick Pay

Бизнес-смысл. Зачисление денег на кошелёк OneWallet из внешнего источника — банковского перевода, эквайринга, корпоративной выплаты. Обратное направление к выводу: деньги приходят извне и появляются на балансе клиента.

Кто инициирует. Внутренний шлюз пополнений — после того, как партнёрский банк или Quick Pay подтвердили зачисление на корреспондентский счёт OneWallet.

Кто получает. Пользователь OneWallet — обычный клиент, который ждёт пополнения.

Типичный сценарий. Клиент перевёл 5 000 THB со своего банковского счёта в OneWallet через Quick Pay; банк подтвердил поступление, шлюз OneWallet увидел подтверждение и зачислил сумму на кошелёк клиента.

Комиссии и лимиты. Дополнительной верификации со стороны клиента не требуется — поступление подтверждается на стороне шлюза. Комиссии (если они есть) обычно удерживаются партнёрским банком, а не OneWallet. Размер пополнения ограничивается лимитами кошелька клиента и правилами KYC: пользователь с базовой верификацией не сможет принять сумму больше своего месячного потолка, такие случаи приведут к отказу на стороне шлюза. Для службы поддержки это «обычная штатная операция»: если у клиента не пришли деньги, разбор начинается со сверки на стороне партнёра — был ли он подтверждён вообще.

MINIAPP_CHARGE — списание у клиента в мини-приложении

Бизнес-смысл. Покупка внутри мини-приложения, встроенного в OneWallet: клиент платит мерчанту мини-аппа за товар, услугу, билет, подписку. Деньги перемещаются внутри системы, без выхода во внешние банки.

Кто инициирует. Мини-приложение клиента (через Auth Center) — клиент нажимает «Купить» / «Оплатить» в интерфейсе мини-аппа.

Кто получает. Мерчант мини-приложения — продавец, чьё мини-приложение клиент использует.

Типичный сценарий. Пользователь покупает билет в кино прямо в мини-аппе кинотеатра внутри OneWallet: выбрал место, нажал «Оплатить 250 THB» — сумма ушла на счёт кинотеатра, билет открылся в приложении.

Комиссии и лимиты. Базовая комиссия — 2% от суммы покупки, удерживается после успешной оплаты. Клиенты с тегом «освобождён от комиссии» платят без процента (например, в рамках программ лояльности). Деление комиссии между OneWallet и партнёрским мини-аппом в будущем будет настраиваться по каждому мерчанту индивидуально.

MINIAPP_CREDIT — возврат / выплата от мини-приложения клиенту

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

Кто инициирует. Мини-приложение мерчанта (через Auth Center) — обычно автоматически по бизнес-правилу или вручную оператором поддержки.

Кто получает. Клиент OneWallet, изначально совершивший покупку.

Типичный сценарий. Покупатель отменил билет в кино за 30 минут до сеанса — мини-приложение кинотеатра возвращает 250 THB на его кошелёк; сумма мгновенно появляется на балансе.

Комиссии и лимиты. Возврат, как правило, идёт без комиссии — это сервисная операция мерчанта, и удерживать с клиента процент за возврат было бы некрасиво. Сумма ограничена остатком на счёте мерчанта внутри мини-аппа: если мерчант успел вывести выручку, для возврата сначала придётся пополнить мерчантский баланс. Жёстких лимитов на сам тип нет — но крупные возвраты (например, отмена бронирования отеля на десятки тысяч батов) обычно сопровождаются заметкой о причине, чтобы аудит и финансовый отдел могли потом легко найти такую операцию.

SERVICE_DEPOSIT — зачисление со служебного счёта

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

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

Кто получает. Пользователь OneWallet — клиент, для которого предназначено служебное зачисление.

Типичный сценарий. Клиент обменял в крипто-партнёре 100 USDT на тайские баты; партнёр подтвердил курс и сумму, и сервисный вебхук попросил OneWallet зачислить клиенту 3 480 THB со служебного счёта криптообменника.

Комиссии и лимиты. Размер одной операции — от 1 сатанга до примерно 100 миллионов тайских батов; этого с большим запасом хватает для всех бизнес-кейсов. Получатель обязан быть указан явно — служебный модуль никогда не угадывает, кому именно зачислять деньги. Дополнительные комиссии обычно не применяются: операция сервисная.

ADMIN_TRANSFER — административный перевод

Бизнес-смысл. Ручной перевод между любыми счетами системы — клиентскими, мерчантскими, агентскими, служебными, корреспондентскими. Используется для корректировок, разовых компенсаций, разбора инцидентов, миграционных операций между счетами при пересборке учёта.

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

Кто получает. Любой счёт в системе, на который у роли «администратор» есть право — клиент, мерчант, агент, технический счёт.

Типичный сценарий. Клиент пожаловался, что у него «съело» 200 THB при сбое — после разбора в логах бухгалтер делает ручной возврат с резервного счёта на кошелёк клиента, оставляя в комментарии номер обращения и причину.

Комиссии и лимиты. Сумма одной операции — от 1 сатанга до примерно 100 миллионов батов. Комиссии в админ-переводах не применяются — это служебная операция. Все переводы фиксируются в журнале с указанием инициатора и причины; нестандартные направления (например, перевод между техническими счетами) требуют отдельного согласования.

INVOICE_PAYMENT — оплата мерчантского инвойса

Бизнес-смысл. Двух-шаговая мерчантская оплата: сначала мерчант (например, через свой POS-терминал) выставляет инвойс с фиксированной суммой и QR-кодом, затем клиент сканирует этот QR и подтверждает оплату. Инвойс может «жить» ограниченное время — например, 10 минут.

Кто инициирует. Создание инвойса — мерчант через свой терминал или приложение продавца. Оплату подтверждает клиент через мобильное приложение OneWallet, сканируя QR.

Кто получает. Мерчант — владелец QR. Деньги списываются с клиента и зачисляются на счёт продавца после подтверждения.

Типичный сценарий. Покупатель на кассе магазина видит на экране POS QR-инвойс на сумму 1 240 THB — сканирует его приложением, видит детали (сумму, название магазина, комментарий «Чек №18234»), подтверждает — продавец видит «Оплачено».

Комиссии и лимиты. Сумма одной оплаты — от 1 сатанга до 1 миллиона тайских батов. Каждый инвойс имеет ограниченное время жизни — по умолчанию задаётся конфигом и не может быть больше системного потолка (иначе попытку выставления отклоняют). В историю транзакции попадает только публично-безопасная часть данных инвойса: текстовая заметка мерчанта, идентификатор POS-терминала, отметка о времени выпуска QR, тип сценария оплаты. Персональные данные плательщика в историю инвойса не записываются.

NFC_CHARGE — оплата прикладыванием карты OneWallet к терминалу

Бизнес-смысл. Бесконтактная оплата: клиент прикладывает физическую карту OneWallet или браслет к POS-терминалу мерчанта, и со счёта клиента списывается сумма в пользу продавца. Инициатором выступает мерчант (модель «pull» — терминал сам запрашивает оплату), а не клиент.

Кто инициирует. Мерчант через свой терминал и подключение «мерчантского» канала Auth Center. Это единственный канал, которому такой тип операций вообще разрешён.

Кто получает. Мерчант — точка обслуживания, в которой клиент приложил карту: магазин, кафе, рынок, агентский пункт.

Типичный сценарий. Клиент покупает кофе за 80 THB — прикладывает браслет OneWallet к терминалу баристы; на экране появляется «Оплачено», а в приложении клиента приходит уведомление о списании.

Комиссии и лимиты. Для NFC-оплат действуют отдельные защитные лимиты, чтобы потерянная карта не «слила» весь баланс: одна оплата — не более 300 THB, в сумме за сутки — не более 1 500 THB. Превышение любого из этих порогов приведёт к отказу. Идентификатор приложенной NFC-метки фиксируется только на стороне списания (у плательщика) и не передаётся в историю мерчанта — это часть защиты персональных данных клиента. Координаты точки оплаты и категория торговой точки сохраняются на обеих сторонах транзакции для аналитики и разбора спорных случаев.

Сквозные бизнес-правила

Несколько принципов применяются ко всем одиннадцати операциям и важны для понимания общей картины:

  • Один тип — один смысл. За каждым кодом операции стоит ровно один бизнес-сценарий, и наоборот: для одного сценария используется только один код. Это позволяет считать бизнес-метрики (объём P2P-переводов, доля QR-оплат, частота возвратов в мини-аппах) без перекрёстных пересечений.
  • Деньги никогда «не теряются». Любая операция строится как пара движений: списание с одного счёта — зачисление на другой, иногда с одновременным удержанием комиссии. Технические счета системы (например, транзитный буфер) всегда возвращаются в ноль после завершения операции — это базовый финансовый инвариант OneWallet.
  • Закрытый реестр. Перечень одиннадцати кодов — это контракт между всеми участниками: мобильным приложением, Auth Center, админ-панелью, мерчантскими интеграциями. Новый тип появляется только после явного обновления и кода, и этой документации. Любая попытка запустить операцию с незнакомым кодом отклоняется с понятной ошибкой ещё до резервирования средств.
  • Право начать операцию выдаётся явно. У каждого инициатора (Auth Center, мерчантский канал, админ-панель, сервисный вебхук) есть свой набор разрешённых типов. Например, NFC_CHARGE имеет право запустить только мерчантский канал, а ADMIN_TRANSFER — только админ-панель. Несоответствие приводит к отказу на этапе проверки полномочий.
  • Защита персональных данных в истории. Для операций, где есть чувствительные поля (идентификатор NFC-метки, комментарий мерчанта в инвойсе), действует «фильтр» — в общедоступную историю транзакций попадает только то, что одобрено по каждому полю отдельно. Например, NFC-идентификатор виден только владельцу карты, но не мерчанту.
  • Идемпотентность. Каждый запрос на операцию сопровождается уникальным ключом, и повторная отправка той же операции с тем же ключом не приводит к повторному списанию. Это защищает от двойных нажатий, потерянных ответов и сетевых таймаутов.

Что бывает с операцией после запуска

Все одиннадцать операций проходят похожий жизненный цикл — от подачи до конечного статуса. Для бизнес-роли важно знать вехи, а не технические шаги:

  1. Запуск. Инициатор отправляет запрос. Система проверяет, что у инициатора есть право на этот тип, что сумма и валюта корректны, а ключевые поля (например, получатель в P2P_TRANSFER или внешний идентификатор в WITHDRAWAL) присутствуют.
  2. Предварительные проверки. Для операций с внешним шлюзом (например, IPPS_WITHDRAWAL, THAI_QR_PAY) система убеждается, что клиент зарегистрирован в шлюзе и что реквизиты получателя заполнены корректно. Если что-то не так — операция отменяется до того, как с клиента списались деньги.
  3. Резервирование. Сумма (вместе с применимыми комиссиями) резервируется на счёте плательщика. До завершения операции эти деньги недоступны, но и не списаны окончательно.
  4. Исполнение. Внутренние операции (P2P, мини-апп, NFC) завершаются мгновенно. Внешние (IPPS, QR-оплата, вывод) ожидают подтверждения от внешнего шлюза — это может занять от секунд до минут.
  5. Подтверждение или откат. При успехе — деньги окончательно списаны и зачислены, операция получает финальный статус «успешно». При сбое — резерв отменяется, и клиент видит «операция отклонена», а сумма становится снова доступной.

Для клиента и для мерчанта весь процесс выглядит так: «отправил → ждёт → готово / отказ». Бизнес-логика остаётся простой и предсказуемой.

Как читать эту страницу аналитику и продакту

Карточки выше можно использовать как «фильтр» для бизнес-метрик и продуктовых решений. Например:

  • Считая объём P2P-активности, нужно смотреть на P2P_TRANSFER — и осознавать, что переводы внутри мини-приложений (MINIAPP_CHARGE) сюда не попадают, хоть и выглядят похоже.
  • Считая «исходящие» деньги из OneWallet (то есть деньги, физически уходящие во внешние банки), складывают IPPS_WITHDRAWAL, THAI_QR_PAY и WITHDRAWAL. Остальные семь операций — это движения внутри системы или входящие потоки.
  • Анализируя торговый оборот мерчантов, смотрят на сумму INVOICE_PAYMENT, NFC_CHARGE и MINIAPP_CHARGE — это три разных канала приёма платежей в торговых точках.
  • Принимая решение о новой комиссии, важно понимать, на какой именно тип она будет влиять. Например, скидка на P2P_TRANSFER не уменьшает выручку от MINIAPP_CHARGE — это разные источники дохода.

Каждый тип имеет собственный «голос» в аналитической витрине, поэтому при построении нового отчёта или дашборда первым шагом обычно идёт уточнение: «какие из одиннадцати операций должны быть включены?».

Частые вопросы

Чем IPPS_WITHDRAWAL отличается от THAI_QR_PAY, если деньги идут через один и тот же шлюз? С точки зрения движения денег — почти ничем. Различие только во входной точке: один тип — это явное действие «вывести в банк», другой — сканирование QR-кода. Разделение нужно для аналитики (доля QR-оплат, сравнение средних чеков), для пользовательского опыта (для QR не показываются формы выбора банка) и для маркетинговых акций («месяц без комиссии за QR» можно реализовать только при отдельном коде).

Почему WITHDRAWAL и IPPS_WITHDRAWAL — это разные коды? Потому что WITHDRAWAL обязательно несёт с собой внешний идентификатор заявки и предназначен для интеграций, где OneWallet — не первичная система учёта. У IPPS_WITHDRAWAL такого требования нет — это собственный вывод клиента из приложения. Разделение помогает поддержке однозначно понимать, откуда «пришла» операция.

Может ли клиент инициировать NFC_CHARGE или ADMIN_TRANSFER? Нет. NFC_CHARGE начинает только мерчантский терминал (модель «pull» — продавец запрашивает оплату). ADMIN_TRANSFER — только сотрудник OneWallet через админ-панель. Мобильное приложение клиента просто не имеет разрешения на эти типы и получит отказ ещё до проверки баланса.

Что произойдёт, если клиент попытается оплатить «зависший» инвойс через несколько часов после его создания? У каждого инвойса есть ограниченное время жизни (обычно несколько минут — задаётся мерчантом, но не дольше системного потолка). По истечении этого времени инвойс считается просроченным, и попытка оплаты будет отклонена с сообщением «инвойс истёк». Клиент должен попросить мерчанта выставить новый.

Существует ли способ «вернуть» уже выполненный P2P_TRANSFER? Автоматического отката нет — это намеренное архитектурное решение, чтобы переводы между клиентами были окончательными (как наличные). Если перевод был ошибочным, у получателя достаточно денег, и он согласен — он может сделать обратный P2P_TRANSFER на ту же сумму. Если получатель не идёт на контакт, остаётся обращение в поддержку: при наличии оснований операция оформляется как ADMIN_TRANSFER с явным указанием причины.

Может ли в одной операции участвовать сразу несколько валют? Сейчас — нет, все одиннадцать операций моновалютны: отправитель и получатель должны быть в одной валюте. Мульти-валютные операции (например, обмен THB в USD внутри кошелька) пока обслуживаются отдельным маршрутом через SERVICE_DEPOSIT после конвертации на стороне партнёра-обменника. Полноценный валютный обмен внутри OneWallet — это сценарий следующих фаз развития.

Где остановиться на этой странице

Эта страница — высокоуровневый обзор одиннадцати операций. Здесь нет ни форматов запросов, ни структуры тел, ни внутренних имён полей. Это сделано намеренно: бизнес-аналитику, продактам и сотрудникам поддержки этот документ должен отвечать на вопросы «что эта операция делает», «кто её запускает», «к каким лимитам она относится» — без необходимости погружаться в код.

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

См. также