Final Gap Review and Next Actions

Статус: черновик для обсуждения

1. Цель документа

Этот документ нужен, чтобы после большой продуктовой проработки было понятно:

• какие решения уже зафиксированы;
• какие вопросы еще нужно закрыть Product Owner-у;
• какие вопросы нужно передать development team;
• какие вопросы нужно передать security / DevOps / QA / design;
• какие outputs нужны до старта полноценной реализации MVP;
• какие вещи явно не входят в MVP.

Это не заменяет domain documents и user journeys. Это summary-документ для планирования следующего этапа работы команды.

2. Общий статус

Product scope MVP в целом определен.

Ключевые product decisions закрыты:

• MVP включает deposits only.
• Withdrawals, refunds, anti-fraud, dashboards и advanced reports не входят в MVP.
• Новая система строится вокруг payment methods, а не вокруг providers.
• Основной payment flow идет через hosted payment page.
• Routing hierarchy определена.
• MASTER MID является merchant-scoped сущностью.
• SUB MID создается под merchant.
• SUB MID AGGREGATOR создается platform users и может переиспользоваться между merchants.
• Provider real names скрываются от merchant users, если merchant не получил provider access.
• Merchant получает только unified error code и human-readable description.
• Provider raw errors и provider internals не показываются merchant users.
• Back Office общий, но разделен на Platform section и Merchant section.
• Доступ ко всем действиям controlled by permissions.
• Все изменения в Back Office пишутся в audit log.
• Transaction investigation строится через timeline.
• Migration переносит только historical transactions.
• Test provider нужен и должен поддерживать все MVP payment methods.

Главный оставшийся пласт работы - не product scope, а детализация:

• final naming;
• final UI/UX;
• MVP epics and delivery milestones;
• database schema;
• exact technical design;
• exact API/security formats;
• exact infrastructure/deployment design;
• test cases and release readiness.

3. Что осталось Product Owner-у

Product Owner должен добить не технические детали, а то, что влияет на поведение продукта, ожидания пользователей и acceptance criteria.

3.1. Проверить и утвердить продуктовый scope

Нужно еще раз пройти:

• 00-context.md
• 01-mvp-scope.md
• 02-actors-and-access-model.md

И подтвердить:

• MVP действительно только deposits;
• first merchant migration будет payment method by payment method;
• no withdrawals in MVP;
• no anti-fraud in MVP;
• no dashboards in MVP;
• no provider polling in MVP;
• no routing simulation in MVP;
• no public API for historical migration;
• no webhooks for migrated historical transactions.

Output:

• MVP scope approved;
• список вещей, которые точно уходят в post-MVP backlog.

3.2. Утвердить user journeys

Нужно пройти все documents в 03-user-journeys и убедиться, что они совпадают с ожидаемым business flow.

Особое внимание:

• merchant creates deposit;
• hosted payment form;
• routing execution;
• provider callback handling;
• merchant webhook delivery;
• transaction investigation timeline;
• configuration draft/publish/versioning;
• manual transaction correction;
• legacy transaction migration;
• MVP release and merchant transition.

Output:

• approved user journeys;
• список сценариев для UAT;
• список сценариев, которые design team должна отрисовать.

3.3. Final naming

Product decision:

Product / Project: Payment Orchestrator / HUB v3
Repository: payment-orchestrator
Core service: Orchestrator Service

Output:

• approved core service name;
• approved repo/project name;
• naming convention для documentation and tickets.

3.4. Подготовить final Back Office behavior

Back Office уже описан на уровне information architecture, но для design team нужны более конкретные screen requirements.

Product Owner должен отдельно описать или подтвердить:

• какие pages открываются first после login;
• какие columns видны по умолчанию в transaction list;
• какие columns можно включать/скрывать;
• какие filters есть на каждой table;
• какие empty states показываются;
• какие access denied states показываются;
• какие confirmations нужны для risky actions;
• где показывать audit log tab;
• как выглядят pages для entities без routing impact;
• где используется simple Save;
• где используется Draft / Publish.

