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

Глоссарий Payment Manager

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

Как пользоваться этим глоссарием

  • Если встретили незнакомый термин в обсуждении или письме — найдите его здесь и прочитайте 2–4 предложения, чтобы понять смысл.
  • Если нужно копнуть глубже (контракты, поведение, граничные случаи, ошибки) — переходите по ссылке в технический раздел; там даются точные правила.
  • Если термина нет в списке — это либо синоним уже описанного понятия, либо часть конкретного интеграционного сценария: ищите в сценариях оплаты или потоке мерчант-инвойса.
  • Глоссарий обновляется одновременно с появлением новых каналов, типов операций и интеграций — если что-то расходится с реальностью, это повод завести задачу на актуализацию документа.

Условные обозначения

  • Термин даётся в форме «английское название (русский перевод)» — это сделано специально, потому что в чатах и коммитах команды чаще используют английские названия, а в текстах писем и презентациях — русские. Оба варианта должны быть узнаваемы.
  • Где есть ссылка «См. …», она ведёт строго в раздел dev/, в котором лежит исчерпывающее техническое описание понятия с точностью до полей и значений.
  • Где есть ссылка «См. …» с относительным путём ./…, она ведёт в соседний бизнес-документ той же серии.

Алфавитный словарь

Channel (канал)

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

В разговорах обычно звучит как «по какому каналу пойдёт этот платёж» или «канал INTERNAL_P2P», и означает именно техническую ветку исполнения, а не способ ввода данных клиентом.

См. реестр каналов.

Fee rule (правило комиссии)

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

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

См. модуль rule-engine.

Intent (платёжное намерение)

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

В отчётах, логах и обсуждениях каждый платёж идентифицируется по intent_id — это единый сквозной идентификатор, который связывает запись клиента, события саги, проводки в главной книге и внешние подтверждения от PSP.

См. архитектуру intent-саги.

IPPS

Внешний платёжный шлюз PromptPay (Таиланд), через который Payment Manager выполняет вывод средств на банковские счета и QR-оплаты в локальной платёжной инфраструктуре. IPPS — это внешний сервис, и любая интеграция с ним по своей природе асинхронна: PM отправляет запрос, ждёт подтверждения по своим каналам (вебхук или периодическая инквайри) и только потом завершает intent. Для клиента это выглядит как «вывод в банк», «оплата по QR» или «пополнение по PromptPay», но за каждой такой операцией стоит длинная техническая цепочка.

IPPS — основной (на текущем этапе единственный) внешний PSP в системе; именно с ним связаны самые сложные сценарии «зависших» платежей, повторных попыток и сверок.

См. интеграцию с IPPS.

Ledger (главная книга)

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

Технически главная книга реализована на специализированной финансовой базе данных (TigerBeetle), которая гарантирует атомарность операций и невозможность «потерять деньги» из-за сбоя одного сервиса.

См. устройство счетов в главной книге.

Limit rule (правило лимита)

Ограничение на сумму или количество операций конкретного типа за единицу времени: разовый лимит на одну операцию, дневной, месячный, годовой. Лимиты могут зависеть от уровня KYC клиента, типа клиента (физлицо / мерчант / агент), канала операции, страны проживания и других факторов. Их задача — управлять рисками (мошенничество, отмывание денег), соблюдать регуляторные требования и защищать клиента от случайных крупных переводов.

Если правило лимита сработало, intent отклоняется ещё до начала исполнения и клиент получает понятное сообщение о том, какой именно лимит превышен и когда он сбросится; деньги при этом не двигаются.

См. модуль лимитов.

Merchant invoice (мерчант-инвойс)

Двухфазный платёж, в котором магазин или поставщик услуг сначала выставляет счёт (создаёт инвойс с суммой, описанием и сроком жизни), а клиент потом подтверждает оплату — обычно через сканирование QR-кода. Между двумя фазами проходит время — клиент может отсканировать QR, посмотреть детали покупки, передумать или отвлечься. Инвойс может истечь по таймауту, если клиент не подтвердит вовремя; тогда мерчант увидит, что счёт «протух», и при необходимости выставит новый.

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

См. поток мерчант-инвойса.

NFC charge (NFC-оплата)

Сценарий оплаты касанием смартфона по NFC-метке мерчанта. Метка хранит идентификатор торговой точки и параметры платежа; клиент касается её телефоном, видит сумму на экране, подтверждает биометрией или PIN-кодом — и платёж проходит как внутренняя операция в кошельке без участия внешних шлюзов. Это один из основных способов офлайн-оплаты в системе, особенно удобный для небольших торговых точек, у которых нет терминала, но есть стикер на кассе.

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

См. сценарии оплаты.

Operation type (тип операции)

