Правила комиссий и лимитов¶

Как Payment Manager превращает бизнес-договорённости («P2P — 1,5%», «NFC — не более 300 бат за касание») в конкретные суммы и пороги, которые видит клиент в чеке. На этой странице — только смысл правил: что взимается, когда, с кого, сколько. Технические форматы выражений, имена колонок и SQL-конструкции живут в dev-разделе.

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

Часть 1. Комиссии¶

Как читается одна строка тарифа¶

Тариф отвечает на четыре вопроса:

К какой операции применяется. Например, «только к переводам между клиентами» или «только к покупкам в мини-аппах». Тип операции — обязательное условие; без совпадения по типу правило просто не рассматривается.
Сколько взять. Здесь возможны три формы:
Процент от суммы — самый частый случай (например, 1,5% от перевода). Сумма комиссии вычисляется в момент платежа от номинала операции и округляется вниз до сатанга (1 бат = 100 сатангов), чтобы общий бухгалтерский баланс всегда сходился до копейки.
Фиксированная сумма — постоянное значение в сатангах, не зависящее от суммы платежа (например, «5 бат за каждый вывод в банк», независимо от суммы вывода).
Комбинация — процент плюс фиксированный минимум или максимум (например, «1% от суммы, но не менее 10 бат и не более 500 бат»). Любая такая логика выражается одной строкой тарифа.
Кому достанется комиссия. Это всегда конкретный внутренний счёт-получатель — обычно это revenue-счёт системы (выручка OneWallet, например для P2P-комиссий), реже — settlement-счёт мерчанта или агента (если у конкретного партнёра предусмотрен revenue-share по комиссии). Один и тот же платёж может содержать сразу несколько получателей комиссии: например, 1% уходит OneWallet и 0,5% — мерчанту-партнёру. Каждый кусок учитывается отдельной записью в истории операций.
Когда применяется. Это самый принципиальный для бизнеса параметр; ему посвящён отдельный раздел ниже.

Когда комиссия удерживается: «до перевода» и «после перевода»¶

В системе есть ровно два режима удержания, для краткости они называются PRE и POST:

PRE — «до перевода» (с отправителя). Комиссия списывается с отправителя дополнительно к сумме платежа. Если клиент переводит другу 500 бат, а комиссия 1,5%, то со счёта отправителя уйдёт 507,5 бат, а получатель получит ровно 500. Эта схема используется во всех клиентских P2P-переводах: пользователь видит на экране подтверждения «Сумма перевода — 500 бат, комиссия — 7,5 бат, итого со счёта — 507,5 бат», и это поведение интуитивно совпадает с тем, как у тайских банков работают переводы с фиксированной надбавкой.
POST — «после перевода» (с получателя). Комиссия удерживается из суммы, которую получит получатель. Если клиент покупает в мини-аппе билет за 250 бат, а тариф POST-комиссии 2%, то со счёта клиента уйдёт ровно 250 бат, а на счёт мерчанта поступит 245 бат — 5 бат отделятся в пользу OneWallet. Эта схема знакома любому, кто работал с эквайрингом: «магазин платит за приём оплаты». Применяется к мерчантским сценариям — покупки в мини-аппах, оплата по QR — где удобно показать клиенту чистую цену товара, а с продавца взять плату за услугу приёма платежа.

В одном платеже могут сработать оба режима одновременно: например, на P2P-перевод может быть наложена PRE-комиссия для отправителя и POST-комиссия в пользу программы лояльности; каждая обсчитывается независимо и попадает в историю отдельной строкой.

Композиция: когда работают сразу несколько правил¶

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

базовая ставка P2P 1,5% + промо-надбавка 0,5% на период акции = в сумме 2%;
комиссия системы 1% + revenue-share мерчанта 0,5% = две отдельные строки в чеке.

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

Освобождение от комиссии через теги¶

У каждого платежа есть набор тегов — это короткие строковые пометки, проставляемые в момент создания платежа (например, vip, promo, fee_exempt, internal_settlement). На тегах строится точечное управление поведением:

fee_exempt — полное освобождение от комиссий. Универсальный «выключатель»: ни одно тарифное правило к платежу с этим тегом не применяется. Используется для служебных переводов, внутренних корректировок, благотворительных акций.
vip — отдельная категория клиента. Базовое правило игнорирует таких клиентов, а для них работает отдельное правило с другой ставкой (например, 0,5% вместо 1,5%).

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

Часть 2. Лимиты¶

Что значит «лимит» в Payment Manager¶

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

Как читается одна строка лимита¶

Каждое правило лимита отвечает на пять вопросов:

К какой операции применяется — например, только к NFC-оплатам, только к выводам в банк, или ко всем операциям сразу (специальная пометка «*» означает «к любой»).
По какому каналу доставки — необязательный дополнительный фильтр. Например, «только внутренние NFC через мерчантский канал», «только выводы через IPPS-шлюз». Если канал не указан — правило ловит все каналы для своего типа операции.
Направление: списание или зачисление. У каждого лимита есть «сторона», к которой он применяется:
списания со счёта пользователя (по-английски DEBIT) — это лимит на исходящие деньги (например, «не выводить больше 50 000 бат в день»);
зачисления на счёт пользователя (по-английски CREDIT) — это лимит на входящие деньги (например, «не принимать переводов больше 100 000 бат в месяц без KYC уровня 2»);
любое движение (по-английски BOTH) — лимит ловит и списания, и зачисления.
Окно времени — в каком интервале считается «уже потрачено»:
per-tx (на одну транзакцию) — потолок на разовую операцию: «не больше 300 бат за одно NFC-касание». Самый простой случай: ничего складывать не надо, проверяется только сумма текущего платежа.
daily (в сутки) — потолок на сумму или количество за календарные сутки по UTC. К моменту нового платежа суммируется всё, что клиент уже успешно потратил по этому правилу с начала суток.
monthly (в месяц) — то же самое, но окно — календарный месяц по UTC. Используется для «крупных» лимитов: месячный потолок KYC-уровня, лимит на пополнения через партнёрский шлюз.
Что именно ограничивается — лимит может задавать сумму (например, «не более 30 000 бат в сутки»), количество операций (например, «не более 5 NFC-касаний в сутки»), или одновременно и то и другое (тогда не должны быть превышены оба порога).