Output:

• Back Office page-by-page requirements;
• wireframe-ready descriptions для design team.

3.5. Зафиксировать hosted payment page UX

Нужно финально описать customer-facing behavior:

• hosted payment page всегда открывается по payment session token;
• page показывает loader, пока transaction/routing/provider result не готов;
• если нужны additional customer fields, page показывает form;
• prefilled fields нельзя менять;
• missing fields customer заполняет сам;
• после provider redirect URL page делает top-level redirect;
• customer не видит internal statuses;
• при internal error до provider flow page делает redirect на merchant fail URL;
• если error screen всё-таки показывается, customer видит generic error message and reference id = transaction ID;
• expired session показывает generic expiration/error message без redirect;
• UI language в MVP: English only;
• brand styling и brand name не показываются в MVP, но brand context обязателен.

Output:

• final hosted payment page UX specification;
• decision: top-level redirect behavior вместо iframe by default;
• customer-facing error messages draft.

3.6. Подготовить merchant public documentation content

Требования к public documentation уже описаны в:

• 12-merchant-documentation/01-merchant-public-documentation-requirements.md

Product Owner должен подготовить или согласовать текст:

• introduction;
• authentication explanation;
• deposit creation flow;
• hosted payment page explanation;
• webhook explanation;
• statuses explanation;
• error codes explanation;
• test provider / staging flow explanation;
• migration notes for merchants.

Exact HMAC examples и cryptographic format должны предложить development/security team.

Output:

• public merchant documentation draft;
• list of required code examples;
• list of required diagrams/screenshots.

3.7. Утвердить release acceptance scenarios

Перед MVP release нужно иметь список сценариев, которые будут показаны Product Owner-у.

Минимальные acceptance scenarios:

1. Platform user создает merchant, brand, API key and payment method.
2. Platform user создает SUB MID / SUB MID AGGREGATOR / MASTER MID / routing.
3. Merchant создает deposit через Merchant API.
4. Customer открывает hosted payment page.
5. Transaction успешно доходит до final status COMPLETED.
6. Merchant получает signed webhook.
7. Failed provider path приводит к fallback.
8. Velocity limit rejection записывается в timeline.
9. Manual correction меняет final status и может trigger resend callback.
10. Duplicate provider callback сохраняется как duplicate/ignored event.
11. Suspicious callback сохраняется и создает alert.
12. Merchant user не видит provider internals без provider access.
13. Merchant user с provider access видит только allowed provider configuration.
14. Secret values нигде не раскрываются после сохранения.
15. Legacy transaction migration переносит historical transactions как read-only legacy records.
16. Load test подтверждает target load.

Output:

• MVP UAT checklist;
• demo script;
• release acceptance decision.

3.8. Подготовить MVP delivery plan

Product Owner и команда должны подтвердить:

• delivery milestones;
• domain epics внутри milestones;
• что foundation идет первым;
• что test provider делается рано;
• что observability не откладывается на конец;
• что migration tool делается ближе к концу MVP;
• что merchant documentation готовится до first merchant launch;
• что withdrawals не входят в MVP, но architecture не должна блокировать future withdrawals.

Output:

• approved MVP delivery plan;
• epics/workstreams ready for technical breakdown;
• milestone-based ticketing plan.

Важно: detailed delivery plan / ticket breakdown не является частью текущего product specification package для шаринга с командой. Его нужно подготовить отдельно на следующем этапе, после обсуждения product scope.

4. Что нужно от Design Team

Design team должна подготовить UX/UI для Back Office и hosted payment page.

4.1. Back Office layout

Нужны designs для:

• login / 2FA / password reset / invitation accept;
• empty Back Office after first admin creation;
• Platform section;
• Merchant section;
• merchant selector/filter;
• transaction list;
• transaction details;
• transaction timeline;
• webhooks tab;
• manual transaction correction;
• merchant details;
• brand details;
• payment method / MID list;
• payment method / MID details;
• MASTER MID details;
• SUB MID details;
• SUB MID AGGREGATOR details;
• API keys;
• user management;
• role management;
• audit logs tab;
• migration tool;
• test provider related flows.

