04.01 Back Office Information Architecture

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

1. Назначение документа

Этот документ описывает структуру Back Office для MVP:

• общую навигацию;
• разделение Platform и Merchant sections;
• правила отображения меню;
• merchant context / merchant filter;
• список MVP pages;
• базовые navigation principles.

2. Общий принцип

В MVP должен быть один общий Back Office для:

• platform users;
• merchant users.

Login flow общий.

После login user попадает в Back Office, где доступные возможности определяются:

• user type;
• roles;
• permissions;
• merchant access;
• merchant group access;
• entity visibility rules.

3. Left menu

В левом меню должны быть два основных раздела:

• Platform;
• Merchant.

Оба раздела отображаются:

• platform user;
• merchant user.

При этом доступность конкретных страниц и действий внутри разделов определяется permissions.

Это значит:

• user может видеть section, но не видеть часть pages внутри section;
• user может открыть page, но видеть только доступные ему данные;
• user может видеть entity, но не иметь permission на edit/delete;
• hidden provider/internal details должны оставаться скрытыми независимо от section.

4. Default page after login

После login Back Office должен открывать:

Transactions

Dashboard/home page в MVP не нужен.

Если user имеет доступ к transaction list, он попадает туда. Если у user нет permission смотреть transactions, система должна открыть первую доступную page или показать empty/access denied state.

5. Merchant selector / merchant filter

На страницах, где данные зависят от merchant context, должен быть selector/filter по merchants.

Принцип:

• user видит только merchants, к которым у него есть доступ;
• user может выбрать одного merchant;
• user может выбрать несколько merchants;
• default state показывает всех доступных merchants;
• merchant group access должен позволять видеть merchants внутри доступной group.

Merchant selector не должен быть обязательным глобальным шагом перед входом в Back Office.

User не должен сначала выбирать merchant context на отдельном экране.

Каждая page сама должна давать удобный filter/context selector, если это нужно для данных этой page.

6. Merchant group view

Если user имеет доступ к merchant group, он должен иметь возможность видеть данные merchants внутри этой group через обычные page filters/context selector.

Merchant Group в MVP используется для grouping/access, а не для отдельных reporting dashboards или общих processing settings.

Один merchant может входить только в одну Merchant Group.

Это применимо к страницам:

• Transactions;
• Users;
• Audit Logs;
• Payment Method / MID;
• Brands;
• API Keys;
• Webhooks, если page/section будет выделен отдельно.

Действия внутри group context все равно должны проверять permissions.

Если user имеет доступ к merchant group, это не значит автоматический доступ ко всем actions.

7. Platform section pages

В MVP Platform section должен содержать:

• Merchants;
• Merchant Groups;
• Users;
• Roles;
• SUB MID Aggregators;
• Audit Logs.

7.1 Merchants

Platform users с permission могут:

• создавать merchant;
• редактировать merchant;
• смотреть merchant details;
• смотреть merchant access overview;
• смотреть linked brands;
• смотреть linked payment method configurations;
• управлять Provider Access через Merchant Details;
• смотреть audit logs по merchant.

Merchant Details в MVP является platform-only overview/control page. Он не должен дублировать CRUD flows из Merchant section pages.

Создание/редактирование brands, API keys, payment methods, users/access выполняется через соответствующие Merchant section pages с выбранным merchant context.

Provider Access является исключением: он управляется внутри Merchant Details и доступен только platform user с permission.

7.2 Merchant Groups

Platform users с permission могут:

• создавать merchant group;
• добавлять merchants в group;
• удалять merchants из group;
• выдавать users доступ к merchant group;
• смотреть merchants внутри group через доступные page filters.

Merchant group access в MVP не включает role assignment in group context.

Создавать Merchant Group и добавлять/удалять merchants из group может только platform user с permission.

Изменение состава Merchant Group должно сразу менять group-based access и писать audit event.

7.3 Users

Platform users с permission могут:

• создавать platform users;
• создавать merchant users;
• приглашать users через email link;
• управлять user status;
• выбирать user type при создании user-а;
• управлять user access to merchants;
• управлять user access to merchant groups;
• назначать roles в нужном context;
• смотреть sessions/profile-related info, если permission позволяет.

Минимальные поля user-а в MVP:

• email;
• first name;
• last name;
• status;
• user type.

Phone в MVP не нужен.

Merchant user может быть создан без merchant / merchant group access.

Если user залогинился без access context, Back Office должен открыться, но показывать пустое состояние без merchant-scoped данных.

Повторный invite на email существующего user-а или pending invite должен вернуть ошибку.

Expired invite должен иметь отдельную resend invite action/button.

Отдельный invite status CANCELED в MVP не нужен.

7.4 Roles

Platform users с permission могут:

• создавать roles;
• редактировать roles;
• назначать permissions roles;
• помечать role как platform role;
• помечать role как merchant role;
• определять, какие roles могут быть выданы merchant admin users.

Merchant users не могут редактировать permissions roles.

7.5 SUB MID Aggregators

Platform users с permission могут:

• создавать SUB MID Aggregator;
• настраивать provider configuration;
• настраивать velocity limits;
• настраивать FX / conversion fee;
• настраивать expiration time;
• настраивать email replacement / fake email generation;
• управлять status;
• использовать SUB MID Aggregator в routing;
• смотреть audit logs.

SUB MID Aggregator является global platform-level reusable configuration.

SUB MID Aggregator details должен иметь вкладку audit logs, как и другие изменяемые entities.

7.6 Audit Logs

Platform users с permission могут смотреть audit logs:

• по users;
• по merchants;
• по merchant groups;
• по roles;
• по payment method configurations;
• по MASTER MID, если user работает в merchant context;
• по SUB MID Aggregators;
• по transactions.

7.7 System Settings

System Settings page не входит в MVP.

Runtime configuration в MVP управляется через environment variables / code-level configuration.

8. Merchant section pages

В MVP Merchant section должен содержать:

• Transactions;
• Payment Method / MID;
• MASTER MID;
• SUB MID;
• Brands;
• Users;
• Roles view-only;
• API Keys;
• Webhooks;
• Audit Logs;
• Profile / Sessions.

8.1 Transactions

Transactions page находится в Merchant section.

Platform users и merchant users с permission могут открывать эту page. Visibility зависит от user type, permissions, merchant access, merchant group access and entity visibility rules.

Users с permission могут:

• смотреть transactions доступных merchants;
• использовать merchant selector/filter;
• смотреть transaction details;
• смотреть timeline according to visibility;
• смотреть webhook payload and delivery attempts;
• делать resend webhook, если permission позволяет;
• делать manual correction, если permission позволяет;
• экспортировать доступные поля.

Merchant user не видит Provider callbacks tab and raw provider data. Platform user with permission can see Provider callbacks tab and raw provider data.

Transaction list row не должен содержать quick actions.

Из transaction list merchant user только открывает transaction details.

Manual correction and resend webhook выполняются из transaction details, если user имеет permission.

Merchant transaction details должен показывать:

• Summary;
• Timeline;
• Webhooks;
• Routing;
• FX / Fees, если есть permission;
• Audit / Corrections, если есть permission.

Merchant user должен видеть Routing всегда, но только merchant-safe representation.

Merchant user с permission может видеть merchant webhook payloads in Webhooks tab.

Merchant user не видит raw provider request / response / callback.

Manual correction доступна для любых transaction statuses, если user имеет permission.

Resend callback/webhook доступен на PROCESSING and final statuses, если user имеет permission.

8.2 Payment Method / MID

Payment Method / MID page находится в Merchant section и используется:

• merchant users с permission;
• platform users с permission.

Page по default показывает configurations по всем доступным merchants с pagination. User может фильтровать по merchant. При создании Payment Method / MID user выбирает merchant.

Users с permission могут:

• смотреть payment method configurations;
• создавать payment method configuration;
• редактировать first-level routing rules;
• видеть routing to MASTER MID GROUP / MASTER MID;
• менять настройки MASTER MID GROUP selection, если permission позволяет;
• подключать MASTER MID, которые доступны merchant-у.

Merchant user не видит internal blueprint MASTER MID, если MASTER MID создан platform user и hidden by design.

Payment Method / MID table в MVP не должна показывать metrics вроде transactions count / success rate.

Payment Method / MID использует одно поле name; отдельный displayName в MVP не нужен.

Customer на hosted payment form не видит Payment Method / MID name.

Payment Method / MID details должна иметь вкладку Audit Logs.

Payment Method / MID details также должна иметь вкладку Linked MASTER MID.

Payment Method / MID нельзя сделать ACTIVE, если нет valid published routing.

8.3 SUB MID

SUB MID page находится в Merchant section и используется:

• merchant users с permission;
• platform users с permission.

SUB MID Aggregator page находится в Platform section.

Page по default показывает SUB MID по всем доступным merchants с pagination. User может фильтровать по merchant. При создании SUB MID user выбирает merchant.

Users с permission могут:

• смотреть SUB MID, которые они имеют право видеть;
• создавать SUB MID, если им выдан provider access и permission;
• настраивать provider configuration для созданного ими SUB MID;
• настраивать velocity limits на созданном ими SUB MID;
• настраивать FX / conversion fee на созданном ими SUB MID;
• подключать SUB MID в routing, если permission позволяет.

Merchant user не видит SUB MID / provider configuration, созданные platform user, если доступ не был явно выдан.

