Payment Orchestrator

Тема

05.11 SUB MID AGGREGATOR ​

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

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

Этот документ описывает SUB MID AGGREGATOR.

SUB MID AGGREGATOR - это reusable platform-level provider method configuration, которую platform users могут использовать в routing разных merchants.

По сути, SUB MID и SUB MID AGGREGATOR имеют одинаковую provider execution модель. Разница в ownership, scope and visibility.

2. Core model ​

Product-level difference:

text
SUB MID: aggregator = false
SUB MID AGGREGATOR: aggregator = true

Это означает:

  • SUB MID создается под конкретного merchant;
  • SUB MID AGGREGATOR является global/reusable configuration;
  • SUB MID AGGREGATOR создается только platform user-ом;
  • SUB MID AGGREGATOR может быть подключен в разные merchants / разные MASTER MID;
  • merchant user не может создавать, редактировать или самостоятельно подключать SUB MID AGGREGATOR.

3. Scope ​

SUB MID AGGREGATOR всегда global.

Он не ограничивается конкретным merchant.

Ограничения по использованию в routing должны контролироваться:

  • permissions;
  • platform user decisions;
  • compatibility validation;
  • method compatibility.

В MVP не нужно делать отдельную модель “aggregator allowed merchants”.

4. Required fields ​

Required fields такие же, как у SUB MID:

  • name;
  • provider;
  • provider method;
  • method;
  • status;
  • credentials/config;
  • createdByType.

Technical/system fields:

  • id;
  • aggregator = true;
  • created by;
  • created at;
  • updated at.

provider и provider method нельзя изменить после создания SUB MID AGGREGATOR.

Если нужно использовать другой provider или другой provider method, platform user должен создать новый SUB MID AGGREGATOR и подключить его в routing.

SUB MID AGGREGATOR нельзя создать без required credentials/config.

SUB MID AGGREGATOR нельзя сохранить как inactive, если required provider config / credentials fields не заполнены.

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

Provider method is selected from code registry after provider selection.

5. Configurable settings ​

SUB MID AGGREGATOR должен поддерживать те же configurable settings, что и SUB MID:

  • method-specific secret/settings fields;
  • expiration time;
  • email replacement / fake email generation;
  • velocity limits;
  • FX / conversion fee;
  • callback validation settings, если применимо.

Эти settings не являются отдельными mandatory fields для каждого aggregator, но модель и UI должны их поддерживать.

Это правило не относится к required provider credentials/config fields.

Required provider credentials/config fields обязательны при создании SUB MID AGGREGATOR.

6. Processing fee ​

Processing fee не настраивается на SUB MID AGGREGATOR.

Processing fee настраивается только на:

text
MASTER MID

SUB MID AGGREGATOR может иметь FX / conversion fee, потому что это относится к provider execution and customer amount conversion.

7. Usage in routing ​

Platform user может подключить один SUB MID AGGREGATOR:

  • в разных merchants;
  • в разных MASTER MID;
  • в разные SUB MID GROUP;
  • рядом с обычными SUB MID внутри одной SUB MID GROUP.

Если SUB MID AGGREGATOR inactive:

  1. Routing не отправляет request через него.
  2. Timeline фиксирует skipped/inactive aggregator.
  3. Если fallback внутри SUB MID GROUP включен, система пробует следующий candidate.
  4. Если candidates закончились, SUB MID GROUP failed.

Если SUB MID AGGREGATOR переведен в DELETED:

  • это soft-delete;
  • реальные записи не удаляются из базы;
  • aggregator не используется для новых provider requests;
  • historical transactions остаются доступными;
  • transaction details должны показывать execution snapshot, который был использован на момент выполнения transaction.

Existing transactions continue processing after SUB MID AGGREGATOR is disabled or soft-deleted.

SUB MID AGGREGATOR details should include Usage / Linked Routing tab showing where it is used.

8. Merchant visibility ​

Merchant user не должен видеть SUB MID AGGREGATOR как отдельную сущность внутри SUB MID GROUP.

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

  • что конкретно подключен SUB MID AGGREGATOR;
  • provider name;
  • credentials/config;
  • internal provider settings;
  • raw provider details;
  • platform-only configuration.

Merchant-facing UI должен скрывать эту часть routing полностью или показывать только high-level route без раскрытия execution candidate.

Если transaction прошла через SUB MID AGGREGATOR, merchant-safe timeline не должен раскрывать aggregator details.

9. Credentials/config visibility and editing ​

Secret fields при создании SUB MID AGGREGATOR показываются как обычные inputs.

После сохранения secret values шифруются и больше никогда не раскрываются.

Старые secret values не показываются при редактировании.

Secret можно только заменить новым введенным значением.

Non-secret config fields можно повторно открыть, увидеть и отредактировать, если platform user имеет permission.

Credentials/config SUB MID AGGREGATOR может видеть/изменять только platform user с permissions:

  • can_view_sub_mid_aggregator_credentials;
  • can_edit_sub_mid_aggregator_credentials.

