GSMA Open Gateway і майбутнє ідентифікації в carrier billing: що потрібно знати афіліатам

Якщо ви працюєте в mVAS, ви вже чули головну новину: header enrichment помирає. Chrome 154 увімкне HTTPS-by-default для 100% користувачів у жовтні 2026 року, що зробить неможливою ін’єкцію MSISDN у незашифровані HTTP-заголовки. Механізм, який забезпечував безшовні one-click та two-click DCB-флоу понад десять років, йде в минуле.

Відповідь індустрії — GSMA Open Gateway, глобальна ініціатива зі стандартизації телеком-API. І вона реальна: 86 операторських груп, 300+ мереж, 65 ринків, 60+ канальних партнерів. Але що конкретно вона змінює для carrier billing і що це означає для афіліатів?

Розбираємося.

Короткий екскурс: чому header enrichment ламається

Header enrichment працював так: коли користувач на мобільних даних заходив на HTTP-сторінку, проксі оператора вставляв його MSISDN (номер телефону) в заголовки запиту. Мерчант або агрегатор зчитував цей заголовок і точно знав, хто перед ним — без логіну, без OTP, без зайвих кроків.

HTTPS-шифрування робить це неможливим. З’єднання між браузером користувача та сервером призначення зашифроване end-to-end. Проксі оператора знаходиться посередині, але не може ні прочитати, ні змінити зашифровані дані. Немає ін’єкції — немає збагачення — немає прихованої ідентифікації.

За даними індустрії, 90% two-click платіжних флоу залежали від header enrichment. Chrome займає 75% мобільного браузерного трафіку у світі. За оцінками, збої HTTP-залежної ідентифікації можуть знизити конверсію DCB на 40–55% лише на Chrome-трафіку.

Технічні деталі ми розібрали в попередній статті: Chrome HTTPS-by-Default: що це означає для carrier billing. Ця стаття — про те, що буде далі.

Що таке GSMA Open Gateway?

GSMA Open Gateway — це загальногалузева ініціатива, запущена у 2023 році для надання можливостей мобільних мереж через стандартизовані API. Уявіть це як універсальний програмний інтерфейс для телеком-інфраструктури — замість пропрієтарних систем кожного оператора всі використовують однакові визначення API, розроблені в рамках проєкту CAMARA (спільно керованого GSMA та Linux Foundation).

Масштаб вражає:

• 86 операторських груп підписали меморандум
• 300+ мереж у всіх регіонах
• 80% глобальних мобільних підключень охоплено
• 65 ринків із комерційно запущеними API
• 60+ канальних партнерів, включаючи гіперскейлерів, агрегаторів та CPaaS-провайдерів
• 300+ екземплярів API з 20 різних CAMARA API розгорнуто комерційно

API охоплюють все: від запобігання шахрайству до сервісів геолокації та управління якістю сервісу. Для світу DCB та mVAS найважливіші:

• Number Verification — безшовно перевіряє, що SIM-картка пристрою відповідає вказаному номеру телефону
• SIM Swap Detection — визначає, чи була SIM нещодавно замінена (антифрод)
• Device Status — підтверджує, чи підключений пристрій до мережі
• KYC Match — верифікує атрибути особистості користувача за записами оператора

Яке місце Open Gateway займає в carrier billing

Важливе уточнення: Open Gateway не замінює сам білінг. У операторів та агрегаторів (Boku, Digital Virgo, Telecoming тощо) вже є налагоджена платіжна інфраструктура та єдині API-платформи, які підключають мерчантів до безлічі операторів. Ця частина стеку працює і не потребує нового стандарту.

Open Gateway розв’язує проблему ідентифікації — визначення, хто саме є користувачем, до моменту платежу. А це саме та задача, яку раніше виконував header enrichment і яку тепер ламає HTTPS. Number Verification API — це пряма стандартизована заміна для цього шару ідентифікації.

Number Verify: API, який дійсно має значення

