GSMA Open Gateway и будущее идентификации в carrier billing: что нужно знать аффилиатам

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-офферы с волатильной конверсией.

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

Дата Событие Влияние
Апрель 2026 Chrome 147: HTTPS-by-default для пользователей Enhanced Safe Browsing (~1 млрд) Первая волна сбоев HE-зависимых флоу
Q2–Q3 2026 Операторы развёртывают краткосрочные решения (API IP Lookup, OTP-фоллбэки) Постепенное восстановление конверсии
Октябрь 2026 Chrome 154: HTTPS-by-default для ВСЕХ пользователей Chrome Полная депрекация HTTP header enrichment
Q4 2026 – 2027 Раскатка Number Verify и UIP ускоряется Новые frictionless-флоу заменяют старый one-click
2027–2028 Header enrichment становится legacy-термином Операторы, которые адаптировались, процветают; остальные теряют партнёров

Итог

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+ рынках.

Share

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *