Universal Commerce Protocol (UCP)

L’11 gennaio 2026, Google ha annunciato l’UCP (Universal Commerce Protocol), uno standard open-source con l’obiettivo di favorire l’interoperabilità tra gli agenti AI e i diversi sistemi di vendita al dettaglio.
Senza entrare subito nei tecnicismi, il protocollo abilita agenti AI ad operare ricerche di prodotti ed effettuarne i relativi acquisti usando il linguaggio naturale.

Il protocollo è stato sviluppato da Google in collaborazione con i principali leader del settore, come Shopify, con il sostegno di oltre 20 partner globali quali American Express, Mastercard, Stripe, Visa, Zalando e molti altri:

Sono passati pochissimi giorni e si sono susseguiti diversi articoli a riguardo, che descrivevano bene il contesto e la promessa di un’esperienza di acquisto fluida come non mai, ma non approfondivano due punti in particolare che mi restavano poco chiari:

1. Il meccanismo di discovery: come fa un agente AI a “scoprire” quali merchant supportano UCP? Qual è il flusso tecnico che collega la richiesta dell’utente (“compra una valigia”) ai server dei vari merchant?
2. Il grado di autonomia: l’acquisto è davvero completamente autonomo, oppure richiede intervento umano? E se sì, in quali fasi?

Parte 1: Capire UCP

Prima di UCP, ogni piattaforma AI che voleva abilitare acquisti doveva costruire integrazioni custom con ogni merchant.
Il tutto collassava in una complessità N×N: N agenti che parlano con N merchant, ognuno con API, flussi di checkout e gestione dei metodi di pagamento diversi e questo pur considerando famiglie di sistemi “standard” riusabili.

Il nuovo protocollo introduce invece un linguaggio comune.
Un merchant implementa UCP una volta e qualsiasi agente compatibile può interagire con lui, simmetricamente un agente implementa UCP una volta, e può parlare con qualsiasi merchant compatibile.

UCP è progettato come un protocollo a strati, ispirato alla filosofia di TCP/IP:

• Shopping Service: le primitive di base (checkout session, line items, totals, messages, status)
• Capabilities: funzionalità principali come Checkout ed Order
• Extensions: moduli opzionali che estendono le capability (sconti, loyalty)

Questa separazione permette al protocollo di evolvere senza rompere le implementazioni esistenti.
Un merchant può supportare solo quello di cui ha effettivamente bisogno (es. niente loyalty), l’agente negozia dinamicamente cosa entrambi supportano.

Il meccanismo di discovery: il pezzo mancante

E qui arriviamo al primo punto che volevo chiarire.
UCP non definisce come un agente scopre i merchant, ma solo cosa succede dopo che il merchant è stato identificato.
Questo è un punto cruciale: implementare UCP sul proprio sito non basta per essere ‘scoperti’ dagli agenti, ma serve un layer di discovery esterno, nel caso di Google è Merchant Center, nel caso di Shopify è il loro Catalog.
Per merchant indipendenti, come questo aspetto evolverà è ancora da definire, presumibilmente la GEO (Generative Engine Optimization) diventerà sempre più rilevante.

Nell’ecosistema Google, di fatto il primo ad implementare UCP, il discovery avviene attraverso il Merchant Center, con un flusso come da video di esempio a seguire:

È possibile iscriversi già oggi alla lista d’attesa per essere tra i primi ad implementare questa tecnologia, a patto però (almeno al 18 gennaio), di essere un venditore che evade ordini dagli Stati Uniti e dispone di un conto bancario negli Stati Uniti.

Shopify (co-sviluppatore dell’iniziativa UCP), ha risolto il problema del discovery in modo diverso tramite Agentic Storefronts, un layer che espone automaticamente i merchant Shopify a ChatGPT, Microsoft Copilot, Perplexity, e presto Google AI Mode.

Il grado di autonomia

Ed ora si può rispondere (almeno in parte) alla seconda domanda, qual è il grado di autonomia della procedura?

Lo standard UCP prevede acquisti completamente autonomi, la specifica definisce esplicitamente uno “Scenario C: Autonomous Agent” dove l’agente completa l’intero checkout senza intervento umano, usando mandati crittografici pre-autorizzati (protocollo AP2, Agent Payments Protocol).

L’implementazione Google invece richiede un intervento manuale, la documentazione Google lo riporta chiaramente:

Manual checkout: The user now interacts only with the Google UI to fill in sensitive fulfillment and payment details and submit the order.
The Agent is not involved in this part, ensuring determinism.

Quindi l’agente porta fino alla soglia del checkout, poi passa il testimone: non è un acquisto autonomo ma assistito, almeno per ora, il che è probabilmente la scelta più saggia per gestire l’intero processo con maggiore trust.

Vediamo ora concretamente come funziona il protocollo, mettendo le mani un po’ più nel dettaglio.

Parte 2: Approfondimento tecnico