Number Verification API — один із найбільш комерційно розгорнутих CAMARA API, що працює на десятках ринків.

Як це працює:

1. Користувач заходить на платіжну сторінку мерчанта з мобільного пристрою (через мобільні дані)
2. Мерчант ініціює OAuth2-авторизаційний флоу через шлюз оператора
3. Інфраструктура оператора безшовно перевіряє, що SIM-картка пристрою відповідає вказаному номеру телефону — без будь-якої видимої взаємодії з користувачем
4. Мерчант отримує відповідь true або false

Ключові переваги перед header enrichment:

• Працює через HTTPS — незашифрований трафік не потрібен
• Немає MITM або TLS-термінації — оператор перевіряє всередині власної інфраструктури
• CGNAT не проблема — верифікація відбувається на стороні оператора, а не через зіставлення IP
• Стандартизований — один API для всіх операторів-учасників
• Безпечний для приватності — використовує OAuth2, MSISDN не розкривається неавторизованим сторонам
• Безшовний UX — верифікація відбувається у фоні, користувач нічого не бачить

Обмеження: Number Verify підтверджує особистість, але не виконує платіж. Для білінгу як і раніше потрібен окремий механізм — або існуюча DCB-інфраструктура оператора (через агрегаторів на кшталт Boku, Digital Virgo чи Telecoming), або PIN/OTP-підтвердження.

П’ять рішень ідентифікації, які реально впроваджують у 2026 році

Індустрія DCB не чекає єдиного стандарту. Оператори та агрегатори розгортають мікс рішень залежно від інфраструктури, ринку та термінів. Ось реалістична картина:

1. PIN/OTP-флоу (вже домінують)

Користувач вводить номер телефону, отримує SMS з одноразовим кодом і вводить його для підтвердження особистості та платежу. Це найуніверсальніше рішення — працює на будь-якому типі підключення (Wi-Fi, мобільні дані, HTTPS), вже розгорнуте у більшості операторів і є обов’язковим за вимогами регуляторів на багатьох ринках (особливо в Європі та частинах MENA).

Вплив на афіліатів: Більше тертя = нижча конверсія порівняно з one-click. Але PIN-флоу не новина — багато ГЕО вже вимагали їх до переходу на HTTPS. Якщо ваші кампанії працювали на PIN-submit офферах, нічого не змінюється.

2. GSMA Number Verify API

Як описано вище — безшовна фонова верифікація SIM vs. MSISDN. Це найближчий аналог frictionless-заміни header enrichment, який активно розгортається на ринках Open Gateway.

Вплив на афіліатів: Якщо цільовий оператор підтримує Number Verify, конверсійні флоу можуть залишатися майже такими ж гладкими, як one-click header enrichment. Слідкуйте за оголошеннями агрегаторів про інтеграцію Number Verify — це буде ключовим диференціатором.

3. HTTPS-сумісний Header Enrichment (TLS-термінація)

Деякі оператори розгортають TLS-проксі, які термінують зашифроване з’єднання, ін’єктують MSISDN і перешифровують назад. Технічно працює, але викликає серйозні занепокоєння щодо приватності (GDPR-ризики в Європі), займає 6–12 місяців на впровадження і вимагає управління SSL-сертифікатами для доменів третіх сторін.

Вплив на афіліатів: Якщо оператор це розгорнув, ваші існуючі one-click флоу можуть продовжити працювати. Але не розраховуйте на це — це тимчасова міра, а не довгострокове рішення.

4. API IP Lookup (резолвінг MSISDN)

Оператор надає REST API. Мерчант відправляє IP-адресу користувача, а оператор повертає пов’язаний MSISDN. Швидше в розгортанні, ніж TLS-термінація (3–6 місяців), нативно сумісний з HTTPS, але вимагає окремих комерційних угод і працює лише через мобільні дані.

Вплив на афіліатів: Прозорий для кінцевих користувачів — аналогічний header enrichment з точки зору UX. Однак доступність залежить від індивідуальних домовленостей операторів з агрегаторами.

