Як взаємодіють модулі iGaming-платформи: шлях гравця і рух грошей

Гравець взаємодіє з платформою через акаунт і спільне представлення своїх коштів. За цим представленням кілька модулів відповідають на різні питання: чи дозволена гравцеві дія, чи пройшов платіж, чи доступні гроші, яка акція застосовується та чи врахований результат гри? Складність — узгодити відповіді, коли повідомлення затримуються або робота переривається посеред процесу.

Стаття призначена для власників продукту, архітекторів і керівників операційних команд, які перевіряють інтегровану платформу. На умовному шляху від реєстрації до виведення коштів для кожного переходу визначено відповідального за рішення, збережений запис і спосіб відновлення. Послідовність та умови акції наведено як приклади для адаптації до затверджених вимог оператора. Це не універсальний порядок, установлений законом, і не опис упровадженої клієнтської системи.

Визначте повноваження до опису шляху гравця

Почніть із можливостей, описаних у матеріалах про модульну iGaming-платформу та можливості платформи, а потім з’ясуйте, який компонент має право змінювати кожен факт. Ці обов’язки можуть бути реалізовані в модульному моноліті або окремих сервісах. Саме по собі окреме розгортання не визначає відповідальності.

• Акаунти гравців: відповідають за ідентичність акаунта, його життєвий цикл і поточні обмеження, що стосуються дії. Підтвердження перевірки особи надходять із відповідного процесу; результат провайдера сам по собі не визначає всіх дозволів на платформі.
• Платежі: відповідають за платіжний запис платформи, посилання на операції провайдера та інтерпретацію зовнішнього статусу платежу.
• Гаманець: відповідає за грошові проведення, доступні кошти та резерви. Статус платежу, результат гри або екран підтримки не можуть незалежно переписувати баланс.
• Бонуси: відповідають за конкретну акцію гравця, застосовні умови, право участі та прогрес. Будь-який рух бонусних коштів має відбуватися за узгодженими правилами взаємодії з гаманцем.
• Ігри: відповідають за інтерпретацію платформою раундів провайдера, приймання ставок, розрахунків і скасувань. Вони посилаються на операції гаманця, а не ведуть конкуруючий баланс.
• Координація процесів: відповідає за незавершені кроки, строки й відновлення. Звітність, підтримка та інтерфейс користувача показують об’єднані представлення; зміни вони запитують у відповідального модуля.

Тому «джерело істини» стосується конкретного факту, а не однієї бази на все. У провайдера є зовнішнє підтвердження, у платежів — нормалізована інтерпретація, у гаманця — фінансове проведення. Звірка перевіряє зв’язок між цими записами, не підмінюючи один іншим.

Розділяйте створення акаунта, перевірку особи й дозвіл дії

У нашому прикладі спочатку створюється акаунт, потім завершується перевірка особи й лише після цього дозволяється депозит. Реальні вимоги залежать від ринку, продукту та дії. Оператор і профільні радники мають визначити, коли застосовуються перевірки, обмеження й ліміти; інженерна команда — забезпечити їх виконання.

Реєстрація має повертати стабільний ідентифікатор гравця та явний стан акаунта. Процес перевірки особи зберігає посилання на перевірку та її результат; модуль акаунтів застосовує затверджену політику, щоб визначити дозволені дії. Не зводьте все до одного прапорця «перевірено», який водночас означає відсутність обмежень, дозвіл депозиту та дозвіл виведення. Завершена перевірка особи не знімає окремого обмеження акаунта.

Дозволи потрібно перевіряти під час приймання суттєвої дії, а не лише під час входу гравця. Уявіть, що обмеження надходить під час обробки запиту депозиту або ставки. Укажіть, який модуль ухвалює остаточне рішення, як він використовує актуальні правила й обмеження та як упорядковує одночасні зміни. Перевірка версії, блокування або узгоджений протокол приймання мають справді забезпечувати ці правила: читання кількох сервісів із подальшою дією залишає можливість гонки.

Під час відновлення також потрібно розрізняти нову активність і раніше прийняте зобов’язання. Обмеження може забороняти нову ставку, але результат уже прийнятого раунду все ще потрібно врахувати за затвердженими правилами. Блокування всіх повідомлень провайдера може залишити гроші без пояснюваного стану. Ці межі станів і дозволів докладніше розглянуто в архітектурі акаунтів гравців.

Депозит може пройти раніше, ніж оновляться гаманець і бонус

Припустімо, гравець запитує депозит на EUR 100. Модуль платежів створює стабільне посилання на операцію до звернення до провайдера. Повернення браузера на сторінку «успіх» не дає підстав зараховувати кошти. Перш ніж платежі приймуть перехід стану, адаптер має перевірити справжність зовнішнього підтвердження та його зв’язок із потрібними обліковим записом провайдера, платежем, гравцем, валютою й сумою.

