Checkout agentico

TL;DR — Il checkout agentico è la parte dello shopping con IA in cui dici «premi acquista per me». Quando un assistente IA trova un prodotto e completa l acquisto per te, quello è il passaggio finale della transazione: il checkout agentico. Nel flusso di pagamento delegato di OpenAI, l agente usa un token di pagamento con ambito limitato invece del numero grezzo della carta e, per qualsiasi cosa rischiosa (login o verifica aggiuntiva), si ferma e restituisce il controllo a una persona. È un elemento dei protocolli più ampi (ACP e UCP), non una cosa autonoma.

Che cos è il checkout agentico

La maggior parte dello «shopping con IA» riguarda la scoperta: chiedi a un assistente di trovare qualcosa e lui legge i feed dei prodotti dei merchant e suggerisce alcune opzioni. Il checkout agentico viene dopo: è il passaggio in cui l agente crea davvero l ordine, sceglie la spedizione, calcola imposte e costi di consegna, inoltra il pagamento e finalizza l acquisto.

La parola chiave è passaggio. Il checkout agentico non è un prodotto o un azienda separata. È la capacità di completare una transazione incorporata nei due grandi standard del commercio agentico: Agentic Commerce Protocol (ACP) di OpenAI e Stripe e Universal Commerce Protocol (UCP) di Google e Shopify. Se vuoi una panoramica, gli articoli fratelli su ciascuno la forniscono; questa pagina entra nei meccanismi del checkout.

Le tre cose che molti capiscono male

• «L IA compra senza alcun intervento umano». Non proprio. Entrambi i protocolli hanno un passaggio incorporato in cui si fermano e chiedono una persona: per un login, una verifica aggiuntiva della carta o una conferma. Un checkout davvero senza supervisione non è il modello previsto dalle specifiche.
• «L IA vede la mia carta di credito». No. Il pagamento viene passato come token con ambito limitato: un sostituto vincolato a un merchant, a un importo e a una finestra temporale, usabile una sola volta. Il numero grezzo della carta non arriva mai all agente.
• «È già normale: la maggior parte dei negozi lo offre». Anche no. A metà 2026 era ancora presto: solo circa una dozzina di negozi Shopify aveva attivato il checkout in ChatGPT prima che OpenAI ridimensionasse la versione completamente in chat nel marzo 2026.

Chi è responsabile se qualcosa va storto?

Il negozio da cui hai comprato resta il negozio: è il cosiddetto merchant of record. Gestisce ordine, rimborsi e contestazioni, proprio come in un acquisto online normale. La parte davvero intricata, che nessuno ha ancora risolto del tutto, è che cosa accade a un addebito contestato quando lo «shopper» era un agente IA. Ne parleremo nella scheda Avanzata.

Vuoi vedere la macchina a stati reale, come viene delimitato il perimetro dei token di pagamento, dove deve intervenire una persona e che cosa i merchant devono testare prima di attivare il flusso? Passa alla scheda Advanced.

TL;DR — Il checkout agentico è la capacità di completare una transazione nel commercio agentico: creare, aggiornare, completare o annullare una sessione di checkout e confermare l ordine. È un elemento di ACP e di UCP, non un protocollo autonomo. La struttura tecnica è una macchina a stati: ACP porta la sessione da not_ready_for_payment → ready_for_payment → (requires_escalation / authentication_required quando serve) → completed, mentre UCP segue incomplete → requires_escalation → ready_for_complete. Gli stati di escalation sono il punto deliberato in cui una persona entra nel ciclo. La delegazione del pagamento usa token con ambito limitato — legati al merchant, con importo massimo, scadenza e uso singolo — così l agente non gestisce mai una carta grezza. La conferma dell ordine è un push: i merchant inviano webhook POST con firma HMAC e oggetto completo. Il merchant resta merchant of record, quindi regolamento, rimborsi e chargeback spettano al merchant e al suo PSP; resta però genuinamente irrisolto, a metà 2026, il quadro probatorio per i chargeback. Prima dell attivazione, costruisci e testa retry sicuri rispetto all idempotenza, verifica le firme dei webhook e prova i percorsi di escalation.

Ambito: è il passaggio della transazione, non l intero protocollo

Il checkout agentico è una capacità. In ACP è proprio il blocco Agentic Checkout (uno dei cinque, insieme a Product Feed, Delegate Payment, Delegate Authentication e Orders/Webhooks). In UCP è la capacità di checkout dentro una specifica più ampia, negoziata per capacità. Gli articoli fratelli su ACP e UCP trattano il protocollo circostante e il contesto commerciale — qualità del feed, profilo /.well-known/ucp e implicazioni per la scoperta del pivot del marzo 2026. Questa pagina resta sui meccanismi del completamento della transazione: ciclo di vita della sessione, delegazione del pagamento, intervento umano, conferma dell ordine e responsabilità.

Un idea da portare qui dall articolo fratello su ACP, senza riaprire la discussione: gli agenti transano contro feed e API, non contro il tuo HTML scansionato. Qui quindi si ottimizza la affidabilità del checkout, non il testo della pagina.

La macchina a stati della sessione di checkout

La cosa più distintiva da capire sul checkout agentico, e quella che la maggior parte degli articoli salta, è che un checkout è una sessione con uno stato e che quello stato attraversa una macchina definita.

