Раздел «Депозиты» PayStar — единое окно по входящим платежам: статусы ордеров, платёжный путь, похожие платежи, комиссии и сверка с мерчантами и PSP.

1. Бизнес-уровень

1.1. Зачем нужен раздел «Депозиты»

Раздел «Депозиты» — это единое окно по всем входящим платежам мерчанта:

видно каждый платёж: кто платил, через какого провайдера, в каком потоке и с каким результатом;

можно быстро понять, где деньги потерялись — на стороне пользователя, шлюза, PayStar или мерчанта;

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

Иными словами, раздел отвечает на главный вопрос владельца бизнеса:

Сколько денег реально дошло, через кого и с какими потерями по пути?

1.2. Ключевые роли и задачи

Собственник / C-level

видит, как реально «заводятся» деньги;

понимает, какие провайдеры и каналы тянут выручку вверх, а какие — в минус.

Операционный отдел

разбирает жалобы игроков;

фиксирует, где произошёл сбой и какие действия уже сделаны.

Риск / Антифрод

ловит паттерны подозрительного поведения;

видит кластеры депозитов по отпечатку устройства / IP / реквизитов.

Финансы

сверяют успешные депозиты с отчётами PSP и мерчантов;

контролируют комиссии, RR и маржинальность по потокам.

Техподдержка и разработка

диагностируют технические ошибки;

проверяют, как именно платёж прошёл по шлюзам и коллбэкам.

1.3. Как «Депозиты» вписываются в общую картину отчётности

«Депозиты» — это детализация до единичного ордера. Над ними — три уровня:

Payment report / Отчёт по ордерам
Аналитика в графиках: распределения по статусам, мерчантам, потокам, каналам, шлюзам, валютам и платёжные воронки.

Summary report / Сводный отчёт
Табличные итоги по периодам: количество ордеров, конверсия, обороты, начальные/конечные балансы, RR и комиссии.

Сверка (Reconciliation)
Загрузка Excel от мерчанта или шлюза, автоматическое сопоставление с данными PayStar и выделение расхождений.

Для аналитики и финансового контроля обычно идут сверху вниз:
Payment report → Summary report → Deposits (конкретные кейсы).

Для операционки и поддержки — наоборот:
жалоба / проблемный платёж → Deposits → при необходимости — отчёты и тренды.

2. Навигация по разделу «Депозиты»

2.1. Основной экран: список депозитов

📸 Скриншот 1 — список депозита

Сверху — фильтры по ключевым измерениям:

период (Создано),

Статус (init / created / processing / success / failed),

Мерчант, Поток, Канал, Шлюз, Интеграция,

Валюта,

точечный поиск по:

Депозит ID / Вывод ID,

Мерчант ордер ID,

Шлюз ордер ID,

реквизитам и пользователю.

В таблице по каждой записи видно:

время создания, сумму и валюту,

статус ордера,

идентификаторы в системах PayStar, мерчанта и шлюза,

реквизиты (банк, маска карты/кошелька и т.д.),

поток, канал и шлюз,

при расширенном представлении — комиссии и RR.

Внизу — строка «Общая сумма» и ссылки FULL / MERCH:

агрегированные суммы по всем отфильтрованным ордерам, с разбивкой по валютам;

запуск выгрузки полного или «обрезанного» отчёта.

2.2. Детали депозита

📸 Скриншот 2 — карточка депозита

В карточке депозита показываются:

статус, сумма, валюта, время создания;

IP, браузер, язык, payerIdentifier, email, страна;

страницы и URL платёжной формы;

идентификаторы ордера в PayStar, у мерчанта и у шлюза.

Доступные действия:

копировать важные поля (ID, реквизиты) для общения с PSP/мерчантом;

добавить в blacklist пользователя или реквизиты (auto-decline будущих попыток);

оставить комментарий и назначить исполнителя по кейсу;

создать задачу разработчику (например, «проверить логи для этого ордера»).

2.3. Платёжный путь

📸 Скриншот 3 — Payment path / Платёжный путь

Блок «Платёжный путь» — это хронология жизни ордера:

события на стороне пользователя (визиты, клики, повторные попытки),

запросы в платёжный шлюз и ответы PSP (коды и сообщения, сырые JSON),

внутренние шаги PayStar (смена статусов, каскад, ошибки),

исходящие коллбэки в сторону мерчанта.

Здесь же:

доступна повторная отправка коллбэка;

видно orderHistory от шлюза/мерчанта;

