Agentikus kereskedelem webshopfejlesztőknek: UCP, ACP és AP2

Az agentikus kereskedelem az a kísérlet, hogy egy nyelvi modell egy felhasználó nevében dolgokat vegyen, és ahhoz gépi interfész kell a vásárláshoz: protokoll, nem weboldal. 2026 szeptemberétől három számít. A Universal Commerce Protocol (UCP) a teljes kereskedelmi életciklust fedi le, az Agentic Commerce Protocol (ACP) a rendeléseket és a fizetést egy asszisztensen belül, az Agent Payments Protocol (AP2) pedig annak igazolását, hogy egy ember tényleg jóváhagyta, amit az ügynök tett.

Ez a cikk mechanizmusonként hasonlítja össze őket, és azzal végződik, mit építsen most egy közepes méretű EU-webshop. A rövid verzió: mindhárom a kereskedőt tartja merchant of recordnek, és egyik sem kéri, hogy újráírd a checkoutodat.

Miért kell a vásárlóügynököknek egyáltalán protokoll

Egy böngészőügynök, amely a checkoutoldaladat kezeli, minden résztvevő számára rossz ötlet. Rossz helyre kattint, nem látja a rejtett díjat, tippel a szállítási mezőnél, az auditnyom pedig egy videó arról, hogyan mozog a kurzor. A fizetésnél még rosszabb: olyan ügynök, amely beírja a kártyaszámokat, olyan ügynök, amely kezeli a kártyaszámokat.

A protokoll a kattintást aláírt, strukturált üzenetekre cseréli. Az ügynök terméket kér egy kereskedő rendszerétől, kosarat épít, checkout sessiont indít, és visszakap valamit, amit egy embernek meg tud mutatni, a kereskedő pedig továbbra is a saját rendszerében számol árat, adót, teljesítést és visszatérítést. A Stripe kerete a legélesebb változata: a hagyományos e-kereskedelem azt feltételezte, hogy egy ember egy vállalat által kezelt oldalon kattint a „Megveszem” gombra, és „az AI-vezérelt kereskedelemben az ügynökök a vevő nevében cselekszenek, és viszik az identitását, fizetési eszközét és vásárlási kontextusát a tranzakcióba”.

A fejlesztők szempontjából az a következmény, amelyik gazdaságilag számít: az ügynökök felé néző felület egy második frontend. Kettő már van (a webshopod és a checkoutod); a harmadik nem újraírás, de valódi munka, és a legtöbb csapatnak itt érdemes kezdenie.

Mit fed le valójában az UCP

Az Universal Commerce Protocol a három közül a legszélesebb. Öt alap képességet ír le: katalóguskeresés és -lekérdezés, kosárépítés, identitás-összekapcsolás, checkout és rendeléskezelés; a szállásra van egy folyamatban lévő tervezet, az étteremezést bejelentették. REST-en és JSON-RPC-n fut, és mellette AP2, A2A és MCP is támogatott, vagyis ugyanaz a kereskedő kiszolgálhat egy asszisztenst, egy ügynök-ügynök folyamatot és egy MCP klienst.

Az UCP két tervezési döntését érdemes lemásolni, függetlenül attól, hogy használod-e. Az első, hogy a vállalat marad merchant of record: a dokumentáció egyértelműen kimondja, hogy a vállalat megtartja az irányítást, a saját üzleti logikáját és a vevői kapcsolatot. A második az identitás-összekapcsolás OAuth 2.0 fölött: az ügynök így nem a vevő hitelesítő adatainak másolatát tartja meg, hanem engedélyezett, korlátozott hatókörű kapcsolatot a kereskedővel. A mintát adó authorization server dokumentum egy dev.ucp.shopping.checkout jellegű hatóköröt hirdet egy szabványos /.well-known/oauth-authorization-server dokumentumban, ami egy szokásos OAuth-integráció, amit át tudsz nézni anélkül, hogy találgatnál.

Hogyan fut végig egy UCP-vásárlás a rendszeren