Il riferimento Checkout di ACP elenca l enumerazione completa degli stati: incomplete, not_ready_for_payment, requires_escalation, authentication_required, ready_for_payment, pending_approval, complete_in_progress, completed, canceled, in_progress ed expired. Il percorso felice è breve — not_ready_for_payment → ready_for_payment → in_progress → completed — con canceled come altro stato terminale. Secondo i concetti del ciclo di vita ACP, fornire un opzione di evasione richiesta porta la sessione da not_ready_for_payment a ready_for_payment; un pagamento fallito può riportarla a ready_for_payment per un nuovo tentativo.

Gli stati interessanti sono quelli che non fanno parte del percorso felice:

• requires_escalation / authentication_required — l agente non può procedere da solo; serve una persona o una verifica aggiuntiva (vedi la sezione successiva).
• pending_approval — in attesa di un approvazione, per esempio l autorizzazione di un ordine di acquisto B2B.
• expired — la sessione è scaduta (la CheckoutSession contiene expires_at).

È lo stesso progetto di fondo del checkout UCP, che attraversa incomplete → requires_escalation → ready_for_complete, dove requires_escalation restituisce il controllo a una persona tramite continue_url (ne parliamo nell articolo fratello su UCP). Due protocolli distinti, uno schema convergente: un checkout non può sempre terminare senza fermarsi a chiedere qualcosa a una persona. Non è una limitazione aggiunta dopo: è la forma centrale del progetto.

Una nota pratica per chi costruisce su ACP: una richiesta malformata restituisce un oggetto di errore a livello HTTP (type pari a invalid_request, request_not_idempotent, processing_error o service_unavailable). Un problema di logica commerciale dentro una sessione altrimenti valida torna invece come oggetto MessageError nell array messages[] della sessione, non come errore HTTP. Devi gestire entrambi: nei primi lavori di integrazione è facile confonderli.

Come funziona la delegazione del pagamento

L intero scopo del livello di delegazione del pagamento è che i dati grezzi della carta non arrivino mai all agente. Invece di consegnargli un numero di carta, i dati di pagamento dell acquirente vengono trasformati in un token con ambito limitato.

Secondo la specifica OpenAI sul pagamento delegato, il payload del pagamento delegato viene inviato direttamente al PSP o al vault del merchant e il PSP o il vault restituisce un token di pagamento limitato al pagamento delegato, fuori dall ambito PCI. Quel token è delimitato lungo quattro assi:

• reason — attualmente "one_time": uso singolo.
• max_amount — limita l addebito al totale del checkout; il token non può essere usato per addebitare di più.
• expires_at (RFC 3339) — il token ha una scadenza rigida.
• merchant_id + checkout_session_id — vincolati a un merchant e a una sessione.

Quindi un token delegato è vincolato al merchant, limitato nell importo, limitato nel tempo e monouso. È il meccanismo che consente a un agente di «spendere» senza affidargli una credenziale riutilizzabile della carta. Sul lato ACP, lo Shared Payment Token di Stripe è descritto come la prima implementazione compatibile con la Delegated Payment Spec, con l arrivo di altri PSP. UCP usa un modello disaccoppiato parallelo che separa gli strumenti di pagamento dai gestori (vedi l articolo fratello su UCP).

L ambito PCI è una decisione reale. La specifica OpenAI chiarisce che un integrazione diretta con la Delegated Payment Spec comporta la gestione diretta dei dati del titolare della carta e può incidere sul tuo ambito PCI; l integrazione diretta richiede lo status PCI DSS Level 1. Per la maggior parte dei merchant, il percorso tokenizzato (network token o PSP che gestisce la delegazione) è il modo per tenere i dati del titolare fuori dall ambiente. Scegliere tra «gestire direttamente i CHD» e «lasciare la tokenizzazione al PSP» è la prima decisione architetturale: la scheda Decision spiega come affrontarla.

Dove deve ancora intervenire una persona

«Lo shopper deve comunque autorizzare» è vero, ma vago. I trigger a livello di protocollo sono specifici e nominarli è il modo per progettare il passaggio di controllo invece di arrivare a un vicolo cieco silenzioso:

• 3-D Secure / step-up. ACP lo modella con InterventionCapabilities (i tipi supportati includono 3ds e address_verification), un livello enforcement (always / conditional / optional) e un display_context (native / webview / modal / redirect). L esito dello step-up torna come AuthenticationResult con valori come authenticated, denied, rejected, abandoned, canceled o not_supported.
• Stati requires_escalation / authentication_required. Sono gli stati della sessione che dicono «serve una persona o un controllo aggiuntivo prima di proseguire».
• approval_required B2B. L oggetto PaymentData contiene campi B2B (purchase_order_number, payment_terms, due_date, approval_required): il checkout agentico non riguarda solo il DTC.
• Passaggio con continue_url di UCP. Lo stato requires_escalation di UCP mostra un continue_url che l acquirente completa in autonomia (login, conferma, controllo dell età). Stesso punto di passaggio, protocollo diverso.

Il punto chiave è questo: una transazione che passa correttamente in escalation è molto meglio di una che finisce silenziosamente. Progetta i percorsi di escalation come flussi di prima classe, non come casi di errore.

La conferma dell ordine è un push, non un pull

Ecco un elemento che molti articoli concorrenti saltano. Dopo un acquisto, la piattaforma dell agente non resta a interrogare periodicamente la tua API per sapere lo stato dell ordine. È il merchant a inviare webhook firmati.