временная шкала показывает, где именно платёж «завис» или упал.

2.4. Похожие депозиты (отпечаток)

📸 Скриншот 4 — блок похожих депозитов

Для каждого депозита строится отпечаток по десяткам сигналов:

IP и гео,

устройство и браузер,

язык, тайминги,

реквизиты карты/кошелька,

поведенческие метрики.

В блок «Похожие депозиты» попадают платежи, где сумма совпадающих признаков превысила порог.
Это позволяет:

увидеть все попытки одного и того же пользователя/устройства,

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

выявлять схемы мультиаккаунта и бонус-абьюза.

2.5. Финансовые проводки и комиссии

📸 Скриншот 5 — финансовые проводки и комиссии

Для успешных ордеров доступны:

проводки по мерчанту, шлюзу и рефералам;

комиссии и RR (merchant RR, gateway RR, общий RR);

начальные и конечные балансы.

Так связываются технический статус и финансовый результат: видно, кто и сколько заработал на этом платеже.

2.6. Ручное изменение статуса и безопасность

📸 Скриншот 6 — ручное изменение статуса

Для пользователей с повышенными правами доступно ручное изменение статуса ордера:

из гриды (в ячейке Status) или из карточки ордера;

операция считается исключительной, требует осознанного решения;

после изменения статуса автоматически отправляется уведомление в Telegram служебного чата.

Рекомендуется всегда предварительно проверять логи и платёжный путь, чтобы не нарушить финансовую отчётность.

2.7. Экспорт и отчёты

📸 Скриншот 7 — футтер и экспорт

Из раздела «Депозиты» доступны два типа выгрузок:

FULL — полный внутренний отчёт со всеми полями (включая детали по PSP, комиссии и технические параметры);

MERCH — «обрезанный» отчёт для мерчанта, без раскрытия инфраструктуры PSP (актуально для платёжных агрегаторов).

Выгрузки формируются отложенно и доступны в разделе «Экспорт файлов».

3. Операционный уровень: кейсы

3.1. Кейс 1. Жалоба игрока: деньги списаны, баланс не обновился

Ситуация. Игрок прислал чек/скрин из банка: деньги списаны, но депозит не виден в кабинете мерчанта.

Шаги в PayStar:

В разделе «Депозиты» находим платёж:

по сумме и времени;

или по Merchant order ID, если он известен;

или через блок Похожие депозиты, если есть только IP/email.

Открываем карточку депозита и «Платёжный путь»:

убеждаемся, что у шлюза статус Success;

смотрим, был ли отправлен и принят коллбек мерчантом.

Если коллбек не был обработан:

нажимаем «Повторить callback»;

фиксируем действие в комментарии (кто и когда переотправил).

При повторяющейся проблеме:

создаём задачу разработчику (проверить endpoint мерчанта, логирование);

при необходимости поднимаем вопрос с мерчантом.

Результат. Оператор чётко видит, где застрял платёж, и документирует все действия по жалобе.

3.2. Кейс 2. Падение конверсии по одному шлюзу

Ситуация. Конверсия депозитов по шлюзу X падает, растёт доля отказов.

Шаги:

В Payment report смотрим распределение по статусам и шлюзам — видим всплеск Failed по шлюзу X.

Переходим в «Депозиты»:

фильтруем по мерчанту (или всем), периоду и шлюзу X;

открываем несколько ордеров и анализируем коды ошибок в Payment path.

Если ошибка массовая и техническая:

временно выключаем шлюз X из роутинга или уводим трафик в каскад на другой шлюз;

отправляем PSP список примеров Gateway order ID с описанием проблемы.

После исправления:

включаем шлюз обратно;

мониторим восстановление конверсии в Payment report и по факту в «Депозитах».

Результат. Решение о переключении трафика принимается не на «ощущениях», а на основе конкретных данных по ордерам.

3.3. Кейс 3. Поиск подозрительных депозитов и блокировка

📸 Скриншот 10 — риск-кейс с похожими депозитами и blacklist

Ситуация. Риск-команда подозревает бонус-абьюз или отмывание.

Шаги:

Находим один из подозрительных депозитов по мерчанту, сумме или шлюзу.

Открываем «Похожие депозиты»:

видим все попытки с теми же IP/устройством/реквизитами;

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

Если паттерн подтверждается:

из карточки депозита добавляем в blacklist payerIdentifier, email, IP, кошелёк и т.п.;

фиксируем в комментариях причину и ссылку на внутренний кейс.

