OpenAI introduce i pagamenti tramite agenti, inizialmente negli Stati Uniti. Per le aziende il lavoro parte da catalogo, accessibilità del sito e verifica delle transazioni.
Un cliente trova il tuo prodotto su ChatGPT e decide di comprarlo. L’agente apre il sito, seleziona la variante e arriva al checkout. Poi incontra un controllo antibot oppure il pagamento viene rifiutato perché la visita proviene da un browser nel cloud.
Il prodotto era quello giusto. Il percorso di acquisto, però, si è interrotto.
È uno dei problemi che le aziende devono considerare con l’arrivo di ChatGPT Wallet, annunciato da OpenAI il 13 novembre 2026. Il servizio permette agli agenti di pagare per conto dell’utente usando credenziali sostitutive della carta. Il cliente controlla l’acquisto e lo autorizza prima del pagamento, come spiega l’annuncio ufficiale di OpenAI.
Per un ecommerce, la domanda utile diventa molto concreta: il sito riesce ad accompagnare un agente dalla scheda prodotto fino a un ordine confermato?
Dove è disponibile e come funziona il pagamento
Il rilascio iniziale è graduale e riguarda gli abbonati ChatGPT Pro maggiorenni negli Stati Uniti, attraverso dots, con una carta idonea emessa negli USA e un indirizzo di fatturazione statunitense. L’annuncio non comprende la disponibilità per i consumatori italiani.
Prima dell’acquisto, l’utente verifica venditore, articoli, importo e carta selezionata, quindi autorizza l’operazione con un controllo come Face ID o impronta digitale.
La rete di pagamento genera un token che sostituisce i dati reali della carta. L’agente utilizza quella credenziale per completare il checkout. L’autorizzazione dell’utente, tuttavia, non equivale alla conferma dell’ordine: occorre verificare l’esito restituito dal venditore. È una distinzione richiamata anche nelle note di rilascio del 13 novembre.
Per le aziende italiane che vendono negli Stati Uniti, il tema merita già una verifica tecnica. Per le altre, rappresenta un’occasione per individuare gli ostacoli del percorso di acquisto, senza anticipare investimenti basati su una disponibilità futura ancora da confermare.
Wallet può usare il checkout esistente
La documentazione sui pagamenti chiarisce un aspetto importante: non è richiesta un’integrazione specifica di Wallet per utilizzare le pagine di checkout e i moduli di pagamento esistenti.
Il merchant continua a gestire ordine, evasione, assistenza e decisioni antifrode.
Questo ridimensiona il primo intervento da commissionare. Prima di chiedere allo sviluppatore un’integrazione, controllerei se il processo attuale funziona:
- scelta corretta di prodotto, variante e quantità;
- aggiornamento del carrello;
- calcolo di spedizione, imposte e totale;
- gestione degli errori del modulo;
- restituzione di un esito comprensibile dopo il pagamento.
Sono controlli che suggerisco come audit del sito. Un’integrazione aggiuntiva avrebbe senso dopo aver individuato un limite concreto del percorso esistente.
Feed, browser e plugin svolgono lavori diversi
Nel commercio tramite agenti è facile sovrapporre componenti che hanno responsabilità distinte.
| Componente | Che cosa permette di fare |
|---|---|
| Feed prodotti | Trasmettere dati strutturati del catalogo per la scoperta dei prodotti |
| Browser dell’agente | Visitare il sito e interagire con pagine e moduli |
| Plugin | Richiamare direttamente azioni esposte dai sistemi aziendali |
| Wallet | Supportare il pagamento autorizzato, dove disponibile |
Il feed non aggiorna il carrello e non conferma un acquisto. Prezzo e disponibilità devono essere ricontrollati dal sito o dall’integrazione quando il cliente agisce. La guida OpenAI ai feed prevede identificativi item_id stabili, scelta di paesi e valute e consegna del catalogo attraverso i metodi supportati dal portale.
Sul piano operativo, partirei dalla coerenza dei dati: lo stesso prodotto deve essere riconoscibile nel feed, nella pagina, nel carrello e nell’ordine. Se gli identificativi cambiano a ogni esportazione o una variante risulta disponibile solo in uno di questi passaggi, diventa più difficile individuare l’origine di un errore.
Il firewall deve riconoscere la richiesta prima di consentirla
Un browser utilizzato da un agente può incontrare blocchi imposti da CDN, WAF o sistemi di protezione dai bot.
OpenAI documenta l’impiego di Web Bot Auth, basato sulle firme HTTP previste da RFC 9421. Le richieste firmate includono gli header Signature, Signature-Input e Signature-Agent. La firma può essere verificata attraverso le chiavi pubbliche indicate nella documentazione sull’accesso degli agenti.
Questa verifica riguarda le visite del browser cloud: è distinta dai controlli sui crawler, compreso OAI-SearchBot.
Chiederei al sistemista di partire dai log di sicurezza: quali richieste vengono bloccate, da quale regola e in quale fase del percorso?
Non basta riconoscere una stringa nell’header per considerare attendibile una richiesta. L’eventuale eccezione deve dipendere dalla verifica della firma o dal riconoscimento effettuato dal provider. OpenAI indica che alcuni servizi, fra cui Cloudflare, Akamai, HUMAN e Vercel, verificano automaticamente le firme; se il traffico passa già correttamente, potrebbe non servire alcuna modifica.
L’antifrode può fermare un acquisto autorizzato
Superato il firewall, resta il controllo della transazione.
I sistemi antifrode possono utilizzare indirizzo IP e caratteristiche del browser come segnali di rischio. Un browser cloud può quindi provocare un rifiuto anche quando l’utente ha autorizzato l’acquisto.
OpenAI sta introducendo il trasferimento di alcuni segnali tramite l’header Forwarded, fra cui informazioni su rete, paese stimato, lingua e fuso orario. La disponibilità dei segnali può variare durante il rilascio, come specifica la guida per accettare i pagamenti.
Qui coinvolgerei insieme sviluppatore, responsabile ecommerce e fornitore antifrode. Prima di modificare le soglie, chiederei come vengono interpretate le transazioni degli agenti e quali informazioni arrivano realmente al sistema.
Come scelta tecnica, farei inoltre verificare la provenienza degli header prima di utilizzarli nelle decisioni: un valore ricevuto da una richiesta qualsiasi non dovrebbe diventare automaticamente un segnale attendibile.
Quando conviene sviluppare un plugin
Il browser può seguire il percorso già presente sul sito. Un plugin consente invece a ChatGPT di richiamare direttamente servizi aziendali tramite strumenti strutturati.
La guida OpenAI per i plugin commerciali descrive azioni come ricerca del prodotto, verifica delle varianti, gestione del carrello e checkout. Il backend mantiene il controllo di prezzi, disponibilità, stato della transazione e conferma.
La documentazione precisa anche che un plugin non è automaticamente più veloce: il risultato va misurato sull’intero percorso.
Per un’azienda valuterei questo investimento quando il percorso via browser mostra problemi ricorrenti, il catalogo richiede verifiche complesse oppure esistono già API affidabili per carrello e ordini.
Il progetto dovrebbe partire da poche azioni ben definite, con errori leggibili e stato persistente del carrello. Se un passaggio non può essere completato, deve esserci un punto chiaro da cui il cliente possa continuare.
Da dove partirei in azienda
Prima di pianificare lo sviluppo, farei lavorare insieme chi gestisce catalogo, sito e pagamenti su un prodotto rappresentativo.
Seguirei il percorso fino all’ordine, annotando blocchi, differenze di prezzo, richieste di autenticazione ed errori. Terrei poi separati tre esiti: acquisto approvato dall’utente, pagamento accettato e ordine confermato dal merchant.
È su questi passaggi che misurerei la preparazione dell’ecommerce. Essere trovati e consigliati da un assistente AI può aprire un’opportunità commerciale; riuscire a completare correttamente l’acquisto richiede che catalogo, infrastruttura e sistemi di pagamento funzionino insieme.