ACP, UCP og AP2 sammenlignet: protokollene for agentisk handel i oktober 2026, og hvilken nettbutikken din trenger

Tre åpne protokoller beskriver nå hvordan en KI-agent kjøper fra en nettbutikk. Agentic Commerce Protocol (ACP) kommer fra OpenAI og Stripe. Universal Commerce Protocol (UCP) kommer fra Google og Shopify. Agent Payments Protocol (AP2), som Google startet og ga til FIDO Alliance i april, er ikke en kasseprotokoll i det hele tatt: Den definerer et signert bevis på at en bruker har godkjent en betaling, og den er laget for å ligge inne i UCP. Alle tre har lisensen Apache 2.0.

Per 22. oktober 2026 står de på svært ulike steder. ACP er merket som beta, siste utgivelse er 2026-04-17, og det er ikke gjort noen commits siden 17. juli. ChatGPT, den viktigste brukeren av protokollen, gikk bort fra frittstående kasse i mars og bruker nå ACP mest til å ta imot produktdata. UCP publiserte en bakoverinkompatibel versjon, 2026-08-25, i august, mens Googles egne tjenester fortsatt kjører 2026-04-08 og kassen der er i tidlig tilgang, bare i USA. AP2 er på v0.2, og ingen Google-produkter dokumenterer at de bruker den.

Denne artikkelen er for teknologidirektører (CTO-er) og ledende utviklere i nettbutikker og handelsplattformer som skal bestemme hva de implementerer. Vil du vite hva hver KI-plattform krever av en nettbutikk som virksomhet, begynner du med oversikten vår over agentisk handel.

Side om side

ACP: Agentic Commerce Protocol

Styring og versjoner

Spesifikasjonsrepositoriet sier at ACP vedlikeholdes av OpenAI og Stripe, og merker den som beta. Styringsdokumentet gjør de to til Founding Maintainers (grunnleggende vedlikeholdere): De utnevner medlemmene av styringskomiteen (opptil sju) og beholder en vetorett som skal brukes «som en siste utvei». Meta ble med som tredje hovedvedlikeholder og komitémedlem 24. april 2026. Stripes dokumentasjon sier at ACP er «laget av Stripe, OpenAI og Meta», men NOTICE-filen i repositoriet krediterer bare OpenAI og Stripe. En nøytral stiftelse er bare en uttalt mulighet for fremtiden.

Det finnes fem daterte utgivelser: 2025-09-29 (kasse og delegert betaling), 2025-12-12 (bakoverinkompatible endringer basert på erfaringene fra adapterne for URBN og Etsy), 2026-01-16 (en 3DS-leverandør som forhandleren velger selv), 2026-01-30 (forhandling av funksjoner, utvidelser og et bakoverinkompatibelt rammeverk for betalingshåndterere) og 2026-04-17 (handlekurv, feed, bestillinger, delegert autentisering, oppdagelse og MCP), som gjorde 2026-01-30 foreldet. Det har ikke kommet noen utgivelse på de seks månedene siden. Mappen unreleased/ inneholder mindre endringer datert fram til 17. juli, som en ID for feedoppdateringer og en valgfri produkt-URL på varene i kassen.

Hva en forhandler implementerer i 2026-04-17

Kasse-API-et driftes av forhandleren og kalles av agenten:

• POST /checkout_sessions oppretter en økt, POST /checkout_sessions/{checkout_session_id} oppdaterer den (en POST, ikke en PUT), GET på samme sti henter den, og .../complete og .../cancel avslutter den.
• Forespørslene har med en bearer-API-nøkkel og en obligatorisk API-Version-header. Siden 2026-04-17 er en Idempotency-Key påkrevd på hver POST, med definerte feil: 400 idempotency_key_required, 409 idempotency_in_flight og 422 idempotency_conflict.
• Opprettelsesforespørselen har med et capabilities-objekt. Agenten oppgir hva den støtter, og selgeren returnerer snittet, slik at en uforenlighet viser seg før betalingen.
• Forhandleren sender bestillingshendelser med POST til en mottaker OpenAI drifter på /agentic_checkout/webhooks/order_events, signert med HMAC-SHA256 i en Merchant-Signature-header. Statusene går fra created til delivered eller canceled, og adjustments[] bærer refusjoner, returer, tvister og tilbakeføringer (chargebacks).

