Payment Orchestrator

Тема

04.03 Back Office Page-by-Page Requirements ​

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

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

Этот документ дополняет:

04.01 отвечает на вопрос: какие разделы есть в Back Office.
04.02 отвечает на вопрос: как должен работать routing blueprint editor.
04.03 отвечает на вопрос: что должно быть на каждой странице.

Документ не является финальным UI design. Это product requirements для будущего дизайна.

2. Naming recommendation ​

На уровне документации и tickets рекомендуется использовать:

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

Рекомендация:

text
Core service = Orchestrator Service

Причина: service отвечает не только за payment record, но и за routing, provider execution, callbacks, webhooks, fees, velocity, timeline and audit.

Product decision:

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

3. Global Back Office Rules ​

3.1. Общий layout ​

Back Office имеет:

  • left menu;
  • top bar;
  • page title;
  • page-level filters;
  • main content area;
  • details pages with tabs;
  • action buttons based on permissions.

Left menu содержит:

  • Platform;
  • Merchant.

Оба section могут быть видны platform users и merchant users. Доступность конкретных pages и actions определяется permissions.

3.2. Default page after login ​

После login открывается:

text
Transactions

Если user не имеет can_view_transactions, система открывает первую доступную page. Если доступных данных нет, показывается empty state.

3.3. Merchant selector ​

На merchant-scoped pages должен быть merchant selector/filter.

Правила:

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

3.4. Permissions ​

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

Если user может открыть page, но данных нет:

text
No data yet

Если user пытается открыть forbidden entity/page:

text
Access denied

Exact copy может быть уточнен design/content team.

3.5. Tables ​

Все основные list pages должны поддерживать:

  • pagination;
  • sorting, если применимо;
  • filters;
  • search, если применимо;
  • column visibility, если columns много;
  • export только там, где это явно указано.

Default sorting для transaction list:

text
updated desc

Для остальных pages default sorting должен быть предложен design/development team.

3.6. Delete behavior ​

Все delete actions в Back Office являются soft-delete.

Physical delete из UI не выполняется.

Для entities со status можно использовать:

text
DELETED

Например:

  • Merchant;
  • Brand;
  • Role;
  • Payment Method / MID.

3.7. Audit Logs tab ​

У всех изменяемых entities должна быть вкладка:

text
Audit Logs

Audit Logs показывают изменения с учетом:

  • permissions;
  • merchant access;
  • merchant group access;
  • entity visibility;
  • secret masking rules.

3.8. Secret values ​

Secret values:

  • шифруются;
  • не показываются после сохранения;
  • не попадают в audit log raw value;
  • могут быть только заменены новым значением;
  • показываются в UI как configured/masked state.

Non-secret config fields можно показывать и редактировать.

4. Auth and Profile Pages ​

4.1. Login ​

Назначение:

User входит в Back Office.

Должно быть:

  • email;
  • password;
  • login action;
  • forgot password link;
  • 2FA step after successful password validation, если 2FA включена.

2FA обязательна в:

  • dev;
  • stg;
  • prod.

4.2. First Admin Setup ​

Если после deployment в системе нет ни одного user-а, Back Office должен показать setup flow.

Flow:

  1. User открывает Back Office.
  2. Система видит, что users отсутствуют.
  3. User создает first platform admin:
    • email;
    • first name;
    • last name;
    • password.
  4. Система создает platform role Admin.
  5. Система назначает role Admin все permissions.
  6. First user получает platform role Admin.

Этот flow доступен только пока в системе нет users.

4.3. Invitation Accept ​

User получает email link.

Flow:

  1. User открывает invitation link.
  2. User задает password.
  3. User сканирует 2FA QR code.
  4. User подтверждает OTP.
  5. User входит в Back Office.

Если invitation expired, user должен обратиться к admin или admin должен нажать resend invite.

4.4. Password Reset ​

Flow:

  1. User нажимает forgot password.
  2. User вводит email.
  3. Система отправляет email link/code.
  4. User задает новый password.
  5. 2FA secret сбрасывается.
  6. User должен заново настроить 2FA.

4.5. Profile / Sessions ​

