ACP, UCP és AP2 összehasonlítva: az agentic commerce protokolljai 2026 októberében, és melyikre van szüksége az Ön webáruházának

Ma három nyílt protokoll írja le, hogyan vásárol egy MI-ügynök egy webáruháztól. Az Agentic Commerce Protocol (ACP) az OpenAI-tól és a Stripe-tól származik. A Universal Commerce Protocol (UCP) a Google-től és a Shopifytól. Az Agent Payments Protocol (AP2), amelyet a Google indított el, és áprilisban a FIDO Alliance-nek adományozott, egyáltalán nem pénztárprotokoll: aláírt bizonyítékot határoz meg arra, hogy a felhasználó engedélyezett egy fizetést, és úgy tervezték, hogy az UCP-n belül működjön. Mindhárom Apache 2.0 licencű.

A három protokoll 2026. október 22-én nagyon különböző állapotban van. Az ACP béta jelölésű, legutóbbi kiadása a 2026-04-17, és július 17. óta nem került bele új commit. Fő felhasználója, a ChatGPT márciusban eltávolodott az önálló pénztártól, és ma az ACP-t főleg termékadatok fogadására használja. Az UCP augusztusban kiadott egy visszafelé nem kompatibilis verziót (2026-08-25), miközben a Google saját felületei még a 2026-04-08 verziót futtatják, pénztára pedig korai hozzáférésű, és csak az Egyesült Államokban érhető el. Az AP2 a v0.2-nél tart, és egyetlen Google-termék dokumentációja sem írja, hogy használná.

Ez a cikk webáruházak és kereskedelmi platformok technológiai vezetőinek (CTO-knak) és vezető fejlesztőinek szól, akik arról döntenek, mit valósítsanak meg. Ha arra kíváncsi, mit várnak el az egyes MI-platformok üzleti szempontból egy webáruháztól, kezdje az „agentic commerce” (ügynökalapú kereskedelem) helyzetéről szóló áttekintésünkkel.

Egymás mellett

ACP: az Agentic Commerce Protocol

Irányítás és verziók

A specifikáció tárolója (repository) szerint az ACP-t az OpenAI és a Stripe tartja karban, és béta jelöléssel látja el. Irányítási dokumentuma a kettőt alapító karbantartóvá (Founding Maintainers) teszi: ők nevezik ki az irányítóbizottság tagjait (legfeljebb hetet), és vétójogot tartanak fenn, amelyet „végső esetben” használhatnak. A Meta 2026. április 24-én csatlakozott harmadik vezető karbantartóként és bizottsági tagként. A Stripe dokumentációja szerint az ACP-t „a Stripe, az OpenAI és a Meta hozta létre”, a tároló notice fájlja azonban csak az OpenAI-t és a Stripe-ot nevezi meg. Egy semleges alapítvány egyelőre csak kinyilvánított jövőbeli irány.

Öt dátummal jelölt kiadás létezik: 2025-09-29 (pénztár és delegált fizetés), 2025-12-12 (az URBN- és az Etsy-adapterek tapasztalataiból levont, visszafelé nem kompatibilis változtatások), 2026-01-16 (a kereskedő által választott 3DS-szolgáltató), 2026-01-30 (képességegyeztetés, bővítmények és egy visszafelé nem kompatibilis fizetéskezelő-keretrendszer) és 2026-04-17 (kosár, feed, rendelések, delegált hitelesítés, felfedezés és MCP), amely elavulttá tette a 2026-01-30 verziót. Az azóta eltelt hat hónapban nem jelent meg új kiadás. Az unreleased/ mappa július 17-ig datált kisebb változtatásokat tartalmaz, például egy feedfrissítési azonosítót és egy opcionális termék-URL-t a pénztári tételeken.

Mit valósít meg a kereskedő a 2026-04-17 verzióban

A pénztár API-ját a kereskedő üzemelteti, és az ügynök hívja:

• A POST /checkout_sessions létrehoz egy munkamenetet, a POST /checkout_sessions/{checkout_session_id} frissíti (POST, nem PUT), ugyanezen az útvonalon a GET lekéri, a .../complete és a .../cancel pedig lezárja.
• A kérések bearer API-kulcsot és egy kötelező API-Version headert tartalmaznak. A 2026-04-17 verzió óta minden POST kérésnél kötelező az Idempotency-Key, meghatározott hibákkal: 400 idempotency_key_required, 409 idempotency_in_flight és 422 idempotency_conflict.
• A létrehozó kérés egy capabilities objektumot tartalmaz. Az ügynök deklarálja, mit támogat, az eladó pedig a kettő metszetét adja vissza, így egy inkompatibilitás még a fizetés előtt kiderül.
• A kereskedő a rendelési eseményeket POST kéréssel küldi egy, az OpenAI által üzemeltetett fogadóra a /agentic_checkout/webhooks/order_events címen, HMAC-SHA256-tal aláírva, egy Merchant-Signature headerben. Az állapotok a created állapottól a delivered vagy a canceled állapotig tartanak, az adjustments[] pedig a visszatérítéseket, a visszaküldéseket, a vitatásokat és a visszaterheléseket (chargeback) hordozza.

A 2026-04-17 kiadás egy statikus, nyilvános /.well-known/acp.json fájlt is bevezetett, amelynek transports mezője megadja, hogy a webáruház a rest, az mcp vagy mindkét átviteli módot támogatja. Bevezetett egy Streamable HTTP feletti MCP-kötést is öt eszközzel (create_checkout_session, get_checkout_session, update_checkout_session, complete_checkout_session, cancel_checkout_session), amelyeknél a hitelesítés a szerverkonfigurációban történik, nem kérésenként. Végül bevezetett egy Feed API-t, amelyet az ügynök üzemeltet, és amelyre a kereskedő küldi az adatokat (POST /feeds, PATCH /feeds/{id}/products), egy egyetlen eladós, fizetési adatok nélküli kosarat (POST /carts, PUT /carts/{id}), valamint delegált 3DS2-hitelesítést (POST /delegate_authentication). Előfizetések nincsenek: a bővítményekről szóló RFC a subscription elemet így írja le: „Ismétlődő számlázás támogatása (jövőbeli)”.

Hogyan működik a fizetés az ACP-ben

Az ACP eredeti válasza a delegált fizetés. A PSP vagy a kártyatároló (card vault) valósítja meg a POST /agentic_commerce/delegate_payment hívást, amely egy kártyát (ez az egyetlen hitelesítőadat-típus) olyan tokenné alakít, amelyet a kereskedő PSP-je csak egy kereten belül használhat fel: reason (csak one_time), max_amount, currency, checkout_session_id, merchant_id és expires_at. Az RFC megfogalmazásában: „A fizetések, a kiegyenlítés és a megfelelés a kereskedő saját fizetési infrastruktúráján maradnak.” A Worldpay dokumentálja a hívás saját változatát, a PayPal pedig a Braintree delegált tokenjeivel támogatja az ACP-t.

A 2026-01-30 verzió óta az elfogadott fizetési módokat fizetéskezelőként kell deklarálni a capabilities.payment.handlers alatt. A változásnapló (changelog) példájában a fizetési adat így néz ki:

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

Az spt a Stripe Shared Payment Token nevű megoldása, amely „az Egyesült Államokban, Kanadában és egyes európai országokban” érhető el. A Stripe-ot használó eladó egy előzetes (preview) API-verzión a payment_method_data[shared_payment_granted_token] paraméterrel terheli meg; a más feldolgozót használó eladó egyszer feloldhatja hálózati hitelesítő adatokká. Hogy ki viseli a kockázatot, azt az ügynöki fizetésekről szóló cikkünk tárgyalja.

Mit változtatott az OpenAI márciusi lépése

Az OpenAI 2026. március 24-én azt írta, hogy „az Instant Checkout első változata nem nyújtotta azt a rugalmasságot, amelyet szeretnénk biztosítani”, lehetővé tette a kereskedőknek, hogy saját pénztárukat használják, és közölte, hogy „az ACP-t kiterjesztjük, hogy a felfedezés teljes folyamatában összekötő réteg legyen a kereskedők és a felhasználók között.” A Target, a Sephora, a Nordstrom, a Lowe's, a Best Buy, a The Home Depot és a Wayfair a felfedezéshez integrálta az ACP-t, a Shopify-katalógusok pedig a Shopify Catalogon keresztül érkeznek. Mit jelent ez egy fejlesztő számára:

• Az éles rész a feed. Az OpenAI kereskedői oldala szerint a vásárlások „a kereskedő saját weboldalán vagy alkalmazásában zárulnak le”, és a vásárlás az amerikai felhasználók számára élesben működik. A feedes csatlakozás jóváhagyott partnereknek szól, várólistáról: naponta egy teljes fájl SFTP-n, kilenc kötelező mezővel, napközbeni frissítések API-n, promóciók csak API-n. A szabványos feltöltés „jelenleg az Egyesült Államokat célozza”.
• A pénztár külön kapu. A feedspecifikáció szerint a pénztárhoz „külön engedélyezett integráció szükséges”. A ChatGPT-alkalmazások esetében az általánosan elérhető út a külső pénztár a fejlesztő saját domainjén. A csevegésen belüli fizetési panel (payment sheet) zárt bétaváltozat, amely „kiválasztott piacterekre korlátozódik”, és egy complete_checkout eszközhívásban adja át a fizetési tokent az alkalmazás MCP-szerverének.
• Az OpenAI oldalai le vannak maradva a specifikációhoz képest. Pénztár-referenciája még mindig a 2025-09-12 API-Version értéket és egy stripe, adyen és braintree értékekből álló provider enumot mutat. A tárolóhoz igazodva fejlesszen, és erősítse meg az OpenAI-jal, melyik verziót fogadja el.

Azok a PSP-oldalak, amelyek az Instant Checkoutot még élő szolgáltatásként mutatják be, elavultak.

UCP: a Universal Commerce Protocol

Irányítás és verziók

A Google 2026. január 11-én indította el az UCP-t, amelyet a Shopifyjal, az Etsyvel, a Wayfairrel, a Targettel és a Walmarttal közösen fejlesztett. Az irányítási szabályok a Google-nek és a Shopifynak egy-egy állandó szavazatot adnak a Governing Councilban, amelyhez a Stripe 2026. április 28-án csatlakozott, és kimondják: „A Google 2028 decemberéig meghatalmazotti szavazattal rendelkezik az összes betöltetlen hely nevében”. Április 24-én a Shopping Tech Council 16 helyesre bővült az Amazonnal, a Metával, a Microsofttal, a Salesforce-szal és a Stripe-pal, így a Meta és a Stripe ma már az ACP bizottságában és az UCP tanácsában is ül.

A tároló négy kiadást tartalmaz. A 2026-04-08 kosár- és katalógusképességeket, kérés- és válaszaláírást, valamint Get Order műveletet adott hozzá. A 2026-08-25 visszafelé nem kompatibilis: a signing_keys[] helyét egy JWK Set vette át a keys[] mezőben, a fizetési bővítmények a dev.ucp.shopping.* alól a dev.ucp.common.payment.* alá kerültek, a közös sémák máshová kerültek, és megváltozott az $id URL-jük, a PAN és a hálózati tokenek pedig külön hitelesítőadat-típusok lettek. Bevezette továbbá a szolgáltatófüggetlen 3DS2-t, a megosztott fizetéseket (split payments), a fizetési feltételeket és a Web Bot Auth szabvánnyal való együttműködést.

Itt rejlik a csapda. A Google profilútmutatója csak a 2026-04-08 és a 2026-01-23 verziót tárgyalja, a Google saját ügynökprofilja az ucp.goog címen "version": "2026-04-08" értéket deklarál, és a Salesforce B2C Commerce 26.9 ugyanezt a két verziót szolgálja ki. A Shopify Checkout MCP-je ugyanakkor a 2026-08-25 verzióra hivatkozik. Ha a legújabb kiadáshoz igazodva fejleszt, olyan verziót épít, amelyet a Google nem dokumentál. A specifikáció válasza egy supported_versions objektum, amely minden régebbi verziót a saját profil-URI-jához rendel.

Felfedezés, átviteli módok és hitelesítés

