Лимиты и комиссии¶
Как OneWallet ограничивает обороты, в какой момент просит дополнительное подтверждение (PIN / биометрия / OTP / повторный KYC) и как начисляет комиссии. Здесь — только смысл и общая механика. Конкретные пороги, ставки и формулы не дублируются — они живут в источниках, на которые ссылается эта страница.
На какие вопросы отвечает¶
- Чем лимит отличается от запроса подтверждения — почему иногда «нельзя совсем», а иногда «можно, но подтверди»?
- Какие бывают окна лимитов (за транзакцию, за день, за месяц)?
- Когда у пользователя спросят PIN, биометрию или отправят на повторный KYC?
- Кто платит комиссию — отправитель или получатель (PRE / POST)?
- Что произойдёт, если пользователь упёрся в дневной лимит?
Три механизма, которые работают вместе¶
В OneWallet три независимых механизма, и их легко перепутать:
- Лимиты (
pm.limit_rule) — жёсткий запрет. Если оборот превышен, платёж не пройдёт; никакое подтверждение его не разблокирует. - Step-up аутентификация (
pm.auth_policies) — мягкая «дверь». Платёж разрешён, но перед списанием нужно собрать дополнительный фактор. - Комиссии (
pm.fee_rule) — сколько денег удержать сверху или из суммы.
Все три хранятся в обычных таблицах схемы pm.* и меняются без перевыпуска
приложения. Управляются через Admin Panel или миграцию.
Лимиты (pm.limit_rule)¶
Каждое правило лимита привязано к типу операции (operationType),
опционально к каналу (channel) и имеет окно подсчёта:
Окно (window) |
Что считает |
|---|---|
PER_TX |
потолок на одну операцию |
DAILY |
суммарный оборот за календарный день (UTC) |
MONTHLY |
суммарный оборот за календарный месяц |
Правило задаёт direction (DEBIT / CREDIT / BOTH) и ограничивает либо
сумму (amountLimit, в сатангах), либо количество операций (countLimit),
либо и то и другое. Теги tagsInclude / tagsExclude позволяют точечно
включать или исключать платежи из-под правила, priority задаёт порядок
проверки. Конкретные действующие пороги и SQL —
см. правила комиссий и лимитов в PM.
Step-up аутентификация (pm.auth_policies)¶
Перед списанием Auth Center спрашивает у PM (POST /policies/evaluate):
«вот сумма, получатель и пользователь — нужно ли что-то дополнительно
спросить?». PM перебирает правила по возрастанию priority, берёт первое
подошедшее по scope + condition и возвращает один из пяти уровней:
Уровень (requiredStepUp) |
Что делает приложение |
|---|---|
NONE |
проводит сразу, без экранов |
PIN |
просит 6-значный PIN |
BIOMETRIC |
Face ID / отпечаток (fallback на PIN) |
OTP |
одноразовый код (в текущем релизе — резерв) |
KYC_UPLIFT |
повторная верификация → выше KYC-tier → шире лимиты |
scope — глобальное правило, правило приложения или правило мерчанта; все
три смешиваются в один список и сортируются по приоритету, поэтому точечное
правило мерчанта легко перекрывает глобальное. Конкретные пороги (при каких
суммах какой уровень) и reason-коды (large_amount, new_payee,
daily_limit) —
см. политики подтверждения.
Важно: политики не отменяют лимиты. Если лимит говорит «нельзя» — ни PIN, ни биометрия его не разблокируют.
Комиссии (pm.fee_rule)¶
Правило комиссии привязано к типу операции и имеет два режима удержания
(timing):
PRE— комиссия списывается с отправителя сверх суммы платежа (перевёл 500 → со счёта ушло 500 + комиссия, получатель получил 500).POST— комиссия удерживается из суммы получателя (клиент заплатил 250 → мерчант получил 250 − комиссия). Это «эквайринг»: магазин платит за приём оплаты.
В одном платеже могут сработать оба режима и несколько правил сразу — они
складываются (например, базовая ставка + промо-надбавка). Тег fee_exempt
полностью освобождает платёж от комиссий. Конкретные ставки, формулы
выражений и теги —
см. правила комиссий и лимитов в PM.
Пример: лимит исчерпан → шаг подтверждения¶
Пользователь сегодня уже перевёл крупную сумму и инициирует ещё один перевод.
sequenceDiagram
participant App as Приложение
participant AC as Auth Center
participant PM as Payment Manager
App->>AC: инициировать перевод
AC->>PM: POST /policies/evaluate (сумма, получатель)
PM-->>AC: requiredStepUp=KYC_UPLIFT (reason=daily_limit)
AC-->>App: нужна расширенная верификация
App->>App: загрузка документов + селфи (повторный KYC)
Note over PM: после uplift KYC-tier выше → лимит шире
Дневной кумулятив выше порога политики → PM возвращает KYC_UPLIFT с
reason-кодом daily_limit. Приложение показывает экран расширенной
верификации. После успешного KYC пользователь поднимается на более высокий
tier, и дневной лимит расширяется. Если же сработал именно жёсткий
pm.limit_rule (например, месячный потолок), операция будет отклонена,
и никакое подтверждение её не пропустит.
Смежные документы¶
- Сценарии оплаты — где в потоке возникают подтверждения.
- Актёры и счета — кто платит, кому идёт комиссия.
- Платежи и леджер (dev) — как комиссии ложатся в TigerBeetle.
- Безопасность и auth (dev) — фактор-сбор на стороне Auth Center.