ACP, UCP и AP2 во споредба: протоколите за агентска трговија во октомври 2026 и кој ѝ треба на вашата продавница

Три отворени протоколи денес опишуваат како AI-агент купува од продавница. Agentic Commerce Protocol (ACP) доаѓа од OpenAI и Stripe. Universal Commerce Protocol (UCP) доаѓа од Google и Shopify. Agent Payments Protocol (AP2), кој го започна Google и во април го предаде на FIDO Alliance, воопшто не е протокол за наплата (checkout): тој дефинира потпишан доказ дека корисникот овластил плаќање и е замислен да работи внатре во UCP. Сите три се под лиценцата Apache 2.0.

На 22 октомври 2026 година тие се во многу различна состојба. ACP е означен како бета-верзија, неговото последно издание е 2026-04-17, а од 17 јули во него не е внесена ниту една измена. ChatGPT, неговиот главен корисник, во март се откажа од самостојната наплата и сега ACP го користи главно за да прима податоци за производите. UCP во август објави верзија со некомпатибилни промени, 2026-08-25, додека сопствените сервиси на Google сè уште работат на 2026-04-08, а неговата наплата е во ран пристап, само во САД. AP2 е на верзија v0.2, и ниту еден производ на Google не документира дека го користи.

Оваа статија е за техничките директори (CTO) и водечките развивачи на продавници и платформи за е-трговија што одлучуваат што да имплементираат. За тоа што секоја AI-платформа бара од продавницата како бизнис, започнете со нашиот преглед на агентската трговија.

Паралелен преглед

ACP: Agentic Commerce Protocol

Управување и верзии

Репозиториумот со спецификацијата наведува дека ACP го одржуваат OpenAI и Stripe и го означува како бета-верзија. Неговиот документ за управување ги прави двете компании Founding Maintainers: тие ги назначуваат членовите на раководниот комитет (до седум) и задржуваат вето што се користи „како последно средство“. Meta се приклучи како трет главен одржувач и член на комитетот на 24 април 2026 година. Документацијата на Stripe вели дека ACP е „создаден од Stripe, OpenAI и Meta“, но датотеката notice во репозиториумот ги наведува само OpenAI и Stripe. Неутрална фондација засега е само наведена како иден пат.

Постојат пет изданија со датум: 2025-09-29 (наплата и делегирано плаќање), 2025-12-12 (некомпатибилни промени според искуствата од адаптерите на URBN и Etsy), 2026-01-16 (давател на 3DS по избор на трговецот), 2026-01-30 (договарање на можностите, проширувања и некомпатибилна рамка за payment handler-и) и 2026-04-17 (кошничка, фид, нарачки, делегирана автентикација, откривање и MCP), со кое 2026-01-30 е прогласено за застарено. Во шесте месеци оттогаш не е објавено ништо. Папката unreleased/ содржи помали промени со датуми до 17 јули, како ID за ажурирање на фидот и незадолжителна URL-адреса на производот во ставките на наплатата.

Што имплементира трговецот во 2026-04-17

API-то за наплата го хостира трговецот, а го повикува агентот:

• POST /checkout_sessions создава сесија, POST /checkout_sessions/{checkout_session_id} ја ажурира (POST, не PUT), GET на истата патека ја враќа, а .../complete и .../cancel ја завршуваат.
• Барањата носат API-клуч од типот bearer и задолжителен header API-Version. Од 2026-04-17 Idempotency-Key е задолжителен на секое POST-барање, со дефинирани грешки: 400 idempotency_key_required, 409 idempotency_in_flight и 422 idempotency_conflict.
• Барањето за создавање носи објект capabilities. Агентот изјавува што поддржува, а трговецот го враќа пресекот, па некомпатибилноста се покажува пред плаќањето.
• Трговецот испраќа настани за нарачките со POST до приемник што го хостира OpenAI на /agentic_checkout/webhooks/order_events, потпишани со HMAC-SHA256 во header-от Merchant-Signature. Статусите одат од created до delivered или canceled, а adjustments[] носи поврат на средства, враќања, спорови и chargeback-ови.

