ACP, UCP e AP2 a confronto: i protocolli del commercio agentico a ottobre 2026 e quale serve al vostro negozio

Oggi tre protocolli aperti descrivono come un agente IA acquista da un negozio. L'Agentic Commerce Protocol (ACP) viene da OpenAI e Stripe. L'Universal Commerce Protocol (UCP) viene da Google e Shopify. L'Agent Payments Protocol (AP2), avviato da Google e affidato alla FIDO Alliance ad aprile, non è affatto un protocollo di checkout: definisce una prova firmata del fatto che un utente ha autorizzato un pagamento, ed è pensato per funzionare dentro UCP. Tutti e tre hanno licenza Apache 2.0.

Al 22 ottobre 2026 si trovano in condizioni molto diverse. ACP è etichettato come beta, la sua ultima release è 2026-04-17 e dal 17 luglio non ha ricevuto alcun commit. ChatGPT, il suo utilizzatore principale, a marzo ha abbandonato il checkout autonomo e ora usa ACP soprattutto per ricevere dati di prodotto. UCP ad agosto ha pubblicato una versione non retrocompatibile, 2026-08-25, mentre i servizi di Google girano ancora su 2026-04-08 e il suo checkout è in accesso anticipato, solo negli Stati Uniti. AP2 è alla v0.2, e nessun prodotto Google ne documenta l'uso.

Questo articolo è rivolto a CTO e lead developer di negozi e piattaforme di commercio che devono decidere che cosa implementare. Per sapere che cosa chiede a un negozio, dal punto di vista commerciale, ciascuna piattaforma IA, partite dalla nostra panoramica sul commercio agentico.

A confronto

ACP: l'Agentic Commerce Protocol

Governance e versioni

Il repository della specifica dice che ACP è mantenuto da OpenAI e Stripe e lo etichetta come beta. Il suo documento di governance fa delle due società i Founding Maintainers: assegnano i seggi del comitato direttivo (fino a sette) e conservano un diritto di veto da usare «come ultima risorsa». Il 24 aprile 2026 Meta si è unita come terzo maintainer principale e membro del comitato. La documentazione di Stripe descrive ACP come «creato da Stripe, OpenAI e Meta», ma il file di notice del repository cita solo OpenAI e Stripe. Una fondazione neutrale è soltanto un percorso futuro dichiarato.

Le release datate sono cinque: 2025-09-29 (checkout e pagamento delegato), 2025-12-12 (modifiche non retrocompatibili nate dall'esperienza con gli adapter di URBN ed Etsy), 2026-01-16 (un fornitore 3DS scelto dall'esercente), 2026-01-30 (negoziazione delle funzionalità, estensioni e un framework non retrocompatibile per i payment handler) e 2026-04-17 (carrello, feed, ordini, autenticazione delegata, discovery e MCP), che ha deprecato 2026-01-30. Nei sei mesi successivi non è uscito nulla. La cartella unreleased/ contiene modifiche minori datate fino al 17 luglio, come un id di aggiornamento del feed e un URL di prodotto facoltativo sugli articoli del checkout.

Che cosa implementa un esercente con la versione 2026-04-17

L'API di checkout è ospitata dall'esercente e chiamata dall'agente:

• POST /checkout_sessions crea una sessione, POST /checkout_sessions/{checkout_session_id} la aggiorna (un POST, non un PUT), un GET sullo stesso percorso la recupera, e .../complete e .../cancel la chiudono.
• Le richieste portano una chiave API bearer e un header API-Version obbligatorio. Dalla 2026-04-17 un Idempotency-Key è obbligatorio su ogni POST, con errori definiti: 400 idempotency_key_required, 409 idempotency_in_flight e 422 idempotency_conflict.
• La richiesta di creazione contiene un oggetto capabilities. L'agente dichiara che cosa supporta e il venditore restituisce l'intersezione, così un'incompatibilità emerge prima del pagamento.
• L'esercente invia con POST gli eventi degli ordini a un endpoint ricevente ospitato da OpenAI su /agentic_checkout/webhooks/order_events, firmati con HMAC-SHA256 in un header Merchant-Signature. Gli stati vanno da created a delivered o canceled, e adjustments[] riporta rimborsi, resi, contestazioni e chargeback.

