05.08 MASTER MID And MASTER MID GROUP

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

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

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

MASTER MID является центральной сущностью между:

first-level Payment Method / MID routing;
second-level internal routing to SUB MID GROUP;
processing fee;
merchant/platform visibility rules.

2. MASTER MID ownership

MASTER MID создается только под конкретного merchant.

MASTER MID не является global/reusable сущностью.

Один MASTER MID принадлежит одному merchant.

MASTER MID может использоваться в нескольких Payment Method / MID configurations этого merchant-а, если method compatibility позволяет.

3. Где управлять MASTER MID

Рекомендуемая продуктовая модель:

MASTER MID управляется в Merchant section, потому что он всегда принадлежит конкретному merchant.

Platform user тоже управляет MASTER MID через merchant context.

Отдельная глобальная вкладка MASTER MID в Platform section в MVP не нужна.

Причина:

MASTER MID не существует без merchant;
visibility зависит от merchant context;
merchant user потенциально может создавать MASTER MID, если ему выдан provider access;
platform user может создать hidden/internal MASTER MID в context merchant;
один и тот же UI может работать для platform и merchant users с разными visibility rules.

4. Кто может создавать MASTER MID

MASTER MID может создать:

platform user с permission в context конкретного merchant;
merchant user с permission, если ему выдан provider access и разрешено создавать provider-related configuration.

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

merchant имеет provider access;
user имеет permission создавать MASTER MID;
user имеет permission управлять provider-related configuration, если внутри MASTER MID нужно создавать SUB MID.

Если MASTER MID создает platform user:

merchant user может видеть только high-level информацию, если MASTER MID доступен для routing;
merchant user не видит internal blueprint MASTER MID;
merchant user не видит SUB MID GROUP / SUB MID / provider internals, если это hidden configuration.

Если MASTER MID создает merchant user:

merchant user может видеть и редактировать MASTER MID в рамках permissions;
merchant user может создавать внутри него SUB MID GROUP;
merchant user может создавать/подключать SUB MID, если у него есть provider access;
platform user с permission видит полную configuration.

5. MASTER MID fields

Минимальные fields MASTER MID:

id;
merchantId;
name;
status;
method;
created by;
createdByType: platform / merchant;
created at;
updated at.

MASTER MID всегда привязан к одному method.

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

Processing fee относится к MASTER MID.

Processing fee может быть пустой.

MASTER MID можно создать без processing fee.

Если processing fee настроена, все transactions, которые проходят через MASTER MID, должны получить processing fee according to its configuration.

Processing fee оплачивает merchant.

Processing fee может быть tiered by MASTER MID turnover.

Thresholds задаются в EUR, например:

text

0 - 100,000 EUR
100,000 - 1,000,000 EUR
1,000,000 EUR - infinity

Для каждого threshold могут быть свои fixed/percent/min/max values.

Threshold turnover считается за календарный месяц и включает только COMPLETED transactions.

Tier для конкретной transaction выбирается перед provider request на основании turnover до этой transaction.

Current transaction amount не учитывается при выборе ее собственного tier.

Детальная модель processing fee описывается в FX / Fees document.

MASTER MID содержит second-level routing blueprint.

MASTER MID blueprint может быть пустым draft, но published MASTER MID routing должен иметь valid path to SUB MID GROUP with execution candidates.

MASTER MID может быть создан без published routing blueprint.

MASTER MID можно создать без internal routing blueprint.

MASTER MID routing нельзя publish, если внутри нет valid route to SUB MID GROUP.

Create flow requires:

merchant;
name;
payment method / method;
status.

After successful creation, user should be redirected to MASTER MID details.

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

Processing fee is configured after creation in a separate Processing Fee tab.

MASTER MID details should include:

Linked SUB MID tab;
Used in Payment Methods tab.

6. MASTER MID GROUP

MASTER MID GROUP создается внутри Payment Method / MID routing.

MASTER MID GROUP является target для first-level routing rule.

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

MASTER MID GROUP может содержать один или несколько MASTER MID.

MASTER MID GROUP отвечает за выбор MASTER MID внутри группы.

У MASTER MID GROUP нет обязательного name в MVP.

Required settings MASTER MID GROUP:

selectionStrategy;
fallbackEnabled.

7. MASTER MID GROUP selection strategy

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

sequence;
weight.

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

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

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

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

8. MASTER MID GROUP fallback

Fallback внутри MASTER MID GROUP должен поддерживаться.

Fallback включен по default.

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

Если selected MASTER MID inactive или не смог выполнить transaction через свой internal routing, система должна попробовать следующий MASTER MID, если fallback включен.

Если fallback выключен, failed MASTER MID завершает текущий routing path.

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

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

9. Merchant editing rights

Merchant user с permission может менять settings MASTER MID GROUP на first-level routing:

selection strategy;
sequence order;
weights;
fallback on/off.

Merchant user может делать это только для Payment Method / MID configurations и MASTER MID GROUP, доступных в его merchant context.

10. MASTER MID visibility for merchant users

Merchant user может видеть:

MASTER MID GROUP;
MASTER MID name;
MASTER MID status;
MASTER MID GROUP selection strategy;
sequence/weight settings;
fallback settings.

Если MASTER MID создан platform user, merchant user не видит:

internal MASTER MID blueprint;
second-level rules;
SUB MID GROUP;
SUB MID;
SUB MID AGGREGATOR;
provider credentials;
provider raw/internal details.

Если MASTER MID создан merchant user, visibility зависит от permissions и provider access.

11. Inactive MASTER MID

Если MASTER MID inactive/deleted, routing должен пропустить его через fallback.

Поведение:

MASTER MID GROUP выбирает MASTER MID.
Система видит, что MASTER MID inactive/deleted.
Timeline фиксирует skipped inactive/deleted MASTER MID.
Если fallback включен, система пробует следующий MASTER MID.
Если fallback выключен или других MASTER MID нет, routing path failed.

Если после всех fallback paths доступных вариантов нет, transaction получает status:

text

REJECTED

Если MASTER MID находится в status DELETED, historical transactions должны оставаться доступными для просмотра и расследования.

MASTER MID can be soft-deleted even if it is used in published routing.

Before soft-delete, UI must show warning that MASTER MID is used in listed Payment Method / MID configurations.

If user confirms and has permission, soft-delete is allowed.

After soft-delete, runtime skips this MASTER MID through fallback.

12. Reuse inside merchant

Один MASTER MID может использоваться в нескольких Payment Method / MID configurations одного merchant-а.

Но MASTER MID не может использоваться между разными merchants.

Один MASTER MID может быть добавлен в несколько MASTER MID GROUP внутри одного merchant.

Compatibility должна проверяться по method.

Например:

Cards MASTER MID может использоваться в card-related configurations;
Cards MASTER MID не должен подключаться к BLIK configuration, если method несовместим.

13. Timeline

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

MASTER MID GROUP selected;
MASTER MID GROUP selection strategy used;
MASTER MID GROUP exhausted because empty;
MASTER MID selected;
MASTER MID skipped because inactive;
MASTER MID fallback started;
MASTER MID fallback exhausted;
MASTER MID blueprint started;
MASTER MID blueprint failed;
next MASTER MID selected.

Merchant-safe timeline должна скрывать internal blueprint, если MASTER MID platform-created/hidden.

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

14. Audit log

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

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

MASTER MID created;
MASTER MID updated;
MASTER MID status changed;
MASTER MID soft-deleted;
MASTER MID GROUP created;
MASTER MID GROUP updated;
MASTER MID added to group;
MASTER MID removed from group;
selection strategy changed;
sequence changed;
weights changed;
fallback changed;
processing fee changed;
actor;
timestamp;
merchant context.

15. Acceptance Criteria

MASTER MID / MASTER MID GROUP считаются согласованными для MVP, если:

MASTER MID создается только под конкретного merchant.
MASTER MID не является global/reusable entity.
MASTER MID может использоваться в нескольких Payment Method / MID configurations одного merchant-а.
MASTER MID всегда привязан к одному method.
MASTER MID может создать platform user с permission.
MASTER MID может создать merchant user с permission, если ему выдан provider access.
Отдельная глобальная вкладка MASTER MID в Platform section в MVP не нужна.
MASTER MID управляется через merchant context.
MASTER MID required fields: name, method, status, createdByType.
MASTER MID create flow requires merchant, name, payment method/method and status.
After create user is redirected to MASTER MID details.
Method нельзя менять после создания MASTER MID.
Если MASTER MID создан platform user, merchant user не видит internal blueprint.
Если MASTER MID создан merchant user, merchant user может видеть/редактировать его по permissions.
MASTER MID GROUP создается внутри Payment Method / MID routing.
MASTER MID GROUP может быть пустой.
MASTER MID GROUP может содержать один или несколько MASTER MID.
MASTER MID GROUP не требует name в MVP.
MASTER MID GROUP required settings: selectionStrategy, fallbackEnabled.
MASTER MID GROUP поддерживает sequence.
MASTER MID GROUP поддерживает weight.
Weight values могут быть любыми положительными числами и считаются пропорционально.
MASTER MID GROUP fallback поддерживается.
MASTER MID GROUP fallback включен по default.
MASTER MID GROUP fallback можно выключить.
Один MASTER MID может быть добавлен в несколько MASTER MID GROUP внутри одного merchant.
MASTER MID поддерживает processing fee configuration.
Processing fee на MASTER MID может быть пустой.
MASTER MID можно создать без processing fee.
Processing fee is configured after MASTER MID creation.
MASTER MID processing fee поддерживает turnover thresholds.
MASTER MID может быть создан без published routing blueprint.
MASTER MID можно создать без internal routing blueprint.
MASTER MID нельзя сделать ACTIVE без valid published routing.
Published MASTER MID routing должен иметь valid path to SUB MID GROUP with SUB MID / SUB MID AGGREGATOR.
MASTER MID details contains Linked SUB MID tab.
MASTER MID details contains Used in Payment Methods tab.
Merchant user с permission может менять strategy/weight/sequence/fallback на доступном first-level routing.
Inactive/deleted MASTER MID пропускается через fallback.
MASTER MID soft-delete allowed even if used in published routing, after warning.
Deleted MASTER MID сохраняет historical transactions доступными.
Historical transactions показывают MASTER MID GROUP / MASTER MID, через которые они прошли, даже если MASTER MID позже удалили из group.
Если все routing paths failed, transaction становится REJECTED.
Изменения пишутся в audit log.

16. Open Questions

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

Technical/design follow-up:

Описать exact UI для merchant-scoped MASTER MID management.
Описать compatibility validation между MASTER MID method и Payment Method / MID method.
Описать owner type / created by model.
Описать visibility model для platform-created vs merchant-created MASTER MID.
Описать exact behavior для inactive MASTER MID в weighted selection.

05.08 MASTER MID And MASTER MID GROUP ​

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

2. MASTER MID ownership ​

3. Где управлять MASTER MID ​

4. Кто может создавать MASTER MID ​

5. MASTER MID fields ​

6. MASTER MID GROUP ​

7. MASTER MID GROUP selection strategy ​

8. MASTER MID GROUP fallback ​

9. Merchant editing rights ​

10. MASTER MID visibility for merchant users ​

11. Inactive MASTER MID ​

12. Reuse inside merchant ​

13. Timeline ​

14. Audit log ​

15. Acceptance Criteria ​

16. Open Questions ​