Бизнес-категория того, что именно клиент или сервис хочет сделать: P2P-перевод между клиентами, оплата мерчанту, NFC-оплата, вывод на банковский счёт, пополнение, сервисное движение, административная корректировка и т. д. Тип операции — это «язык бизнеса»: он не привязан к конкретному каналу или провайдеру, а описывает намерение клиента в терминах, понятных продакту, аналитику и поддержке. Каждый тип операции имеет свой набор разрешённых каналов и свой набор правил (комиссии, лимиты, требования к подтверждению, политики).

В отчётах и аналитике метрики обычно строятся именно по типам операций («сколько P2P за день», «какая комиссия с мерчант-инвойсов»), потому что эта группировка устойчива к смене внутренних каналов и провайдеров.

См. реестр типов операций.

Outbox (исходящий ящик)

Внутренняя очередь Payment Manager, через которую гарантированно обрабатываются все отложенные действия — отправка событий другим сервисам, дальнейшие шаги саги, уведомления, обращения к внешним PSP. Принцип простой: пока действие не подтверждено как выполненное, оно остаётся в очереди и будет повторено при следующей попытке. Это даёт гарантию, что ни одно событие в системе не потеряется из-за сбоя сети или временной недоступности соседнего сервиса.

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

См. модуль воркеров.

PSP (Payment Service Provider)

Обобщённое название внешнего платёжного провайдера — банка, платёжного шлюза, эквайера, локального оператора платежей. С точки зрения Payment Manager все внешние партнёры, через которых идут деньги наружу или приходят снаружи, — это PSP. Для каждого PSP в системе есть свой адаптер, который умеет общаться с ним по его правилам (своя криптография, свои таймауты, свой формат запросов), но единая бизнес-логика остаётся в PM.

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

См. модуль PSP.

Saga (сага)

Последовательность шагов, в которые разбивается один платёж. Например, перевод от клиента А клиенту Б — это резервирование суммы у А, проверки лимитов и политик, списание комиссии, зачисление получателю, фиксация в истории, отправка уведомлений обеим сторонам. Если какой-то из шагов не удался, сага откатывает уже сделанные шаги (возвращает зарезервированные деньги, отменяет проводки) и помечает intent как неуспешный с понятной причиной отказа.

Сага — это «как»; intent — это «что». Один и тот же intent в разных каналах исполняется разными сагами, но клиент видит только итог: либо платёж прошёл, либо нет, и почему.

См. архитектуру intent-саги.

Service key (ключ сервиса)

Учётная запись сервиса-клиента, который обращается к Payment Manager: Auth Center, админ-панель, мини-апп бэкенды, KYC-сервис, нотификации и т. д. У каждого ключа свой набор разрешений: какие типы операций он может создавать, с какими каналами, в каком диапазоне сумм, с какими ограничениями по получателям. Ни один сервис не может выполнить операцию, на которую у его ключа нет права, — даже если он по ошибке отправит такой запрос, PM ответит отказом.

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

См. реестр ключей сервисов.

Step-up policy (политика дополнительного подтверждения)

Требование подтвердить операцию дополнительно — например, ввести PIN, приложить биометрию, ввести одноразовый код из SMS или пройти расширенный KYC. Политика срабатывает на основании суммы операции, её типа, истории клиента, признаков риска и других условий, которые задаются на стороне бизнеса и могут меняться без релиза. Цель — снизить риск мошенничества и защитить деньги клиента, не превращая каждый платёж в долгую процедуру: дешёвые и привычные операции проходят без лишних подтверждений, а большие и нетипичные требуют доп. шага.

Для клиента это выглядит как «иногда приложение спрашивает PIN, а иногда нет» — и за этим стоит именно политика, а не случайность.

См. модуль политик.

Transit account (транзитный счёт)

Служебный «сквозной» счёт в главной книге, через который технически проходят деньги во время операции. Например, при переводе между двумя клиентами деньги сначала уходят с отправителя на транзитный счёт, оттуда — на счёт получателя; в инвойсе и оплате на внешний PSP схема такая же, только число шагов больше. Главный финансовый инвариант системы: суммарный остаток на всех транзитных счетах всегда равен нулю в стационарном состоянии (когда нет активных платежей в процессе).

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

См. устройство счетов в главной книге.

Карта связей между терминами

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

  • Intent — корневое понятие. Каждый платёж — это один intent.
  • Operation type определяет, что за платёж: P2P, NFC, инвойс, вывод и т. д.
  • Channel определяет, как физически исполнить платёж выбранного типа.
  • Saga — это сценарий из шагов, по которому исполняется intent в выбранном канале.
  • Limit rule проверяется до начала исполнения: можно ли клиенту вообще делать такую операцию сейчас.
  • Fee rule считается на этапе оценки intent и фиксирует комиссию до подтверждения клиентом.
  • Step-up policy определяет, нужно ли клиенту дополнительно подтвердить операцию (PIN, биометрия, KYC).
  • Transit account появляется внутри саги: через него идут деньги от отправителя к получателю.
  • Ledger — место, где остаются все проводки и где видны итоговые балансы.
  • PSP и IPPS — внешние партнёры, к которым обращается канал, если платёж выходит за пределы кошелька.
  • Outbox обеспечивает, что любой запущенный intent дойдёт до финального статуса даже при сбоях.
  • Service key — учётка инициатора (Auth Center, мини-апп, админка), который имеет право создавать конкретные типы операций.
  • Merchant invoice и NFC charge — два частных, но важных бизнес-сценария поверх общей модели intent / channel / saga.

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