Як приклад правил конкретного провайдера, документація Stripe щодо вебхуків попереджає про повторну доставку й порушення порядку подій, а також вимагає перевірки джерела. Це ілюстрація інтеграційного ризику, а не рекомендація провайдера для iGaming чи спільний договір для всіх платіжних систем.

Коли узгоджене підтвердження платежу дозволяє зарахування, платежі запитують у гаманця проведення депозиту з одним стабільним ідентифікатором. Гаманець надійно зберігає операцію та зарахування разом. Якщо відповідь втрачена, платежі перевіряють або повторюють ту саму операцію за правилами взаємодії; вони не запитують нового зарахування з іншим ідентифікатором. До підтвердження проведення платежі можуть показувати «провайдер підтвердив; зарахування в гаманець очікується». Гравцеві потрібен цей зрозумілий проміжний статус, а не баланс, який платформа не може обґрунтувати.

Підтверджене проведення гаманця потім може запустити оцінювання бонусу. У прикладі гравець, який явно активував доступну йому пропозицію, отримує EUR 20 на окремо облікований бонусний баланс; умови дозволяють незалежно виводити грошові кошти, але виключають цей бонусний баланс із виведення. Це умовні правила, а не стандартна поведінка. Модуль бонусів зберігає активацію та версію умов, потім використовує окрему стабільну операцію гаманця для нарахування. Затримка бонусу не повинна повторювати депозит EUR 100 або призводити до його зникнення.

Пов’яжіть нарахування з відповідним депозитом і конкретною акцією, щоб повтор обробки не створив другого бонусу. Визначте поведінку, якщо право участі зміниться до активації або депозит згодом буде скасований: оцініть зачеплену акцію та вже витрачені кошти за узгодженими правилами. Автоматичне видалення попередніх зарахувань не відновить дій, які гравець уже вчинив.

Приймання ставки, операції гаманця й бонусний прогрес мають узгоджуватися

Тепер гравець ставить EUR 10 із грошового балансу. Ігрова інтеграція пов’язує акаунт, бренд, валюту, ігрову сесію та раунд провайдера зі стабільною операцією платформи. Вона перевіряє поточні дозволи й застосовні ліміти, потім узгоджує фінансування та приймання ставки за документованими правилами взаємодії.

Один із можливих варіантів — спочатку зарезервувати кошти, надіслати ігрову команду й перетворити резерв на проведення ставки після встановлення факту приймання. Це лише варіант, а не універсальний протокол: у деяких інтеграціях провайдер ініціює списання повідомленням, в інших використовуються інші схеми. Визначте реальне підтвердження приймання, момент фіксації фінансування та спосіб відновлення. Запуск гри не доводить існування ставки.

Дві вкладки можуть одночасно надіслати різні ставки. Гаманець має атомарно контролювати доступні кошти для обох: кожен запит може бути допустимим окремо, але їхня сума — ні. Спільним механізмам лімітів потрібен аналогічний захист від одночасних змін контрольованої величини. Придушення повторів саме по собі не запобігає перевитраті за різними операціями.

Для простого прикладу обліку припустімо, що прийнята ставка витрачає EUR 10 грошових коштів, потім провайдер повідомляє загальну грошову виплату EUR 15, включно з поверненою ставкою. Доступні грошові кошти змінюються з EUR 100 до EUR 90, потім до EUR 105. Невикористаний бонус EUR 20 залишається окремо. Адаптер має визначити, чи означає сума провайдера загальну виплату або чистий виграш: зарахування виплати й додаткове повернення ставки призвели б до переплати.

Розрахунок посилається на прийнятий раунд і використовує стабільну фінансову операцію. Бонусний прогрес залежить від фактичного розподілу коштів ставки та збережених умов акції; грошова ставка не зараховується автоматично до кожної пропозиції. Результат, що надійшов до необхідного запису раунду, має дочекатися з’ясування ситуації або потрапити до керованого процесу розбору винятку. Його не можна мовчки відкидати. Подальше скасування чи коригування — нова пов’язана операція, а не зміна, що стирає початковий розрахунок.

Для виведення потрібні резерв коштів і відновлюваний процес виплати

Гравець запитує EUR 40 із грошового балансу EUR 105. За умовами прикладу, якщо дія пройшла актуальні перевірки акаунта, ризику та виведення, гаманець резервує EUR 40 під це виведення. Доступно тепер EUR 65, у резерві — EUR 40; загальна сума грошових коштів ще не виплачена. Бонусний баланс до цього розрахунку не входить.