Entriamo un po’ più nel dettaglio incrociando la documentazione ufficiale e la pagina GitHub con l’implementazione di riferimento.
Questa parte dell’articolo è pensata per professionisti tech o chi è più interessato a questi elementi di dettaglio, si parte dal presupposto di avere già un ambiente di sviluppo Python disponibile, in quanto adatteremo l’esempio ufficiale del comportamento server, simulando l’interfaccia e la risposta che il sito di un merchant deve esporre.

Iniziamo con il clonare il repository ufficiale:

mkdir sdk
git clone https://github.com/Universal-Commerce-Protocol/python-sdk.git sdk/python
pushd sdk/python
uv sync

popd
git clone https://github.com/Universal-Commerce-Protocol/samples.git
cd samples/rest/python/server
uv sync

Che predisporrà sia l’SDK Python, che l’ambiente con gli esempi basato su FastAPI.

Se volete personalizzare qualche prodotto prima dell’importazione nel DB locale, potete farlo ora editando il contenuto dei file CSV nella cartella samples/rest/python/test_data/flower_shop, nel nostro esempio andremo a modificare il titolo dei prodotti nel file products.csv.

Lanciamo ora la creazione dei DB locali:

mkdir /tmp/ucp_test
uv run import_csv.py \
    --products_db_path=/tmp/ucp_test/products.db \
    --transactions_db_path=/tmp/ucp_test/transactions.db \
    --data_dir=../test_data/flower_shop

Notate come la cartella /tmp/ucp_test stia ora ospitando i file DB temporaneamente, valutate l’uso di una cartella diversa qualora vogliate persistenza.

Lanciamo ora il server locale:

uv run server.py \
   --products_db_path=/tmp/ucp_test/products.db \
   --transactions_db_path=/tmp/ucp_test/transactions.db \
   --port=8182 & SERVER_PID=$!

Che ci risponderà con qualcosa come:

[1] 1532
% INFO:     Started server process [1533]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:8182 (Press CTRL+C to quit)

Ora il nostro server è in esecuzione e possiamo simulare un client usando il 🔗 progetto Postman in allegato che per motivi di leggibilità risulta più comodo rispetto all’invocazione dei servizi da riga di comando.

Discovery

I siti che supportano UCP lo definiscono tramite un manifesto JSON standard esposto sul path /.well-known/ucp.

Questo URL permette agli agenti di individuare dinamicamente caratteristiche, endpoint e configurazioni di pagamento senza integrazioni hard-coded, MA come già visto nel paragrafo “Il meccanismo di discovery: il pezzo mancante”, devono conoscere a priori l’URL del sito web.

Possiamo interrogare le caratteristiche del nostro server eseguendo la request “1. Discovery” nel progetto Postman.
La response è un JSON che descrive completamente le capacità del server, la struttura è piuttosto articolata, concentriamoci quindi solo su due elementi in particolare per capire il flusso, i services e le capabilities.

Services: dove e come comunicare

"services": {
  "dev.ucp.shopping": {
    "version": "2026-01-11",
    "spec": "https://ucp.dev/specification/reference",
    "rest": {
      "schema": "https://ucp.dev/services/shopping/openapi.json",
      "endpoint": "http://localhost:8182/"
    },
    "mcp": null,
    "a2a": null,
    "embedded": null
  }
}

Questa sezione dichiara i canali di comunicazione disponibili:

In questo esempio il merchant supporta solo REST.
Un merchant più avanzato potrebbe esporre lo stesso servizio su più trasporti, lasciando all’agent la scelta del canale preferito.

Capabilities: cosa sa fare il merchant

"capabilities": [
  {
    "name": "dev.ucp.shopping.checkout",
    "version": "2026-01-11",
    "spec": "https://ucp.dev/specification/checkout",
    "schema": "https://ucp.dev/schemas/shopping/checkout.json",
    "extends": null,
    "config": null
  },
  {
    "name": "dev.ucp.shopping.order",
    "version": "2026-01-11",
    "spec": "https://ucp.dev/specification/order",
    "schema": "https://ucp.dev/schemas/shopping/order.json",
    "extends": null,
    "config": null
  },
  {
    "name": "dev.ucp.shopping.discount",
    "version": "2026-01-11",
    "spec": "https://ucp.dev/specification/discount",
    "schema": "https://ucp.dev/schemas/shopping/discount.json",
    "extends": "dev.ucp.shopping.checkout",
    "config": null
  },
  ... OMISSIS ...
]

Le capabilities sono i mattoni funzionali di UCP, il campo extends determina se si tratta di una funzionalità autonoma o di un’estensione:

Capability autonome (extends: null, non estendono nulla sono root ed esistono da sole):

• dev.ucp.shopping.checkout: gestione sessioni di checkout
• dev.ucp.shopping.order: gestione ciclo di vita ordini

Extensions (extends punta a una capability padre da cui dipendono):

• dev.ucp.shopping.discount: estende checkout, aggiunge gestione codici sconto
• dev.ucp.shopping.fulfillment: estende checkout, aggiunge opzioni di spedizione
• dev.ucp.shopping.buyer_consent: estende checkout, aggiunge gestione consensi espliciti

