GH GambleHub

On-ramp рішення і провайдери

1) Що таке on-ramp і навіщо він iGaming

On-ramp - це платіжний міст фіат → крипто (карта, A2A, локальні методи → стейблкоіни/ВТС/ЕТН та ін.), після чого кошти надходять на ваш кастодіальний/некостодіальний гаманець або субрахунок у провайдера. Користь для iGaming:
  • ↑ конверсія в регіонах з низькою картовою схвалюваністю;
  • ↓ комісії (при правильній мережі/активах) і швидкі фіналізації;
  • менше ризиків чарджбеків (при коректній архітектурі і верифікації).

Ризики: KYC/AML/KYT/санкції, Travel Rule, повернення і суперечки, волатильність, операційні помилки (мережа/тег), залежність від провайдера.

2) Моделі інтеграції

2. 1 Hosted (редирект/віджет провайдера)

Швидкий старт, готові KYC/AML/KYT/Travel Rule.
Мінуси: обмежений UX-контроль, залежність від флоу і лімітів провайдера.

2. 2 Embedded (вбудований SDK/iframe + серверні хуки)

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

2. 3 Hybrid

Hosted для «далеких» ринків/рідкісних методів, Embedded для core-географій/VIP.
Легкий фейловер між провайдерами і методами.

3) Методи оплати в on-ramp

Картки (Visa/Mastercard/локальні): високе охоплення, ризик чарджбеків → вимагайте 3DS/SCA, нормалізацію AVS/CVV.
А2А/банківські перекази (Open Banking, локальні схеми): низькі комісії, менше чарджбеков, але UX може бути складніше.
Локальні гаманці та ваучери: критично для LATAM/Азії/Африки.
Apple/Google Pay: як «надбудова» над картами - вище конверсія в мобілі.

💡 Політика: тримайте мінімум два методи на регіон, з можливістю авто-перемикання при деградації.

4) Активи та мережі

База: стейблкоіни (USDT/USDC на TRON, ETH-L2, BSC тощо), додатково BTC/ETH для VIP.

Правило: T0-конверсія в стейблкоін або фіат для зниження волатильності.
Узгодьте підтримувані мережі і обов'язковість мемо/тегів (TRX, XRP, XLM і т.п.).

5) Комплаєнс-ядро on-ramp

KYC/KYB: рівні, лівнес, PoA, SoF/SoW за тригерами.
AML/KYT/санкції: оцінка адрес/бірж/кластерів, заборона «високоризикових» маршрутів; щоденний рескринінг.
Travel Rule: обмін IVMS101-даними VASP↔VASP; політика для unhosted (підтвердження володіння адресою).
RBA: матриця «Low/Med/High» з різною глибиною перевірок і лімітами.

6) Фрод і авторизації

3DS2/SCA по картах (обов'язково для спірних BIN/гео).
Velocity-ліміти (card_token/device/ip/account), ретраї з backoff + jitter.
Скоринг транзакцій: device/geo/BIN/поведінка/граф; порогова логіка approve/challenge/decline.
Анти-аб'юз промо: caps по `device_id/ip/payment_fingerprint`, cool-off окна.

7) Економіка: з чого складається «вартість on-ramp»

Інтерчейндж/схемні витрати для карт + маржа провайдера.
Комісії А2А/локальних методів.
Крипто-комісії мережі (gas/fee) і висновки/депозити у провайдера.
FX/конверсія (якщо оплата в одній валюті, актив - в іншій).
KYT/Travel Rule (за повідомлення/перевірку).
Операційні витрати: ручні рев'ю, саппорт, chargeback/dispute.

💡 Оцінюйте Cost per Approved і Time-to-Finality, а не тільки «% комісії».

8) SLA, аптайм і деградації

Вимоги: аптайм ≥ 99. 9%, вебхукі ≤ 2-5 з p95, обробка Travel Rule ≤ 120 з p95, диспути ≤ T + 1.
Деградації: зростання'91/96 '/таймаути в картових потоках → авто-роутинг на А2А/альтернативу; затримки блокчейна → динамічні вікна підтверджень.
Фейловер: резервний провайдер, перемикання DNS/API-ключів, дублі мережі/активів.

9) Казначейство та зберігання активів