Secondo il riferimento webhook di ACP, i merchant inviano eventi dell ordine con POST affinché la piattaforma dell agente resti sincronizzata con lo stato reale dell evasione. Due tipi di evento lo trasportano: order_create per i nuovi ordini e order_update per i cambi di stato. Tra gli stati dell ordine citati figurano created, manual_review, confirmed, canceled, shipped e fulfilled. Tre dettagli contano per chi lo implementa:

• Le richieste devono essere firmate con una firma HMAC nell header Merchant-Signature. Le richieste senza firma o con firma errata ricevono 401.
• Il campo data deve contenere l oggetto Order completo, non delta incrementali. Ogni volta invii lo stato completo.
• Codici di risposta da gestire: 200 successo, 401 firma non valida, 429 limitazione del rate.

Quindi «come fa la piattaforma a sapere che l ordine è passato?» ha una risposta concreta: glielo dici tu, con una POST firmata e completa, e gestisci il back-pressure 429 della piattaforma.

Frodi, chargeback e responsabilità: che cosa è risolto e che cosa no

Questa è la sezione più onesta e più distintiva, quindi dirò chiaramente dove passa davvero il confine tra ciò che è «risolto» e ciò che resta «aperto».

Che cosa è risolto: il merchant of record. La specifica di pagamento di OpenAI dichiara che OpenAI non è il merchant of record: con ACP i merchant portano il proprio PSP e regolamento, rimborsi, chargeback e conformità restano al merchant e al suo PSP. Arjun Bhargava di Rye lo conferma in modo indipendente: entrambi i protocolli mantengono il merchant come merchant of record, responsabile di evasione, chargeback e contestazioni. È coerente con il framing del merchant of record negli articoli fratelli: portalo avanti senza ricostruirlo da capo.

Che cosa non è risolto: il quadro probatorio dei chargeback. Merchant of record dice chi sostiene la contestazione per impostazione predefinita. Non dice come vincerla quando il «cliente» è stato mediato da un agente IA. La difesa tradizionale dei chargeback si basa su tracce generate da persone (IP, dispositivo, comportamento di navigazione, un clic umano su «acquista»). I log di autorizzazione generati da un agente sono un tipo diverso di prova e le regole di contestazione dei circuiti di pagamento non sono state scritte per loro. Lo specialista frodi di Chargeflow Ben Herut descrive il commercio agentico come un nuovo livello di frodi e confusione che i sistemi legacy non sanno interpretare, e l analisi di Chargeflow è ancora più netta: non ci sono risposte pulite; circuiti, emittenti e piattaforme stanno ancora lavorando su queste domande.

I framework emergenti sono emergenti, non finiti. Il Trusted Agent Protocol di Visa è descritto come un framework basato su standard che consente ai merchant di verificare in tempo reale identità e intenzione dell agente, evitando l impersonificazione senza peggiorare l esperienza utente. Agent Pay di Mastercard (annunciato nell aprile 2025) usa «Agentic Tokens», un estensione del suo Digital Enablement Service. Secondo i resoconti di terze parti (Fintech Wrap Up / Finextra), si dice che la responsabilità di Mastercard segua le stesse regole delle transazioni tokenizzate standard — l emittente assume la responsabilità delle frodi quando il token è stato emesso e accettato correttamente in fase di autorizzazione — ma tratterei questa specifica attribuzione come riportata, non confermata finché non comparirà nei documenti Mastercard. Inoltre, la garanzia Visa di responsabilità zero per i consumatori protegge i titolari da addebiti non autorizzati; non risolve la questione della contestazione lato merchant, che è quella ancora aperta. Non confondere le due.

Che cosa devono implementare e testare i merchant

I contenuti esistenti danno consigli strategici (feed puliti, programmi fedeltà). Qui c è il livello operativo: che cosa costruire e verificare davvero prima di attivarlo:

• Decidi il tuo assetto PCI. Percorso tokenizzato/network token rispetto a gestione diretta dei CHD (Level 1). La maggior parte dei merchant vuole che sia il PSP a custodire la delegazione.
• Rendi i retry sicuri rispetto all idempotenza. ACP ha un tipo di errore request_not_idempotent per una ragione. Un agente (o una rete instabile) riproverà davvero una chiamata di creazione o completamento; invia una chiave di idempotenza e rendi sicure le chiamate ripetute con la stessa chiave, così non addebiti né crei due volte l ordine.
• Verifica le firme dei webhook. Valida l HMAC Merchant-Signature su ogni webhook di ordine in ingresso, rifiuta le firme errate e conferma di restituire 200/429 correttamente sotto carico.
• Simula in sandbox i percorsi di escalation. Forza requires_escalation / authentication_required, esegui uno step-up 3DS e conferma che la gestione di AuthenticationResult copra denied/rejected/abandoned, non solo authenticated.
• Riconcilia la parità di prezzo feed/checkout. Se l agente vede un prezzo nel feed e il checkout ne restituisce un altro, la fiducia si erode rapidamente: l articolo fratello su ACP lo dice per i feed, ma il problema pesa soprattutto al checkout.
• Predisponi l attribuzione degli ordini agentici. Un checkout agentico completato può arrivare senza una sessione GA4. Traccialo al livello dell ordine/OMS, non aspettare una visita al sito.

Le schede Testing SOP e Cheat Sheet trasformano tutto questo in un passaggio concreto.

A che punto siamo a metà 2026

