GSMA Open Gateway and the Future of Carrier Billing Identity: What Affiliates Need to Know

GSMA Open Gateway and the Future of Carrier Billing Identity: What Affiliates Need to Know

If you work in mVAS, you have heard the headline: header enrichment is dying. Chrome 154 will enforce HTTPS-by-default for 100% of users in October 2026, making it impossible for operators to inject MSISDNs into unencrypted HTTP headers. The mechanism that powered frictionless one-click and two-click DCB flows for over a decade is going away.

The industry’s answer is GSMA Open Gateway — a global initiative to standardize telco APIs. And it is real: 86 operator groups, 300+ networks, 65 markets, 60+ channel partners. But what exactly does it change for carrier billing, and where does it leave affiliates?

This article breaks it down.

A Quick Recap: Why Header Enrichment Is Breaking

Header enrichment worked like this: when a user on mobile data visited an HTTP page, the operator’s proxy injected their MSISDN (phone number) into the request headers. The merchant or aggregator read that header and knew exactly who the user was — no login, no OTP, no friction.

HTTPS encryption makes this impossible. The connection between the user’s browser and the destination server is encrypted end-to-end. The operator’s proxy sits in the middle but cannot read or modify the encrypted payload. No injection, no enrichment, no silent identity.

According to industry data, 90% of two-click payment flows relied on header enrichment. Chrome represents 75% of mobile browser traffic globally. Estimates suggest that HTTP-dependent identification failures could reduce DCB conversion rates by 40–55% on Chrome traffic alone.

We covered the technical details in our previous article: Chrome’s HTTPS-by-Default: What It Really Means for Carrier Billing. This article is about what comes next.

What Is GSMA Open Gateway?

GSMA Open Gateway is an industry-wide initiative launched in 2023 to expose mobile network capabilities through standardized APIs. Think of it as a universal programming interface for telecom infrastructure — instead of each operator having proprietary systems, everyone uses the same API definitions developed under the CAMARA project (co-managed by GSMA and the Linux Foundation).

The scale is impressive:

  • 86 operator groups have signed the MoU
  • 300+ networks across all regions
  • 80% of global mobile connections covered
  • 65 markets with commercially launched APIs
  • 60+ channel partners including hyperscalers, aggregators, and CPaaS providers
  • 300+ API instances of 20 different CAMARA APIs deployed commercially

The APIs cover everything from fraud prevention to location services to quality-of-service controls. For the DCB and mVAS world, the most important ones are:

  • Number Verification — silently verifies that a device’s SIM matches a given phone number
  • SIM Swap Detection — checks whether a SIM was recently swapped (anti-fraud)
  • Device Status — confirms whether a device is currently connected to the network
  • KYC Match — verifies user identity attributes against operator records

Where Open Gateway Fits in Carrier Billing

An important distinction: Open Gateway does not replace the billing itself. Operators and aggregators (Boku, Digital Virgo, Telecoming, etc.) already have well-established payment infrastructure and single-API platforms that connect merchants to multiple operators. That part of the stack works and does not need a new standard.

What Open Gateway solves is the identity problem — knowing who the user is before the payment happens. And that is exactly the piece that header enrichment used to handle and that HTTPS is now breaking. The Number Verification API is the direct, standardized replacement for that identity layer.

Number Verify: The API That Actually Matters

The Number Verification API is one of the most commercially deployed CAMARA APIs, with instances live across dozens of markets.

How it works:

  1. The user visits a merchant’s payment page on their mobile device (over mobile data)
  2. The merchant initiates an OAuth2 authorization flow through the operator’s gateway
  3. The operator’s infrastructure silently verifies that the device’s SIM card matches the phone number provided — without any visible interaction from the user
  4. The merchant receives a true or false response

Key advantages over header enrichment:

  • Works over HTTPS — no unencrypted traffic needed
  • No MITM or TLS termination — the operator verifies internally, within its own infrastructure
  • CGNAT is not an issue — verification happens on the operator side, not through IP matching
  • Standardized — same API across all participating operators
  • Privacy-safe — uses OAuth2, the MSISDN is never exposed to unauthorized parties
  • Seamless UX — verification happens in the background, the user sees nothing

The limitation: Number Verify confirms identity, but it does not execute a payment. The billing still needs a separate mechanism — either the operator’s existing DCB infrastructure (via aggregators like Boku, Digital Virgo, or Telecoming) or PIN/OTP-based confirmation.

The Five Identity Solutions Actually Being Deployed in 2026

The DCB industry is not waiting for a single standard. Operators and aggregators are deploying a mix of solutions depending on their infrastructure, market, and timeline. Here is the realistic landscape:

1. PIN/OTP Flows (Already dominant)

The user enters their phone number, receives an SMS with a one-time code, and enters it to confirm identity and payment. This is the most universal solution — it works on any connection type (Wi-Fi, mobile data, HTTPS), is already deployed by most operators, and is required by regulators in many markets (especially in Europe and parts of MENA).

Impact on affiliates: More friction = lower conversion rates compared to one-click. But PIN flows are not new — many GEOs already required them before the HTTPS transition. If your campaigns ran on PIN-submit offers, nothing changes.

