Nell’ultimo anno il commercio autonomo ha spinto tutti i grandi player dei pagamenti a ripensare infrastrutture, protocolli e modelli di business per l’economia guidata da agenti AI.
Summary
Due livelli architetturali per i pagamenti tra agenti
Tra settembre 2025 e marzo 2026, tutti i protagonisti globali dei pagamenti hanno mosso passi concreti verso transazioni gestite da agenti. OpenAI e Stripe hanno lanciato l’Agentic Commerce Protocol, Google ha presentato l’Universal Commerce Protocol, Visa e Mastercard hanno introdotto framework specifici per agenti, mentre Coinbase ha spinto il protocollo x402 oltre i 15 milioni di transazioni su Base.
Nello stesso periodo, Stripe e Tempo hanno co-firmato il Machine Payments Protocol, inviato allo IETF per la standardizzazione. Questo allineamento temporale non è casuale. Riflette la consapevolezza che l’infrastruttura costruita negli ultimi trent’anni è stata progettata per esseri umani, non per software autonomi.
Le architetture esistenti presuppongono un utente davanti al browser che compila form, clicca bottoni e passa controlli di sicurezza. Gli agenti AI, invece, richiedono interfacce programmatiche, autorizzazioni quasi istantanee e sistemi in grado di regolare importi di frazioni di centesimo. Il vecchio stack non è nato per questi volumi e granularità.
Di conseguenza, sta emergendo una struttura a due livelli. Lo strato superiore gestisce l’orchestrazione commerciale, cioè come l’agente trova dove comprare e avvia la transazione. Lo strato inferiore gestisce la regolazione, cioè come il denaro si muove effettivamente. I due piani evolveranno in modo indipendente, guidati da attori e incentivi diversi.
Orchestrazione: come gli agenti compongono le transazioni
Lo strato di orchestrazione definisce come una transazione prende forma: scoperta del servizio, gestione della sessione e passaggio al pagamento. Inoltre, stanno emergendo due categorie di casi d’uso, abbastanza differenti da non poter essere trattate come un unico mercato.
Agenti che acquistano per conto dei consumatori
Nel commercio al dettaglio, il primo ostacolo non è il pagamento ma l’accesso. Le piattaforme e-commerce sono state pensate per la navigazione umana. Tuttavia, un agente non dovrebbe scorrere pagine prodotto, interpretare banner o cliccare su “aggiungi al carrello”. Prima del pagamento, i merchant devono offrire endpoint strutturati e leggibili dalle macchine. Oggi, la maggior parte non li ha.
L’Agentic Commerce Protocol (ACP), lanciato da OpenAI e Stripe nel settembre 2025, ruota attorno alla delega sicura del pagamento al momento dell’acquisto. Il metodo di pagamento dell’utente è salvato in ChatGPT. Quando l’utente conferma, Stripe emette un Shared Payment Token (SPT), una credenziale monouso legata a merchant e importo, inviata via API.
Il merchant mantiene lo status di Merchant of Record ed elabora il pagamento sulla propria infrastruttura esistente. Lo SPT di Stripe è il primo esempio operativo di questo modello di delega ed è compatibile con la Delegated Payment Spec di OpenAI. Altri PSP possono implementare integrazioni proprie, rendendo il protocollo aperto a livello di pagamento.
ChatGPT Instant Checkout è stato lanciato a settembre 2025 per gli utenti statunitensi, ma chiuso nel marzo 2026 dopo tassi di conversione prossimi allo zero. OpenAI ha quindi riposizionato il prodotto sulla discovery: ChatGPT propone articoli e reindirizza ai siti o alle app dei merchant per il checkout. ACP sopravvive in forma più ristretta, alimentando app dedicate in ChatGPT per pochi grandi retailer selezionati.
I merchant devono candidarsi per partecipare e OpenAI controlla sia chi viene mostrato sia l’ordine di esposizione. In sostanza, ACP opera come ambiente curato e chiuso, con OpenAI in ruolo di gatekeeper.
Il Universal Commerce Protocol (UCP) di Google, annunciato da Sundar Pichai l’11 gennaio 2026 alla NRF Conference, segue una logica diversa. È stato co-sviluppato con Shopify, Etsy, Wayfair, Target e Walmart, e supportato da oltre 20 partner tra cui Adyen, American Express, Best Buy, Mastercard, Visa, Stripe e The Home Depot.
UCP è pensato per essere compatibile con l’Agent Payments Protocol (AP2) di Google, con lo standard Agent2Agent (A2A) e con il Model Context Protocol (MCP. È, in modo deliberato, una mossa verso l’interoperabilità di “alto livello”. I merchant pubblicano un profilo UCP, un documento JSON strutturato disponibile a /.well-known/ucp sul proprio dominio.
Questo profilo dichiara metodi di trasporto, capacità di checkout e payment handler supportati. Gli agenti lo leggono direttamente, senza intermediari. Google Pay è lo strumento di pagamento predefinito per i checkout basati su UCP, con PayPal annunciato come opzione in arrivo.
L’architettura riflette una precisa scelta strategica. Google non ha interesse a intermediare direttamente le transazioni, operazione che esporrebbe a margini compressi, responsabilità e maggiori controlli regolamentari. Ciò che cerca è invece un indicizzazione completa del web del commercio.
UCP posiziona Gemini come livello primario di discovery per lo shopping guidato da agenti, sfruttando l’expertise storica nella ricerca. Il modello a profili mantiene Google a monte: essenziale per la scoperta, ma invisibile nella fase di regolazione.
ACP e UCP, quindi, non competono sulla stessa casella. ACP è un ambiente controllato: OpenAI seleziona i merchant, ottimizza l’esperienza end-to-end dentro ChatGPT e limita l’accesso. UCP funziona come un catalogo aperto, dove i merchant si autopubblicano e ogni agente compatibile può leggere i profili.
Detto ciò, Google mantiene il controllo della superficie di discovery senza toccare la transazione. Il risultato è minore frizione in onboarding e potenziale platea più ampia, ma meno supporto operativo ai merchant rispetto al modello chiuso di OpenAI.
Transazioni tra agenti autonomi
Il secondo gruppo di casi d’uso ha una struttura diversa. Quando entrambe le controparti sono agenti autonomi e nessun merchant umano è coinvolto, i consueti ancoraggi di fiducia scompaiono. Non ci sono termini di servizio, tutele al consumo o diritto di chargeback su carta.
Il problema diventa: come possono due sistemi che non si sono mai incontrati scambiarsi valore senza doversi fidare? Lo standard ERC-8183, proposto il 10 marzo 2026 dal team dAI della Ethereum Foundation insieme a Virtuals Protocol, affronta direttamente questo tema.
Ogni transazione è strutturata come un “job” a tre parti: un Client che commissiona il lavoro, un Provider che lo esegue e un Evaluator che certifica il completamento. Il pagamento è bloccato in escrow in uno smart contract ed è rilasciato solo quando l’Evaluator firma l’esito.
In questo modo, né Client né Provider devono valutare l’affidabilità della controparte, perché l’esito è imposto meccanicamente dal contratto. Sotto questo schema opera ERC-8004, che fornisce il layer di identità.
Gli agenti si registrano on-chain e costruiscono una reputazione a partire dalla storia transazionale, generando un segnale di credibilità riutilizzabile. Il design del protocollo è solido. Tuttavia, la criticità è la capacità di scalare l’adozione.
Nella pratica, l’attività è concentrata dentro la piattaforma Virtuals Protocol, dove un orchestratore chiamato Butler scompone task complessi in sotto-job e li instrada a agenti specializzati. La comunità di sviluppatori più ampia non ha ancora adottato questo modello su larga scala.
In sintesi, ERC-8183 è il tentativo di rendere questo schema aperto e permissionless. Inoltre, la distinzione tra i due percorsi implica requisiti diversi per la regolazione. L’e-commerce tradizionale può restare sulle reti carta, perché gli umani restano nel loop.
Il commercio tra agenti autonomi, invece, tende verso la regolazione in stablecoin, poiché le fee sui circuiti carta non si adattano bene a servizi di piccola entità e alta frequenza.
Regolazione: protocolli a confronto
Se l’orchestrazione stabilisce cosa si scambia, lo strato di regolazione stabilisce se e come la transazione si chiude. Attualmente cinque protocolli competono in questo spazio, con differenze rilevanti dal punto di vista operativo.
Delegated Payment Spec e SPT di Stripe
L’approccio di Stripe estende l’infrastruttura carta esistente invece di sostituirla. Quando il cliente autorizza un agente, Stripe genera un token di pagamento condiviso (SPT) che l’agente memorizza. Al momento dell’operazione, l’agente presenta questo token limitato nel tempo e nell’importo al merchant.
La regolazione passa attraverso lo stack di card processing standard di Stripe. Sul back-end, Stripe ha integrato i sistemi con Visa Intelligent Commerce e Mastercard Agent Pay, che emette token di rete specifici per agenti, così i merchant vedono una sola superficie di integrazione a prescindere dal network sottostante.
Questa architettura è adatta agli acquisti retail e a molte transazioni, inclusi pagamenti tra agenti di valore elevato in cui le tutele quali i chargeback sono utili. Tuttavia, si presta meno a scenari di micropagamento ad alta frequenza tra agenti o macchine, dove gli importi sono frazioni di centesimo e i volumi possono raggiungere migliaia di transazioni al minuto.
Tokenizzazione intelligente di Visa e Mastercard
Visa e Mastercard hanno riprogettato l’infrastruttura di tokenizzazione per accogliere transazioni guidate da agenti. I numeri di carta reali vengono sostituiti con token dinamici e cifrati che includono metadati sull’agente autorizzante: identità, limiti di spesa, finestra di validità e lista di merchant ammessi.
La regolazione rimane sulle reti carta esistenti, senza nuovi binari. Entrambe le reti sono oltre la fase di test. Mastercard ha elaborato la prima transazione con agente completamente identificato nel settembre 2025 con Commonwealth Bank in Australia. Visa ha concluso i primi deployment in Europa tramite il programma Agentic Ready.
L’infrastruttura si sta dimostrando efficace. Tuttavia, il livello minimo delle fee introduce un vincolo strutturale: nessuna delle due reti può servire in modo efficiente i micropagamenti sotto la soglia del dollaro che il commercio tra agenti potrebbe richiedere su larga scala.
x402 di Coinbase e pagamenti HTTP 402
x402, sviluppato da Coinbase, adotta una logica completamente diversa. Invece di adattare le carte, si aggancia direttamente a HTTP, sfruttando il codice di stato 402 “Payment Required”, presente nella specifica dal 1997 ma mai realmente utilizzato.
Quando un agente richiede una risorsa a pagamento, il server risponde con un 402 e i parametri di pagamento. L’agente firma un’autorizzazione e un Facilitator completa la regolazione on-chain in USDC o altri token supportati, di norma in circa 2 secondi. Non servono account, API key o KYC. La governance dello standard aperto è affidata alla x402 Foundation, creata da Coinbase e Cloudflare.
Entro fine 2025 il protocollo aveva elaborato oltre 100 milioni di transazioni su Base, Solana e Polygon. Tuttavia, analisti di Artemis, in un report di febbraio 2026, stimano che una parte rilevante del traffico rifletta operazioni interne e test infrastrutturali più che commercio reale.
Il volume annuo di pagamenti è indicato in circa 600 milioni di dollari, ma la concentrazione e la qualità del volume restano punti critici. Inoltre, non esiste un floor di fee che impedisca i micropagamenti: x402 è progettato proprio per transazioni sotto il centesimo.
La lacuna attuale non è l’architettura, ma la profondità di adozione e la densità di transazioni commerciali reali.
Nanopayments di Circle
Il protocollo Nanopayments di Circle è esplicitamente compatibile con x402: utilizza il trigger HTTP 402 secondo lo standard e aggiunge sopra un’architettura di regolazione batch. Invece di regolare ogni transazione on-chain singolarmente, sfrutta un conto Circle Gateway prefinanziato lato acquirente.
Ogni pagamento è autorizzato tramite firme off-chain EIP-3009, con regolazione periodica in batch sulla blockchain. I costi di gas vengono sostenuti al deposito, non per singola operazione, il che rende economicamente sostenibili pagamenti di appena 0,000001 dollari.
Il compromesso è che entrambe le parti devono prima depositare in Circle Gateway, limitando oggi il protocollo a una rete semi-chiusa. Nanopayments è stato lanciato in testnet nel marzo 2026 su 12 chain supportate. La struttura commissionale è molto competitiva per i casi d’uso di micropagamenti ad alta frequenza, a patto che Circle riesca a ridurre la frizione di onboarding su larga scala.
Machine Payments Protocol di Tempo e Stripe
Il Machine Payments Protocol (MPP), co-autore Tempo insieme a Stripe, è il più ambizioso dal punto di vista architetturale. Tempo è una blockchain Layer-1 focalizzata sui pagamenti, sviluppata da Stripe e Paradigm. MPP utilizza il trigger HTTP 402 e consente a merchant e agenti di scegliere tra più rail di regolazione nello stesso framework.
In questo modo, lo sviluppatore non deve decidere a priori tra stablecoin e infrastruttura fiat. L’agente può selezionare a runtime il canale più adatto alle esigenze della transazione. Tra le opzioni supportate figurano:
- Tempo: stablecoin, sia con regolazione per transazione on-chain sia in modalità batch off-chain
- Stripe: pagamenti basati su SPT
- Circuiti carta: pagamenti tramite token di rete monouso cifrati con dati dinamici per transazioni machine-initiated
- Lightspark: pagamenti via Bitcoin Lightning
MPP introduce inoltre il concetto di “sessione”, simile a OAuth: un agente autorizza una volta e prefinanzia un account, abilitando regolazione automatica in tempo reale sulle interazioni successive senza una transazione on-chain per ogni pagamento.
La specifica principale è stata inviata allo IETF per la standardizzazione come implementazione ufficiale dell’HTTP 402. Al lancio, la Payment Directory integra oltre 100 servizi. MPP è arrivato su mainnet il 18 marzo 2026.
Il doppio ruolo di Stripe è rilevante. L’azienda ha co-scritto il protocollo e al contempo è uno dei canali di pagamento previsti. In questo modo, cattura valore sia se gli sviluppatori scelgono MPP per la sua flessibilità multi-rail sia se lo adottano principalmente per le capacità carta.
Stato attuale e frammentazione dell’orchestrazione
Quasi tutti i protocolli citati sono nati negli ultimi sei mesi, ma l’attività commerciale non ha tenuto il passo. Sul fronte regolazione, x402 guida per numero di transazioni, ma il volume giornaliero reale è di circa 28.000 dollari.
Sul fronte orchestrazione, il prodotto di punta ACP per il checkout è stato chiuso per conversioni quasi nulle. Anche protocolli più recenti, come ERC-8183 o MPP, mostrano lo stesso schema: narrazione molto avanzata rispetto all’implementazione effettiva. L’architettura di base sembra definita, ma la scala commerciale non è ancora cominciata.
La criticità principale è una forte frammentazione nello strato di orchestrazione. I merchant devono confrontarsi con standard multipli, ognuno con SDK, flussi di autenticazione e requisiti di compliance propri. Ciò rende i costi di integrazione poco prevedibili e frena la partecipazione.
Storicamente, frammentazioni di questo tipo si risolvono tramite un livello di aggregazione che unifica l’accesso sopra gli standard concorrenti. In questo caso, però, la dinamica potrebbe essere diversa. Ogni piattaforma con traffico significativo di agenti, da OpenAI a Google fino a Microsoft, ha un incentivo diretto a mantenere una propria superficie chiusa anziché instradare utenti altrove.
La stessa logica si osserva su scala geografica: Cina, Sud-est asiatico, Corea e Giappone stanno sviluppando ecosistemi chiusi regionali, spesso ancorati a super-app dominanti. Il risultato probabile è la coesistenza di più sistemi chiusi in parallelo, non un unico standard aperto.
L’auspicata orchestrazione dei pagamenti decentralizzata, utile ai merchant, rischia quindi di nascere non dai grandi player di piattaforma ma da provider terzi di infrastruttura focalizzati sui merchant stessi. I loro incentivi sono più allineati alla semplificazione dell’accesso.
Opportunità: infrastrutture e applicazioni per agenti
Da questo quadro emergono due traiettorie di opportunità distinte. La prima, più vicina nel tempo, riguarda le infrastrutture di pagamento per agenti; la seconda, più inesplorata, il livello applicativo del commercio tra agenti.
Settlement: il caso del wallet multicanale per agenti
A prescindere da quanto lo strato di orchestrazione si frammenti, tutti gli agenti condividono lo stesso problema di fondo: pagare. Si sta delineando un’asimmetria chiara: l’orchestrazione si frammenta per incentivo di piattaforma, mentre la regolazione tende a consolidarsi per necessità degli sviluppatori.
Uno sviluppatore non può mantenere integrazioni di pagamento separate per ogni superficie di orchestrazione su cui il suo agente dovrà operare. Inoltre, man mano che aumentano le piattaforme coinvolte, la pressione economica verso un’unica integrazione di pagamento unificata si intensifica.
Questo genera un requisito concreto per i wallet destinati agli agenti: il supporto a canali di liquidazione multipli non è opzionale. Le reti carta, tramite SPT, Visa Agentic Token e Mastercard Agentic Token, coprono il commercio tradizionale con merchant.
Le reti stablecoin, tramite x402 e i pagamenti in sessione di MPP, coprono invece servizi API on-chain e transazioni tra software. Entrambi i casi d’uso sono già reali e non convergeranno su un singolo rail nel breve termine.
La flessibilità deve risiedere dal lato dell’agente, non del merchant. I merchant scelgono una volta quali rail supportare, una decisione relativamente stabile. Le imprese, invece, dotano i propri agenti di stablecoin e di una carta delegata; l’agente paga con il rail accettato dalla controparte.
In questo contesto, un wallet multicanale per agenti che gestisca entrambi i rail tramite un’unica integrazione abilita agenti generalisti capaci di operare con qualsiasi controparte. Il valore di questa infrastruttura si accumula su ogni transazione, piattaforma ed ecosistema, diventando difficile da sostituire.
Commercio tra agenti autonomi: il layer meno sviluppato
La seconda opportunità riguarda il commercio tra agenti autonomi, ancora poco esplorato al livello applicativo. Oggi l’economia A2A è concentrata su casi d’uso crypto-native: agenti che interrogano dati on-chain, interagiscono con protocolli DeFi o gestiscono transazioni blockchain.
Il mercato non ha ancora oltrepassato l’ambito infrastrutturale. Eppure, dal punto di vista tecnico, agenti che commissionano servizi nel mondo reale, dall’analisi dati alla produzione di contenuti, fino a ricerche legali o code review, sono già possibili con gli standard esistenti.
Mancano soprattutto gli sviluppatori che costruiscono questi servizi e li espongono come API pagabili per singola chiamata da agenti. Questa è la vera lacuna e rappresenta la direzione meno competitiva oggi, nonostante il potenziale.
Questa opportunità è limitata da un concreto problema di avvio a freddo. Sistemi di identità come ERC-8004 hanno bisogno di densità transazionale per produrre segnali di fiducia significativi. Un agente senza storia di pagamenti è poco credibile, quindi fatica a trovare controparti, rallentando la costruzione della propria reputazione.
Microsoft prevede circa 1,3 miliardi di agenti AI attivi entro il 2028, ma la base attuale è di ordini di grandezza inferiore. Questa lacuna non si chiuderà automaticamente. È proprio la barriera che mantiene bassa la concorrenza, e superarla per primi è la posizione più strategica.
La conseguenza più profonda è una ristrutturazione dei modelli di business oltre i pagamenti. I due modelli dominanti di Internet, pubblicità e abbonamenti, danno per scontato un acquirente umano. Gli agenti non sono influenzati dagli annunci e non richiedono accesso mensile, ma pagano il risultato di singole chiamate.
I pagamenti HTTP 402 per chiamata offrono ai provider API una struttura diversa: vendere risultati anziché accesso, far pagare gli heavy user per l’effettivo consumo e smettere di sovvenzionare gli utenti leggeri o sovraprovisionare picchi rari di domanda.
Verso il commercio autonomo su larga scala
Nel complesso, il commercio tra agenti autonomi si svilupperà lungo due direttrici distinte. Sul lato consumer, gli agenti che acquistano beni per conto delle persone continueranno a usare rail carta. La velocità di adozione dipenderà dai framework di autorizzazione aziendale e dalla fiducia dei consumatori in nuove interfacce di pagamento.
Il commercio tra agenti, dove software paga software per API, calcolo e dati, è invece già pronto tecnicamente sulle reti stablecoin, in attesa che agenti e servizi vengano distribuiti su larga scala. Il punto di arrivo probabile è uno stack a due livelli che evolvono in parallelo: orchestrazione per l’avvio delle transazioni e regolazione per il movimento del valore.
Per chi costruisce infrastrutture, la priorità è l’ampiezza di integrazione. Una soluzione capace di instradare qualunque transazione di agente attraverso il protocollo richiesto dalla controparte, senza esporre complessità all’applicazione, gode di un vantaggio strutturale quando il mercato scalerà.
Il vero trigger per la scala commerciale non sono protocolli migliori, ma il momento in cui le imprese delegano potere di spesa agli agenti, con tracciabilità delle operazioni, budget autorizzativi e responsabilità chiare in caso di errore di acquisto.
Quando ciò accadrà, due posizioni infrastrutturali diventeranno centrali: un’integrazione che unisca carte e stablecoin in un solo wallet per agenti e una directory di servizi on demand per agenti, accessibile a sviluppatori senza background crypto. Nessuna delle due funziona senza l’altra.
Solo quando gli agenti spenderanno su scala, con capacità di pagare su più rail e di scoprire facilmente servizi da acquistare, il commercio autonomo potrà esprimere appieno il proprio potenziale.