Tieni i piedi nella realtà dell adozione, non nel pitch deck. Harley Finkelstein, presidente di Shopify, ha indicato che solo circa una dozzina di merchant Shopify usava attivamente strumenti di checkout con IA — un numero trascurabile rispetto alla base complessiva di merchant Shopify — e che OpenAI stessa ha ridimensionato la versione completamente in chat di Instant Checkout tornando a discovery-plus-redirect nel marzo 2026, dopo problemi di onboarding, accuratezza e carrelli con più articoli. Leigh McKenzie di Semrush ha descritto bene l attrito: normalizzare in tempo reale un catalogo di decine di milioni di SKU è un problema da scala decennale e i consumatori continuano a preferire flussi di checkout di cui si fidano — Apple Pay, Google Wallet, Amazon one-click.

Questo non significa che il checkout agentico sia fumo negli occhi. La capacità del protocollo — creare, aggiornare e completare una sessione in modo programmatico, con pagamento delegato e webhook firmati per gli ordini — è reale, specificata e merita di essere implementata. Semplicemente non è «già normale» e il fatto che l ultimo passaggio si chiuda in chat o sul tuo sito è un dettaglio di implementazione che è già cambiato una volta e può cambiare ancora.

Riepilogo IA

Una sintesi della versione Avanzata:

• Il checkout agentico è il passaggio di completamento della transazione nel commercio agentico: un agente crea, aggiorna, completa o annulla una sessione di checkout per conto del cliente. È un elemento di ACP e di UCP, non un protocollo autonomo.
• È una macchina a stati. ACP: not_ready_for_payment → ready_for_payment → (requires_escalation/authentication_required) → completed, con canceled, expired e pending_approval fuori dal percorso felice. Rispecchia incomplete → requires_escalation → ready_for_complete di UCP.
• Gli stati di escalation sono il punto human-in-the-loop: login, step-up 3DS, controllo dell indirizzo, approval_required B2B e continue_url di UCP. Un checkout completamente autonomo, senza persone, non è il modello delle specifiche.
• Il pagamento usa token con ambito limitato: vincolati al merchant (merchant_id + checkout_session_id), con importo massimo (max_amount), scadenza (expires_at) e uso singolo (reason: one_time). L agente non gestisce mai una carta grezza. Gestire direttamente i CHD incide sull ambito PCI (Level 1); la maggior parte dei merchant usa il percorso PSP/tokenizzato.
• La conferma dell ordine è un push: i merchant inviano webhook HMAC firmati (Merchant-Signature) con oggetto completo (order_create/order_update) e gestiscono 200/401/429.
• Responsabilità: il merchant resta merchant of record (regolamento/rimborsi/chargeback con merchant e PSP, secondo la specifica OpenAI), ma la questione probatoria dei chargeback (contestare un acquisto fatto da un agente IA) è irrisolta a metà 2026. Visa TAP e Mastercard Agent Pay sono framework emergenti, non conclusi.
• Test: retry sicuri rispetto all idempotenza (request_not_idempotent), verifica della firma dei webhook, percorsi simulati di escalation/3DS, parità del prezzo feed/checkout e attribuzione degli ordini agentici (senza sessione GA4).
• L adozione è iniziale: circa una dozzina di merchant Shopify attivi prima del pivot di OpenAI del marzo 2026 verso discovery-plus-redirect.

Documentazione ufficiale

Documentazione di fonte primaria sui meccanismi del checkout.

ACP: checkout, ciclo di vita e webhook

• Riferimento API del checkout ACP — endpoint della sessione, enumerazione completa degli stati, campi CheckoutSession, oggetti di errore/MessageError, RiskSignals, AuthenticationResult e InterventionCapabilities.
• Ciclo di vita e concetti del checkout ACP — transizioni di stato (fulfillment-option → ready_for_payment; retry dopo un pagamento fallito).
• Webhook degli ordini ACP — order_create/order_update, requisito HMAC Merchant-Signature, payload completi e codici di risposta.
• Specifiche ACP su GitHub — OpenAPI/JSON Schema e versioni basate sulla data.

OpenAI / Stripe: delegazione del pagamento

• Specifica OpenAI sul pagamento delegato — flusso dei token con ambito, oggetto allowance (max_amount, expires_at, merchant_id, checkout_session_id, reason), nota sull ambito PCI e formulazione del merchant of record.
• Documentazione Commerce di OpenAI — panoramica dell integrazione merchant.
• Stripe: commercio agentico (ACP) — Shared Payment Token, prima implementazione compatibile con il pagamento delegato.
• Stripe: specifica del protocollo ACP — costruzione degli endpoint di checkout.

UCP (macchina di checkout parallela)

• Guida UCP per Google Developers — formulazione su merchant of record ed eleggibilità nel lato Google/Shopify.

Piattaforma e circuito di pagamento

• Requisiti Shopify per gli Agentic Storefront — Supplemental Terms e, secondo la ricerca, stato di accesso anticipato a Google AI Mode/Gemini.
• Visa: commercio agentico, minacce e rischi — formulazione del Trusted Agent Protocol.

Citazioni dalla fonte

Dichiarazioni registrate su come funziona il checkout agentico e su dove restano le domande aperte. I deep link portano al passaggio citato quando la pagina sorgente lo supporta.

ACP / OpenAI: la specifica

