x402 и машинните плащания през 2026 г.: таксуване на ИИ агентите за всяка заявка и колко от това е реално

HTTP има код на състоянието за това от първите дни на уеба. RFC 9110 още го казва ясно: „Кодът на състоянието 402 (Payment Required) е запазен за бъдеща употреба.“ През 2026 г. два протокола се опитват да докарат това бъдеще. x402, започнат от Coinbase и вече воден от проект на Linux Foundation, отговаря на заявка с цена и приема подписано плащане със стейбълкойн при повторния опит. Machine Payments Protocol (MPP) на Stripe и Tempo прави същото чрез хедърите за удостоверяване на HTTP и носи както карти, така и стейбълкойни. AWS и Cloudflare вече продават и двете идеи на edge, така че издател може да таксува ИИ роботите за обхождане, без да докосва своя origin сървър.

Предложението е привлекателно за всеки, който продава данни, API или съдържание, четено от ИИ агенти: таксуване за всяко извикване, уреждане за секунди, без акаунти и без фактури. Числата зад предложението са друга работа. Независимо измерване на x402 в Base установи, че повечето записани уреждания са плащания към самия себе си или движение на пари в един клъстер от портфейли, а компания за анализ на блокчейн оцени обема, който прилича на покупки от агенти, на около USD 5 000 до 11 000 на месец през 2026 г.

Тази статия е за собственици и разработчици на API, услуги за данни и сайтове със съдържание, които решават дали да таксуват агентите сега. Тя обхваща как работят протоколите, какво предлага всеки доставчик към 22 октомври 2026 г., какво бихте изградили, какво показват обемите в действителност и регулаторните въпроси, които идват с държането на стейбълкойни.

Как работи x402

Спецификацията е във версия 2, от 9 декември 2025 г., в хранилище, преместено от Coinbase към x402 Foundation. Тя определя три роли: сървър на ресурса, който иска плащане, клиент (често агент), който плаща, и фасилитатор (facilitator), който „се занимава с проверката на плащането и уреждането в блокчейна“.

Едно платено извикване протича така:

1. Клиентът иска ресурса и получава 402 Payment Required. Хедър PAYMENT-REQUIRED носи обект, кодиран в Base64, който изброява един или повече приемливи начини за плащане, всеки със scheme, network във формата CAIP-2 (eip155:8453 е Base), amount в най-малките единици на токена, asset, адрес payTo и maxTimeoutSeconds.
2. Клиентът подписва плащане и повтаря заявката с хедър PAYMENT-SIGNATURE. В EVM мрежите това е подпис по EIP-712 върху оторизация на превод по EIP-3009 с времеви прозорец и nonce от 32 байта срещу повторно възпроизвеждане.
3. Сървърът кара фасилитатора да провери подписа (POST /verify, който „НЕ ТРЯБВА да фиксира състоянието на плащането“), изпълнява своя обработчик, после кара фасилитатора да уреди плащането (POST /settle).
4. Сървърът отговаря с ресурса и хедър PAYMENT-RESPONSE, който съдържа хеша на транзакцията.

Това е стандартният поток „authorization“: „плащането се проверява, преди ресурсът да бъде изпълнен, и се урежда след това“. Определени са още два потока: единият урежда първо, другият взема депозит и урежда крайната сума след това. Ако уреждането е излъчено, но не е потвърдено, фасилитаторът може да върне settlement_pending с хеша, а сървърът трябва да съгласува състоянието, преди някой да повтори заявката.

Две подробности подвеждат хората. Версия 1, която показват повечето по-стари уроци, ползваше X-PAYMENT и X-PAYMENT-RESPONSE и имена на мрежи като base-sepolia; версия 2 преименува хедърите и мина на CAIP-2. А същите съобщения са определени и върху MCP и протокола Agent-to-Agent (A2A): през MCP един платен инструмент връща резултат с isError: true, а плащането пътува в _meta["x402/payment"].

Четирите схеми за плащане

В EVM мрежите по принцип работи всеки ERC-20 токен, чрез EIP-3009 (методът на USDC) или Permit2. На практика референтните SDK оценяват в долари и свързват "$0.01" със стейбълкойн в USD за всяка мрежа: USDC в Base и повечето EVM мрежи, няколко стейбълкойна в Solana, USDT в TON. Референтният клиент приема само активи, които разпознава, и ограничава всяко плащане до USD 1 по подразбиране. Няма стандартен вариант в евро.

Фасилитатори: кой движи парите

Фасилитаторът е „по желание, но препоръчително“. Той проверява подписите и подава ончейн превода, а документацията казва, че „не държи средства и не действа като попечител“: парите отиват във вашия портфейл payTo.

• Публичният фасилитатор x402.org е само за тестови мрежи. Началното ръководство за продавачи е недвусмислено: „Не използвайте повторно https://x402.org/facilitator за маршрути в mainnet.“
• Хостваният CDP фасилитатор на Coinbase не взема нищо за първите 1 000 ончейн транзакции на месец, после USD 0,001 за всяка, като проверката винаги е безплатна. Той извършва проверки на OFAC и Know Your Transaction за всяко плащане, изисква API ключ за CDP и поддържа Base, Polygon, Arbitrum, Monad, World и Solana. Не изброява auth-capture. Batch settlement разпределя таксата: „една ончейн транзакция може да обработи хиляди плащания“.
• Фондацията изброява други фасилитатори в производство, сред които Fireblocks, Polygon, PayAI, Corbits, Stellar и Celo, и казва, че списъкът „не е изчерпателен каталог“.
• Можете да бъдете свой собствен фасилитатор, като плащате gas таксите и, в Solana, сами изградите откриването на дублирано уреждане, което иначе би предоставил фасилитаторът.

x402 Foundation започна работа на 14 юли 2026 г. с 40 члена. Сред водещите му членове (premier members) са Adyen, AWS, American Express, Cloudflare, Coinbase, Google, Mastercard, Shopify, Stripe и Visa; техническият му управляващ комитет има членове от Coinbase, Cloudflare и Stripe. Членството е подкрепа за управлението, а не внедряване. В съобщението за старта се споменава „поддръжка на видове плащания, от традиционните карти до стейбълкойни“, но спецификацията днес няма binding за карти.

Machine Payments Protocol на Stripe и Tempo

Stripe и Tempo пуснаха MPP на 18 март 2026 г., в деня, в който заработи mainnet на Tempo. Той ползва рамката за удостоверяване на HTTP: 402 с предизвикателство WWW-Authenticate: Payment, удостоверение в Authorization: Payment и хедър Payment-Receipt при успех. Намеренията му са charge (едно плащане), session (стрийминг плащане през канал) и subscription, а платежните му методи в производство са стейбълкойните на Tempo и картовите методи на Stripe. Visa публикува картова спецификация и SDK за MPP в същия ден. Документът в IETF зад него е индивидуален Internet-Draft, който „няма формален статут в процеса на стандартизация на IETF“.

В Stripe MPP приема карти (чрез Shared Payment Tokens) и стейбълкойни, а Stripe приема и плащания със стейбълкойни по x402 в Base, уредени през фасилитатора на Coinbase в депозитен адрес в Stripe. Така или иначе резултатът стига до баланса ви в Stripe като PaymentIntent, а стейбълкойните, изпратени на депозитен адрес, се обменят: „Stripe автоматично обменя тези плащания (offramp) и ги урежда във вашия баланс в Stripe.“ Условията:

• Приемането на стейбълкойни е „достъпно за фирми във всички щати на САЩ, с изключение на Ню Йорк“. Другаде пишете на Stripe, за да поискате достъп, който се разглежда; ЕС, Хонконг, Мексико и Швейцария са в частна предварителна версия.
• Минимумът е USD 0,50 за картово плащане и 0,01 USDC за плащане със стейбълкойн. Сесиите на MPP могат да таксуват на стъпки „чак до 0,000001 USDC“, но се уреждат в цели центове, а остатък под един цент се губи.
• Плащанията със стейбълкойни в Stripe нямат поддръжка на спорове, възстановяванията се връщат като стейбълкойни в първоначалния портфейл, а една транзакция е ограничена до USD 10 000.
• API са предварителни версии (2026-07-29.preview за MPP, 2026-05-27.preview за депозитния адрес на x402).

Intelligent Commerce Connect на Visa, обявен на 8 април 2026 г. в пилотен етап, изброява MPP сред протоколите за агенти, които търговците могат да приемат през него. Не изброява x402.

Таксуване на edge: AWS и Cloudflare

Ако съдържанието или API ви вече стоят зад CDN, edge може да се заеме с таксуването.

AWS WAF AI traffic monetization (обявено на 15 юни 2026 г.) връща на ботове и агенти „машинночетим HTTP отговор 402 Payment Required по отворения протокол x402“ и урежда през фасилитатора на Coinbase в портфейл с USDC, който вие посочвате, в Base или Solana. Функцията няма допълнителна такса, но важат обичайните такси за WAF и Bot Control, и работи само с CloudFront. Можете да оценявате проверените роботи на търсачки различно от непроверените агенти и роботите за обучение, и да тествате, преди да пуснете на живо. Урежда само когато вашият origin върне 2xx и не таксува за 4xx или 5xx. Документацията е откровена за разходите: минимум USD 0,001 на заявка, „няколко секунди допълнително забавяне“ при платените заявки, откриване на ботове, което е „вероятностно“, и предупреждение, че правило Monetize, което не е ограничено до ботове, „на практика ще блокира достъпа на неавтоматизираните клиенти“. „AWS не е страна по потока от средства и не е част от него“, а вие се съгласявате с условията на Coinbase. Уреждането през Stripe и поддръжката на MPP бяха „скоро достъпни“ при обявяването.

Cloudflare pay per crawl е друг модел. Той е в закрита бета версия, домейнът ви трябва да е в Cloudflare, задавате една цена за всички роботи, които таксувате, а Cloudflare „действа като Merchant of Record“ (търговецът, на чието име е продажбата и който отговаря за нея). Роботите се идентифицират с Web Bot Auth и плащат с фактура от Stripe, а не от портфейл. Никога не докосвате стейбълкойни.

Cloudflare Workers могат да поставят прокси за x402 или MPP пред всеки HTTP бекенд, с цена за всеки шаблон на маршрут, и могат да таксуват само заявки с ниска оценка на бот (bot score), така че хората да разглеждат безплатно. Agents SDK има paidTool, който превръща MCP инструмент в платен. Имайте предвид, че примерите на Cloudflare използват ориентирания към тестови мрежи фасилитатор x402.org и имена на мрежи от версия 1; в производство сменете с производствен фасилитатор и идентификатори по CAIP-2.

Колко от това е реално

Заглавните числа са големи и не си съвпадат. Началната страница на x402.org показва 75,41 милиона транзакции и USD 24,24 милиона за последните 30 дни, без дата, източник или метод на страницата. Coinbase казва, че фасилитаторът ѝ е обработил „повече от 100 милиона транзакции и $28 милиона обем на плащанията само в Base и Solana“, без период. Това са броеве на уреждания, и тук е проблемът.

Проучване с измервания от изследователи от City University of Hong Kong, The Chinese University of Hong Kong и Zhejiang University (предпечатна публикация, от 14 юли 2026 г.) разгледа 280 дни на x402 в Base, от 17 септември 2025 г. до 23 юни 2026 г.: 136 708 672 уреждания на стойност USD 44,1 милиона. От тях „21,20% са фиктивни, а 63,78% са вътрешно уреждане в рамките на свързан клъстер“. Стойността, която „доказуемо стига до назовима услуга“, е била USD 187 861,35. От 624 получатели, които някога са получавали плащане, 249 са спечелили поне USD 10, медианният приход за целия им живот е бил USD 3,96, а само 474 от 910 обявени хоста още връщали действащо платежно предизвикателство. Изводът на авторите: „Броят на уредените плащания измерва възможността за изкуственото им създаване, а не приемането.“

TRM Labs, която продава наблюдение на блокчейн, преброи USD 52,7 милиона в 198,9 милиона уреждания в Base, Solana и Polygon от май 2025 г. насам. Около половината отпаднаха след премахване на плащанията към самия себе си, масовите потоци и продавачите с малко купувачи. От останалите USD 25,62 милиона тя оцени, че между 0,6% и 7,5% „изглежда да са агентни“ и че обемът, преместен от агенти, е останал на около USD 5 000 до 11 000 на месец през 2026 г. Нейното заключение за продавачите е полезно: „привличането на трафик от агенти изисква различен дизайн. Той трябва да е машинночетим и да има цена за всяко извикване на крайна точка, която купувачът може да открие, без човек изобщо да види страницата.“

Нищо от това не казва, че идеята е погрешна. Казва, че през октомври 2026 г. крайна точка, която таксува агентите за всяко извикване, трябва да очаква приходи от порядъка на експеримент и да не планира около заглавните броеве.

Кой държи парите и кои правила важат

При x402 плащането отива направо във вашия портфейл. Това означава, че вашата фирма държи ключовете, води USDC в счетоводството си и го обменя в собствената си валута, освен ако доставчик като Stripe не го обменя вместо вас. Проверките на фасилитатора (проверките на OFAC и KYT на Coinbase) се правят от фасилитатора; спецификацията на x402 не определя никакви. Възстановяванията са ваша грижа: exact „не определя възстановяване“, а плащанията със стейбълкойни в Stripe нямат спорове.

Два режима са значими за всеки, който е в потока на средствата.

• Съединените щати: GENIUS Act. Публичен закон 119-27, одобрен на 18 юли 2025 г., влиза в сила 18 месеца след приемането или 120 дни след окончателните наредби, което от двете настъпи по-рано. Предложеното правило на Министерството на финансите на САЩ от 18 август 2026 г. казва, че датата на влизане в сила „се очаква да бъде 18 януари 2027 г.“. От тази дата доставчик на услуги с дигитални активи не може да предоставя в САЩ стейбълкойн на чуждестранен емитент, освен ако емитентът не може да изпълнява законни заповеди. От 18 юли 2028 г. доставчик на услуги с дигитални активи не може да предлага или продава платежен стейбълкойн на лице в САЩ, освен ако не е издаден от разрешен емитент. Законът определя доставчика на услуги с дигитални активи по дейности като обмен, превод или държане на дигитални активи за други лица, извършвани „срещу възнаграждение или печалба“.
• Европейски съюз: MiCA. Преходният период за доставчиците на услуги с крипто активи приключи на 1 юли 2026 г. Позицията на ESMA: „всяко лице, което предоставя услуги с крипто активи на клиенти в ЕС без лиценз по MiCA, нарушава правото на ЕС и трябва да преустанови предлагането на такива услуги“, а фирми извън ЕС не могат да обслужват клиенти от ЕС, „също ... в отношенията между предприятия (business-to-business)“. Стейбълкойните в USD са токени за електронни пари по MiCA. Съветът на ESMA към потребителите е да проверят дали доставчикът е във временния ѝ регистър.

Онова, което нито един от тези източници не урежда, е положението на фирма, която само получава стейбълкойни като плащане за собствения си API или съдържание. Ограниченията на GENIUS Act са писани за доставчици на услуги с дигитални активи, а тези на MiCA за доставчици на услуги с крипто активи; дали вашата уредба ви прави някой от двата вида или зависи от доставчици, които трябва да са такива, е въпрос към юрист във всяка юрисдикция, в която работите. Ние сме инженери, не юристи, и изграждаме според отговора, който даде вашият съветник. На практика попитайте всеки доставчик във веригата ви дали е лицензиран там, където са клиентите ви.

Четири начина да го изградите

От най-малко код към най-много:

1. Оставете CDN да таксува. AWS WAF върху CloudFront: конфигурация за монетизация с вашия портфейл и цените, правила Monetize с обхват върху етикети на ботове, първо тестов режим, без промени в origin. Cloudflare pay per crawl: ако сте в бета версията, цена и настройки за изплащане, като Cloudflare е merchant of record.
2. Оставете доставчик на платежни услуги да таксува. Stripe MPP: профил в Stripe, библиотеката mppx, извикване на charge във вашия обработчик и депозитен адрес в Tempo. Карта и стейбълкойн, уредени във фиатна валута в баланса ви в Stripe. Или x402 в Stripe с акаунт в CDP и депозитен адрес в Base, само със стейбълкойн.
3. Пуснете x402 на собствения си сървър с middleware от SDK за вашата рамка (Express, Hono, Next.js, Fastify; има SDK за Python и Go), хостван фасилитатор и конфигурация на маршрута със схема, цена, мрежа, payTo и описание.
4. Бъдете свой собствен фасилитатор, ако ви трябва пълен контрол или мрежа, която никой не обслужва.

Който път и да изберете, някои решения остават ваши: коя схема отива на работата (exact за фиксирани цени, upto за измервана работа, batch settlement, когато извикванията струват по-малко от gas), кой вижда платената бариера (402, показан на потребител в браузър, е задънена улица), как съгласувате settlement_pending, идемпотентни повторни опити, ако клиентите изпращат идентификатор на плащане, възстановявания, съхранение на портфейла за получаване и как осчетоводявате получените USDC. Агентите също трябва да могат да плащат: клиент на x402 има нужда от портфейл със съответния стейбълкойн в съответната мрежа, клиент на MPP от портфейл в Link или Tempo, робот за pay per crawl от идентичност в Web Bot Auth и платежни отношения със Stripe. Не можете да допускате, че даден агент има нещо от това.

Трябва ли да таксувате агентите сега?

• Продавате API или данни, които агентите вече извикват: експериментът е евтин. Сложете една или две крайни точки зад MPP или x402 до съществуващите ви ключове и планове, оценявайте над минимумите (USD 0,001 при AWS, 0,01 USDC в Stripe) и измервайте кой плаща. Запазете съществуващите платени планове: каналът за плащания от агенти засега ще е малък.
• Публикувате съдържание, което ИИ роботите вече четат: опциите на edge са за това. AWS WAF, ако сте в CloudFront и ви е удобно да държите USDC; Cloudflare pay per crawl, ако сте в Cloudflare, искате картово уреждане и можете да влезете в бета версията. Нито едното не е план за приходи засега; и двете ви дават цена и дневник кой е отказал да я плати.
• Искате агентите да купуват стоки от магазина ви: това не е този проблем. Картовите мрежи, Shared Payment Tokens на Stripe и протоколите за плащане на Google и OpenAI покриват агентите, които купуват от търговци, и ги разглеждаме в статията ни за агентните плащания.

Какво може да се промени

• Началото на GENIUS Act на 18 януари 2027 г. (по-рано, ако окончателните правила излязат първи) и ограничението от 2028 г. след него.
• AWS добавя уреждане през Stripe и MPP, обявено като скоро достъпно.
• Узряването на auth-capture, което би дало на x402 възстановявания извън проектите.
• Internet-Draft на MPP да се придвижи, или не, към работна група на IETF.
• Intelligent Commerce Connect на Visa да излезе отвъд партньорите си от пилотния етап, което би донесло картово финансирани плащания от агенти на повече търговци през MPP.

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

Изграждаме сървърната страна на платения машинен достъп: измерване и ценообразуване за всяка крайна точка, предизвикателства на x402 или MPP пред съществуващи API и MCP инструменти, съгласуване на уредените плащания със системите, които финансовият ви екип вече ползва, и идентифицирането на ботове, което решава кой вижда цена. Нашата услуга за разработка на ИИ агенти и интеграция на MCP сървъри е мястото, откъдето тази работа започва.

Ако преценявате дали да таксувате агентите за вашия API или съдържание и през кой доставчик, пишете на office@c9group.dev.