La release 2026-04-17 ha aggiunto anche un file statico e pubblico, /.well-known/acp.json, il cui campo transports indica se il negozio parla rest, mcp o entrambi. Ha aggiunto un binding MCP su Streamable HTTP con cinque tool (create_checkout_session, get_checkout_session, update_checkout_session, complete_checkout_session, cancel_checkout_session), autenticato nella configurazione del server anziché a ogni richiesta. E ha aggiunto una Feed API ospitata dall'agente, verso cui l'esercente invia i dati (POST /feeds, PATCH /feeds/{id}/products), un carrello con un solo venditore e senza dati di pagamento (POST /carts, PUT /carts/{id}) e l'autenticazione 3DS2 delegata (POST /delegate_authentication). Gli abbonamenti non ci sono: la RFC sulle estensioni elenca subscription come «supporto alla fatturazione ricorrente (futuro)».

Come funziona il pagamento in ACP

La risposta originaria di ACP è il pagamento delegato. Il PSP o il vault delle carte implementa POST /agentic_commerce/delegate_payment, che trasforma una carta (l'unico tipo di credenziale) in un token che il PSP dell'esercente può usare solo entro limiti precisi: reason (solo one_time), max_amount, currency, checkout_session_id, merchant_id e expires_at. Con le parole della RFC, «pagamenti, regolamento e conformità restano sui circuiti dell'esercente». Worldpay documenta una propria versione della chiamata, e PayPal supporta ACP tramite token delegati in Braintree.

Dalla 2026-01-30 i metodi accettati si dichiarano come handler sotto capabilities.payment.handlers. Ecco i dati di pagamento d'esempio del changelog:

{ "handler_id": "card_tokenized", "instrument": { "type": "card", "credential": { "type": "spt", "token": "spt_123" } } }

Lo spt è lo Shared Payment Token di Stripe, disponibile «negli Stati Uniti, in Canada e in alcuni paesi europei». Un venditore Stripe lo addebita con payment_method_data[shared_payment_granted_token] su una versione di anteprima dell'API; un venditore che usa un altro processor può convertirlo una sola volta in credenziali di rete. Il nostro articolo sui pagamenti agentici spiega chi si assume il rischio.

Che cosa ha cambiato la mossa di OpenAI a marzo

Il 24 marzo 2026 OpenAI ha scritto che «la versione iniziale di Instant Checkout non offriva il livello di flessibilità che aspiriamo a garantire», ha lasciato che gli esercenti usassero i propri checkout e ha detto che stava «estendendo ACP perché diventi lo strato di collegamento tra esercenti e utenti per tutta la fase di scoperta». Target, Sephora, Nordstrom, Lowe's, Best Buy, The Home Depot e Wayfair avevano integrato ACP per la scoperta dei prodotti, e i cataloghi Shopify arrivano tramite Shopify Catalog. Che cosa significa per uno sviluppatore:

• Il feed è la parte attiva. La pagina per gli esercenti di OpenAI dice che gli acquisti «vengono completati su siti web o app di proprietà dell'esercente» e che lo shopping è attivo per gli utenti statunitensi. L'onboarding dei feed è riservato ai partner approvati da una lista d'attesa: un file completo ogni giorno via SFTP con nove campi obbligatori, aggiornamenti tramite API durante la giornata, promozioni solo tramite API. Il caricamento standard «attualmente è destinato agli Stati Uniti».
• Il checkout richiede un'abilitazione a parte. La specifica del feed dice che il checkout «richiede un'integrazione abilitata separatamente». Per le app di ChatGPT, la strada in disponibilità generale è il checkout esterno sul dominio dello sviluppatore. La schermata di pagamento in chat è una beta privata «limitata a marketplace selezionati», che passa un token di pagamento al server MCP dell'app in una chiamata al tool complete_checkout.
• Le pagine di OpenAI sono indietro rispetto alla specifica. Il suo riferimento per il checkout mostra ancora API-Version 2025-09-12 e un enum provider con stripe, adyen e braintree. Sviluppate seguendo il repository e verificate con OpenAI quale versione accetta.

Le pagine dei PSP che presentano ancora Instant Checkout come attivo non sono aggiornate.

UCP: l'Universal Commerce Protocol

Governance e versioni

Google ha lanciato UCP l'11 gennaio 2026, sviluppato insieme a Shopify, Etsy, Wayfair, Target e Walmart. Le regole di governance danno a Google e Shopify un voto permanente ciascuno nel Governing Council, in cui Stripe siede dal 28 aprile 2026, e stabiliscono che «Google detiene il voto per delega per tutti i seggi vacanti fino a dicembre 2028». Il 24 aprile lo Shopping Tech Council è salito a 16 seggi, con l'ingresso di Amazon, Meta, Microsoft, Salesforce e Stripe, quindi Meta e Stripe ora siedono sia nel comitato di ACP sia nel consiglio di UCP.

Il repository ha quattro release. La 2026-04-08 ha aggiunto le funzionalità di carrello e catalogo, la firma di richieste e risposte e Get Order. La 2026-08-25 non è retrocompatibile: signing_keys[] ha lasciato il posto a un JWK Set in keys[], le estensioni di pagamento sono passate da dev.ucp.shopping.* a dev.ucp.common.payment.*, gli schemi condivisi sono stati spostati e hanno cambiato i loro URL $id, e PAN e token di rete sono diventati tipi di credenziale distinti. Ha aggiunto anche il 3DS2 indipendente dal fornitore, i pagamenti suddivisi, i termini di pagamento e l'interoperabilità con Web Bot Auth.

Ecco la trappola. La guida al profilo di Google copre solo 2026-04-08 e 2026-01-23, il profilo dell'agente di Google su ucp.goog dichiara "version": "2026-04-08" e Salesforce B2C Commerce 26.9 serve le stesse due versioni. Il Checkout MCP di Shopify, invece, rimanda alla 2026-08-25. Se sviluppate sull'ultima release, sviluppate una versione che Google non documenta. La risposta della specifica è un oggetto supported_versions che associa ogni versione precedente al proprio URI di profilo.

Discovery, trasporti e autenticazione

Ogni esercente pubblica un profilo su /.well-known/ucp con ucp.version, ucp.services e ucp.payment_handlers, e Google richiede che sia pubblico e accessibile senza autenticazione. Anche la piattaforma dell'agente ne pubblica uno, e ogni richiesta ne porta l'URI in un header UCP-Agent, su HTTPS con almeno TLS 1.3. L'autenticazione è a scelta dell'esercente: nessuna, X-API-Key, OAuth 2.0, TLS reciproco o HTTP Message Signatures secondo la RFC 9421. Google invia un token bearer, e le sue FAQ prevedono anche mTLS. Un Idempotency-Key è solo un «SHOULD»; un server che lo accetta lo conserva per almeno 24 ore e risponde 409 se viene riutilizzato con un corpo diverso.

REST è il trasporto principale, insieme a MCP, a un'estensione A2A e a una modalità embedded raggiungibile tramite un continue_url. Gli ordini sono un GET /orders/{id} più un webhook dall'esercente alla piattaforma firmato secondo la RFC 9421. I percorsi del carrello sono gli stessi di ACP. Le operazioni di checkout si assomigliano ma non sono intercambiabili:

Un unico nucleo di checkout può servirli entrambi. Un'unica tabella delle route no.

Come funziona il pagamento in UCP

UCP non sposta denaro. Un payment handler è una specifica scritta da un fornitore di credenziali, come com.google.pay per Google Pay o dev.shopify.shop_pay per Shop Pay. L'esercente elenca gli handler che accetta, la piattaforma ne esegue uno, e su complete l'esercente riceve un token opaco da addebitare tramite il proprio PSP.

Sui servizi di Google l'unico handler è Google Pay, PAN_ONLY è l'unico metodo di autenticazione usato, e il vostro PSP «deve essere in grado di elaborare i nostri token». Stripe pubblica com.stripe.payments per carte e Apple Pay: «L'agente invia uno shared payment token (SPT) nella richiesta Complete Checkout, e il venditore lo addebita». Google Pay resta sul proprio handler. PayPal supporta l'handler di Google Pay tramite Braintree o tramite la sua API Orders v2.

Che cosa richiede Google prima di chiamarvi

La guida al checkout integrato di Google chiede l'API di checkout REST e tiene per sé il passaggio di pagamento: l'acquirente inserisce i dati sensibili «solo con l'interfaccia utente di Google». I livelli di servizio sono almeno il 95% di disponibilità su ogni endpoint, con latenze p50 e p95 di 1 e 4 secondi per la creazione, 1 e 5 per l'aggiornamento e 6 e 10 per il completamento. Dopo un ordine, inviate gli aggiornamenti di stato a un webhook di Google con un id partner e una chiave rilasciati durante l'onboarding. In Merchant Center ogni prodotto deve avere native_commerce(checkout_eligibility) impostato su true (l'attributo «ha FALSE come valore predefinito»), una politica di reso e un contatto per l'assistenza sono obbligatori, e sono esclusi abbonamenti, pagamenti rateali, prodotti personalizzati, articoli usati e ricondizionati, preordini e prodotti soggetti a limiti di età.