• “Merchant maintains full control over inventory, pricing, tax calculations, and payment processing.” (traduzione) «L esercente mantiene il pieno controllo su inventario, prezzi, calcolo delle imposte e gestione dei pagamenti». — Riferimento API ACP sulla procedura di acquisto. Vai alla citazione
• Il riferimento ACP elenca l intera enumerazione degli stati; i token esatti sono riportati nella sezione Advanced. — Riferimento API ACP sulla procedura di acquisto. Vai alla citazione
• “OpenAI is not the merchant of record.” (traduzione) «OpenAI non è il merchant of record». Con ACP, i merchant portano il proprio PSP e regolamento, rimborsi, chargeback e conformità restano al merchant e al suo PSP. — Specifica OpenAI sul pagamento delegato. Vai alla citazione
• Sul flusso del token: il PSP o il vault restituisce un “payment token scoped to the delegated payment” (traduzione) «token di pagamento con ambito limitato al pagamento delegato», fuori dall ambito PCI. — Specifica OpenAI sul pagamento delegato. Vai alla citazione

Voci del settore: la questione della responsabilità

• “Agentic commerce brings efficiency, but also a new layer of fraud and confusion that legacy systems cannot interpret.” (traduzione) «Il commercio agentico porta efficienza, ma anche un nuovo livello di frodi e confusione che i sistemi legacy non sanno interpretare». — Ben Herut, stratega per frodi e chargeback presso Chargeflow. Leggi la copertura
• Sul fatto che le regole siano risolte: secondo l analisi di Chargeflow, “there are no clean answers yet” (traduzione) «non ci sono ancora risposte nette»: circuiti, emittenti e fornitori di piattaforma stanno ancora affrontando queste domande. Leggi la copertura
• “Both protocols keep the merchant as the merchant of record — responsible for fulfillment, chargebacks, and disputes.” (traduzione) «Entrambi i protocolli mantengono il merchant come merchant of record, responsabile di evasione, chargeback e contestazioni». — Arjun Bhargava, Co-founder & CEO, Rye. Leggi la copertura

Circuiti di pagamento: framework emergenti

• Sull approccio di Visa: il Trusted Agent Protocol è “a standards-based framework enabling merchants to verify agent identity and intent in real time, preventing impersonation without degrading user experience.” (traduzione) «un framework basato su standard che consente ai merchant di verificare in tempo reale identità e intenzione dell agente, prevenendo l impersonificazione senza peggiorare l esperienza utente». — Visa, commercio agentico: minacce e rischi. Vai alla citazione

La realtà dell adozione

• Sul motivo per cui il checkout completamente autonomo è più lento dell hype: “Real-time catalog normalization across tens of millions of SKUs is a decade-scale problem Google already solved with Merchant Center, and consumers still default to checkout flows they trust—Apple Pay, Google Wallet, and Amazon one-click.” (traduzione) «La normalizzazione in tempo reale di cataloghi con decine di milioni di SKU è un problema da scala decennale già risolto da Google con Merchant Center, e i consumatori continuano a preferire flussi di checkout di cui si fidano: Apple Pay, Google Wallet e Amazon one-click». — Leigh McKenzie, Director of Online Visibility, Semrush, tramite Search Engine Land. Leggi la copertura

Quale percorso di integrazione del pagamento dovresti scegliere?

La prima vera decisione architetturale nel checkout agentico è come delegare il pagamento, perché determina direttamente il tuo ambito PCI e quanto devi costruire. Procedi così:

Test pre-lancio per il checkout agentico

Esegui questo passaggio in modalità sandbox/test prima di abilitare il checkout agentico in produzione. È il livello operativo che i consigli strategici sul «ripulire il feed» spesso saltano.

1. Crea una sessione di checkout e percorri il percorso felice. POST /checkout_sessions: conferma di ricevere 201 e una sessione in not_ready_for_payment (o incomplete). Aggiungi un opzione di evasione e conferma la transizione a ready_for_payment.
2. Verifica che i totali siano autorevoli. Conferma che totals[] (subtotale / imposte / evasione / sconti / totale) corrisponda al calcolo del backend e che il prezzo sia uguale a quello nel feed. Una differenza di prezzo feed/checkout distrugge la fiducia.
3. Completa la sessione. POST /checkout_sessions/{id}/complete: verifica che il pagamento venga elaborato, che si crei un ordine e che lo stato arrivi a completed.
4. Annulla una sessione. POST /checkout_sessions/{id}/cancel: verifica che l inventario venga rilasciato, così non perdi stock trattenuto.
5. Forza i percorsi di escalation. Simula requires_escalation / authentication_required. Esegui uno step-up 3DS e conferma che la gestione di AuthenticationResult copra gli esiti negativi (denied, rejected, abandoned, canceled, not_supported), non solo authenticated.
6. Testa l idempotenza. Invia due volte la stessa richiesta di creazione/completamento con la stessa chiave di idempotenza; conferma di ottenere un ordine, non due, e che un retry realmente non idempotente esponga request_not_idempotent invece di addebitare due volte.
7. Testa gli errori di logica commerciale rispetto agli errori HTTP. Attiva un problema nella sessione (per esempio una riga esaurita) e conferma che torni come MessageError in messages[], mentre una richiesta malformata torni come oggetto di errore a livello HTTP: il client deve gestirli entrambi.
8. Verifica le firme dei webhook. Invia un webhook order_create valido, conferma la firma HMAC Merchant-Signature e restituisci 200. Invia un webhook alterato e conferma il rifiuto con 401. Verifica di emettere l oggetto Order completo, non un delta.
9. Testa il back-pressure dei webhook. Conferma che il mittente gestisca un 429 della piattaforma con retry/backoff invece di abbandonare l evento.
10. Conferma la cattura dell attribuzione. Verifica che l ordine completato sia marcato come originato da un agente a livello OMS, dato che non esisterà una sessione GA4.

