Рекомендации по реализации

Роли и их реализация

Ниже описано, что необходимо реализовать каждой роли, и приведены примеры того, как эта роль может быть воплощена в платёжной экосистеме.

Продавец (Merchant)

Продавец должен реализовать:

• Предоставление конечных точек Каталога (Catalog) и Оформления заказа (Checkout) для Торгового Агента — например, согласно спецификации Universal Commerce Protocol.
• Генерацию подписанного продавцом Checkout JWT.
• Верификацию Checkout Mandate — либо самостоятельно, либо делегируя эту обязанность технологическому провайдеру (например, MPP).
• Завершение оформления заказа с использованием хеша Checkout Mandate и payment_token (ограниченного областью действия Payment Mandate) — либо реализацию роли MPP самостоятельно.
• Генерацию подписанной Checkout Receipt с соответствующим статусом и её возврат Торговому Агенту.

Возможные архитектурные варианты:

• Классический продавец с UCP-эндпоинтами.
• Merchant Agent, взаимодействующий с Торговым Агентом по протоколу A2A, а с бэкендом продавца — через UCP.
• Совмещённые роли Продавца и Платёжного Процессора (MPP).
• Продавец с делегированной верификацией Checkout Mandate.

Платёжный Процессор Продавца (MPP)

• Принимает платёжный токен от Продавца.
• Верифицирует Payment Mandate, содержащийся в платёжном токене.
• Генерирует подписанный Payment Receipt, доступный Торговому Агенту, Провайдеру Удостоверений и Сети.
• Обрабатывает или верифицирует платёж.

Торговый Агент (Shopping Agent)

• Агентский поиск товаров и определение намерения пользователя.
• Выбор платёжного инструмента у Провайдера Удостоверений.
• Формирование содержимого Checkout и Payment Mandate.
• Получение подписанных мандатов через Доверенную Поверхность.
• Предъявление Payment Mandate Провайдеру Удостоверений для получения платёжного токена, включая:
  • выбор подходящего мандата из хранилища,
  • привязку ключом агента (Key Binding),
  • минимизацию данных через выборочное раскрытие,
  • предотвращение двойного расходования и управление квитанциями.
• Предъявление Checkout Mandate Продавцу при завершении оформления заказа (аналогичный набор операций).
• Получение квитанций и обработку успешных и ошибочных результатов.

Провайдер Удостоверений (Credential Provider)

• Предоставление Торговому Агенту списка доступных платёжных инструментов.
• Верификация Payment Mandate.
• Получение платёжного токена от сети с использованием Payment Mandate либо инициирование отправки средств продавцу.
• Выпуск платёжного токена или номера подтверждения перевода.
• Получение и хранение Payment Receipt.

Примеры реализации: - Цифровой кошелёк пользователя или платёжная сеть, с которой связан Торговый Агент. - Хранилище платёжных инструментов, предоставляемое непосредственно Торговым Агентом. - Хранилище платёжных инструментов, предоставляемое Продавцом.

Доверенная Поверхность (Trusted Surface)

Доверенная Поверхность представляет собой UI, которому все стороны доверяют получение авторизации и согласия от конечного пользователя. Обязанности:

• Отображение содержимого мандатов пользователю.
• Получение авторизации и согласия пользователя.
• Создание подписанных мандатов и их делегирование Торговому Агенту.

Примеры реализации: - Детерминированная часть приложения Торгового Агента. - Отдельное приложение кошелька или приложение банка-эмитента. - Доверенные пользовательские агенты (мобильные платформы или браузеры).

Идентификация агента

AP2 спроектирован так, чтобы ограничивать поведение агентов, не требуя от них изначальной доверенности. В рамках реализации Коммерческого Протокола Продавцы или Доверенные Поверхности МОГУТ пожелать работать только с доверенными агентами — эти детали остаются на уровне Коммерческого Протокола.

Вычисление хешей

При вычислении хешей критически важно использовать одно и то же представление данных. Как правило, это достигается передачей base64url-представления JSON-структур. Для разрешения споров это означает хранение SD-JWT вместе с их раскрытиями в компактной сериализации — это позволяет легко вычислить sd_hash, checkout_hash и reference квитанции.

Для согласованности используется один и тот же алгоритм хеширования как для дайджестов SD-JWT, так и для checkout_hash.

Ключ агента

Ключ агента — критически важный элемент автономных сценариев. Он используется для:

• Привязки к транзакции (transaction binding) открытых мандатов и предотвращения их повторного использования.
• Предотвращения двойного расходования путём блокировки выпуска перекрывающихся закрытых мандатов.

Один из способов реализации — использование вызова инструментов (tool calling), при котором детерминированный код проверяет создаваемый закрытый мандат перед его подписанием. Эта обязанность также может быть делегирована Торговым Агентом технологическому провайдеру.

Управление мандатами

Поскольку мандаты являются долгоживущими объектами, Торговый Агент ДОЛЖЕН предоставлять механизм управления активными мандатами (вместе с задачами, для которых они используются). Ограничение срока действия активных мандатов и уведомление пользователя — даже при автономном выполнении — являются важными мерами для сохранения пользовательского контроля над Торговым Агентом.

В случае использования внешних Доверенных Поверхностей может иметь смысл предусмотреть управление делегированными мандатами, однако этот вопрос выходит за рамки настоящей спецификации.