Payment Orchestrator

Тема

05.13 Provider Catalog And Methods ​

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

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

Этот документ описывает, откуда в системе берется список providers и provider methods.

В MVP Provider Catalog не является пользовательской бизнес-сущностью в Back Office.

Provider и provider method существуют в системе только если они описаны и реализованы в коде.

2. Core rule ​

Список providers хранится в коде.

Примеры:

text
INTERKASSA
JETON
SKRILL

Provider появляется в UI только если:

  • он описан в code registry;
  • для него есть provider adapter / integration code;
  • он доступен в текущем context;
  • user имеет право его видеть.

Если provider не реализован на уровне кода, его не существует для product/UI flow.

3. Provider methods ​

Список provider methods тоже хранится в коде.

У каждого provider может быть свой список methods.

Пример:

text
Provider: INTERKASSA
Methods:
  - cards
  - apple_pay
  - google_pay

Provider method появляется в UI только если он реализован на уровне кода.

Если provider теоретически поддерживает method, но adapter method еще не реализован, этот method не должен показываться в Back Office и не должен быть доступен для создания SUB MID.

4. Provider visibility ​

Platform users с нужными permissions могут видеть реальные provider names.

Merchant users по умолчанию не видят реальные provider names.

Merchant user может увидеть реальное provider name только если:

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

Если Provider Access не выдан, merchant user не должен видеть provider name вообще.

Hidden platform-created routing должен оставаться blackbox.

5. Provider display name ​

Для platform users можно показывать real technical provider name.

Для merchant users, которым выдан Provider Access, можно показывать реальное provider name, потому что access выдан осознанно.

Отдельная friendly/public naming model для merchant users в MVP не нужна.

6. Provider method visibility ​

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

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

Provider method list не показывается merchant user-у отдельной страницей.

Provider method list появляется только внутри relevant UI flow, например:

  • создание SUB MID;
  • редактирование allowed config fields SUB MID, если это применимо.

7. Required attributes visibility ​

Provider method required / optional attributes описываются в коде provider adapter.

Merchant user не должен заранее видеть список required attributes provider method до создания SUB MID.

Required attributes используются системой для:

  • validation;
  • hosted payment form dynamic inputs;
  • provider request mapping;
  • internal support/debugging.

8. Method availability ​

В MVP status provider method в Back Office не нужен.

Если provider method временно недоступен, это operational agreement / operational handling, а не отдельная product setting.

Если нужно отключить execution через provider method, это делается через конкретные configurations:

  • SUB MID status;
  • SUB MID AGGREGATOR status;
  • routing publish/update;
  • provider integration operational controls, если они будут добавлены development team.

9. Provider capabilities ​

Отдельная сущность Provider Capabilities в MVP не нужна.

Под capabilities здесь могли бы пониматься:

  • supported countries;
  • supported currencies;
  • supported methods;
  • limits;
  • settlement rules;
  • provider-specific availability.

В MVP это не хранится как отдельная бизнес-модель, потому что такие договоренности часто меняются и могут быстро устареть.

Для MVP достаточно:

  • code registry для providers and methods;
  • provider adapter schema for required/optional attributes;
  • routing rules для country/currency/amount decisions;
  • operational agreements outside Back Office.

Если в будущем потребуется управлять provider capabilities как продуктовой сущностью, это должно быть отдельным requirement.

10. Audit log ​

Так как provider catalog и provider methods хранятся в коде, отдельный Back Office audit log для изменений provider catalog в MVP не нужен.

Изменения provider catalog должны проходить через обычный development/release process.

Audit log нужен для product/runtime действий:

  • Provider Access grant/revoke;
  • SUB MID created/updated/deleted;
  • SUB MID AGGREGATOR created/updated/deleted;
  • routing draft/publish;
  • status changes.

11. Acceptance Criteria ​

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

  • Список providers хранится в коде.
  • Список provider methods хранится в коде.
  • Provider появляется в UI только если он реализован на уровне кода.
  • Provider method появляется в UI только если он реализован на уровне кода.
  • Если provider method не реализован в коде, он не показывается в Back Office.
  • Platform users с permissions могут видеть реальные provider names.
  • Merchant users без Provider Access не видят реальные provider names.
  • Merchant users с Provider Access и permissions могут видеть реальное provider name.
  • Если merchant получил access к provider, он видит все реализованные methods этого provider при создании SUB MID.
  • Отдельный access на provider method не нужен.
  • Merchant user не видит required attributes provider method до создания SUB MID.
  • Provider method status в Back Office для MVP не нужен.
  • Отдельная Provider Capabilities бизнес-сущность в MVP не нужна.
  • Отдельный Back Office audit log на изменение provider catalog не нужен.

12. Open Questions ​

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

Technical/design follow-up:

  1. Определить формат code registry для provider adapters.
  2. Определить internal provider identifiers.
  3. Определить format provider method schema.
  4. Определить validation, что SUB MID method compatible с Payment Method / MID and MASTER MID method.