Процес виплати зберігає свою операцію, посилання на одержувача, перевірки та необхідний розгляд. Платежі надсилають запит провайдеру зі стабільним зовнішнім ідентифікатором, який підтримує інтеграція. Погодження працівником дозволяє виконання заявки; воно не доводить виплати провайдером. Унеможливте надсилання другої виплати паралельними обробниками або повторними погодженнями.

Якщо провайдер остаточно відхилив виплату до переказу коштів, звільніть резерв пов’язаною операцією гаманця. Якщо узгоджені підтвердження доводять завершення виплати, спишіть резерв і збережіть цей результат. Якщо після надсилання сплив час очікування відповіді, явно позначте невідомий результат і з’ясовуйте його за початковим посиланням. Не можна звільняти резерв і водночас пробувати іншого провайдера: обидві виплати згодом можуть пройти.

Для скасування потрібна так само точна межа. Гравець може запитати скасування, але до повернення зарезервованих коштів у доступні платформа має встановити, чи можна ще зупинити зовнішню виплату. Сплив строку закріплення завдання за обробником не доводить, що його зовнішня команда не виконалася. Якщо провайдер не забезпечує надійної перевірки результату або захисту від повторів, відновлення може потребувати ручного підтвердження у провайдера замість автоматичного повтору.

Статуси для гравця й підтримки мають мати однаковий операційний зміст: на розгляді, очікується результат у провайдера, виплачено, відхилено або скасування з’ясовується. Показуйте доречні відомості, не розкриваючи чутливих документів і платіжних реквізитів доступу. «Завершено» має відображати обране підтвердження фінансового результату, а не факт виконання завдання черги.

Координуйте незавершену роботу, зберігаючи відповідальність модулів

Використовуйте синхронне рішення, якщо дії негайно потрібна відповідь відповідального модуля, і надійно збережену асинхронну роботу, якщо завершення може вийти за час запиту. Збережений процес може координувати резерв, розгляд, надсилання та результат виведення. Він має запитувати дії у предметних модулів, а не обходити їхні перевірки чи ставати другим гаманцем.

Рекомендації Microsoft щодо саг описують узгоджені локальні транзакції та компенсувальні дії, попереджаючи про збої компенсації й відсутність вбудованої ізоляції між сервісами. Тому рушій процесів не забезпечує спільного фінансового відкочування й не розв’язує проблеми одночасних змін балансу.

У запропонованому варіанті зберігайте поточний крок процесу, посилання на прийняті рішення, команду, що очікує виконання, строк, версію та відповідальну чергу відновлення. Після збою обробника перевіряйте цей збережений стан і запис операції в учасника процесу. Умовні переходи кроків не дозволяють конкуруючим обробникам завершувати несумісні гілки; стабільні ідентифікатори операцій учасників захищають від повторної зовнішньої роботи лише там, де сторона, що приймає запит, забезпечує захист від повторів. Кожного з цих механізмів окремо недостатньо.

Рекомендації AWS щодо transactional outbox пов’язують локальну зміну стану й запис вихідної події в одній транзакції бази. Окремий відправник передає події зафіксованих транзакцій. Документ також розглядає повтори та порядок доставки; цей підхід не робить зовнішню фінансову операцію атомарною з локальною транзакцією.

Застосуйте цей принцип до зарахування гаманця та його повідомлення. У разі збою відправника підтверджена робота очікує доставки, а запуск бонусу не втрачається назавжди. Споживачі мають надійно узгоджувати запис обробленого повідомлення зі своєю локальною зміною; подальшим зовнішнім діям потрібні власні правила операцій. Ідентифікатор події усуває повтор доставки, ідентифікатор операції визначає діловий результат, а ідентифікатор кореляції пов’язує весь шлях. Підмінювати перші два останнім небезпечно.

Amazon Builders’ Library пояснює ідентифікатори запитів від сторони, що викликає сервіс, їх атомарне збереження зі змінами, відхилення змінених параметрів і строки зберігання, залежні від сервісу. Ці властивості потрібні там, де повтор запиту здатний повторити дію; ідентифікатора в журналі недостатньо.

Узгодьте обмежену політику повторів для кожної межі й зберігайте відомості захисту від дублювання протягом підтримуваного періоду повторної обробки та відновлення. Після нього звіряйте старі запити, а не вважайте їх новими. Порядку потрібна область дії: у раунду, платежу або акції може бути своя послідовність. Час на годиннику не створює надійного спільного порядку. Перевіряйте допустимі переходи та версії; ставте в очікування справді відсутні передумови, відхиляйте суперечливі зміни й розбирайте неусунені прогалини.

