Обзор системы OneWallet

OneWallet — это электронный кошелёк для Таиланда, а Платёжный шлюз PM — сердце всех денежных операций внутри него.

Что такое OneWallet

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

• Переводы между пользователями — мгновенная отправка денег другому владельцу кошелька внутри OneWallet, без выхода во внешние банковские сети. Деньги перемещаются практически мгновенно, потому что оба счёта находятся внутри одной системы.
• Оплата по QR-коду — клиент сканирует QR продавца (или продавец сканирует QR клиента) и подтверждает сумму к списанию. Этот сценарий покрывает как небольшие покупки в кофейне, так и крупные оплаты в магазинах.
• Оплата NFC-меткой — короткое прикосновение телефоном к терминалу или к специальной метке на витрине, чтобы оплатить покупку. Удобен для повторяющихся ежедневных покупок и общественного транспорта.
• Пополнение со счёта в банке — клиент переводит деньги со своего банковского счёта в кошелёк через привычное банковское приложение или интернет-банк. После того как банк подтверждает зачисление, баланс в OneWallet растёт автоматически.
• Вывод денег на банковский счёт — обратная операция: клиент забирает средства из кошелька на свой банковский счёт. Это позволяет в любой момент превратить «электронные» деньги обратно в обычные банковские.

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

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

Жизненный цикл денег в кошельке

Чтобы понять роль Платёжного шлюза, полезно проследить путь, который проходит одна типичная сумма от появления в кошельке до того, как она его покидает:

1. Появление. Пользователь пополняет кошелёк со своего банковского счёта. После того как банк подтверждает зачисление, баланс в OneWallet увеличивается, а в общей бухгалтерской книге появляется запись «такой-то клиент внёс такую-то сумму».
2. Хранение. Деньги хранятся на персональном счёте клиента внутри OneWallet. Этот счёт — не сама купюра в сейфе, а строчка в общей бухгалтерской книге системы, защищённая правилом «итог сходится всегда».
3. Использование. Клиент тратит деньги: переводит другу, оплачивает кофе по QR, прикладывает телефон в магазине, покупает услугу у партнёра внутри мини-приложения. Каждое такое действие — новая запись в книге: с одного счёта списали, на другой зачислили, отдельно удержали комиссию.
4. Выход. Клиент в любой момент может вывести оставшиеся деньги обратно на банк. В общей книге появляется запись о списании, а реальные деньги уходят пользователю на банковский счёт.

На каждом из этих этапов решение принимает именно Платёжный шлюз: можно ли провести операцию, какая комиссия, нужно ли спросить дополнительное подтверждение, и в каком порядке делать записи в книге.

Какое место занимает Платёжный шлюз PM

Платёжный шлюз PM (Payment Manager) — это «бухгалтерия и кассир» всей системы. Он невидим для конечного пользователя, но именно через него проходит каждая копейка. У него четыре главных обязанности:

1. Ведение общей бухгалтерской книги. PM — единственная служба, которой разрешено записывать движения денег во внутреннюю учётную книгу OneWallet. Никакой другой компонент не может изменить баланс счёта в обход PM. Это даёт строгую гарантию того, что итоговые цифры всегда сходятся.
2. Расчёт комиссий. Для каждой операции PM определяет, какая комиссия применяется (зависит от типа операции, суммы, статуса клиента и продавца), и удерживает её одновременно с основным переводом.
3. Контроль лимитов. PM сверяет каждую попытку операции с действующими лимитами: дневной лимит на переводы, лимит на одну транзакцию, ограничения по статусу верификации клиента. Если операция выходит за рамки — она отклоняется до того, как затронет реальные деньги.
4. Запрос дополнительного подтверждения. Когда сумма крупная, операция выглядит подозрительной или клиент впервые отправляет деньги новому получателю, PM требует дополнительного шага — ввод ПИН-кода, подтверждение биометрией или одноразовый код. Само окно подтверждения показывает пользовательское приложение, но решение о том, нужен этот шаг или нет, принимает именно PM.

Таким образом, PM — единая точка истины обо всех деньгах в OneWallet. Если в системе нужно знать «сколько у пользователя на счёте» или «прошёл ли платёж» — спрашивать надо у PM.

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

Кто инициирует операции

Сам PM никогда не начинает платежи по собственной инициативе — он всегда исполняет запросы от других участников. На практике источников запросов три:

• Пользовательское приложение — клиент нажимает в OneWallet кнопку «Перевести», «Оплатить QR», «Пополнить» или «Вывести». Приложение сначала обращается к Auth Center (служба учётных записей, отвечающая за вход, профиль и проверку личности), а тот уже передаёт сформированный платёжный запрос в PM. Такая схема нужна, чтобы PM никогда не работал с «сырыми» учётными данными клиента и не хранил его персональные сведения.
• Админ-панель — внутренний инструмент сотрудников OneWallet. Через неё операторы могут провести возврат средств, скорректировать ошибочную транзакцию, выпустить служебный счёт партнёру и т. д. Все такие действия записываются в общую бухгалтерскую книгу через тот же PM.
• Мини-приложения внутри OneWallet — встроенные партнёрские сервисы. Когда пользователь оплачивает внутри них покупку, мини-приложение тоже формирует платёжный запрос и отдаёт его в PM на исполнение.

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

Упрощённая диаграмма системы

flowchart TD
    Client["Клиент<br/>(мобильное приложение)"]
    Merchant["Магазин / партнёр<br/>(мини-приложение)"]
    Admin["Сотрудник OneWallet<br/>(админ-панель)"]
    Auth["Auth Center<br/>учётные записи, вход, KYC"]
    PM["Платёжный шлюз PM<br/>комиссии, лимиты, бухгалтерия"]
    Ledger[("Общая бухгалтерская книга<br/>OneWallet")]
    Bank["Внешние банки<br/>(пополнение и вывод)"]

    Client -->|вход и платёжный запрос| Auth
    Auth -->|передаёт запрос| PM
    Merchant -->|запрос на оплату| PM
    Admin -->|служебные операции| PM
    PM -->|записывает движение денег| Ledger
    PM <-->|пополнение / вывод| Bank
    PM -.->|уведомляет о статусе| Auth
    Auth -.->|показывает результат| Client

Что важно понять из диаграммы:

• Клиент никогда не обращается к платёжному шлюзу напрямую — между ним всегда стоит Auth Center, который сначала убеждается, что это действительно тот самый клиент.
• Все три источника запросов (клиент, магазин, сотрудник) сходятся в одной точке — PM.
• В общую бухгалтерскую книгу пишет только PM.
• Связь с внешними банками — для пополнения и вывода — тоже идёт через PM, а не напрямую из приложения.
• Уведомление пользователя о результате операции возвращается обратно тем же путём: PM сообщает статус Auth Center, а тот доводит его до приложения. Поэтому пользователь видит надпись «Платёж прошёл» или «Платёж отклонён» только после того, как PM окончательно зафиксировал результат в общей бухгалтерской книге.

Что это даёт бизнесу

Описанная схема не случайна — у неё есть конкретные бизнес-преимущества:

• Один центр расчётов — одна правда. Когда финансовая команда сводит отчёт за день, она берёт цифры из одного источника, а не сравнивает данные из разных служб. Расхождений «по техническим причинам» не возникает.
• Единые правила на всех каналах. Если завтра меняется тариф или вводится новое ограничение по сумме, достаточно описать это правило один раз в PM — и оно автоматически начнёт действовать и для переводов, и для оплаты QR, и для покупок в мини-приложениях.
• Защита от ошибок интеграции. Партнёры и мини-приложения не имеют доступа к деньгам пользователей напрямую. Даже если у партнёра случится сбой или утечка, чужие средства снять или перевести он не сможет — это физически невозможно в обход PM.
• Прозрачная цепочка ответственности. Любая операция в системе имеет единый сквозной идентификатор, по которому её можно отследить от момента нажатия кнопки в приложении клиента до записи в общей бухгалтерской книге и уведомления, отправленного пользователю.

Краткое резюме

Если описать всё одним абзацем для коллеги, который слышит про OneWallet впервые: это тайский электронный кошелёк, в котором пользователь хранит деньги, переводит их знакомым, платит по QR и NFC, пополняется и выводит средства обратно в банк, а ещё покупает услуги у партнёров через мини-приложения. Всеми деньгами внутри OneWallet распоряжается единый Платёжный шлюз PM — он ведёт общую бухгалтерскую книгу, считает комиссии, проверяет лимиты и при необходимости требует у пользователя дополнительное подтверждение. Любая платёжная функция в OneWallet — от перевода другу до оплаты заказа у партнёра — проходит через этот единый шлюз и подчиняется одним и тем же правилам.

Где это в коде

Если нужны технические детали — какие именно модули реализуют описанные роли, как выглядит формат запроса и какие гарантии даёт общая бухгалтерская книга — см.:

• Архитектурный обзор PM (для разработчиков)
• Карта модулей PM