ACP, UCP och AP2 jämförda: protokollen för agentisk handel i oktober 2026, och vilket din butik behöver

Tre öppna protokoll beskriver nu hur en AI-agent köper från en butik. Agentic Commerce Protocol (ACP) kommer från OpenAI och Stripe. Universal Commerce Protocol (UCP) kommer från Google och Shopify. Agent Payments Protocol (AP2), som Google startade och lämnade över till FIDO Alliance i april, är inte alls något kassaprotokoll: det definierar ett signerat bevis på att en användare har godkänt en betalning, och det är utformat för att ligga inuti UCP. Alla tre har licensen Apache 2.0.

Den 22 oktober 2026 befinner de sig i mycket olika lägen. ACP är märkt som beta, den senaste versionen är 2026-04-17, och inga commits har gjorts sedan 17 juli. ChatGPT, protokollets största användare, lämnade den fristående kassan i mars och använder nu ACP främst för att ta emot produktdata. UCP publicerade en version med brytande ändringar, 2026-08-25, i augusti, medan Googles egna tjänster fortfarande kör 2026-04-08 och Googles kassa är i tidig åtkomst, bara i USA. AP2 är i version v0.2, och det finns ingen Google-produkt vars dokumentation säger att den använder det.

Den här artikeln är för CTO:er och ledande utvecklare på butiker och handelsplattformar som ska bestämma vad de ska implementera. Vill du veta vad varje AI-plattform begär av en butik som företag, börja med vår översikt över agentisk handel.

Sida vid sida

ACP: Agentic Commerce Protocol

Styrning och versioner

Specifikationens repo säger att ACP underhålls av OpenAI och Stripe och märker det som beta. Dess styrningsdokument gör de två till Founding Maintainers (grundande underhållare): de tillsätter platserna i styrkommittén (upp till sju) och behåller ett veto att använda ”som en sista utväg”. Meta anslöt som tredje ledande underhållare och kommittémedlem den 24 april 2026. Stripes dokumentation beskriver ACP som ”skapat av Stripe, OpenAI och Meta”, men NOTICE-filen i repot anger bara OpenAI och Stripe. En neutral stiftelse finns bara med som en uttalad framtida väg.

Det finns fem daterade versioner: 2025-09-29 (kassa och delegerad betalning), 2025-12-12 (brytande ändringar byggda på erfarenheter från adaptrarna för URBN och Etsy), 2026-01-16 (en 3DS-leverantör som handlaren väljer), 2026-01-30 (förhandling av funktioner, tillägg och ett ramverk för betalningshanterare med brytande ändringar) och 2026-04-17 (varukorg, flöde, beställningar, delegerad autentisering, upptäckt och MCP), som markerade 2026-01-30 som föråldrad. Ingenting har släppts under de sex månader som gått sedan dess. Mappen unreleased/ innehåller mindre ändringar daterade fram till 17 juli, till exempel ett ID för flödesuppdateringar och en valfri produkt-URL på artiklar i kassan.

Vad en handlare implementerar i 2026-04-17

Kassans API ligger hos handlaren och anropas av agenten:

• POST /checkout_sessions skapar en kassasession (checkout session), POST /checkout_sessions/{checkout_session_id} uppdaterar den (en POST, inte en PUT), GET på samma sökväg hämtar den, och .../complete och .../cancel avslutar den.
• Förfrågningarna skickar med en API-nyckel som bearer-token och en obligatorisk header API-Version. Sedan 2026-04-17 är en Idempotency-Key obligatorisk på varje POST, med definierade fel: 400 idempotency_key_required, 409 idempotency_in_flight och 422 idempotency_conflict.
• Förfrågan som skapar sessionen innehåller ett objekt capabilities. Agenten deklarerar vad den stöder och säljaren returnerar snittet, så att en inkompatibilitet syns före betalningen.
• Handlaren skickar orderhändelser med POST till en mottagare som OpenAI tillhandahåller på /agentic_checkout/webhooks/order_events, signerade med HMAC-SHA256 i en header Merchant-Signature. Statusvärdena går från created till delivered eller canceled, och adjustments[] bär återbetalningar, returer, tvister och återkrav (chargebacks).

