ACP, UCP и AP2: сравнение на протоколите за агентна търговия през октомври 2026 г. и кой от тях е нужен на вашия магазин

Три отворени протокола вече описват как ИИ агент купува от магазин. 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, а плащането в Google е в ранен достъп и само за САЩ. AP2 е на v0.2 и в документацията на нито един продукт на Google не пише, че го използва.

Тази статия е за технически директори (CTO) и водещи разработчици на магазини и платформи за електронна търговия, които решават какво да внедрят. Ако ви интересува какво иска всяка ИИ платформа от магазина като бизнес, започнете с нашия преглед на агентната търговия.

Сравнителна таблица

ACP: Agentic Commerce Protocol

Управление и версии

Хранилището на спецификацията казва, че ACP се поддържа от OpenAI и Stripe, и го обозначава като бета версия. Документът му за управление прави двете компании Founding Maintainers (основатели, които поддържат проекта): те назначават членовете на управляващия комитет (до седем места) и запазват право на вето, което да се използва „в краен случай“. Meta се присъедини на 24 април 2026 г. като трета компания, която води поддръжката (lead maintainer), и като член на комитета. Документацията на Stripe нарича ACP „създаден от Stripe, OpenAI и Meta“, но файлът NOTICE в хранилището посочва само OpenAI и Stripe. Неутрална фондация е само заявен бъдещ път.

Има пет издания с дати: 2025-09-29 (процесът на плащане и делегираното плащане), 2025-12-12 (несъвместими промени, научени от адаптерите за URBN и Etsy), 2026-01-16 (доставчик на 3DS, избран от търговеца), 2026-01-30 (договаряне на възможностите, разширения и несъвместима рамка за payment handlers) и 2026-04-17 (количка, фийд, поръчки, делегирано удостоверяване, откриване и MCP), с което 2026-01-30 беше обявено за остаряло. През шестте месеца оттогава няма ново издание. Папката unreleased/ съдържа по-малки промени с дати до 17 юли, например идентификатор на актуализацията на фийда и незадължителен URL адрес на продукта в артикулите на сесията за плащане.

Какво внедрява търговецът във версия 2026-04-17

API за плащане се хоства от търговеца и се извиква от агента:

• POST /checkout_sessions създава сесия, POST /checkout_sessions/{checkout_session_id} я актуализира (POST, а не PUT), GET на същия път я извлича, а .../complete и .../cancel я приключват.
• Заявките носят API ключ тип Bearer и задължителен хедър 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 в хедър Merchant-Signature. Статусите вървят от created до delivered или canceled, а adjustments[] носи възстановяванията на суми, връщанията, споровете и чарджбековете (chargebacks).

Изданието 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 приеманите методи се декларират като handlers под 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] в предварителна версия (preview) на API; продавач, който използва друг процесор, може еднократно да го преобразува в платежни данни на картовата мрежа. Нашата статия за агентните плащания описва кой носи риска.

Какво промени ходът на 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 и изброяване provider със стойности stripe, adyen и braintree. Изграждайте според хранилището и потвърдете с OpenAI коя версия приема.

Страниците на PSP, които все още представят Instant Checkout като действащ, са остарели.

UCP: Universal Commerce Protocol

Управление и версии

Google пусна UCP на 11 януари 2026 г., разработен съвместно с Shopify, Etsy, Wayfair, Target и Walmart. Правилата за управление дават на Google и Shopify по един постоянен глас в управителния съвет (Governing Council), към който Stripe се присъедини на 28 април 2026 г., и гласят, че до декември 2028 г. „Google държи гласа по пълномощие за всички свободни места“. На 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.*, общите схеми се преместиха и смениха своите URL адреси в $id, а 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 в хедър UCP-Agent, по HTTPS с минимум TLS 1.3. Удостоверяването е по избор на бизнеса: без удостоверяване, X-API-Key, OAuth 2.0, взаимен TLS (mutual TLS) или HTTP Message Signatures по RFC 9421. Google изпраща bearer токен, а въпросите и отговорите на Google предлагат и mTLS. Хедърът Idempotency-Key е само „SHOULD“ (препоръка, а не изискване); сървър, който приема такъв ключ, го пази поне 24 часа и отговаря с 409, когато бъде използван повторно с различно тяло на заявката.

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

Едно ядро за плащане може да обслужва и двата протокола. Една таблица с маршрути не може.

Как работи плащането в UCP

UCP не движи пари. Payment handler е спецификация, написана от доставчик на платежни данни, например com.google.pay за Google Pay или dev.shopify.shop_pay за Shop Pay. Бизнесът изброява handlers, които приема, платформата изпълнява един от тях, а при complete бизнесът получава непрозрачен токен, който таксува чрез своя PSP.

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

Какво изисква Google, преди да извиква вашия API

Ръководството за нативно плащане на Google изисква REST API за плащане и запазва платежната стъпка за себе си: купувачът въвежда чувствителните данни „само чрез интерфейса на Google“. Нивата на обслужване, които Google изисква, са поне 95% достъпност на всяка крайна точка, с латентност (p50 и p95) от 1 и 4 секунди при създаване, 1 и 5 при актуализиране и 6 и 10 при завършване. След поръчка изпращате актуализации на статуса към уебхук на Google с идентификатор на партньора и ключ, издадени при включването. В Merchant Center всеки продукт трябва да има native_commerce(checkout_eligibility) със стойност true („по подразбиране е FALSE“), политиката за връщане и контактът за поддръжка са задължителни, а абонаментите, плащането на вноски, персонализираните, употребяваните и обновените стоки, предварителните поръчки и артикулите с възрастови ограничения са изключени.

По-лекият вариант, достъпен от 2026-04-08, е прехвърлянето на количката: внедрявате само създаването на количка, Google предава количката на вашия сайт и не са нужни нито payment handler, нито уебхук за поръчките.

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

UCP извън Google

Microsoft Merchant Center приема фийдове, готови за UCP, в САЩ от 21 април 2026 г. 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). След като бъде договорено, бизнесът подписва отговорите си за плащането, платформата представя checkout_mandate и payment_mandate при complete, а сесията е „Security Locked“ (заключена от съображения за сигурност): никоя от страните не може да се върне към обикновено плащане.

Никой още не го изисква. Въпросите и отговорите на Google наричат AP2 „особено полезен за бъдещи сценарии, свързани с транзакции на автономни ИИ агенти“. Собственият профил на агента на Google посочва Google Pay като единствен payment handler и не декларира възможност за AP2, а профилът му за 2026-08-25 също няма запис за AP2. Нито един продукт на Google не документира използването на AP2, така че търговецът няма какво да изгражда, докато някоя платформа не започне да го договаря.

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

MCP

ACP и UCP могат да работят върху MCP, чиято текуща спецификация, 2026-07-28, премахва сесиите и хедъра Mcp-Session-Id, отказва се от ръкостискането initialize, изисква server/discover и кара клиента да изпрати заявката отново с нов ID, когато потокът му прекъсне. Обвързването на ACP все още препраща към транспорта от 2025-11-25. Идентификаторът на сесията за плащане е точно онзи идентификатор, издаден от сървъра, който новата спецификация очаква, а 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 казва, че е обявила Personal Agent Protocol („Poppy“) заедно с Meta на 6 октомври 2026 г., а на 9 октомври публикува чернова. Компанията публикува един файл на /.well-known/poppy.json; протоколът използва OAuth, JWT, HTTPS, OpenAPI и MCP, за да позволи на личния агент да се идентифицира и да получи разрешение от клиента за всякакъв вид задача, а Sierra го нарича допълващ UCP. Сайтът на протокола показва версия 0.2 и казва: „Това е чернова“. Не открихме публикация за него в собствения раздел за новини на Meta.

Кой протокол ви е нужен?

В Shopify

Няма какво да изграждате. Агентните витрини (agentic storefronts) на Shopify са „активни по подразбиране за магазините, които отговарят на условията“. ChatGPT получава каталога ви чрез Shopify Catalog и изпраща купувачите към вашия магазин. Директното плащане на Google е включено по подразбиране за магазините, които са установени в САЩ и продават в САЩ, а Copilot автоматично записа търговците в Shopify. Вашите решения са за продуктовите данни и за това дали да оставите директното плащане включено, като знаете, че персонализираните пиксели не се задействат в плащането на 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 изглед на количката, а ръководството за технически одит на Salesforce предупреждава, че контролерите на SFRA и SiteGenesis и „другите ресурси на SCAPI, които използвате днес, не се изпълняват в този поток“, така че логиката, свързана с тях, трябва да се копира или да се прехвърли към хуковете на сесията за плащане по UCP. Фийдът трябва да е насочен към en-US, а Salesforce „не прескача списъка с чакащи на Google“. За ChatGPT Salesforce е един от каналите за доставка, които OpenAI посочва за фийдовете по ACP.

В commercetools или друга платформа попитайте доставчика кои версии и възможности на UCP обслужва, кои от вашите хукове се изпълняват при плащане от агент и дали изпраща фийдове към OpenAI.

На собствен софтуер

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

Нито един от двата протокола днес не дава на абонаментен бизнес нативно плащане от агент.

Ако продавате само извън САЩ

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

Поддържайте фийда си в Merchant Center пълен и ако така или иначе преработвате плащането, изградете описаното по-горе ядро, управлявано през API, така че адаптерът да е малка задача, когато вашият пазар се отвори. Продавате в САЩ от чужбина? Проверете къде всяка програма изисква търговецът да е установен; директното плащане на Google чрез Shopify например изисква магазин в САЩ.

Къде да потърсите помощ

Изграждаме протоколния слой за магазини, които не работят на Shopify: профил на /.well-known/ucp и крайни точки за сесиите за плащане върху вашата съществуваща логика за поръчки, данъци и плащания, уебхукове за поръчките към Google, продуктови фийдове за Google Merchant Center и OpenAI, както и MCP сървъри, които предоставят същото плащане на агентите. Тази работа започва от нашата услуга за разработка на ИИ агенти и интеграция на MCP сървъри.

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