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

Статус и роадмап OneWallet

Что в платформе уже работает, а что ещё в плане. Документ помогает не путать «реализовано» и «спроектировано, но не сделано».

На какие вопросы отвечает

  • Что уже можно использовать прямо сейчас?
  • Готов ли вывод на банк (IPPS), приём по NFC, оплата по инвойсу?
  • Когда появятся внешние PSP-адаптеры, top-up и оплата по тайскому QR из приложения?
  • Поддерживает ли система другие валюты, кроме THB?
  • Что значит «Phase 2B» и почему этого ещё нет?

Кратко: реализовано vs план

Возможность Статус Где смотреть
Payment Manager core (POST /intents, state machine, TigerBeetle ledger) Готово 04-scenarios.md, ../dev/04-payments-and-ledger.md
P2P-переводы (INTERNAL, синхронно) Готово operationType=P2P_TRANSFER
Вывод на банк через IPPS Готово operationType=IPPS_WITHDRAWAL
Merchant invoice (резерв → confirm/cancel, QR-подпись, expiry-job) Готово operationType=INVOICE_PAYMENT
NFC-платежи Готово operationType=NFC_CHARGE
Mini-app каталог + charge/credit Готово operationType=MINIAPP_CHARGE/MINIAPP_CREDIT
PII-шифрование (AES-256-GCM, hash с pepper, маскирование) Готово ../dev/05-security-and-auth.md, ../adr/0005-pii-encryption.md
Step-up auth (инфраструктура) Готово (инфра) pm.auth_policies + POST /policies/evaluate
PSP-адаптеры через Redis Streams План (Phase 2B) stream.ipps.*, stream.qp.* — не реализованы
Webhook Gateway План (Phase 2B) —
QP top-up адаптер План (Phase 2B) operationType=QP_TOPUP (тип есть, адаптер — нет)
Client-initiated THAI_QR_PAY План (Phase 2B) operationType=THAI_QR_PAY (тип есть, флоу — нет)
Мультивалюта План (Phase 2C) сейчас только THB
Reconciliation service План (Phase 2C) сейчас только startup-reconciler внутри PM

Важно: наличие operationType в коде (например QP_TOPUP, THAI_QR_PAY) не означает, что полный сценарий работает. Сами внешние PSP-каналы заработают только в Phase 2B.

Фазы

graph LR
  P1["Phase 1 — ГОТОВО<br/>PM core, P2P, IPPS-вывод,<br/>merchant invoice, NFC,<br/>mini-app каталог,<br/>PII-шифрование, step-up инфра"]
  P2B["Phase 2B — ПЛАН<br/>PSP-адаптеры (Redis Streams),<br/>webhook gateway, QP top-up,<br/>client THAI_QR_PAY"]
  P2C["Phase 2C — ПЛАН<br/>мультивалюта,<br/>reconciliation service"]
  P1 --> P2B --> P2C

Phase 1 — реализовано

Полностью рабочий контур e-money кошелька (THB):

  • Payment Manager — единый endpoint POST /intents с HMAC, машина состояний из 9 статусов, двухфазные переводы в TigerBeetle (transit.balance=0 — главный инвариант).
  • P2P — канал INTERNAL_P2P исполняется синхронно (CREATED→SETTLED в одном запросе).
  • IPPS-вывод — через in-process psp-worker внутри PM (WORKER_ROLES, FOR UPDATE SKIP LOCKED, таблица pm.psp_tx_map). Внешний канал возвращает intent на AUTHORIZED с requiresMonitoring=true, финал — асинхронно через intent.{id} (Redis pub/sub).
  • Merchant invoice — резерв (INVOICE_PAYMENT) → confirm/cancel, подпись qrSignature, авто-истечение job invoice-expiry.
  • NFC — приём на POS продавца (NFC_CHARGE).
  • Mini-app каталог — запуск мини-аппов (LAUNCH_JWT RS256 + window.OneWallet SDK), списания/начисления.
  • PII-шифрование — user_profile.encryptedPii, ключи в passwords.yaml.
  • Step-up auth (инфра) — POST /policies/evaluate возвращает требуемый уровень (NONE/PIN/OTP/BIOMETRIC/KYC_UPLIFT).

Активный Redis в Phase 1: stream.notifications.jobs (→ Notifications) и pub/sub intent.{id} (PM→Auth Center→Flutter).

Phase 2B — план (внешние PSP)

Вынос обработки PSP из процесса PM в отдельные адаптеры, общение только через Redis Streams:

  • PSP-адаптеры IPPS/QP — потоки stream.ipps.jobs/stream.ipps.results, stream.qp.jobs/stream.qp.results.
  • Webhook Gateway — приём колбэков от PSP → поток в PM.
  • QP top-up адаптер — пополнение кошелька (QP_TOPUP).
  • Client-initiated THAI_QR_PAY — оплата по тайскому QR из приложения.

Сейчас этих потоков и адаптеров в коде нет — реализован только in-process путь (Phase 1).

Phase 2C — план

  • Мультивалюта — сейчас платформа работает только с THB.
  • Reconciliation service — отдельная сверка с PSP/банком. Сегодня в PM есть лишь стартовый startup-reconciler (закрывает «зависшие» intent при перезапуске), это не полноценная сверка.

Пример: как проверить, что доступно сегодня

P2P-перевод между кошельками работает end-to-end:

POST /intents   (HMAC: X-Service-Id, X-Timestamp, X-Signature)
{ "operationType": "P2P_TRANSFER",
  "amount": 10000, "currency": "THB", ... }
→ status: SETTLED   (синхронно, в одном ответе)

channel не передаётся в запросе — роутер сам выбирает канал по паре (operationType, amount). Для P2P это INTERNAL_P2P; итоговый канал резолвится сервером и возвращается в ответе/событии intent.

А QP_TOPUP/THAI_QR_PAY пока упрутся в отсутствие внешнего PSP-адаптера — это Phase 2B.

Открытый backlog (выверено по коду 2026-06-06)

Конкретные незакрытые задачи интеграции — перенесены из обсолетного TODO-INTEGRATION.md (заархивирован) и перепроверены по коду. Статусы: OPEN — не сделано, PARTIAL — частично/нужна доработка.

Задача Статус Что осталось доделать
Live-статус intent в Auth Center OPEN Продюсер PM (intent.{id} pub/sub) есть, но streamStatus()-потребитель в Auth Center отсутствует — Flutter использует polling (pollIntent/getIntent). Решить: реализовать streamStatus() + e2e или официально закрыть как «вытеснено polling».
FCM routing по appId OPEN notifications-service (src/handler.js fetchTokens) не выбирает appId и шлёт на все токены пользователя. Нужно фильтровать/маршрутизировать по целевому приложению. (device_token.appId уже заполняется — это сделано.)
Multi-FCM (несколько проектов) OPEN src/fcm.js поднимает один FCM-инстанс. Для разных приложений нужны отдельные FCM-проекты и выбор инстанса по appId.
CI для notifications-service OPEN В .github/workflows/ только pm-ci.yml. Нужен lint+test pipeline для notifications-service.
Staging-окружение OPEN В projects/deploy/envs/ только dev. Нужны staging env/overlay (root docker-compose уже есть).
Миграция userId integer→uuid в pm.* OPEN pm.* (tb_account_map, intent, tx_history) всё ещё integer. Крупная задача, согласование с Auth Center. (спека 2026-05-11-pm-uuid-userid).
Лимиты по accountType (merchant/agent) PARTIAL Лимит-движок есть (limit_rule), но ключи — operationType/channel/tags, не accountType. Нужно привязать правила/теги к accountType.
IPPS/PromptPay transfer UI (Flutter) PARTIAL Есть quote (previewIntent) и polling; нет UI исходящего IPPS/PromptPay-перевода (QR PromptPay = «coming soon»). Нужен флоу IPPS_WITHDRAWAL/THAI_QR_PAY с requiresMonitoring.
Force-resolve в Admin Panel PARTIAL PM-эндпоинт POST /admin/intents/:id/resolve есть; список MANUAL_REVIEW есть (read-only); нет UI-действия force-resolve.

Примечание: старые пункты трекера «TOPUP/SETTLEMENT operationType» функционально покрыты иначе (QP_TOPUP + ledger-settlement MERCHANT_SETTLEMENT/AGENT_SETTLEMENT), отдельных типов с такими именами нет — доделывать по сути нечего.

Смежные документы