L'opzione più leggera, dalla 2026-04-08, è il trasferimento del carrello: implementate solo la creazione del carrello, Google passa il carrello al vostro sito e non servono né un payment handler né un webhook per gli ordini.

Il vero limite è l'accesso. Il checkout è «disponibile per esercenti selezionati» tramite un modulo di interesse del programma di accesso anticipato, nel quale vi impegnate a iniziare entro 30 giorni e accettate che l'accesso «possa essere revocato» se non fate progressi. Le condizioni di UCP Checkout si applicano «solo agli Stati Uniti». L'hub di Merchant Center arriverà poi in Australia e Canada «all'inizio del prossimo anno»; per il checkout Google non indica una data per nessun altro paese.

UCP fuori da Google

Microsoft Merchant Center accetta feed compatibili con UCP negli Stati Uniti dal 21 aprile 2026. Copilot Checkout richiede un feed conforme a UCP, accetta esercenti di lingua inglese che vendono ad acquirenti statunitensi in dollari, con un solo PSP ciascuno, e la relativa impostazione del negozio è contrassegnata come «solo in fase pilota, per clienti selezionati». Shopify espone UCP tramite MCP su https://{shop}/api/ucp/mcp e ha rimosso i suoi vecchi tool per catalogo e carrello. Una funzionalità per la prenotazione di alloggi è stata integrata nel repository come bozza il 24 settembre 2026 e non fa parte di nessuna release.

