ACP, UCP un AP2 salīdzinājums: aģentiskās tirdzniecības protokoli 2026. gada oktobrī un kurš no tiem vajadzīgs jūsu veikalam

Trīs atvērti protokoli tagad apraksta, kā MI aģents veic pirkumu veikalā. Agentic Commerce Protocol (ACP) nāk no OpenAI un Stripe. Universal Commerce Protocol (UCP) nāk no Google un Shopify. Agent Payments Protocol (AP2), ko aizsāka Google un aprīlī nodeva aliansei FIDO Alliance, nemaz nav pirkuma noformēšanas protokols: tas definē parakstītu pierādījumu tam, ka lietotājs ir autorizējis maksājumu, un ir paredzēts darbam UCP iekšienē. Visi trīs ir publicēti ar Apache 2.0 licenci.

To stāvoklis 2026. gada 22. oktobrī ir ļoti atšķirīgs. ACP ir apzīmēts kā beta versija, tā jaunākais laidiens ir 2026-04-17, un kopš 17. jūlija tajā nav veiktas nekādas izmaiņas. ChatGPT, tā galvenais lietotājs, martā atkāpās no patstāvīgas pirkuma noformēšanas un tagad ACP izmanto galvenokārt produktu datu saņemšanai. UCP augustā publicēja versiju ar nesaderīgām izmaiņām, 2026-08-25, bet paša Google pakalpojumi joprojām darbojas ar 2026-04-08, un tā pirkuma noformēšana ir agrīnās piekļuves programmā, tikai ASV. AP2 ir versijā v0.2, un neviena Google produkta dokumentācijā nav teikts, ka tas to izmanto.

Šis raksts ir paredzēts veikalu un e-komercijas platformu tehnoloģiju direktoriem (CTO) un vadošajiem izstrādātājiem, kas lemj, ko ieviest. Par to, ko katra MI platforma prasa no veikala kā uzņēmuma, sāciet ar mūsu aģentiskās tirdzniecības pārskatu.

Salīdzinājums

ACP: Agentic Commerce Protocol

Pārvaldība un versijas

Specifikācijas repozitorijā teikts, ka ACP uztur OpenAI un Stripe, un tas ir apzīmēts kā beta versija. Tā pārvaldības dokuments abus nosaka par dibinātājiem uzturētājiem (Founding Maintainers): tie ieceļ vadības komitejas locekļus (līdz septiņiem) un patur veto tiesības, ko izmantot „kā galējo līdzekli“. Meta 2026. gada 24. aprīlī pievienojās kā trešais vadošais uzturētājs un komitejas loceklis. Stripe dokumentācijā par ACP teikts, ka to „izveidoja Stripe, OpenAI un Meta“, taču repozitorija autortiesību paziņojuma failā minēti tikai OpenAI un Stripe. Neitrāls fonds pagaidām ir tikai deklarēts nākotnes ceļš.

Ir pieci datēti laidieni: 2025-09-29 (pirkuma noformēšana un deleģēts maksājums), 2025-12-12 (nesaderīgas izmaiņas, kas izrietēja no URBN un Etsy adapteru pieredzes), 2026-01-16 (tirgotāja izvēlēts 3DS nodrošinātājs), 2026-01-30 (spēju saskaņošana, paplašinājumi un nesaderīgs maksājumu apstrādātāju ietvars) un 2026-04-17 (iepirkumu grozs, plūsma, pasūtījumi, deleģēta autentifikācija, atrašana un MCP), ar kuru 2026-01-30 tika atzīts par novecojušu. Sešos mēnešos kopš tā laika nekas nav izlaists. Mapē unreleased/ ir mazākas izmaiņas, datētas līdz 17. jūlijam, piemēram, plūsmas atjauninājuma ID un neobligāts produkta URL pirkuma noformēšanas precēm.

Kas tirgotājam jāievieš versijā 2026-04-17

Pirkuma noformēšanas API darbojas tirgotāja pusē, un to izsauc aģents:

• POST /checkout_sessions izveido sesiju, POST /checkout_sessions/{checkout_session_id} to atjaunina (POST, nevis PUT), GET tajā pašā ceļā to nolasa, un .../complete un .../cancel to noslēdz.
• Pieprasījumos ir bearer API atslēga un obligāta galvene API-Version. Kopš 2026-04-17 katram POST pieprasījumam obligāta ir Idempotency-Key ar definētām kļūdām: 400 idempotency_key_required, 409 idempotency_in_flight un 422 idempotency_conflict.
• Izveides pieprasījumā ir objekts capabilities. Aģents norāda, ko tas atbalsta, un pārdevējs atgriež abu pušu spēju šķēlumu, tāpēc nesaderība atklājas pirms maksājuma.
• Tirgotājs ar POST sūta pasūtījumu notikumus uz OpenAI mitinātu saņēmēju adresē /agentic_checkout/webhooks/order_events, parakstot tos ar HMAC-SHA256 galvenē Merchant-Signature. Statusi ir no created līdz delivered vai canceled, un adjustments[] satur atmaksas, preču atgriešanu, maksājumu strīdus un atprasījumus (chargeback).

Laidiens 2026-04-17 pievienoja arī statisku, publisku /.well-known/acp.json, kura lauks transports norāda, vai veikals atbalsta rest, mcp vai abus. Tas pievienoja MCP saistījumu (binding) caur Streamable HTTP ar pieciem rīkiem (create_checkout_session, get_checkout_session, update_checkout_session, complete_checkout_session, cancel_checkout_session), ko autentificē servera konfigurācijā, nevis katrā pieprasījumā. Un tas pievienoja Feed API, ko mitina aģents un uz kuru tirgotājs nosūta datus (POST /feeds, PATCH /feeds/{id}/products), viena pārdevēja iepirkumu grozu bez maksājuma datiem (POST /carts, PUT /carts/{id}) un deleģētu 3DS2 autentifikāciju (POST /delegate_authentication). Abonementu nav: paplašinājumu RFC subscription ir uzskaitīts kā „Atkārtotu rēķinu atbalsts (nākotnē)“.

Kā maksājumi notiek ACP

ACP sākotnējā atbilde ir deleģēts maksājums. PSP (maksājumu pakalpojumu sniedzējs) vai karšu datu glabātuve ievieš POST /agentic_commerce/delegate_payment, kas karti (vienīgo maksāšanas datu veidu) pārvērš tokenā, ko tirgotāja PSP drīkst izmantot tikai noteiktu limitu robežās: reason (tikai one_time), max_amount, currency, checkout_session_id, merchant_id un expires_at. RFC vārdiem: „Maksājumi, norēķini un atbilstība prasībām paliek tirgotāja maksājumu infrastruktūrā“. Worldpay dokumentē savu šī izsaukuma versiju, un PayPal atbalsta ACP ar deleģētiem tokeniem Braintree vidē.

Kopš 2026-01-30 pieņemtās maksāšanas metodes deklarē kā apstrādātājus zem capabilities.payment.handlers. Izmaiņu žurnālā dots šāds maksājuma datu piemērs:

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

spt ir Stripe Shared Payment Token, kas pieejams „ASV, Kanādā un atlasītās Eiropas valstīs“. Stripe pārdevējs to iekasē ar payment_method_data[shared_payment_granted_token], izmantojot API priekšskatījuma versiju; pārdevējs, kas izmanto citu maksājumu procesoru, var vienreiz iegūt no tā tīkla maksāšanas datus. Kas uzņemas risku, aplūkots mūsu rakstā par aģentiskajiem maksājumiem.

Ko mainīja OpenAI marta lēmums

OpenAI 2026. gada 24. martā rakstīja, ka „Instant Checkout sākotnējā versija nepiedāvāja tādu elastību, kādu vēlamies nodrošināt“, ļāva tirgotājiem izmantot savus pirkuma noformēšanas risinājumus un paziņoja, ka „paplašina ACP, lai tas kļūtu par savienojošo slāni starp tirgotājiem un lietotājiem visā produktu atrašanas procesā“. Target, Sephora, Nordstrom, Lowe's, Best Buy, The Home Depot un Wayfair bija integrējuši ACP produktu atrašanai, un Shopify katalogi nonāk caur Shopify Catalog. Ko tas nozīmē izstrādātājam:

• Plūsma ir tā daļa, kas darbojas. OpenAI lapā tirgotājiem teikts, ka pirkumi „tiek pabeigti tirgotājiem piederošās tīmekļa vietnēs vai lietotnēs“ un ka iepirkšanās darbojas ASV lietotājiem. Pievienošanās ar plūsmu ir paredzēta apstiprinātiem partneriem no gaidīšanas saraksta: katru dienu pilns fails pa SFTP ar deviņiem obligātiem laukiem, API atjauninājumi dienas laikā, akcijas tikai caur API. Standarta augšupielāde „pašlaik ir paredzēta ASV“.
• Pirkuma noformēšanai ir atsevišķa piekļuve. Plūsmas specifikācijā teikts, ka pirkuma noformēšanai „nepieciešama atsevišķi aktivizēta integrācija“. ChatGPT lietotnēm vispārēji pieejamais ceļš ir ārēja pirkuma noformēšana izstrādātāja paša domēnā. Maksājuma logs tērzēšanā ir slēgta beta versija, kas „pieejama tikai atlasītām tirdzniecības platformām“ un nodod maksājuma tokenu lietotnes MCP serverim rīka izsaukumā complete_checkout.
• OpenAI lapas atpaliek no specifikācijas. Tās pirkuma noformēšanas dokumentācijā joprojām norādīta API-Version 2025-09-12 un provider uzskaitījums (enum) ar vērtībām stripe, adyen un braintree. Izstrādājiet pēc repozitorija un noskaidrojiet ar OpenAI, kura versija tiek pieņemta.

PSP lapas, kurās Instant Checkout joprojām parādīts kā darbojošs, ir novecojušas.

UCP: Universal Commerce Protocol

Pārvaldība un versijas

Google palaida UCP 2026. gada 11. janvārī, un tas izstrādāts kopā ar Shopify, Etsy, Wayfair, Target un Walmart. Pārvaldības noteikumi piešķir Google un Shopify katram vienu pastāvīgu balsi Pārvaldes padomē (Governing Council), kurai 2026. gada 28. aprīlī pievienojās Stripe, un nosaka, ka „Google pieder pilnvarotā balss par visām brīvajām vietām līdz 2028. gada decembrim“. Shopping Tech Council 24. aprīlī paplašinājās līdz 16 vietām, pievienojot Amazon, Meta, Microsoft, Salesforce un Stripe, tāpēc Meta un Stripe tagad ir gan ACP komitejā, gan UCP padomē.

Repozitorijā ir četri laidieni. 2026-04-08 pievienoja iepirkumu groza un kataloga spējas, pieprasījumu un atbilžu parakstīšanu un Get Order. Versija 2026-08-25 ievieš nesaderīgas izmaiņas: signing_keys[] aizstāja JWK Set laukā keys[], maksājumu paplašinājumi pārcēlās no dev.ucp.shopping.* uz dev.ucp.common.payment.*, kopīgās shēmas tika pārvietotas un mainīja savus $id URL, un PAN un tīkla tokeni kļuva par atsevišķiem maksāšanas datu veidiem. Tā pievienoja arī no piegādātāja neatkarīgu 3DS2, sadalītus maksājumus, maksājuma nosacījumus un sadarbspēju ar Web Bot Auth.

Te ir slazds. Google profila rokasgrāmata aptver tikai 2026-04-08 un 2026-01-23, paša Google aģenta profils vietnē ucp.goog deklarē "version": "2026-04-08", un Salesforce B2C Commerce 26.9 apkalpo tās pašas divas versijas. Savukārt Shopify Checkout MCP norāda uz 2026-08-25. Ja izstrādājat pēc jaunākā laidiena, jūs izstrādājat versiju, ko Google nedokumentē. Specifikācijas risinājums ir objekts supported_versions, kas katrai vecākai versijai piesaista savu profila URI.

Atrašana, transports un autentifikācija

