TL;DR
- DCB can adapt in an HTTPS world: Telenity’s MENA experience shows that OTP and operator APIs can replace traditional header enrichment, although added friction can reduce conversion.
- RCS offers a new payment journey: Mobile Business Engine’s early German rollout moves subscriptions into messaging, works over Wi-Fi and records customer consent, with performance still to be proven.
- PNV could restore simpler verification: Telenor Linx is developing a payment flow around Google’s phone number verification that removes SMS codes, but deployment depends on operator support and further integration.
|Watch the full session here |
For years, header enrichment has done much of the unnoticed work behind direct carrier billing. A customer arrives over a mobile network, the operator identifies the number and a subscription can be completed in a couple of clicks. Simple for the customer, valuable for the merchant and a significant part of DCB’s appeal.
Google’s move towards HTTPS by default puts pressure on journeys that still depend on unencrypted HTTP to identify that customer. But the discussion at Telemedia Marbella suggested that the industry’s most useful response is to build something better: secure identification, clearer consent and payment journeys that can also reach customers on Wi-Fi.
The session brought together experience from markets that have already moved away from conventional header enrichment with two approaches to replacing its role: an RCS-based subscription journey from Mobile Business Engine and phone number verification being developed into a payment flow by Telenor Linx.
They address different parts of the problem. Neither removes the need for operator involvement. Both suggest that preserving DCB’s ease of use need not mean preserving the technology that originally delivered it.
|Watch the full session here |
The power of ‘S’
First, the issue needs defining accurately. Google has announced that Chrome’s “Always Use Secure Connections” setting will become the default for public sites with Chrome 154 in October 2026. Chrome attempts HTTPS connections and presents a bypassable warning when HTTPS is unavailable. That creates an obvious commercial obstacle for a payment journey relying on an HTTP step, even if the customer can technically proceed.
It does not mean that secure operator identification is impossible. Frank Arnold from Mobile Business Engine said Germany had used tokenised mobile-number recognition for several years. Joost Goaree from Sam Media similarly pointed to tokenisation and other secure implementations being pursued by carriers elsewhere.
The exposure therefore varies by operator and market. The immediate task is to establish which acquisition journeys depend on the older mechanism, what replaces it and how the change affects their economics.
Luigi Mastrodicasa from Content for Mobile described the merchant’s predicament: adding manual number entry interrupts the familiar journey, threatening conversion and increasing acquisition costs. The merchant can monitor the impact and explore alternatives, but cannot modernise the operator’s infrastructure alone.
Amine Ennajih from Telenity offered a useful corrective to the idea that this is entirely a Google-created crisis. In some Middle Eastern markets, header enrichment had already been restricted following fraud, traffic injection and other abuses.
The first response was often SMS one-time-password (OTP) verification. Customers had to authenticate themselves, adding friction but also creating a record of their participation.
“Does it work? Yes. Does it cost you revenues? Of course, it did,” Ennajih said.
That is the uncomfortable trade-off facing merchants. Extra steps lose customers, especially when traffic has already been paid for. But Ennajih argued that the resulting business could be healthier, with clearer evidence that users initiated the session and authenticated themselves.
“You end up with pure traffic initially initiated by the users themselves,” he said.
Other operators could expose mobile numbers through APIs, shifting the integration effort into the systems behind the customer journey. Different markets adopted different approaches, reflecting regulatory requirements, operator priorities and the technology available.
The lesson is that OTP can keep a business operating while more seamless alternatives are developed. Its value should be measured against billing, retention and the quality of consent, alongside the loss at the subscription page.
An audience question also highlighted how much of this problem already exists. Customers using VPNs or Wi-Fi may already fall outside traditional header-enrichment journeys and receive a number-entry and OTP flow instead. For those customers, the industry has already adapted.
The opportunity is to improve that experience and widen the audience merchants can profitably acquire.
RCS: does messaging hold the key?
Arnold’s approach moves the interaction from the browser into messaging. Mobile Business Engine originally developed its RCS flow as a new DCB channel, its relevance to the header-enrichment problem emerged along the way.
“We saw or see RCS as a new channel or a new flow for DCB payment,” he explained.
In the German implementation presented at Marbella, a customer clicks an advertisement and enters an RCS conversation. Crucially, the customer must initiate the exchange through a pre-filled message expressing interest in the service. The agent then responds, and a further confirmation completes the subscription.
Arnold illustrated this with NBA League Pass, developed with Content for Mobile. The journey retains a double opt-in, but the interaction takes place in the messaging app rather than through browser pages dependent on header enrichment.
Its commercial attraction is that it works over Wi-Fi. Merchants who previously concentrated buying on mobile-network traffic could reach customers they had excluded because the preferred identification flow did not work.
It also leaves the customer with a visible conversation. When someone queries a charge, the service can point to the messages through which they requested and confirmed the subscription.
Whether that reduces complaints remains to be demonstrated. But it creates an opportunity to make the purchase easier to understand and easier to investigate.
Mobile Business Engine also sends a post-subscription message offering withdrawal from the payment. Arnold showed a button intended to support revocation and refund, bringing customer service into the same conversation.
The next step could be delivering some products there too. He described plans to supply a Düsseldorf newspaper’s e-paper as a PDF within the RCS flow. Messaging could therefore hold acquisition, purchase, delivery and support together.
There are important limits. At the session, Arnold said marketing had been running for only a week and there were no meaningful KPIs yet.
“We don’t know if people actually understand it,” he said.
Nor is it an unrestricted route from an advertisement into a messaging app. Arnold described months of discussions with Google and German operators to secure approval. Mobile Business Engine’s agent and participating merchants went through approval arrangements; the operator also had to trust the identification information passed into billing.
RCS changes where the journey happens, but the commercial and authentication relationships still have to work.
The interface needs attention too. Arnold showed differences between Android and iPhone presentation, including cropped images, restricted text and the effect of font settings. A purchase explanation that is clear on one handset may be incomplete on another.
A more familiar flow?
For merchants, the test is therefore broader than conversion. Can customers see the terms, understand the charge, access the product and find help across the devices being targeted?
Frode Alvad from Telenor Linx presented another route: retain a short digital journey, but replace the old identification mechanism with a secure verification process.
The approach builds on work with Google around Firebase Phone Number Verification, or PNV. Google’s published Android service obtains the number assigned to the device’s SIM directly from the carrier, with the user’s consent, and returns a signed verification token. It removes the need to receive and type an SMS code.
Alvad described Telenor Linx’s cloud-based entitlement server as the layer connecting operators to that capability. The ambition is to combine number verification and payment in a short customer journey. “It removes the one-time password completely,” he said.
That matters for usability and security: there is no verification code for the customer to mistype or be persuaded to hand to somebody else. It does not, by itself, remove every source of payment fraud or establish consent to every subsequent charge.
Alvad stressed that the user initiates the process and sees information explaining what is happening. Verification and the decision to buy need to fit together clearly. Like the RCS approach, it can reach beyond mobile-data traffic. Alvad highlighted Wi-Fi support; Google also documents PNV working across internet connections, including Wi-Fi.
The desktop flow Alvad presented uses a QR code: a customer starts on a computer, scans with their phone and continues through the verification journey.
However, the distinction between the underlying service and the proposed payment experience is important. Firebase PNV is generally available, but its public implementation is for Android apps and requires compatible devices and participating carriers. Google recommends an alternative verification method where support is unavailable.
Telenor Linx’s browser and payment integration was still work in progress at Marbella. Alvad had hoped to demonstrate it live, but said changes to Google’s platform had prevented that. His description should therefore be read as the direction of development, rather than a universally deployable replacement already proven across markets.
Pricing also remains part of the equation. Alvad floated five euro cents per successful transaction as an illustrative proposition, asking whether merchants would find that affordable. It was a discussion of the business case, not an announced tariff.
A verification fee might be worthwhile if it improves completion or opens access to more customers. That needs testing against the revenue those customers actually generate.
What it means for merchants
The common thread is operator participation. Secure APIs, trusted RCS billing and PNV-based payment all require carriers to support the technology and accept the resulting customer journey.
Sam Media’s Goaree warned that merchants bear the immediate impact when a flow changes because they fund acquisition. Advertising bids may eventually settle at a new profitable level, but the adjustment takes time.
He also raised a more fundamental commercial question. Easy identification is part of the value operators contribute to DCB and part of the justification for their share of revenue. If that advantage weakens, the commercial terms deserve examination too.
Merchants should therefore assess the whole transaction: acquisition cost, verification cost, successful billing, customer understanding and support burden. A flow that converts slightly fewer people may produce better subscribers. A flow that works on Wi-Fi may create a larger viable audience. A frictionless demonstration may still need considerable integration before it earns anything.
Marbella offered several credible directions, at different stages of readiness. The MENA experience shows that business can continue after header enrichment changes. RCS offers a new place to acquire and serve customers. PNV offers a way to rebuild secure number verification without asking them to copy a code.
DCB’s advantage has always been how little effort it asks of the customer. The task now is to preserve that convenience while making the purchase clearer, the identification more secure and the service available wherever that customer happens to be connected.
|Watch the full session here |