2. GSMA Number Verify API

As described above — silent, background verification of the SIM vs. MSISDN. This is the closest thing to a frictionless replacement for header enrichment and is actively being deployed across Open Gateway markets.

Impact on affiliates: If your target operator supports Number Verify, conversion flows can remain nearly as smooth as one-click header enrichment. Watch for aggregators announcing Number Verify integration — this will be a key differentiator.

3. HTTPS-Compatible Header Enrichment (TLS Termination)

Some operators are deploying TLS proxies that terminate the encrypted connection, inject the MSISDN, and re-encrypt. Technically it works, but it raises significant privacy concerns (GDPR exposure in Europe), takes 6–12 months to implement, and requires the operator to manage SSL certificates for third-party domains.

Impact on affiliates: If an operator deploys this, your existing one-click flows may continue working. But do not count on it — this is a stopgap measure, not a long-term solution.

4. API IP Lookup (MSISDN Resolution)

The operator exposes a REST API. The merchant sends the user’s source IP, and the operator returns the associated MSISDN. Faster to deploy than TLS termination (3–6 months), natively HTTPS-compatible, but requires dedicated commercial agreements and only works on mobile data connections.

Impact on affiliates: Transparent to end users — similar to header enrichment from a UX perspective. However, availability depends on individual operator deals with aggregators.

5. User Identification Platforms (UIP)

This is the approach advocated by aggregators like Telecoming: a dedicated component within the operator’s infrastructure that identifies the subscriber silently, without touching the HTTPS stream, and delivers a secure, anonymized token to the merchant. Think of it as a modern, privacy-safe version of header enrichment — but built as a platform rather than a protocol hack.

Impact on affiliates: Long-term, UIPs promise the smoothest user experience. But deployment is slow — these require deep operator-side infrastructure changes.

What This Means for mVAS Affiliates

The practical implications depend on what type of offers you run and where:

If you run PIN-submit offers

Nothing changes. PIN-submit flows are already HTTPS-compatible and do not rely on header enrichment. The Chrome transition has zero impact on your campaigns.

If you run one-click or two-click offers

Expect disruption between Q2 and Q4 2026. Chrome 147 (April 2026, Enhanced Safe Browsing users — ~1 billion) and Chrome 154 (October 2026, all users) will progressively break header-enrichment-dependent flows. The impact will vary by operator:

  • Operators with Number Verify or API IP Lookup deployed: minimal impact
  • Operators still on legacy HTTP header enrichment: conversion drops of 40–55%

Action items for affiliates

  1. Ask your CPA network: Which identification method does each offer use? If the answer is “header enrichment” — ask for the migration plan.
  2. Diversify GEOs: Markets where PIN/OTP is already the standard (most of Europe, parts of MENA) will not be affected. Markets that still rely heavily on one-click HE flows (parts of Africa, Southeast Asia) will see the biggest disruption.
  3. Watch aggregator announcements: Boku, Digital Virgo, and Telecoming are all building HTTPS-compatible solutions. When your aggregator announces Number Verify or UIP support for a specific operator, that is a green light.
  4. Test your offers on Chrome now: Enable “Always Use Secure Connections” in Chrome settings and test your flows. If they break, you know what is coming for everyone in October.
  5. Consider RevShare over CPA: In a transition period, conversion rates will fluctuate. RevShare offers with quality traffic may deliver more stable returns than CPA offers with volatile conversion rates.

Timeline: What to Watch

Date Event Impact
April 2026 Chrome 147: HTTPS-by-default for Enhanced Safe Browsing users (~1B users) First wave of HE-dependent flow failures
Q2–Q3 2026 Operators deploying short-term fixes (API IP Lookup, OTP fallbacks) Gradual recovery of conversion rates
October 2026 Chrome 154: HTTPS-by-default for ALL Chrome users Full deprecation of HTTP header enrichment
Q4 2026 – 2027 Number Verify and UIP rollouts accelerate New frictionless flows replace old one-click
2027–2028 Header enrichment becomes a legacy term Operators who adapted thrive; those who didn’t lose merchant and affiliate partners

The Bottom Line

GSMA Open Gateway is real and it is big — 86 operators, 300+ networks, 80% of global connections. It is not replacing the entire carrier billing stack — aggregators already handle multi-operator payments well. What Open Gateway delivers is the new identity layer — through Number Verify, SIM Swap, and related APIs — which is exactly the piece that header enrichment used to provide.

For affiliates, the transition is not a crisis. PIN-submit offers are unaffected. One-click flows will migrate to new identity mechanisms over 2026–2027. The operators and aggregators who move fastest will offer the best conversion rates — and that is the signal to watch when choosing offers and GEOs.

The smart play right now: ask questions, test your flows, and lean into markets and offers that are already HTTPS-ready. The DCB ecosystem is not dying — it is upgrading.

Ready to run mVAS offers across high-growth GEOs? Sign up with Affiliate Dragons — we work with top-tier operators and aggregators across 40+ markets.

Share

Leave a Reply

Your email address will not be published. Required fields are marked *