# Чек-лист готовности инфраструктуры — перед запуском > Дата: 2026-04-24 Формат: чекбоксы + приоритеты P0/P1/P2 **P0** — блокер запуска (без этого нельзя запускать продукт) **P1** — критично, но можно запустить пилот/закрытую бету без этого **P2** — улучшение, можно после публичного запуска **Легенда статусов**: `[ ]` не начато · `[~]` в работе · `[x]` готово · `[?]` требует уточнения *** ### 1. Telegram-инфраструктура #### 1.1. Основной бот (вход в мини-апп) * [ ] **P0** Создан через `@BotFather`, получен токен * [ ] **P0** Зарегистрирован домен мини-аппа, добавлен как Web App URL в BotFather (`/setmenubutton`) * [ ] **P0** Настроен webhook на бэкенд (`setWebhook`), HTTPS обязателен * [ ] **P0** Команда `/start` с обработкой deep-link параметров (для ref-ссылок: `/start ref_XXX`) * [ ] **P0** Команда `/app` (или кнопка меню) — открытие мини-аппа * [ ] **P0** Команда `/help` — вывод FAQ / контактов поддержки * [ ] **P1** Команда `/language` — смена языка интерфейса * [ ] **P1** Команда `/support` — переадресация в бот поддержки * [ ] **P1** Inline-кнопки для ключевых действий (открыть карту, пополнить, поддержка) * [ ] **P1** Rate limiting на уровне бота (защита от флуда и ботов) * [ ] **P1** Логирование всех команд и взаимодействий в PostgreSQL * [ ] **P2** Мультиязычность (RU / EN минимум) * [ ] **P2** A/B тестирование приветственных сообщений #### 1.2. Сам Telegram Mini App * [ ] **P0** `initData` валидация на бэкенде (HMAC-SHA256 от `bot_token`) — **без этого любой может подделать user\_id** * [ ] **P0** Фронтенд размещён на HTTPS, домен добавлен в BotFather * [ ] **P0** Telegram WebApp SDK подключён (`telegram-web-app.js`) * [ ] **P0** Адаптация под тему Telegram (light/dark), учёт `themeParams` * [ ] **P0** Кнопка `BackButton` и `MainButton` используются корректно * [ ] **P0** Обработка `viewportStableHeight` (клавиатура на мобиле) * [ ] **P1** Haptic Feedback на ключевых действиях * [ ] **P1** Popup через `showPopup` (нативные диалоги) * [ ] **P1** CloudStorage для быстрых данных (не финансовых) * [ ] **P2** Telegram BiometricManager (подтверждение через биометрию Telegram) #### 1.3. Бот поддержки * [ ] **P0** Отдельный бот через BotFather, отдельный токен * [ ] **P0** Интеграция с CRM (Chatwoot / в файле 40 выбран Chatwoot) * [ ] **P0** Автоматическое определение пользователя по `user_id` (тянуть профиль из основной БД) * [ ] **P0** AI-агент первого уровня (RAG по FAQ, pgvector) * [ ] **P0** Эскалация к оператору по ключевым словам/по кнопке * [ ] **P1** Классификация обращений (карта, платёж, KYC, другое) * [ ] **P1** Привязка тикета к транзакции / карте в системе * [ ] **P1** Шаблоны ответов оператора * [ ] **P1** SLA таймеры и авто-эскалация * [ ] **P2** Оценка диалога (CSAT) после закрытия тикета * [ ] **P2** Аналитика по темам обращений #### 1.4. Система уведомлений (через основной бот) * [ ] **P0** Очередь уведомлений (Redis / Kafka) с приоритетами * [ ] **P0** Уведомления по транзакциям (оплата, отказ, возврат) * [ ] **P0** Уведомления по статусу KYC (approved/rejected/needs-more-docs) * [ ] **P0** Уведомления по безопасности (смена email, подозрительный вход, заморозка карты) * [ ] **P1** Уведомления по пополнению баланса * [ ] **P1** Уведомления по истечению срока карты * [ ] **P1** Маркетинговые уведомления с opt-in/opt-out * [ ] **P1** Обработка ошибок доставки (user blocked bot, user deactivated) * [ ] **P2** Настройка типов уведомлений пользователем в мини-аппе #### 1.5. Админский / служебный бот (опционально) * [ ] **P1** Алерты мониторинга в служебный чат * [ ] **P1** Команды для операторов (разблокировать карту, ручная проверка, поиск юзера) * [ ] **P1** Уведомления о подозрительных транзакциях (антифрод) * [ ] **P2** Статистика (DAU, транзакции, выручка) по запросу *** ### 2. Платежи: СБП и крипто-ввод (пункты готовности) #### 2.1. СБП / fiat-on-ramp - будет готовый СБП провайдер, который процессит платежи и отдает нам крипто для пополнения карт сервиса * [ ] **P0** Определён провайдер (ЮKassa / CloudPayments / Tinkoff API / банк-партнёр) * [ ] **P0** Заключён договор с провайдером * [ ] **P0** Получены реквизиты: merchant\_id, API-ключ, webhook-секрет * [ ] **P0** Реализован приём webhook о зачислении * [ ] **P0** Идемпотентность на уровне платежа (повторный webhook не дублирует зачисление) * [ ] **P0** Генерация QR / deeplink оплаты в мини-аппе * [ ] **P0** Определение курса RUB→USDT (источник курса + спред) * [ ] **P0** Лимиты операций (мин/макс, дневные/месячные) * [ ] **P1** Fallback-провайдер на случай простоя основного * [ ] **P1** Возвраты (refund) при ошибках * [ ] **P1** Анти-AML правила (структурирование, подозрительные паттерны) #### 2.2. Крипто-ввод (USDT TRC20/ERC20/BEP20) - будет готовый крипто провайдер, который процессит платежи и отдает нам крипто для пополнения карт сервиса * [ ] **P0** Определён провайдер нод (TronGrid, Infura, QuickNode) или self-hosted * [ ] **P0** Генерация уникальных депозитных адресов на юзера (HD wallet) * [ ] **P0** Мониторинг входящих транзакций (подтверждения, финализация) * [ ] **P0** Свип средств на hot/warm-кошелёк * [ ] **P0** Зачисление на баланс после N подтверждений * [ ] **P1** Поддержка нескольких сетей (TRC20, ERC20, BEP20, Polygon) * [ ] **P1** Memo/tag для централизованных адресов (если применяется) * [ ] **P2** Поддержка USDC, DAI #### 2.3. Fiat-off-ramp (вывод) - пока не предусмотрен * [ ] **P1** Провайдер для вывода на карту / СБП * [ ] **P1** KYC-уровень для вывода (обычно выше, чем для ввода) * [ ] **P1** Лимиты и комиссии * [ ] **P2** SWIFT/SEPA-вывод для крупных сумм #### 2.4. Курсообразование * [ ] **P0** Источник курса (Rapira) * [ ] **P0** Спред (маржа сервиса) - фиксированно закладывается через интерфейс * [ ] **P0** Кэширование курса в Redis (TTL \~1-5 минут) * [ ] **P1** Блокировка операций при экстремальной волатильности (>3% за минуту) * [ ] **P1** Исторический лог курсов (для отчётов клиенту) *** ### 3. Лендинг и маркетинговые сайты #### 3.1. Основной лендинг * [ ] **P0** Домен зарегистрирован, SSL-сертификат * [ ] **P0** Код фронтенда (Next.js 14, согласно файлу 38) задеплоен * [ ] **P0** Хостинг (Vercel / собственный VPS + nginx) * [ ] **P0** Форма сбора email / wait-list — подключена к БД * [ ] **P0** CTA-кнопка "Открыть в Telegram" с deep-link на основной бот * [ ] **P0** Meta-теги (OG image, Twitter card, описание, title) * [ ] **P0** Favicon и иконки PWA * [ ] **P0** robots.txt и sitemap.xml * [ ] **P1** Google Analytics / Яндекс.Метрика / Plausible * [ ] **P1** Facebook Pixel / TikTok Pixel (если планируется platnnyj marketing) * [ ] **P1** Блог / раздел с материалами (SEO) * [ ] **P1** Мультиязычность (RU + EN минимум) * [ ] **P2** A/B тесты лендинга * [ ] **P2** Dark/light mode #### 3.2. Поддомены / служебные сайты * [ ] **P0** `app.brand.com` — домен мини-аппа * [ ] **P0** `api.brand.com` — бэкенд API * [ ] **P1** `admin.brand.com` — админ-панель (закрытая) * [ ] **P1** `partners.brand.com` — партнёрский кабинет (см. §4) * [ ] **P1** `status.brand.com` — статус-страница * [ ] **P1** `docs.brand.com` или `help.brand.com` — база знаний / FAQ * [ ] **P2** `blog.brand.com` — блог *** ### 4. Партнёрская программа #### 4.1. Механика ссылок * [ ] **P0** Генерация уникального ref-кода на каждого партнёра (формат: `XXXX-1234`, не угадываемый) * [ ] **P0** Deep-link для Telegram: `t.me/brand_bot?start=ref_XXXX1234` * [ ] **P0** Web-ссылка для лендинга: `brand.com/?ref=XXXX1234` (cookie на 30 дней) * [ ] **P0** Атрибуция: последний клик или первый клик (зафиксировать политику) * [ ] **P0** Передача ref-кода из cookie/Telegram start-parameter в момент регистрации в БД * [ ] **P0** UTM-параметры для трекинга каналов (`utm_source`, `utm_medium`) * [ ] **P1** QR-коды ref-ссылок (для офлайн-распространения) * [ ] **P1** Короткие ссылки (собственный shortener или bit.ly/t.ly) #### 4.2. Партнёрский кабинет * [ ] **P0** Отдельный интерфейс (веб, не мини-апп) — `partners.brand.com` * [ ] **P0** Регистрация партнёра (отдельно от обычного юзера) * [ ] **P0** Dashboard: клики, регистрации, активации, комиссии * [ ] **P0** Таблица рефералов (анонимизированно: кто, когда, статус) * [ ] **P0** Выплаты (история + запрос на вывод) * [ ] **P0** Раздел маркетинг-материалов (баннеры, тексты) * [ ] **P1** API для партнёров (для postback/s2s трекинга) * [ ] **P1** Многоуровневая структура (если планируется MLM-логика — CAREFUL: в РФ часто серая зона) * [ ] **P2** Live-статистика (websocket) #### 4.3. Расчёт комиссий * [ ] **P0** Определена модель: CPA (фикс за активацию), RevShare (% от выручки), Hybrid * [ ] **P0** Триггер выплаты: первое пополнение / первая транзакция / месячный оборот * [ ] **P0** Минимальная сумма к выводу (например, $50) * [ ] **P0** Способ выплаты (USDT на wallet в ручном режиме?) * [ ] **P0** Частота выплат (еженедельно / ежемесячно) * [ ] **P0** Учёт chargeback'ов и возвратов — вычитать из комиссии * [ ] **P1** Hold period (1-2 недели на возврат) перед выплатой * [ ] **P1** Tiered-ставки (больше рефералов → выше %) #### 4.4. Антифрод в партнёрке * [ ] **P0** Проверка: один и тот же IP / device для партнёра и реферала → блок * [ ] **P0** Проверка: одинаковый phone/email pattern → ручная ревью * [ ] **P0** Проверка: циклические ссылки (A пригласил B, B пригласил A) * [ ] **P0** Проверка: реферал не делает реальных транзакций (создан только под выплату) * [ ] **P1** ML-скоринг фрода * [ ] **P1** Блэклист партнёров (если пойманы на фроде) * [ ] **P1** Ручная верификация партнёров с большим трафиком #### 4.5. Юридические документы партнёрки * [ ] **P0** Партнёрская оферта (отдельный договор, см. §6) * [ ] **P0** Налоговая форма для нерезидентов (W-8BEN / самостоятельная декларация) * [ ] **P1** Self-billing инвойсы (генерация от имени партнёра) *** ### 5. Базы данных: клиенты, ledger, KYC, рефералы #### 5.1. База клиентов (PostgreSQL) * [ ] **P0** Схема `users` (id, telegram\_id, email, phone, created\_at, status) * [ ] **P0** Схема `user_profiles` (имя, фамилия, страна, язык, тип KYC) * [ ] **P0** Схема `user_devices` (audit входов, fingerprint) * [ ] **P0** Схема `sessions` (JWT/refresh-токены) * [ ] **P0** Индексы на `telegram_id`, `email`, `phone` * [ ] **P0** Шифрование PII-полей (PGP или поле-уровневое) * [ ] **P1** Партиционирование по месяцам (если > 1M users) * [ ] **P1** Soft delete + data retention policy #### 5.2. Финансовый ledger (двойная запись) * [ ] **P0** Схема `ledger_accounts` (user\_id, account\_type, currency, balance\_cached) * [ ] **P0** Схема `ledger_entries` (account\_id, amount, direction, ref\_tx\_id) — **APPEND-ONLY, без UPDATE** * [ ] **P0** Схема `transactions` (внешний id, provider, status, amount, currency, fee) * [ ] **P0** Двойная запись: каждая транзакция = минимум 2 записи (debit + credit) * [ ] **P0** Идемпотентность: `external_id + provider` UNIQUE * [ ] **P0** Ежедневный reconciliation-job с upstream * [ ] **P0** Партиционирование `ledger_entries` по месяцам * [ ] **P1** Snapshot balances (ежедневный, для быстрого чтения) * [ ] **P1** Separate read-replica для аналитики #### 5.3. KYC-база * [ ] **P0** Схема `kyc_applications` (user\_id, level, status, provider, external\_id) * [ ] **P0** Схема `kyc_documents` (application\_id, doc\_type, s3\_path, sha256) * [ ] **P0** Шифрование S3-бакета (SSE-S3 или KMS) * [ ] **P0** Логирование доступа к документам (кто, когда, откуда) * [ ] **P0** Data retention: хранить 5-7 лет после закрытия счёта (зависит от юрисдикции) * [ ] **P1** Автоматическое удаление после истечения retention #### 5.4. Реферальная база * [ ] **P0** Схема `referral_codes` (code, owner\_user\_id, created\_at, active) * [ ] **P0** Схема `referrals` (ref\_code, referred\_user\_id, attribution\_source, created\_at) * [ ] **P0** Схема `referral_rewards` (referral\_id, amount, status, paid\_at) * [ ] **P0** Связь с `ledger_entries` (выплата = запись в ledger) * [ ] **P1** Схема `partner_payouts` (batch-выплаты партнёрам) #### 5.5. Audit log и безопасность данных * [ ] **P0** Схема `audit_log` (actor, action, entity, before, after, ip, ua, timestamp) * [ ] **P0** Логирование всех изменений PII и финансовых данных * [ ] **P0** Offsite-бэкапы (минимум 2 гео-региона) * [ ] **P0** PITR (Point-in-Time Recovery) 7-30 дней * [ ] **P0** Тестирование восстановления из бэкапа (раз в квартал) * [ ] **P1** Database activity monitoring * [ ] **P1** DB firewall / ограничение IP на подключение *** ### 6. Юридические документы #### 6.1. Обязательные (P0) * [ ] **P0** **Terms of Service (Условия использования)** — общие правила * [ ] **P0** **Публичная оферта** — юридически значимый договор, принимается кнопкой * [ ] **P0** **Privacy Policy (Политика конфиденциальности)** — ст. 13-14 GDPR эквивалент * [ ] **P0** **Cookie Policy** — для лендинга, отдельно от Privacy * [ ] **P0** **AML Policy (Anti-Money Laundering)** — внутренняя и публичная версии * [ ] **P0** **KYC Policy** — уровни верификации, требования к документам * [ ] **P0** **Sanctions Policy** — санкционные списки (OFAC, EU, UN), запрещённые юрисдикции * [ ] **P0** **Risk Disclaimer** — крипто-риски, волатильность, отсутствие госгарантии * [ ] **P0** **Tariff Schedule (Прайс-лист)** — отдельный документ, чтобы менять без переподписи ToS * [ ] **P0** **Refund / Chargeback Policy** — порядок возвратов и споров #### 6.2. Важные (P1) * [ ] **P1** **PEP Policy** — работа с публично значимыми лицами * [ ] **P1** **Data Retention Policy** — сколько и что храним * [ ] **P1** **Complaints Policy** — порядок рассмотрения жалоб * [ ] **P1** **Partnership Agreement** — договор с партнёрами (§4.5) * [ ] **P1** **Data Processing Agreement (DPA)** — с каждым субобработчиком (Fireblocks, апстрим, CRM, email) * [ ] **P1** **Acceptable Use Policy** — что нельзя делать в сервисе #### 6.3. Желательные (P2) * [ ] **P2** **Whistleblower Policy** — анонимные сообщения о нарушениях * [ ] **P2** **Business Continuity Plan (BCP)** — план действий при катастрофе * [ ] **P2** **Outsourcing Policy** — внутренний документ о работе с подрядчиками * [ ] **P2** **Incident Response Plan** — план реагирования на инциденты #### 6.4. Техническая реализация документов * [ ] **P0** Все документы доступны по прямым ссылкам: `brand.com/legal/` * [ ] **P0** Версионирование: каждый документ имеет версию и дату * [ ] **P0** Принятие в мини-аппе: чекбокс + запись в БД (какую версию, когда, IP) * [ ] **P0** Обновление: при изменении документа — требовать переакцепта при следующем логине * [ ] **P1** Multi-language (минимум RU + EN) * [ ] **P1** PDF-версии для скачивания * [ ] **P1** Diff-версионирование (показывать что изменилось) *** ### 7. Админ-панель и инструменты операторов #### 7.1. Админка (веб, закрытая) * [ ] **P0** Авторизация: 2FA обязательно (TOTP / FIDO2) * [ ] **P0** RBAC: роли (admin, compliance, support, finance, readonly) * [ ] **P0** Поиск юзера (по email, phone, telegram\_id, card\_id, tx\_id) * [ ] **P0** Карточка юзера: профиль, баланс, транзакции, KYC-документы, карты * [ ] **P0** Действия: заморозить/разморозить карту, блокировка юзера, ручной refund * [ ] **P0** Очередь KYC на ручную ревью * [ ] **P0** Очередь тикетов поддержки (если Chatwoot — отдельно) * [ ] **P0** Audit log всех действий операторов * [ ] **P1** Batch-операции (разблокировать N карт, отправить рассылку) * [ ] **P1** Feature flags (включать функции для отдельных юзеров) #### 7.2. BI / аналитика * [ ] **P1** Dashboard: DAU/MAU, регистрации, активации, транзакции, выручка, LTV, CAC * [ ] **P1** Воронка регистрации → KYC → активация → первая транзакция * [ ] **P1** Когортный анализ retention * [ ] **P1** Инструмент: Metabase (open-source) / Superset / Looker Studio * [ ] **P2** Прогнозирование (ML-модели churn, LTV) #### 7.3. Инструменты комплаенс-офицера * [ ] **P0** Алерты по подозрительным транзакциям (SAR — Suspicious Activity Report) * [ ] **P0** Скринер по sanctions lists (OFAC, EU, UN) — ежедневная проверка * [ ] **P0** PEP скринер * [ ] **P1** Travel rule (если применимо — для transfers > €1000) * [ ] **P1** Transaction monitoring rules (структурирование, скорость, география) *** ### 8. Общая инфраструктура #### 8.1. Домены и DNS * [ ] **P0** Основной домен зарегистрирован, privacy protection включён * [ ] **P0** DNS у провайдера с DDoS-защитой (Cloudflare рекомендуется) * [ ] **P0** SPF, DKIM, DMARC для email (иначе письма уходят в спам) * [ ] **P0** CAA-записи (разрешённые CA для SSL) * [ ] **P1** DNSSEC включён * [ ] **P1** Backup domain registrar (второй регистратор на случай проблем) #### 8.2. SSL / HTTPS * [ ] **P0** Wildcard SSL для `*.brand.com` (LetsEncrypt или коммерческий) * [ ] **P0** Автоматическое обновление сертификатов * [ ] **P0** HSTS включён с preload * [ ] **P1** Certificate transparency monitoring #### 8.3. CDN и хранилище статики * [ ] **P0** CDN для публичной статики (Cloudflare / bunny.net) * [ ] **P0** S3-совместимое хранилище (MinIO self-hosted или внешний) * [ ] **P0** Разделение бакетов: public (картинки) vs private (KYC-документы) * [ ] **P0** Политики доступа (IAM / policy) * [ ] **P1** Image optimization (WebP, AVIF) #### 8.4. Email-инфраструктура * [ ] **P0** Провайдер (SendGrid / Mailgun / Postmark / Amazon SES) * [ ] **P0** Выделенный отправляющий домен (`mail.brand.com` или `notify.brand.com`) * [ ] **P0** SPF/DKIM/DMARC настроены и проверены (mail-tester.com ≥ 9/10) * [ ] **P0** Dedicated IP (если объём > 50k писем/месяц) * [ ] **P0** Обработка bounce/complaint (автоотписка) * [ ] **P0** Шаблоны транзакционных писем (welcome, KYC, password reset) * [ ] **P1** Отдельный sub-domain для маркетинга (чтобы не влиять на транзакционные) #### 8.5. SMS-провайдер * [ ] **P1** Провайдер для RU (SMS.ru / SMSC / Exolve) * [ ] **P1** Провайдер для EU (Twilio / MessageBird / Vonage) * [ ] **P1** Провайдер для KG/KZ (отдельно, обычно через местных операторов) * [ ] **P1** Fallback между провайдерами * [ ] **P2** Flash-SMS для OTP #### 8.6. Хостинг серверов * [ ] **P0** Production VPS / cluster (минимум 2 инстанса для HA) * [ ] **P0** Staging-окружение (для тестов перед деплоем) * [ ] **P0** Reverse proxy (nginx / Caddy / Traefik) * [ ] **P0** Firewall (iptables / ufw + облачный firewall) * [ ] **P0** SSH только по ключам, без паролей, fail2ban * [ ] **P0** Отдельный management-сервер (bastion host) для доступа к prod * [ ] **P1** Kubernetes / Docker Swarm (если масштаб оправдан) * [ ] **P1** Load balancer *** ### 9. DevOps: CI/CD, мониторинг, логи, backups #### 9.1. CI/CD * [ ] **P0** Git-репозиторий (GitHub / GitLab / self-hosted Gitea) * [ ] **P0** CI-пайплайн: lint, typecheck, unit-тесты, security scan * [ ] **P0** CD-пайплайн: staging → production (с approval) * [ ] **P0** Миграции БД версионированы (Alembic / Prisma Migrate) * [ ] **P0** Rollback-стратегия (blue/green или canary) * [ ] **P1** Автотесты e2e (Playwright / Cypress) на staging * [ ] **P1** Security scan (Snyk / Trivy) в пайплайне * [ ] **P1** Dependency updates (Renovate / Dependabot) #### 9.2. Мониторинг и алерты * [ ] **P0** Prometheus + Grafana (метрики) * [ ] **P0** Алерты в Telegram / PagerDuty / Opsgenie * [ ] **P0** Uptime-мониторинг (UptimeRobot / self-hosted Uptime Kuma) * [ ] **P0** SLI/SLO определены (например: API p95 < 300ms, availability > 99.9%) * [ ] **P0** Алерты: ошибки 5xx, latency, disk full, memory, DB connections * [ ] **P1** Синтетические транзакции (имитация действий юзера каждые N минут) * [ ] **P1** APM (Application Performance Monitoring) — DataDog / New Relic / SigNoz #### 9.3. Логи * [ ] **P0** Централизованное логирование (Loki + Grafana / ELK / self-hosted) * [ ] **P0** Структурированные логи (JSON) * [ ] **P0** Retention policy (90 дней для hot, 1 год archive) * [ ] **P0** PII-маскирование в логах (никаких full card number, CVV, паролей) * [ ] **P1** Correlation ID (trace-id через все сервисы) #### 9.4. Error tracking * [ ] **P0** Sentry (self-hosted или SaaS) для фронта и бэка * [ ] **P0** Source maps загружены для фронта * [ ] **P0** Алерты на критические ошибки #### 9.5. Бэкапы и DR * [ ] **P0** Автоматические бэкапы PostgreSQL (pg\_dump + PITR через WAL-G) * [ ] **P0** Бэкапы в offsite (другой регион / другой провайдер) * [ ] **P0** Шифрование бэкапов * [ ] **P0** Тест восстановления раз в квартал * [ ] **P0** Бэкап S3/MinIO (документы KYC) * [ ] **P0** Бэкап Redis (если содержит persistent-данные) * [ ] **P1** DR-план (Disaster Recovery) с RTO/RPO метриками * [ ] **P1** Hot standby PostgreSQL в другом регионе #### 9.6. Status page * [ ] **P1** Публичная status-страница (Cachet / StatusPage.io / Instatus) * [ ] **P1** Автоматическое обновление статуса из мониторинга * [ ] **P1** История инцидентов *** ### 10. Апстрим-интеграции (SquareFi / UPay) #### 10.1. API-клиент * [ ] **P0** SDK/HTTP-клиент с retry, exponential backoff * [ ] **P0** Circuit breaker (не долбить упавший апстрим) * [ ] **P0** Rate limiting с учётом лимитов апстрима * [ ] **P0** Таймауты на каждый вызов * [ ] **P0** Секреты в Vault, не в коде #### 10.2. Webhooks * [ ] **P0** Эндпоинт приёма (`/webhooks/squarefi`, `/webhooks/upay`) * [ ] **P0** Валидация подписи (HMAC / asymmetric — в зависимости от провайдера) * [ ] **P0** Идемпотентность по `event_id` * [ ] **P0** Очередь обработки (Kafka / Redis Streams / RabbitMQ) * [ ] **P0** DLQ (Dead Letter Queue) для проваленных событий * [ ] **P0** Retry для upstream-сбоев * [ ] **P0** Обработка всех событий из файла 39 §12 (card.*, transaction.*, kyc.\*) * [ ] **P1** Мониторинг отставания очереди #### 10.3. Reconciliation * [ ] **P0** Ежедневный cron-job сверки баланса с апстримом * [ ] **P0** Алерт при расхождении > определённого порога * [ ] **P0** Ручной reconciliation-инструмент в админке * [ ] **P1** Еженедельная сверка транзакций (matched / unmatched) #### 10.4. Gaps (отмечены в файле 39) * [ ] **P0** Push provisioning Apple/Google Pay — **запросить у апстрима под NDA** (gap) * [ ] **P0** Disputes/chargebacks flow — **запросить у апстрима** (gap, не документирован публично) * [ ] **P0** `balance.updated` events — реализовать через polling + перерасчёт из транзакций (gap) * [ ] **P0** SLA от апстрима (uptime, response time) — подписать * [ ] **P0** Sandbox-креды и доступ для разработки * [ ] **P1** Fallback-апстрим (второй провайдер на случай простоя) *** ### 11. Безопасность и секреты #### 11.1. Secrets management * [ ] **P0** HashiCorp Vault (self-hosted) или аналог для production * [ ] **P0** Ротация ключей (как минимум ежеквартально для API-ключей) * [ ] **P0** Separate secrets для staging/production * [ ] **P0** Никаких секретов в git (pre-commit hook + detect-secrets) * [ ] **P1** Integration с CI/CD (Vault Agent / External Secrets Operator) #### 11.2. Аутентификация и авторизация * [ ] **P0** 2FA для админки (TOTP минимум, FIDO2 рекомендуется) * [ ] **P0** 2FA опциональное для юзера (TOTP / SMS) * [ ] **P0** Session management (JWT short-lived + refresh, или session-cookies) * [ ] **P0** Rate limiting на логин / восстановление пароля * [ ] **P0** Защита от brute-force (lockout после N попыток) * [ ] **P1** Device fingerprinting * [ ] **P1** Anomaly detection (новая страна, новое устройство) #### 11.3. PCI DSS scope * [ ] **P0** **Определён scope**: скорее всего **SAQ A** (весь PAN на стороне апстрима) * [ ] **P0** Никогда не хранить / не передавать / не логировать PAN + CVV * [ ] **P0** Card widget — iframe от апстрима, а не свой * [ ] **P0** Network segmentation от card-related зон (если есть) * [ ] **P1** Независимая PCI-аудиторская проверка (если scope расширится до SAQ B/C/D) #### 11.4. Application security * [ ] **P0** OWASP Top 10 checklist пройден * [ ] **P0** Input validation на всех эндпоинтах (Pydantic / Zod) * [ ] **P0** SQL injection защита (ORM + prepared statements) * [ ] **P0** XSS защита (Content Security Policy) * [ ] **P0** CSRF-токены * [ ] **P0** Rate limiting на public API * [ ] **P1** WAF (Cloudflare WAF / ModSecurity) * [ ] **P1** Regular penetration testing (раз в год) * [ ] **P1** Bug bounty программа (после стабилизации) #### 11.5. Сетевые правила * [ ] **P0** БД недоступна из интернета, только из приложения * [ ] **P0** Redis только для приложения, с паролем * [ ] **P0** Internal services в private network * [ ] **P0** VPN для админ-доступа к prod (WireGuard / OpenVPN / Tailscale) *** ### 12. Compliance, регуляторы, юрлицо #### 12.1. Юрлицо и счета * [ ] **P0** Регистрация юрлица (KG, Кыргызстан) — подтвердить, что KYB пройден у апстрима * [ ] **P0** Расчётный счёт для операционных расходов * [ ] **P0** Регистрация товарного знака (минимум в KG, желательно ЕАЭС + EUIPO) * [ ] **P1** Резервный юрюрисдикция (если меняется регулятор) #### 12.2. Регуляторы * [ ] **P0** Определиться: нужна ли лицензия НБКР (платёжный агент / VASP) * [ ] **P0** Если да — подать документы заранее (6-12 месяцев) * [ ] **P0** Если нет — работать через партнёра с лицензией (упоминать в ToS) * [ ] **P1** Регистрация FIU (финразведка) — при обороте > порога * [ ] **P1** AML-офицер назначен (обязателен по законам большинства юрисдикций) #### 12.3. AML / KYC operational * [ ] **P0** Провайдер KYC (Sumsub / Veriff / Shufti Pro / встроенный в апстрим) * [ ] **P0** Уровни KYC (tier 1 / 2 / 3) с разными лимитами * [ ] **P0** Процедура enhanced due diligence (EDD) для high-risk юзеров * [ ] **P0** Screening по sanctions/PEP lists (ComplyAdvantage / Refinitiv / встроенный) * [ ] **P0** SAR-отчётность (как, куда, кто отвечает) * [ ] **P0** Training AML-офицера и операторов (раз в год) #### 12.4. Защита данных * [ ] **P0** Data Protection Officer (DPO) — обязательно для GDPR-scope * [ ] **P0** Регистрация как data controller (если работаете с ЕС) * [ ] **P0** Right to be forgotten — процедура удаления * [ ] **P0** Data export — пользователь может скачать свои данные * [ ] **P1** Privacy impact assessment (PIA) задокументирована #### 12.5. Страхование * [ ] **P1** Cyber liability insurance * [ ] **P2** D\&O (Directors & Officers) insurance * [ ] **P2** Professional indemnity *** ### 13. Итоговый must-have перед публичным запуском **Минимальный набор P0, без которого нельзя запускаться:** * [ ] Бот + мини-апп с `initData` валидацией * [ ] Один рабочий fiat-on-ramp (СБП через одного провайдера) * [ ] Один рабочий crypto-on-ramp (USDT TRC20 минимум) * [ ] KYC-интеграция с tier 1 (email + phone + ID документ) * [ ] Финансовый ledger с двойной записью * [ ] Webhook-приёмник от апстрима с идемпотентностью * [ ] Reconciliation-job ежедневно * [ ] Все 10 обязательных документов (§6.1) опубликованы и принимаются * [ ] AML/PEP/sanctions screening * [ ] 2FA для админки, RBAC * [ ] Audit log финансовых операций * [ ] Бэкапы с тестом восстановления * [ ] Мониторинг + алерты на критические сбои * [ ] Бот поддержки с очередью тикетов * [ ] Status page публичная * [ ] Юрлицо + счёт + KYB у апстрима пройден * [ ] Договор с апстримом, DPA, SLA подписаны * [ ] AML-офицер назначен *** ### 14. Что НЕ входит в этот чек-лист (намеренно) * Конкретные сроки и person-days оценки (было запрошено без сроков) * Выбор конкретных вендоров по каждой позиции (это решения за вами / ADR) * Маркетинг-стратегия и go-to-market (не инфраструктура) * Найм команды (отдельный трек) * Разработка фичей сверх MVP *** > Источники: собственные файлы 30/37/38/39/40/41, публичная документация SquareFi (docs.squarefi.co/docs), UPay (upay-api-en.readme.io), OWASP Top 10, PCI DSS 4.0 SAQ, GDPR Art. 13-14. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://alt3-capital.gitbook.io/funding-arbitrage-strategy/cart/proektnaya-dokumentaciya/chek-list-gotovnosti-infrastruktury-pered-zapuskom.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.