Споживач подій для листів або звітності може відставати в разі збою, не скасовуючи коректного проведення гаманця. Відсутність обов’язкового рішення про дозвіл, навпаки, може вимагати призупинення чи відхилення нової дії. Явно визначте вибір для кожної залежності. Це дозволяє частково продовжувати роботу, не вважаючи обхід будь-якого компонента однаково безпечним.

Перевірте шлях гравця як послідовність обов’язкових правил взаємодії

Використовуйте наступну послідовність як робочий список для перевірки. Замініть усі прикладові стани й ролі відповідальними модулями та реальними правилами провайдера; для кожного пункту додайте відповідальну команду, очікуваний строк завершення та поріг передавання на розбір.

1. Акаунт створено → дію дозволено. Який стан акаунта, які перевірки потрібні для цієї дії та де приймається дозвіл? Підтвердження: посилання на гравця, версія правил і рішення. Відновлення: невизначеність перевірки особи або обмеження спрямовується до конкретної справи; сплив часу не перетворює її на дозвіл.
2. Депозит запитано → гаманець поповнено. Що підтверджує платіж, хто зберігає його нормалізований статус і яка операція виконує зарахування? Підтвердження: посилання провайдера, прийнятий перехід платежу та проведення гаманця. Відновлення: звірити підтверджений платіж без проведення; ніколи не зараховувати за поверненням браузера.
3. Відповідний депозит → бонус активовано. Яка пропозиція та версія умов застосовуються, чи має гравець погодитися на участь? Підтвердження: конкретна акція, посилання на депозит і проведення нарахування. Відновлення: завершити чи відхилити цю активацію без повторення депозиту; подальше скасування обробити за явними правилами.
4. Ставку запитано → раунд розраховано. Який модуль приймає раунд, як фіксується фінансування та що означає передана сума? Підтвердження: приймання, розподіл коштів і пов’язані проведення. Відновлення: з’ясувати невизначене приймання до звільнення коштів; обробляти коригування з посиланням на початковий раунд.
5. Виведення запитано → результат виплати встановлено. Коли резервуються кошти, коли дозволено зовнішнє надсилання та що підтверджує звільнення або списання резерву? Підтвердження: заявка, розгляд за потреби, посилання провайдера та операції гаманця. Відновлення: зберігати резерв за невідомого результату й з’ясовувати початкове надсилання.
6. Результат записано → результат видно. Які представлення можуть відставати, а які мають бути актуальними для рішення? Підтвердження: посилання на джерело, версія представлення та остання оброблена позиція. Відновлення: повторно обробити події або перебудувати представлення без повторення початкових фінансових команд.

Забезпечте операційній команді пошук ланцюжка цих посилань і часу очікування незавершених кроків. Розрізняйте затриману подію, відсутнє проведення й невідому зовнішню виплату: їм потрібні різні відповідальні та реакції. Визначайте пороги сповіщення за узгодженими строками процесу й договорами провайдерів, а не за вигаданими галузевими цифрами. Ведіть нерозв’язані випадки до узгодження записів; зелена панель HTTP не доводить завершення шляху гравця.

Для поглибленої перевірки використовуйте матеріали про межі модулів і відповідальність за рішення, проєктування гаманця та журналу проведень, платіжну оркестрацію та звірку й технічну перевірку платформи перед угодою. Наведена нижче перевірка інтеграції має показувати збережені результати й відновлення, а не лише успішне проходження інтерфейсу.

• Підтверджений депозит, перерване зарахування. Зупиніть обробку після збереження результату провайдера, потім окремо — після фіксації зарахування в гаманець, але до отримання відповіді. Відновіть обидва випадки: одне грошове зарахування, одна активація доступного бонусу, на який гравець погодився, та узгоджені статуси гравця й підтримки. Також доведіть, що за відсутності права участі бонус не нараховується.
• Одночасні ставки, повторний результат. Надішліть різні ставки, що разом перевищують доступні кошти; приймання має дотримуватися балансу й застосовних лімітів. Повторіть один розрахунок і доставте його до необхідного запису раунду. Відновіть обробку до одного проведення за цим розрахунком із правильним розумінням загальної виплати.
• Невідома виплата, спроба скасування. Нехай провайдер прийме виплату, а відповідь загубиться. Спробуйте повтор, скасування й надсилання іншим обробником. Доведіть, що кошти залишаються захищеними до встановлення початкового результату й відновлення не може створити другої виплати.
• Зміна обмеження та перервана доставка подій. Виконайте зміну обмеження одночасно з прийманням дії та перевірте документоване правило порядку. Перервіть роботу відправника після фіксації гаманця, потім повторіть доставку. Нові дії підпорядковуються обмеженням, раніше прийняті зобов’язання допускають відновлення, а представлення й обробка бонусів наздоганяють джерело без повторення грошових операцій.