Panorama dell’AI‑commerce e ruolo di OpenAI

1. Che cos’è, in sostanza, l’AI‑commerce

Se l’e‑commerce classico è la storia «sei entrato nel sito — hai aperto il catalogo — hai messo nel carrello — sei passato attraverso tre moduli», l’AI‑commerce è quando l’interfaccia principale diventa il dialogo con ChatGPT. L’utente formula il compito in linguaggio naturale e l’agente dentro ChatGPT assume il ruolo di consulente, merchandiser e in parte product manager.

Le richieste non assomigliano a «category=calzini&price_max=20», ma a «scegli un regalo divertente, ma non troppo imbarazzante, per un collega fino a 20 dollari, che si possa inviare via email». L’agente interpreta il compito, fa domande di chiarimento, consulta il catalogo prodotti, spiega pro e contro delle opzioni e poi guida l’utente fino all’acquisto — e tutto ciò senza che l’utente veda il «carrello» come pagina separata.

Dal punto di vista dell’architettura, la ChatGPT App in questo momento si trasforma da «catalogo intelligente di regali» in un applicazione di commerce, in grado di:

1. Comprendere l’intento dell’utente e i vincoli (budget, tipo di regalo, paese, articolo digitale/fisico).
2. Selezionare SKU specifici dal product feed e spiegare la scelta.
3. Iniziare il processo d’acquisto tramite il protocollo standardizzato ACP (Agentic Commerce Protocol).

L’idea dell’AI‑commerce è che «catalogo + checkout» non siano un sito separato, ma il naturale proseguimento del dialogo che l’utente sta già avendo con GPT.

2. E‑commerce classico vs AI‑commerce

Per cogliere meglio la differenza, è utile mettere i due approcci a confronto. Di seguito — una tabella semplificata che non pretende di essere esaustiva, ma evidenzia bene il cambio di paradigma.

Conseguenza pratica: nell’AI‑commerce l’attenzione si sposta dal design visivo di «catalogo e carrello» sulla struttura e qualità dei dati, nonché sul protocollo formale di interazione tra ChatGPT, il vostro backend e il provider di pagamento. Il product feed e gli endpoint ACP diventano un «UI» importante quanto il widget stesso.

Nel negozio classico si può correggere parte della UX nel browser; nell’AI‑commerce il modello si affida quasi interamente ai dati e agli schemi che gli avete fornito: dalla descrizione del prodotto agli stati della sessione di checkout.

3. I mattoni di OpenAI Commerce

OpenAI non offre una «magica piattaforma di pagamento GPTPay» che faccia tutto da sola. Al contrario, esiste un insieme di specifiche e linee guida che descrivono, come collegare correttamente i merchant e i provider di pagamento esistenti al mondo di ChatGPT. Tra questi documenti, per noi sono particolarmente importanti quattro tasselli.

Primo, la Product Feed Specification. È il formato ufficiale con cui il venditore descrive il proprio catalogo prodotti: id, title, description, prezzo, valuta, disponibilità, immagini, ecc. Il feed funge da «fonte di verità strutturata» che OpenAI convalida, indicizza e utilizza per la ricerca, il ranking e il checkout all’interno di ChatGPT.

Secondo, la Agentic Checkout Specification. È un contratto REST per lavorare con l’entità checkout_session: l’API descrive come creare una sessione di pagamento, aggiornarla (per esempio al cambio di indirizzo o opzione di consegna) e completarla, nonché quali campi deve restituire il backend (importi, imposte, opzioni di fulfillment, link alla policy di reso, ecc.).

Terzo, la Delegated Payment Specification. È il protocollo con cui la piattaforma dell’agente (ChatGPT) ottiene un token di pagamento delegato dal provider di pagamento (per esempio Stripe Shared Payment Token) e lo passa al vostro backend, senza rivelare i dati di pagamento. Il token è limitato per importo, durata e altri parametri e viene utilizzato dal vostro backend per creare il pagamento reale presso il PSP.

Infine, l’Instant Checkout in ChatGPT — è una UX costruita sopra queste specifiche. Nella chat compare un’interfaccia di checkout compatta: prodotto selezionato, prezzo, indirizzo, metodo di pagamento. Sotto il cofano si basa sul Product Feed, chiama i vostri /checkout_sessions secondo l’Agentic Checkout Spec e usa il Delegated Payment per effettuare la transazione presso il PSP.

