# Agent Payments Protocol для платежей продавца > Разбираем, как Agent Payments Protocol защищает покупки агентов, что доказывают мандаты, кто поддерживает AP2 и что нужно внедрить продавцу. Agent Payments Protocol дает ИИ-агенту для покупок доказательство того, что он вправе купить товар и оплатить его. Протокол не дает продавцу каталог, API оформления заказа, правила борьбы с мошенничеством, платежный процессинг или освобождение от норм защиты потребителей. Эта граница важнее любой схемы протокола. Продавец, который воспринимает AP2 как еще один способ оплаты, построит неверную интеграцию. Если же считать его слоем авторизации и доказательств, его можно подключить к существующему процессу торговли, проверить без движения реальных денег и понять, оправдывают ли автономные покупки затраты. Текущая публичная спецификация называется AP2 v0.2 и использует два связанных мандата, Checkout и Payment, в открытой и закрытой формах. В материалах первого анонса и ранних примерах встречаются термины Intent, Cart и Payment Mandate, поэтому перед копированием схемы или названия типа проверяйте версию. ## AP2 авторизует агента, но не весь процесс покупки AP2 отвечает на вопросы, кто разрешил агенту выполнить конкретное действие, в каких пределах и для какой итоговой транзакции. Обычный интернет-платеж предполагает, что человек смотрит на страницу продавца и нажимает кнопку покупки. Агент может найти товар в одной системе, договориться с агентом продавца, получить платежные данные в другом месте и провести операцию, когда пользователь уже вышел. Существующие платежные системы переведут деньги, но стандартный запрос не докажет, что агент соблюдал поручение пользователя. Протокол добавляет подписанные и защищенные от незаметного изменения записи, которые называются мандатами. Checkout Mandate описывает, что агенту разрешено купить. Payment Mandate описывает, как можно оплатить получившийся заказ. Криптографические ссылки связывают записи с оформленным продавцом заказом и друг с другом. Поэтому участники могут обнаружить подмену, а не полагаться на переписку или рассказ агента о своих действиях. Квитанции сохраняют результат. Область AP2 уже, чем можно подумать по многим описаниям. Протокол не стандартизирует поиск товаров, остатки, расчет доставки и налогов, возвраты или управление заказом. Спецификация v0.2 говорит, что он работает как защитная функция внутри торгового протокола. Он явно совместим с Universal Commerce Protocol, или UCP, но AP2 можно встроить и в другую торговую систему, если она реализует недостающий жизненный цикл. A2A или MCP могут передавать сообщения между программными компонентами, однако ни один из них сам по себе не превращает корзину в авторизованный платеж. При разборе архитектуры я провожу простую границу: состояние оформления заказа показывает, что продавец готов продать, а мандат показывает полномочия, которые может предъявить агент. Если смешать эти сущности, вероятностный вывод агента попадет в детерминированную авторизацию. Пусть агент свободно рассуждает о товарах. Обычный код должен проверять подписи, хеши, срок действия, адресата, ограничения и текущее состояние заказа. Спецификация требует, чтобы проверка и обработка выполнялись детерминированным кодом, даже если сама роль использует LLM. ## Пять ролей разделяют границу доверия AP2 v0.2 определяет пять ролей, причем одна реальная компания может выполнять несколько. Такое разделение назначает обязанности по проверке, а не заставляет привлекать пять поставщиков к каждому платежу. - Shopping Agent находит товары, собирает данные заказа, выбирает платежный инструмент и получает мандаты. - Merchant отвечает за целостность каталога и заказа, подписывает заказ, проверяет Checkout Mandate и исполняет заказ. - Credential Provider управляет доступом к платежным данным и ограничивает платежные данные или токен рамками разрешенной транзакции. - Merchant Payment Processor проверяет Payment Mandate и проводит либо подтверждает платеж. - Trusted Surface показывает пользователю условия авторизации, получает осознанное согласие и подтверждение личности, а затем создает подписанные пользователем мандаты. Trusted Surface должен работать без агента. В демонстрации это требование легко проигнорировать, а позже исправление обойдется дорого. Если одна и та же LLM толкует запрос и решает, что показать на экране согласия, независимой контрольной точки нет. Доверенная поверхность должна детерминированно отображать содержимое мандата, ясно показывать сумму и условия, при необходимости заново подтверждать личность пользователя и защищать ключи подписи. Credential Provider не сводится к API хранилища. Он должен проверить право агента использовать платежный инструмент, оценить Payment Mandate и вернуть платежные данные, ограниченные конкретной транзакцией. Передача номера карты многократного использования агенту для покупок разрушает разделение, ради которого создавался AP2. В рекомендациях протокола по безопасности сказано, что платежные данные или токен должны попасть к продавцу только после проверки окончательного Payment Mandate. Совмещение ролей меняет эксплуатацию, но не обязанности. Если продавец сам выполняет функции платежного процессора, ему все равно нужны отдельные проверки полномочий на заказ и на оплату. Если поставщик агента владеет доверенной поверхностью, ее неагентский путь согласия по-прежнему требует изолированных ключей, контролируемых выпусков и модели угроз, где агент для покупок считается враждебным. AP2 прямо исходит из того, что надежно предотвратить внедрение инструкций в запрос невозможно, и считает агентов и LLM потенциальными нарушителями. Это верное допущение. ## При участии человека подписываются итоговые условия В сценарии с участием человека пользователь подтверждает готовый заказ и платеж, пока остается в сессии. Для пользователя это похоже на обычное оформление заказа, но подписи делают сведения об участии и полномочиях агента переносимыми между всеми сторонами. Сначала агент для покупок собирает корзину вместе с продавцом. Продавец создает подписанный заказ с окончательными товарами, ценами, условиями доставки и другими данными торговой системы. Агент получает подходящие варианты платежных инструментов от Credential Provider. Затем он формирует содержимое закрытых Checkout Mandate и Payment Mandate и отправляет оба объекта в Trusted Surface. Trusted Surface показывает фактическое содержимое, а не текстовый пересказ агента. После подтверждения личности и согласия пользователя поверхность подписывает мандаты. Хеш подписанного продавцом заказа навсегда связывает авторизацию с этим заказом. Агент предъявляет Payment Mandate поставщику платежных данных, получает токен для конкретной транзакции и отправляет продавцу Checkout Mandate вместе с токеном. Продавец и процессор проверяют каждый свое доказательство до исполнения заказа, а потом выпускают квитанции. Типичная ошибка возникает, когда продавец пересчитывает налог или доставку после согласия. Теперь итог заказа равен $214.80, хотя мандат охватывает подписанный заказ на $199.00. Слишком терпимая интеграция сверяет только идентификатор заказа, принимает токен и незаметно списывает новую сумму. Правильная интеграция считает любое существенное изменение заказа новым событием авторизации. Она создает новый подписанный заказ и получает новые закрытые мандаты. Несовпадение хеша требует остановки, его нельзя перехватить и проигнорировать ради удобства. Обычные платежные проверки никуда не исчезают. Эмитент, процессор, поставщик платежных данных или продавец может запросить знакомый этап, например 3DS. Пользователь должен пройти его на доверенной поверхности. AP2 переносит доказательства действий агента, но не отменяет контроль рисков эмитента и не гарантирует одобрение. Для отказов, тайм-аутов и незавершенных проверок нужны обычные переходы состояний и идемпотентные повторы. ## Автономная покупка начинается с открытых ограничений В сценарии без участия человека пользователь заранее разрешает действия в определенных границах, пока конкретный товар, сумма или время исполнения еще неизвестны. Позже агент закрывает эти мандаты для конкретного заказа. Именно это отличает AP2 от обычной подписанной кнопки покупки. Представим основателя компании, который просит агента купить один возвратный билет экономкласса в указанный город, на разрешенные даты, не дороже заданной общей суммы и с помощью корпоративного платежного инструмента. Trusted Surface превращает эти условия в открытые Checkout Mandate и Payment Mandate и получает аутентифицированную подпись пользователя. Открытый Checkout Mandate может ограничивать список продавцов и допустимых позиций. Открытый Payment Mandate может ограничивать получателя, платежный инструмент, диапазон суммы, общий бюджет, повторяемость, дату исполнения и связь с полномочием на заказ. Найдя подходящий вариант, агент получает подписанный продавцом заказ и создает закрытые мандаты, связанные с открытыми. Агент подписывает закрытое представление ключом, который указан в открытом мандате. Детерминированные проверяющие компоненты проверяют исходную подпись пользователя, привязку ключа агента, избирательно раскрытые поля, срок действия, связь между открытым и закрытым объектами, хеш заказа продавца и каждое раскрытое ограничение. Credential Provider выдает ограниченный токен только после успешного прохождения всех проверок. Открытый мандат не разрешает импровизировать. Текстовый запрос может помогать агенту искать, но принудительно применяемые правила должны сводиться к полям, которые проверяет машина. Фраза «приличный отель рядом с площадкой» не может стать правилом авторизации, пока продукт не определит критерии и источник этих сведений. Там, где могут уйти деньги, используйте точные идентификаторы продавца и товара, количество, валюту, максимальную сумму, даты, условия возврата и предел повторений. Если условие нельзя оценить детерминированно, верните пользователя в процесс. Продавец или Credential Provider может отклонить неразрешенное ограничение и перевести автономный сценарий в режим подтверждения человеком. Продуктовые команды иногда считают это сбоем из-за дополнительного трения. На деле это предохранитель. Хуже, если агент выдумывает уверенность ради красивого графика конверсии. Спроектируйте возврат пользователя до автономной демонстрации: учтите истечение срока, изменение цены, отсутствие товара и проверку на втором устройстве. ## Мандаты дают доказательства, но не иммунитет Подписанные мандаты проясняют ответственность, потому что каждый участник проверяет структурированную запись, а не гадает, правильно ли модель поняла пользователя. Они сами по себе не определяют юридическую ответственность, не предотвращают любой повтор и не доказывают доставку товара. Текущая спецификация связывает закрытый Checkout Mandate с подписанным продавцом заказом через `checkout_hash`. Закрытый Payment Mandate ссылается на связанный заказ через идентификатор транзакции, а открытый Payment Mandate использует ограничение-ссылку. В открытых мандатах содержится ключ подтверждения агента, а закрытые представления связываются с открытым разрешением. Избирательное раскрытие позволяет каждому участнику получить только необходимые для его роли утверждения, не открывая весь разговор о покупке или исходные платежные данные. Эти доказательства помогают при споре: продавец показывает подписанный им заказ, Credential Provider показывает, какой ограниченный платеж он разрешил, а пользователь может оспорить транзакцию за пределами мандата. Кто понесет убыток, по-прежнему определяют правила платежной сети, договоры, защита потребителей, процедуры карточных систем и местное законодательство. AP2 дает этим системам более точные факты. Он не пишет их правила. Контроль повторов требует отдельного состояния, даже если подписи действительны. Действующее открытое разрешение может позволять одну покупку, несколько покупок или расходование бюджета в течение периода. Проверяющему компоненту нужны атомарное погашение, ключи идемпотентности, проверка срока, поведение при отзыве и постоянная запись о том, какая закрытая транзакция использовала конкретное разрешение. Два обработчика могут одновременно найти один дефицитный товар. Криптография подтвердит оба запроса, если слой правил и хранилище не обеспечат одноразовое использование или общий бюджет. Сохраняйте доказательства после успеха и после отказа. Записывайте идентификаторы и хеши мандатов, версии, издателей, адресатов, время, раскрытые ограничения, решения проверок, ссылки на квитанции заказа и платежа, а также коды отказа. Не храните полные запросы лишь потому, что они доступны. Запрос неоднозначен, может содержать посторонние персональные данные и служит более слабым доказательством в споре, чем полученный из него подписанный объект. До выхода в эксплуатацию согласуйте с юристами и платежными партнерами сроки хранения и правила доступа. ## Для покупки агентом нужен отдельный торговый контракт Продавцу нужен торговый интерфейс, через который агент обнаруживает возможности, создает и меняет состояние заказа, получает варианты исполнения и завершает покупку. AP2 защищает авторизацию внутри этого процесса. UCP подходит для этой задачи, и текущие материалы Google описывают AP2 как расширение для автономных транзакций UCP. Можно использовать другой детерминированный API, но тогда продавец сам отвечает за сопоставление моделей и совместимость. Не начинайте с браузерной автоматизации потребительского сайта. Она популярна, потому что демонстрация может открыть множество магазинов без интеграции с продавцами. Для архитектуры продавца это неверный путь: текст DOM не равен подписанному каталогу, состояние сессии меняется непредсказуемо, защита от ботов попадает в платежный процесс, а согласие может относиться к странице, которую продавец изменит через секунду. Браузерная автоматизация поможет проверить спрос. Но она не даст стабильных идентификаторов и целостности заказа, необходимых для проверки мандата. AP2 также не конкурирует со всеми протоколами, в названии которых есть слова agent или payment. A2A может передавать сообщения между агентами. MCP открывает модели инструменты и ресурсы. UCP охватывает более широкий жизненный цикл торговли. x402 описывает платежную схему, которую часто связывают с программным доступом или стейблкоинами, а AP2 не зависит от способа оплаты и сосредоточен на полномочиях и доказательствах. У Agentic Commerce Protocol от OpenAI своя модель торговли и оформления заказа. Поддержка одного протокола не означает соответствия другому. Стройте адаптеры вокруг канонической внутренней модели заказа, а не размазывайте объекты разных протоколов по всему коду заказов. Практическая граница проходит через шлюз авторизации непосредственно перед выдачей платежных данных и завершением заказа. До шлюза агент может искать, сравнивать и договариваться. На шлюзе детерминированные сервисы фиксируют подписанный продавцом заказ, проверяют мандаты, применяют правила, резервируют одноразовое полномочие, запрашивают ограниченные платежные данные и фиксируют заказ. После шлюза продолжают работать существующие системы исполнения, возвратов, сверки и поддержки. Возврат должен ссылаться на исходное доказательство, но до появления иных правил в будущей версии протокола он проходит по процедуре продавца и платежной системы. ## Объявленная поддержка не равна рабочему внедрению В AP2 участвуют серьезные организации, но открытые данные не позволяют говорить, что каждая названная компания принимает AP2-транзакции в рабочей среде. Google анонсировала протокол в сентябре 2025 года вместе с более чем 60 организациями. В список вошли платежные сети, процессоры, торговые компании, поставщики программ и криптоинфраструктуры, в том числе American Express, Adyen, Coinbase, Etsy, JCB, Mastercard, PayPal, Revolut, Salesforce, ServiceNow, UnionPay International и Worldpay. Эти имена говорят об участии в разработке, поддержке идеи, экспериментах или планах интеграции. Значения у заявлений разные. Платежная сеть, которая помогает проектировать доказательства мандата, не равна продавцу с открытой точкой AP2. Поддержка процессора не равна рабочему эквайрингу в каждом регионе. Поддержка торговой платформы не означает автоматического подключения каждого продавца. При закупке спрашивайте о поддерживаемой роли, версии, среде, способах оплаты, регионах, подтверждении совместимости, рабочих примерах и ответственном за споры. Управление стандартом тоже меняется. Google передала AP2 в FIDO Alliance в апреле 2026 года, а Payments Technical Working Group этой организации использует AP2 вместе с разработкой Mastercard Verifiable Intent для создания спецификаций торговли с участием агентов. Во время перехода Google выпустила v0.2 с поддержкой автономных транзакций. Это усиливает путь к открытому стандарту, но управление рабочей группой не равно окончательному стандарту, который уже развернут повсеместно. Фиксация версии и управление изменениями остаются обязательными для продавца. Публичный репозиторий содержит реализацию под Apache-2.0, схемы, код SDK и тестовые сценарии. В нем сказано, что пакетный выпуск появится позже, а пока установка документирована прямо из репозитория. Этого достаточно для прототипа и контрактных тестов. Но это не доказывает, что управление ключами, хранение, имитацию платежного провайдера или агентский фреймворк из примера можно без изменений переносить в рабочую среду. В некоторых примерах используются инструменты Google, однако репозиторий прямо говорит, что AP2 не требует конкретного агентского фреймворка или модели. Просите поставщиков показать отказ, а не только успешную покупку. Пусть они предъявят просроченный открытый мандат, измененный хеш заказа, неразрешенного продавца, сумму выше лимита, повторное разрешение, неизвестный ключ и мандат другой версии протокола. Если партнер не показывает детерминированные пути отказа, он интегрировал демонстрацию счастливого сценария, а не платежный контроль. ## Готовность продавца начинается с дисциплины оформления заказа Продавец готов к пилоту AP2, когда его существующие системы создают стабильные подписанные условия заказа и отклоняют несогласованные попытки оплаты. Большинство требований скучны, и это хорошо. Платежи чаще ломаются на границах и переходах состояний, чем в библиотеке подписей. Торговому слою нужны стабильные идентификаторы товара и продавца, версионные сессии заказа, окончательные суммы по валютам, явное состояние налогов и доставки, правила резервирования остатков, условия возврата и определение существенного изменения. Платежному слою нужны токенизированные инструменты, поддержка контекста агента у процессора, идемпотентные авторизация и списание, обработка отказов, сверка, возвраты и способ связать токен с заказом. Слою идентификации нужны доверенные ключи подписи и проверки, ротация, отзыв, проверка адресата, точное время и изолированное подтверждение пользователя. После этого специальная работа с AP2 становится понятной. Зафиксируйте версию протокола и мандата. Создавайте подписанный продавцом JWT заказа. Проверяйте Checkout Mandate сами или передайте проверку по договору, который сохраняет доказательства. Передавайте хеш мандата заказа и ограниченный платежный токен в операцию завершения. Проверяйте Payment Mandate в роли процессора. Выпускайте подписанные квитанции заказа и платежа. Записывайте структурированные результаты проверок, не раскрывая платежные данные и лишние персональные сведения. Сделайте криптографическую проверку сервисом с небольшим версионным интерфейсом, а не набором вызовов по всему контроллеру заказов. Сервис должен находить доверенных издателей и ключи, проверять разрешенный список алгоритмов, отклонять отсутствующего адресата и устаревшее время, проверять представления с избирательным раскрытием и выпускать запись решения. Кешируйте открытые ключи только на заявленный срок и заранее решите, что делать при недоступности источника ключей. Разрешение операции из-за тайм-аута сервиса обнаружения превращает инфраструктурный сбой в несанкционированные расходы. Зафиксируйте владельцев ключей в письменной схеме. Продавец подписывает состояние заказа. Trusted Surface или ее поставщик подписывает полномочие пользователя в рамках выбранной модели авторизации. Автономный агент доказывает владение ключом, привязанным к открытому мандату. Издатели квитанций подписывают результаты. Используйте отдельные ключи и адресатов для тестовой и рабочей среды, отрепетируйте ротацию и сохраняйте метаданные, достаточные для проверки доказательств после замены активного ключа. Никогда не поручайте LLM выбирать алгоритмы, издателей, ключи или исключения проверки. Работа с конфиденциальностью начинается с карты данных на уровне полей. Продавцу нужны сведения для проверки полномочий на покупку, а Credential Provider и процессору нужны данные для авторизации платежа. Ни одной стороне автоматически не нужен исходный запрос, полный список рассмотренных товаров или все платежные инструменты пользователя. Избирательное раскрытие уменьшает риск лишь тогда, когда реализации запрашивают и записывают минимум полей. Если копировать полное представление мандата в общие журналы приложения, большая часть пользы исчезнет. Требования регулирования не исчезают за протоколом. Продавец все равно должен определить область PCI DSS вместе с эквайером или квалифицированным аудитором, соблюдать права на персональные данные, применять санкционные ограничения и запреты на товары, выполнять правила аутентификации, сохранять уведомления для потребителя и соблюдать местные нормы повторных или делегированных платежей. Ограниченный токен может уменьшить прямой контакт с карточными данными, но область требований определяют реальный путь токена и договор с провайдером. Не ставьте на архитектурную схему пометку «безопасно по PCI» лишь потому, что агент не видел номер карты. Назначьте владельца каждому результату проверки. Служба безопасности отвечает за неверные подписи и неизвестных издателей. Торговая система отвечает за изменившееся состояние заказа и отсутствие товара. Платежная команда отвечает за отказы поставщика данных и процессора. Команда агентского продукта отвечает за условия, которые не удалось превратить в детерминированные правила. Поддержке нужен безопасный экран с объяснением решения без показа платежных данных и закрытых утверждений. Финансам нужны доказательства совпадения сумм заказа, авторизации, списания, возврата и квитанции. Такое разделение превращает сбои AP2 в наблюдаемые состояния, а не в общую ошибку агента. Тесты совместимости должны пересекать границы организаций. Проверяйте свой компонент продавца мандатами, созданными не вашим SDK, а свои мандаты проверяйте независимой реализацией. Используйте фиксированные векторы для канонических хешей, раскрытий, подписей, границ срока действия, идентификаторов Unicode, точности валют и переставленных полей JSON. Система, которая проверяет только объекты из той же библиотеки, может скрывать одинаковую ошибку с обеих сторон. Совместимость начинается, когда две независимые реализации одинаково оценивают действительные и недействительные доказательства. На границе между сервисом заказа для агента и детерминированным шлюзом авторизации используйте контракт такого вида. Названия полей ниже относятся к внутреннему примеру, а не к схеме AP2. Такое разделение сделано намеренно. ```json { "checkout_session_id": "chk_7f31", "checkout_version": 4, "merchant_checkout_jwt": "", "checkout_mandate": "", "payment_mandate": "", "payment_token": "", "idempotency_key": "agent-order-0184" } ``` Шлюз должен возвращать стабильное решение, например `approved`, `user_required`, `declined` или `invalid`, вместе с машиночитаемой причиной и ссылкой на доказательство. Никогда не возвращайте «повторите попытку» при ошибке подписи или ограничения. Повтор безопасен при тайм-ауте и явно временной ошибке. Для другой версии заказа нужна новая авторизация, а для погашенного одноразового мандата нужен новый мандат. До перевода реальных денег подключите ответственных за платежи, безопасность, конфиденциальность, поддержку, финансы и юридические вопросы. Определите, кто разбирает претензию о неверном выборе товара агентом, кто может смотреть раскрытые утверждения, как пользователь отзывает открытое полномочие, как поддержка узнает агентский заказ и какие доказательства получит процессор или платежная сеть. AP2 делает такие разговоры точнее. Но он не проведет их вместо команды. ## Пилот должен доказать отказы раньше конверсии Безопасный пилот AP2 начинается в узкой категории товаров с детерминированными признаками, простой логикой исполнения и платежным партнером, готовым изучать доказательства. Не берите регулируемые товары, сложные замены, разделенные отправления, маркетплейсы с неясным продавцом по договору и необратимые покупки, пока базовый контроль не заработал. 1. Запустите официальный пример с имитацией платежных провайдеров и сохраните каждый мандат, раскрытие, результат проверки и квитанцию. Затем по одной заменяйте роли собственными детерминированными сервисами. 2. Сначала создайте сценарий с участием человека. Зафиксируйте и подпишите окончательный заказ, покажите его на независимой доверенной поверхности и докажите, что любое изменение после согласия требует новой авторизации. 3. Добавьте один автономный сценарий с точным продавцом, товаром, количеством, валютой, потолком суммы, сроком и одноразовым использованием. Проверьте параллельные обработчики и возврат пользователя, когда ограничение невозможно разрешить. 4. Добавьте в CI недействительные и повторные запросы. Зафиксируйте схемы и криптографические тестовые векторы, отклоняйте неизвестные версии и включите оповещения об обходе проверок или необъяснимой доле `user_required`. 5. Переводите ограниченную внутреннюю группу на реального процессора лишь после того, как поддержка сможет проследить заказ от подписанного оформления до платежа и квитанций без чтения переписки. Измеряйте результаты авторизации, причины отклонения ограничений, время восстановления через `user_required`, повторные попытки, изменения заказа после согласия, отказы процессора, причины возвратов и время работы поддержки. Конверсия станет важна позже. На раннем этапе успех означает, что система надежно отказывает в неверной покупке и объясняет причину структурированными данными. Здесь же проявляется важность устройства команды. Пилот AP2 затрагивает код агента, оформление заказа, платежи, идентификацию, инфраструктуру и операционные правила. Если нанять отдельных специалистов до появления стабильных границ, можно потратить месяцы на согласование вокруг меняющейся спецификации. Team & AI Audit от oleg.is помогает распределить эту работу в небольшой команде инженеров с ИИ и определить, какие обязанности по платежам и идентификации должны оставаться под явным контролем человека. Пилот AP2 оправдан, если делегированные покупки входят в продуктовую стратегию или крупный партнер по дистрибуции требует совместимой авторизации. Начинать рано, если каталог не создает стабильное состояние заказа, платежный провайдер не умеет ограничивать платежные данные или в команде никто не отвечает за споры и отзыв полномочий. Сначала исправьте основу. Протокол изменится, но подписанный заказ, детерминированный шлюз правил, изолированная поверхность согласия и контролируемый автомат состояний переживут следующую версию.