Merchant user не видит credentials/config SUB MID AGGREGATOR.

Credentials/config должны иметь version/history.

Historical transaction должна ссылаться на credentials/config version, которая использовалась во время provider execution.

Historical transaction не должна раскрывать secret values.

Rollback credentials/config к старой version в MVP не нужен.

OTP / 2FA confirmation для изменения SUB MID AGGREGATOR credentials/config в MVP не нужен.

Audit logs, exports и system logs не должны хранить old/new secret values ни в открытом, ни в masked, ни в encrypted виде.

10. Historical execution snapshot ​

При provider execution система должна сохранить snapshot использованной SUB MID AGGREGATOR configuration.

Snapshot нужен, чтобы historical transaction оставалась понятной даже если после этого:

  • aggregator был удален через soft-delete;
  • credentials/config были изменены;
  • aggregator был отключен;
  • aggregator был удален из SUB MID GROUP;
  • routing blueprint был переопубликован.

Минимальный snapshot:

  • SUB MID AGGREGATOR id;
  • SUB MID AGGREGATOR name;
  • aggregator = true;
  • provider;
  • provider method;
  • method;
  • version/config version used, если используется versioning;
  • masked credentials/config reference;
  • applied expiration time;
  • applied email replacement flag;
  • applied velocity limits reference;
  • applied FX/conversion fee reference.

Merchant user не должен видеть provider-sensitive snapshot fields.

11. Audit log ​

На странице SUB MID AGGREGATOR details должна быть вкладка audit logs, как и на других изменяемых сущностях.

Audit log должен фиксировать:

  • aggregator created;
  • aggregator updated;
  • status changed;
  • credentials/config updated;
  • expiration time changed;
  • email replacement setting changed;
  • velocity limits changed;
  • FX/conversion fee changed;
  • aggregator connected to routing;
  • aggregator removed from routing;
  • aggregator soft-deleted;
  • actor;
  • timestamp.

Sensitive fields не должны храниться в audit log в открытом виде.

provider и provider method не должны попадать в audit log как changed fields, потому что они immutable после создания.

12. Acceptance Criteria ​

SUB MID AGGREGATOR считается согласованным для MVP, если:

  • Создается только platform user-ом.
  • Всегда global/reusable.
  • Использует ту же provider execution модель, что SUB MID.
  • Отличается от SUB MID атрибутом aggregator = true.
  • Required fields: name, provider, provider method, method, status, credentials/config, createdByType.
  • Provider method is selected from code registry after provider selection.
  • SUB MID AGGREGATOR нельзя создать без required credentials/config.
  • Save is blocked if required credentials/config are missing.
  • SUB MID AGGREGATOR нельзя сохранить inactive, если required credentials/config не заполнены.
  • provider нельзя изменить после создания SUB MID AGGREGATOR.
  • provider method нельзя изменить после создания SUB MID AGGREGATOR.
  • Поддерживает те же configurable settings, что SUB MID.
  • Может быть подключен в разные merchants / MASTER MID / SUB MID GROUP.
  • Merchant user не видит SUB MID AGGREGATOR как отдельную сущность внутри SUB MID GROUP.
  • Merchant user не видит provider/internal details SUB MID AGGREGATOR.
  • Inactive SUB MID AGGREGATOR пропускается через fallback.
  • Existing transactions continue processing after SUB MID AGGREGATOR disable.
  • DELETED SUB MID AGGREGATOR является soft-delete.
  • SUB MID AGGREGATOR можно soft-delete даже если по нему есть transactions.
  • Historical transactions показывают execution snapshot, даже если SUB MID AGGREGATOR удален или credentials/config изменены.
  • Secret values шифруются и не раскрываются после сохранения.
  • Secret можно только заменить новым введенным значением.
  • Non-secret config fields можно повторно открыть после сохранения, если platform user имеет permission.
  • Merchant user не видит credentials/config SUB MID AGGREGATOR.
  • Credentials/config имеют version/history.
  • Historical transaction ссылается на credentials/config version used.
  • Historical transaction не раскрывает secret values.
  • Rollback credentials/config к старой version в MVP не нужен.
  • OTP / 2FA confirmation для изменения SUB MID AGGREGATOR credentials/config не нужен.
  • Audit log не хранит old/new secret values.
  • Processing fee не настраивается на SUB MID AGGREGATOR.
  • Processing fee существует только на MASTER MID.
  • SUB MID AGGREGATOR details содержит audit logs tab.
  • SUB MID AGGREGATOR details содержит Usage / Linked Routing tab.

13. Open Questions ​

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

Technical/design follow-up:

  1. Определить exact shared table/model для SUB MID and SUB MID AGGREGATOR.
  2. Определить exact UI labels: SUB MID AGGREGATOR vs internal aggregator=true.
  3. Определить compatibility validation для подключения aggregator в MASTER MID / SUB MID GROUP.