Az UCP oldalán lévő mintapayloadok a leggyorsabb út a felépítés megértéséhez, mert megmutatják azokat a mezőket, amelyekre egy kereskedőnek tudnia kell válaszolni. Egy katalógusválasz termékeket tartalmaz variánsokkal, SKU-val, opciókkal, minor unitben megadott ártartományokkal, egyszerre három taxonómiából származó kategóriákkal (egy platformtaxonómia, a kereskedő sajátja és egy Google termékkategória), alt szöveggel ellátott médiával, értékelésekkel, szabad metadata-val és egy lapozási kurzorral. Ez egy termékfeed, amellyel egy ügynök oldaltöredelés nélkül dolgozhat.

Egy kosár több, mint egy sorszámlista. A mintakosár contextet tartalmaz a vevő országával, régiójával, irányítószámával, szándékával, nyelvével és valutájával; egy attribution blokkot forrással, csatornával, kampánnyal, kattintási azonosítóval és refererrel; egy buyer-t; összegeket; messages mezőket azokhoz a dolgokhoz, amelyeket az ügynöknek ki kell mondania; linkeket az adatvédelmi tájékoztatóhoz, az ÁSZF-hez és a GYIK-hoz; géppel olvasható policies mezőket, mint egy visszatérítési szabályzatot, JSON pointerekkel megadva, mely sorszámokra vonatkozik; egy continue_url-t, ami visszahozza a vásárlót a saját oldaladra; és egy expires_at mezőt. Két ilyen mező fontosabb, mint látszik: az attribúció megőrzi, melyik csatornán érkezett a vevő, a szabályzatblokk pedig így tanítja meg az ügynöknek a visszatérítési feltételeidet ahelyett, hogy tippelne.

A checkout egy session-objektum, amelynek van egy állapota, például ready_for_complete, továbbá sorszámai, összegei, fizetési és teljesítési csoportjai választható szállítási lehetőségekkel. A rendelés objektum ezután hordoz egy checkout_id-t, egy permalink_url-t, teljesítési elvárásokat, olyan eseményeket, mint a delivered egy követési számmal, és korrekciókat a visszatérítésekhez. Más szavakkal: a rendelés élő adathalmaz, nem megerősítő e-mail, és pontosan ez kell annak az ügynöknek, amikor a vevő három hét múlva rákérdez a kiszállításra.

A Google Under the hood of the Universal Commerce Protocol cikke 2026 januárjában több mint 20 támogató céget említett, köztük a Shopifyt, a Walmartot, a Targetet, a Stripe-ot, a Visát és a MasterCardot, a kiskereskedelemtől az utazáson át a gastronómiáig. A támogatói lista az a jel, amire figyelni kell: egy protokoll csak akkor számít, ha benne van a fizetési hálózatok és a platformok, mert ezek azok a részek, amelyeket egy kereskedő nem tud lecserélni.

Mit ad hozzá az AP2: bizonyítani, hogy az ember igent mondott

Az AP2 egyetlen nehéz kérdés miatt létezik: ha egy autonóm ügynök fizet, hogyan bizonyítja bárki, hogy a felhasználó pontosan ezt a vásárlást engedélyezte? A dokumentáció három rést nevez meg, amelyet a mai fizetési rendszerek nem tudnak lezárni, és ez a helyes három: engedélyezés (a felhasználó megengedte-e ennek az ügynöknek, hogy ezt a vásárlást megkötse), hitelesség (valódi szándékot tükröz-e a kérés, nem ügynökhibát vagy hallucinációt) és felelősség (ki válaszol, ha téves volt).

A mechanizmus egy mandátum, amely verifikálható digitális credentialként kerül továbbításra: egy módosításra érzékeny, kriptográfiával aláírt objektum. Két mandátum van, mindkettőnek egy nyitott és egy zárt szakasza. A checkout mandátum nyitott szakasza rögzíti a felhasználó feltételeit és céljait, mielőtt a kosár végleges, a zárt szakasz pedig egy konkrét, lezárt checkoutra ad engedélyt. A payment mandátum nyitott szakasza a fizetés feltételeit rögzíti, például egy keretet és az engedélyezett fizetési eszközöket, a zárt szakasz pedig egy konkrét összeget engedélyez, amely az adott checkouthoz kötött.

