Платёжный шлюз + антифрод
▍Подключение эквайринга, рекуррент, сплитование и антифрод-правила с честной реконсиляцией под сверку до копейки.
Контекст
Клиент под NDA: сервис с подпиской и разовыми покупками. Платежи были прикручены к одному провайдеру «как получилось» — без идемпотентности, с дублями списаний при ретраях и ручной сверкой в Excel раз в неделю.
Чарджбэков становилось всё больше, а часть отказов на оплате была не фродом, а ложными срабатываниями. Нужен был платёжный слой, которому можно доверять цифры, и антифрод, который режет мошенников, а не выручку.
Задача
- 01Подключить эквайринг (YooKassa / CloudPayments) за единым интерфейсом
- 02Рекуррентные платежи и управление подписками из коробки
- 03Сплитование выручки между несколькими получателями
- 04Антифрод-правила: лимиты, скоринг, ручная очередь на ревью
- 05Ежедневная реконсиляция со сверкой до копейки и алертами
Решение
Единый платёжный слой
Один внутренний API над двумя провайдерами. Любая операция инициируется с idempotency-key, так что повтор запроса при таймауте не создаёт второе списание.
Вебхуки как источник истины
Статус платежа меняем только по подписанному вебхуку провайдера, а не по ответу на запрос. Вебхуки складываются в очередь, обрабатываются ровно один раз и переигрываются при сбое.
Антифрод-правила и скоринг
Правила на лимиты, гео, скорость и BIN считают риск-скор. Высокий риск — отказ, средний — в ручную очередь, низкий — пропуск. Правила меняются без релиза.
Рекуррент и сплитование
Подписки тарифицируются по расписанию с retry-логикой и dunning при неудачном списании. Сплит делит платёж между получателями по правилам в момент захвата средств.
Реконсиляция до копейки
Каждое утро сверяем наши транзакции с реестрами провайдеров. Любое расхождение по сумме или статусу подсвечивается и улетает алертом, а не теряется до конца месяца.
Архитектура
Платёжный сервис — отдельный домен с собственной БД и журналом операций (append-only ledger). Каждая транзакция проходит конечный автомат состояний; переход разрешён только при валидном вебхуке с проверенной подписью.
Идемпотентность держится на ключах в Redis и уникальных индексах в Postgres — двойная защита от дублей при ретраях и гонках. Реконсиляция и антифрод вынесены в фоновые воркеры, чтобы оплата не зависела от их нагрузки.
Результаты
- конверсия оплаты
- фрод-чарджбэков
- рекуррентные платежи
- ежедневная реконсиляция
Что не получилось с первого раза
- ✕Первую версию антифрода настроили слишком жёстко: лимит по скорости платежей рубил легитимных пользователей, которые быстро докупали — конверсия просела на ровном месте. Разнесли правила на «отказ» и «ручную очередь», добавили whitelist для проверенных карт, и фрод поехал вниз без потери живых оплат.
- ✕Сначала меняли статус платежа и по ответу на запрос, и по вебхуку — при сетевом таймауте провайдера это давало рассинхрон: у нас «оплачено», у него «в обработке». Сделали вебхук единственным источником истины, а ответ на запрос — только подсказкой для UI. Расхождения в реконсиляции почти исчезли.
“Раньше каждое утро начиналось со сверки в Excel и вопроса «а где деньги». Теперь цифрам можно верить, а отказы перестали бить по своим же клиентам.
Команда
Что дальше
- →ML-скоринг фрода поверх правил
- →Подключение третьего эквайера для отказоустойчивости
- →Автоматический cascade-роутинг между провайдерами
- →Self-service дашборд правил для риск-команды
