Payment Orchestrator

Тема

05.09 SUB MID GROUP ​

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

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

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

SUB MID GROUP является execution group внутри MASTER MID blueprint.

SUB MID GROUP нужна, чтобы сгруппировать execution candidates:

  • SUB MID;
  • SUB MID AGGREGATOR.

2. Где создается SUB MID GROUP ​

SUB MID GROUP создается внутри MASTER MID blueprint.

SUB MID GROUP не является самостоятельной global entity.

SUB MID GROUP принадлежит конкретному MASTER MID.

В Back Office SUB MID GROUP создается на странице MASTER MID под merchant.

3. Что может содержать SUB MID GROUP ​

SUB MID GROUP может содержать:

  • SUB MID;
  • SUB MID AGGREGATOR;
  • SUB MID и SUB MID AGGREGATOR одновременно.

SUB MID GROUP может быть пустой.

Это позволяет в одном routing path использовать:

  • merchant-specific provider configurations;
  • platform-level reusable provider configurations;
  • mixed execution candidates.

4. Selection strategy ​

SUB MID GROUP должна поддерживать selection strategies:

  • sequence;
  • weight.

sequence означает, что SUB MID / SUB MID AGGREGATOR выбираются по заданному порядку.

weight означает, что execution candidate выбирается по configured weight distribution.

Для weight strategy weights могут быть любыми положительными числами.

Сумма weights не обязана быть 100. Система должна считать распределение как пропорцию от суммы заданных weights.

5. Fallback ​

Fallback внутри SUB MID GROUP должен быть включен по default.

Fallback можно включать/выключать, если user имеет permission редактировать SUB MID GROUP settings.

Если выбранный SUB MID / SUB MID AGGREGATOR не может выполнить transaction, система пробует следующий candidate внутри этой же SUB MID GROUP, если fallback включен.

Fallback triggers:

  • provider error;
  • provider timeout;
  • velocity exceeded;
  • SUB MID inactive;
  • SUB MID AGGREGATOR inactive;
  • missing provider execution capability;
  • other execution failure.

6. Кто может создавать SUB MID GROUP ​

Merchant user может создавать SUB MID GROUP только внутри MASTER MID, к которому у него есть full access.

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

  • MASTER MID был создан этим merchant user / merchant-side context;
  • user имеет permission управлять MASTER MID blueprint;
  • user имеет provider access, если внутри group создаются/подключаются SUB MID.

Platform user с permission может создавать SUB MID GROUP внутри MASTER MID в context merchant.

Если MASTER MID создан platform user и hidden from merchant, merchant user не может создавать или редактировать SUB MID GROUP внутри него.

В MVP основной flow: SUB MID GROUP обычно создает platform user внутри platform-created MASTER MID.

Merchant user can add SUB MID candidate only if:

  • SUB MID was created under this merchant;
  • SUB MID is visible to this merchant user;
  • user has required permissions.

Merchant user cannot add SUB MID AGGREGATOR to SUB MID GROUP.

Platform user with permission can add both SUB MID and SUB MID AGGREGATOR.

7. Visibility для merchant users ​

Если SUB MID GROUP содержит platform-created SUB MID AGGREGATOR, merchant user не должен видеть его как отдельную entity внутри group.

Merchant-facing UI должен скрывать эту часть execution configuration.

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

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

Если SUB MID / SUB MID GROUP созданы merchant user-ом и user имеет permissions, он может видеть и редактировать их details.

8. Fields ​

SUB MID GROUP не требует отдельного name в MVP.

SUB MID GROUP не имеет status.

Минимальные technical fields:

  • id;
  • masterMidId;
  • selectionStrategy;
  • fallbackEnabled;
  • order/position in blueprint;
  • candidates list;
  • created at;
  • updated at.

fallback enabled default:

text
true

9. No status behavior ​

Так как SUB MID GROUP не имеет status, ее нельзя сделать inactive целиком.

Routing не должен проверять SUB MID GROUP inactive.

Если group не может выполнить transaction, это происходит из-за состояния candidates внутри group:

  • все SUB MID inactive;
  • все SUB MID AGGREGATOR inactive;
  • velocity exceeded;
  • provider errors/timeouts;
  • candidates отсутствуют или невалидны.

Если SUB MID GROUP пустая, runtime routing считает group exhausted.

Если это возможно, система продолжает fallback flow. Если fallback path недоступен, transaction получает REJECTED.

10. All candidates failed ​