Minden vállalkozás profilt tesz közzé a /.well-known/ucp címen az ucp.version, az ucp.services és az ucp.payment_handlers mezőkkel, és a Google megköveteli, hogy ez nyilvános és hitelesítés nélkül elérhető legyen. Az ügynök platformja is közzétesz egyet, és minden kérés egy UCP-Agent headerben hordozza ennek URI-ját, HTTPS-en, legalább TLS 1.3-mal. A hitelesítést a vállalkozás választja meg: nincs hitelesítés, X-API-Key, OAuth 2.0, kölcsönös TLS vagy RFC 9421 szerinti HTTP Message Signatures. A Google bearer tokent küld, GYIK-ja pedig az mTLS-t is felkínálja. Az Idempotency-Key csak „SHOULD” (ajánlott) szintű; az a szerver, amely elfogad egyet, legalább 24 órán át megőrzi, és 409-cel válaszol, ha eltérő törzzsel használják újra.

A REST az alapvető átviteli mód, mellette az MCP, egy A2A-bővítmény és egy continue_url révén elérhető beágyazott mód. A rendelések egy GET /orders/{id} hívásból és egy RFC 9421 szerint aláírt, a vállalkozástól a platform felé irányuló webhookból állnak. A kosár útvonalai ugyanazok, mint az ACP-ben. A pénztári műveletek hasonlítanak egymásra, de nem cserélhetők fel:

Egy pénztári mag mindkettőt kiszolgálhatja. Egy útvonaltábla nem.

Hogyan működik a fizetés az UCP-ben

Az UCP nem mozgat pénzt. A fizetéskezelő egy hitelesítőadat-szolgáltató által írt specifikáció, például a com.google.pay a Google Pay-hez vagy a dev.shopify.shop_pay a Shop Pay-hez. A vállalkozás felsorolja az általa elfogadott fizetéskezelőket, a platform futtat egyet, és a complete hívásnál a vállalkozás egy átlátszatlan (opaque) tokent kap, amelyet saját PSP-jén keresztül terhel meg.

A Google felületein az egyetlen fizetéskezelő a Google Pay, az egyetlen használt hitelesítési mód a PAN_ONLY, és az Ön PSP-jének „képesnek kell lennie a tokenjeink feldolgozására”. A Stripe kártyákhoz és Apple Pay-hez közzétette a com.stripe.payments fizetéskezelőt: „Az ügynök a Complete Checkout kérésben megosztott fizetési tokent (SPT) küld, és az eladó megterheli azt.” A Google Pay a saját fizetéskezelőjén marad. A PayPal a Braintree-n vagy az Orders v2 API-ján keresztül fogadja a Google Pay fizetéskezelőt.

Mit követel meg a Google, mielőtt hívja Önt

A Google natív pénztárra vonatkozó útmutatója a REST pénztár-API-t kéri, és a fizetési lépést magánál tartja: a vásárló az érzékeny adatokat „csak a Google felhasználói felületén” adja meg. Szolgáltatási szintjei: végpontonként legalább 95%-os rendelkezésre állás, p50 és p95 késleltetésként 1 és 4 másodperc a létrehozásnál, 1 és 5 a frissítésnél, 6 és 10 a lezárásnál. Rendelés után Ön küldi el az állapotfrissítéseket egy Google-webhookra, a csatlakozáskor kiadott partnerazonosítóval és kulccsal. A Merchant Centerben minden terméknél true értékre kell állítani a native_commerce(checkout_eligibility) attribútumot (ez „alapértelmezés szerint FALSE”), a visszaküldési szabályzat és az ügyfélszolgálati elérhetőség kötelező, az előfizetések, a részletfizetés, a személyre szabott, a használt és a felújított termékek, az előrendelések és a korhatáros termékek pedig ki vannak zárva.

Ennél könnyebb lehetőség a 2026-04-08 verzió óta a kosárátadás (cart transfer): csak a kosár létrehozását valósítja meg, a Google átadja a kosarat az Ön oldalának, és nincs szükség sem fizetéskezelőre, sem rendelési webhookra.

A valódi korlát a hozzáférés. A pénztár „kiválasztott kereskedők számára érhető el” egy korai hozzáférési érdeklődési űrlapon keresztül, amelyen vállalja, hogy 30 napon belül elkezdi a munkát, és elfogadja, hogy a hozzáférést „megszüntethetik”, ha nem halad előre. Az UCP Checkout feltételei „csak az Egyesült Államokra” vonatkoznak. A Merchant Center hub Ausztráliában és Kanadában „jövő év elején” következik; más országra a Google nem ad pénztárdátumot.

Az UCP a Google-ön kívül

A Microsoft Merchant Center 2026. április 21. óta fogadja az UCP-kompatibilis feedeket az Egyesült Államokban. A Copilot Checkouthoz UCP-nek megfelelő feed kell, angol nyelvű, amerikai vevőknek dollárban értékesítő kereskedőket fogad, egyenként egy PSP-vel, webáruház-beállítása pedig a „csak pilot, kiválasztott ügyfeleknek” jelölést viseli. A Shopify az MCP-n keresztül teszi elérhetővé az UCP-t a https://{shop}/api/ucp/mcp címen, és eltávolította régebbi katalógus- és kosáreszközeit. Egy szállásfoglalási képességet 2026. szeptember 24-én piszkozatként (draft) olvasztottak be, és egyetlen kiadásban sem szerepel.

AP2: az Agent Payments Protocol

Az AP2 nem egy harmadik pénztármegoldás. Specifikációja szerint „biztonsági funkcióként működik egy kereskedelmi protokollon (Commerce Protocol) belül”, és „kifejezetten úgy tervezték, hogy kompatibilis legyen a Universal Commerce Protocollal (UCP)”. A 0.1.0-s verzió 2025. szeptember 16-án jelent meg, a v0.2 pedig 2026. április 28-án, azon a napon, amikor a Google a FIDO Alliance-nek adományozta az AP2-t. A FIDO bejelentése megnevez egy Agentic Authentication munkacsoportot és egy Payments munkacsoportot, amelyeket a Mastercard és a Visa képviselői vezetnek, és azt írja, hogy a hozzájárulásokat „felülvizsgálják és továbbfejlesztik”. A FIDO nem tett közzé AP2-specifikációt. A GitHub-tároló ma már csak mintákat és SDK-módosításokat fogad, utolsó commitja április 29-i.

A 0.2-es verzió két elemet határoz meg: a Checkout Mandate azt rögzíti, mit vásárolnak, a Payment Mandate pedig a fizetést, olyan korlátokkal, mint a payment.amount_range, a payment.budget és a payment.allowed_payees. Mindkettő SD-JWT, zárt és nyitott formában (például mandate.payment.1 és mandate.payment.open.1). Human Present (jelen lévő felhasználó) módban a felhasználó a zárt mandátumokat hagyja jóvá. Human Not Present (távol lévő felhasználó) módban a felhasználó korlátokat rögzítő nyitott mandátumokat hagy jóvá, amelyek egy cnf claimben hordozzák az ügynök nyilvános kulcsát, az ügynök pedig ezeken a korlátokon belül állítja össze a zárt mandátumokat. Az Intent és Cart Mandate-ekről szóló oktatóanyagok a v0.1-et írják le; ezek a fogalmak a v0.2-ből eltűntek.

Az UCP-n belül az AP2 a dev.ucp.common.payment.ap2_mandate bővítmény (a 2026-08-25 előtt dev.ucp.shopping.ap2_mandate). Amint egyeztették, a vállalkozás aláírja a pénztári válaszait, a platform a complete hívásnál bemutat egy checkout_mandate és egy payment_mandate elemet, a munkamenet pedig „Security Locked” (biztonsági zárolt) állapotba kerül: egyik fél sem térhet vissza szokásos pénztárhoz.

Még senki nem kéri. A Google GYIK-ja szerint az AP2 „különösen hasznos az autonóm MI-ügynöki tranzakciókat érintő jövőbeli forgatókönyvekben”. A Google saját ügynökprofilja egyetlen fizetéskezelőként a Google Pay-t sorolja fel, és nem deklarál AP2-képességet, 2026-08-25 profiljában pedig szintén nincs AP2-bejegyzés. Egyetlen Google-termék dokumentációja sem írja, hogy AP2-t használna, így egy kereskedőnek nincs mit megépítenie, amíg egy platform nem egyezteti.

A szomszédos protokollok

MCP

Az ACP és az UCP egyaránt futhat MCP felett, amelynek jelenlegi specifikációja, a 2026-07-28, megszünteti a munkameneteket és az Mcp-Session-Id headert, elhagyja az initialize kézfogást, előírja a server/discover használatát, és megköveteli, hogy a kliens új azonosítóval küldje el újra a kérést, ha megszakad a streamje. Az ACP kötése még a 2025-11-25 átvitelre hivatkozik. A pénztári munkamenet azonosítója pontosan az a szerver által kiadott leíró (handle), amelyet az új specifikáció elvár, egy stream közben elveszett complete pedig új kérésként érkezik vissza: kezelje az idempotenciakulcsokat mindkét protokollon kötelezőként.

WebMCP

A WebMCP egy javasolt webes szabvány, amellyel egy oldal saját funkcióit lehet elérhetővé tenni a böngészőben futó ügynökök számára. A Shopify az UCP-pénztárat Checkout MCP-ként és Checkout WebMCP-ként is kínálja, ugyanazzal a pénztárobjektummal, és a Checkout MCP-t ajánlja. Állapotát WebMCP-útmutatónk tárgyalja.

x402 és MPP

Az x402 és a Machine Payments Protocol, amelyet a Tempo és a Stripe tervezett, HTTP-kérésenként számol fel díjat egy ügynöknek egy API-ért, adatokért vagy tartalomért. Ezek nem webáruházi pénztárprotokollok. Lásd az x402-ről szóló cikkünket.

Visa Trusted Agent Protocol és Mastercard Agent Pay

Ezek az ACP és az UCP mellett működnek, nem helyettük. A Visa Trusted Agent Protocolja „szabványosított, kriptográfiai módszert” ad egy ügynöknek arra, hogy igazolja identitását és felhatalmazását a kereskedők felé, a Mastercard Agent Pay pedig tokenizációs program az agentic commerce számára. A Mastercard kereskedői útmutatója az UCP-t és az ACP-t a legmagasabb felkészültségi szintjére sorolja, megjegyzi, hogy „a korai alkalmazók jelenleg integrálnak”, és azt tanácsolja a kereskedőknek, hogy a két egyszerűbb szintjével kezdjenek. Mindkét programot az ügynöki fizetésekről szóló cikkünk tárgyalja.

Personal Agent Protocol

A Sierra azt írja, hogy 2026. október 6-án a Metával közösen jelentette be a Personal Agent Protocolt („Poppy”), és október 9-én közzétett egy tervezetet. Egy vállalat egyetlen fájlt tesz közzé a /.well-known/poppy.json címen; a protokoll OAuth, JWT-k, HTTPS, OpenAPI és MCP segítségével teszi lehetővé, hogy egy személyes ügynök azonosítsa magát, és bármilyen feladathoz megszerezze az ügyfél engedélyét, a Sierra pedig az UCP kiegészítőjének nevezi. A protokoll oldala a 0.2-es verziót mutatja, és azt írja: „Ez egy tervezet”. A Meta saját sajtóoldalán nem találtunk róla bejegyzést.

Melyikre van szüksége?

Shopifyon

Nincs mit megépítenie. A Shopify ügynököknek szóló kirakatai (agentic storefronts) „a jogosult webáruházak számára alapértelmezés szerint aktívak”. A ChatGPT a Shopify Catalogon keresztül kapja meg az Ön katalógusát, és a vásárlókat az Ön webáruházába küldi. A Google közvetlen pénztára alapértelmezés szerint be van kapcsolva az Egyesült Államokban működő és oda értékesítő webáruházaknál, a Shopify-kereskedők pedig automatikusan bekerültek a Copilotba. Önnek a termékadatokról kell döntenie, és arról, hogy bekapcsolva hagyja-e a közvetlen pénztárat, tudva, hogy az egyéni pixelek (custom pixels) a Google pénztárában nem aktiválódnak.

Salesforce, commercetools vagy más platform esetén

A Salesforce B2C Commerce 26.9 UCP-t szolgál ki, a 2026-01-23 és a 2026-04-08 verziót: a /.well-known/ucp profilt egy supported_versions leképezéssel, a pénztári munkamenetek végpontjait pedig egy SLAS token mögött. A Salesforce a Google-ön futó UCP-pénztárat 2026 októberében általánosan elérhetőként tünteti fel. Egy munkamenet a kosár headless nézete, és a Salesforce auditútmutatója arra figyelmeztet, hogy az SFRA- és SiteGenesis-kontrollerek, valamint „a ma használt egyéb SCAPI-erőforrások nem futnak ebben a folyamatban”, így a hozzájuk kapcsolt logikát át kell másolni az UCP pénztári munkamenet-hookjaira, vagy át kell hidalni azokhoz. A feednek az en-US területet kell céloznia, és a Salesforce „nem kerüli meg a Google várólistáját”. A ChatGPT esetében a Salesforce az egyik olyan csatorna, amelyet az OpenAI az ACP-feedek eljuttatására megnevez.

A commercetools vagy más platform esetén kérdezze meg a szállítót, mely UCP-verziókat és -képességeket szolgál ki, az Ön mely hookjai futnak le egy ügynöki pénztárban, és küld-e feedeket az OpenAI-nak.

Saját szoftveren

1. Először a feedek. A Google Merchant Center, és ha az OpenAI felveszi Önt, az ő termékfeedje. Az ACP kereskedelmi felhasználása a ChatGPT-ben ma pontosan ez.
2. UCP a Google-höz, ha az Egyesült Államokban értékesít, és a Google felveszi Önt. A 2026-04-08 verzióhoz igazodva fejlesszen: profil a com.google.pay fizetéskezelővel, pénztári műveletek a Google késleltetési céljain belül, a Google Pay-tokeneket feldolgozni képes PSP, a rendelési webhook és a feedattribútum. Vagy kezdje csak a kosárátadással.
3. ACP-pénztárat csak akkor, ha oka van rá, például ha egy ChatGPT-alkalmazását felvették a fizetési panel bétaváltozatába. A tároló 2026-04-17 verziójához igazodva fejlesszen.
4. AP2: egyelőre semmi.
5. Egyetlen pénztári mag. Mindkét protokoll olyan munkamenetet vár, amely API-n keresztül létrehozható, frissíthető, lezárható és visszavonható, és biztonságosan újrapróbálható. Építse meg egyszer a rendelési, adó- és fizetési logikája fölé, vékony ACP- és UCP-adapterekkel a tetején, és MCP-vel ott, ahol az ügynököknek szükségük van rá.

Ma egyik protokoll sem kínál natív ügynöki pénztárat egy előfizetéses vállalkozásnak.

Ha csak az Egyesült Államokon kívül értékesít

A három közül ma egyik sem ad Önnek ügynöki pénztárat. A ChatGPT-s vásárlás és az OpenAI szabványos feedfeltöltése amerikai; a Google UCP Checkout feltételei csak az Egyesült Államokra vonatkoznak; a Copilot Checkout amerikai vevőket szolgál ki dollárban. A Google következő bejelentett lépése a Merchant Center hub Ausztráliában és Kanadában „jövő év elején”, az Egyesült Királyságra és az EU-ra nincs dátum.

Gondoskodjon róla, hogy a Merchant Center-feedje teljes legyen, és ha amúgy is újraépíti a pénztárát, építse meg a fent leírt, API-vezérelt magot, hogy egy adapter kis munka legyen, amikor az Ön piaca megnyílik. Külföldről értékesít az Egyesült Államokba? Ellenőrizze, hol kell a kereskedő székhelyének lennie az egyes programokban; a Shopify Google-féle közvetlen pénztárához például amerikai webáruház kell.

Hol kaphat segítséget

Megépítjük a protokollréteget azoknak a webáruházaknak, amelyek nem Shopifyon futnak: /.well-known/ucp profilt és a pénztári munkamenetek végpontjait a meglévő rendelési, adó- és fizetési logikájára építve, rendelési webhookokat a Google felé, termékfeedeket a Google Merchant Centerhez és az OpenAI-hoz, valamint MCP-szervereket, amelyek ugyanazt a pénztárat teszik elérhetővé az ügynökök számára. MI-ügynök-fejlesztési és MCP-integrációs szolgáltatásunk az, ahol ez a munka elkezdődik.

Írjon az office@c9group.dev címre, adja meg a platformját, a fizetési szolgáltatóját és azokat az országokat, ahol értékesít, és megmondjuk, melyik protokoll vonatkozik Önre, és mivel járna a megvalósítása. A Google és az OpenAI programfeltételei szerződések: mérnökök vagyunk, nem jogászok, ezért aláírás előtt olvastassa el őket egy tanácsadóval.