Katrs uzņēmums publicē profilu adresē /.well-known/ucp ar ucp.version, ucp.services un ucp.payment_handlers, un Google prasa, lai tas būtu publisks un pieejams bez autentifikācijas. Aģenta platforma arī publicē savu profilu, un katrs pieprasījums nes tā URI galvenē UCP-Agent, caur HTTPS ar vismaz TLS 1.3. Autentifikācija ir uzņēmuma izvēle: bez autentifikācijas, X-API-Key, OAuth 2.0, savstarpējais TLS vai RFC 9421 HTTP Message Signatures. Google sūta bearer tokenu, un tā BUJ piedāvā arī mTLS. Idempotency-Key ir tikai ieteikums („SHOULD“); serveris, kas to pieņem, glabā to vismaz 24 stundas un atbild ar 409, ja to izmanto atkārtoti ar citu pieprasījuma saturu.

REST ir galvenais transports, līdzās MCP, A2A paplašinājumam un iegultajam režīmam, kuram piekļūst caur continue_url. Pasūtījumiem ir GET /orders/{id} un webhook no uzņēmuma uz platformu, parakstīts saskaņā ar RFC 9421. Iepirkumu groza ceļi ir tādi paši kā ACP. Pirkuma noformēšanas operācijas izskatās līdzīgas, bet nav savstarpēji aizstājamas:

Viens pirkuma noformēšanas kodols var apkalpot abus. Viena maršrutu tabula nevar.

Kā maksājumi notiek UCP

UCP pats naudu nepārvieto. Maksājumu apstrādātājs (payment handler) ir specifikācija, ko raksta maksāšanas datu nodrošinātājs, piemēram, com.google.pay Google Pay vai dev.shopify.shop_pay Shop Pay. Uzņēmums uzskaita apstrādātājus, ko tas pieņem, platforma izmanto vienu no tiem, un operācijā complete uzņēmums saņem necaurskatāmu tokenu, ko iekasēt caur savu PSP.

Google platformās vienīgais apstrādātājs ir Google Pay, vienīgā izmantotā autentifikācijas metode ir PAN_ONLY, un jūsu PSP „jāspēj apstrādāt mūsu tokenus“. Stripe publicē com.stripe.payments kartēm un Apple Pay: „Aģents pieprasījumā Complete Checkout nosūta shared payment token (SPT), un pārdevējs to iekasē“. Google Pay paliek savā apstrādātājā. PayPal pieņem Google Pay apstrādātāju caur Braintree vai caur savu Orders v2 API.

Ko Google prasa, pirms sāk izsaukt jūsu sistēmu

Google rokasgrāmata par iebūvēto pirkuma noformēšanu prasa REST pirkuma noformēšanas API un maksājuma soli patur sev: pircējs ievada sensitīvus datus „tikai Google saskarnē“. Noteiktie pakalpojuma līmeņi ir vismaz 95 % pieejamība katram galapunktam, ar p50 un p95 latentumu 1 un 4 sekundes izveidei, 1 un 5 atjaunināšanai un 6 un 10 pabeigšanai. Pēc pasūtījuma jūs nosūtāt statusa atjauninājumus uz Google webhook ar partnera ID un atslēgu, kas izsniegti pievienošanās laikā. Merchant Center katram produktam native_commerce(checkout_eligibility) jābūt iestatītam uz true (tā „noklusējuma vērtība ir FALSE“), atgriešanas politika un atbalsta kontaktinformācija ir obligātas, un abonementi, maksājumi pa daļām, personalizētas, lietotas un atjaunotas preces, priekšpasūtījumi un preces ar vecuma ierobežojumu ir izslēgti.

Vieglākā iespēja kopš 2026-04-08 ir groza nodošana: jūs ieviešat tikai groza izveidi, Google nodod grozu jūsu vietnei, un nav vajadzīgs ne maksājumu apstrādātājs, ne pasūtījumu webhook.

Piekļuve ir īstais ierobežojums. Pirkuma noformēšana ir „pieejama atlasītiem tirgotājiem“ caur agrīnās piekļuves interesenta veidlapu, kurā jūs apņematies sākt 30 dienu laikā un piekrītat, ka piekļuvi „var atņemt“, ja darbs nevirzās uz priekšu. UCP Checkout noteikumi attiecas „tikai uz Amerikas Savienotajām Valstīm“. Merchant Center centram (hub) Austrālijā un Kanādā jāseko „nākamā gada sākumā“; Google nenorāda pirkuma noformēšanas datumu nevienai citai valstij.

