Вне архитектуры конкретной платформы не существует «лучшей модели кошелька». Выбор единого или переводного кошелька зависит от действующей системы балансов, обработки исключений, процессов сверки и допустимого объёма изменений.
Эта статья объясняет решения для закупок и архитектуры. Она не содержит конечных точек интерфейса, протоколов обратных вызовов, правил подписи, учётных данных или производственной конфигурации.
Что такое единый кошелёк?
Единый кошелёк часто называют seamless wallet. Проще говоря, платформа продолжает вести основной баланс игрока, а взаимодействие, связанное с игровыми балансами, списаниями, выплатами или отменами, выполняется в процессах, согласованных обеими сторонами.
При закупке следует подтвердить:
- Может ли интерфейс кошелька платформы выполнять требования взаимодействия в реальном времени;
- как обрабатываются дублирующиеся и неуспешные запросы;
- как сверяются балансы, транзакции и игровые записи;
- кто определяет проблему и эскалирует её, когда исключение возникает на стороне платформы или поставщика.
Единый кошелёк не означает автоматически «нулевой риск» или «отсутствие изменений». Он предъявляет более чёткие требования к стабильности интерфейса, обработке дублей и ответственности за исключения.
Что такое переводной кошелёк?
Переводной кошелёк обычно сначала переводит баланс со стороны платформы на сторону игрового поставщика, а затем при выходе игрока из игры переводит его обратно либо обрабатывает остаток согласно согласованному сторонами процессу.
При закупке следует подтвердить:
- Как фиксируются пополнения, выводы и статус баланса;
- как восстанавливается работа после прерываний или сбоев;
- как сверяются баланс платформы и баланс на стороне поставщика;
- допускают ли пользовательский путь и существующий опыт платформы дополнительные шаги.
Переводной кошелёк тоже не обязательно «проще». Часть сложности переносится в процессы перевода баланса, управления статусом и сверки.
Что сравнивать между двумя моделями?
| Пункт сравнения | Фокус единого кошелька | Фокус переводного кошелька |
|---|---|---|
| Существующая архитектура | Может ли кошелёк платформы надёжно взаимодействовать | Уже существуют ли зрелые переводы и управление статусом |
| Обработка исключений | Дубли, тайм-ауты, сбои и согласованность баланса | Прерывания перевода, неопределённый статус и восстановление |
| Сверка | Записи транзакций, раундов и балансов | Балансы платформы и поставщика, а также записи транзакций |
| Пользовательский путь | Взаимодействие в реальном времени во время игры | Влияют ли пополнения и выводы на опыт |
| Технический объём | Требования к обратным вызовам и идемпотентности | Требования к переводу баланса и автомату состояний |
Таблица предназначена для организации технического обсуждения. Она не является обязательством AG по конкретной реализации, производительности или возможности автоматизации.
Что должна охватывать стадия тестирования?
Независимо от выбранной модели нельзя проверять только успешный путь. Как минимум рекомендуется подтвердить:
- Обычный запуск и обычные пути транзакций;
- недостаточный баланс, неуспешные запросы или исключения сессии;
- дублирующиеся запросы или повторную доставку одного статуса;
- порядок сверки записей, раундов или расхождений баланса;
- материалы по проблемам, ответственных лиц и способы эскалации.
Какие вопросы нельзя решить публичной статьёй?
Полные протоколы интерфейса, домены сред, подпись, поля обратных вызовов, учётные данные, списки разрешений, задержка, ёмкость, стабильность, рыночные условия и коммерческие условия должны быть подтверждены в контролируемом проектном процессе.
AG может подтвердить только то, что существующие бизнес-материалы охватывают две темы интеграции: единый и переводной кошелёк. Конкретный подход к совместимости, тестовая среда и объём поставки по-прежнему зависят от архитектуры платформы и результата подтверждения проекта.
Нужно превратить это руководство в план проекта?
Материал помогает оценить проект, но не заменяет техническое, договорное, сертификационное или правовое подтверждение.