Errori comuni (e che cosa fare invece)

Supporre che «checkout agentico» significhi acquisti completamente autonomi, senza persone. Perché è sbagliato: ogni implementazione credibile conserva un punto di autorizzazione o escalation — requires_escalation, authentication_required, step-up 3DS e approval_required B2B. La piena autonomia senza autorizzazione human-in-the-loop non è né il modello delle specifiche né il modo in cui i circuiti di pagamento trattano oggi queste transazioni. Fai invece così: progetta i percorsi di escalation (continue_url, 3DS, approvazione) come flussi di prima classe, così una transazione che richiede una persona passa correttamente in escalation invece di finire in un vicolo cieco.

Trattarlo come già normale perché i titoli fanno rumore. Perché è sbagliato: solo circa una dozzina di merchant Shopify aveva attivato il checkout in ChatGPT prima che OpenAI ridimensionasse la versione in chat nel marzo 2026. Fai invece così: costruisci sulla capacità del protocollo (è reale e specificata), ma pianifica e assegna risorse come un early adopter, non come chi arriva tardi e deve recuperare.

Credere che la responsabilità delle frodi sia risolta perché il merchant of record è definito. Perché è sbagliato: il merchant of record è confermato per regolamento, rimborsi e conformità, ma il quadro probatorio dei chargeback — dimostrare che una transazione contestata era stata autorizzata correttamente quando l acquirente era un agente IA — è descritto esplicitamente dagli specialisti di frodi del settore come irrisolto. Fai invece così: acquisisci ora i log di autorizzazione dell agente e i segnali di rischio, tratta Visa TAP/Mastercard Agent Pay come framework emergenti (non conclusi) e non presumere che le prove esistenti per la difesa dei chargeback siano trasferibili.

Supporre che l agente salti il tuo sito e che quindi il checkout sul sito non conti. Perché è sbagliato: «salta sempre il sito del merchant» era il pitch originale di ChatGPT Instant Checkout, ma la sua implementazione principale su ACP è passata al modello discovery-plus-redirect nel marzo 2026. La capacità del protocollo è indipendente dall implementazione. Fai invece così: mantieni solido il checkout ospitato da te e supporta il flusso di sessione programmatico: a seconda della superficie, potresti chiudere l acquisto in chat o sul sito.

Pensare che l agente gestisca il numero della carta del cliente. Perché è sbagliato: i dati grezzi della carta non arrivano mai all agente per progettazione; token con ambito limitato/delegato (Shared Payment Token, modello disaccoppiato strumento/gestore di UCP) sono l intero scopo del livello di delegazione del pagamento. Fai invece così: instrada la delegazione tramite il tuo PSP, così un token vincolato al merchant, con importo massimo e uso singolo fa il lavoro, mantenendo piccolo il tuo ambito PCI.

Gestire retry non idempotenti. Perché è sbagliato: agenti e reti riprovano. ACP ha un tipo di errore request_not_idempotent proprio perché i retry ingenui addebitano o creano ordini due volte. Fai invece così: richiedi chiavi di idempotenza su creazione/completamento e rendi sicure le chiamate ripetute con la stessa chiave.

Checkout agentico: cheat sheet

Enumerazione degli stati della sessione di checkout ACP

Macchina parallela di UCP: incomplete → requires_escalation (persona tramite continue_url) → ready_for_complete.

Endpoint di checkout (ACP)

• POST /checkout_sessions — crea (201)
• GET /checkout_sessions/{id} — recupera
• POST /checkout_sessions/{id} — aggiorna
• POST /checkout_sessions/{id}/complete — elabora il pagamento e crea l ordine
• POST /checkout_sessions/{id}/cancel — annulla e rilascia l inventario

Token di pagamento con ambito limitato: i quattro vincoli

• merchant_id + checkout_session_id → vincolato a merchant e sessione
• max_amount → con importo massimo
• expires_at (RFC 3339) → limitato nel tempo
• reason: "one_time" → uso singolo

Webhook degli ordini (ACP)

• Eventi: order_create, order_update
• Firmati: header HMAC Merchant-Signature (obbligatorio)
• Payload: oggetto Order completo, non delta
• Risposte: 200 ok · 401 firma errata · 429 rate limit
• Stati dell ordine: created · manual_review · confirmed · canceled · shipped · fulfilled

Trigger di intervento umano

• Stati requires_escalation / authentication_required
• InterventionCapabilities (3ds, address_verification; enforcement always/conditional/optional)
• Esiti di AuthenticationResult (authenticated/denied/rejected/abandoned/…)
• approval_required B2B; continue_url UCP

Responsabilità in breve

• Merchant = merchant of record → regolamento/rimborsi/chargeback con merchant + PSP ✅ risolto
• Regole sulle prove del chargeback per acquirenti agentici ⚠️ irrisolte (metà 2026)
• Visa TAP / Mastercard Agent Pay → framework emergenti, non conclusi

Frammenti per lavorare con il checkout agentico

Servono per ispezionare e testare la tua integrazione, non per pilotare acquisti reali. Usa credenziali sandbox/test.

Verificare una firma webhook (Node.js, HMAC)

Rifiuta tutto ciò la cui Merchant-Signature non corrisponde. Confronta le firme in tempo costante.

import crypto from "node:crypto";