A dokumentációból két részlet fontos a megvalósításhoz. Az AP2 nem zárt hurok, hanem az A2A és az MCP nyílt, nem proprietáris kiterjesztése, a szabványosítás pedig a FIDO Alliance munkacsoportjaiban folytatódik: a specifikáció a 0.2-es verziónál tart, és az első verzió a „pull” fizetési módokat fedi le, például a hitel- és debitkártyát, a push fizetések és a walletek még a roadmapon vannak. Ha a vállalatod B2B, és számlával számolsz kártya helyett, akkor az AP2 számodra főként az UCP-n keresztül fontos, nem közvetlenül.

Hová illik az ACP: rendelések az asszisztensből

Az ACP a három közül a legszűkebb és a legkonkrétabb. A Stripe és az OpenAI 2025. szeptember 29-én jelentette be „egy új, kereskedőbarát, nyílt szabványként, amelyet a Stripe és az OpenAI közösen fejlesztett”, az Instant Checkouttel együtt a ChatGPT-ben, ahol az amerikai vásárlók az Etsy kereskedőinél, majd hamarosan egy nagy Shopify kereskedőcsoporttól tudtak vásárolni.

Érdemes megérteni a mechanizmust, mert a hitelesítő adatok problémáját egy credential-protokoll nélkül oldja meg. Miután a vevő a chatben fizetett, a Stripe kiállít egy Shared Payment Token-t, amely egy konkrét kereskedőre és egy kosárértékre korlátozott, így az asszisztens fizetést tud kezdeményezni anélkül, hogy a vevő fizetési adatai egyáltalán látszódnának. A token a API-n át jut el a kereskedőhöz, aki a Stripe-on vagy más szolgáltatón keresztül dolgozza fel, továbbra is a Stripe kockázati pontszámaival. A rendelések maguk ACP-n át folynak az asszisztensből a kereskedő backendjébe, ahol a kereskedő pontosan úgy annimmt vagy elutasítja őket, számolja be, kezeli az adót és teljesít, mint mindig.

Két fenntartás. Az ACP az asszisztensek és platformok története, nem általános ügynökstandard, és a 2026. márciusi beszámolók szerint az Instant Checkout az alkalmazások felé mozdul, ami fókuszváltás, nem megszüntetés. Ugyanazígy fontos: a Stripe agent toolkitet és Stripe MCP szervert szállít, szóval az „agentikus kereskedelem” nagy része a gyakorlatban egy fizetési API-val beszélő MCP kliens, nem protokollbevezetés.

A három protokoll összehasonlítva

A három átfed egymással, és egyik sem váltja fel a másikat. Az UCP az életciklus, az AP2 a fizetés igazolása, az ACP az asszisztenshez kötött rendelési út, a WebMCP pedig a helyi alternatíva, ahol az ügynök a böngészőben marad.

A negyedik lehetőség nem protokoll, és gyakran a legolcsóbb. Ha az ügynök a saját oldaladon fut, nem kell semmi ebből: deklaráld az eszközöket a böngészőnek, és hagyd, hogy az ügynök közvetlenül hívja a katalógusodat, a készletedet és a kosarat, ahogy ezen az oldalon a WebMCP implementáció teszi. Ez már ma működik egy origin trial böngészőben, nem igényel partnerintegrációt, és a vevőt a checkoutodon tartja.

Mit tegyen most egy közepes méretű EU-webshop