Изданието 2026-04-17 додаде и статична, јавна датотека /.well-known/acp.json, чие поле transports кажува дали продавницата зборува rest, mcp или и двете. Додаде врзување (binding) за MCP преку Streamable HTTP со пет алатки (create_checkout_session, get_checkout_session, update_checkout_session, complete_checkout_session, cancel_checkout_session), со автентикација во конфигурацијата на серверот, а не во секое барање. Додаде и Feed API што го хостира агентот, а на кое трговецот праќа податоци (POST /feeds, PATCH /feeds/{id}/products), кошничка за еден продавач без податоци за плаќање (POST /carts, PUT /carts/{id}) и делегирана 3DS2-автентикација (POST /delegate_authentication). Претплати нема: RFC-то за проширувањата го наведува subscription како „поддршка за повторувачко наплаќање (во иднина)“.

Како функционира плаќањето во ACP

Првобитниот одговор на ACP е делегираното плаќање. PSP-от или трезорот за картички (card vault) ја имплементира POST /agentic_commerce/delegate_payment, која картичката (единствениот тип на податоци за плаќање) ја претвора во токен што PSP-от на трговецот смее да го користи само во рамките на дозволен лимит: reason (само one_time), max_amount, currency, checkout_session_id, merchant_id и expires_at. Со зборовите на RFC-то: „Плаќањата, порамнувањето и усогласеноста остануваат на инфраструктурата на трговецот.“ Worldpay документира сопствена верзија на овој повик, а PayPal го поддржува ACP преку делегирани токени во Braintree.

Од 2026-01-30 прифатените начини на плаќање се изјавуваат како handler-и под capabilities.payment.handlers. Примерот за податоци за плаќање од дневникот на промени (changelog):

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

spt е Shared Payment Token на Stripe, достапен „во САД, Канада и одбрани европски земји“. Трговец на Stripe го наплаќа со payment_method_data[shared_payment_granted_token] на API-верзија во preview; трговец што работи со друг процесор може еднаш да го претвори во мрежни податоци за плаќање. Нашата статија за агентските плаќања објаснува кој го носи ризикот.

Што промени потегот на OpenAI во март

На 24 март 2026 година OpenAI напиша дека „почетната верзија на Instant Checkout не го нудеше нивото на флексибилност кон кое се стремиме“, им дозволи на трговците да ги користат сопствените решенија за наплата и изјави дека „го проширува ACP за да биде поврзувачкиот слој меѓу трговците и корисниците низ целото откривање производи.“ Target, Sephora, Nordstrom, Lowe's, Best Buy, The Home Depot и Wayfair го интегрираа ACP за откривање, а каталозите на Shopify пристигнуваат преку Shopify Catalog. Што значи тоа за развивачот:

• Фидот е делот што е активен. Страницата за трговци на OpenAI вели дека купувањата „се завршуваат на веб-сајтови или апликации во сопственост на трговците“ и дека купувањето е активно за корисниците во САД. Вклучувањето на фидови е за одобрени партнери од листата на чекање: дневна целосна датотека преку SFTP со девет задолжителни полиња, ажурирања преку API во текот на денот, промоции само преку API. Стандардното прикачување „моментално е насочено кон САД“.
• Наплатата бара посебно одобрение. Спецификацијата на фидот вели дека наплатата „бара посебно овозможена интеграција“. За апликациите во ChatGPT, општо достапниот пат е надворешна наплата на сопствениот домен на развивачот. Платежниот прозорец во самиот разговор е приватна бета-верзија „ограничена на одбрани маркетплејси“, која му предава токен за плаќање на MCP-серверот на апликацијата во повик на алатката complete_checkout.
• Страниците на OpenAI заостануваат зад спецификацијата. Неговата референца за наплатата сè уште прикажува API-Version 2025-09-12 и enum provider со stripe, adyen и braintree. Градете според репозиториумот и потврдете со OpenAI која верзија ја прифаќа.

Страниците на PSP-и што сè уште го претставуваат Instant Checkout како активен се застарени.

UCP: Universal Commerce Protocol

Управување и верзии

Google го лансираше UCP на 11 јануари 2026 година, развиен заедно со Shopify, Etsy, Wayfair, Target и Walmart. Правилата за управување им даваат на Google и Shopify по еден траен глас во Управниот совет, на кој Stripe се приклучи на 28 април 2026 година, и наведуваат дека „Google има полномошен глас за сите слободни места до декември 2028“. На 24 април Shopping Tech Council се зголеми на 16 места, со Amazon, Meta, Microsoft, Salesforce и Stripe, па Meta и Stripe сега седат и во комитетот на ACP и во советот на UCP.

Репозиториумот има четири изданија. 2026-04-08 додаде можности за кошничка и каталог, потпишување на барањата и одговорите и Get Order. 2026-08-25 носи некомпатибилни промени: signing_keys[] отстапи место на JWK Set во keys[], проширувањата за плаќање се преместија од dev.ucp.shopping.* во dev.ucp.common.payment.*, заедничките шеми се преместија и ги сменија своите $id URL-адреси, а PAN и мрежните токени станаа посебни типови на податоци за плаќање. Додаде и 3DS2 независен од добавувачот, поделени плаќања, услови за плаќање и интероперабилност со Web Bot Auth.

Тука е замката. Водичот за профилот на Google ги опфаќа само 2026-04-08 и 2026-01-23, сопствениот профил на агентот на Google на ucp.goog изјавува "version": "2026-04-08", а Salesforce B2C Commerce 26.9 ги служи истите две верзии. Checkout MCP на Shopify, пак, упатува на 2026-08-25. Ако градите според последното издание, градите верзија што Google не ја документира. Одговорот на спецификацијата е објектот supported_versions, кој секоја постара верзија ја поврзува со сопствено URI на профилот.

Откривање, транспорт и автентикација

Секој бизнис објавува профил на /.well-known/ucp со ucp.version, ucp.services и ucp.payment_handlers, а Google бара тој да биде јавен и достапен без автентикација. Платформата на агентот исто така објавува свој профил, а секое барање го носи неговото URI во header-от UCP-Agent, преку HTTPS со најмалку TLS 1.3. Автентикацијата е по избор на бизнисот: никаква, X-API-Key, OAuth 2.0, взаемен TLS или HTTP Message Signatures според RFC 9421. Google праќа bearer-токен, а неговите најчести прашања нудат и mTLS. Idempotency-Key е само „SHOULD“ (препорака, не обврска); серверот што го прифаќа го чува најмалку 24 часа и одговара со 409 кога клучот ќе се употреби повторно со различно тело на барањето.

REST е основниот транспорт, покрај MCP, проширување за A2A и вграден режим до кој се стигнува преку continue_url. Нарачките се GET /orders/{id} плус webhook од бизнисот кон платформата, потпишан според RFC 9421. Патеките за кошничката се исти како кај ACP. Операциите за наплата изгледаат слично, но не се заменливи:

Едно јадро за наплата може да ги опслужува двата протокола. Една табела со рути не може.

Како функционира плаќањето во UCP

UCP не пренесува пари. Payment handler е спецификација што ја пишува давател на податоци за плаќање, како com.google.pay за Google Pay или dev.shopify.shop_pay за Shop Pay. Бизнисот ги наведува handler-ите што ги прифаќа, платформата извршува еден од нив, а при complete бизнисот добива непроѕирен токен што го наплаќа преку сопствениот PSP.

Во сервисите на Google единствениот handler е Google Pay, PAN_ONLY е единствениот метод на автентикација што се користи, а вашиот PSP „мора да може да ги обработува нашите токени“. Stripe објавува com.stripe.payments за картички и Apple Pay: „Агентот испраќа shared payment token (SPT) во барањето Complete Checkout, а трговецот го наплаќа.“ Google Pay останува на сопствениот handler. PayPal го прифаќа handler-от за Google Pay преку Braintree или преку својот Orders v2 API.

