In India alcuni utenti di Gemini e di AI Mode vedono un tasto Compra accanto ai prodotti Flipkart. Accanto ai prodotti Amazon, nella stessa risposta, il tasto non c’è. Lo ha documentato TechCrunch il 26 settembre 2026: test limitato a prodotti e utenti selezionati, estensione prevista più avanti in ottobre, prima della stagione di vendite delle feste indiane.

A un negozio WooCommerce in Ticino o in Italia la notizia indiana interessa per un dettaglio. Il tasto Compra porta a un checkout con il marchio Flipkart, sempre dentro l’interfaccia AI, e non al checkout ospitato da Google che l’azienda aveva presentato a gennaio. Il protocollo su cui Google costruisce questi acquisti prevede più di un modo per chiudere la vendita, e chi vende online dovrà sceglierne uno.

Le due strade

A: checkout nativo dentro l’agente. L’acquisto si chiude dentro Gemini o AI Mode, con Google Pay in pochi tocchi. Il negozio espone carrello, prezzi, spedizioni e tasse attraverso l’Universal Commerce Protocol (UCP), lo standard aperto che Google ha annunciato l’11 gennaio 2026 e che dichiara sviluppato insieme a Shopify, Etsy, Wayfair, Target e Walmart. L’interfaccia che il cliente vede è quella di Google. Nella guida per sviluppatori è il percorso predefinito e si chiama native checkout.

B: carrello trasferito al tuo sito. L’agente trova il prodotto e prepara il carrello, poi passa la mano: il cliente paga sulla tua pagina di checkout. Google ha aggiunto questa opzione il 20 maggio 2026, insieme all’Universal Cart. Nel protocollo il passaggio ha un nome preciso: quando il checkout richiede un intervento del cliente, il negozio risponde con lo stato requires_escalation e deve fornire un continue_url verso la propria pagina.

In entrambi i casi il venditore resta merchant of record: è lui che vende e risponde di pagamento, fattura e resi. Google lo scrive nell’annuncio di maggio e la specifica UCP lo ribadisce. La scelta vera riguarda un’altra cosa: chi controlla gli ultimi trenta secondi prima del pagamento.

C’è anche una terza via, ed è quella che somiglia al test Flipkart: la guida di Google la chiama embedded checkout, un checkout con il marchio del negozio caricato in un iframe dentro l’assistente, pensato per chi ha un branding molto personalizzato o flussi di checkout complessi. È riservato a commercianti approvati da Google, quindi per una PMI oggi non è sul tavolo. Resta la scelta fra A e B.

Il criterio: quanta logica di vendita sopravvive al passaggio

Un checkout WooCommerce reale non è un modulo con indirizzo e carta. È il punto dove vivono gli sconti a scaglioni, il campo per il codice destinatario della fattura elettronica, le spese di spedizione calcolate per CAP, la casella della newsletter, il prodotto suggerito prima del pagamento. Il criterio con cui confronto A e B è questo: quanta di quella logica arriva intatta fino al pagamento.

Criterio A: checkout nell’agente B: carrello al tuo sito
Attrito per il cliente Minimo: Google Pay, nessuna pagina nuova Un cambio di contesto e un modulo da compilare
Logica del checkout Va rifatta in API, riga per riga Resta dov’è, nei plugin che hai già
Tracciamento e cross-sell La tua pagina di ringraziamento non si carica Funziona come oggi
Lavoro di integrazione Alto, e ogni plugin nuovo lo riapre Più basso: sessioni UCP da gestire, ma il pagamento resta sul tuo checkout

Dove vince il checkout nell’agente

Sull’attrito A non ha rivali: il cliente ha già scelto nella conversazione e il pagamento è salvato nell’account Google. La specifica aggiunge un vantaggio meno visibile: il negozio non deve diventare conforme PCI DSS per accettare carte attraverso questo canale, perché le credenziali passano per i gestori di pagamento dichiarati nel profilo.

Il conto arriva sulla logica. La specifica pretende che la gestione delle sessioni di checkout sia deterministica: stessa richiesta, stessa risposta. Ogni regola che oggi vive in un hook PHP del checkout, il supplemento per le isole, lo sconto per il cliente registrato, il campo obbligatorio per le aziende, va riprodotta nelle risposte che il tuo server manda all’agente. Se non lo fai, l’agente mostra un prezzo e tu ne incassi un altro. E ogni plugin che installerai dopo riapre il lavoro.

Dove vince il carrello trasferito

B tiene tutto quello che hai già costruito. Il cliente arriva sul checkout che conosci, con i tuoi plugin, le tue regole fiscali, il tuo tracciamento sulla pagina di ringraziamento. Le sessioni di checkout UCP vanno comunque gestite, ma quando serve il cliente torna sul tuo sito con il continue_url e il pagamento passa dalla logica che hai già.

Il prezzo è il passaggio in più. Chi compra da un assistente AI si aspetta di chiudere lì, e un’uscita verso una pagina esterna è il punto dove una parte dei clienti lascia perdere. Quanto costa quel passaggio nel tuo caso non lo sa nessuno: nessuno ha ancora pubblicato numeri di conversione per questo canale, e il test Flipkart non dà dati.

La mia scelta: B oggi, A solo per il catalogo semplice

Per una PMI su WooCommerce parto da B, per due ragioni. La prima è tecnica: le integrazioni UCP che trovi oggi nel repository di WordPress.org sono plugin di terze parti, e quello con il nome più esplicito dichiara una trentina di installazioni attive. Affidare il checkout a codice con quella base di utenti vuol dire fare da collaudatore. La seconda è di mercato: Flipkart, in cui Google ha investito circa 350 milioni di dollari nel 2024, nel test visto da TechCrunch non usa la schermata di pagamento di Google. Il cliente resta nell’assistente, ma l’ultima schermata porta il marchio Flipkart. Non sappiamo quale tecnologia ci sia dietro. Leggo il segnale così: chi ha quel peso si tiene l’ultima schermata, e una PMI senza accesso alla via embedded la conserva solo con B.

A ha senso in un caso preciso: catalogo con prezzi fissi, poche varianti, una sola tariffa di spedizione e nessun plugin che tocca il checkout. Lì la logica da replicare è quasi zero e l’attrito ridotto è un guadagno netto. Negli altri negozi il checkout nell’agente è un secondo checkout da mantenere, e i secondi checkout divergono.

Cosa fare questa settimana

  1. Elenca i plugin attivi che modificano prezzo, tasse, spedizione o campi del checkout.
  2. La mia regola pratica: se sono più di due, scegli B e non guardare A finché il protocollo non ha un’integrazione mantenuta da chi mantiene WooCommerce.
  3. Sistema prima il catalogo: senza dati prodotto leggibili nessun agente ti propone, in nessuna delle due strade. Ne ho scritto in WooCommerce: gli agenti AI ti leggono?
  4. Se vendi anche con campagne, confronta il canale con quello pubblicitario: Sponsored Agent o landing page.
  5. Dal lato di chi compra con un agente, i controlli su budget e approvazioni sono in Agenti AI e pagamenti: 7 controlli per le PMI.

In sintesi: finché il tuo checkout ha regole proprie, tieni il pagamento sul tuo sito.

Fonti

Approfondimenti