AP2: l'Agent Payments Protocol

AP2 non è un terzo modo di fare il checkout. La sua specifica dice che «opera come funzione di sicurezza all'interno di un protocollo di commercio» ed è «progettato esplicitamente per essere compatibile con l'Universal Commerce Protocol (UCP)». La versione 0.1.0 è uscita il 16 settembre 2025 e la v0.2 il 28 aprile 2026, il giorno in cui Google ha donato AP2 alla FIDO Alliance. L'annuncio di FIDO indica un gruppo di lavoro Agentic Authentication e un gruppo di lavoro Payments presieduti da membri di Mastercard e Visa, e dice che i contributi «saranno esaminati e ulteriormente sviluppati». FIDO non ha pubblicato alcuna specifica AP2. Il repository GitHub ora accetta solo esempi e modifiche all'SDK, e il suo ultimo commit risale al 29 aprile.

La versione 0.2 definisce un Checkout Mandate (che cosa si acquista) e un Payment Mandate (il pagamento, con vincoli come payment.amount_range, payment.budget e payment.allowed_payees). Ciascuno è un SD-JWT in una forma chiusa e in una aperta (mandate.payment.1 e mandate.payment.open.1, per esempio). In modalità Human Present l'utente approva i mandati chiusi. In modalità Human Not Present l'utente approva mandati aperti che fissano i vincoli e portano la chiave pubblica dell'agente in un claim cnf, e l'agente compone quelli chiusi entro quei limiti. I tutorial sugli Intent Mandate e sui Cart Mandate descrivono la v0.1; quei termini non esistono più nella v0.2.