Versionen 2026-04-17 lade också till en statisk, publik /.well-known/acp.json, vars fält transports anger om butiken talar rest, mcp eller båda. Den lade till en MCP-bindning över Streamable HTTP med fem verktyg (create_checkout_session, get_checkout_session, update_checkout_session, complete_checkout_session, cancel_checkout_session), som autentiseras i serverkonfigurationen snarare än per förfrågan. Och den lade till ett Feed API som agenten driftar och handlaren pushar till (POST /feeds, PATCH /feeds/{id}/products), en varukorg för en enda säljare utan betalningsdata (POST /carts, PUT /carts/{id}) och delegerad 3DS2-autentisering (POST /delegate_authentication). Det finns inga prenumerationer: RFC:n om tillägg listar subscription som ”Stöd för återkommande debitering (framtida)”.

Så fungerar betalningen i ACP

ACP:s ursprungliga svar är delegerad betalning. Betaltjänstleverantören (PSP) eller kortvalvet implementerar POST /agentic_commerce/delegate_payment, som gör om ett kort (den enda typen av betaluppgift) till en token som handlarens PSP bara får använda inom en ram: reason (bara one_time), max_amount, currency, checkout_session_id, merchant_id och expires_at. Med RFC:ns ord: ”Betalningar, avveckling och regelefterlevnad ligger kvar på handlarens egen betalningsinfrastruktur.” Worldpay dokumenterar sin egen version av anropet, och PayPal stöder ACP via delegerade tokens i Braintree.

Sedan 2026-01-30 deklareras godkända betalmetoder som hanterare under capabilities.payment.handlers. Ändringsloggens exempel på betalningsdata:

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

Värdet spt är Stripes Shared Payment Token, som finns ”i USA, Kanada och utvalda europeiska länder”. En säljare på Stripe debiterar den med payment_method_data[shared_payment_granted_token] på en förhandsversion av API:et; en säljare med en annan betalningsförmedlare kan en gång lösa upp den till betaluppgifter från kortnätverket. Vår artikel om agentiska betalningar går igenom vem som bär risken.

Vad OpenAI:s kursändring i mars innebar

Den 24 mars 2026 skrev OpenAI att ”den första versionen av Instant Checkout inte erbjöd den flexibilitet som vi strävar efter att ge”, lät handlarna använda sina egna kassor och sa att företaget ”utvidgar ACP till att bli det sammanbindande lagret mellan handlare och användare genom hela produktupptäckten”. Target, Sephora, Nordstrom, Lowe's, Best Buy, The Home Depot och Wayfair hade integrerat ACP för produktupptäckt, och kataloger från Shopify kommer in via Shopify Catalog. Vad det innebär för en utvecklare:

• Flödet är den del som är i gång. OpenAI:s sida för handlare säger att köp ”slutförs på webbplatser eller i appar som handlaren äger” och att shopping är i gång för användare i USA. Anslutningen av flöden är öppen för godkända partner från en väntelista: en daglig fullständig fil via SFTP med nio obligatoriska fält, API-uppdateringar under dagen och kampanjer bara via API. Standarduppladdningen ”riktar sig för närvarande mot USA”.
• Kassan är en separat spärr. Flödesspecifikationen säger att kassan ”kräver en separat aktiverad integration”. För ChatGPT-appar är den allmänt tillgängliga vägen en extern kassa på utvecklarens egen domän. Betalningsrutan i chatten är en privat beta ”begränsad till utvalda marknadsplatser”, som lämnar över en betalningstoken till appens MCP-server i ett verktygsanrop complete_checkout.
• OpenAI:s sidor ligger efter specifikationen. Företagets referens för kassan visar fortfarande API-Version 2025-09-12 och en provider-enum med stripe, adyen och braintree. Bygg mot repot och bekräfta med OpenAI vilken version företaget accepterar.

Sidor från PSP:er som fortfarande presenterar Instant Checkout som i gång är inaktuella.

UCP: Universal Commerce Protocol

Styrning och versioner

Google lanserade UCP den 11 januari 2026, utvecklat tillsammans med Shopify, Etsy, Wayfair, Target och Walmart. Reglerna för styrningen ger Google och Shopify varsin permanent röst i Governing Council, som Stripe anslöt till den 28 april 2026, och slår fast att ”Google har fullmaktsröst för alla vakanta platser till dec. 2028”. Den 24 april utökades Shopping Tech Council till 16 platser, med Amazon, Meta, Microsoft, Salesforce och Stripe som nya medlemmar, så Meta och Stripe sitter nu både i ACP:s kommitté och i UCP:s råd.

Repot har fyra versioner. 2026-04-08 lade till funktioner för varukorg och katalog, signering av förfrågningar och svar, samt Get Order. Version 2026-08-25 har brytande ändringar: signing_keys[] ersattes av ett JWK Set i keys[], betalningstilläggen flyttade från dev.ucp.shopping.* till dev.ucp.common.payment.*, delade scheman flyttades och bytte $id-URL:er, och PAN och nätverkstokens blev separata typer av betaluppgifter. Den lade också till leverantörsoberoende 3DS2, delade betalningar, betalningsvillkor och interoperabilitet med Web Bot Auth.

Här finns fällan. Googles guide för profilen täcker bara 2026-04-08 och 2026-01-23, Googles egen agentprofil på ucp.goog deklarerar "version": "2026-04-08", och Salesforce B2C Commerce 26.9 stöder samma två versioner. Shopifys Checkout MCP länkar däremot till 2026-08-25. Bygger du mot den senaste versionen bygger du en version som Google inte dokumenterar. Specifikationens svar är ett objekt supported_versions som kopplar varje äldre version till en egen profil-URI.

Upptäckt, transporter och autentisering

Varje företag publicerar en profil på /.well-known/ucp med ucp.version, ucp.services och ucp.payment_handlers, och Google kräver att den är publik och kan läsas utan autentisering. Agentens plattform publicerar också en, och varje förfrågan bär dess URI i en header UCP-Agent, över HTTPS med minst TLS 1.3. Autentiseringen väljer företaget: ingen, X-API-Key, OAuth 2.0, ömsesidig TLS eller HTTP Message Signatures enligt RFC 9421. Google skickar en bearer-token, och Googles vanliga frågor erbjuder också mTLS. En Idempotency-Key är bara ett ”SHOULD”; en server som tar emot en sparar den i minst 24 timmar och svarar 409 när den återanvänds med en annan body.

REST är kärntransporten, tillsammans med MCP, ett A2A-tillägg och ett inbäddat läge som nås via en continue_url. Beställningar är en GET /orders/{id} plus en webhook från företaget till plattformen, signerad enligt RFC 9421. Sökvägarna för varukorgen är desamma som i ACP. Kassaoperationerna liknar varandra men är inte utbytbara:

En gemensam kassakärna kan betjäna båda. En gemensam routningstabell kan det inte.

Så fungerar betalningen i UCP

UCP flyttar inga pengar. En betalningshanterare (payment handler) är en specifikation skriven av en leverantör av betaluppgifter, till exempel com.google.pay för Google Pay eller dev.shopify.shop_pay för Shop Pay. Företaget listar de hanterare det accepterar, plattformen kör en av dem, och vid complete får företaget en opak token att debitera via sin egen PSP.

I Googles tjänster är Google Pay den enda hanteraren, PAN_ONLY den enda autentiseringsmetoden som används, och din PSP ”måste kunna behandla våra tokens”. Stripe publicerar com.stripe.payments för kort och Apple Pay: ”Agenten skickar en delad betalningstoken (SPT) i förfrågan Complete Checkout, och säljaren debiterar den.” Google Pay ligger kvar på sin egen hanterare. PayPal stöder Google Pay-hanteraren via Braintree eller via sitt Orders v2 API.

Vad Google kräver innan Google anropar dig

Googles guide för inbyggd kassa kräver kassans REST-API och behåller betalningssteget: kunden anger känsliga uppgifter ”endast via Googles gränssnitt”. Servicenivåerna är minst 95 % tillgänglighet för varje endpoint, med latens för p50 och p95 på 1 och 4 sekunder för skapande, 1 och 5 för uppdatering och 6 och 10 för slutförande. Efter en beställning skickar du statusuppdateringar till en webhook hos Google med ett partner-ID och en nyckel som utfärdas vid anslutningen. I Merchant Center måste varje produkt ha native_commerce(checkout_eligibility) satt till true (attributet ”har FALSE som standardvärde”), en returpolicy och en kontaktuppgift till kundtjänst är obligatoriska, och prenumerationer, delbetalningar, personanpassade, begagnade och rekonditionerade varor, förbeställningar och åldersbegränsade varor är undantagna.

Det lättare alternativet, sedan 2026-04-08, är överföring av varukorgen (cart transfer): du implementerar bara skapandet av varukorgen, Google lämnar över varukorgen till din webbplats, och varken betalningshanterare eller webhook för beställningar behövs.

Åtkomsten är den verkliga begränsningen. Kassan är ”tillgänglig för utvalda handlare” via ett intresseformulär för tidig åtkomst, där du åtar dig att börja inom 30 dagar och godtar att åtkomsten ”kan tas bort” om du inte gör framsteg. Villkoren för UCP Checkout gäller ”endast för USA”. Navet i Merchant Center ska följa i Australien och Kanada ”i början av nästa år”; Google anger inget datum för kassan i något annat land.

UCP utanför Google

Microsoft Merchant Center har tagit emot UCP-klara flöden i USA sedan 21 april 2026. Copilot Checkout kräver ett UCP-kompatibelt flöde, tar emot engelskspråkiga handlare som säljer till köpare i USA i dollar med en PSP var, och butiksinställningen är märkt ”endast en pilot för utvalda kunder”. Shopify exponerar UCP via MCP på https://{shop}/api/ucp/mcp och har tagit bort sina äldre verktyg för katalog och varukorg. En funktion för bokning av logi slogs samman som utkast den 24 september 2026 och ingår inte i någon version.

AP2: Agent Payments Protocol

AP2 är inte ett tredje sätt att slutföra ett köp. Dess specifikation säger att det ”fungerar som en säkerhetsfunktion inom ett handelsprotokoll” och är ”uttryckligen utformat för att vara kompatibelt med Universal Commerce Protocol (UCP)”. Version 0.1.0 kom den 16 september 2025 och v0.2 den 28 april 2026, samma dag som Google överlämnade AP2 till FIDO Alliance. FIDO:s tillkännagivande namnger en arbetsgrupp för Agentic Authentication och en arbetsgrupp för Payments, med ordförande från Mastercard och Visa, och säger att bidragen ”kommer att granskas och vidareutvecklas”. FIDO har inte publicerat någon AP2-specifikation. GitHub-repot tar nu bara emot exempel och ändringar i SDK:er, och den senaste committen gjordes den 29 april.

Version 0.2 definierar ett Checkout Mandate (vad som köps) och ett Payment Mandate (betalningen, med begränsningar som payment.amount_range, payment.budget och payment.allowed_payees). Vart och ett är en SD-JWT i en sluten och en öppen variant (till exempel mandate.payment.1 och mandate.payment.open.1). I läget Human Present godkänner användaren de slutna mandaten. I läget Human Not Present godkänner användaren öppna mandat som sätter begränsningarna och som bär agentens publika nyckel i ett cnf-claim, och agenten sätter ihop de slutna mandaten inom de ramarna. Handledningar om Intent Mandates och Cart Mandates beskriver v0.1; de begreppen finns inte längre i v0.2.

Inuti UCP är AP2 tillägget dev.ucp.common.payment.ap2_mandate (dev.ucp.shopping.ap2_mandate före 2026-08-25). När det har förhandlats signerar företaget sina kassasvar, plattformen presenterar ett checkout_mandate och ett payment_mandate vid complete, och sessionen blir ”Security Locked” (säkerhetslåst): ingen av parterna får falla tillbaka på en vanlig kassa.

Ingen efterfrågar det än. Googles vanliga frågor kallar AP2 ”särskilt användbart för framtida scenarier med transaktioner som utförs av autonoma AI-agenter”. Googles egen agentprofil listar Google Pay som enda betalningshanterare och deklarerar ingen AP2-funktion, och profilen för 2026-08-25 har inte heller någon post för AP2. Ingen Google-produkt dokumenterar att den använder AP2, så det finns inget för en handlare att bygga förrän en plattform förhandlar om det.

Angränsande protokoll

MCP

ACP och UCP kan båda köras över MCP, vars nuvarande specifikation, 2026-07-28, tar bort sessioner och headern Mcp-Session-Id, slopar handskakningen initialize, kräver server/discover och får klienten att skicka om en förfrågan med ett nytt ID när strömmen bryts. ACP:s bindning länkar fortfarande till transporten i 2025-11-25. Ett ID för en kassasession är precis det slags handtag, skapat av servern, som den nya specifikationen förväntar sig, och en complete som går förlorad mitt i strömmen kommer tillbaka som en ny förfrågan: behandla idempotensnycklar som obligatoriska i båda protokollen.

WebMCP

WebMCP är en föreslagen webbstandard för att exponera en sidas egna funktioner för agenter i webbläsaren. Shopify erbjuder UCP-kassan både som Checkout MCP och som Checkout WebMCP, med samma kassaobjekt, och rekommenderar Checkout MCP. Vår guide till WebMCP går igenom var standarden står.

x402 och MPP

x402 och Machine Payments Protocol, som har utformats av Tempo och Stripe, debiterar en agent per HTTP-förfrågan för ett API, data eller innehåll. De är inte kassaprotokoll för butiker. Se vår artikel om x402.

Visa Trusted Agent Protocol och Mastercard Agent Pay

De ligger bredvid ACP och UCP snarare än att ersätta dem. Visas Trusted Agent Protocol ger en agent ”en standardiserad, kryptografisk metod” för att styrka sin identitet och sitt bemyndigande inför handlare, och Mastercard Agent Pay är ett tokeniseringsprogram för agentisk handel. Mastercards guide för handlare placerar UCP och ACP på sin högsta mognadsnivå, konstaterar att ”tidiga användare håller på att integrera” och råder handlare att börja med de två enklare nivåerna. Vår artikel om agentiska betalningar går igenom båda programmen.

Personal Agent Protocol

Sierra uppger att företaget tillkännagav Personal Agent Protocol (”Poppy”) tillsammans med Meta den 6 oktober 2026, och det publicerade ett utkast den 9 oktober. Ett företag publicerar en fil på /.well-known/poppy.json; protokollet använder OAuth, JWT:er, HTTPS, OpenAPI och MCP för att låta en personlig agent identifiera sig och få kundens tillstånd för alla slags uppgifter, och Sierra beskriver det som ett komplement till UCP. Protokollets webbplats visar version 0.2 och säger ”Det är ett utkast”. Vi hittade inget inlägg om det i Metas eget nyhetsrum.

Vilket behöver du?

På Shopify

Inget att bygga. Shopifys agentic storefronts är ”aktiva som standard för behöriga butiker”. ChatGPT får din katalog via Shopify Catalog och skickar kunderna till din butik. Googles direktkassa är påslagen som standard för butiker som är etablerade i USA och säljer dit, och Copilot anslöt Shopify-handlare automatiskt. Dina beslut gäller produktdata och om du ska behålla direktkassan påslagen, med vetskap om att anpassade pixlar inte körs i Googles kassa.

På Salesforce, commercetools eller en annan plattform

Salesforce B2C Commerce 26.9 stöder UCP 2026-01-23 och 2026-04-08: /.well-known/ucp med en supported_versions-mappning, och endpoints för kassasessioner bakom en SLAS-token. Salesforce anger att UCP-kassan på Google är allmänt tillgänglig i oktober 2026. En session är en headless-vy av en varukorg (basket), och Salesforces granskningsguide varnar för att controllers i SFRA och SiteGenesis och ”andra SCAPI-resurser som du använder i dag inte körs i det här flödet”, så logik som är kopplad till dem måste kopieras eller överbryggas till UCP:s hooks för kassasessioner. Flödet måste rikta sig mot en-US, och Salesforce ”hoppar inte över Googles väntelista”. För ChatGPT är Salesforce en av de leveransvägar som OpenAI nämner för ACP-flöden.

Kör du commercetools eller en annan plattform, fråga leverantören vilka UCP-versioner och funktioner den stöder, vilka av dina hooks som körs när en agent går igenom kassan och om den skickar flöden till OpenAI.

På egen programvara

1. Flöden först. Google Merchant Center och, när OpenAI har antagit dig, OpenAI:s produktflöde. ACP:s kommersiella användning i ChatGPT i dag är precis detta.
2. UCP för Google, om du säljer i USA och Google antar dig. Bygg mot 2026-04-08: profilen med com.google.pay, kassaoperationerna inom Googles latensmål, en PSP som behandlar tokens från Google Pay, webhooken för beställningar och flödesattributet. Eller börja med enbart överföring av varukorgen.
3. ACP-kassa bara om du har ett skäl, till exempel en ChatGPT-app som har antagits till betan för betalningsrutan. Bygg mot repots 2026-04-17.
4. AP2: inget än.
5. En gemensam kassakärna. Båda protokollen vill ha en session som kan skapas, uppdateras, slutföras och avbrytas via ett API, och där anrop säkert kan göras om. Bygg den en gång ovanpå din order-, skatte- och betalningslogik, med tunna adaptrar för ACP och UCP överst och MCP där agenter behöver det.

Inget av protokollen ger i dag ett företag med prenumerationer en inbyggd kassa för agenter.

Försäljning bara utanför USA

Inget av de tre ger dig en kassa för agenter i dag. Shopping i ChatGPT och OpenAI:s standarduppladdning av flöden gäller USA; Googles villkor för UCP Checkout gäller bara USA; Copilot Checkout betjänar köpare i USA i dollar. Googles nästa aviserade steg är navet i Merchant Center i Australien och Kanada ”i början av nästa år”, utan datum för Storbritannien eller EU.

Håll ditt flöde i Merchant Center komplett, och om du ändå bygger om kassan, bygg den API-drivna kärnan som beskrivs ovan, så blir en adapter ett litet jobb när din marknad öppnar. Säljer du till USA från utlandet? Kontrollera var varje program kräver att handlaren är etablerad; Shopifys direktkassa i Google kräver till exempel en amerikansk butik.

Var du får hjälp

Vi bygger protokollagret för butiker som inte kör Shopify: en profil på /.well-known/ucp och endpoints för kassasessioner ovanpå din befintliga order-, skatte- och betalningslogik, webhooks för beställningar till Google, produktflöden för Google Merchant Center och OpenAI, och MCP-servrar som exponerar samma kassa för agenter. Vår tjänst för integration av AI-agenter och MCP är där det arbetet börjar.

Skriv till office@c9group.dev med din plattform, din betaltjänstleverantör och de länder du säljer i, så talar vi om vilket protokoll som gäller och vad det skulle krävas för att implementera det. Googles och OpenAI:s programvillkor är avtal: vi är ingenjörer, inte jurister, så låt en rådgivare läsa dem innan du skriver under.