Максим Петров
Максим Петров спрашивает:

Казино должно отклонить депозит игрока в самоисключении, как это технически реализуется?

📁 Казино 1 нед. назад 💬 4 ответов
Оцените этот вопрос:
4.1 / 5  (11 оценок)

4 ответов

Артём Лазарев
Артём Лазарев 9 28 1 нед. назад
Соединяем базу данных самоисключённых игроков с платёжным шлюзом в реальном времени. Когда игрок пытается внести депозит, система сверяет его ID, email и платёжные реквизиты с чёрным списком до того, как транзакция подтвердится. Если срабатывает триггер, платёж автоматически отбивается на этапе пречека - деньги даже не успевают зависнуть на балансе.
5
Павел Родионов
Павел Родионов 7 38 1 нед. назад
Обычно техническая реализация строится на пре-авторизации платежа через интеграцию с платёжным шлюзом. На стороне казино мы ставим асинхронный хукинг: система проверяет не только баланс игрока, но и его статус в реестре самоисключений до того, как отправить запрос в банк или платёжную систему. Если флаг активен, API сразу возвращает ошибку, и деньги даже не списываются со счёта игрока - это снижает нагрузку на возвраты.
5
Анатолий Киселёв
Анатолий Киселёв 7 32 1 нед. назад
На уровне базы данных ставим блокировку по уникальному идентификатору игрока - user_id или его хешированному платёжному токену. Когда система принимает запрос на депозит, я в коде проверяю наличие этого ID в таблице self_exclusion с флагом active=true. Если флаг есть, транзакция обрывается на этапе валидации, ещё до отправки в платёжный шлюз. Сам депозит не создаётся в бухгалтерском модуле казино.
5
Ярослав Одинцов
Ярослав Одинцов 6 25 1 нед. назад
Ставлю проверку на уровне платёжного микросервиса до того, как сумма уходит в процессинг. Беру ID игрока, его хеш паспорта и привязанные карты, сверяю с динамическим списком самоисключений в Redis - он обновляется каждые 10 секунд. Если совпадение есть, микросервис возвращает платёжному шлюзу статус cancelled ещё на стадии pre-auth, даже не трогая баланс игрока.
5

Ответить

0 / 3000