При необходимости выгружаем список ордеров (FULL) и прикладываем к отчёту по расследованию.

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

3.4. Кейс 4. Подготовка отчёта для мерчанта (агрегатор)

📸 Скриншот 11 — фильтр по одному мерчанту и экспорт MERCH

Ситуация. Платёжный агрегатор готовит отчёт для мерчанта и не хочет раскрывать детали своей PSP-инфраструктуры.

Шаги:

В разделе «Депозиты»:

фильтруем по нужному мерчанту и периоду;

при необходимости фильтруем по валюте/каналу.

В футтере нажимаем MERCH:

в отчёт попадают суммы, статусы и ID ордеров;

исключены внутренние данные по PSP и их комиссиям.

Передаём отчёт мерчанту как официальный разрез по его платежам.

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

3.5. Кейс 5. Техническая аномалия и ручное изменение статуса

📸 Скриншот 12 — аномальный статус и ручное исправление

Ситуация. Шлюз вернул нестандартный статус, ордер «завис» в Processing, а фактически деньги вернулись пользователю.

Шаги:

Через Payment report или список депозитов находим красный/аномальный ордер.

В Payment path проверяем:

что шлюз действительно вернул нетипичный статус;

что транзакция не была проведена (или была отменена).

После проверки:

администратор вручную меняет статус ордера на корректный (failed / другой финальный статус);

система отправляет уведомление в Telegram о ручной правке.

По итогам:

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

Результат. Даже при нестандартных ответах PSP система остаётся контролируемой и прозрачной.

3.6. Кейс 6. Связка с отчётами и сверкой

Ситуация. Финансовый отдел готовит ежемесячную сверку с PSP и видит расхождения.

Шаги:

В Summary report смотрим:

количество успешных ордеров и оборот по конкретному шлюзу за период;

сравниваем с отчётом PSP.

В разделе Сверка загружаем отчёт PSP:

получаем список совпадений и расхождений.

По спорным строкам:

кликаем по ID и переходим в конкретный ордер в «Депозиты»;

через Payment path проверяем, что реально произошло.

Финальный отчёт формируем с опорой на:

данные PSP,

данные PayStar,

набор конкретных ордеров по спорным пунктам.

Результат. Сверка превращается из «битвы Excel» в управляемый процесс с доказательной базой по каждому спорному платёжному кейсу.

Раздел «Депозиты» в PayStar

1. Бизнес-уровень#

1.1. Зачем нужен раздел «Депозиты»#

1.2. Ключевые роли и задачи#

1.3. Как «Депозиты» вписываются в общую картину отчётности#

2. Навигация по разделу «Депозиты»#

2.1. Основной экран: список депозитов#

2.2. Детали депозита#

2.3. Платёжный путь#

2.4. Похожие депозиты (отпечаток)#

2.5. Финансовые проводки и комиссии#

2.6. Ручное изменение статуса и безопасность#

2.7. Экспорт и отчёты#

3. Операционный уровень: кейсы#

3.1. Кейс 1. Жалоба игрока: деньги списаны, баланс не обновился#

3.2. Кейс 2. Падение конверсии по одному шлюзу#

3.3. Кейс 3. Поиск подозрительных депозитов и блокировка#

3.4. Кейс 4. Подготовка отчёта для мерчанта (агрегатор)#

3.5. Кейс 5. Техническая аномалия и ручное изменение статуса#

3.6. Кейс 6. Связка с отчётами и сверкой#

1. Бизнес-уровень

1.1. Зачем нужен раздел «Депозиты»

1.2. Ключевые роли и задачи

1.3. Как «Депозиты» вписываются в общую картину отчётности

2. Навигация по разделу «Депозиты»

2.1. Основной экран: список депозитов

2.2. Детали депозита

2.3. Платёжный путь

2.4. Похожие депозиты (отпечаток)

2.5. Финансовые проводки и комиссии

2.6. Ручное изменение статуса и безопасность

2.7. Экспорт и отчёты

3. Операционный уровень: кейсы

3.1. Кейс 1. Жалоба игрока: деньги списаны, баланс не обновился

3.2. Кейс 2. Падение конверсии по одному шлюзу

3.3. Кейс 3. Поиск подозрительных депозитов и блокировка

3.4. Кейс 4. Подготовка отчёта для мерчанта (агрегатор)

3.5. Кейс 5. Техническая аномалия и ручное изменение статуса

3.6. Кейс 6. Связка с отчётами и сверкой