Payment Orchestrator

Тема

05.12 Provider Access ​

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

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

Этот документ описывает Provider Access для merchant.

Provider Access нужен, чтобы управлять тем, какие реальные providers merchant может использовать в self-service сценариях.

По умолчанию реальные provider names и provider details скрыты от merchant users.

2. Core rule ​

Provider Access выдается на уровне:

text
Merchant -> Provider

Provider Access не выдается:

  • на уровне brand;
  • на уровне merchant group;
  • на уровне конкретного user;
  • на уровне provider method.

Если merchant получил доступ к provider, то merchant users с нужными permissions в context этого merchant могут использовать этот provider при создании SUB MID.

3. Provider scope ​

Provider Access выдается к конкретному provider.

Примеры:

text
Merchant A -> INTERKASSA
Merchant A -> JETON
Merchant B -> SKRILL

Доступ к одному provider не означает доступ ко всем providers.

Если merchant получил access к provider, он сразу видит все provider methods этого provider, которые доступны в системе.

Под доступными provider methods понимаются только methods, реализованные в code registry / provider adapter.

Отдельно выдавать access к provider method в MVP не нужно.

4. Кто может выдавать Provider Access ​

Provider Access может выдать только platform user с permission:

text
can_grant_provider_access_to_merchant

Merchant user не может выдавать Provider Access своему merchant или другим merchants.

Provider Access управляется на странице merchant details.

5. UI behavior ​

Platform UI ​

На странице merchant details должна быть секция или вкладка Provider Access.

Platform user с permission может:

  • посмотреть список providers, к которым merchant имеет access;
  • выдать access к конкретному provider;
  • убрать access к конкретному provider;
  • увидеть audit log изменений.

Merchant UI ​

В Merchant section не нужна отдельная страница Provider Access.

Merchant user видит provider как option только там, где это нужно для действия.

Например, при создании SUB MID в списке provider choices должны появиться только те providers, к которым merchant имеет access.

Если merchant не имеет access к provider, этот provider не должен появляться в списке выбора.

Отдельная страница со списком provider methods для merchant users в MVP не нужна.

6. Revoke Provider Access ​

Provider Access можно убрать.

Revoke Provider Access требует confirmation modal. Reason/comment при revoke в MVP не требуется.

Если Provider Access был revoked:

  • merchant users больше не видят provider в списке при создании нового SUB MID;
  • merchant users больше не видят provider details по существующим merchant-created SUB MID этого provider;
  • уже созданные SUB MID остаются active;
  • существующие SUB MID не отключаются автоматически;
  • routing не ломается автоматически;
  • historical transactions остаются доступными.

То есть revoke Provider Access влияет на visibility и future self-service actions, но не является runtime disable существующих configurations.

Если нужно остановить processing через конкретный SUB MID, user с permission должен отдельно изменить status SUB MID на INACTIVE или DELETED.

7. Visibility rules ​

Merchant user может видеть provider details только если выполняются все условия:

  • merchant имеет Provider Access к этому provider;
  • SUB MID создан под этого merchant;
  • user имеет permission смотреть / управлять SUB MID;
  • user имеет access к merchant context.

Если provider access отсутствует:

  • provider name скрыт;
  • credentials/config скрыты;
  • provider-sensitive settings скрыты;
  • hidden platform-created SUB MID отображается как blackbox / placeholder, если это нужно для high-level routing visibility.

SUB MID AGGREGATOR всегда остается platform-only configuration.

Merchant user не видит SUB MID AGGREGATOR provider details даже если merchant имеет access к тому же provider.

8. Audit log ​

Provider Access changes должны попадать в audit log.

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

  • Provider Access granted;
  • Provider Access revoked;
  • merchant;
  • provider;
  • actor;
  • timestamp.

Provider Access revoke не требует reason/comment в MVP.

Audit log должен быть доступен:

  • на странице merchant details;
  • в общем audit logs разделе, если user имеет permission.

9. Acceptance Criteria ​

Provider Access считается согласованным для MVP, если:

  • Provider Access выдается на уровне merchant.
  • Provider Access не выдается на уровне brand.
  • Provider Access не выдается на уровне merchant group.
  • Provider Access не выдается конкретному user.
  • Provider Access выдается к конкретному provider.
  • Provider Access не выдается отдельно к provider method.
  • Если merchant получил access к provider, он видит все provider methods этого provider.
  • Merchant видит только provider methods, реализованные в code registry.
  • Provider Access может выдать только platform user с permission can_grant_provider_access_to_merchant.
  • Provider Access можно revoke.
  • После revoke существующие SUB MID остаются active.
  • После revoke merchant users больше не видят provider data по существующим SUB MID этого provider.
  • После revoke merchant users больше не могут создавать новые SUB MID этого provider.
  • Provider Access управляется на странице merchant details.
  • В Merchant section отдельная страница Provider Access не нужна.
  • При создании SUB MID merchant user видит только providers, к которым merchant имеет access.
  • Если merchant не имеет access к provider, hidden routing остается blackbox.
  • Provider Access grant/revoke пишется в audit log.
  • Provider Access revoke требует confirmation modal.
  • Provider Access revoke не требует reason/comment.

10. Open Questions ​

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

Technical/design follow-up:

  1. Определить exact table/model для merchant-provider access.
  2. Определить provider identifier format.
  3. Определить UI component на merchant details page.
  4. Определить masking behavior для SUB MID после revoke provider access.