What’s Happening: Chrome Goes HTTPS-by-Default
In October 2025, Google announced that with the release of Chrome 154 in October 2026, the browser will enable the “Always Use Secure Connections” setting for all users by default. Chrome will automatically attempt to load every website over HTTPS and will prompt users for permission before navigating to any HTTP page.
The first phase starts earlier — from April 2026, Chrome 147 will activate this feature for users with Enhanced Safe Browsing enabled. That’s over one billion people.
For regular users, the change is barely noticeable — according to Google, 95% of Chrome traffic already uses HTTPS, and fewer than 3% of navigations triggered a warning in tests. But for the mVAS and carrier billing industry, this move impacts a key mechanism: HTTP header enrichment.
What Exactly Breaks — and What Doesn’t
Before analyzing solutions, it’s important to understand: not all DCB flows are equally vulnerable.
The carrier billing industry uses several types of billing flows:
- 1-click — MSISDN is identified automatically via header enrichment; the user subscribes with a single tap
- 2-click — same as above, but with an additional confirmation step
- 1-click + PIN / 2-click + PIN — after clicking, the user receives an SMS PIN code and enters it to confirm
- PIN flow (without header enrichment) — the user enters their number manually, receives an SMS PIN, and confirms
What breaks: 1-click and 2-click flows that rely entirely on automatic identification via HTTP header enrichment. If the operator uses only HTTP headers to determine the MSISDN, these flows will stop working on HTTPS traffic.
What does NOT break: PIN-based flows. If the user enters their number manually and confirms via SMS PIN, header enrichment isn’t involved at all. These flows don’t depend on HTTP/HTTPS and will continue working as before.
This is important context. When projections of “40–55% DCB conversion drops” surface, they refer to a specific subset of flows — automatic identification via HTTP header enrichment. Not carrier billing as a whole.
How Header Enrichment Works and Why HTTPS Breaks It
Header enrichment is a technique where the mobile operator’s gateway automatically inserts the subscriber’s identifier (usually the MSISDN — phone number) into the HTTP request headers as they pass through the operator’s network.
With an HTTP connection, the request is transmitted in plaintext. The operator’s gateway sees the headers, adds X-MSISDN: 66812345678, and forwards it. The merchant reads the header and knows who the user is.
With an HTTPS connection, the request is encrypted end-to-end from browser to merchant server. The operator’s gateway sees only an encrypted stream — it cannot read or modify the headers. Header enrichment becomes impossible.
This is a fundamental limitation built into the TLS protocol itself: its entire purpose is to prevent anyone between sender and receiver from tampering with traffic.
Path 1: TLS Termination with Header Enrichment
How it works: The operator deploys a TLS proxy within their network. The proxy intercepts the HTTPS connection from the subscriber’s device, terminates the TLS session (decrypts it), injects the MSISDN into the headers, then establishes a new TLS connection with the merchant’s server and forwards the enriched request.
Pros:
- Preserves the familiar flow for merchants — they continue reading MSISDN from headers
- Requires no integration changes on the merchant side
- User experience appears unchanged on the surface
Challenges:
- This is MITM (man-in-the-middle). Technically, the operator positions itself between the user and the website, breaking end-to-end encryption. For this to work, the device must trust the operator’s proxy certificate. If the certificate isn’t installed, the browser will display a security warning.
- Certificate Transparency. Modern browsers, including Chrome, require all publicly trusted certificates to be registered in open Certificate Transparency logs. Operator certificates used for TLS interception may fail this verification.
- High cost and complexity. Deploying a TLS proxy in the operator’s core network is a major infrastructure project requiring hardware capable of real-time traffic decryption and re-encryption at scale.
Verdict: A working solution already used by some operators. But it’s a heavy and expensive path, and with browsers tightening Certificate Transparency requirements, its long-term viability is questionable.
Path 2: API-Based IP Lookup (MSISDN Resolution by IP)
How it works: The merchant captures the user’s IP address and sends it to the operator via a REST API. The operator matches the IP against their records (AAA/PCRF systems) and returns the MSISDN.
Pros:
- Doesn’t require tampering with HTTPS traffic
- Relatively simple integration
Challenges:
- Carrier-Grade NAT (CGNAT). The main problem. Due to IPv4 address exhaustion, most mobile operators — especially in developing markets — use CGNAT, a technology where hundreds or thousands of subscribers share the same public IP address. The merchant sees this shared IP and cannot determine which specific subscriber is behind it. Accurate identification would require IP + port, but merchants typically only see the IP.
- VPN traffic. If the user is on a VPN, their IP belongs to the VPN server. The operator cannot map this IP to a subscriber.
- Latency and unreliability. The API call adds a step to the payment flow and creates a point of failure. If the operator’s API is down or slow to respond, conversion drops.
- Per-operator integration. The merchant needs to connect to each operator’s API separately. There’s no unified standard.
Verdict: A weak solution. With CGNAT widespread across mobile networks, IP-based identification is unreliable. It’s a fallback for specific cases rather than a full replacement for header enrichment.
Path 3: Redirect via Operator Page
How it works: Instead of automatic identification via headers, the merchant redirects the user to the operator’s identification page (e.g., https://id.operator.com/verify). Since this is the operator’s own domain, the operator controls the server and can identify the subscriber on their end — through their internal network, without header enrichment. After identification, the operator issues a token and redirects the user back to the merchant.
Pros:
- Works over HTTPS without tampering with encryption
- No TLS interception or MITM required
- The operator identifies the subscriber within their own infrastructure — reliable and accurate
- Token is protected against forgery
Challenges:
- Extra redirect. The user passes through an additional page — this adds a step and can reduce conversion. Every redirect means some traffic loss.
- Token lifetime. Tokens are typically valid for 60–120 seconds. If the process takes longer, re-identification is needed.
- Non-standardized. Each operator implements their own page and API differently. Merchants need to adapt to each operator.
- User experience. A 1-click flow effectively becomes 2-click or 3-click. For markets accustomed to seamless subscriptions, this can be painful.
Verdict: A reliable and clean solution from a security perspective. Many operators already use this for PIN-based flows. The main downside is lower conversion due to the extra step.
Path 4: GSMA Open Gateway / CAMARA Number Verify
How it works: GSMA and the Linux Foundation developed a standardized API — Number Verify — that silently verifies the user’s phone number through their mobile connection. The request is initiated from the user’s device, passes through the operator’s network, and the operator confirms within their infrastructure that the number matches the SIM card in the device.
The key difference from IP Lookup: with Number Verify, the operator sees the device’s internal IP within their network (before CGNAT), not the public IP visible to the merchant. This is why CGNAT isn’t a problem — the operator verifies at the network level, not at the internet IP level.
Pros:
- Works over HTTPS, doesn’t require header enrichment
- No MITM or TLS termination needed
- CGNAT is not an issue — verification happens on the operator side
- Standardized — one API for all participating operators
- Already deployed commercially: 300+ API instances, 86 operator groups, 65 markets, 60+ aggregator partners
- Seamless user experience — verification happens in the background
Challenges:
- Coverage. Not all operators are connected yet. As of March 2026 — 86 operator groups, which is significant but far from 100% of the global market. In developing markets where DCB is especially popular, adoption may lag.
- Mobile data dependency. Number Verify only works when the device is connected via the mobile network. The request must go specifically through mobile data so the operator can verify the SIM.
- Integration required. Merchants need to integrate a new API. This isn’t a drop-in replacement for header enrichment — the payment flow needs to change.
- Maturity. Despite active scaling, the ecosystem is still evolving. Not all APIs are equally stable across all operators.
Verdict: The most promising and cleanest solution. Standardized, secure, doesn’t break TLS, solves the CGNAT problem. The main limitation is the speed of operator adoption. But the direction is set and scaling is progressing rapidly.
The Big Picture: The Panic Is Overblown, but Action Is Needed
Let’s bring it all together:
| Solution | Reliability | Implementation Complexity | CGNAT | Future Outlook |
|---|---|---|---|---|
| TLS Termination + HE | High | Very High | Not an issue | Questionable (Certificate Transparency) |
| IP Lookup API | Low | Medium | Critical problem | Dead end |
| Redirect via Operator | High | Medium | Not an issue | Viable, but lower conversion |
| GSMA Open Gateway | High | Medium | Not an issue | Industry standard |
And here’s the key point: Chrome’s HTTPS-by-default is not a sudden threat. It’s the final step in a process that has been underway for years. HTTPS became the web standard long before 2026. 95% of Chrome traffic is already encrypted. The fact that some operators in 2026 still rely exclusively on HTTP header enrichment is a legacy infrastructure issue, not a problem created by Google.
It’s also important to remember: PIN-based flows are not affected at all. And they make up a significant share of the DCB market, especially in regulated jurisdictions where PIN confirmation is mandatory.
What to Do Right Now
For operators:
- Audit: what percentage of DCB flows rely on HTTP-only header enrichment?
- If significant — start the migration. Options: HTTPS-compatible header enrichment (TLS termination), redirect-based flow, or connecting to GSMA Open Gateway.
- If the operator isn’t yet part of GSMA Open Gateway — it’s time to join. The ecosystem is growing, and falling behind will cost more than integration.
For publishers and affiliates:
- Check with each operator your traffic runs through: is their infrastructure HTTPS-ready?
- Diversify your flows: don’t rely entirely on 1-click header enrichment. PIN-based flows are a reliable fallback.
- Monitor GSMA Open Gateway adoption on your key markets.
For merchants and advertisers:
- Ask your payment partners: what identification method is being used? If it’s HTTP-only header enrichment — demand a migration plan.
- Prepare to integrate GSMA Number Verify API when it becomes available with your target operators.
The Bottom Line
Chrome’s HTTPS-by-default is not a threat to carrier billing. It’s a deadline for an infrastructure upgrade that many operators have been putting off for years. Technologies for working with HTTPS traffic exist — from TLS termination to GSMA Open Gateway. PIN-based flows aren’t affected at all.
The industry doesn’t need panic — it needs migration. The tools are there. The standards are set. Those who upgrade will keep working. Those who don’t will face the consequences of their own inaction, not Google’s.
At Affiliate Dragons, we work with operators and publishers across global markets and are closely monitoring this transition. If you want to understand how Chrome’s HTTPS changes affect your traffic and offers — get in touch with our team.