5. User Identification Platforms (UIP)

Підхід, що просувається агрегаторами на кшталт Telecoming: виділений компонент в інфраструктурі оператора, який ідентифікує абонента безшумно, не торкаючись HTTPS-потоку, і доставляє мерчанту безпечний анонімізований токен. Уявіть це як сучасну, privacy-safe версію header enrichment — тільки побудовану як платформу, а не як протокольний хак.

Вплив на афіліатів: У довгостроковій перспективі UIP обіцяють найплавніший користувацький досвід. Але розгортання повільне — потрібні глибокі зміни інфраструктури на стороні оператора.

Що це означає для mVAS-афіліатів

Практичні наслідки залежать від того, які оффери ви крутите і де:

Якщо ви працюєте з PIN-submit офферами

Нічого не змінюється. PIN-submit флоу вже сумісні з HTTPS і не залежать від header enrichment. Перехід Chrome ніяк не впливає на ваші кампанії.

Якщо ви працюєте з one-click або two-click офферами

Очікуйте disruption між Q2 та Q4 2026. Chrome 147 (квітень 2026, користувачі Enhanced Safe Browsing — ~1 мільярд) та Chrome 154 (жовтень 2026, всі користувачі) послідовно ламатимуть флоу, залежні від header enrichment. Вплив відрізнятиметься за операторами:

• Оператори з Number Verify або API IP Lookup: мінімальний вплив
• Оператори на legacy HTTP header enrichment: падіння конверсії на 40–55%

Що робити афіліатам

1. Запитайте свою CPA-мережу: Який метод ідентифікації використовується в кожному оффері? Якщо відповідь «header enrichment» — вимагайте план міграції.
2. Диверсифікуйте ГЕО: Ринки, де PIN/OTP вже стандарт (більша частина Європи, частина MENA), не постраждають. Ринки, які все ще покладаються на one-click HE-флоу (частини Африки, ПСА), побачать найбільші потрясіння.
3. Слідкуйте за оголошеннями агрегаторів: Boku, Digital Virgo та Telecoming будують HTTPS-сумісні рішення. Коли ваш агрегатор оголосить про підтримку Number Verify або UIP для конкретного оператора — це зелене світло.
4. Протестуйте свої оффери в Chrome прямо зараз: Увімкніть «Завжди використовувати безпечні з’єднання» в налаштуваннях Chrome і протестуйте флоу. Якщо вони ламаються — ви знаєте, що чекає всіх у жовтні.
5. Розгляньте RevShare замість CPA: У перехідний період конверсія коливатиметься. RevShare-оффери з якісним трафіком можуть дати стабільнішу дохідність, ніж CPA-оффери з волатильною конверсією.

Таймлайн: за чим стежити

Підсумок

GSMA Open Gateway — реальна та масштабна ініціатива: 86 операторів, 300+ мереж, 80% глобальних підключень. Вона не замінює весь стек carrier billing — агрегатори і так добре справляються з мультиоператорними платежами. Open Gateway дає новий шар ідентифікації — через Number Verify, SIM Swap та суміжні API — тобто саме ту частину, яку раніше забезпечував header enrichment.

Для афіліатів перехід — не криза. PIN-submit оффери не зачеплені. One-click флоу мігрують на нові механізми ідентифікації у 2026–2027. Оператори та агрегатори, які рухаються найшвидше, запропонують кращу конверсію — і це той сигнал, за яким варто стежити при виборі офферів та ГЕО.

Розумний хід прямо зараз: ставте запитання, тестуйте свої флоу і робіть ставку на ринки та оффери, які вже готові до HTTPS. DCB-екосистема не вмирає — вона оновлюється.

Готові працювати з mVAS-офферами на зростаючих ГЕО? Реєструйтесь в Affiliate Dragons — ми працюємо з топовими операторами та агрегаторами на 40+ ринках.