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

Дорожная карта Payment Manager

Что уже работает сегодня, что запланировано в ближайшей фазе развития и что лежит в долгом ящике. Документ помогает принимать решения — «можно ли строить новую мини-фичу прямо сейчас?» или «нужно ли подождать Phase 2B?». Все упоминания фич сверены с реальным кодом и dev-документацией: если в коде стоит заглушка, она попадает в «Phase 2B», а не в «Готово».

Состояние зафиксировано на 2026-05-29. Список Phase 2B соответствует разделу «Redis Streams» и кросс-сервисным правилам корневого CLAUDE.md.

Готово сейчас (Phase 1)

Всё, что в этой колонке, уже работает в продакшен-сборке: есть код, тесты, миграции БД, seed-данные и dev-документация. Каждая запись ниже указывает на dev-документ, в котором подробно описаны схемы данных, контракты API и операционные процедуры.

Платёжные операции

  • Внутренние P2P-переводы (P2P_TRANSFER, канал INTERNAL_P2P). Синхронный перевод между кошельками OneWallet, исполняется внутри HTTP-запроса POST /intents — без участия PSP, без outbox. Это базовый «строительный блок», на который опираются MINIAPP_* и NFC_CHARGE. См. dev/modules/channels.md и business/04-operation-types.md.
  • Вывод на банк через IPPS PromptPay (IPPS_WITHDRAWAL, THAI_QR_PAY). Двухфазная сага через канал IPPS_AUTO, in-process psp-worker и очередь pm.psp_tx_map с FOR UPDATE SKIP LOCKED. Запросы в IPPS не ретраятся — статус определяется через inquiry. См. dev/integrations/ipps.md.
  • Пополнение кошелька (QP_TOPUP, WITHDRAWAL). Поток от внешнего провайдера/партнёра к клиенту; WITHDRAWAL дополнительно поддерживает привязку к внешней заявке (operationId). См. business/04-operation-types.md.
  • Mini-app платежи (MINIAPP_CHARGE, MINIAPP_CREDIT). Клиент → мерчант мини-приложения и обратное начисление от мерчанта; служебная аутентификация через auth-center service key с белым списком operationType'ов. См. business/03-payment-scenarios.md.
  • Двухфазный invoice по QR (MERCHANT_INVOICE / INVOICE_PAYMENT). Мерчант резервирует инвойс (reserve — сохраняет expires_at + HMAC-подпись QR без обращения к TigerBeetle), плательщик подтверждает через POST /intents/:id/confirm, есть отмена (/cancel) и автоматическое истечение через invoice-expiry job. См. dev/cookbook/issue-merchant-invoice.md и dev/architecture/04-two-phase-channels.md.
  • NFC-чарж (NFC_CHARGE). Синхронный pull-charge с кошелька клиента на мерчантский счёт по касанию NFC-метки; ходит по каналу INTERNAL_P2P, аутентификация — service key auth-center-merchant, индексация по nfcTagId в tx_history.attributes. См. business/04-operation-types.md.
  • Админская корректировка (ADMIN_TRANSFER). Ручной перевод между любыми счетами из админ-панели — для сторнирования ошибок, сервисных операций и точечных корректировок. Admin panel читает TigerBeetle напрямую (read-only), но любые write-операции идут через POST /intents с HMAC. См. dev/integrations/admin-panel.md.
  • Сервисный депозит (SERVICE_DEPOSIT). Зачисление со служебного счёта системы — например, после крипто-вебхука, бонусной программы или партнёрского начисления. См. business/04-operation-types.md.