SUB MID details должна иметь вкладку Audit Logs. SUB MID details должна иметь вкладку Linked MASTER MID.

При создании SUB MID provider method выбирается из code registry после выбора provider. Если required credentials/config не заполнены, save должен быть запрещен.

Если SUB MID disabled/deleted, routing skips it and tries fallback.

8.4 MASTER MID

MASTER MID является merchant-scoped сущностью.

MASTER MID page находится в Merchant section и используется:

• merchant users с permission;
• platform users с permission.

Page по default показывает MASTER MID по всем доступным merchants с pagination. User может фильтровать по merchant. При создании MASTER MID user выбирает merchant.

Platform user с permission может создавать и управлять MASTER MID в context конкретного merchant.

Merchant user с permission может создавать MASTER MID, если:

• у него есть access к merchant / merchant group;
• у него есть permission управлять MASTER MID;
• ему выдан provider access, если для MASTER MID нужно создавать SUB MID под конкретного provider.

Если MASTER MID создан platform user, merchant user не должен видеть его internal blueprint, если такой доступ не был явно разрешен.

Merchant user может видеть high-level MASTER MID name/status и использовать его в Payment Method / MID routing, если MASTER MID доступен этому merchant.

MASTER MID details должна иметь вкладку Audit Logs. MASTER MID details должна иметь вкладки Linked SUB MID и Used in Payment Methods.

MASTER MID нельзя сделать ACTIVE, если нет valid published routing.

Processing Fee настраивается после создания MASTER MID.

Если MASTER MID disabled/deleted, routing skips it and tries fallback.

MASTER MID можно soft-delete even if used in published routing, but UI must show warning with linked Payment Method / MID list.

8.5 Brands

Merchant users с permission могут:

• создавать brand;
• редактировать brand;
• смотреть brand details;
• использовать brand в deposit request;
• управлять basic brand data.

Brand является отдельной сущностью внутри merchant context.

Brands должны быть отдельной вкладкой, а не только частью merchant details.

Brand details должна иметь вкладку Audit Logs.

8.6 Users

Merchant users с permission могут:

• invite merchant users;
• выдавать доступ только к merchants, где у них есть право управлять users;
• назначать только те merchant roles, которые разрешены platform configuration;
• не могут менять permissions roles.

Merchant users не могут выдавать доступ к merchant groups.

8.7 Roles view-only

Merchant users могут видеть доступные merchant roles, если permission позволяет.

Merchant users не могут:

• создавать roles;
• редактировать role permissions;
• менять platform-defined role behavior.

8.8 API Keys

Merchant users с permission могут:

• создавать merchant API keys;
• смотреть список keys;
• управлять key rotation;
• удалять/revoke keys;
• выбирать key rotation grace period.

API keys создаются на merchant, не на brand.

8.9 Webhooks

Merchant users с permission могут:

• смотреть webhook delivery history;
• смотреть webhook payload;
• смотреть response code/body;
• делать manual resend;
• видеть attempts/retries.

Webhook URLs задаются на уровне transaction request.

8.10 Audit Logs

Merchant users с permission могут смотреть audit logs по доступным им сущностям.

Audit logs должны учитывать visibility rules и secret data rules.

Merchant users не должны видеть:

• provider credentials;
• hidden provider/internal data;
• platform-only operational details.

8.11 Profile / Sessions

User может:

• смотреть свой profile;
• смотреть active sessions;
• смотреть history завершенных sessions / login sessions;
• смотреть security events;
• редактировать свои first name / last name;
• завершать выбранную session;
• менять password через reset/change flow, если это поддержано UI.

Security events в profile должны включать:

• login failed;
• password reset;
• 2FA reset;
• new device/IP login notification.

9. Permissions principle

Весь Back Office должен быть permission-based.

Каждое действие должно иметь permission.

Минимально permissions должны покрывать:

• view;
• create;
• edit;
• delete/revoke;
• export;
• manual correction;
• resend webhook;
• manage access;
• manage roles;
• view sensitive/internal data.

UI не должен показывать действия, которые user не может выполнить.

Backend должен проверять permission независимо от UI.

9.1 Save / draft behavior in forms

Обычные сущности, которые не влияют напрямую на routing/payment execution, используют обычный Save.

Save as draft для таких сущностей в MVP не нужен.

Обычный Save достаточно для:

• Merchant;
• Merchant Group;
• Brand;
• User;
• Role metadata;
• Provider Access grant/revoke;
• API key actions, с учетом OTP для sensitive actions.

Draft / publish применяется к configurations, которые влияют на payment execution/routing:

• Payment Method / MID routing;
• MASTER MID routing;
• SUB MID / SUB MID AGGREGATOR credentials/config versioning;
• velocity limits;
• FX / fees;
• processing fee.