Доступно всем logged-in users.

Page должна показывать:

  • profile data;
  • active sessions;
  • session history;
  • security events;
  • action to terminate selected session;
  • action to change password / reset password flow.

User может редактировать:

  • first name;
  • last name.

User не может сам менять email в MVP, если это не будет отдельно согласовано.

Security events:

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

5. Transactions ​

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

Platform users также используют эту page через Merchant section. Разница между platform user и merchant user определяется permissions, merchant access and visibility rules.

Отдельная Platform / Transactions page в MVP не нужна.

5.1. Transaction List ​

Назначение:

Показать transactions, доступные user-у.

Default behavior:

  • открывается после login;
  • default sorting: updated desc;
  • pagination;
  • export by current filters;
  • no row quick actions;
  • row click opens transaction details.

Default visible columns:

  • merchant name;
  • brand name;
  • transaction ID;
  • merchant user ID;
  • type;
  • amount original;
  • currency;
  • status;
  • created;
  • updated.

Optional/hideable columns:

  • merchant group;
  • user email;
  • MID ID;
  • MID name;
  • amount in EUR;
  • account reference;
  • provider transaction ID, only if visible by permissions;
  • corrected;
  • legacy;
  • test.

Error code / error description не должны быть columns в transaction list. Эта информация отображается в transaction details.

Для merchant user:

  • provider column/filter не показывается;
  • MID-related column может показывать MID name, если user имеет право видеть эту колонку;
  • real provider name не показывается, если нет Provider Access and permission.

Filters:

  • merchant;
  • brand;
  • merchant group;
  • payment method;
  • status;
  • date;
  • amount;
  • currency;
  • provider, platform/internal visibility only;
  • user ID;
  • transaction ID search input;
  • type;
  • legacy;
  • test.

Transaction ID search input должен искать по:

  • internal transaction ID;
  • merchant transaction ID;
  • provider transaction ID.

Merchant user может искать по provider transaction ID, если он знает этот ID. Search result при этом остается merchant-safe и не раскрывает provider internals.

Table columns/filters customization сохраняется локально в browser storage.

Export:

  • only current filters;
  • only visible columns;
  • only allowed fields;
  • CSV in MVP.

Export date range limit:

text
maximum 90 days per export

Если user выбирает date range больше 90 дней, UI должен показать validation error.

5.2. Platform Transaction Details ​

Platform user с permissions может видеть full internal transaction details.

Tabs:

  • Summary;
  • Timeline;
  • Webhooks;
  • Provider Callbacks;
  • Routing;
  • FX / Fees;
  • Audit / Corrections;
  • Raw Payloads.

Actions:

  • export/copy technical identifiers, if allowed.

Manual correction:

  • can change status;
  • requires reason/comment;
  • can trigger resend callback;
  • writes timeline event;
  • writes audit event.
  • action is located inside Audit / Corrections tab.

Resend webhook/callback:

  • action is located inside Webhooks tab.

Summary tab must include:

  • transaction identifiers;
  • current status;
  • merchant;
  • brand;
  • payment method;
  • amount/currency;
  • customer email;
  • customer country;
  • customer first name;
  • customer last name;
  • customer IP;
  • customer city;
  • customer address;
  • account reference, if exists.

Summary tab should not include a separate latest event / failure reason block. Failure/error details should be shown in regular transaction details fields and timeline.

Provider Callbacks tab:

  • raw callback payload is not shown by default;
  • user opens raw payload through explicit View raw action.

5.3. Merchant Transaction Details ​

Merchant user видит merchant-safe transaction details.

Tabs:

  • Summary;
  • Timeline;
  • Webhooks;
  • Routing;
  • FX / Fees, if permission;
  • Audit / Corrections, if permission.

Merchant user не видит:

  • raw provider request;
  • raw provider response;
  • raw provider callback;
  • real provider error;
  • hidden routing details;
  • platform-created internal MASTER MID blueprint, если access не выдан.

Merchant user видит:

  • unified error code;
  • human-readable description;
  • status;
  • transaction identifiers;
  • merchant webhook attempts;
  • merchant-safe timeline.

Merchant user sees merchant webhook payloads in Webhooks tab. Merchant user does not get separate Raw Payloads access to provider payloads.

6. Platform Section Pages ​

6.1. Platform / Merchants ​

Назначение:

Platform user управляет merchants.

Merchant Details в MVP является platform-only page. Merchant user не открывает общий Merchant Details / Merchant Profile.

Merchant users работают через отдельные Merchant section pages:

  • Brands;
  • API Keys;
  • Payment Method / MID;
  • MASTER MID;
  • SUB MID;
  • Users;
  • Transactions;
  • Webhooks;
  • Audit Logs.

Важно: Merchant Details не должен дублировать CRUD functionality из Merchant section pages. Если функционал уже есть отдельной page в Merchant section, Merchant Details должен давать overview/list/link, а не вторую форму создания/редактирования.

List columns:

  • merchant name;
  • status;
  • merchant group;
  • created;
  • updated.

Filters:

  • status;
  • merchant group;
  • search by merchant name/id.

Actions:

  • create merchant;
  • open merchant details;
  • soft-delete/disable merchant, if permission.

Merchant details tabs:

  • Overview;
  • Brands;
  • Payment Methods / MID;
  • API Keys;
  • Users / Access;
  • Provider Access;
  • Transactions;
  • Audit Logs.

Provider Access в MVP отображается как tab внутри Merchant Details. Отдельная Platform page для Provider Access не нужна. Provider Access tab видит только platform user с permission. Merchant user не видит read-only список providers, к которым merchant имеет access.

Merchant fields:

  • merchant ID;
  • name;
  • status;
  • legal name;
  • merchant group;
  • created;
  • updated.

display name отдельно не нужен, если name уже выполняет эту функцию. default currency, country, website/domain на Merchant в MVP не нужны.

6.1.1. Merchant Details / Overview ​

Overview показывает read-only/admin summary по merchant:

  • merchant ID;
  • name;
  • legal name;
  • status;
  • merchant group;
  • created;
  • updated.

Actions:

  • edit merchant basic fields, if permission;
  • disable/soft-delete merchant, if permission.

No MVP risk warning section:

  • no active API key warning не нужен;
  • no active brands warning не нужен;
  • no payment methods warning не нужен.

Если merchant disabled/inactive:

  • new API deposits should be rejected with unified error;
  • existing transactions continue to be visible;
  • existing provider callbacks continue to be processed;
  • existing merchant webhooks/retries continue to be processed.

Hosted payment form does not use merchant public name in MVP. Hosted payment form should not show merchant name as a separate public label.

6.1.2. Merchant Details / Brands tab ​

Brands tab in Merchant Details is overview/navigation only.

It may show:

  • list/count of brands;
  • brand status;
  • link to Merchant section Brands page with this merchant preselected.

Create/edit brand is done through Merchant section Brands page.

Platform user who needs to create a brand should open Merchant section Brands, select merchant and create brand there.

6.1.3. Merchant Details / Payment Methods / MID tab ​

Payment Methods / MID tab in Merchant Details is overview/navigation only.

It may show:

  • linked payment method configurations;
  • status;
  • method type;
  • link to Merchant section Payment Method / MID page with this merchant preselected.

Create/edit Payment Method / MID is done through Merchant section Payment Method / MID page.

6.1.4. Merchant Details / API Keys tab ​

API Keys tab in Merchant Details is overview/navigation only.

It may show:

  • key metadata;
  • active/rotation state;
  • link to Merchant section API Keys page with this merchant preselected.

API key create/rotate/revoke is done through Merchant section API Keys page.

Platform user with permission can create/rotate/revoke API key for any merchant from Merchant section API Keys, after selecting the merchant.

If platform user creates or rotates API key, secret value is shown once, same as for merchant user.

6.1.5. Merchant Details / Users / Access tab ​

Users / Access tab in Merchant Details is overview/navigation only.

Platform user can see:

  • users who have access to this merchant;
  • their role in this merchant context;
  • user status;
  • link to Merchant section Users page with this merchant preselected.

Granting/removing merchant user access is done through Merchant section Users page.