UCP ārpus Google

Microsoft Merchant Center kopš 2026. gada 21. aprīļa pieņem UCP gatavas plūsmas ASV. Copilot Checkout prasa UCP atbilstošu plūsmu, pieņem angļu valodā strādājošus tirgotājus, kas pārdod ASV pircējiem dolāros, katram vienu PSP, un tā veikala iestatījums ir apzīmēts kā „pilotprojekts tikai atlasītiem klientiem“. Shopify nodrošina UCP caur MCP adresē https://{shop}/api/ucp/mcp un ir noņēmis savus vecākos kataloga un groza rīkus. Naktsmītņu rezervēšanas spēja tika pievienota kā melnraksts 2026. gada 24. septembrī un nav iekļauta nevienā laidienā.

AP2: Agent Payments Protocol

AP2 nav trešais pirkuma noformēšanas veids. Tā specifikācijā teikts, ka tas „darbojas kā drošības funkcija tirdzniecības protokola ietvaros“ un ir „izstrādāts tieši tā, lai būtu saderīgs ar Universal Commerce Protocol (UCP)“. Versija 0.1.0 iznāca 2025. gada 16. septembrī, bet v0.2 iznāca 2026. gada 28. aprīlī, dienā, kad Google nodeva AP2 aliansei FIDO Alliance. FIDO paziņojumā minēta Agentic Authentication darba grupa un Payments darba grupa, ko vada Mastercard un Visa pārstāvji, un teikts, ka ieguldījumi „tiks izskatīti un tālāk attīstīti“. FIDO nav publicējusi nevienu AP2 specifikāciju. GitHub repozitorijs tagad pieņem tikai piemērus un SDK izmaiņas, un pēdējās izmaiņas tajā veiktas 29. aprīlī.

Versija 0.2 definē Checkout Mandate (kas tiek pirkts) un Payment Mandate (maksājums ar ierobežojumiem, piemēram, payment.amount_range, payment.budget un payment.allowed_payees). Katrs no tiem ir SD-JWT slēgtā un atvērtā formā (piemēram, mandate.payment.1 un mandate.payment.open.1). Režīmā Human Present lietotājs apstiprina slēgtos mandātus. Režīmā Human Not Present lietotājs apstiprina atvērtos mandātus, kas nosaka ierobežojumus un satur aģenta publisko atslēgu prasībā (claim) cnf, un aģents šo ierobežojumu robežās saliek slēgtos mandātus. Pamācības par Intent un Cart Mandates apraksta v0.1; versijā v0.2 šo terminu vairs nav.

UCP ietvaros AP2 ir paplašinājums dev.ucp.common.payment.ap2_mandate (dev.ucp.shopping.ap2_mandate pirms 2026-08-25). Kad tas ir saskaņots, uzņēmums paraksta savas pirkuma noformēšanas atbildes, platforma operācijā complete uzrāda checkout_mandate un payment_mandate, un sesija ir „Security Locked“ (drošības bloķēta): neviena puse nedrīkst atkāpties uz parastu pirkuma noformēšanu.

Neviens to vēl neprasa. Google BUJ AP2 nosaukts par „īpaši noderīgu nākotnes scenārijiem, kas ietver autonomus MI aģentu darījumus“. Paša Google aģenta profilā kā vienīgais maksājumu apstrādātājs norādīts Google Pay, un tajā nav deklarēta AP2 spēja; arī tā 2026-08-25 profilā nav AP2 ieraksta. Neviena Google produkta dokumentācijā nav teikts, ka tas izmanto AP2, tāpēc tirgotājam nav ko izstrādāt, kamēr kāda platforma to nesaskaņo.

Blakus esošie protokoli

MCP

ACP un UCP abi var darboties caur MCP, kura pašreizējā specifikācija 2026-07-28 atceļ sesijas un galveni Mcp-Session-Id, atsakās no sākotnējās saskaņošanas (handshake) initialize, prasa server/discover un liek klientam atkārtoti nosūtīt pieprasījumu ar jaunu ID, ja tā straume pārtrūkst. ACP saistījums joprojām norāda uz 2025-11-25 transportu. Pirkuma noformēšanas sesijas ID ir tieši tāds servera izveidots identifikators, kādu sagaida jaunā specifikācija, un complete, kas pazudis straumes vidū, atgriežas kā jauns pieprasījums: uzskatiet idempotences atslēgas par obligātām abos protokolos.

WebMCP

WebMCP ir ierosināts tīmekļa standarts, kas ļauj lapai atklāt savas funkcijas aģentiem pārlūkā. Shopify piedāvā UCP pirkuma noformēšanu gan kā Checkout MCP, gan kā Checkout WebMCP ar to pašu pirkuma noformēšanas objektu un iesaka Checkout MCP. Tā statuss aplūkots mūsu WebMCP ceļvedī.

x402 un MPP

x402 un Machine Payments Protocol, ko izstrādājuši Tempo un Stripe, iekasē no aģenta maksu par katru HTTP pieprasījumu, piekļūstot API, datiem vai saturam. Tie nav veikala pirkuma noformēšanas protokoli. Skatiet mūsu rakstu par x402.

Visa Trusted Agent Protocol un Mastercard Agent Pay

Tie darbojas līdzās ACP un UCP, nevis tos aizstāj. Visa Trusted Agent Protocol dod aģentam „standartizētu, kriptogrāfisku metodi“, ar ko pierādīt tirgotājiem savu identitāti un autorizāciju, un Mastercard Agent Pay ir tokenizācijas programma aģentiskajai tirdzniecībai. Mastercard ceļvedī tirgotājiem UCP un ACP ierindoti augstākajā gatavības līmenī, norādīts, ka „agrīnie ieviesēji pašlaik veic integrāciju“, un tirgotājiem ieteikts sākt ar diviem vienkāršākajiem līmeņiem. Abas programmas aplūkotas mūsu rakstā par aģentiskajiem maksājumiem.

Personal Agent Protocol

Sierra norāda, ka 2026. gada 6. oktobrī kopā ar Meta izziņoja Personal Agent Protocol („Poppy“), un 9. oktobrī tā publicēja protokola projektu. Uzņēmums publicē vienu failu adresē /.well-known/poppy.json; protokols izmanto OAuth, JWT, HTTPS, OpenAPI un MCP, lai personīgais aģents varētu sevi identificēt un saņemt klienta atļauju jebkura veida uzdevumam, un Sierra to sauc par UCP papildinošu. Protokola vietnē redzama versija 0.2 un teikts: „Tas ir projekts“. Meta oficiālajā ziņu vietnē mēs neatradām nevienu ierakstu par to.

Kurš no tiem jums vajadzīgs?

Ja izmantojat Shopify

Nekas nav jāizstrādā. Shopify funkcija agentic storefronts ir „pēc noklusējuma aktīva atbilstošiem veikaliem“. ChatGPT saņem jūsu katalogu caur Shopify Catalog un sūta pircējus uz jūsu veikalu. Google tiešā pirkuma noformēšana ir ieslēgta pēc noklusējuma veikaliem, kas atrodas ASV un pārdod ASV, un Copilot Shopify tirgotājus iekļāva automātiski. Jums jālemj par produktu datiem un par to, vai paturēt tiešo pirkuma noformēšanu ieslēgtu, zinot, ka pielāgotie pikseļi (custom pixels) Google pirkuma noformēšanā netiek aktivizēti.

Ja izmantojat Salesforce, commercetools vai citu platformu

Salesforce B2C Commerce 26.9 apkalpo UCP versijas 2026-01-23 un 2026-04-08: /.well-known/ucp ar karti supported_versions un pirkuma noformēšanas sesiju galapunktus aiz SLAS tokena. Salesforce sarakstā UCP pirkuma noformēšana Google vidē 2026. gada oktobrī norādīta kā vispārēji pieejama. Sesija ir groza headless skats, un Salesforce audita ceļvedis brīdina, ka SFRA un SiteGenesis kontrolieri un „citi SCAPI resursi, ko jūs šodien izmantojat, šajā procesā nedarbojas“, tāpēc ar tiem saistītā loģika jākopē vai jāsavieno ar UCP pirkuma noformēšanas sesijas āķiem (hooks). Plūsmai jābūt paredzētai en-US, un Salesforce „neļauj apiet Google gaidīšanas sarakstu“. ChatGPT gadījumā Salesforce ir viens no piegādes ceļiem, ko OpenAI min ACP plūsmām.

Ja izmantojat commercetools vai citu platformu, jautājiet tās piegādātājam, kuras UCP versijas un spējas platforma apkalpo, kuri no jūsu āķiem darbojas aģenta pirkuma noformēšanā un vai tā sūta plūsmas uz OpenAI.

Ja izmantojat savu programmatūru

1. Vispirms plūsmas. Google Merchant Center un, kad OpenAI jūs pieņem, tā produktu plūsma. ACP komerciālais lietojums ChatGPT šodien ir tieši šis.
2. UCP Google vajadzībām, ja pārdodat ASV un Google jūs pieņem. Izstrādājiet pēc 2026-04-08: profils ar com.google.pay, pirkuma noformēšanas operācijas Google latentuma mērķu robežās, PSP, kas apstrādā Google Pay tokenus, pasūtījumu webhook un plūsmas atribūts. Vai sāciet tikai ar groza nodošanu.
3. ACP pirkuma noformēšanu tikai tad, ja tam ir iemesls, piemēram, ChatGPT lietotne, kas uzņemta maksājuma loga beta versijā. Izstrādājiet pēc repozitorija versijas 2026-04-17.
4. AP2: pagaidām nekas.
5. Viens pirkuma noformēšanas kodols. Abi protokoli prasa sesiju, ko var izveidot, atjaunināt, pabeigt un atcelt caur API un droši atkārtot. Izstrādājiet to vienreiz virs savas pasūtījumu, nodokļu un maksājumu loģikas, ar vienkāršiem ACP un UCP adapteriem virsū un MCP tur, kur aģentiem tas vajadzīgs.

Šodien neviens no abiem protokoliem nedod abonementu biznesam iebūvētu pirkuma noformēšanu aģentiem.

Ja pārdodat tikai ārpus ASV

Neviens no trim šodien nedod jums pirkuma noformēšanu aģentiem. ChatGPT iepirkšanās un OpenAI standarta plūsmas augšupielāde ir paredzētas ASV; Google UCP Checkout noteikumi attiecas tikai uz ASV; Copilot Checkout apkalpo ASV pircējus dolāros. Nākamais izziņotais Google solis ir Merchant Center centrs Austrālijā un Kanādā „nākamā gada sākumā“, bez datuma Apvienotajai Karalistei vai ES.

Uzturiet savu Merchant Center plūsmu pilnīgu un, ja tik un tā pārbūvējat pirkuma noformēšanu, izstrādājiet iepriekš aprakstīto API vadīto kodolu, lai adapteris būtu neliels darbs, kad jūsu tirgus atvērsies. Pārdodat ASV no ārzemēm? Pārbaudiet, kur katra programma prasa tirgotājam atrasties; piemēram, Shopify Google tiešajai pirkuma noformēšanai nepieciešams ASV veikals.

Kur saņemt palīdzību

Mēs izstrādājam protokolu slāni veikaliem, kas neizmanto Shopify: /.well-known/ucp profilu un pirkuma noformēšanas sesiju galapunktus virs jūsu esošās pasūtījumu, nodokļu un maksājumu loģikas, pasūtījumu webhook uz Google, produktu plūsmas Google Merchant Center un OpenAI un MCP serverus, kas to pašu pirkuma noformēšanu atver aģentiem. Šis darbs sākas ar mūsu MI aģentu izstrādes un MCP integrācijas pakalpojumu.

Rakstiet uz office@c9group.dev, norādot savu platformu, maksājumu pakalpojumu sniedzēju un valstis, kurās pārdodat, un mēs pateiksim, kurš protokols uz jums attiecas un ko prasītu tā ieviešana. Google un OpenAI programmu noteikumi ir līgumi: mēs esam inženieri, nevis juristi, tāpēc pirms parakstīšanas lūdziet konsultantam tos izlasīt.