Egy évtized B2B kereskedelem és PIM platformok után a tanácsom egy ilyen helyzetben lévő shopnak szándékosan unalmas. Előbb tedd a katalógust géppel olvashatóvá és helyessé, mielőtt bárhová csatlakoznál: egy termékfeed variánsokkal, SKU-kkal, adóosztályokkal, készletállapottal és egységárakkal, mert mindegyik protokoll ugyanazzal a feltételezéssel indul, hogy kérdésekre tudsz válaszolni egy termékről. Ez ugyanaz a fegyelem, mint a Markdownot kiszolgálni az ügynököknek HTML-töredelés helyett, csak adatokra alkalmazva, nem oldalakra. Utána implementáld az UCP-ben leírt katalógust, kosarat és rendelést, ha a vevőid fogyasztók, mert ez a legszélesebb specifikáció, és ezt fogja leginkább megkövetelni az a platform, amellyel nem tudsz tárgyalni.

Ne írd újra a checkoutot. Mindegyik ilyen design kifejezetten a kereskedő saját rendszerét tartja merchant of recordnek, a checkout újraírása pedig több negatív negyedre tartó kockázat igazolt haszon nélkül. B2B-ben a nagyobb hatású lépés egy MCP szerver a saját domain API-jaid fölött, az elérhetőségre, a szállítási határidőre és a rendelésállapotra vonatkozó eszközökkel, hogy a vevőid belső ügynökei közvetlenül dolgozhassanak veled. Ez kisebb projekt, mint egy protokollzertifizálás, azonnal értéket termel, és akkor is megtérül, bármit változtatnak is a protokollok a következő körben, amíg az eszközök kevések és jól le vannak írva.

Az őszinte mérleg: mindhárom specifikáció fiatal, és még változhat, az AP2 még nem fontos, ha nem fogadsz kártyás fizetést autonóm vásárlásokra, aki pedig túl korán kezd, integrációs munkával fizet garantált forgalom nélkül. Várj azokra a részekre, amelyeket a legnagyobb platformpartnerséged követel, és az időt arra fejezd, amire minden protokollnak szüksége van: a jó adatminőségre.

Agentikus kereskedelmi ellenőrzőlista

1. Tedd lekérdezhetővé a katalógust: variánsok, SKU-k, minor unitben megadott árak, adóosztály, készletállapot, alt szöveggel ellátott képek.
2. Tedd közzé a géppel olvasható szabályzatokat, a visszatérítést és a szállítást is, hogy egy ügynök kimondhassa a feltételeidet, ne pedig tippeljen.
3. Tartsd az attribúciót a kosár payloadjában, különben elveszíted az elismerést azokért az eladásokért, amelyekre odaküldtek.
4. Maradj merchant of record, és tartsd az árat, az adót, a teljesítést és a visszatérítést a saját rendszeredben.
5. Agent-hozzáféréshez korlátozott OAuthot használj, soha megosztott fiókot vagy hosszú életű tokent.
6. Sosem nézhessen meg egy ügynök nyers kártyaadatot; ha csatlakozol az ACP-hez, pontosan erre való a Shared Payment Token.
7. Vegyél fel WebMCP eszközöket a saját oldaladra olvasási műveletekhez, hogy az oldalon belüli ügynököknek ne kelljen oldaltöredelni.
8. Számolj azzal, hogy a specifikáció mozog. Verziózd az integrációdat, és tartsd vékonyan az adaptert.

Ha ilyen integrációt építesz, a B2B e-kereskedelmi fejlesztői oldal arról szól, hogyan strukturálom a munkát, a B2B e-kereskedelem oldal pedig a PIM- és katalogusoldalt, amelyre mindegyik protokoll támaszkodik.

Források

1. Universal Commerce Protocol: capabilities, core concepts and specification
2. Google Developers Blog: Under the hood of the Universal Commerce Protocol (2026. január)
3. AP2: Agent Payments Protocol documentation, mandates and verifiable credentials
4. Stripe and OpenAI: Instant Checkout and the Agentic Commerce Protocol (2025. szeptember 29.)
5. Digital Commerce 360: OpenAI shifts its checkout plans for agentic commerce (2026. március 6.)