Il meccanismo funziona così: un’extension non può esistere senza la sua capability padre.
Se l’agent non supporta checkout, tutte le extension che la estendono (discount, fulfillment, buyer_consent) vengono automaticamente escluse dalla negoziazione.

Questo permette una composizione modulare: un merchant può supportare il checkout base senza sconti, oppure aggiungere solo le estensioni di cui ha bisogno.
L’agent, confrontando questo elenco con le proprie capability per determinare ciò che entrambi sanno gestire.

Gestione sessione

Possiamo avviare la creazione di una sessione eseguendo la request “2. Capabilities & Extensions” nel progetto Postman.

Dopo l’invocazione il merchant risponde con la sessione inizializzata:

{
    ... OMISSIS ...
    "id": "42b9bc87-4477-46d3-83c0-a59c059e110d",
    "line_items": [
        {
            "id": "1bd97562-b8b4-4e64-87f9-fe83096a8cb3",
            "item": {
                "id": "bouquet_roses",
                "title": "Mazzo di rose rosse",
                "price": 3500,
                "image_url": null
            },
            "quantity": 1,
            "totals": [
                {
                    "type": "subtotal",
                    "display_text": null,
                    "amount": 3500
                },
                {
                    "type": "total",
                    "display_text": null,
                    "amount": 3500
                }
            ],
            "parent_id": null
        }
    ],
    "buyer": {
        ... OMISSIS ...
    },
    "status": "ready_for_complete",
    "currency": "EUR",
    "totals": [
        {
            "type": "subtotal",
            "display_text": null,
            "amount": 3500
        },
        {
            "type": "total",
            "display_text": null,
            "amount": 3500
        }
    ],
... OMISSIS ...

Notare nel campo id il valore dell’ID checkout, nel nostro esempio 42b9bc87-4477-46d3-83c0-a59c059e110d ed il totale parziale dell’ordine in totals.

Possiamo aggiornare la sessione, applicando ad esempio un coupon visto che il nostro server supporta questa capability eseguendo la request “3. Example of Discount Extension” nel progetto Postman, assicurandosi però di modificare il valore dell’ID checkout nell’indirizzo: /checkout-sessions/CHECKOUT_ID con quello tornato dalla creazione sessione.

ATTENZIONE: Si possono effettuare più invocazioni dei vari servizi, ma è necessario cambiare il valore in header di idempotency-key o si otterrà un errore nella forma:

{
    "detail": "Idempotency key reused with different parameters",
    "code": "IDEMPOTENCY_CONFLICT"
}

Tornando al nostro esempio, dopo l’applicazione del codice sconto vedremo il nuovo totale aggiornato di conseguenza.

"totals": [
    {
        "type": "subtotal",
        "display_text": null,
        "amount": 3500
    },
    {
        "type": "discount",
        "display_text": null,
        "amount": 350
    },
    {
        "type": "total",
        "display_text": null,
        "amount": 3150
    }
]

Non è chiaro in che modo l’agente dovrebbe conoscere a priori il codice da applicare, ma è facile dedurre come questa componente sarà legata all’interazione umana ancora presente nel flusso.

Per chiudere il processo è poi necessario indicare i dati di spedizione (fulfillment, request Postman “4. Fulfillment”) e di conclusione ordine con i dettagli di pagamento (request Postman “5. Payment”), nello scenario Google entrambi fuori dal processo automatizzato.

Nella cartella samples/rest/python/client/flower_shop del progetto di test è disponibile un client demo che simula tutti i processi di acquisto ed è eseguibile con:

cd samples/rest/python/client/flower_shop/
uv sync
uv run simple_happy_path_client.py --server_url=http://localhost:8182

Conclusione

Tornando alle due domande iniziali:

Sul discovery: UCP standardizza le transazioni, non la scoperta dei merchant.
Implementare il protocollo sul proprio sito non è sufficiente, serve essere indicizzati in un catalogo (Google Merchant Center, Shopify Catalog, o equivalenti futuri).
Per i merchant indipendenti, questo significa che la GEO (Generative Engine Optimization) diventerà probabilmente un requisito, non un’opzione.

Sull’autonomia dell’agente: esiste una differenza significativa tra ciò che lo standard permette e ciò che le implementazioni attuali fanno/faranno.
UCP supporta acquisti completamente autonomi tramite AP2 e mandati crittografici; Google ha scelto un approccio più conservativo con conferma manuale.

E l’Agentic Commerce Protocol di OpenAI?

Vale la pena notare che OpenAI ha pubblicato un proprio standard, l’Agentic Commerce Protocol (ACP), con obiettivi simili ma architettura diversa.
Siamo quindi di fronte a due standard concorrenti, o potenzialmente complementari.

Una cosa è certa: il commercio agentico non è più fantascienza, la domanda non è se arriverà, ma quanto velocemente e chi sarà pronto a intercettarlo.