Кто «съедает» лимит: отправитель или получатель¶

Лимит привязан к конкретному пользователю. Когда платёж проходит через PM, система смотрит, чей именно пользовательский идентификатор стоит на счёте-источнике или счёте-получателе:

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

Принципиальная тонкость: направление считается по фактическому владельцу счёта, а не по «имени» счёта (например, «у любого user.* счёта это списание» — неверно, потому что мерчантские и агентские счета тоже привязаны к пользователю-владельцу). Правильное правило: «если владелец счёта-источника — это тот пользователь, от имени которого пришёл запрос, то для него это списание». Эта тонкость особенно важна для NFC-оплат, где платёж инициирует мерчант, но «лимитоносителем» должен быть клиент, у которого деньги списываются.

Что считается «уже потрачено» в окне¶

Когда правило проверяет daily- или monthly-окно, оно считает фактические завершённые операции пользователя — те, что окончательно зачислились получателю. Платежи, которые отменились (отказ внешнего шлюза, недостаточно средств, отказ клиента подтвердить) в счёт лимита не идут — это справедливо для пользователя: неудачная попытка не «съедает» сегодняшнюю квоту.

Это значит, что после неудачного платежа клиент может попробовать ещё раз — лимит на этот момент свободен ровно настолько же, насколько он был свободен до попытки.

Часть 3. Примеры (для аналитиков и поддержки)¶

В таблице — типичные правила, которые сегодня работают в системе или планируются к подключению. Все суммы — в тайских батах.

Комиссии¶

Операция	Условие применения	Сколько	Кому достаётся	Когда удерживается
Перевод между клиентами	без особых тегов	1,5% от суммы	OneWallet (revenue-счёт)	до перевода (с отправителя)
Перевод между клиентами	у клиента тег «VIP»	0,5% от суммы	OneWallet (revenue-счёт)	до перевода (с отправителя)
Перевод между клиентами	у клиента тег «освобождён»	0	—	— (правило не сработает)
Покупка в мини-аппе	без особых тегов	2% от суммы	OneWallet (revenue-счёт)	после перевода (с мерчанта)
Покупка в мини-аппе (план на будущее)	мерчант с revenue-share	1% + 0,5%	OneWallet 1% и мерчантский settlement 0,5%	после перевода

Лимиты¶

Операция	Канал	Сторона	Окно	Порог
NFC-оплата	внутренний канал мерчанта	списание с клиента	per-tx (на одно касание)	300 бат
NFC-оплата	внутренний канал мерчанта	списание с клиента	daily (в сутки)	1 500 бат
Вывод в банк (план)	IPPS-шлюз	списание	per-tx	200 000 бат
Любая операция (план)	—	списание	monthly (в месяц)	зависит от уровня KYC клиента

Эти таблицы — не исчерпывающая регуляторная справка, а иллюстрация того, как разные правила одного типа складываются в единую защиту: одна NFC-оплата ограничена одновременно «не более 300 за касание» и «не более 1 500 в сумме за сегодня», и достаточно одного «нет» — операция отклоняется.

Часть 4. Что бывает, когда лимит сработал¶

Если предполагаемая сумма платежа превышает порог, Payment Manager откажет в операции до резервирования денег в кошельке — это означает:

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

Это намеренное архитектурное решение: лимиты считаются «защитной сеткой», и срабатывание не должно вызывать у клиента ощущения, что у него что-то «съели». Если клиент хочет провести операцию выше лимита, единственный путь — либо подождать окно (часто это «следующий день»), либо обновить KYC-уровень, после чего к нему привяжется другой набор правил.

Часть 5. Когда правило меняется¶

Правила и комиссий, и лимитов хранятся как обычные строки в справочнике системы. Это значит:

Изменение тарифа — это правка/добавление строки, без выпуска новой версии Payment Manager. Деплой не требуется; новое правило начинает действовать на следующих платежах.
Деактивация правила — это пометка «неактивно». Историческая статистика по уже совершённым платежам не пересчитывается, но в новых операциях правило просто не появится.
Тестовый просмотр. Прежде чем включать новый тариф боевым клиентам, бизнес-команда может «прогнать» правило в режиме предпросмотра: задать тестовый платёж и увидеть, какая комиссия и куда начислится. Это позволяет ловить ошибки в формулах до того, как они доедут до реальной операции.

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

Где это в коде¶

Эта страница описывает бизнес-смысл; технические подробности (форматы выражений, имена колонок, SQL-фильтры, sandbox-механика для тарифных формул) — в dev-разделе:

../dev/reference/database/05-fee-rule.md — справочник тарифов: какие поля, как заполняются, какие ограничения, какие seed-правила сейчас в системе.
../dev/reference/database/12-limit-rule.md — справочник лимитов: как кодируются направление, окно и тип ограничения; ключевой инвариант про принадлежность счёта пользователю; примеры запросов «сколько уже потрачено».
../dev/modules/rule-engine.md — как Payment Manager выбирает применимые правила, считает комиссии и проверяет лимиты; жизненный цикл «до перевода» и «после перевода»; эндпоинт предпросмотра тарифа.

См. также¶

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