La buona notizia è che tutto questo non è un «API segreta di ChatGPT», ma specifiche aperte ACP (Agentic Commerce Protocol). Ciò significa che lo stesso backend può teoricamente funzionare anche con altre piattaforme AI, se anch’esse supportano ACP.

4. Ruoli e confini di responsabilità

E qui inizia la parte più interessante: quando nel sistema entrano i soldi, regolatori e avvocati diventano improvvisamente i vostri migliori amici. Per non fare confusione, è importante separare chiaramente i ruoli.

Il ruolo principale è della piattaforma dell’agente, nel nostro caso — ChatGPT. Essa detiene l’esperienza utente: chat, widget, Instant Checkout UI. La piattaforma avvia il flusso di commerce, seleziona i prodotti dal Product Feed, chiama i vostri endpoint ACP e mostra il risultato all’utente. Tuttavia, ChatGPT non diventa né proprietario del prodotto né provider di pagamento e non conserva i vostri dati di prodotto come «proprio catalogo» — usa esattamente il feed che voi gli avete fornito.

Il secondo ruolo è il merchant (seller, merchant‑of‑record). È il proprietario dei prodotti o servizi. Il merchant è responsabile del product feed (struttura, qualità, aggiornamento di prezzi e disponibilità), della corretta implementazione degli endpoint ACP (/checkout_sessions, webhook), della creazione e conservazione degli ordini, della consegna, del supporto e dei resi. La documentazione ACP sottolinea che il merchant rimane il venditore a tutti gli effetti, non la piattaforma dell’agente.

Il terzo ruolo è il provider di pagamento (PSP), ad esempio Stripe. Il PSP è responsabile dell’elaborazione dei pagamenti, del rispetto del PCI DSS e di altri requisiti, della conservazione dei dati di pagamento, della lotta contro frodi e chargeback. Nel contesto del Delegated Payment il PSP rilascia alla piattaforma dell’agente un token speciale (SPT), che poi viene utilizzato dal vostro server per creare il pagamento reale (per esempio un PaymentIntent in Stripe).

Il quarto e più importante ruolo è l’utente. Formula il compito, prende la decisione finale d’acquisto, dà il consenso al pagamento e, idealmente, legge i Termini / Privacy Policy che mostrate onestamente nell’interfaccia di checkout. Il product feed può contenere link a questi documenti e alla policy di reso per aumentare fiducia e trasparenza.

Per comodità, riassumiamo in una piccola tabella:

La separazione delle aree di responsabilità è importante non solo per i legali, ma anche per l’architettura. Ad esempio, se domani collegherete un secondo PSP, non dovrete riscrivere la ChatGPT App: basterà adattare il livello di Delegated Payment nel vostro backend. E se apparirà una seconda piattaforma AI che capisce ACP, potrete riutilizzare sia il product feed sia gli endpoint di checkout.

5. Come appare lo scenario d’acquisto «tutto nel dialogo»

Mettiamo tutto insieme e vediamo come appare uno scenario end‑to‑end di acquisto di un regalo digitale in ChatGPT dal punto di vista architetturale. È uno scenario semplificato, ma rende l’idea.

sequenceDiagram
  participant U as Utente
  participant C as ChatGPT
  participant G as GiftGenius App
  participant B as Merchant Backend
  participant P as PSP (Stripe)

  U->>C: "Compra un regalo digitale fino a 50 $"
  C->>G: callTool(find_gifts, budget<=50)
  G->>B: GET /catalog?budget_lte=50
  B-->>G: Elenco di SKU adatti
  G-->>C: Opzioni di regalo + metadati
  C-->>U: Spiega la scelta, propone opzioni
  U->>C: "Prendo questo"
  C->>B: POST /checkout_sessions (sku, price...)
  C->>P: Richiedere token di pagamento (SPT)
  C->>B: POST /checkout_sessions/{id}/complete (token)
  B->>P: Effettuare il pagamento
  B-->>C: Webhook sulla creazione dell’ordine
  C-->>U: Conferma d’acquisto

In termini ACP, qui avviene quanto segue:

1. L’agente usa il Product Feed (tramite il vostro backend) per selezionare SKU adatti.
2. Quando si decide «si compra», ChatGPT crea una checkout_session tramite il vostro /checkout_sessions secondo l’Agentic Checkout Spec.
3. Durante l’Instant Checkout ChatGPT richiede al PSP un token di pagamento delegato per un importo e un merchant specifici.
4. Questo token viene passato a POST /checkout_sessions/{id}/complete, il vostro backend crea il pagamento presso il PSP e genera l’ordine.
5. Quando l’ordine è pronto, il vostro server notifica OpenAI tramite webhook, dopodiché l’utente vede la conferma finale.

Per noi, in questa lezione è importante non tanto memorizzare i nomi degli endpoint, quanto vedere la struttura: feed → selezione SKU → checkout_session → pagamento → ordine → webhook. Nelle prossime lezioni analizzeremo ogni parte separatamente, inclusi i campi del feed, i campi della sessione di checkout e il formato dei pagamenti delegati.

6. GiftGenius: come la nostra App si inserisce nell’AI‑commerce

Fino a questo momento GiftGenius svolgeva il ruolo di «assistente per la scelta dei regali». Sapeva:

• chiedere all’utente per chi e per quale occasione serve il regalo;
• usare gli strumenti MCP per cercare nel proprio catalogo;
• mostrare le schede delle opzioni nel widget e inviare pulsanti di follow‑up in chat.

Dal punto di vista del commerce era un «discovery intelligente» senza acquisto reale. Nel mondo OpenAI commerce tale modalità corrisponde a un feed in cui per gli SKU è impostato enable_search = true, ma enable_checkout = false: i prodotti si possono trovare e discutere, ma l’Instant Checkout per essi è disabilitato.

Nel modulo di AI‑commerce trasformeremo gradualmente GiftGenius in un merchant pienamente integrato:

• aggiungeremo un Product Feed strutturato secondo la specifica OpenAI;
• progetteremo un ACP‑backend che sappia lavorare con le checkout_sessions;
• collegheremo il Delegated Payment tramite Stripe Shared Payment Token;
• insegneremo all’App a mostrare all’utente che può non solo scegliere, ma anche acquistare un regalo direttamente in chat.

Per evitare che tutto ciò sembri «magia nera», aggiungiamo nel nostro codice un piccolo livello tecnico che modella esplicitamente ruoli e passi del flusso di commerce. Tornerà utile per log e test interni.

// app/commerce/types.ts
export type CommerceRole = "user" | "chatgpt" | "merchant" | "psp";

export interface CommerceStep {
  id: string;
  role: CommerceRole;
  description: string;
}

Questi tipi aiutano a separare mentalmente «chi fa cosa» anche a livello TypeScript. Possiamo usarli, ad esempio, nei test o in una UI di debug all’interno del widget.

Un piccolo esempio di array di passi per lo scenario «regalo digitale fino a 50 $»:

// app/commerce/exampleFlow.ts
import type { CommerceStep } from "./types";

export const digitalGiftFlow: CommerceStep[] = [
  { id: "intent", role: "user", description: "Formulare la richiesta e il budget" },
  { id: "search", role: "chatgpt", description: "Selezionare SKU dal Product Feed" },
  { id: "checkout", role: "merchant", description: "Creare la checkout_session" },
  { id: "payment", role: "psp", description: "Eseguire il pagamento tramite token" }
];

Questo codice per ora non parla con nessuno in rete, ma crea già un utile «asse di coordinate», attorno al quale svilupperemo il vero codice ACP nelle prossime lezioni.

7. Mini‑esercizio: scomponete il flow «Comprami un regalo digitale fino a 50 $»

Alla fine della lezione è utile analizzare a mano quanto appena visto. Prendete la richiesta dell’utente:

«Comprami un regalo digitale fino a 50 $».

Compito — descrivere in 3–5 passaggi logici cosa succede dopo e, per ciascun passaggio, indicare chi lo esegue: ChatGPT, il vostro backend merchant, il provider di pagamento o l’utente stesso. Potete fare riferimento al diagramma sopra e all’array digitalGiftFlow, ma non è necessario coincidere punto per punto.

Ad esempio, potete iniziare dal passo in cui ChatGPT interpreta la richiesta e chiede dettagli all’utente (buono regalo digitale, regione del destinatario, a chi è destinato). Poi il passo in cui il vostro backend, tramite il Product Feed, cerca gli SKU idonei; quindi — la creazione di checkout_session, l’ottenimento del token di pagamento dal PSP e il completamento dell’acquisto.