9.2 Destructive/sensitive action confirmations

Все soft-delete actions в Back Office должны требовать confirmation modal.

Для soft-delete user должен указать reason/comment.

Это относится к удалению/архивации изменяемых entities, например:

• Merchant;
• Merchant Group;
• Brand;
• Payment Method / MID;
• MASTER MID;
• SUB MID;
• SUB MID AGGREGATOR;
• Role;
• User access removal, если action реализован как removal/revoke.

API key revoke требует confirmation modal and OTP code.

Provider Access revoke требует confirmation modal. Provider Access revoke не требует reason/comment.

Manual transaction correction требует reason/comment.

Manual resend callback/webhook требует reason/comment.

10. Access denied / empty states

Если user открыл page без нужной permission:

• показываем access denied state;
• не показываем hidden data.

Если user имеет permission, но данных нет:

• показываем empty state с текстом No data yet;
• если user может создать entity, показываем create action;
• если user не может создать entity, показываем только empty state.

10.1 Transaction table UX

Transaction list должен иметь configurable columns.

Default visible columns определяются product/design team на основе самых важных investigation fields.

Recommended default columns:

• transaction ID;
• Merchant Name;
• Brand Name;
• type;
• amount original;
• currency;
• status;
• corrected;
• updated.

Все columns, кроме transaction ID, можно скрывать/показывать через table column settings.

Transaction ID всегда остается visible.

Column settings должны сохраняться на client side.

Transaction list должен показывать legacy transactions как badge/marker в row.

Transaction list row не должен иметь quick actions.

Из transaction list user только открывает transaction details.

10.2 Audit Logs tabs on entity details

Все изменяемые entity details pages должны иметь вкладку Audit Logs, если user имеет permission видеть audit logs по этой entity.

Минимально это относится к:

• Merchant;
• Merchant Group;
• Brand;
• Payment Method / MID;
• MASTER MID;
• SUB MID;
• SUB MID Aggregator;
• User;
• Role;
• API Key;
• Provider Access;
• Transaction, через Audit / Corrections или Audit Logs section.

11. Acceptance Criteria

Back Office IA считается согласованной для MVP, если:

• Один Back Office используется для platform users и merchant users.
• Login flow общий.
• Left menu содержит Platform section.
• Left menu содержит Merchant section.
• Platform и Merchant sections отображаются platform users и merchant users.
• Доступность pages/actions определяется permissions.
• После login открывается Transactions.
• Dashboard/home page не нужен в MVP.
• Pages с merchant-dependent data имеют merchant selector/filter.
• Merchant selector показывает всех доступных merchants по default.
• User может выбрать одного или несколько merchants.
• Merchant group access дает доступ к merchants внутри group через обычные filters/context selectors.
• Merchant Group используется для grouping/access.
• Один merchant может входить только в одну Merchant Group.
• Platform section содержит Merchants, Merchant Groups, Users, Roles, SUB MID Aggregators, Audit Logs.
• Merchant Details является platform-only overview/control page.
• Merchant Details не дублирует CRUD flows из Merchant section pages.
• Provider Access управляется внутри Merchant Details и виден только platform users с permission.
• Merchant section содержит Transactions, Payment Method / MID, MASTER MID, SUB MID, Brands, Users, Roles view-only, API Keys, Webhooks, Audit Logs, Profile / Sessions.
• Brands являются отдельной вкладкой.
• Merchant user может создавать users только из Merchant section, только в merchant context и только в рамках permissions/access.
• Merchant user не может добавлять users в merchant groups.
• Platform user может создавать merchant users и platform users.
• Platform user может управлять merchant group access user-ов.
• User без access context видит пустой Back Office.
• User profile показывает active sessions, session history и security events.
• UI и backend проверяют permissions.
• Empty state для pages без данных показывает No data yet.
• Transaction table имеет configurable columns.
• Все columns, кроме transaction ID, можно скрывать/показывать.
• Transaction ID нельзя скрыть.
• Column settings сохраняются на client side.
• Transaction list показывает legacy badge/marker.
• Transaction details показывает Routing tab merchant user-у всегда в merchant-safe representation.
• Merchant user с permission видит merchant webhook payloads in Webhooks tab.
• Raw provider payloads доступны только platform users с permission.
• Manual correction доступна из transaction details для любых statuses при наличии permission.
• Resend callback/webhook доступен из transaction details на PROCESSING and final statuses при наличии permission.
• Изменяемые entity details pages имеют Audit Logs tab, если user имеет permission.

12. Open Questions

Product open questions отсутствуют.

Design follow-up:

1. Нарисовать left menu structure.
2. Описать page-level layouts для Platform section.
3. Описать page-level layouts для Merchant section.
4. Описать merchant selector/filter UI.
5. Описать empty/access denied states.