T0-хеджування в стейблкоіни/фіат, RFQ з декількома біржами.
Мультисиг/ліміти на висновки, незалежне підтвердження (4-око).
Роздільні баланси: робочий float, резерви під висновки, «холодні» сховища.
Політика курсів: єдине джерело цін/мультифід, відмітка часу курсу, правила повернень.

10) Облік і реконсиляція

Субрахунки на рівні клієнта/інвойсу, мепінг'invoice _ id ↔ txid ↔ wallet_subaccount'.
Реконсиляція T + 0/T + 1: суми, комісії мережі/провайдера, курси, статуси.
Експорт в DWH і звітність (податки/аудит), незмінні логи.

11) UX-практики (конверсія без втрат)

Авто-детекція мережі/мемо, QR/Deep-link, таймери актуальності адреси/курсу.
Статуси в реальному часі: «очікування підтверджень», «зараховано».
Address book/Whitelist з реверифікацією.
Зрозумілі помилки: «невірна мережа», «адреса без тегу», «ризик-адреса».
Локалізація методів і підказок по країнах.

12) Плейбуки інцидентів

Невірна мережа/без тегу: автоматичні перевірки на стороні UI/API, ручний розбір за регламентом (якщо можливе відновлення).
Сплеск чарджбеків: посилити 3DS/скоринг/velocity; тимчасово обмежити BIN/гео.
KYT high-risk за висновком: hold, запит SoF, Travel Rule, можливий SAR.
Падіння аптайма провайдера: переключення на резерв, інформування клієнтів у продукті.

13) Метрики та OKR

Approval Rate за методами/мережами, Time-to-Finality p50/p95.
Cost per Approved (all-in), КУТ/санкції reject%, SAR-conversion (якщо релевантно).
3DS rate / Challenge success%, velocity-FP%.
UX: помилки «невірна мережа/тег», частка повторних платежів (address book), drop-off у флоу.
Надійність: аптайм, затримки вебхуків, частота фейловера.

14) Анти-патерни

Єдиний провайдер без резервного каналу.
Прийняття активів «у будь-якій мережі» без валідації - втрати на невірних переказах.
Відсутність T0-конверсії/хеджу - волатильні збитки.
Ігнорування Travel Rule/KYT «через малі суми».
Зберігання приватних ключів без HSM/KMS/мультисиг.
Немає ідемпотентності і backoff - дублі і «шторми» ретраїв.

15) Чек-лист вибору провайдера (RFP)

Покриття та продукти

Мережі/активи (стейбл/TRON/L2, BTC/ETH), методи оплати (карти/А2А/локальні).
Географії, ліміти, пороги KYC/EDD, підтримка unhosted.

Комплаєнс

KYC/AML/KYT, Travel Rule (IVMS101, протоколи), санкції, періодичний рескринінг.
Політики RBA, журнали рішень, DPIA/ретеншн, звітність.

Техніка та SLA

Аптайм, латентність, вебхуки, sandbox, документація, швидкість інтеграції.
Failover, rate limits, анти-дублі, підписані вебхуки, версіонування API.

Економіка

Комісії з методів, мережа/висновок, FX, KYT/Travel Rule, об'ємні знижки.
Модель білінгу (per-txn/per-volume), settlement і звіти T + N.

Операції

Case-менеджмент, терміни диспутів, підтримка 24/7, мови.
Процедури інцидентів і повідомлень, прозорі статуси.

16) Приклад архітектури (референс)

On-ramp Gateway: єдина точка входу, оркестрація провайдерів, роутинг за гео/методом/ризиком.
Risk & Compliance Hub: 3DS/скоринг/velocity, КУТ/санкції, Travel Rule, RBA-матриці.
Treasury Service: T0-конверсія, мультисиг, ліміти, провайдери/біржі, курси.
Accounting/Recon: лейджер, звірка, звіти, DWH-експорт.
Status & Support API: статуси інвойсів/txid, кейси, шаблони відповідей.
Observability: логи/метрики/трейси, алерти SLA.

17) Резюме

Успішний on-ramp в iGaming - це не один провайдер, а архітектура: мульти-методи оплати, правильні активи/мережі, комплаєнс-ядро (KYC/AML/KYT/Travel Rule, RBA), казначейство і сувора реконсиляція, SLA/фейловер і доброзичливий UX. Такий контур підвищує конверсію в складних географіях, знижує вартість схваленого платежу і утримує ризики під контролем.

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Telegram
@Gamble_GC
Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.