Se volete, potete persino farlo direttamente in codice, aggiungendo qualche passo a digitalGiftFlow e renderizzandoli in un piccolo componente di debug nel widget. Questo esercizio allena bene l’abitudine a pensare non solo «al codice», ma anche ai ruoli nel protocollo.

Ecco un semplice endpoint API che potrebbe ricevere un «piano di flow» di questo tipo e loggarlo (per ora senza commerce reale):

// app/api/commerce/flow/route.ts
import { NextRequest, NextResponse } from "next/server";
import type { CommerceStep } from "@/app/commerce/types";

export async function POST(req: NextRequest) {
  const steps = (await req.json()) as CommerceStep[];
  console.log("Planned AI-commerce flow:", steps);
  return NextResponse.json({ ok: true, stepsCount: steps.length });
}

Nella vita reale, invece di console.log scriverete log strutturati e, forse, conserverete questi scenari come parte della documentazione o dei test. Ma anche un esempio così piccolo aiuta a collegare l’architettura astratta con il TypeScript concreto della vostra app Next.js.

Se tenete a mente il quadro dei ruoli che abbiamo analizzato in questa lezione, i dettagli tecnici successivi — campi del Product Feed, schemi delle sessioni di checkout e struttura dei pagamenti delegati — risulteranno molto più semplici e senza eccessivo romanticismo attorno al «GPT onnipotente».

8. Errori tipici nella comprensione dell’AI‑commerce e dei ruoli

Errore n. 1: pensare che «ChatGPT farà tutto da solo».
A volte gli sviluppatori pensano che basti «collegare Stripe» e in qualche modo «dare al modello accesso all’API», e poi GPT sistemerà tutto. In realtà l’AI‑commerce attorno a ChatGPT poggia su specifiche formali: Product Feed, Agentic Checkout, Delegated Payment. Se non avete descritto i prodotti sotto forma di feed strutturato, non avete implementato /checkout_sessions e non avete configurato il Delegated Payment, nessun modello potrà inventarlo al posto vostro.

Errore n. 2: confondere i ruoli di ChatGPT e del merchant.
Un’altra confusione frequente è ritenere che ChatGPT diventi il «negozio» e che voi colleghiate solo il catalogo. In realtà è il contrario: voi restate il merchant, conservate il product feed, create e gestite gli ordini, gestite i resi. ChatGPT è responsabile soltanto dell’UX del dialogo e della corretta chiamata dei vostri endpoint ACP. Se cercate di progettare il sistema come se «GPT distribuisse autonomamente abbonamenti e inviasse i prodotti», prima o poi vi troverete in un vicolo cieco giuridico e tecnico.

Errore n. 3: ignorare il provider di pagamento come entità separata.
A volte si vorrebbe «nascondere» il PSP dentro il backend e parlare con lui come con una qualsiasi REST API, dimenticando che lo strato di pagamento vive secondo regole proprie (PCI, frodi, chargeback, limiti). Nell’approccio ACP non a caso è evidenziata una Delegated Payment Spec separata: la piattaforma dell’agente parla con il PSP al proprio livello, riceve un token SPT e ve lo passa, e siete voi a creare il pagamento. Se cercate di aggirare questo schema e accettare direttamente i dati delle carte nell’App, vi metterete rapidamente nei guai con i requisiti di compliance.

Errore n. 4: percepire il product feed come una «configurazione di marketing» e non come un’API per la LLM.
Molti arrivano con il background di Google Shopping e pensano al feed come a qualcosa di più importante per l’account pubblicitario che per il codice. Nel mondo dell’AI‑commerce il feed è, in sostanza, la base di conoscenza del vostro assortimento per il modello. Se contiene link alle immagini rotti, attributi incoerenti, unità di misura strane e iperboli di marketing al posto dei fatti, il modello proporrà ciò che non vi serve e la conversione calerà.

Errore n. 5: provare a introdurre l’Instant Checkout «in un solo passo».
La tentazione è forte: «attiviamo subito enable_checkout, così gli utenti comprano dalla chat». Ma senza un buon discovery (feed di qualità), senza un backend di checkout affidabile e senza un’integrazione ben pensata con il PSP, rischiate di ottenere un sistema fragile, in cui metà degli ordini resta sospesa a metà. È molto più sensato procedere per gradini, come suggerisce OpenAI: prima un Product Feed di qualità, poi il debug degli endpoint ACP, poi il Delegated Payment e solo dopo l’attivazione dell’Instant Checkout in produzione.