ME

Кейс · PoputkaGo · 2024 · Rideshare-приложение

PoputkaGo

Подключение Payme и Click для приложения совместных поездок по Узбекистану.

Стек проекта

  • FastAPI
  • PostgreSQL
  • Redis
  • Payme API
  • Click API
  • Docker
Срок
несколько недель
Бюджет
Стандарт-пакет (от $1500)
Индустрия
Rideshare-приложение

TL;DR

Payme + Click primary + fallback для непрерывности
FastAPI асинхронные вебхуки и retry-логика
ночной job автоматическая сверка с банком
мобиль кастомный чекаут без редиректа

Контекст

Вводные данные.

PoputkaGo — приложение совместных поездок по Узбекистану. Команда пришла с задачей подключить локальные платёжные шлюзы (Payme как primary + Click как fallback) с минимальными комиссиями и кастомным чекаут-flow.

До работы с нами оплата шла через сторонний сервис с высокими комиссиями и плохой конверсией на мобильных устройствах.

Задача

Что нужно было решить.

01

Подключить Payme и Click с минимальными комиссиями

02

Кастомный чекаут под мобильное приложение, без редиректа на сторону шлюза

03

Автоматическая реконсиляция платежей и сверка с банком

04

Антифрод-логика и защита от двойных списаний

Решение

Что и как мы сделали.

Подключили Payme как primary шлюз с приоритетом UZS-карт, Click добавили fallback'ом для случаев недоступности Payme. Серверная часть на FastAPI с асинхронными вебхуками и retry-логикой.

Реконсиляция через ночной job, который сверяет транзакции с банком и помечает расхождения. Антифрод на уровне сервиса (rate-limit + проверка device fingerprint) плюс встроенные правила шлюзов.

Наблюдение

Падение Payme в Узбекистане — реальный риск, не теоретический. Fallback на Click решает проблему незаметно для пользователя в приложении.

Этапы

Как разворачивали.

01

Подключение Payme

Primary шлюз с приоритетом UZS-карт, кастомный чекаут под мобильное приложение.

02

Click fallback

Автоматический переход на Click при недоступности Payme — пользователь не замечает сбоя.

03

Webhook-сервис

Асинхронная обработка платёжных событий с retry-логикой и идемпотентностью.

04

Реконсиляция

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

05

Антифрод

Rate-limit + device fingerprint на стороне сервиса + встроенные правила шлюзов.

Архитектура

Как это устроено.

Клиент Бэкенд Воркеры Внешние API
Мобильное приложение FastAPI PostgreSQL Redis Реконсиляция Антифрод Payme API Click API Сверка с банком

Трансформация

До и после.

Было

Оплата через сторонний сервис с высокими комиссиями, редирект на сторону шлюза, плохая конверсия на мобильных, нет fallback при сбоях.

Стало

Прямая интеграция Payme + Click через FastAPI, кастомный чекаут в приложении, автоматический fallback при недоступности шлюза.

Результаты

Что получилось.

Кастомный чекаут под мобильное приложение, без редиректа на сторону шлюза
Снижение failed payments за счёт fallback-логики и retry-механизмов
Несколько недель от старта до production

Похожая задача?

Расскажите о вашей ситуации — пришлю расчёт и план в течение рабочего дня.

Обсудить задачу → — Резидент IT Park · Ташкент