6.1.6. Merchant Details / Provider Access tab ​

Provider Access tab is platform-only.

Platform user with permission can:

  • see providers granted to this merchant;
  • grant provider access;
  • revoke provider access;
  • see audit history for provider access changes.

Revoke Provider Access requires confirmation modal. Reason/comment is not required in MVP.

6.1.7. Merchant Details / Transactions tab ​

Transactions tab is navigation only.

It should link to Merchant section Transactions page with merchant filter applied.

Embedded transaction list inside Merchant Details is not required in MVP.

6.1.8. Merchant Details / Audit Logs tab ​

Audit Logs tab inside Merchant Details shows audit events for merchant entity only.

It does not aggregate child entity audit logs in MVP.

Child entity audit logs are viewed in their own entity pages:

  • Brand;
  • Payment Method / MID;
  • API Key;
  • Provider Access, if shown as tab events;
  • User access;
  • other related entities.

6.2. Platform / Merchant Groups ​

Назначение:

Platform user группирует merchants и выдает group-level access.

List columns:

  • group name;
  • merchants count;
  • created;
  • updated.

Actions:

  • create group;
  • edit group;
  • add/remove merchants;
  • grant user access to group;
  • soft-delete group, if permission.

Merchant Group не имеет processing settings в MVP.

6.3. Platform / Users ​

Назначение:

Platform user управляет platform users и merchant users.

Platform Users page shows all users according to permissions.

List columns:

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

Filters:

  • user type;
  • status;
  • merchant access;
  • merchant group access;
  • search by email/name.

Create user flow:

  • choose user type: platform user or merchant user;
  • email;
  • first name;
  • last name;
  • send email invitation link.

User fields:

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

Phone is not required in MVP.

User details tabs:

  • Overview;
  • Roles;
  • Merchant Access;
  • Merchant Group Access;
  • Sessions;
  • Security Events;
  • Audit Logs.

Merchant user может быть создан без merchant access. В таком случае после login он видит empty Back Office.

Merchant access means:

  • user gets access to concrete merchant;
  • user receives merchant role in context of this merchant.

Merchant group access means:

  • user gets access scope to merchant group;
  • merchant role is not assigned in merchant group context in MVP.

Merchant group access can be granted only by platform user.

If user has merchant access and merchant group access, effective access is calculated from available scopes and merchant-specific roles.

Remove access removes concrete access binding. It does not delete user.

Expired invite:

  • show resend invite action.

Duplicate invite/user:

  • system returns error.

Invite cancel status/action is not required in MVP.

6.4. Platform / Roles ​

Назначение:

Platform user создает roles and assigns permissions.

List columns:

  • role name;
  • role type;
  • status;
  • created;
  • updated.

Role type:

  • platform role;
  • merchant role.

Platform role can be assigned only to platform user. Merchant role can be assigned only to merchant user in context of one merchant. Merchant role cannot be assigned in merchant group context in MVP.

Actions:

  • create role;
  • edit role;
  • edit permissions;
  • mark role as merchant-assignable;
  • soft-delete role.

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

Если role удаляется у user-а, у user-а просто пропадает эта role. Если у user-а не остается access/roles, он видит empty Back Office.

Role details page should show grouped permissions by domain:

  • Transactions;
  • Webhooks;
  • Merchants;
  • Merchant Groups;
  • Brands;
  • Users;
  • Roles;
  • API Keys;
  • Payment / Routing;
  • MASTER MID;
  • SUB MID;
  • SUB MID Aggregators;
  • Velocity Limits;
  • FX / Fees;
  • Audit Logs;
  • Sensitive Data.

Permissions do not need to be represented as CRUD matrix. Action permissions should use explicit capability names, for example:

text
can_resend_tx_callback

Default seed roles:

  • first platform Admin role is created automatically and receives all permissions;
  • default merchant admin role is created automatically;
  • platform admin can edit default merchant admin role permissions later.

6.5. Platform / SUB MID Aggregators ​

Назначение:

Platform user управляет reusable provider configurations.

List columns:

  • name;
  • provider real name;
  • provider method;
  • status;
  • created;
  • updated.