Что НЕ относится к глоссарию

Чтобы избежать ложных ожиданий, важно зафиксировать, чего здесь нет.

  • Здесь нет описания конкретных API-методов и форматов запросов — это в техническом разделе про API и контракты.
  • Здесь нет таблиц с полями и SQL-структурами — это в разделе про базу данных.
  • Здесь нет конкретных правил комиссий, лимитов и политик с цифрами — они задаются на стороне бизнеса и хранятся в системе как данные; список актуальных правил всегда смотрится в админ-панели и операционных регламентах.
  • Здесь нет описания внутреннего устройства TigerBeetle, Redis или PostgreSQL — это инфраструктура, которая нужна разработчикам и эксплуатации, но не нужна для понимания продукта.

Мини-FAQ

Несколько частых вопросов, которые помогают быстро отличить близкие, но не тождественные понятия.

  • «Intent — это то же самое, что транзакция?» Не совсем. Intent — это намерение и весь процесс его обработки от старта до финального статуса; в книге одной операции может соответствовать несколько проводок (резерв, комиссия, зачисление). Транзакция в обыденной речи — это обычно успешный intent, увиденный глазами клиента.
  • «Channel и operation type — это одно и то же?» Нет. Operation type — это бизнес-категория («перевод другу», «оплата мерчанту»), а channel — техническая ветка исполнения («внутренний перевод», «внешний PromptPay»). У одного типа операции может быть несколько каналов.
  • «PSP и IPPS — это одно и то же?» IPPS — конкретный PSP (PromptPay-шлюз в Таиланде). PSP — общее слово для всех внешних провайдеров; в будущем их может быть больше одного.
  • «Если intent отказал из-за лимита — деньги списались?» Нет. Limit rule проверяется до начала исполнения, поэтому деньги клиента остаются на месте; intent просто помечается отказом с причиной.
  • «Что такое транзитный счёт с нулевым остатком — это что-то опасное?» Наоборот, это здоровая норма. Если у транзитного счёта остаток отличается от нуля в стационарном состоянии — это сигнал, что нужно расследовать «зависший» платёж.
  • «Saga, intent и operation — где разница?» Operation — это пользовательский язык («перевод», «оплата»), он закрепляется в operation type. Intent — это конкретная команда от инициатора с суммой, получателем и параметрами. Saga — это исполнение этой команды в системе как последовательность шагов.
  • «Кто запускает intent — клиент или сервис?» Технически intent всегда создаёт сервис, у которого есть service key (Auth Center, админка, мини-апп бэкенд, и т. п.). Клиент инициирует это действие в приложении, но в PM приходит запрос уже от сервиса с подписью.
  • «Зачем нужен step-up, если есть лимиты?» Лимиты говорят «можно или нельзя», step-up — «можно, но только с дополнительным подтверждением». Это разные слои защиты: лимит — про предельные суммы, step-up — про проверку, что действительно сам клиент совершает операцию.
  • «Outbox — это очередь сообщений вроде Kafka?» По смыслу — да, это очередь отложенных действий. По реализации — нет, она внутренняя для PM и хранится в той же базе, что и intent; это сделано намеренно, чтобы запись действия и запись «надо его выполнить» происходили в одной транзакции и не могли разойтись.

Шпаргалка на одну страницу

Если нужен быстрый взгляд «на всё сразу» — вот сжатые формулировки всех терминов:

  • Intent — намерение платежа, корневая сущность; имеет уникальный идентификатор intent_id.
  • Operation type — что делает клиент: P2P, инвойс, NFC, вывод, пополнение.
  • Channel — как система это исполняет: внутренний перевод, PromptPay, мерчант-инвойс, админ.
  • Saga — пошаговое исполнение intent в выбранном канале, с откатом при сбое.
  • Fee rule — правило, по которому считается комиссия.
  • Limit rule — ограничение по сумме и частоте операций.
  • Step-up policy — требование дополнительного подтверждения (PIN, биометрия, OTP, KYC).
  • Ledger — главная бухгалтерская книга всех денежных движений.
  • Transit account — служебный счёт-«мост»; остаток в норме равен нулю.
  • Outbox — внутренняя очередь, гарантирующая, что каждое действие будет доведено до конца.
  • PSP — внешний платёжный провайдер (обобщённо).
  • IPPS — конкретный PSP: PromptPay-шлюз в Таиланде.
  • Merchant invoice — двухфазная оплата по счёту от мерчанта.
  • NFC charge — оплата касанием NFC-метки.
  • Service key — учётка сервиса-инициатора с правами на конкретные операции.

Связанные документы