Што бара Google пред да ве повика

Водичот за нативна наплата на Google бара REST API за наплата, а чекорот на плаќање го задржува кај себе: купувачот ги внесува чувствителните податоци „само во интерфејсот на Google“. Нивоата на услуга се најмалку 95% достапност на секоја крајна точка, со латенција p50 и p95 од 1 и 4 секунди за создавање, 1 и 5 за ажурирање и 6 и 10 за завршување. По нарачката, испраќате ажурирања на статусот до webhook на Google, со ID на партнер и клуч што се издаваат при вклучувањето. Во Merchant Center, секој производ треба да има native_commerce(checkout_eligibility) поставено на true („стандардно има вредност FALSE“), политиката за враќање и контактот за поддршка се задолжителни, а претплатите, плаќањето на рати, персонализираните, користените и обновените производи, нарачките однапред и производите со старосно ограничување се исклучени.

Полесната опција, од 2026-04-08, е префрлањето на кошничката (cart transfer): имплементирате само создавање кошничка, Google ја предава кошничката на вашиот сајт, и не ви треба ни payment handler ни webhook за нарачките.

Пристапот е вистинското ограничување. Наплатата е „достапна за одбрани трговци“ преку формулар за интерес за ран пристап, во кој се обврзувате да започнете во рок од 30 дена и прифаќате дека пристапот „може да биде отстранет“ ако не напредувате. Условите за UCP Checkout се однесуваат „само на Соединетите Држави“. Хабот во Merchant Center треба да следи во Австралија и Канада „на почетокот на следната година“; Google не дава датум за наплатата за ниту една друга земја.

UCP надвор од Google

Microsoft Merchant Center од 21 април 2026 година прифаќа фидови подготвени за UCP во САД. Copilot Checkout бара фид усогласен со UCP, прима трговци што работат на англиски јазик и продаваат на купувачи во САД во долари, со по еден PSP, а поставката на продавницата е означена со „пилот само за одбрани клиенти“. Shopify го изложува UCP преку MCP на https://{shop}/api/ucp/mcp и ги отстрани своите постари алатки за каталог и кошничка. Можноста за резервирање сместување беше споена како нацрт на 24 септември 2026 година и не е во ниту едно издание.

AP2: Agent Payments Protocol

AP2 не е трет начин за наплата. Неговата спецификација вели дека „работи како безбедносна функција во рамките на протокол за трговија“ и дека е „изрично замислен да биде компатибилен со Universal Commerce Protocol (UCP)“. Верзијата 0.1.0 излезе на 16 септември 2025 година, а v0.2 на 28 април 2026 година, денот кога Google го донираше AP2 на FIDO Alliance. Соопштението на FIDO именува работна група Agentic Authentication и работна група Payments, со претседавачи од Mastercard и Visa, и вели дека придонесите „ќе бидат разгледани и дополнително развиени“. FIDO нема објавено спецификација за AP2. Репозиториумот на GitHub сега прима само примери и промени во SDK-то, а последната измена во него е од 29 април.

Верзијата 0.2 дефинира Checkout Mandate (што се купува) и Payment Mandate (плаќањето, со ограничувања како payment.amount_range, payment.budget и payment.allowed_payees). Секој од нив е SD-JWT во затворена и во отворена форма (на пример, mandate.payment.1 и mandate.payment.open.1). Во режимот Human Present (корисникот е присутен) корисникот ги одобрува затворените мандати. Во режимот Human Not Present (корисникот не е присутен) корисникот одобрува отворени мандати што поставуваат ограничувања и го носат јавниот клуч на агентот во claim-от cnf, а агентот ги составува затворените мандати во рамките на тие ограничувања. Упатствата за Intent Mandate и Cart Mandate ја опишуваат v0.1; тие поими ги нема во v0.2.

Во рамките на UCP, AP2 е проширувањето dev.ucp.common.payment.ap2_mandate (dev.ucp.shopping.ap2_mandate пред 2026-08-25). Штом ќе се договори, бизнисот ги потпишува своите одговори за наплатата, платформата при complete поднесува checkout_mandate и payment_mandate, а сесијата е „Security Locked“ (безбедносно заклучена): ниедна страна не смее да се врати на обична наплата.

Никој сè уште не го бара. Најчестите прашања на Google го нарекуваат AP2 „особено корисен за идни сценарија со автономни трансакции на AI-агенти“. Сопствениот профил на агентот на Google го наведува Google Pay како единствен payment handler и не изјавува можност за AP2, а ниту неговиот профил за 2026-08-25 нема ставка за AP2. Ниту еден производ на Google не документира користење на AP2, па трговецот нема што да гради додека некоја платформа не почне да го договара.

Соседните протоколи

MCP

ACP и UCP можат да работат преку MCP, чија тековна спецификација, 2026-07-28, ги отстранува сесиите и header-от Mcp-Session-Id, го укинува воведното ракување initialize, бара server/discover и налага клиентот повторно да го испрати барањето со нов ID кога ќе му се прекине стримот. Врзувањето на ACP сè уште упатува на транспортот од 2025-11-25. ID-то на сесијата на наплата е токму идентификаторот што го создава серверот, каков што очекува новата спецификација, а complete изгубен среде стримот се враќа како ново барање: третирајте ги клучевите за идемпотентност како задолжителни во двата протокола.

WebMCP

WebMCP е предложен веб-стандард со кој страницата ги изложува сопствените функции пред агентите во прелистувачот. Shopify нуди UCP-наплата и како Checkout MCP и како Checkout WebMCP, со ист објект за наплата, и препорачува Checkout MCP. Нашиот водич за WebMCP го опишува неговиот статус.

x402 и MPP

x402 и Machine Payments Protocol, дизајниран од Tempo и Stripe, му наплаќаат на агентот за секое HTTP-барање за API, податоци или содржина. Тие не се протоколи за наплата во продавница. Видете ја нашата статија за x402.

Visa Trusted Agent Protocol и Mastercard Agent Pay

Тие стојат покрај ACP и UCP, а не наместо нив. Trusted Agent Protocol на Visa му дава на агентот „стандардизиран, криптографски метод“ да ги докаже пред трговците својот идентитет и овластување, а Mastercard Agent Pay е програма за токенизација за агентска трговија. Водичот за трговци на Mastercard ги става UCP и ACP на своето највисоко ниво на подготвеност, забележува дека „раните корисници моментално ги интегрираат“ и им препорачува на трговците да започнат со двете поедноставни нивоа. Нашата статија за агентските плаќања ги опфаќа двете програми.

Personal Agent Protocol

Sierra вели дека на 6 октомври 2026 година заедно со Meta го најавила Personal Agent Protocol („Poppy“), а на 9 октомври објави нацрт. Компанијата објавува една датотека на /.well-known/poppy.json; протоколот користи OAuth, JWT, HTTPS, OpenAPI и MCP за личниот агент да може да се идентификува и да добие дозвола од клиентот за каква било задача, а Sierra го нарекува комплементарен на UCP. Сајтот на протоколот прикажува верзија 0.2 и вели: „Ова е нацрт“. Не најдовме објава за него во сопствениот центар за вести на Meta.

Кој ви треба?

На Shopify

Нема ништо за градење. Агентските продавници на Shopify се „стандардно активни за продавниците што ги исполнуваат условите“. ChatGPT го добива вашиот каталог преку Shopify Catalog и ги праќа купувачите во вашата продавница. Директната наплата на Google е стандардно вклучена за продавниците со седиште во САД што продаваат во САД, а Copilot автоматски ги вклучи трговците на Shopify. Вашите одлуки се податоците за производите и дали директната наплата ќе остане вклучена, знаејќи дека прилагодените пиксели (custom pixels) не се активираат во наплатата на Google.

На Salesforce, commercetools или друга платформа

Salesforce B2C Commerce 26.9 го служи UCP во верзиите 2026-01-23 и 2026-04-08: /.well-known/ucp со мапа supported_versions и крајните точки за сесии на наплата зад SLAS-токен. Salesforce ја наведува UCP-наплатата на Google како општо достапна во октомври 2026 година. Сесијата е headless-приказ на кошничката (basket), а водичот за ревизија на Salesforce предупредува дека контролерите на SFRA и SiteGenesis и „другите SCAPI-ресурси што ги користите денес не се извршуваат во овој тек“, па логиката поврзана со нив мора да се копира или да се премости кон hook-овите на сесиите на наплата на UCP. Фидот мора да биде насочен кон en-US, а Salesforce „не ја прескокнува листата на чекање на Google“. За ChatGPT, Salesforce е еден од патиштата за доставување што OpenAI ги именува за фидовите на ACP.

На commercetools или друга платформа, прашајте го добавувачот кои верзии и можности на UCP ги служи, кои од вашите hook-ови се извршуваат при агентска наплата и дали испраќа фидови до OpenAI.

На сопствен софтвер

1. Прво фидовите. Google Merchant Center и, штом OpenAI ќе ве прими, неговиот фид за производи. Комерцијалната употреба на ACP во ChatGPT денес е токму ова.
2. UCP за Google, ако продавате во САД и Google ве прими. Градете според 2026-04-08: профилот со com.google.pay, операциите за наплата во рамките на целните латенции на Google, PSP што ги обработува токените на Google Pay, webhook-от за нарачките и атрибутот во фидот. Или започнете само со префрлањето на кошничката.
3. Наплата преку ACP само ако имате причина, на пример апликација во ChatGPT примена во бета-верзијата на платежниот прозорец. Градете според 2026-04-17 од репозиториумот.
4. AP2: засега ништо.
5. Едно јадро за наплата. Двата протокола бараат сесија што може да се создаде, ажурира, заврши и откаже преку API и безбедно да се повтори. Изградете ја еднаш врз вашата логика за нарачки, даноци и плаќања, со тенки адаптери за ACP и UCP над неа и MCP таму каде што им треба на агентите.

Ниту еден од двата протокола денес не ѝ дава на дејност заснована на претплати нативна агентска наплата.

Продажба само надвор од САД

Ниту еден од трите денес не ви дава агентска наплата. Купувањето во ChatGPT и стандардното прикачување фидови на OpenAI се за САД; условите за UCP Checkout на Google важат само за САД; Copilot Checkout ги опслужува купувачите во САД во долари. Следниот најавен чекор на Google е хабот во Merchant Center во Австралија и Канада „на почетокот на следната година“, без датум за Обединетото Кралство или ЕУ.

Одржувајте го фидот во Merchant Center целосен, а ако и онака ја преправате наплатата, изградете го јадрото управувано преку API опишано погоре, за адаптерот да биде мала работа кога ќе се отвори вашиот пазар. Продавате во САД од странство? Проверете каде секоја програма бара да биде седиштето на трговецот; директната наплата на Google преку Shopify, на пример, бара продавница во САД.

Каде да побарате помош

Го градиме протоколскиот слој за продавници што не работат на Shopify: профил /.well-known/ucp и крајни точки за сесии на наплата врз вашата постојна логика за нарачки, даноци и плаќања, webhook-ови за нарачките кон Google, фидови за производи за Google Merchant Center и OpenAI и MCP-сервери што истата наплата ја изложуваат пред агентите. Нашата услуга за развој на AI-агенти и интеграција со MCP е местото каде што започнува таа работа.

Пишете ни на office@c9group.dev, со вашата платформа, вашиот давател на платежни услуги и земјите во кои продавате, и ќе ви кажеме кој протокол важи за вас и што би барала неговата имплементација. Условите на програмите на Google и OpenAI се договори: ние сме инженери, не правници, па дајте ги на советник да ги прочита пред да потпишете.