Carrier billing-powered content and services face massive disruption from next month as Google starts to shift Chrome to HTTPS-by-default; a move that nullifies the header enrichment that powers the seamless user identification needed to run DCB billing.
The change – first announced by Google in late 2025 as part of Chrome 147 and that will begin to roll out from April – will see Chrome automatically attempt to upgrade website connections from HTTP to HTTPS wherever possible. From October this will be Chrome 154’s default setting.
The goal is to improve user security by preventing network-level interception and manipulation of web traffic. However, for DCB-backed services the move hits operator billing’s key advantage – automatic identification of users through header enrichment.
According to data from Digital Virgo, 90% of two-click payment flows will be impacted, as around 75% of mobile browser traffic is currently running on Chrome. Additionally, based on traffic data from Telecoming‘s global operator network, resultant HTTP-dependent identification failures could reduce DCB conversion by 40% to 55% on Chrome traffic alone.
Other browsers are likely to follow suit, so the industry is being urged to act to find alternatives to header enrichment, or risk serious disruption to DCB-backed services worldwide.
Why HTTPS impacts header enrichment
Header enrichment has long been used by mobile operators to simplify subscriber identification during mobile transactions. When a user accesses a service over mobile data, the operator’s gateway can insert additional HTTP headers containing identifiers such as the MSISDN.
This allows services to identify the subscriber automatically without requiring the user to enter their number manually. The approach has powered frictionless subscription sign-ups, carrier billing payments and mobile authentication services across the telemedia industry for years.
However, the system depends on mobile networks being able to inspect and modify web traffic and HTTPS changes that. Once a connection is encrypted using TLS, the request, including its headers, is protected end-to-end between the user’s browser and the destination server. This means intermediate network elements, including mobile operator gateways, can no longer read or modify the request.
In practical terms, traditional HTTP-based header enrichment becomes incompatible with strict HTTPS environments.
For telemedia services designed around seamless network identification, this will have a dramatic and immediate impact on how subscribers are recognised during billing and subscription flows.
The roll out of Chrome 147 starting in April is likely to see around 1 billion enhanced safe browsing users blocked. The introduction of Chrome 154 from October will apply this to 100% of Google users worldwide, with no exceptions, says data from Telecoming.
What are the alternatives?
Alternatives to header enrichment do exist. Digital Virgo, for example, has been quick to show a range of possible fixes. TLS Termination/HTTPS Header Enrichment, where a TLS proxy within the operator network terminates the TLS session, injects the MSISDN header, then re-encrypts the request before forwarding it is one fix. API IP Lookup/MSISDN resolution, where the operator exposes a REST/HTTPS API and the partner sends the source IP, the API returns the associated MSISDN is another.
MNOs and telemedia and mVAS companies can also look at MSISDN resolution via APN Private IP, where the operator maintains the private IP-MSISDN mapping (PCRF/AAA) and the partner resolves the source IP via a dedicated API.
The GSMA also has a potential solution through its GSMA Open Gateway/CAMARA Number Verification industry standard, developed with the Linux Foundation. This can silently verify the MSISDN via the data connection and works with 73+ operators worldwide and is largely interoperable.
But each comes with challenges and timeframe issues, as summarised by Digital Virgo in the chart below.
Structural changes needed
While these and other alternatives that can be implemented from today do exist, the move to HTTPS-by-default by Google may require a more structured and systemic shift for operators and mVAS companies.
The answer is not a patch, says Telecoming, it is a structural upgrade. Telecoming recommends migrating to a User Identification Platform (UIP): a dedicated component in the operator’s infrastructure that identifies the subscriber silently, without touching the HTTPS stream, and delivering a secure token to the merchant.
The user experience remains seamless. The merchant receives a privacy-safe identifier. The operator stays in control.
This approach is fully compatible with the GSMA’s global initiative to expose standardised telecom APIs — including Number Verify — to digital merchants worldwide. Deploying a UIP today positions your network for the next decade of mobile commerce, adds Telecoming.
Time for action is now
Whatever alternatives work for your business, the shift to HTTPS is going to happen and action is required right now to keep DCB-powered telemedia services running. Chrome 154 will make HTTPS-by-default happen and the key, according to David Lotfi, CEO of Evina, is to get business teams on the telco side involved early to get HTTPS ready header enrichment up and running. The same applies to all the other potential solutions.
****************************************
Have your say: we need your input
This is a key issue for the telemedia sector globally and, as a community, we need to come together to work out the real impact this might have on the sector and its services, as well as plotting a route through HTTPS implementation and beyond.
So, share this piece with your thoughts and comments, get in touch with and stay tuned for more on our collective approach to this rapidly evolving issue.
********************************************