Utgivelsen 2026-04-17 la også til en statisk, offentlig /.well-known/acp.json, der feltet transports sier om butikken snakker rest, mcp eller begge. Den la til en MCP-binding over Streamable HTTP med fem verktøy (create_checkout_session, get_checkout_session, update_checkout_session, complete_checkout_session, cancel_checkout_session), autentisert i serverkonfigurasjonen og ikke per forespørsel. Og den la til et Feed API som agenten drifter og forhandleren sender til (POST /feeds, PATCH /feeds/{id}/products), en handlekurv for én selger uten betalingsdata (POST /carts, PUT /carts/{id}) og delegert 3DS2-autentisering (POST /delegate_authentication). Abonnementer finnes ikke: RFC-en for utvidelser oppgir subscription som «Støtte for gjentakende fakturering (fremtidig)».

Slik fungerer betaling i ACP

ACPs opprinnelige svar er delegert betaling. PSP-en eller kortlageret (card vault) implementerer POST /agentic_commerce/delegate_payment, som gjør et kort (den eneste typen betalingsopplysning) om til et token som forhandlerens PSP bare kan bruke innenfor en ramme: reason (bare one_time), max_amount, currency, checkout_session_id, merchant_id og expires_at. Med RFC-ens ord: «Betalinger, oppgjør og etterlevelse forblir på forhandlerens egen infrastruktur.» Worldpay dokumenterer sin egen versjon av kallet, og PayPal støtter ACP gjennom delegerte tokener i Braintree.

Siden 2026-01-30 deklareres betalingsmetodene som godtas, som håndterere under capabilities.payment.handlers. Eksempelet på betalingsdata i endringsloggen:

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

spt er Stripes Shared Payment Token, tilgjengelig «i USA, Canada og utvalgte europeiske land». En selger på Stripe belaster det med payment_method_data[shared_payment_granted_token] på en forhåndsversjon av API-et; en selger med en annen betalingsbehandler kan løse det opp til nettverkets betalingsopplysninger én gang. Artikkelen vår om agentiske betalinger tar for seg hvem som bærer risikoen.

Hva OpenAIs kursendring i mars betydde

Den 24. mars 2026 skrev OpenAI at «den første versjonen av Instant Checkout ga ikke den graden av fleksibilitet vi har som mål å tilby», lot forhandlerne bruke sine egne kasser og sa at selskapet «utvider ACP til å bli bindeleddet mellom forhandlere og brukere gjennom hele oppdagelsen». Target, Sephora, Nordstrom, Lowe's, Best Buy, The Home Depot og Wayfair hadde integrert ACP for oppdagelse, og Shopify-kataloger kommer inn gjennom Shopify Catalog. Hva det betyr for en utvikler:

• Feeden er den delen som er i drift. OpenAIs side for forhandlere sier at kjøp «fullføres på nettsteder eller i apper som forhandleren eier», og at shopping er i drift for brukere i USA. Onboarding av feeder er for godkjente partnere fra en venteliste: en daglig fullstendig fil over SFTP med ni obligatoriske felt, API-oppdateringer i løpet av dagen, kampanjer bare via API. Standardopplastingen «retter seg foreløpig mot USA».
• Kassen er en egen port. Feedspesifikasjonen sier at kassen «krever en integrasjon som aktiveres separat». For ChatGPT-apper er den generelt tilgjengelige veien en ekstern kasse på utviklerens eget domene. Betalingsvinduet i chatten er en privat beta «begrenset til utvalgte markedsplasser», som gir et betalingstoken til appens MCP-server i et complete_checkout-verktøykall.
• OpenAIs sider henger etter spesifikasjonen. Kassereferansen viser fortsatt API-Version 2025-09-12 og en provider-enum med stripe, adyen og braintree. Bygg etter repositoriet, og få bekreftet av OpenAI hvilken versjon de godtar.

PSP-sider som fortsatt presenterer Instant Checkout som i drift, er utdaterte.

UCP: Universal Commerce Protocol

Styring og versjoner

Google lanserte UCP 11. januar 2026, utviklet sammen med Shopify, Etsy, Wayfair, Target og Walmart. Styringsreglene gir Google og Shopify én fast stemme hver i Governing Council (styringsrådet), som Stripe ble med i 28. april 2026, og slår fast at «Google har fullmaktsstemmen for alle ledige plasser fram til des. 2028». Den 24. april ble Shopping Tech Council utvidet til 16 plasser, med Amazon, Meta, Microsoft, Salesforce og Stripe, slik at Meta og Stripe nå sitter både i ACPs komité og i UCPs råd.

Repositoriet har fire utgivelser. 2026-04-08 la til funksjoner for handlekurv og katalog, signering av forespørsler og svar, og Get Order. 2026-08-25 er bakoverinkompatibel: signing_keys[] ble erstattet av et JWK Set i keys[], betalingsutvidelsene flyttet fra dev.ucp.shopping.* til dev.ucp.common.payment.*, felles skjemaer ble flyttet og fikk nye $id-URL-er, og PAN og nettverkstokener ble egne typer betalingsopplysninger. Den la også til leverandøruavhengig 3DS2, delte betalinger, betalingsbetingelser og interoperabilitet med Web Bot Auth.

Her ligger fellen. Googles profilveiledning dekker bare 2026-04-08 og 2026-01-23, Googles egen agentprofil på ucp.goog oppgir "version": "2026-04-08", og Salesforce B2C Commerce 26.9 leverer de samme to versjonene. Shopifys Checkout MCP lenker derimot til 2026-08-25. Bygger du etter siste utgivelse, bygger du en versjon Google ikke dokumenterer. Spesifikasjonens svar er et supported_versions-objekt som knytter hver eldre versjon til sin egen profil-URI.

Oppdagelse, transport og autentisering

Hver virksomhet publiserer en profil på /.well-known/ucp med ucp.version, ucp.services og ucp.payment_handlers, og Google krever at den er offentlig og tilgjengelig uten autentisering. Agentens plattform publiserer også en, og hver forespørsel har med URI-en til den i en UCP-Agent-header, over HTTPS med minst TLS 1.3. Autentisering er virksomhetens valg: ingen, X-API-Key, OAuth 2.0, gjensidig TLS (mutual TLS) eller HTTP Message Signatures etter RFC 9421. Google sender et bearer-token, og Googles spørsmål og svar om UCP tilbyr også mTLS. En Idempotency-Key er bare en «SHOULD»; en server som godtar en, beholder den i minst 24 timer og svarer 409 når den gjenbrukes med et annet innhold i forespørselen.

REST er kjernetransporten, sammen med MCP, en A2A-utvidelse og en innebygd modus som nås gjennom en continue_url. Bestillinger er en GET /orders/{id} pluss en webhook fra virksomheten til plattformen, signert etter RFC 9421. Stiene for handlekurven er de samme som i ACP. Kasseoperasjonene ligner hverandre, men er ikke utskiftbare:

Én kassekjerne kan betjene begge. Én rutetabell kan ikke det.

Slik fungerer betaling i UCP

UCP flytter ikke penger. En betalingshåndterer (payment handler) er en spesifikasjon skrevet av en leverandør av betalingsopplysninger, som com.google.pay for Google Pay eller dev.shopify.shop_pay for Shop Pay. Virksomheten lister opp håndtererne den godtar, plattformen kjører én av dem, og ved complete mottar virksomheten et opakt token som den belaster gjennom sin egen PSP.

I Googles tjenester er Google Pay den eneste håndtereren, PAN_ONLY er den eneste autentiseringsmetoden som brukes, og PSP-en din «må kunne behandle tokenene våre». Stripe publiserer com.stripe.payments for kort og Apple Pay: «Agenten sender et delt betalingstoken (SPT) i Complete Checkout-forespørselen, og selgeren belaster det.» Google Pay forblir på sin egen håndterer. PayPal støtter Google Pay-håndtereren gjennom Braintree eller gjennom sitt Orders v2 API.

Hva Google krever før de kaller deg

Googles veiledning for innebygd kasse krever kasse-API-et over REST og beholder selv betalingssteget: Kunden oppgir sensitive opplysninger «bare i Googles brukergrensesnitt». Tjenestenivåene er minst 95 % tilgjengelighet på hvert endepunkt, med p50- og p95-svartid på 1 og 4 sekunder for opprettelse, 1 og 5 for oppdatering og 6 og 10 for fullføring. Etter en bestilling sender du statusoppdateringer til en webhook hos Google med en partner-ID og en nøkkel som utstedes ved onboarding. I Merchant Center må hvert produkt ha native_commerce(checkout_eligibility) satt til true (attributtet «har FALSE som standardverdi»), returvilkår og kontaktinformasjon for kundeservice er obligatorisk, og abonnementer, avbetaling, personaliserte, brukte og overhalte varer, forhåndsbestillinger og aldersbegrensede varer er unntatt.

Det lettere alternativet, siden 2026-04-08, er overføring av handlekurv (cart transfer): Du implementerer bare opprettelse av handlekurv, Google sender handlekurven til nettstedet ditt, og du trenger verken betalingshåndterer eller ordrewebhook.

Tilgangen er den egentlige begrensningen. Kassen er «tilgjengelig for utvalgte forhandlere» gjennom et interesseskjema for tidlig tilgang, der du forplikter deg til å starte innen 30 dager og godtar at tilgangen «kan bli fjernet» hvis du ikke gjør fremskritt. Vilkårene for UCP Checkout gjelder «bare for USA». Huben i Merchant Center skal etter planen komme til Australia og Canada «tidlig neste år»; Google oppgir ingen dato for kassen i noe annet land.

UCP utenfor Google

Microsoft Merchant Center har tatt imot UCP-klare feeder i USA siden 21. april 2026. Copilot Checkout krever en UCP-kompatibel feed, tar imot engelskspråklige forhandlere som selger til kjøpere i USA i dollar med én PSP hver, og butikkinnstillingen er merket «kun som pilot for utvalgte kunder». Shopify eksponerer UCP over MCP på https://{shop}/api/ucp/mcp og har fjernet sine eldre verktøy for katalog og handlekurv. En funksjon for overnattingsbestilling ble slått sammen som utkast 24. september 2026 og er ikke med i noen utgivelse.

AP2: Agent Payments Protocol

AP2 er ikke en tredje måte å gjennomføre et kjøp på. Spesifikasjonen sier at den «fungerer som en sikkerhetsfunksjon i en handelsprotokoll» og er «utformet uttrykkelig for å være kompatibel med Universal Commerce Protocol (UCP)». Versjon 0.1.0 kom 16. september 2025 og v0.2 28. april 2026, samme dag som Google ga AP2 til FIDO Alliance. FIDOs kunngjøring nevner en arbeidsgruppe for agentisk autentisering (Agentic Authentication) og en arbeidsgruppe for betalinger (Payments), ledet av medlemmer fra Mastercard og Visa, og sier at bidragene «vil bli gjennomgått og videreutviklet». FIDO har ikke publisert noen AP2-spesifikasjon. GitHub-repositoriet tar nå bare imot eksempler og SDK-endringer, og siste commit var 29. april.

Versjon 0.2 definerer et Checkout Mandate (hva som kjøpes) og et Payment Mandate (betalingen, med begrensninger som payment.amount_range, payment.budget og payment.allowed_payees). Hvert av dem er en SD-JWT i en lukket og en åpen form (for eksempel mandate.payment.1 og mandate.payment.open.1). I modusen Human Present godkjenner brukeren de lukkede mandatene. I modusen Human Not Present godkjenner brukeren åpne mandater som setter rammene og har med agentens offentlige nøkkel i en cnf-claim, og agenten setter sammen de lukkede innenfor disse grensene. Veiledninger om Intent Mandates og Cart Mandates beskriver v0.1; de begrepene er borte fra v0.2.

Inne i UCP er AP2 utvidelsen dev.ucp.common.payment.ap2_mandate (dev.ucp.shopping.ap2_mandate før 2026-08-25). Når den er forhandlet fram, signerer virksomheten kassesvarene sine, plattformen legger fram et checkout_mandate og et payment_mandate ved complete, og økten er «Security Locked»: Ingen av partene kan falle tilbake til en vanlig kasse.

Ingen etterspør den ennå. Googles spørsmål og svar om UCP kaller AP2 «særlig nyttig i fremtidige scenarioer med transaksjoner utført av autonome KI-agenter». Googles egen agentprofil oppgir Google Pay som eneste betalingshåndterer og deklarerer ingen AP2-funksjon, og 2026-08-25-profilen har heller ingen AP2-oppføring. Ingen Google-produkter dokumenterer bruk av AP2, så det er ingenting for en forhandler å bygge før en plattform forhandler den fram.

Naboprotokollene

MCP

ACP og UCP kan begge kjøre over MCP, der gjeldende spesifikasjon, 2026-07-28, fjerner økter (sessions) og Mcp-Session-Id-headeren, dropper initialize-håndtrykket, krever server/discover og lar en klient sende en forespørsel på nytt med ny ID når strømmen brytes. ACPs binding lenker fortsatt til transporten fra 2025-11-25. En ID for en kasseøkt er nettopp det håndtaket utstedt av serveren som den nye spesifikasjonen forventer, og en complete som går tapt midt i strømmen, kommer tilbake som en ny forespørsel: Behandle idempotensnøkler som obligatoriske i begge protokollene.

WebMCP

WebMCP er en foreslått nettstandard for å gjøre en sides egne funksjoner tilgjengelige for nettleseragenter. Shopify tilbyr UCP-kasse både som Checkout MCP og som Checkout WebMCP, med det samme kasseobjektet, og anbefaler Checkout MCP. WebMCP-guiden vår tar for seg statusen.

x402 og MPP

x402 og Machine Payments Protocol, utviklet av Tempo og Stripe, tar betalt fra en agent per HTTP-forespørsel for et API, data eller innhold. De er ikke kasseprotokoller for nettbutikker. Se artikkelen vår om x402.

Visa Trusted Agent Protocol og Mastercard Agent Pay

Disse står ved siden av ACP og UCP i stedet for å erstatte dem. Visas Trusted Agent Protocol gir en agent «en standardisert, kryptografisk metode» for å bevise identiteten og fullmakten sin overfor forhandlere, og Mastercard Agent Pay er et tokeniseringsprogram for agentisk handel. Mastercards veiledning for forhandlere plasserer UCP og ACP på sitt høyeste modenhetsnivå, påpeker at «tidlige brukere er i gang med å integrere nå», og råder forhandlere til å begynne med de to enklere nivåene. Artikkelen vår om agentiske betalinger tar for seg begge programmene.

Personal Agent Protocol

Sierra sier at selskapet kunngjorde Personal Agent Protocol («Poppy») sammen med Meta 6. oktober 2026, og det publiserte et utkast 9. oktober. Et selskap publiserer én fil på /.well-known/poppy.json; protokollen bruker OAuth, JWT-er, HTTPS, OpenAPI og MCP for at en personlig agent skal kunne identifisere seg og få kundens tillatelse til alle slags oppgaver, og Sierra beskriver den som et supplement til UCP. Protokollsiden viser versjon 0.2 og sier «Det er et utkast». Vi fant ingen omtale av den i Metas eget nyhetsrom.

Hvilken trenger du?

På Shopify

Ingenting å bygge. Shopifys agentiske butikkfronter er «aktive som standard for kvalifiserte butikker». ChatGPT får katalogen din gjennom Shopify Catalog og sender kundene til butikken din. Googles direkte kasse er slått på som standard for butikker som er etablert i og selger til USA, og Copilot meldte inn Shopify-forhandlere automatisk. Det du må bestemme, er produktdataene og om du vil beholde den direkte kassen, vel vitende om at egendefinerte piksler (custom pixels) ikke utløses i Googles kasse.

På Salesforce, commercetools eller en annen plattform

Salesforce B2C Commerce 26.9 leverer UCP 2026-01-23 og 2026-04-08: /.well-known/ucp med et supported_versions-kart, og endepunktene for kasseøkter bak et SLAS-token. Salesforce oppfører UCP-kasse i Google som generelt tilgjengelig i oktober 2026. En økt er en headless-visning av en handlekurv, og Salesforces veiledning for teknisk gjennomgang advarer om at SFRA- og SiteGenesis-kontrollere og «andre SCAPI-ressurser du bruker i dag, ikke kjører i denne flyten», så logikk som er knyttet til dem, må kopieres eller kobles over til UCP-hookene for kasseøkter. Feeden må være rettet mot en-US, og Salesforce «hopper ikke over Googles venteliste». For ChatGPT er Salesforce en av leveringsveiene OpenAI nevner for ACP-feeder.

På commercetools eller en annen plattform spør du leverandøren hvilke UCP-versjoner og -funksjoner den leverer, hvilke av hookene dine som kjører i en agentkasse, og om den sender feeder til OpenAI.

På egen programvare

1. Feeder først. Google Merchant Center og, når OpenAI slipper deg inn, OpenAIs produktfeed. ACPs kommersielle bruk i ChatGPT i dag er nettopp dette.
2. UCP for Google, hvis du selger i USA og Google slipper deg inn. Bygg etter 2026-04-08: profilen med com.google.pay, kasseoperasjonene innenfor Googles mål for svartid, en PSP som behandler Google Pay-tokener, ordrewebhooken og feedattributtet. Eller begynn med bare overføring av handlekurv.
3. ACP-kasse bare med en god grunn, for eksempel en ChatGPT-app som er tatt opp i betaversjonen av betalingsvinduet. Bygg etter repositoriets 2026-04-17.
4. AP2: ingenting ennå.
5. Én kassekjerne. Begge protokollene vil ha en økt som kan opprettes, oppdateres, fullføres og avbrytes over et API og trygt prøves på nytt. Bygg den én gang over ordre-, skatte- og betalingslogikken din, med tynne ACP- og UCP-adaptere på toppen og MCP der agentene trenger det.

Ingen av protokollene gir en abonnementsvirksomhet innebygd agentkasse i dag.

Salg bare utenfor USA

Ingen av de tre gir deg en agentkasse i dag. Shopping i ChatGPT og OpenAIs standard feedopplasting gjelder USA; Googles vilkår for UCP Checkout gjelder bare USA; Copilot Checkout betjener kjøpere i USA i dollar. Googles neste kunngjorte steg er huben i Merchant Center i Australia og Canada «tidlig neste år», uten dato for Storbritannia eller EU.

Hold Merchant Center-feeden din komplett, og bygger du om kassen likevel, så bygg den API-drevne kjernen som er beskrevet over, slik at en adapter blir en liten jobb når markedet ditt åpner. Selger du til USA fra utlandet? Sjekk hvor hvert program krever at forhandleren er etablert; Shopifys direkte kasse i Google krever for eksempel en butikk i USA.

Hvor du får hjelp

Vi bygger protokollaget for nettbutikker som ikke kjører på Shopify: en /.well-known/ucp-profil og endepunkter for kasseøkter oppå den eksisterende ordre-, skatte- og betalingslogikken din, ordrewebhooks til Google, produktfeeder for Google Merchant Center og OpenAI, og MCP-servere som gjør den samme kassen tilgjengelig for agenter. Vår tjeneste for utvikling av KI-agenter og MCP-integrasjon er der dette arbeidet starter.

Skriv til office@c9group.dev med plattformen din, betalingsleverandøren din og landene du selger i, så forteller vi deg hvilken protokoll som gjelder, og hva det vil kreve å implementere den. Programvilkårene til Google og OpenAI er kontrakter: Vi er ingeniører, ikke jurister, så la en rådgiver lese dem før du signerer.