Задача
Магазину нужен приём платежей, а не изучение тридцати пяти протоколов. У каждой платёжной системы свой формат запроса, своё подтверждение, своя логика возвратов и свой набор ситуаций, когда деньги списаны, а уведомление не пришло.
Задача платформы в том, чтобы всё это осталось у нас, а мерчант увидел одну документацию и один способ подключения.
Решение
Платформа устроена как динамический шлюз. Общий путь платежа один для всех систем, а различия вынесены в описание конкретного шлюза, поэтому новая система подключается настройкой и адаптером, а не переписыванием ядра.
Путь денег: внешний магазин инициирует платёж по API, покупатель платит на странице оплаты, подтверждение приходит уведомлением от платёжной системы, сумма за вычетом комиссии падает на баланс мерчанта и дальше уходит на вывод по расписанию.
Комиссии считаются в две ступени, отдельно комиссия шлюза и отдельно комиссия платформы, с учётом скидок и перевода в базовую валюту. Формула лежит в одном месте, потому что вторая копия расчёта денег расходится с первой всегда.
Архитектура и реализация
Что внутри:
· API подключения и страница оплаты
· адаптеры к платёжным системам, добавляемые без правки ядра
· приём и проверка уведомлений об оплате
· двухступенчатый расчёт комиссий и конвертация в базовую валюту
· баланс мерчанта с историей операций
· вывод средств по расписанию с учётом выходных
· выбор счёта для приёма по стратегиям и лимитам на день, неделю и месяц
· готовые плагины к популярным движкам магазинов и SDK
Стек: Laravel и PHP, MySQL, серверные шаблоны.
Результат
Тридцать пять с лишним разных платёжных систем в одном подключении. Цифра считает именно разные системы, а не количество работ: у каждой свой протокол и свой набор пограничных случаев.
Это же число стоит у нас на главной как показатель широты, и вот кейс, из которого оно взялось.
