Context

Current System

На текущий момент у нас есть платежная система, которая позволяет мерчантам создавать депозиты и выводы, а администраторам управлять конфигурациями через Back Office.

Однако базовая модель платежных методов была заложена неверно. Сейчас депозитные и withdrawal-методы во многом построены вокруг провайдеров. Например, в системе может существовать депозит через конкретного провайдера, хотя с продуктовой точки зрения это должен быть не провайдерский метод, а понятный платежный метод:

• Card payment
• Open Banking
• Skrill
• Quick Checkout
• Crypto
• Apple Pay
• Google Pay

Например, сейчас депозит может восприниматься как Interkassa deposit, хотя правильно было бы моделировать это как Apple Pay deposit, внутри которого могут использоваться разные провайдеры, поддерживающие Apple Pay.

Новая система должна быть построена вокруг платежных методов и бизнес-флоу, а не вокруг названий провайдеров.

Current Problems

Текущий Back Office недостаточно интуитивен. Если пользователь не знает внутреннее устройство системы, ему сложно создать или изменить конфигурацию. Это создает зависимость от разработчиков и людей, которые исторически знают, как система работает.

Часть функционала Back Office не продумана до конца. В некоторых местах есть лишние настройки или возможности, которые сейчас не используются и, скорее всего, не будут использоваться в будущем. Несмотря на это, команда разработки вынуждена поддерживать и тестировать этот функционал.

Также есть проблема смешения пользовательских контекстов. В Back Office есть функциональность, где не всегда понятно, для кого она предназначена: для мерчанта или для администратора платежной платформы. Пользователь заходит на страницу и ожидает, что функционал работает одинаково для merchant user и для platform admin, хотя на практике эти роли должны иметь разные возможности, разные уровни видимости и разные сценарии использования.

Из-за этого нужно четко разделить платформу для администратора и платформу для мерчанта. В интерфейсе Back Office меню, доступные разделы и действия должны зависеть от типа пользователя и его permissions:

• Merchant user должен видеть только merchant-facing функциональность.
• Platform admin должен видеть platform/admin functionality.

Это разделение должно быть понятным не только технически, но и визуально, в структуре продукта.

Why v3 Is Needed

Новая версия нужна не как косметическое обновление старой системы. V3 нужен для того, чтобы реализовать действительно необходимый функционал в более качественном, понятном и поддерживаемом виде.

Новая версия должна:

• исправить неправильную provider-centric модель платежных методов;
• сделать конфигурацию routing понятной и управляемой;
• разделить platform admin и merchant-facing functionality;
• дать возможность видеть полный flow транзакции;
• улучшить качество технической реализации;
• убрать лишний или неиспользуемый функционал;
• сделать систему проще для поддержки, тестирования и расширения.

Цель MVP: реализовать функционал, при котором merchant может провести deposit transaction через новый routing, видеть свои транзакции через Back Office / Merchant Portal и иметь возможность работать с тем routing-level, который ему разрешено видеть.

Product Principles

Мы принимаем design-first подход.

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

1. Сначала мы полностью продумываем систему и функционал.
2. После этого создается дизайн.
3. После этого функционал детально описывается в технических тикетах.
4. После этого он оценивается.
5. Только после этого он берется в работу для MVP.

Функционал не должен попадать в разработку только потому, что он кажется очевидным. Перед разработкой должны быть описаны use cases, основные сценарии, альтернативные сценарии, ошибки, права доступа, visibility rules и acceptance criteria.

Back Office Separation

Одно из обязательных требований MVP - разделить Back Office на две логические платформы:

• Platform Admin area
• Merchant area / Merchant Portal

Если пользователь является merchant user, он должен видеть только разделы и действия, относящиеся к merchant-facing functionality.

Если пользователь является platform admin, он должен видеть platform/admin functionality: merchants, brands, payment methods, routing configuration, MID configuration, users, roles, permissions, audit logs etc.

Это разделение должно быть отражено в навигации, permissions, visibility rules и UX.

Transaction Explainability

Новая система должна позволять видеть полный flow транзакции.

Для каждой transaction должно быть понятно:

• какой payment method был использован;
• какие routing rules применились;
• какой routing path был выбран;
• какие provider/MID attempts были выполнены;
• какие attempts были пропущены или отклонены;
• почему сработал fallback;
• какие ошибки произошли;
• какая причина у ошибки;
• какие callbacks пришли от provider;
• какие webhooks были отправлены merchant;
• какие retry были выполнены.

Support, Platform Admin и другие разрешенные пользователи должны иметь возможность расследовать transaction без помощи разработчика.

Provider Confidentiality

Обязательное требование новой версии - скрывать реальные названия провайдеров от пользователей, у которых нет права видеть эту информацию.

Это критично для бизнеса. Если merchant увидит название реального provider, он может обратиться к этому provider напрямую. Такой сценарий является фатальной ошибкой для платежного агрегатора.

Поэтому:

• Merchant users не должны видеть реальные provider names если только ему не был выдан доступ к этому провайдеру.
• Merchant users не должны видеть raw provider responses.
• Provider information должна быть доступна только platform users с соответствующими permissions или пользователю, которому выдали доступ к определённому провайдеру.

Migration Approach

Миграция на v3 будет происходить постепенно.

Предполагаемый процесс:

1. В новой системе создается merchant.
2. Под merchant создается нужный brand и payment method, который соответствует методу из старого Back Office.
3. Выполняется test deposit.
4. Merchant начинает отправлять traffic по этому payment method в новую версию.
5. Старая система продолжает работать, пока merchant использует v1 endpoints.
6. Когда merchant перестал отправлять traffic по этому payment method в старую систему, запускается специальная утилита для переноса historical transactions из старого Back Office в новый Back Office.

Перенесенные transactions нужны для истории и расследований. Они должны быть помечены как legacy, чтобы пользователь понимал, что эти данные пришли из старой системы.

Auditability

В новой системе должен быть audit log на любое значимое действие пользователя Back Office.

Если пользователь:

• создал сущность;
• изменил сущность;
• удалил или деактивировал сущность;
• изменил routing;
• изменил MID configuration;
• изменил permissions;
• изменил role;
• создал API key;
• запустил migration;
• сделал operational action;

система должна записать, кто это сделал, когда это произошло, что именно изменилось и, где возможно, предыдущее и новое значение.

Мы должны иметь возможность понять, что, почему и когда происходило в системе.