4.2. Routing blueprint editor

Routing editor является critical UX area.

Design must cover:

• graph/blueprint view;
• Routing Rule and conditions creation;
• AND conditions inside Routing Rule;
• fallback route;
• MASTER MID GROUP node;
• MASTER MID node;
• SUB MID GROUP node;
• SUB MID / SUB MID AGGREGATOR node;
• hidden provider internals for merchant users;
• draft version list;
• published version marker;
• edit lock state;
• publish action;
• delete inactive version action;
• validation errors.

4.3. Hosted payment page

Design must cover:

• loading state;
• missing attributes form;
• generic error state;
• redirect preparation state;
• English-only MVP copy;
• no brand name / no brand styling MVP state;
• mobile layout.

5. Что нужно от Development Team

Development team должна превратить product documents в technical design.

5.1. Application architecture

Нужно определить:

• exact monorepo folder structure;
• service/module naming;
• boundaries between Backoffice Service, Orchestrator Service, Gateways, Exchange Service, Report Service;
• whether Exchange Service is runtime service, module or job;
• internal communication between Backoffice and Orchestrator;
• transaction creation boundary;
• hosted payment session boundary;
• callback ingestion boundary;
• webhook delivery boundary.

5.2. Database schema

Нужно подготовить database schema draft для:

• merchants;
• brands;
• merchant groups;
• users;
• roles;
• permissions;
• merchant access;
• merchant group access;
• API keys;
• provider access;
• payment methods / MID;
• MASTER MID GROUP;
• MASTER MID;
• SUB MID GROUP;
• SUB MID / SUB MID AGGREGATOR;
• routing rules and Routing Rules;
• draft/published versions;
• processing fees;
• FX/conversion snapshots;
• velocity limits;
• transactions;
• transaction timeline;
• provider callbacks;
• merchant webhook deliveries;
• raw payload references;
• audit/security logs;
• legacy migration records if needed.

Нужно отдельно определить:

• indexes for Back Office filters/search/export;
• uniqueness constraints;
• idempotency keys;
• transaction snapshots;
• immutable historical configuration references;
• retention/security rules.

5.3. Reliable async processing

Нужно определить:

• Pub/Sub topics/subscriptions;
• event schemas;
• outbox/inbox pattern;
• idempotency model;
• retry strategy;
• dead-letter strategy;
• ordering expectations;
• how timeline is written from async events;
• how gateways stay available when core lags/restarts;
• what data must be durably stored before returning OK.

5.4. Provider adapter model

Нужно определить:

• provider adapter interface;
• method-specific required/optional customer attributes;
• SUB MID configuration schema;
• secret/non-secret config field types;
• validation of provider callbacks;
• provider callback URL hiding strategy;
• amount/currency matching;
• provider transaction id matching;
• duplicate callback handling;
• suspicious callback detection;
• provider raw payload storage and masking.

5.5. Merchant API and webhook signing

Нужно предложить:

• exact HMAC format for Merchant API request signing;
• exact HMAC format for outgoing merchant webhooks;
• timestamp/replay protection rules;
• canonical payload serialization;
• signature headers;
• code examples;
• rotation behavior;
• webhook retry intervals;
• webhook max retry duration;
• webhook timeout.

5.6. Routing engine

Нужно определить:

• exact routing evaluation algorithm;
• fallback stack behavior;
• how candidate SUB MID attributes are collected before provider request;
• how velocity limits affect fallback;
• how inactive entities are skipped;
• how routing version snapshot is attached to transaction;
• how merchant visibility filtering works for routing history.

5.7. Security and secrets

Нужно определить:

• encryption strategy for all secrets;
• secrets storage approach;
• field masking strategy;
• audit behavior for secret changes;
• exact access control checks;
• session storage;
• 2FA implementation;
• failed login/rate limit/lockout rules;
• new device/IP detection;
• secure handling of raw payloads.

6. Что нужно от DevOps

DevOps team должна определить:

• infrastructure per environment: local/dev/stg/prod;
• Kubernetes/GKE deployment model;
• Cloudflare/WAF and Load Balancer configuration;
• GKE Gateway API manifests;
• Pub/Sub infrastructure;
• PostgreSQL/PgBouncer/read replica setup;
• Redis setup;
• Cloud Storage buckets;
• secret management;
• CI/CD pipeline;
• deployment approval process;
• rollback/deploy strategy;
• monitoring stack deployment;
• Prometheus metrics scraping;
• alert routing;
• log retention.

Product decision:

• no separate sandbox environment;
• test provider works inside stg and also can be available in prod;
• no Back Office environment badge in MVP;
• no mandatory PO approval gate for every production deploy.

7. Что нужно от QA

QA team должна подготовить:

• test plan;
• UAT scenarios;
• E2E scenarios;
• provider callback test scenarios;
• webhook delivery test scenarios;
• routing/fallback test scenarios;
• velocity limit test scenarios;
• fee/FX test scenarios;
• permissions/visibility test scenarios;
• secret leakage test scenarios;
• migration validation scenarios;
• load test scenario;
• resilience test scenario.

Load test обязателен.

Target:

• 5 million transactions per month;
• average около 2 transactions per second;
• peak 10 transactions per second for 5 minutes.

Любой critical required test failure должен блокировать release.

8. Что нужно от Security

Security team должна согласовать:

• API request signing;
• webhook signing;
• secret encryption;
• 2FA;
• session management;
• password reset flow;
• audit/security log requirements;
• raw payload masking;
• provider name exposure risk;
• provider callback endpoint hiding strategy;
• sensitive data retention;
• data access model.

Critical requirement:

Merchant users не должны случайно увидеть real provider names, credentials, raw provider errors или provider internals, если для этого нет explicit access.

9. Что нужно от Data / Reporting

В MVP dashboards не нужны.

Но нужно обеспечить:

• transaction list filters;
• transaction export by current filters;
• migrated transaction visibility;
• legacy marker;
• test transaction marker;
• transaction details;
• timeline;
• webhook delivery history;
• audit log visibility.

Report Service остается технической частью проекта, но product-facing dashboards/report builder не входят в MVP.

10. Migration gaps

Migration direction определен:

• migration переносит only historical transactions;
• migration запускается вручную platform user-ом;
• migration tool может быть максимально простым;
• migration не обязана иметь public API;
• migration functionality может быть удалена после завершения transition;
• migrated transactions read-only;
• webhooks по migrated transactions не отправляются.

Осталось определить:

• exact input format;
• exact old-to-new mapping;
• exact report format;
• validation rules;
• fallback status mapping;
• duplicate handling;
• who signs off migration result.

Input direction:

• old system: merchantId / merchantConfigId;
• new system: brandId / paymentMethodId.

11. Test Provider gaps

Test Provider product direction определен:

• нужен;
• должен поддерживать все MVP payment methods;
• работает в stg;
• может быть доступен в prod;
• доступен всем merchants;
• возвращает hosted redirect URL;
• может участвовать в test velocity/fees/turnover context;
• test transactions видны в обычных transaction pages;
• test marker должен быть виден в Back Office.

Осталось определить:

• exact outcome control mechanism;
• exact hosted redirect URL implementation;
• exact timeout/error simulation trigger;
• exact provider adapter identifier;
• whether test marker is included in merchant webhook payload or only internal/backoffice data.

12. Monitoring and Operations gaps

Monitoring product direction определен:

• Prometheus metrics;
• Cloud Logging / Cloud Monitoring / Grafana;
• alerts for provider/merchant/system success rate;
• webhook failures;
• queue lag;
• suspicious callbacks;
• provider errors/timeouts.

Осталось определить:

• exact metric names;
• exact labels/cardinality;
• exact alert thresholds;
• alert routing;
• on-call/runbook process;
• dead-letter handling process;
• internal ops response flow.

13. Things Not Included in MVP

Следующие вещи явно не входят в MVP:

• withdrawals;
• approve/cancel withdrawals;
• refunds;
• anti-fraud module;
• blocklist/frozen/unfreeze functionality;
• customer profile/entity management;
• advanced reports;
• dashboards;
• provider polling;
• routing simulation;
• maintenance banner;
• feature flags;
• public troubleshooting page;
• OpenAPI/Postman package as mandatory deliverable;
• multi-language hosted payment page;
• merchant self-service creation of SUB MID AGGREGATOR;
• merchant ability to see platform-created provider internals without access.

Важно: часть этих вещей может быть planned later, но не должна блокировать MVP.

14. Recommended Next Steps

Рекомендуемый порядок работы:

1. Product Owner проходит 00-context, 01-mvp-scope, 02-actors-and-access-model и подтверждает high-level scope.
2. Product Owner и development lead проходят user journeys и domain documents.
3. Product Owner помечает documents как product-approved, где product behavior закрыт.
4. Design team начинает Back Office and hosted payment page UX на основе approved flows.
5. Development team готовит technical design: architecture, database schema, events, security, provider adapter model.
6. DevOps готовит environment/deployment/monitoring plan.
7. QA готовит test plan and release acceptance checklist.
8. Product Owner готовит merchant public documentation draft.
9. Команда превращает approved documents в epics/tickets.
10. PO и team выбирают first merchant / first payment method for transition.

15. Ownership Matrix

Area	Owner	Output	Blocks MVP
MVP scope approval	Product Owner	Approved MVP scope	Yes
User journeys approval	Product Owner	Approved flows / UAT scenarios	Yes
Back Office UX	Design + Product Owner	Designs / screen specs	Yes
Hosted payment page UX	Design + Product Owner	Customer-facing page design	Yes
Merchant public docs	Product Owner + Development	Public docs draft	Yes
Database schema	Development	DB schema draft	Yes
Technical architecture	Development	Technical design	Yes
Event/PubSub design	Development	Event contracts / retry strategy	Yes
API/webhook HMAC	Development + Security	Signing specification	Yes
Secret handling	Development + Security	Security design	Yes
Environments/deploy	DevOps	Deployment plan	Yes
Monitoring/alerts	DevOps + Development	Metrics/alerts/runbooks	Yes
QA test plan	QA	Test plan / acceptance checklist	Yes
Load test	QA + DevOps + Development	Load test report	Yes
Legacy migration tool	Development + Product Owner	Tool + migration report	Yes for first migrated merchant
Test provider	Development + QA	Test provider implementation	Yes

16. Ready for Ticketing Checklist

Перед созданием production implementation tickets нужно иметь:

• approved MVP scope;
• approved deposit user journeys;
• approved routing hierarchy;
• approved Back Office information architecture;
• approved permissions dictionary;
• approved status dictionary;
• approved error code dictionary;
• approved transaction data requirements;
• technical database schema;
• technical architecture decision record;
• API request signing specification;
• webhook signing and retry specification;
• provider adapter contract;
• event schemas;
• QA acceptance checklist;
• initial design/wireframes for Back Office and hosted payment page.

После этого можно разбивать работу на epics:

• Merchant / Brand / API Keys;
• Auth / Users / Roles / Permissions;
• Provider Catalog / Provider Access;
• SUB MID / SUB MID AGGREGATOR;
• Payment Method / MASTER MID / Routing;
• Deposit API / Hosted Payment Page;
• Provider Callback Gateway;
• Merchant Webhook Delivery;
• Transaction Timeline / Investigation;
• Velocity Limits;
• FX / Fees;
• Error Mapping;
• Audit Logs;
• Migration Tool;
• Test Provider;
• Monitoring / Alerts;
• QA / Load Testing.