All'interno di UCP, AP2 è l'estensione dev.ucp.common.payment.ap2_mandate (dev.ucp.shopping.ap2_mandate prima della 2026-08-25). Una volta negoziata, l'esercente firma le proprie risposte di checkout, la piattaforma presenta un checkout_mandate e un payment_mandate su complete, e la sessione è «Security Locked»: nessuna delle due parti può ripiegare su un checkout ordinario.

Per ora nessuno lo richiede. Le FAQ di Google definiscono AP2 «particolarmente utile per scenari futuri che prevedono transazioni autonome di agenti IA». Il profilo dell'agente di Google indica Google Pay come unico payment handler e non dichiara alcuna funzionalità AP2, e nemmeno il suo profilo 2026-08-25 contiene una voce AP2. Nessun prodotto Google documenta l'uso di AP2, quindi per un esercente non c'è nulla da sviluppare finché una piattaforma non lo negozia.

I protocolli vicini

MCP

ACP e UCP possono funzionare entrambi su MCP, la cui specifica attuale, 2026-07-28, elimina le sessioni e l'header Mcp-Session-Id, abbandona l'handshake initialize, richiede server/discover e prevede che il client rimandi una richiesta con un nuovo ID quando il suo stream si interrompe. Il binding di ACP rimanda ancora al trasporto 2025-11-25. Un id di sessione di checkout è esattamente l'handle generato dal server che la nuova specifica si aspetta, e un complete perso a metà stream torna come una richiesta nuova: trattate le chiavi di idempotenza come obbligatorie in entrambi i protocolli.

WebMCP

WebMCP è uno standard web proposto per esporre le funzioni di una pagina agli agenti che operano nel browser. Shopify offre il checkout UCP sia come Checkout MCP sia come Checkout WebMCP, con lo stesso oggetto di checkout, e raccomanda Checkout MCP. La nostra guida a WebMCP ne descrive lo stato.

x402 e MPP

x402 e il Machine Payments Protocol, progettato da Tempo e Stripe, fanno pagare a un agente ogni richiesta HTTP per un'API, dei dati o dei contenuti. Non sono protocolli di checkout per negozi. Leggete il nostro articolo su x402.

Visa Trusted Agent Protocol e Mastercard Agent Pay

Si affiancano ad ACP e UCP, non li sostituiscono. Il Trusted Agent Protocol di Visa offre a un agente «un metodo crittografico standardizzato» per dimostrare agli esercenti la propria identità e la propria autorizzazione, e Mastercard Agent Pay è un programma di tokenizzazione per il commercio agentico. La guida per gli esercenti di Mastercard colloca UCP e ACP al suo livello di preparazione più alto, osserva che «i primi ad adottarli li stanno integrando in questo momento» e consiglia agli esercenti di partire dai suoi due livelli più semplici. Il nostro articolo sui pagamenti agentici tratta entrambi i programmi.

Personal Agent Protocol

Sierra dice di aver annunciato il Personal Agent Protocol («Poppy») con Meta il 6 ottobre 2026, e il 9 ottobre ne ha pubblicato una bozza. Un'azienda pubblica un solo file su /.well-known/poppy.json; il protocollo usa OAuth, JWT, HTTPS, OpenAPI e MCP per permettere a un agente personale di identificarsi e di ottenere il permesso del cliente per qualsiasi tipo di attività, e Sierra lo definisce complementare a UCP. Il sito del protocollo mostra la versione 0.2 e dice «È una bozza». Nella newsroom di Meta non abbiamo trovato alcun post a riguardo.

Quale vi serve?

Su Shopify

Niente da sviluppare. Le vetrine agentiche (agentic storefronts) di Shopify sono «attive per impostazione predefinita per i negozi idonei». ChatGPT riceve il vostro catalogo tramite Shopify Catalog e manda gli acquirenti al vostro negozio. Il checkout diretto di Google è attivo per impostazione predefinita per i negozi che hanno sede negli Stati Uniti e vendono negli Stati Uniti, e Copilot ha iscritto automaticamente gli esercenti Shopify. Le vostre decisioni riguardano i dati di prodotto e se tenere attivo il checkout diretto, sapendo che i pixel personalizzati non si attivano in quello di Google.

Su Salesforce, commercetools o un'altra piattaforma

