La CMA vuole che Google permetta i link ai pagamenti esterni
La Competition and Markets Authority propone di obbligare Google a permettere link a pagamenti esterni nelle app Android, riducendo le commissioni.
La proposta della CMA mira a scardinare il monopolio dei pagamenti in-app di Google
Un link. Solo un link. Ma è il dettaglio tecnico attorno al quale si costruisce la proposta della Competition and Markets Authority (CMA), pubblicata ieri, che potrebbe aprire una crepa strutturale nel modello di controllo dei pagamenti di Google. La proposta introduce un cosiddetto steering conduct requirement: un requisito che obbligherebbe Google a consentire agli sviluppatori di indirizzare — letteralmente steer, come si sterza un veicolo — gli utenti fuori dall’app per completare transazioni a condizioni eque e ragionevoli. In altri termini, uno sviluppatore potrebbe inserire nella propria app Android un collegamento al proprio sito web o a un sistema di pagamento esterno, senza che Google possa bloccarlo o penalizzarlo. La consultazione pubblica su questa proposta rimarrà aperta fino al 28 luglio 2026.
Il protocollo di steering: un link che fa tremare il Play Store
Per capire perché questa proposta abbia un peso architetturale e non solo normativo, bisogna guardare a come funziona oggi il sistema di pagamento in-app di Google. Il Play Store impone agli sviluppatori di usare Google Play Billing per tutte le transazioni digitali all’interno delle app distribuite sulla piattaforma. Questo significa che ogni volta che un utente acquista un abbonamento, un contenuto aggiuntivo o una funzione premium, il pagamento transita attraverso le API di Google, che preleva una commissione — storicamente attestata attorno al 30% per i grandi publisher, ridotta al 15% in alcuni casi specifici. Nessun link a sistemi alternativi, nessun reindirizzamento, nessuna scorciatoia verso PayPal, Stripe, o la propria subscription page. Il muro è by design.
Lo steering, nella sua semplicità, è una soluzione architetturalmente elegante proprio perché non richiede di smontare l’infrastruttura esistente: basta rendere legittimo un <a href="...">. Non si tratta di imporre un’API alternativa, né di certificare gateway di pagamento concorrenti. Si tratta di permettere che l’app possa comunicare all’utente: “puoi completare l’acquisto anche qui, fuori da questa schermata”. Un meccanismo già conosciuto da chi ha seguito le vicende legali di Epic Games contro Apple, dove il concetto di steering era al centro delle dispute. Ma perché la CMA ha scelto proprio questo meccanismo? E, soprattutto, quali sono i precedenti normativi che hanno reso possibile questo intervento?
Il precedente: quando lo status SMS cambia le regole
Questa proposta non nasce dal nulla. Già nell’ottobre 2025, la CMA ha ridisegnato il campo di gioco: lo scorso 22 ottobre, l’autorità ha pubblicato la decisione finale con cui assegnava a Google la designazione SMS — Strategic Market Status — per la sua piattaforma mobile. Nella stessa tornata, anche Apple ha ricevuto la medesima classificazione. La designazione SMS di Apple e Google nelle rispettive piattaforme mobile non è un titolo onorifico: nel quadro del Digital Markets, Competition and Consumers Act britannico, essa abilita la CMA a imporre conduct requirements — requisiti di condotta vincolanti — direttamente alle aziende designate, senza dover attendere una pronuncia giudiziaria. È questa la leva che trasforma una consultazione normativa in una minaccia reale per l’architettura attuale del Play Store. Ora, la vera domanda è: cosa significa tutto questo per chi sviluppa?
Cosa cambia nello stack: pagamenti, commissioni e libertà di scelta
Superare il muro delle commissioni del 30% non era mai stato così a portata di URL. Se il requisito di steering venisse adottato nella forma proposta, uno sviluppatore potrebbe inserire nella propria app un collegamento diretto alla propria pagina di checkout — ospitata su un dominio proprio, gestita con Stripe, Paddle, o qualunque altro payment processor. L’utente clic, esce dall’app, completa il pagamento sul web, torna all’app con il contenuto sbloccato. Nessuna Google Play Billing API, nessuna commissione al Play Store per quella transazione. L’integrazione tecnica sarebbe banale rispetto agli standard attuali: deep link, URI scheme, o semplicemente un URL HTTPS. La complessità non è nel codice — è nel fatto che fino a ieri Google avrebbe potuto rimuovere l’app per violazione delle policy.
Le implicazioni per il revenue model degli sviluppatori sono concrete e immediate. Le app di abbonamento — streaming, SaaS mobile, utility premium — sono quelle che guadagnano di più da questo cambiamento: gestire direttamente la relazione di pagamento con l’utente significa poter applicare prezzi differenziati, offrire trial personalizzati, integrare sistemi di loyalty senza passare per le restrizioni del billing di piattaforma. Ma ci sono anche i trade-off. Uscire dal sistema di Google Play Billing significa rinunciare a una UX di pagamento già ottimizzata e familiare per l’utente medio Android, dover gestire autonomamente la conformità PCI-DSS, e affrontare friction aggiuntiva nel flusso di acquisto — ogni step fuori dall’app è potenzialmente un punto di abbandono. Non è una scelta banale: per app con volumi elevati e utenti tecnici, il guadagno netto è ovvio; per prodotti consumer di massa, il calcolo è meno scontato.
C’è poi una dimensione meno visibile ma altrettanto rilevante: la granularità del dato. Oggi, Google Play Billing è anche una fonte di dati transazionali per la piattaforma. Lo steering sposta quella conoscenza verso lo sviluppatore — e lontano da Google. Per chi costruisce app Android, l’architettura dei pagamenti sta per diventare un terreno di sperimentazione reale. Non più solo API di Google, ma un insieme di link, scelte progettuali e nuovi modelli di business da costruire fuori dal perimetro del Play Store.