Если все SUB MID / SUB MID AGGREGATOR внутри SUB MID GROUP failed:

  1. Текущий MASTER MID считается failed для этой transaction.
  2. Система возвращается на уровень MASTER MID GROUP.
  3. Система проверяет, включен ли fallback на уровне MASTER MID GROUP.
  4. Если fallback включен и есть следующий MASTER MID, система пробует следующий MASTER MID.
  5. Если fallback выключен или следующего MASTER MID нет, routing path exhausted.
  6. Если других доступных routing paths нет, transaction становится:
text
REJECTED

Система не возвращается к поиску другого rule внутри того же MASTER MID blueprint после полного failure SUB MID GROUP.

11. Dynamic attributes ​

При выборе SUB MID GROUP система должна определить required attributes для всех candidates внутри group.

Hosted payment form должна дособрать все missing customer attributes, которые могут понадобиться любому SUB MID / SUB MID AGGREGATOR в этой group.

Это нужно, чтобы при fallback внутри SUB MID GROUP не запрашивать customer attributes повторно.

12. Timeline ​

Transaction timeline должна фиксировать:

  • SUB MID GROUP selected;
  • SUB MID GROUP selection strategy used;
  • SUB MID GROUP exhausted because empty;
  • SUB MID selected;
  • SUB MID AGGREGATOR selected;
  • SUB MID skipped;
  • SUB MID AGGREGATOR skipped;
  • fallback inside SUB MID GROUP started;
  • candidate failed reason;
  • all candidates failed;
  • current MASTER MID failed because SUB MID GROUP exhausted;
  • returned to MASTER MID GROUP fallback.

Merchant-safe timeline должна скрывать provider-sensitive details.

Если SUB MID был удален из group после выполнения historical transaction, transaction details/timeline все равно должны показывать, через какую SUB MID GROUP и SUB MID transaction прошла.

13. Audit log ​

Изменения SUB MID GROUP должны попадать в audit log.

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

  • SUB MID GROUP created;
  • SUB MID GROUP updated;
  • candidate added;
  • candidate removed;
  • candidate order changed;
  • weight changed;
  • selection strategy changed;
  • fallback changed;
  • actor;
  • timestamp;
  • MASTER MID context;
  • merchant context.

14. Acceptance Criteria ​

SUB MID GROUP считается согласованной для MVP, если:

  • SUB MID GROUP создается внутри MASTER MID blueprint.
  • SUB MID GROUP создается на странице MASTER MID под merchant.
  • SUB MID GROUP принадлежит конкретному MASTER MID.
  • SUB MID GROUP может содержать SUB MID.
  • SUB MID GROUP может содержать SUB MID AGGREGATOR.
  • SUB MID GROUP может содержать SUB MID и SUB MID AGGREGATOR одновременно.
  • SUB MID GROUP может быть пустой.
  • SUB MID GROUP может быть published пустой.
  • SUB MID GROUP поддерживает sequence.
  • SUB MID GROUP поддерживает weight.
  • Weight values могут быть любыми положительными числами и считаются пропорционально.
  • Fallback внутри SUB MID GROUP включен по default.
  • Fallback внутри SUB MID GROUP можно выключить.
  • Merchant user может создавать SUB MID GROUP только внутри MASTER MID, к которому имеет full access.
  • Merchant user can add visible merchant SUB MID candidates.
  • Merchant user cannot add SUB MID AGGREGATOR.
  • Platform user can add SUB MID and SUB MID AGGREGATOR.
  • Основной MVP flow: SUB MID GROUP создает platform user.
  • Если SUB MID GROUP содержит platform-created SUB MID AGGREGATOR, merchant user не видит его как отдельную entity.
  • SUB MID GROUP не имеет name в MVP.
  • SUB MID GROUP не имеет status.
  • SUB MID GROUP required settings: selectionStrategy, fallbackEnabled.
  • Один SUB MID может быть добавлен в несколько SUB MID GROUP внутри одного merchant.
  • Если все candidates failed, система возвращается на уровень MASTER MID GROUP fallback.
  • Если доступных MASTER MID больше нет, transaction становится REJECTED.
  • Timeline фиксирует SUB MID GROUP selection/fallback/failure events.
  • Historical transactions показывают SUB MID GROUP / SUB MID, через которые они прошли, даже если SUB MID позже удалили из group.
  • Изменения SUB MID GROUP пишутся в audit log.

15. Open Questions ​

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

Technical/design follow-up:

  1. Описать behavior для weighted selection when candidate inactive.
  2. Описать exact timeline event names.