Provider real name видят только platform users.

Details tabs:

  • Overview;
  • Credentials / Config;
  • Velocity Limits;
  • FX / Conversion Fee;
  • Expiration;
  • Email Replacement;
  • Usage / Linked Routing;
  • Audit Logs.

Actions:

  • create;
  • edit non-secret fields;
  • replace secret values;
  • disable;
  • soft-delete/archive, if allowed.

SUB MID Aggregator может использоваться в routing разными merchants, но создавать и подключать его может только platform user.

6.6. Platform / Audit Logs ​

Назначение:

Platform user расследует изменения в системе.

Filters:

  • entity type;
  • entity ID;
  • actor;
  • action;
  • date;
  • merchant, where applicable;
  • brand, where applicable.

List columns:

  • date;
  • actor;
  • action;
  • entity type;
  • entity ID;
  • merchant, where applicable;
  • summary.

Details:

  • old values;
  • new values;
  • request metadata;
  • IP;
  • user agent;
  • correlation/trace reference, if available.

Secret values must not be visible.

7. Merchant Section Pages ​

7.1. Merchant / Transactions ​

Same UX as Transaction List, but merchant-scoped.

Merchant user sees only:

  • transactions for merchants/merchant groups where user has access;
  • fields allowed by permissions;
  • merchant-safe provider/routing data.

7.2. Merchant / Payment Method / MID ​

Назначение:

User manages merchant payment method configuration and first-level routing.

List behavior:

  • page shows Payment Method / MID configurations for all merchants available to user;
  • merchant selector/filter is available on the page;
  • if user does not filter by merchant, table shows all accessible merchants with pagination;
  • create flow requires selecting merchant;
  • platform user also uses this Merchant section page and selects merchant in create flow.

List columns:

  • merchant name;
  • name;
  • payment method;
  • status;
  • created;
  • updated.

Payment method examples:

  • Cards;
  • Apple Pay;
  • Google Pay;
  • Sofort Uber;
  • BLIK;
  • Skrill Quick Checkout or other concrete method names.

APM as generic method name should not be used in UI.

Actions:

  • create Payment Method / MID;
  • open details;
  • edit basic fields;
  • create draft routing;
  • publish routing;
  • disable;
  • soft-delete.

Details tabs:

  • Overview;
  • Routing Blueprint;
  • Linked MASTER MID;
  • Versions;
  • Audit Logs.

Overview fields:

  • merchant;
  • name;
  • method;
  • status.

Create required fields:

  • merchant;
  • name;
  • method;
  • status.

method cannot be changed after creation.

If Payment Method / MID does not have valid published routing, UI must not allow status ACTIVE.

After successful creation, user is redirected to Payment Method / MID details.

Linked MASTER MID tab:

  • shows MASTER MID connected through first-level routing;
  • does not replace Routing Blueprint;
  • provides quick navigation to related MASTER MID details where user has access.

Payment Method / MID disable behavior:

  • new deposits with this paymentMethodId are rejected before transaction creation;
  • existing transactions continue processing.

Routing Blueprint:

  • first-level Routing Rules;
  • target MASTER MID GROUP;
  • MASTER MIDs inside group;
  • group selection strategy;
  • sequence/weights;
  • fallback enabled/disabled.

Merchant user may edit first-level routing if permission allows.

7.3. Merchant / MASTER MID ​

Назначение:

User manages merchant-scoped MASTER MID and second-level routing where allowed.

List behavior:

  • page shows MASTER MID for all merchants available to user;
  • merchant selector/filter is available on the page;
  • if user does not filter by merchant, table shows all accessible merchants with pagination;
  • create flow requires selecting merchant;
  • platform user also uses this Merchant section page and selects merchant in create flow.

List columns:

  • merchant name;
  • name;
  • payment method;
  • status;
  • created by;
  • created;
  • updated.

Actions:

  • create MASTER MID;
  • open details;
  • edit basic fields;
  • configure processing fee;
  • create/edit second-level routing draft;
  • publish routing;
  • disable;
  • soft-delete.

