Крипто-казино
Torrent Gear
Як влаштована інтеграція платіжних систем
Платежі - це «аорта» онлайн-казино. Від того, як влаштована інтеграція з платіжними провайдерами (PSP), залежить конверсія в перший депозит, швидкість виведення, частка чарджбеків, навантаження саппорту і навіть репутація у регулятора. Нижче - практична карта: які компоненти потрібні, як тече запит, де ставити захист і що вважати.
1) Архітектура платіжного контуру
Основні блоки:- Каса (Checkout UI): вибір методу/валюти/суми, 3DS/SCA, статуси, помилки.
- Платіжний шлюз (Gateway): маршрутизація на PSP за правилами (країна, валюта, ризик, вартість).
- Гаманець (PAM/Wallet): облік балансу, ліміти RG, транзакції'debit/credit'.
- Антифрод/AML: скоринг операції до і після авторизації.
- Вебхукі (Callbacks): підтверджують фінальні статуси.
- Білінг/Згоряння (Reconciliation): щоденний збіг грошей в PSP і в гаманці.
- Сховище токенів: картки/гаманці через токенізацію PSP, без «сирих» PAN.
- Правила по країнах/банках/валютах/лімітах, A/B-лінії, автоматичний фейловер при деградації.
2) Потоки «депозит» і «виведення» (схеми)
Депозит (картка/гаманець/банкінг):1.'POST/payments/init'→ створити намір (amount, currency, method).
2. Редирект/SDK → 3DS/SCA/біометрія.
3. PSP повертає попередній статус (authorized/pending/failed).
4. Webhook PSP → фінальний статус (captured/failed).
5.'wallet/credit'по фіналу + запис лімітів RG/історії.
Висновок:1.'POST/payouts/init'→ перевірка вейджера/лімітів/ризику.
2. Ініціація payout в PSP (в ідеалі - той же маршрут, що і депозит).
3. Webhook PSP → success/failed.
4.'wallet/debit'при success, журнал причин при відмові, повідомлення гравця.
3) Ідемпотентність і зв'язність грошей
Кожен виклик - з'Idempotency-Key'і унікальним'txn _ id'.
Депозити/висновки змінюють баланс тільки один раз - за фінальним webhook.
Будь-який повтор запиту повертає той же'txn _ id'і статус.
У зв'язці з іграми: `round_id` ↔ `debit_txn_id`/`credit_txn_id`.
4) Безпека та комплаєнс
TLS 1. 2+/1. 3, HSTS; webhooks з HMAC-підписом і anti-replay ('timestamp', nonce).
Tokenization карт у PSP; PCI DSS scope-редукція (hosted fields/pages).
SCA/3DS2 для карток, PSD2/Open Banking для Pay-by-Bank.
GDPR: мінімізація PII, ретенція, DSR-процеси; журнал доступу до профілів.
mTLS/IP allow-list для з'єднань з PSP, сегрегація платіжного контуру.
5) Антифрод і AML (до і після платежу)
Pre-auth правила: гео/ASN, пристрій, velocity, поведінка, «pass-through».
ML-скоринг/граф: загальні карти/гаманці/пристрої, повторні chargeback.
Post-auth моніторинг: скасування, повернення, швидкий вивід.
AML-сценарії: пороги, structuring, незвичайні маршрути, звіти STR/SAR.
Step-up KYC: при середньо/високому ризику перед виведенням.
6) Вебхукі: Надійна доставка
Підпис HMAC, перевірка'timestamp'і дедуплікація по'event _ id'.
Ретраї на стороні PSP - ідемпотентні.
Логи доставки (success/fail), dead-letter queue і ручний «replay».
Webhook не змінює баланс, якщо не збігається сума/ідентифікатори.
7) Помилки і таймаути: дизайн відповідей
Коди: «402» (payment required), «409» (ідемпотентний конфлікт), «422» (валідація), «429» (rate-limit), «5xx» (інцидент).
Тіла помилок: «error», «message», «trace _ id», «details {...}» - допомагають саппорту і алертам.
Graceful retry на клієнті (експоненціальний бекофф), чіткі підказки в UI.
8) Роутинг і фейловер на кілька PSP
Правила якості: p95 авторизацій, конверсія, частка 3DS-фейлів, вартість.
Смарт-роутер: при погіршенні метрик - переведення трафіку на альтернативу.
Sticky-маршрут на сесію/банк для стабільності 3DS.
План деградації: вимкнення «важких» методів, залишаючи швидкі (P2P/Pay-by-Bank), черга висновків.
9) Згортання та фінанси (Reconciliation)
Щоденне вивантаження PSP і автосверку з гаманцем: збіг сум, комісій, повернень.
Розбіжності → кейси на розслідування.
Окремі звіти по chargeback/refund/fees, розрахунок справжньої маржі за методами.
10) Метрики, які треба тримати у фокусі
Конверсія депозиту за методом/банку/країні/пристрою.
Час депозиту/виведення (p50/p95).
Частка 3DS-фейлів, відмін, повернень, chargeback rate.
Частка ручних рев'ю і TTV KYC.
Uptime PSP і власний error-rate за маршрутами.
Cost per success і ROI за методами.
11) Приклад мінімального API (скорочено)
Створити намір депозиту- `POST /v1/payments/init`
json
{
"amount":"50. 00", "currency":"EUR", "method":"card", "return_url":"https://app. example. com/checkout/return", "idempotency_key":"b6a1-…", "meta":{"country":"FI","device":"ios"}
}Відповідь
json
{"payment_id":"pay_123","status":"pending","redirect_url":"https://psp. example/3ds/…"}- `POST /v1/payments/webhook` + `X-Signature: sha256=…`
json
{
"event_id":"evt_789", "payment_id":"pay_123", "status":"captured", "amount":"50. 00", "currency":"EUR", "timestamp":"2025-10-17T09:41:00Z"
}- `POST /v1/wallet/credit`
json
{"payment_id":"pay_123","txn_id":"txn_555","amount":"50. 00","idempotency_key":"b6a1-…"}12) Доступність і UX каси
Мінімум кроків: auto-detect країни/валюти, збережені токени методів.
Локальні методи: банківські кнопки, e-wallets, Apple/Google Pay.
Прозорість: комісії/ЕТА висновку, статус операції, зрозумілі помилки.
Доступність: великі елементи, контраст, screen readers, багатомовність.
13) DR/BCP і безпека операцій
Реплікація платіжних журналів, бекапи з шифруванням, щоквартальні DR-навчання.
RPO/RTO задокументовані, флоу «відкладених» виплат при збої PSP.
WAF/бот-менеджмент на касі, але винятки для редиректів/SDK PSP.
14) Часті помилки
Баланс змінюється до фіналу webhook → дублі/розсинхрон.
Ні'Idempotency-Key'→ повтор при мережевих збоях створює другу операцію.
Слабка перевірка підпису webhook → підміна статусів.
Відсутність автосверки з PSP → «тихі розбіжності».
Один PSP «на все» → простої і втрати конверсії при деградації.
Валідація 3DS/адресних полів «для галочки» → зростання чарджбеків.
15) Чеклист впровадження (збережіть)
- Мульти-PSP роутер, правила якості, фейловер
- Idempotency на кожному шарі ('txn _ id','Idempotency-Key')
- Webhooks: HMAC, anti-replay, логи доставки, дедуплікація
- Tokenization/hosted fields, PCI DSS scope-редукція
- 3DS2/SCA, PSD2/Open Banking де доступно
- Антифрод/AML до і після платежу, step-up KYC
- Автосверка звітів PSP, розбір невідповідностей
- Спостережуваність: p95 депозиту/виведення, 3DS fail-rate, uptime PSP
- DR-план, відкладені виплати, бекапи журналів
- UX каси: локальні методи, прозорі ЕТА/комісії, доступність
Хороша платіжна інтеграція - це не «підключити SDK», а вибудувати стійкий контур: мульти-PSP маршрутизація, сувора ідемпотентність, підписані webhooks, антифрод/AML, автосверку і спостережуваність. Такий стек підвищує конверсію, прискорює висновок, знижує ризики чарджбеків і робить платформу передбачуваною для гравців, партнерів і регуляторів.