ACP, UCP ir AP2 palyginimas: agentinės prekybos protokolai 2026 m. spalį ir kurio iš jų reikia jūsų parduotuvei

Trys atviri protokolai dabar aprašo, kaip DI agentas perka iš parduotuvės. Agentic Commerce Protocol (ACP) sukūrė OpenAI ir Stripe. Universal Commerce Protocol (UCP) sukūrė Google ir Shopify. Agent Payments Protocol (AP2), kurį pradėjo Google ir balandį perdavė FIDO Alliance, apskritai nėra atsiskaitymo protokolas: jis apibrėžia pasirašytą įrodymą, kad naudotojas įgaliojo mokėjimą, ir yra skirtas veikti UCP viduje. Visi trys platinami pagal Apache 2.0 licenciją.

2026 m. spalio 22 d. jų padėtis labai skiriasi. ACP pažymėtas kaip beta versija, naujausias jo leidimas yra 2026-04-17, o nuo liepos 17 d. į jį neįtrauktas nė vienas pakeitimas. ChatGPT, pagrindinis jo naudotojas, kovą atsisakė savarankiško atsiskaitymo ir dabar ACP daugiausia naudoja produktų duomenims gauti. UCP rugpjūtį paskelbė versiją 2026-08-25, nesuderinamą su ankstesnėmis, o pačios Google aplinkos vis dar veikia su 2026-04-08, ir jos atsiskaitymas tebėra ankstyvosios prieigos etape, tik JAV. AP2 pasiekė v0.2, ir nė vienas Google produktas nedokumentuoja jo naudojimo.

Šis straipsnis skirtas parduotuvių ir prekybos platformų technikos vadovams (CTO) ir vyriausiesiems programuotojams, sprendžiantiems, ką įgyvendinti. Jei norite sužinoti, ko kiekviena DI platforma reikalauja iš parduotuvės kaip verslo, pradėkite nuo mūsų agentinės prekybos apžvalgos.

Vienas šalia kito

ACP: Agentic Commerce Protocol

Valdymas ir versijos

Specifikacijos saugykloje rašoma, kad ACP prižiūri OpenAI ir Stripe, o protokolas pažymėtas kaip beta versija. Pagal valdymo dokumentą abi bendrovės yra Founding Maintainers (steigėjos ir pagrindinės prižiūrėtojos): jos skiria valdymo komiteto narius (iki septynių) ir pasilieka veto teisę, kurią naudoja „kraštutiniu atveju“. 2026 m. balandžio 24 d. Meta prisijungė kaip trečioji pagrindinė prižiūrėtoja ir komiteto narė. Stripe dokumentacijoje ACP vadinamas „sukurtu Stripe, OpenAI ir Meta“, tačiau saugyklos NOTICE faile nurodytos tik OpenAI ir Stripe. Neutralus fondas kol kas tėra deklaruotas ateities kelias.

Yra penki datomis pažymėti leidimai: 2025-09-29 (atsiskaitymas ir deleguotas mokėjimas), 2025-12-12 (nesuderinami pakeitimai, padaryti remiantis URBN ir Etsy adapterių patirtimi), 2026-01-16 (prekybininko pasirenkamas 3DS teikėjas), 2026-01-30 (galimybių derinimas, plėtiniai ir nesuderinama mokėjimų apdorojimo modulių sistema) ir 2026-04-17 (krepšelis, sklaidos kanalas, užsakymai, deleguotas autentifikavimas, atradimas ir MCP), kuriame 2026-01-30 paskelbtas pasenusiu. Per šešis mėnesius nuo to laiko nieko naujo neišleista. Aplanke unreleased/ yra smulkesnių pakeitimų, datuotų iki liepos 17 d., pavyzdžiui, sklaidos kanalo atnaujinimo ID ir neprivalomas produkto URL atsiskaitymo prekėse.

Ką prekybininkas įgyvendina versijoje 2026-04-17

Atsiskaitymo API talpina prekybininkas, o kviečia agentas:

• POST /checkout_sessions sukuria sesiją, POST /checkout_sessions/{checkout_session_id} ją atnaujina (tai POST, ne PUT), GET tuo pačiu keliu ją grąžina, o .../complete ir .../cancel ją užbaigia.
• Užklausose perduodamas bearer API raktas ir privaloma antraštė API-Version. Nuo 2026-04-17 kiekvienoje POST užklausoje privalomas Idempotency-Key, o klaidos apibrėžtos: 400 idempotency_key_required, 409 idempotency_in_flight ir 422 idempotency_conflict.
• Sukūrimo užklausoje perduodamas objektas capabilities. Agentas nurodo, ką palaiko, o pardavėjas grąžina sankirtą, todėl nesuderinamumas išryškėja dar prieš mokėjimą.
• Prekybininkas POST užklausomis siunčia užsakymų įvykius į OpenAI talpinamą gavėją adresu /agentic_checkout/webhooks/order_events, pasirašydamas juos HMAC-SHA256 antraštėje Merchant-Signature. Būsenos eina nuo created iki delivered arba canceled, o adjustments[] perduoda pinigų grąžinimus, prekių grąžinimus, ginčus ir mokėjimų atšaukimus (chargebacks).

Leidime 2026-04-17 taip pat atsirado statinis, viešas /.well-known/acp.json, kurio laukas transports nurodo, ar parduotuvė palaiko rest, mcp ar abu. Jame atsirado ir MCP susiejimas per Streamable HTTP su penkiais įrankiais (create_checkout_session, get_checkout_session, update_checkout_session, complete_checkout_session, cancel_checkout_session), autentifikuojamas serverio konfigūracijoje, o ne kiekvienoje užklausoje. Be to, jame atsirado Feed API, kurią talpina agentas ir į kurią duomenis siunčia prekybininkas (POST /feeds, PATCH /feeds/{id}/products), vieno pardavėjo krepšelis be mokėjimo duomenų (POST /carts, PUT /carts/{id}) ir deleguotas 3DS2 autentifikavimas (POST /delegate_authentication). Prenumeratų nėra: plėtinių RFC dokumente subscription aprašomas kaip „Pasikartojančio apmokestinimo palaikymas (ateityje)“.

Kaip ACP veikia mokėjimai

Pirminis ACP sprendimas yra deleguotas mokėjimas. Mokėjimų paslaugų teikėjas (PSP) arba kortelių duomenų saugykla įgyvendina POST /agentic_commerce/delegate_payment, kuris kortelę (vienintelį mokėjimo duomenų tipą) paverčia žetonu, kurį prekybininko mokėjimų paslaugų teikėjas gali naudoti tik neviršydamas leistinų ribų: reason (tik one_time), max_amount, currency, checkout_session_id, merchant_id ir expires_at. RFC dokumente rašoma: „Mokėjimai, galutinis atsiskaitymas ir atitiktis lieka prekybininko infrastruktūroje.“ Worldpay dokumentuoja savo šios užklausos versiją, o PayPal palaiko ACP per deleguotus žetonus Braintree sistemoje.

Nuo 2026-01-30 priimami mokėjimo būdai deklaruojami kaip mokėjimų apdorojimo moduliai lauke capabilities.payment.handlers. Pakeitimų žurnalo pavyzdiniai mokėjimo duomenys:

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

spt yra Stripe Shared Payment Token, prieinamas „JAV, Kanadoje ir atrinktose Europos šalyse“. Stripe naudojantis pardavėjas pagal jį nuskaičiuoja mokėjimą su payment_method_data[shared_payment_granted_token], naudodamas API peržiūros versiją; kitos mokėjimų apdorojimo bendrovės paslaugomis besinaudojantis pardavėjas gali vieną kartą jį paversti kortelių tinklo mokėjimo duomenimis. Kas prisiima riziką, aptariama mūsų straipsnyje apie agentinius mokėjimus.

Ką pakeitė OpenAI kovo sprendimas

2026 m. kovo 24 d. OpenAI rašė, kad „pirmoji Instant Checkout versija nesuteikė tokio lankstumo, kokio siekiame“, leido prekybininkams naudoti savo pačių atsiskaitymo sprendimus ir pareiškė, kad „plečia ACP, kad jis taptų jungiamuoju sluoksniu tarp prekybininkų ir naudotojų viso atradimo metu“. Target, Sephora, Nordstrom, Lowe's, Best Buy, The Home Depot ir Wayfair buvo integravę ACP atradimui, o Shopify katalogai patenka per Shopify Catalog. Ką tai reiškia programuotojui:

• Veikia būtent sklaidos kanalas. OpenAI puslapyje prekybininkams rašoma, kad pirkimai „užbaigiami prekybininkams priklausančiose svetainėse ar programėlėse“ ir kad apsipirkimas veikia JAV naudotojams. Sklaidos kanalų prijungimas skirtas patvirtintiems partneriams iš laukiančiųjų sąrašo: kasdienis visas failas per SFTP su devyniais privalomais laukais, API atnaujinimai dienos metu, akcijos tik per API. Standartinis įkėlimas „šiuo metu skirtas JAV“.
• Atsiskaitymas atrakinamas atskirai. Sklaidos kanalo specifikacijoje rašoma, kad atsiskaitymui „reikia atskirai įjungiamos integracijos“. ChatGPT programėlėms visuotinai prieinamas kelias yra išorinis atsiskaitymas paties kūrėjo domene. Mokėjimo langas pokalbio viduje yra privati beta versija, „skirta tik atrinktoms prekyvietėms“, kuri perduoda mokėjimo žetoną programėlės MCP serveriui per įrankio complete_checkout iškvietimą.
• OpenAI puslapiai atsilieka nuo specifikacijos. Bendrovės atsiskaitymo dokumentacijoje vis dar nurodyta API-Version 2025-09-12 ir provider reikšmių sąrašas (enum) su stripe, adyen ir braintree. Kurkite pagal saugyklą ir pasitikslinkite su OpenAI, kurią versiją ji priima.

Mokėjimų paslaugų teikėjų puslapiai, kuriuose Instant Checkout vis dar pateikiamas kaip veikiantis, yra pasenę.

UCP: Universal Commerce Protocol

Valdymas ir versijos

Google pristatė UCP 2026 m. sausio 11 d.; protokolas sukurtas kartu su Shopify, Etsy, Wayfair, Target ir Walmart. Valdymo taisyklės suteikia Google ir Shopify po vieną nuolatinį balsą Valdymo taryboje (Governing Council), prie kurios 2026 m. balandžio 28 d. prisijungė Stripe, ir nustato, kad „Google turi įgaliotinio balsą visose laisvose vietose iki 2028 m. gruodžio“. Balandžio 24 d. taryba Shopping Tech Council išsiplėtė iki 16 vietų: į ją įtrauktos Amazon, Meta, Microsoft, Salesforce ir Stripe, taigi Meta ir Stripe dabar yra ir ACP komitete, ir UCP taryboje.

Saugykloje yra keturi leidimai. 2026-04-08 pridėjo krepšelio ir katalogo galimybes, užklausų ir atsakymų pasirašymą bei Get Order. 2026-08-25 yra nesuderinamas su ankstesniais: signing_keys[] pakeistas JWK Set rinkiniu lauke keys[], mokėjimų plėtiniai perkelti iš dev.ucp.shopping.* į dev.ucp.common.payment.*, bendros schemos perkeltos ir pakeitė savo $id URL, o PAN ir tinklo žetonai tapo atskirais mokėjimo duomenų tipais. Jame taip pat atsirado nuo tiekėjo nepriklausomas 3DS2, padalyti mokėjimai, mokėjimo sąlygos ir suderinamumas su Web Bot Auth.

Čia ir slypi spąstai. Google profilio vadovas apima tik 2026-04-08 ir 2026-01-23, pačios Google agento profilis adresu ucp.goog deklaruoja "version": "2026-04-08", o Salesforce B2C Commerce 26.9 palaiko tas pačias dvi versijas. Tuo tarpu Shopify Checkout MCP pateikia nuorodą į 2026-08-25. Jei kursite pagal naujausią leidimą, sukursite versiją, kurios Google nedokumentuoja. Specifikacija tam siūlo objektą supported_versions, kuris kiekvieną senesnę versiją susieja su atskiru profilio URI.

Atradimas, perdavimo būdai ir autentifikavimas

