Цель

реализовать простое решение для лендбейзед провайдеров, при помощи которого они могли бы конвертировать своих постоянных клиентов в онлайн игроков.

PreConditions:

• у лендбейзед провайдера нет своего онлайн казино
• лендбейзед провайдер интегрировал у себя платы RLS
• лендбейзед провайдеру ок, что интеграции его системы с ROP не будет, то есть ему руками прийдется заводить аккаунты пользователей и проставлять им статусы авторизации.
• Кассиры лендбейса не знают английский и им нужен локализованный интерфейс

User Storie

Я как пользователь казино могу зайти на сайт и зарегистироваться используя почту либо авторизацию через соц сети.

Я как пользователь после регистации я вижу заглушку, с требованием связаться ОФФЛАЙН с администратором казино и предоставить ему свой код клиента (просто userid).

Я как пользовател иду в казино оффлайн, подхожу к администратору, передаю свои документы для идентификации и кладу сумму денег на ОНЛАЙН счет.

Я как администратор казино, проведя идентификацию клиента, при помощи админ панели загружаю данные клиента в админку, и активирую учетную запись по UserID. После чего вношу кредиты на баланс пользователя.

Я как пользователю, могу вернуться домой, зайти на сайт казино, залогинится используя ранне сохраненные данные и попасть в лобии онлайн продукта. В лобби онлайн продукта я могу открыть лобби RLS и поиграть в настоящий аппарат.

Я как пользователь иду в оффлайн казино и прошу администратора снять деньги с онлайн счета и положить их на оффлайн счет.

Я как администратор казино — могу убрать баланс с онлайн счета клиента и пополнить его баланс в зале.

Функциональные блоки

Блок клиента казино

Лендинг

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

Форма регистрации/логина

Фактически это форма первичной регистрации, максимально простая, емейл/пароль либо Gmail авторизации

Экран не верифицированного пользователя

Этот экран показывается всем зарегистрировавшимся пользователям, на нем важно показать userID, с которым нужно проходить верификацию. На этом экране так же можно сделать форму подачи документов для KYC, но не во всех юрисдикциях это законно онлайн, поэтому это скорее опциональная форма заявки на KYC

Экран верифицированного пользователя (лобби)

Если пользователь верифицирован и допущен к иге онлай то мы должны показать ему лобби.

• необходимо показать пользователю его баланс (уточнить в кредитах или в фиат валюте?)
• необходимо показать пользователю список доступных игр (к примеру лобби RLS с аппаратами нетента, лобби RLS с аппаратами другого производителя)

Экран игры

Собсвтенно урл привязанный к запуску конкретного игрового лобби.

Блок Администратора

Предполагается несколько ролей:

• Супер админ
• KYC
• Кассир

Авторизация

Для администраторов требования к логину выше, поэтому необходимо обязательно реализовать 2fa (либо auth по времени, либо СМС какой-нибудь)

Управление пользователями

Задача блока — видеть всех зарегистрированных пользователей и их статусы. К примеру в виде таблички с колонками:

• способ авторизации
• дата регистрации
• дата последнего логина
• баланс на счету
• валюта счета (нужно ли)
• статус KYC (не пройдено|подал документы|верифицирован|верифицирован на дату хххх)
• статус (активен|заблокирован)
• роли (пользователь|супер админ|KYC|Кассир)
• комментарий
• группы (пользовательски группы, создаются администратором по своему усмотрению, как теги) Мы должны иметь возможность открыть каждого пользователя и видеть его карточку.

Для роли KYC: мы должны видеть историю изменения статусов KYC, привязанные к пользователю документы (без возможности удаления, только опция скрыть из карточки), иметь возможность добавить новые KYC документы, иметь возможность изменить статус KYC. Вероятно, проще всего это реализовать как отдельную табу в карточке клиента. ВАЖНО — все действия с KYC должны логироваться не только во времени, но и в разрезе какой именно пользователь их совершил.

Для роли кассир: необходимо показывать историю изменений баланса, в разрезе каждой ставки. Так же необходимо иметь возможность внести деньги на счет (операция внесения денег) и забрать деньги со счета. Операции по изменению счета должны так же быть показаны в разделе касса и должны иметь опциональное поле комментарий (в нем, скорее всего, будет номер чека).

Для всех администраторов: сессии игрока, на этой табе должна быть таблица с историей логинов пользователя. К примеру:

• дата время начала сессии
• ip
• страна и город сессии
• продолжительность сессии

Управление кассой

Задача этого блока — оперативный финансовый контроль. Два основных среза

1. последние операции Фактически это просто история всех кассовых ордеров (внесения и вынесения денег на счет игроков)

2. остатки на счетах Табличка которая в принципе совпадает с таблицей из управления пользователями и вероятно может быть опущена

Возможность создать документ внесения денег на счет, или забора денег со счета. У документа взаимодействия со счетом должно быть поле тип (касса, бонус, компенсация) по которому можно фильтровать ордера. Каждый ордер должен иметь автора.

Роль кассир не может править ордера старше сегодняшней даты. (это требует обсуждения на самом деле)

Управление Играми

В этом блоке можно конфигурировать игры, к примеру добавлять или убирать лобби в RLS, скрывать или показывать их.

В этом разделе так же должна быть история ставок по всем лобби/аппаратам с возможностью фильтрации

Программные блоки

• Авторизация - необходима поддержка авторизации по емейл (с возможностью сброса пароля по емейлу), с авторизацией по соц сетям (oauth), с поддержкой 2fa (authenticatator, возможно смс)
• Роли пользователей - важно иметь гарды на ограничение действий определенных груп в админке, один пользователь может быть членом нескольких групп
• Загрузка файлов - загрузка файлов в s3 like хранилище. с поддержкой доступ к файлаам только авторизированных пользователей.
• Интеграция с провайдерами игр - важно обрабатывать некорректные ответы и иные корнер кейсы, которые могут возникать из-за того что баланс внутри провайдера свой, а внутри платформы свой.

Проблемы

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

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

Tech Decisions

Предлагается использовать SvelteKit для быстрого разворачивания решения.

Для хостинга статики и бекенда использовать CloudFlare Pages

Для авторизации использовать Lucia-auth (не поддерживает авторизацию через телеграм)

Для админ панели использовать IBM Carbon

Для клиентской части (лендинги и т.п.) максимально вынести все настройки оформления в css-vars, чтобы их можно было хотя бы частично переиспользовать между клиентами