// secret = your shared webhook signing secret; rawBody = the exact bytes received
function verifyMerchantSignature(rawBody, signatureHeader, secret) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(rawBody)          // sign the raw body, not the parsed JSON
    .digest("hex");
  const a = Buffer.from(expected);
  const b = Buffer.from(signatureHeader || "");
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
// In your handler: if (!verify) return res.status(401).end();  // else 200

Interrogare lo stato di una sessione di checkout (shell)

Osserva una sessione sandbox attraversare la macchina a stati durante i test.

# Retrieve a session and print just its status field (needs jq)
SESSION_ID="cs_test_123"
curl -s "https://api.example.com/checkout_sessions/$SESSION_ID" \
  -H "Authorization: Bearer $ACP_TEST_KEY" \
  | jq -r '.status'          # e.g. not_ready_for_payment → ready_for_payment → completed

Inviare una chiamata di creazione con una chiave di idempotenza (Python)

Dimostra che un retry con la stessa chiave produce un ordine, non due.

import uuid, requests

key = str(uuid.uuid4())  # reuse this SAME key on retry
headers = {
    "Authorization": f"Bearer {ACP_TEST_KEY}",
    "Idempotency-Key": key,
    "Content-Type": "application/json",
}
payload = {"line_items": [{"id": "sku_1", "quantity": 1}]}
r1 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)
r2 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)  # retry
print(r1.json().get("id") == r2.json().get("id"))  # expect True — same session, no dupe

Frammento da console: scansionare una pagina renderizzata per un profilo UCP .well-known

Controllo rapido nella console DevTools per verificare se un merchant espone la discovery UCP (incollalo nella console del browser sull origin del merchant):

fetch("/.well-known/ucp")
  .then(r => (console.log("status:", r.status), r.ok ? r.json() : null))
  .then(p => console.log("capabilities:", p && p.capabilities));

Bookmarklet: saltare all enumerazione degli stati nei documenti ACP

Inseriscilo in un segnalibro per aprire il riferimento Checkout ACP direttamente all elenco degli stati:

javascript:location.href='https://www.agenticcommerce.dev/docs/reference/checkout#:~:text=incomplete';

Errori comuni del checkout agentico

Un retry crea due ordini o due addebiti

Sintomo: la stessa sessione di checkout produce ordini duplicati dopo un timeout o un retry di rete. Causa probabile: le chiamate di creazione o completamento non sono associate a una chiave e non sono sicure rispetto ai replay. Correzione: richiedi una chiave di idempotenza, restituisci il risultato originale per un retry con la stessa chiave e conferma che due chiamate identiche in sandbox producano una sessione e un ordine soltanto.

Il checkout non diventa mai pronto per il pagamento

Sintomo: una sessione resta in not_ready_for_payment o incomplete. Causa probabile: una scelta di evasione richiesta, un campo dell indirizzo o una regola commerciale non è risolta. Correzione: ispeziona i campi obbligatori della sessione e messages[], fornisci la scelta mancante e conferma che lo stato avanzi a ready_for_payment o ready_for_complete.

Una richiesta valida sembra riuscire, ma il carrello non può essere completato

Sintomo: la richiesta HTTP riesce mentre la sessione contiene una riga esaurita o un altro errore commerciale. Causa probabile: il client gestisce solo gli errori HTTP e ignora le voci MessageError. Correzione: gestisci sia gli errori di trasporto sia i messaggi della sessione, poi conferma che l utente o l agente vedano un errore utilizzabile.

La verifica umana finisce silenziosamente in un vicolo cieco

Sintomo: il checkout entra in requires_escalation o authentication_required e non torna. Causa probabile: il passaggio 3DS, login, approvazione o continue_url è stato trattato come un errore eccezionale invece che come uno stato supportato. Correzione: conserva la sessione durante il passaggio, gestisci ogni esito di autenticazione e conferma che i flussi riusciti e abbandonati si chiudano correttamente.

Lo stato dell ordine smette di aggiornarsi dopo il pagamento

Sintomo: il merchant ha l ordine ma la superficie dell agente resta in attesa o obsoleta. Causa probabile: una firma webhook non è valida, è stato inviato solo un delta o le risposte 429 sono state scartate. Correzione: firma il payload esatto, invia l oggetto Order completo, ripeti gli eventi limitati dal rate con backoff e conferma che il destinatario accetti l evento.

Modelli mentali per il checkout agentico

Il checkout è una macchina a stati, non una singola chiamata API

Ogni risposta dovrebbe portare la sessione a uno stato noto o esporre un motivo noto per cui non può avanzare. Progetta i client attorno a transizioni, stati terminali, retry ed escalation, non attorno a una singola richiesta “buy”.

L autorità resta al merchant

L agente esprime un intenzione, ma il merchant resta autorevole per prezzo, inventario, imposte, evasione, stato dell ordine e obblighi di merchant of record. Tratta il carrello richiesto dall agente come input e quello restituito dal merchant come verità.

La delegazione restringe i permessi

Un token di pagamento con ambito limitato è sicuro perché è vincolato al merchant e alla sessione, limitato nell importo, limitato nel tempo e monouso. Valuta ogni capacità delegata chiedendoti che cosa può fare, per chi, per quale importo e per quanto tempo.

L escalation è un ramo riuscito

L intervento umano non è un checkout autonomo fallito. Un passaggio pulito per 3DS, login, indirizzo o approvazione B2B è il protocollo che funziona come progettato.

Dopo il completamento, la consegna è asincrona

Il completamento del pagamento non chiude l integrazione. I webhook firmati con oggetto completo trasportano la verità sull ordine dopo il checkout, quindi verifica delle firme, protezione dai replay e gestione dei retry fanno parte dell affidabilità del checkout.