Kiekviena įmonė skelbia profilį adresu /.well-known/ucp su ucp.version, ucp.services ir ucp.payment_handlers, o Google reikalauja, kad jis būtų viešas ir pasiekiamas be autentifikavimo. Savo profilį skelbia ir agento platforma, o kiekvienoje užklausoje jo URI perduodamas antraštėje UCP-Agent, per HTTPS, naudojant ne senesnį nei TLS 1.3 protokolą. Autentifikavimą pasirenka įmonė: jokio, X-API-Key, OAuth 2.0, abipusis TLS arba RFC 9421 HTTP Message Signatures. Google siunčia bearer žetoną, o jos DUK siūlo ir mTLS. Idempotency-Key tėra rekomendacija („SHOULD“); serveris, kuris jį priima, saugo jį ne trumpiau kaip 24 valandas ir atsako 409, kai jis pakartotinai panaudojamas su kitokiu užklausos turiniu.

REST yra pagrindinis perdavimo būdas, šalia jo veikia MCP, A2A plėtinys ir įterptasis režimas, pasiekiamas per continue_url. Užsakymai yra GET /orders/{id} ir įmonės platformai siunčiamas webhook, pasirašytas pagal RFC 9421. Krepšelio keliai tokie patys kaip ACP. Atsiskaitymo operacijos atrodo panašiai, tačiau viena kitos nepakeičia:

Vienas atsiskaitymo branduolys gali aptarnauti abu protokolus. Viena maršrutų lentelė negali.

Kaip UCP veikia mokėjimai

UCP pinigų neperveda. Mokėjimų apdorojimo modulis yra specifikacija, kurią parašo mokėjimo priemonės teikėjas, pavyzdžiui, com.google.pay Google Pay atveju arba dev.shopify.shop_pay Shop Pay atveju. Įmonė nurodo, kuriuos modulius priima, platforma vieną jų vykdo, o po complete įmonė gauna nepermatomą žetoną, pagal kurį mokėjimą nuskaičiuoja per savo mokėjimų paslaugų teikėją.

Google aplinkose vienintelis modulis yra Google Pay, vienintelis naudojamas autentifikavimo metodas yra PAN_ONLY, o jūsų mokėjimų paslaugų teikėjas „turi gebėti apdoroti mūsų žetonus“. Stripe skelbia com.stripe.payments kortelėms ir Apple Pay: „Agentas užklausoje Complete Checkout siunčia Shared Payment Token (SPT), o pardavėjas pagal jį nuskaičiuoja mokėjimą.“ Google Pay lieka savo atskirame modulyje. PayPal Google Pay modulio mokėjimus priima per Braintree arba per savo Orders v2 API.

Ko Google reikalauja, prieš kreipdamasi į jus

Google integruoto atsiskaitymo vadove reikalaujama REST atsiskaitymo API, o mokėjimo žingsnį Google pasilieka sau: jautrius duomenis pirkėjas įveda „tik Google sąsajoje“. Paslaugų lygio reikalavimai: kiekvieno galinio taško prieinamumas ne mažesnis kaip 95 %, o p50 ir p95 delsa yra 1 ir 4 sekundės sukūrimui, 1 ir 5 atnaujinimui bei 6 ir 10 užbaigimui. Po užsakymo būsenos atnaujinimus siunčiate į Google webhook su partnerio ID ir raktu, išduotais prisijungimo metu. Merchant Center sistemoje kiekvienam produktui reikia native_commerce(checkout_eligibility) reikšmės true (ji „pagal numatytuosius nustatymus yra FALSE“), grąžinimo politika ir pagalbos kontaktas yra privalomi, o prenumeratos, mokėjimas dalimis, personalizuotos, naudotos ir atnaujintos prekės, išankstiniai užsakymai ir prekės su amžiaus apribojimais neįtraukiami.

Lengvesnis variantas nuo 2026-04-08 yra krepšelio perdavimas (cart transfer): įgyvendinate tik krepšelio sukūrimą, Google perduoda krepšelį į jūsų svetainę, o mokėjimų apdorojimo modulio ar užsakymų webhook nereikia.

Tikrasis apribojimas yra prieiga. Atsiskaitymas „prieinamas atrinktiems prekybininkams“ per ankstyvosios prieigos susidomėjimo formą, kurioje įsipareigojate pradėti per 30 dienų ir sutinkate, kad prieiga „gali būti panaikinta“, jei nepadarysite pažangos. UCP Checkout sąlygos taikomos „tik Jungtinėms Valstijoms“. Merchant Center UCP centras Australijoje ir Kanadoje turėtų atsirasti „kitų metų pradžioje“; jokiai kitai šaliai Google atsiskaitymo datos nenurodo.

UCP už Google ribų

Microsoft Merchant Center nuo 2026 m. balandžio 21 d. JAV priima UCP pritaikytus sklaidos kanalus. Copilot Checkout reikalauja UCP reikalavimus atitinkančio sklaidos kanalo, priima anglų kalba veikiančius prekybininkus, parduodančius JAV pirkėjams doleriais, kiekvieną su vienu mokėjimų paslaugų teikėju, o jo parduotuvės nustatymas pažymėtas „tik bandomasis projektas atrinktiems klientams“. Shopify teikia UCP per MCP adresu https://{shop}/api/ucp/mcp ir pašalino savo senesnius katalogo ir krepšelio įrankius. Apgyvendinimo užsakymo galimybė 2026 m. rugsėjo 24 d. įtraukta kaip juodraštis ir nėra nė viename leidime.

AP2: Agent Payments Protocol

AP2 nėra trečiasis atsiskaitymo būdas. Jo specifikacijoje rašoma, kad jis „veikia kaip saugumo funkcija prekybos protokolo viduje“ ir yra „sukurtas būtent taip, kad būtų suderinamas su Universal Commerce Protocol (UCP)“. Versija 0.1.0 pasirodė 2025 m. rugsėjo 16 d., o v0.2 2026 m. balandžio 28 d., tą dieną, kai Google perdavė AP2 FIDO Alliance. FIDO pranešime įvardijama Agentic Authentication darbo grupė ir Payments darbo grupė, kurioms pirmininkauja Mastercard ir Visa atstovai, ir teigiama, kad perduoti darbai „bus peržiūrėti ir toliau plėtojami“. FIDO nėra paskelbusi jokios AP2 specifikacijos. GitHub saugykla dabar priima tik pavyzdžių ir SDK pakeitimus, o paskutinis pakeitimas (commit) joje padarytas balandžio 29 d.

Versijoje 0.2 apibrėžiami Checkout Mandate (kas perkama) ir Payment Mandate (mokėjimas su apribojimais, tokiais kaip payment.amount_range, payment.budget ir payment.allowed_payees). Kiekvienas jų yra SD-JWT, turintis uždarąją ir atvirąją formą (pavyzdžiui, mandate.payment.1 ir mandate.payment.open.1). Režimu Human Present naudotojas patvirtina uždaruosius įgaliojimus. Režimu Human Not Present naudotojas patvirtina atviruosius įgaliojimus, kurie nustato apribojimus ir kurių cnf teiginyje (claim) pateikiamas agento viešasis raktas, o uždaruosius agentas sudaro pats, neviršydamas tų ribų. Mokomosios medžiagos apie Intent ir Cart Mandates aprašo v0.1; versijoje 0.2 šių terminų nebeliko.

UCP viduje AP2 yra plėtinys dev.ucp.common.payment.ap2_mandate (iki 2026-08-25 jis vadinosi dev.ucp.shopping.ap2_mandate). Kai dėl jo susitariama, įmonė pasirašo savo atsiskaitymo atsakymus, platforma per complete pateikia checkout_mandate ir payment_mandate, o sesija tampa „Security Locked“ (užrakinta saugumo sumetimais): nė viena šalis nebegali grįžti prie įprasto atsiskaitymo.

Jo dar niekas neprašo. Google DUK AP2 vadinamas „ypač naudingu ateities scenarijams, susijusiems su autonominiais DI agentų sandoriais“. Pačios Google agento profilyje vienintelis mokėjimų apdorojimo modulis yra Google Pay ir nedeklaruojama jokia AP2 galimybė, o jos 2026-08-25 profilyje AP2 įrašo taip pat nėra. Nė vienas Google produktas nedokumentuoja AP2 naudojimo, todėl prekybininkui nėra ką kurti, kol kuri nors platforma dėl jo nesusitars.

Gretimi protokolai

MCP

ACP ir UCP abu gali veikti per MCP, kurio dabartinė specifikacija 2026-07-28 panaikina sesijas ir antraštę Mcp-Session-Id, atsisako pasisveikinimo initialize, reikalauja server/discover, o nutrūkus duomenų srautui klientas turi pakartoti užklausą su nauju ID. ACP susiejimas vis dar nurodo 2025-11-25 transporto versiją. Atsiskaitymo sesijos ID yra būtent tas serverio sukurtas identifikatorius, kurio tikisi naujoji specifikacija, o duomenų srauto viduryje prarasta complete užklausa grįžta kaip nauja užklausa: abiejuose protokoluose idempotentiškumo raktus laikykite privalomais.

WebMCP

WebMCP yra siūlomas žiniatinklio standartas, leidžiantis puslapiui pateikti savo funkcijas naršyklės agentams. Shopify UCP atsiskaitymą siūlo ir kaip Checkout MCP, ir kaip Checkout WebMCP, su tuo pačiu atsiskaitymo objektu, ir rekomenduoja Checkout MCP. Jo būklė aptariama mūsų WebMCP vadove.

x402 ir MPP

x402 ir Machine Payments Protocol, kurį sukūrė Tempo ir Stripe, apmokestina agentą už kiekvieną HTTP užklausą, kai šis naudojasi API, duomenimis ar turiniu. Tai nėra parduotuvių atsiskaitymo protokolai. Daugiau rasite mūsų straipsnyje apie x402.

Visa Trusted Agent Protocol ir Mastercard Agent Pay

Jie veikia šalia ACP ir UCP, o ne vietoj jų. Visa Trusted Agent Protocol suteikia agentui „standartizuotą kriptografinį metodą“ prekybininkams įrodyti savo tapatybę ir įgaliojimus, o Mastercard Agent Pay yra tokenizavimo programa agentinei prekybai. Mastercard gairėse prekybininkams UCP ir ACP priskiriami aukščiausiam pasirengimo lygiui, pažymima, kad „ankstyvieji diegėjai šiuo metu vykdo integraciją“, ir prekybininkams patariama pradėti nuo dviejų paprastesnių lygių. Abi programos aptariamos mūsų straipsnyje apie agentinius mokėjimus.

Personal Agent Protocol

Sierra teigia, kad 2026 m. spalio 6 d. kartu su Meta paskelbė Personal Agent Protocol („Poppy“), o spalio 9 d. paskelbė juodraštį. Įmonė skelbia vieną failą adresu /.well-known/poppy.json; protokolas naudoja OAuth, JWT, HTTPS, OpenAPI ir MCP, kad asmeninis agentas galėtų nustatyti savo tapatybę ir gauti kliento leidimą bet kokiai užduočiai, o Sierra jį vadina UCP papildančiu protokolu. Protokolo svetainėje nurodyta versija 0.2 ir rašoma, kad „tai juodraštis“. Pačios Meta naujienų skiltyje neradome jokio įrašo apie jį.

Kurio iš jų jums reikia?

Shopify platformoje

Kurti nieko nereikia. Shopify funkcija agentic storefronts „pagal numatytuosius nustatymus aktyvi tinkamoms parduotuvėms“. ChatGPT jūsų katalogą gauna per Shopify Catalog ir siunčia pirkėjus į jūsų parduotuvę. Google tiesioginis atsiskaitymas pagal numatytuosius nustatymus įjungtas parduotuvėms, kurios yra įsikūrusios JAV ir parduoda JAV, o Copilot Shopify prekybininkus įtraukė automatiškai. Jums lieka nuspręsti dėl produktų duomenų ir dėl to, ar palikti tiesioginį atsiskaitymą įjungtą, žinant, kad pasirinktiniai pikseliai (custom pixels) Google atsiskaityme nesuveikia.

Salesforce, commercetools ar kitoje platformoje

Salesforce B2C Commerce 26.9 palaiko UCP 2026-01-23 ir 2026-04-08: /.well-known/ucp su supported_versions žemėlapiu ir atsiskaitymo sesijų galinius taškus, apsaugotus SLAS žetonu. Salesforce nurodo, kad 2026 m. spalį UCP atsiskaitymas Google aplinkoje yra visuotinai prieinamas. Sesija yra headless krepšelio vaizdas, o Salesforce audito vadove įspėjama, kad SFRA ir SiteGenesis valdikliai (controllers) ir „kiti SCAPI ištekliai, kuriuos naudojate šiandien, šiame procese neveikia“, todėl prie jų prijungtą logiką reikia nukopijuoti arba per tarpinį sluoksnį susieti su UCP atsiskaitymo sesijos hook'ais. Sklaidos kanalas turi būti skirtas en-US, o Salesforce „neleidžia apeiti Google laukiančiųjų sąrašo“. ChatGPT atveju Salesforce yra vienas iš kelių, kuriais, pasak OpenAI, galima pateikti ACP sklaidos kanalus.

Jei naudojate commercetools ar kitą platformą, paklauskite tiekėjo, kurias UCP versijas ir galimybes jis palaiko, kurie jūsų hook'ai veikia agento atsiskaitymo metu ir ar jis siunčia sklaidos kanalus į OpenAI.

Jūsų pačių programinėje įrangoje

1. Pirmiausia sklaidos kanalai. Google Merchant Center ir, kai OpenAI jus priims, jos produktų sklaidos kanalas. Būtent tai šiandien ir yra komercinis ACP panaudojimas ChatGPT.
2. UCP Google aplinkai, jei parduodate JAV ir Google jus priima. Kurkite pagal 2026-04-08: profilis su com.google.pay, atsiskaitymo operacijos, atitinkančios Google delsos tikslus, mokėjimų paslaugų teikėjas, apdorojantis Google Pay žetonus, užsakymų webhook ir sklaidos kanalo atributas. Arba pradėkite vien nuo krepšelio perdavimo.
3. ACP atsiskaitymas tik turint priežastį, pavyzdžiui, ChatGPT programėlę, priimtą į mokėjimo lango beta versiją. Kurkite pagal saugyklos 2026-04-17.
4. AP2: kol kas nieko.
5. Vienas atsiskaitymo branduolys. Abu protokolai reikalauja sesijos, kurią galima sukurti, atnaujinti, užbaigti ir atšaukti per API ir saugiai kartoti. Sukurkite ją vieną kartą virš savo užsakymų, mokesčių ir mokėjimų logikos, su plonais ACP ir UCP adapteriais viršuje ir MCP ten, kur jo reikia agentams.

Šiandien nė vienas protokolas nesuteikia prenumeratomis grįstam verslui integruoto atsiskaitymo per agentą.

Jei parduodate tik už JAV ribų

Šiandien nė vienas iš trijų nesuteikia jums atsiskaitymo per agentą. ChatGPT apsipirkimas ir OpenAI standartinis sklaidos kanalo įkėlimas skirti JAV; Google UCP Checkout sąlygos taikomos tik JAV; Copilot Checkout aptarnauja JAV pirkėjus, mokančius doleriais. Kitas paskelbtas Google žingsnis yra Merchant Center UCP centras Australijoje ir Kanadoje „kitų metų pradžioje“, o Jungtinei Karalystei ir ES datos nėra.

Palaikykite išsamų Merchant Center sklaidos kanalą, o jei vis tiek perkuriate atsiskaitymą, kurkite aukščiau aprašytą API valdomą branduolį, kad adapteris būtų nedidelis darbas, kai atsivers jūsų rinka. Parduodate į JAV iš užsienio? Patikrinkite, kur kiekviena programa reikalauja, kad būtų įsisteigęs prekybininkas; pavyzdžiui, Shopify tiesioginiam atsiskaitymui Google aplinkoje reikia JAV parduotuvės.

Kur gauti pagalbos

Kuriame protokolų sluoksnį parduotuvėms, kurios nenaudoja Shopify: /.well-known/ucp profilį ir atsiskaitymo sesijų galinius taškus virš jūsų esamos užsakymų, mokesčių ir mokėjimų logikos, užsakymų webhook'us į Google, produktų sklaidos kanalus Google Merchant Center ir OpenAI bei MCP serverius, kurie tą patį atsiskaitymą atveria agentams. Toks darbas prasideda nuo mūsų DI agentų kūrimo ir MCP integracijos paslaugos.

Rašykite office@c9group.dev, nurodydami savo platformą, mokėjimų paslaugų teikėją ir šalis, kuriose parduodate, ir pasakysime, kuris protokolas jums taikomas ir ko pareikalautų jo įgyvendinimas. Google ir OpenAI programų sąlygos yra sutartys: esame inžinieriai, o ne teisininkai, todėl prieš pasirašydami duokite jas perskaityti patarėjui.