Salesforce B2C Commerce 26.9 serve UCP 2026-01-23 e 2026-04-08: /.well-known/ucp con una mappa supported_versions, e gli endpoint delle sessioni di checkout dietro un token SLAS. Salesforce indica il checkout UCP su Google come in disponibilità generale a ottobre 2026. Una sessione è una vista headless di un carrello, e la guida all'audit di Salesforce avverte che i controller SFRA e SiteGenesis non vengono eseguiti in questo flusso, e nemmeno «le altre risorse SCAPI che usate oggi», quindi la logica collegata a questi elementi deve essere copiata o agganciata, tramite un ponte, agli hook delle sessioni di checkout UCP. Il feed deve avere come target en-US, e Salesforce «non salta la lista d'attesa di Google». Per ChatGPT, Salesforce è uno dei canali che OpenAI indica per consegnare i feed ACP.

Su commercetools o su un'altra piattaforma, chiedete al fornitore quali versioni e funzionalità di UCP serve, quali dei vostri hook vengono eseguiti in un checkout fatto da un agente e se invia feed a OpenAI.

Su software proprio

1. Prima i feed. Google Merchant Center e, quando OpenAI vi ammette, il suo feed prodotti. L'uso commerciale di ACP in ChatGPT oggi è esattamente questo.
2. UCP per Google, se vendete negli Stati Uniti e Google vi ammette. Sviluppate sulla 2026-04-08: il profilo con com.google.pay, le operazioni di checkout entro gli obiettivi di latenza di Google, un PSP che elabori i token di Google Pay, il webhook degli ordini e l'attributo del feed. Oppure iniziate con il solo trasferimento del carrello.
3. Checkout ACP solo se c'è un motivo, come un'app di ChatGPT ammessa alla beta della schermata di pagamento. Sviluppate sulla 2026-04-17 del repository.
4. AP2: per ora niente.
5. Un unico nucleo di checkout. Entrambi i protocolli vogliono una sessione che si possa creare, aggiornare, completare e annullare tramite API e ripetere in sicurezza. Sviluppatela una volta sola sopra la vostra logica di ordini, imposte e pagamenti, con adapter ACP e UCP leggeri in cima e MCP dove servono agli agenti.

Oggi nessuno dei due protocolli offre a un'attività in abbonamento un checkout nativo per agenti.

Se vendete solo fuori dagli Stati Uniti

Oggi nessuno dei tre vi dà un checkout per agenti. Lo shopping in ChatGPT e il caricamento standard dei feed di OpenAI riguardano gli Stati Uniti; le condizioni di UCP Checkout di Google valgono solo per gli Stati Uniti; Copilot Checkout serve acquirenti statunitensi in dollari. Il prossimo passo annunciato da Google è l'hub di Merchant Center in Australia e Canada «all'inizio del prossimo anno», senza una data per il Regno Unito o l'UE.

Mantenete completo il vostro feed di Merchant Center e, se state comunque rifacendo il checkout, sviluppate il nucleo guidato da API descritto sopra, così un adapter sarà un lavoro piccolo quando il vostro mercato si aprirà. Vendete negli Stati Uniti dall'estero? Verificate dove ogni programma richiede che abbia sede l'esercente; il checkout diretto di Google tramite Shopify, per esempio, richiede un negozio statunitense.

Dove trovare aiuto

Sviluppiamo lo strato dei protocolli per i negozi che non usano Shopify: un profilo /.well-known/ucp ed endpoint per le sessioni di checkout sopra la vostra logica esistente di ordini, imposte e pagamenti, webhook degli ordini verso Google, feed prodotti per Google Merchant Center e OpenAI, e server MCP che espongono lo stesso checkout agli agenti. Il nostro servizio di sviluppo di agenti IA e integrazione MCP è il punto di partenza per questo lavoro.

Scrivete a office@c9group.dev indicando la vostra piattaforma, il vostro PSP e i paesi in cui vendete, e vi diremo quale protocollo si applica e che cosa richiederebbe implementarlo. Le condizioni dei programmi di Google e OpenAI sono contratti: siamo ingegneri, non avvocati, quindi fatele leggere a un consulente prima di firmare.