Перейти к основному содержимому
УзнатьГлоссарийПлатежное полномочие
ГЛОССАРИЙ

Что такое платежное поручение.

ОПРЕДЕЛЕНИЕ

Платежное полномочие - это предварительно авторизованная инструкция, позволяющая агенту выполнять определенный класс платежей без дальнейшего одобрения. Полномочие параметризовано: оно может указывать максимальную сумму, получателя или набор разрешенных получателей, окно частоты и дату истечения. Примитивный протокол AP2 от Google и несколько аналогичных систем платежей на основе полномочий построены на этом.

ПОЧЕМУ ЭТО ВАЖНО

The "approve every payment" model does not scale to agents.

Человеческие платежные модели предполагают одно одобрение на транзакцию: вы видите общую сумму при оформлении заказа, вы нажимаете для подтверждения. Агенты, которым нужно оплатить 200 API за час, не могут работать таким образом. Пользователь не может нажать 200 подтверждений, и даже если бы мог, задержка убила бы полезность агента. Требуется какая-то модель предварительного одобрения.

Payment mandates formalize the pre-authorization. Instead of "approve every payment" or "approve nothing" (a static spend limit), a mandate says: "approve any payment that matches these parameters, up to this cap, until I revoke it." The user grants the mandate once; the agent executes against it many times. This is the structural primitive that turns the agent into an autonomous economic actor while still keeping the human in control of the boundaries.

КАК ЭТО РАБОТАЕТ

Предоставить, представить, завершить, отозвать.

  1. Предоставить. Пользователь (или делегат пользователя) создает мандат через интерфейс протокола, указывая параметры: максимальная сумма за платеж, максимальная сумма за период, белый список получателей, срок действия. Мандат подписывается и хранится протоколом.
  2. Представить. Когда агенту нужно сделать платеж, он представляет мандат процессору платежей получателя как доказательство авторизации. Процессор проверяет мандат, проверяет, что параметры платежа находятся в пределах лимитов мандата, и принимает платеж.
  3. Рассчитаться. Фактический расчет происходит на той платформе, которую указывает мандат (стейблкоин, карта, ACH). Проверка мандата отделена от расчета; один мандат может авторизовать платежи через несколько методов расчета, если протокол это позволяет.
  4. Отмена. В любое время пользователь может отозвать мандат. Последующие представления не проходят проверку. Платежи в процессе могут завершиться или не завершиться в зависимости от гарантий атомарности протокола.

The protocol layer holds the mandate; the agent never holds the user's payment credentials directly. This is the safety property that makes mandate-based systems different from "give the agent your credit card." Compromise the agent and the worst case is the mandate's parameter envelope, not the user's full payment power.

ПРИМЕРЫ

Три формы мандата.

ПРИМЕР 1

Обязательство доступа к API по вызову

Агенту предоставляется мандат на расходы до $0.10 за вызов на любой API в определенном белом списке, до $50 в общей сложности за день. Агент вызывает API в течение дня; каждый вызов в рамках параметров мандата завершается без дальнейшего одобрения. Расходы свыше $50 за 24 часа блокируются на уровне платформы.

ПРИМЕР 2

Мандат подписки, специфичный для поставщика

Агент исследования получает мандат на оплату одному конкретному поставщику данных до $200/месяц, выставляемому в стейблкоинах. Счет поставщика автоматически инициирует предавторизованный платеж по мандату. Агент никогда не должен показывать счет человеку.

ПРИМЕР 3

Одноразовый лимитированный мандат

Пользователь предоставляет агенту мандат на одноразовое использование, чтобы потратить до $500 на бронирование отеля с одной доверенной платформы бронирования. Агент ищет, выбирает вариант в пределах лимита и бронирует. После использования мандат не может быть повторно использован.

Часто задаваемые вопросы

Три общих вопроса.

Является ли платежное полномочие тем же, что и постоянная авторизация на карте?

Схожи по духу, но структурно очень разные. Авторизация карты удерживается сетью карт и применяется между конкретным держателем карты и конкретным торговцем. Платежный мандат в смысле агентской торговли удерживается платежным протоколом (например, AP2), может быть параметризован по сумме, получателю, частоте и временным окнам и рассчитывается в стейблкоинах или фиатных деньгах в зависимости от реализации. Мандаты более программируемые, более детализированные и не привязаны к сетям карт.

Можно ли отозвать мандат?

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

Использует ли Blockchain0x платежные мандаты?

Пока нет, формально. Мы достигаем похожих результатов agent-spending-control через per-agent spend permission (allowance на период и cap на одну transaction), enforced at the API layer. Для common cases это mandate-equivalent (ограниченные spend за time window). Полная поддержка mandate-protocol (revocation primitives, signed mandates, которые передаются вместе с payment requests, AP2-compatible flows) находится в roadmap по мере сближения standards.
Последний обзор: 2026-05-15. Опубликовано под CC BY 4.0.

Предварительно авторизуйте расходы вашего агента.

Политики расходов за агента, применяемые на уровне API. Бесплатно для начала.