Metriche per il checkout agentico

Completamento del checkout per stato terminale

• Metrica: sessioni completate, annullate o scadute come quota delle sessioni avviate.
• Che cosa indica: dove termina la macchina a stati del checkout e quanta intenzione si perde prima che esista un ordine.
• Come estrarla: aggrega i cambiamenti di stato delle sessioni di checkout dall API commerciale o dalla piattaforma ordini, segmentati per protocollo e superficie del merchant.
• Benchmark / intervallo realistico: stabilisci una baseline per il tuo mix di prodotti e confronta flussi omogenei; in questa fase di adozione non è difendibile un tasso universale.
• Cadenza: monitoraggio quotidiano con revisione settimanale della tendenza.

Tasso di recupero dopo l escalation

• Metrica: sessioni entrate in escalation che tornano e si completano dopo intervento 3DS, login, indirizzo o approvazione.
• Che cosa indica: se il passaggio a una persona è praticabile o è un vicolo cieco.
• Come estrarla: unisci gli eventi di escalation alle transizioni di stato successive usando l ID della sessione di checkout.
• Benchmark / intervallo realistico: definisci una baseline separata per ogni tipo di intervento, perché autenticazione e approvazione B2B hanno attriti diversi.
• Cadenza: settimanale e dopo ogni modifica al flusso di passaggio.

Tasso di ordini duplicati e fallimenti dei webhook

• Metrica: ordini duplicati da retry con la stessa chiave più consegne webhook rifiutate o esaurite.
• Che cosa indica: se idempotenza e sincronizzazione asincrona degli ordini sono sicure in caso di errore.
• Come estrarla: confronta chiavi di idempotenza, ID ordine, fallimenti delle firme, 401, 429, retry ed eventi in dead letter nei log applicativi.
• Benchmark / intervallo realistico: gli ordini duplicati devono essere zero; stabilisci una baseline dei retry transitori normali e indaga ogni deviazione persistente.
• Cadenza: avviso immediato, riepilogo settimanale.

Risorse che meritano il tuo tempo

I miei articoli correlati

• I due protocolli in cui rientra il checkout agentico sono trattati in profondità sul sito: consulta gli articoli su Agentic Commerce Protocol (ACP) e Universal Commerce Protocol (UCP); questa pagina è l approfondimento sui meccanismi del checkout che sta sotto entrambi.
• Guida introduttiva alla SEO per ecommerce — il posto del checkout rivolto agli agenti nel quadro più ampio dell ecommerce.

I miei interventi

• Come funziona la ricerca (SlideShare) — il mio percorso su scoperta, indicizzazione e ranking; un contesto utile per capire come il livello transazionale mediato da un agente si appoggi a tutto questo. (Vale la mia avvertenza permanente: «questa è la mia comprensione dei sistemi… non sarà completa o accurata al 100%».)

Dal resto del settore

• Agentic Commerce Protocol: riferimento del checkout (OpenAI/Stripe) — enumerazione autorevole degli stati, campi della sessione e oggetti di intervento/autenticazione.
• Specifica OpenAI sul pagamento delegato — flusso del token con ambito e linguaggio su merchant of record e ambito PCI.
• Riferimento ai webhook degli ordini ACP (OpenAI/Stripe) — meccanismi push di sincronizzazione degli ordini, firmati HMAC e con oggetto completo.
• Chargeback nel commercio agentico: chi è responsabile quando compra l IA? (Chargeflow) — l analisi onesta del problema probatorio: «non ci sono ancora risposte nette».
• Commercio agentico: minacce e rischi (Visa) — Trusted Agent Protocol e identità dell agente.
• È appena cambiato il piano di OpenAI per Instant Checkout in ChatGPT (Search Engine Land) — pivot del marzo 2026 e citazioni sulla realtà dell adozione.
• Che cos è il checkout agentico? (Rye) — definizione indipendente chiara e conferma del merchant of record.
• Deep dive: Mastercard Verifiable Intent contro Visa Trusted Agent Protocol (Fintech Wrap Up / Finextra) — confronto dei framework dei circuiti; tratta l attribuzione specifica della responsabilità come riportata, non confermata.

Statistiche degne di essere citate

Numeri che descrivono il punto in cui si trova davvero il checkout agentico: considera indicativi i dati riportati dai merchant o riferiti da terzi e verifica prima di usarli.

• Circa una dozzina di merchant Shopify usava attivamente strumenti di checkout con IA — definiti trascurabili rispetto alla base complessiva di merchant Shopify — secondo il presidente di Shopify, riferito dalla copertura di Search Engine Land sul pivot del marzo 2026. Copertura
• Marzo 2026: il pivot. OpenAI ha spostato Instant Checkout di ChatGPT dal completamento completo dell acquisto in chat a discovery-plus-redirect, dopo attriti di onboarding, accuratezza e carrelli con più articoli. Copertura
• Ambito del token = 4 vincoli. Un token di pagamento delegato è limitato da max_amount, expires_at, merchant_id/checkout_session_id e reason: one_time: il meccanismo concreto che tiene la carta grezza lontana dall agente. Fonte
• Regola dei webhook: sempre l oggetto completo. ACP richiede che il campo data del webhook contenga l oggetto Order completo invece di delta incrementali e che ogni richiesta sia firmata HMAC. Fonte

Mettiti alla prova: Checkout agentico

Cinque domande rapide sui meccanismi del checkout. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche