Universal Commerce Protocol
Universal Commerce Protocol, forkortet UCP, er en åpen protokoll for samhandling mellom handelssystemer. Den beskriver hvordan en virksomhet kan gjøre støttede funksjoner tilgjengelige for kompatible plattformer og agenter. For en nettbutikk er det viktigste spørsmålet hvilke funksjoner den aktuelle kjøpsreisen trenger, og om begge sider støtter dem.
Hva UCP skal løse
Når en agent skal utføre en handelsoppgave, trenger den mer enn produkttekst. Den må vite hvilke funksjoner butikken tilbyr, hvordan de brukes og hvilke svar den kan forvente. UCP beskriver en felles kontrakt for slik samhandling.
Dokumentasjonen skiller mellom virksomheten som tilbyr funksjonalitet og plattformen som bruker den. Betalings- og legitimasjonsleverandører har egne roller. Protokollen omfatter dermed samhandlingen mellom aktører, ikke bare informasjonen på en produktside.
En felles protokoll kan redusere behovet for særtilpasninger der begge aktører støtter den. Det er et formål med standarden, ikke et bevis på at deres butikk allerede er kompatibel eller at en bestemt AI-tjeneste kan gjennomføre kjøp hos dere.
Begrepene dere møter i en UCP-vurdering
En vurdering må skille mellom hvilken oppgave som støttes, hvordan systemene kommuniserer og hvilken versjon de bruker. Det er ikke nok at begge sier at de «støtter UCP». De må støtte den aktuelle funksjonen på en kompatibel måte.
| Begrep | Betydning | Spørsmål til leverandøren |
|---|---|---|
| Capability | En avgrenset funksjon, som checkout | Hvilke funksjoner støttes i produksjon? |
| Extension | En utvidelse av en funksjon | Hvilke tilleggsbehov håndteres? |
| Service og transport | Hvordan operasjoner gjøres tilgjengelige | Hvilket grensesnitt bruker integrasjonen? |
| Profil | Maskinlesbar beskrivelse av støtte | Hvor ligger profilen og hva erklærer den? |
| Versjon | Utgaven av kontrakten som brukes | Hvilken versjon støtter begge parter? |
Fra støtteerklæring til en faktisk kjøpsflyt
UCP beskriver en maskinlesbar virksomhetsprofil på /.well-known/ucp. Profilen erklærer blant annet støttede tjenester og funksjoner. En profil bør beskrive det virksomheten faktisk kan utføre, ikke en ønskeliste over fremtidige funksjoner.
De to partene må finne et felles sett med funksjoner og versjoner. En funksjon som bare én part støtter, kan ikke tas for gitt i kjøpsreisen. Tilleggsfunksjoner har også avhengigheter. Derfor må leverandøren vise den konkrete kombinasjonen som skal brukes.
Checkout er en tilstandsstyrt prosess. Produktvalg, adresse, levering, totalsum og betalingshåndtering kan endres før ordren er ferdig. En pilot må vise at disse endringene håndteres, og at systemene er enige om resultatet. Det er mer enn en test av at en server svarer.
UCP, ACP, MCP og produktfeed har ulike roller
En produktfeed gir en mottaker katalogdata. UCP beskriver handelsfunksjoner og hvordan kompatible parter bruker dem. MCP gjør verktøy og data tilgjengelige for AI-systemer og kan være en transport i en UCP-løsning. Disse delene kan inngå i samme system uten å være det samme.
ACP er en annen protokoll for agentbasert handel. Det riktige valget avhenger av den konkrete kanalen, butikkplattformen, tilgangen og hvilke operasjoner dere vil støtte. Dere bør ikke velge en protokoll bare fordi den er omtalt som fremtidens standard.
En integrasjon med én tjeneste er heller ikke automatisk en integrasjon med alle AI-modeller. Be om dokumentasjon for den plattformen, funksjonen og versjonen dere skal bruke.
| Del | Primær oppgave | Hva den alene ikke dokumenterer |
|---|---|---|
| Produktfeed | Overføre katalogdata til en mottaker | En fungerende checkout |
| Produktmarkup | Beskrive synlig produktinformasjon | Tilgang til en handelskanal |
| MCP | Eksponere verktøy og data | Komplett ordre- og betalingsflyt |
| UCP eller ACP | Beskrive en handelsintegrasjon | At den aktuelle plattformen godkjenner butikken |
Hva nettbutikken bør avklare før utvikling
Start med en forretningsoppgave: skal agenten forberede en handlekurv, avklare levering eller gjennomføre en støttet checkout? Be deretter leverandøren beskrive hvordan oppgaven kobles til eksisterende produkt-, betalings- og ordresystemer.
Tilgang og ansvar må være tydelig. Hvem kan opprette og endre en kjøpsøkt? Hvordan bekrefter kunden det som skal gjennomføres? Hvilket system er autoritativt for pris og ordrestatus? Hvem følger opp kunden dersom deler av flyten feiler?
Kontroller gjeldende spesifikasjon når prosjektet avgrenses. UCP har versjoner og dokumentasjon under utvikling; et utkast bør ikke omtales som stabil produksjonsstøtte. Noter versjonen i krav og testresultater, slik at støtte kan etterprøves.
- Aktuell kanal, marked og butikkplattform
- Funksjoner og versjoner som begge parter støtter
- Dataflyt til produkt-, lager- og ordresystemer
- Kundens godkjenning og ansvar for betaling
- Drift, oppgraderinger og håndtering av feil
Hva en pilot bør bevise
En egnet pilot omfatter et avgrenset produktutvalg og avtalte kjøpssituasjoner. Den bør prøve både en normal flyt og avvik som endret pris, utsolgt variant, avbrudd og gjentatte forespørsler.
Resultatet skal vise hva som fungerer, hva som feiler og hva som kreves for videre drift. En fungerende demonstrasjon er ikke en garanti for plattformgodkjenning, lønnsomhet eller bred markedsstøtte. Det er et beslutningsgrunnlag for en konkret integrasjon.
FAQ
Spørsmål om Universal Commerce Protocol
Universal Commerce Protocol. Det er en åpen protokoll for samhandling mellom aktører som tilbyr og bruker handelsfunksjoner.
UCP alene dokumenterer ikke produktsynlighet. Synlighet, katalogtilgang og gjennomføring av handelsoppgaver er forskjellige deler av kjøpsreisen.
Nei. En feed overfører katalogopplysninger til en mottaker. UCP beskriver funksjoner og samhandling mellom kompatible systemer.
UCP beskriver flere transportmuligheter. Den konkrete løsningen avgjør hvilket grensesnitt som brukes. MCP skal ikke tas for gitt som et krav til alle UCP-integrasjoner.
En profil erklærer støtte; den implementerer ikke funksjonene. Erklærte operasjoner må fungere i systemene bak og kunne prøves mot en kompatibel motpart.
Velg etter faktisk kanalstøtte, tilgang og kjøpsbehov. Sammenlign konkrete integrasjoner og driftskrav fremfor navnene på protokollene.
Ikke anta det. Sjekk versjon og status for den enkelte funksjonen i gjeldende spesifikasjon og bekreft leverandørens produksjonsstøtte.
Vi kan avklare kjøpsreisen, dataforutsetninger og aktuelle integrasjonskrav. Implementering, tilgang og drift må avgrenses sammen med butikkens tekniske leverandører.
Les videre om AI-assistert handel
Produktfeed for AI-modeller
En produktfeed er en strukturert overføring av katalogdata til en mottaker. Den kan hjelpe en AI-tjeneste å forstå hvilke varer dere selger, hva de koster og hvilke varianter som er tilgjengelige. Hver mottaker bestemmer format, felt, tilgang og hvordan opplysningene brukes. Det finnes ikke én produktfeed som automatisk fungerer i alle AI-modeller.
Produktdata for AI-søk
Produktdata gjør det mulig å vurdere om en vare passer et konkret behov. For AI-assistert handel er det særlig viktig at produkt, variant, egenskaper og tilbud kan kobles riktig. Jobben starter i datagrunnlaget, før dere velger feed, protokoll eller integrasjon.
Agent Commerce
Se konkrete leveranser, kjøpssituasjoner og hvordan et avgrenset oppdrag gjennomføres.
Kilder og gjeldende spesifikasjoner
Faglig gjennomgått 4. oktober 2026. Formater, tilgang og protokollstøtte kan endres. Bruk mottakerens gjeldende dokumentasjon når en integrasjon avgrenses.
Start med én konkret kjøpsreise
Fortell hvilken nettbutikk dere bruker, hva dere selger og hvor dere ser problemer med produktdata eller kjøpsflyt. Vi avklarer hva som bør undersøkes først.
Var dette nyttig?