Details tabs:

  • Overview;
  • Processing Fee;
  • Routing Blueprint;
  • Linked SUB MID;
  • Used in Payment Methods;
  • Versions;
  • Audit Logs.

Create required fields:

  • merchant;
  • name;
  • payment method;
  • status.

After successful creation, user is redirected to MASTER MID details.

MASTER MID can be created without second-level routing blueprint, but it cannot be used for successful processing until valid routing is published.

If MASTER MID does not have valid published routing, UI must not allow status ACTIVE.

Processing Fee is configured after creation in Processing Fee tab.

Used in Payment Methods tab:

  • shows Payment Method / MID configurations where this MASTER MID is connected;
  • shows MASTER MID GROUP context where available;
  • provides navigation to linked Payment Method / MID details.

Linked SUB MID tab:

  • shows SUB MID / SUB MID AGGREGATOR connected through second-level routing, according to user visibility;
  • provides navigation to linked SUB MID details where user has access.

MASTER MID disable behavior:

  • new routing attempts skip it and use fallback;
  • existing transactions continue processing.

MASTER MID soft-delete behavior:

  • soft-delete is allowed even if MASTER MID is used in published routing;
  • before soft-delete, UI must show warning that MASTER MID is used in listed Payment Method / MID configurations;
  • user can still confirm soft-delete if permission allows;
  • runtime skips deleted MASTER MID through fallback.

If MASTER MID was created by platform user and hidden from merchant user:

  • merchant user may see high-level entity reference if needed;
  • merchant user must not see internal blueprint;
  • merchant user must not see SUB MID / provider internals.

7.4. Merchant / SUB MID ​

Назначение:

User manages merchant-scoped provider execution configuration, if provider access and permissions allow.

List behavior:

  • page shows SUB MID for all merchants available to user;
  • merchant selector/filter is available on the page;
  • if user does not filter by merchant, table shows all accessible merchants with pagination;
  • create flow requires selecting merchant;
  • platform user also uses this Merchant section page and selects merchant in create flow.

List columns:

  • merchant name;
  • name;
  • provider, only if visible;
  • provider method, only if visible;
  • payment method;
  • status;
  • created by;
  • created;
  • updated.

If merchant does not have provider visibility:

  • provider real name is hidden;
  • sensitive config is hidden;
  • entity can appear as blackbox/reference where needed.

Details tabs:

  • Overview;
  • Credentials / Config;
  • Velocity Limits;
  • FX / Conversion Fee;
  • Expiration;
  • Email Replacement;
  • Linked MASTER MID;
  • Audit Logs.

Create required fields:

  • merchant;
  • name;
  • provider;
  • provider method;
  • status;
  • required credentials/config.

Provider method is selected from code registry after provider selection.

If required config/credentials are missing, save must be blocked by validation error.

Linked MASTER MID tab:

  • shows MASTER MID / SUB MID GROUP where this SUB MID is used;
  • provides navigation to linked MASTER MID details where user has access.

Actions:

  • create SUB MID, if provider access exists;
  • edit non-secret config;
  • replace secrets;
  • configure velocity;
  • configure FX/conversion fee;
  • configure expiration time;
  • configure fake email generation;
  • disable;
  • soft-delete.

SUB MID disable behavior:

  • routing skips it and tries fallback;
  • existing transactions continue processing.

7.5. Merchant / Brands ​

Назначение:

Merchant user manages brands under merchant context.

List columns:

  • name;
  • status;
  • domain;
  • created;
  • updated.

Actions:

  • create brand;
  • edit brand;
  • disable;
  • soft-delete.

Brand fields:

  • name;
  • status;
  • legal name;
  • domain.

brandId is always required in deposit request. Brand styling customization is not part of MVP, but brand context is required for hosted payment page.

Details tabs:

  • Overview;
  • Transactions;
  • Audit Logs.

7.6. Merchant / Users ​

Назначение:

Merchant admin user invites and manages users inside allowed merchant context.

Merchant Users page shows users in accessible merchant context. Merchant user can invite only merchant users.

List columns:

  • email;
  • first name;
  • last name;
  • status;
  • merchants/access;
  • created;
  • updated.

Actions:

  • invite user;
  • assign merchant role in allowed merchant context;
  • remove access;
  • resend invite if expired;
  • soft-delete user access where allowed.

Merchant user cannot:

  • create platform users;
  • grant merchant group access;
  • edit role permissions;
  • assign roles outside allowed context.

Merchant user can manage only merchants where this user has permission to manage users.

Invite flow:

  • admin enters email, first name and last name;
  • system sends email invite link;
  • invited user sets password;
  • invited user sets up 2FA.

Duplicate invite or existing email returns error. Expired invite has Resend invite action. Invite cancel status/action is not required in MVP.

7.7. Merchant / Roles ​

Назначение:

Merchant user can view roles available for assignment.

MVP behavior:

  • view-only;
  • no permission editing;
  • no role creation by merchant users.

List columns:

  • role name;
  • status;
  • assignable marker.

7.8. Merchant / API Keys ​

Назначение:

User with permission manages merchant API key in selected merchant context.

This page is used by:

  • merchant user with permission in allowed merchant context;
  • platform user with permission for any selected merchant.

Rules:

  • API key is merchant-level, not brand-level;
  • one active API key per merchant;
  • key is secret for request signing;
  • after creation, secret is shown once;
  • after page is closed, secret cannot be viewed again;
  • rotation can keep previous key valid for grace period.

Grace period options:

  • 1 hour;
  • 3 hours;
  • 12 hours;
  • 24 hours.

Sensitive actions require OTP:

  • create key;
  • rotate key;
  • revoke key.

Actions:

  • create API key;
  • rotate API key;
  • revoke API key.

If platform user creates or rotates API key for merchant, the secret is shown once, same as for merchant user.

List/details should show:

  • key identifier;
  • created;
  • last rotated;
  • status;
  • grace period if rotation in progress.

7.9. Merchant / Webhooks ​

Назначение:

User sees merchant webhook deliveries.

Important:

Webhook URLs are provided in transaction request. There is no global webhook URL setup in MVP.

List columns:

  • transaction ID;
  • event/status;
  • webhook URL;
  • delivery status;
  • attempts;
  • last attempt at;
  • response status.

Filters:

  • merchant;
  • brand;
  • transaction ID;
  • delivery status;
  • date.

Actions:

  • open delivery details;
  • resend webhook, if permission and status allows.

Details:

  • request payload;
  • response code;
  • response body;
  • attempts history;
  • next retry, if applicable.

7.10. Merchant / Audit Logs ​

Назначение:

Merchant user sees audit logs for accessible entities.

Visibility:

  • only accessible merchant-scoped entities;
  • no provider secrets;
  • no hidden provider internals;
  • no platform-only operational details.

Filters:

  • entity type;
  • entity ID;
  • actor;
  • action;
  • date.

7.11. Internal Admin / Migration Tool ​

Migration Tool is a temporary MVP/internal tool.

Access:

  • platform user with can_run_legacy_transaction_migration.

Migration Tool should be an internal admin tool. It should not be shown as a normal Platform section page. It should not be a merchant self-service feature.

Input:

  • old merchantId;
  • old merchantConfigId;
  • new brandId;
  • new paymentMethodId.

Behavior:

  • migrates historical transactions only;
  • marks transactions as legacy;
  • migrated transactions are read-only;
  • no webhooks are sent;
  • generates immediate report;
  • no long-term separate migration audit log required.

8. Empty States ​

Required empty states:

  • no transactions yet;
  • no merchants yet;
  • no brands yet;
  • no payment methods yet;
  • no users yet;
  • no API key yet;
  • no webhook deliveries yet;
  • no audit logs yet;
  • user has no merchant access;
  • user has no data for selected filters.

Default empty copy can be:

text
No data yet

Design/content team can improve copy per page.

9. Required Confirmation Dialogs ​

Confirmation is required for:

  • soft-delete entity;
  • disable entity;
  • API key creation;
  • API key rotation;
  • API key revoke;
  • manual transaction correction;
  • resend webhook;
  • publish routing/configuration draft;
  • remove user access;
  • reset 2FA;
  • password reset by admin, if supported.

Sensitive confirmations may require OTP.

10. MVP Design Deliverables ​

Design team should prepare:

  • auth/login/2FA/invite/password reset screens;
  • first admin setup screen;
  • global Back Office layout;
  • transaction list;
  • transaction details;
  • routing blueprint editor;
  • merchant list/details;
  • brand list/details;
  • payment method list/details;
  • MASTER MID list/details;
  • SUB MID list/details;
  • SUB MID Aggregator list/details;
  • user management;
  • role management;
  • API keys;
  • webhook deliveries;
  • audit logs;
  • internal migration tool;
  • profile/sessions.

11. Open Questions ​

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

Зафиксированные решения:

  1. Naming approved: Payment Orchestrator, payment-orchestrator, Orchestrator Service.
  2. Migration Tool является internal admin tool, а не обычной Platform page.
  3. Comments / Notes не входят в MVP.
  4. Provider Access отображается как tab внутри Merchant Details.
  5. Transaction List default columns остаются как описано в этом документе.
  6. Merchant Details является platform-only page.
  7. Merchant Details не дублирует CRUD flows из Merchant section pages.
  8. Brands, API Keys, Payment Method / MID, Users/Access редактируются через соответствующие Merchant section pages.
  9. Transactions and Payment Methods tabs inside Merchant Details are navigation/overview only.
  10. Merchant Details Audit Logs tab shows merchant entity audit events only.
  11. Payment Method / MID list shows all accessible merchants by default with pagination.
  12. Payment Method / MID create flow requires merchant selection.
  13. Payment Method / MID details contains Linked MASTER MID tab.
  14. Payment Method / MID cannot be set to ACTIVE without valid published routing.
  15. Routing draft changes autosave; publish requires explicit action and comment/reason.
  16. MASTER MID GROUP is created inside blueprint and does not require user-defined name.
  17. MASTER MID must be created on MASTER MID page, not from Payment Method / MID blueprint modal.
  18. Payment Method / MID export/list behavior must keep merchant name visible as a table column.
  19. MASTER MID list shows all accessible merchants by default with pagination.
  20. MASTER MID create flow requires merchant selection and redirects to details.
  21. MASTER MID cannot be set to ACTIVE without valid published routing.
  22. MASTER MID details contains Linked SUB MID and Used in Payment Methods tabs.
  23. MASTER MID soft-delete is allowed even if used in published routing, after warning.
  24. SUB MID list shows all accessible merchants by default with pagination.
  25. SUB MID create flow requires merchant, provider, provider method, status and required credentials/config.
  26. SUB MID save is blocked if required credentials/config are missing.
  27. SUB MID details contains Linked MASTER MID tab.
  28. SUB MID Aggregator remains Platform section only.
  29. SUB MID and SUB MID Aggregator use same model with aggregator: true/false.
  30. SUB MID GROUP is created inside MASTER MID blueprint and does not require user-defined name.
  31. Merchant user cannot add SUB MID Aggregator to SUB MID GROUP.
  32. Platform user can add SUB MID and SUB MID Aggregator to SUB MID GROUP.
  33. Platform Users page can create platform users and merchant users.
  34. Merchant Users page can invite only merchant users.
  35. Merchant access requires merchant role in context of one merchant.
  36. Merchant group access is access scope only and has no merchant role assignment in MVP.
  37. Merchant group access can be granted only by platform user.
  38. Merchant admin can assign only merchant roles marked assignable by platform.
  39. Roles and permissions are created/edited only by platform users.
  40. First platform Admin role and default merchant admin role are created automatically.

Design follow-up:

  1. Определить exact responsive layout.
  2. Определить table density and column customization UX.
  3. Определить visual style for hidden/blackbox routing entities.
  4. Определить confirmation modal patterns.
  5. Определить empty/access denied state UI.

Technical follow-up:

  1. Development team должна определить API endpoints/read models для каждой page.
  2. Development team должна определить authorization checks per action.
  3. Development team должна определить table indexing/search strategy.
  4. Development team должна определить export implementation.
  5. Development team должна определить audit log query model.