Платформенные механизмы

  • Step-up policies (PIN, BIOMETRIC, OTP, KYC_UPLIFT). Таблица pm.auth_policies + endpoint POST /policies/evaluate подбирают требуемое усиление аутентификации по приоритету, операции, окнам и сумме. См. dev/modules/policies.md и docs/AUTH-POLICIES.md.
  • Fees engine (PRE / POST timing, sandboxed JS). Правила в pm.fee_rule исполняются в изолированной JS-песочнице до (PRE) или после (POST) расчёта основной проводки; поддерживается несколько получателей с автоматическим равновесием TB-инварианта. См. dev/modules/rule-engine.md и dev/cookbook/write-fee-rule.md.
  • Limits engine (per_tx, daily, monthly). Лимиты по сумме одной транзакции, дневному и месячному окну считаются по tb_account_map.userId; направление (DEBIT/CREDIT) берётся из карты счетов, а не по префиксу имени. См. dev/modules/limits.md и dev/cookbook/write-limit-rule.md.
  • Outbox + saga workers. Однопоточный OutboxWorker (NO-GO правило: ровно один экземпляр) + role-based воркеры (psp-worker, invoice-expiry и др.) с горячим переключением ролей через env. См. dev/modules/workers.md и dev/operations/worker-roles.md.

Phase 2B (запланировано)

Фичи, для которых уже есть архитектурный замысел и зачастую заготовки в коде или схеме БД, но рабочей реализации пока нет. Перечень синхронизирован с CLAUDE.md (разделы «Redis Streams» и «Кросс-сервисные правила»).

  • Redis Streams для PSP-адаптеров. Транспорт PM ↔ внешних адаптеров переедет с in-process очереди на Redis Streams (stream.ipps.jobs, stream.ipps.results, stream.qp.jobs, stream.qp.results). См. CLAUDE.md → Redis Streams и dev/integrations/redis.md.
  • Webhooks от PSP (stream.webhook.ipps). Замена polling-инквайри на push-уведомления от PSP через Webhook Gateway, который пишет события в Redis Stream. См. CLAUDE.md → Redis Streams.
  • Multi-currency. В tb_ledger (integer) уже заложена заготовка под несколько валютных «леджеров» TigerBeetle; пока во всём контуре используется только THB. См. dev/architecture/05-tigerbeetle-accounts.md.
  • Multi-instance OutboxWorker. Сейчас инвариант — ровно один экземпляр OutboxWorker (см. NO-GO в CLAUDE.md проекта); Phase 2B принесёт безопасное горизонтальное масштабирование. См. dev/modules/workers.md.
  • Prometheus exporter. Метрики SLA / saga / outbox для пром-стека (сейчас наблюдаемость ограничена логами и health-check'ами). См. dev/operations/monitoring.md.
  • QP и Wise PSP-адаптеры. В коде есть стабы каналов и operation type'ов, но рабочих адаптеров (QR-аггрегатор QP, валютный оператор Wise) нет — они активируются вместе с Redis Streams транспортом. См. dev/modules/psp.md.

Backlog / открытые вопросы

Идеи и проекты, у которых есть design-документ, но нет конкретной даты исполнения и они не привязаны к Phase 2B.

  • Universal refund flow. Универсальный паттерн возвратов, работающий поверх любого канала (INTERNAL_P2P, IPPS, будущие PSP) — каждый возврат сам по себе становится новым pm.intent, оригинал получает терминальный статус REFUNDED, TB видит явные обратные трансферы. Design-spec: docs/superpowers/specs/2026-05-11-universal-refund-design.md.

Как читать дорожную карту

  • «Готово сейчас» ≠ «полностью бесплатно для интегратора». Часть операций требует service key с нужным allowedOperationTypes и соответствующих PSP-договорённостей. Подробности — в dev/integrations/auth-center.md и dev/cookbook/add-service-key.md.
  • «Phase 2B» не означает «скоро». Это означает «архитектурно согласовано, ждёт ресурса». До переезда на Redis Streams все интеграции с PSP — через in-process PostgreSQL-очередь pm.psp_tx_map.
  • «Backlog» — это не отказ. Это сигнал «есть design, но пока не идём в реализацию». Любые новые мини-приложения и продуктовые сценарии должны строиться на «Готово сейчас», а не на Phase 2B и не на backlog.