К содержанию
Платежи · агенты

Предпроцессинг для агентов: покупка и оплата в пределах задачи

Агенту дают не карту без границ, а право выполнить одну задачу: заказать, купить и оплатить в пределах её бюджета.

Предпроцессингом я называю сервис, который связывает задачу агента, его полномочия, общий бюджет, заказ, оплату и сверку. Банк или процессор спрашивает его до ответа по карте. Карта только один путь: та же схема работает со счётом, кошельком и оплатой API. Страница опирается на моё исследование 88 открытых источников из США, Европы, Индии и Китая.

Что банк не видит в покупке агентаЧетыре сценария ↓

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

Кубик бюджета: одна покупка (продуктовая модель автора)

Три покупки прошли и списаны из бюджета, четвёртая вне задачи остановлена (продуктовая модель автора)

Разрыв

По сумме и продавцу банк не отличит нужную покупку агента от лишней

В запросе на авторизацию банк видит сумму, продавца, его категорию и страну. Цель покупки он не видит: какой заказ, какой рейс, какая машина, чья задача. Это знает компания. Через внешнюю авторизацию процессор спрашивает сервис компании, прежде чем ответить по операции. Так к лимиту карты добавляется проверка цели покупки. Банк сохраняет право отказать: разрешение компании не обязывает его провести платёж.

Терминал

Видит банк в запросе

  • сумма и валюта
  • продавец и его категория
  • страна и терминал
  • карта и её лимиты
  • время операции
Внешняя авторизация: процессор банка спрашивает компанию до ответа

Знает компания

  • задача и её владелец
  • заказ или корзина
  • рейс и машина
  • договор и поставщик
  • бюджет задачи и остаток
  • срок задачи
Кто разрешает операцию
КомпанияПлатформа выпуска картИтог
дадапроходит
нетдаотказ
данетотказ после «да»

документация процессоров; продуктовая модель автора

Что тогда получает агент вместо карты? ↓

Полномочия

Ошибка агента ограничена одной задачей, а не картой компании

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

Сколько может потратить агент, если ошибся

  • С доступом к карте компаниивесь лимит карты
  • С правом на задачубюджет одной задачи

Ширина полосы: сколько агент может потратить. Рабочий пример

  1. 1Задачачья она и зачем
  2. 2Полномочиякакой агент и от чьего имени
  3. 3Бюджетостаток и резерв
  4. 4Заказпредмет, продавец, условияпродавец не из договора: заказ остановлен
  5. 5Оплатаплатёжное средство в границах задачикарта закрывает только это звено
  6. 6Исполнениезаказ создан, товар или услуга получены
  7. 7Сверкачек, счёт, отмена, возврат

Задача агентарабочий пример

Чья задача
начальника ремонтной службы
Цель
деталь для заявки на ремонт
Продавцы
поставщики из договора
Сумма
в пределах бюджета заявки
Срок
до конца недели
Подтверждает человек
замену детали и новые условия
Если не вышло
задача возвращается человеку

продуктовая модель автора; пилот по сообщению компании

Когда проверять задачу? ↓

Заказ

Предпроцессинг проверяет покупку до заказа: при оплате обязательство уже есть

Агент может забронировать невозвратный тариф, оформить заказ с оплатой позже, принять условия поставки или подключить подписку. Если покупку проверяют только при оплате, компания узнаёт о ней, когда обязательство уже есть. Поэтому предпроцессинг сверяет покупку с задачей до подтверждения заказа и в тот же момент резервирует бюджет. Оплата идёт из этого резерва, второго расхода нет.

Проверка только при оплате
  1. Задача
  2. Заказ подтверждён
  3. Резерв бюджета: резерва нетрезерва нет
  4. Авторизация: отказ
  5. Списание
  6. Отмена или возврат

Тариф уже куплен: отказ по карте не отменяет обязательство

Проверка до заказа
  1. Задача
  2. Заказ не создан
  3. Резерв бюджета
  4. Авторизация
  5. Списание
  6. Отмена или возврат

Заказ не создан: тариф вне задачи, запрос уходит человеку

Обязательство раньше списания

  • невозвратный тариф
  • заказ с оплатой позже
  • условия поставки
  • подписка на будущие расходы

Если цепочка порвалась

Деньги ушли, заказа нет
восстановление: вернуть деньги или создать заказ
Заказ есть, оплата не прошла
решение: повторить оплату или отменить заказ

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

  • 4 видаобязательства, которое агент берёт раньше списанияневозвратный тариф, оплата позже, условия поставки, подпискаисследование автора, 2026

исследование автора; продуктовая модель автора

Где в этой схеме человек? ↓

Человек

Человек одобряет задачу один раз, а не каждую из шести покупок

В режиме делегирования человек один раз утверждает границы и бюджет задачи, и покупки внутри них проходят сами. В режиме подтверждения он одобряет каждую покупку, в режиме исключений только ту, где агенту не хватает прав. Согласующий перестаёт подписывать каждую покупку и разбирает исключения. Контроль остаётся, меняется момент согласия. Пилоты на рынке уже идут в режимах подтверждения и делегирования.

Кто решаетСогласия человека на задачу из шести покупокЧто идёт без человека
Подтверждениеагент готовит, человек одобряетперед каждой покупкой · 6 согласийпоиск и подготовка покупки
Делегированиечеловек заранее утверждает границы и бюджетдо задачи · 1 согласиепокупки внутри границ
Исключенияагент действует сам, пока хватает правкогда нужно больше прав · 1 согласиевсё, кроме расширения прав

до задачи: · Квадрат: покупка, точка: согласие человека. Рабочий пример

Режимы в пилотах рынка

  • Европейская платформа корпоративных картчеловек подтверждает каждую оплату, оплату выше порога или заранее задаёт границыПодтверждениеДелегированиепилотисточник ↗
  • Индийский платёжный шлюз на UPI Reserve Payразовое согласие и лимит на продавца, дальше агент покупает самДелегированиезакрытый пилотисточник ↗
  • Китайский кошелёк в мессенджеревыделенный баланс, каждый заказ агента подтверждает пользовательПодтверждениедокументацияисточник ↗
  • Европейский банк и карточная сетьплатёж агента с заданными заранее ограничениями через инфраструктуру банкаДелегированиеконтролируемый пилотисточник ↗
  • Платформа исполнения для банковагент предлагает действие по запросу клиента, а исполняет его отдельный компонент по правилам вне моделиПодтверждениесообщение компанииисточник ↗

Согласующийподписывает каждую покупкуутверждает границы и разбирает исключенияпродуктовая модель автора

продуктовая модель автора; пилоты по сообщениям компаний

А если покупают несколько агентов? ↓

Бюджет

Общий бюджет не даёт агентам вместе потратить больше бюджета задачи

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

  • агент закупки
  • агент доставки
  • агент данных
Свой лимит у каждого агента

Сумма лимитов больше бюджета задачи

Общий журнал задачи

Следующий запрос: отказ, остаток исчерпан

Ширина полосы: доля бюджета задачи, белая черта: его граница. Рабочий пример

рабочий пример; документация компаний

Что здесь делает ИИ? ↓

ИИ

ИИ готовит покупку заранее, и авторизация не ждёт модель

Пока банк ждёт ответа, у сервиса компании 1⁠–⁠3 секунды: сверить полномочия, остаток, повтор запроса и запреты. Модели, которая рассуждает в несколько шагов, этого окна мало. Спецификация AP2 требует, чтобы обязательную проверку выполнял детерминированный код, а не агент. До оплаты агент понимает задачу и готовит проект разрешения, после разбирает отказ. В момент платежа работают правила и быстрая модель риска. Решение человека становится новым разрешением для следующей попытки.

До оплатыВ момент оплатыПосле оплаты
Агентпонимает задачу, сравнивает предложения, готовит проект разрешенияне участвуетразбирает отказ, собирает документы, предлагает правку правил
Модель рискаготовит признаки: связи карт, машин и терминаловбыстрая оценка рискаучится на исходах, которые становятся известны позже
Сервис исполненияпубликует утверждённую версию правилпроверяет полномочия, остаток, повтор и запреты, резервирует бюджетсверяет резерв с исходом, клирингом и возвратом
Человекутверждает правила и границы задачине участвуетрешает исключение: новое разрешение для следующей попытки

Сколько секунд внешняя авторизация ждёт ответа компании

  • Европейский процессор выпуска карт↗1 свместе с сетью
  • Две европейские платформы карт↗↗1,5 с
  • Американская платформа выпуска карт↗2 с
  • Европейская платёжная платформа↗2 с
  • Платформа выпуска карт с австралийскими корнями↗2,5 с
  • Американский процессор выпуска карт↗3 с
  • Американский процессор с доступом к потоку авторизаций↗6 спредел, рекомендовано меньше 3

Это параметры интерфейсов, а не замеры задержки и не свободное время для модели.

документация процессоров; спецификация протокола

Кто на рынке уже строит такие части? ↓

Рынок

В 88 источниках нет целой цепочки: место для банка свободно

У покупки агента шесть слоёв, и каждый отвечает на свой вопрос: что покупается, что разрешено агенту, кто он, чем платить, разрешает ли покупку компания и проводит ли её банк. Открытые протоколы закрывают первые четыре слоя, внешняя авторизация процессоров пятый, банки и платёжные сети шестой. Ни в одном из 88 источников нет кейса, где есть сразу банк, компания, её модель в момент оплаты и измеренный эффект.

  1. 1КорзинаЧто покупается и как согласован заказ?ACP, UCP↗↗открытые протоколы
  2. 2ПолномочияЧто человек разрешил агенту?AP2: мандат на покупку и мандат на оплату↗спецификация v0.2
  3. 3Идентичность агентаКто делает запрос и можно ли ему доверять?Trusted Agent Protocol↗документация сети
  4. 4Платёжный инструментКаким ограниченным средством платить?Shared Payment Tokens; MPP и x402 для оплаты API↗↗документация; токены в предварительной версии
  5. 5Решение компанииздесь предпроцессингРазрешена ли покупка по данным бизнеса?внешняя авторизация процессоров↗документация; работа ИИ в момент оплаты не описана
  6. 6Банк и расчётыМожно ли провести и рассчитать операцию?банк, процессор, карточная сеть, система мгновенных платежей, кошелёкработают
  • банк
  • компания
  • модель в момент оплаты
  • измеренный эффект

Источников: 88, целой цепочки нет

Что сильнее всего в регионах

  • СШАинтерфейсы выпуска карт с моделью риска и топливные карты с телематикой
  • Европасамая подробная документация о праве отказать и пилот, где агенты платят корпоративными картами
  • Индияагентные покупки через UPI Reserve Pay с разовым согласием и резервом средств
  • Китайкарточная сеть превращает намерение пользователя в ограничения платежа, кошелёк просит подтвердить каждый заказ

Свободное местосвязать данные бизнеса, разрешение на заказ, общий бюджет и оплату в одной отраслиисследование автора, 2026

  • 6 слоёвнельзя подменять друг другом: протокол корзины не даёт права платитьисследование автора, 2026
  • продукт для корпоративных клиентовплата за подключённую компанию, активного агента или обработанную задачупроектная гипотеза
  • нет независимого замераэффекта ИИ в момент оплаты: в процентах экономии у поставщиков смешаны кэшбэк, выбор станций, правила и моделиисследование автора, 2026

исследование автора; спецификации протоколов

Где эта цепочка нужна первой? ↓

Топливо

Чужую заправку компания останавливает до выдачи топлива, а не находит на сверке

Заправку грузовика объясняет сама машина: она идёт этим рейсом и тратит топливо. До авторизации компания знает маршрут, станции и разрешение. В момент оплаты она проверяет карту, машину, продавца, время и близость машины к станции. Литры, сорт и итоговая сумма приходят после оплаты. Поэтому модель риска учат только на том, что было известно в момент оплаты.

  1. До авторизации
    • маршрут рейса и станции на нём
    • ожидаемая потребность, а не точный замер
    • разрешение на заправку этой машины
  2. В момент оплаты
    • карта закреплена за водителем и машиной
    • разрешённый продавец и окно времени
    • машина рядом со станцией
    • оценка риска: повтор без пробега, несколько карт на одном терминале
    машина далеко от станции: отказ до выдачи топлива
  3. После оплаты
    • итоговая сумма вместо удержания
    • литры и сорт топлива
    • чек станции
    • расход на следующем пробеге

Где данные обманывают

  • станциясорт топлива
  • удержаниеитоговая сумма
  • место продавцаместо машины
  • объём бакапредел заправки: у техники бывает несколько баков
  • потеря связи датчикамошенничество

Что перевозчики пишут о топливе и оплате в рейсе →

исследование автора; документация компаний

Как та же схема работает вне топлива? ↓

Сценарии

Закупки, командировки, рейсы и оплата API проходят через один предпроцессинг

Отрасль меняется, а цепочка одна и та же: задача, бюджет, заказ, оплата. На схеме четыре проектных сценария. Сверяет предпроцессинг: чек, счёт и заказ связаны с задачей. Человек смотрит только расхождения.

  • Закупка
    1. Задачарасходная деталь
    2. Проверкапоставщик из договора, условияЧеловек: замена детали
    3. Оплататокен на корзинуКарта
    4. Сверкасчёт · поставка · заказ
  • Командировка
    1. Задачатранспорт и жильё
    2. Проверкастоимость всей поездкиЧеловек: невозвратный тариф
    3. Оплатакарта или счётКартаСчёт
    4. Сверкабилеты · жильё · отчёт
  • Рейс
    1. Задачатопливо и сервис в рейсе
    2. Проверкамашина, станция, окно, рискЧеловек: заправка без пробега
    3. Оплататопливная картаКарта
    4. Сверкалитры · чек · пробег
  • Данные и API
    1. Задачаданные и вычисления
    2. Проверкасервис, доля бюджетаЧеловек: новый поставщик
    3. Оплатакарта, кошелёк, MPP или x402КартаКошелёкAPI
    4. Сверкаресурс · задача

продуктовая модель автора; проектные сценарии

С чего начать? ↓

Старт

Начать стоит с контроля топлива: процессинг для этого менять не нужно

Начинать стоит там, где платёж связан с машиной и задачей, а решение банка не меняется. Это контроль топлива поверх текущей авторизации, помощник для правил и агент, который разбирает исключения. Потом нужны связь заказа или поездки с оплатой, общий бюджет и идентичность агентов. Машинные платежи за API позже: экономика малых сумм ещё не доказана. Каждый шаг сначала проверяют на прошлых операциях или в теневом режиме. До договора банку или процессору стоит задать 10 вопросов.

Порядок

  1. 1 высокий приоритетКонтроль топлива поверх текущей авторизацииплатёж связан с машиной и рейсомдоказать: свежие данные доступны, потерь меньше без роста ложных отказов
  2. 2 высокий приоритетПомощник по правилам и агент, который разбирает исключенияне меняет решение в момент оплатыдоказать: качество правил, меньше ручной работы, права не расширяются
  3. 3 высокий приоритетСвязь заказа или поездки с оплатойконтроль, которого нет в лимите по категории продавцадоказать: идентификаторы и сопоставление событий
  4. 4 основаБюджет и идентичность корпоративных агентовна этом стоит процессинг для агентовдоказать: границы держатся на реальных путях оплаты, доступ можно отозвать, журнал единый
  5. 5 позжеМашинные платежи и несколько путей оплатыAPI, данные и машинные сервисыдоказать: экономика малых платежей и договорная модель

Три гипотезы и их проверка

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

10 вопросов банку или процессору

  1. Кто эмитент, кто процессор, кто ведёт журнал и кто реально может отказать?
  2. Есть ли синхронный запрос с правом отказа или только события после операции?
  3. Какой таймаут у карточной программы компании и что при молчании, потере связи и офлайне?
  4. Какие операции идут в обход запроса: увеличение суммы, отмена, списание, возврат?
  5. Какие данные есть до решения: продавец, позиции, литры, место, заказ?
  6. Где работает ИИ: до оплаты, в момент или после, и чем это подтверждено?
  7. Как измерены качество модели и эффект: период, клиенты, база сравнения, ложные отказы?
  8. Может ли агент сам менять лимит или правила, кто их утверждает и кто исполняет?
  9. Как связаны агент, пользователь, бюджет, задача, корзина, инструмент и итоговое списание?
  10. Что подтверждает работу: живые клиенты и документация или анонс, пилот, демо?
  • 3 гипотезыих проверяют на прошлых операциях, в теневом режиме и тестом границпроектная гипотеза
  • 10 вопросовбанку или процессору до договорапродуктовая модель автора

продуктовая модель автора; проектные гипотезы

Как поручение с лимитом выглядит в приложении банка? →

Источники

По чему собрана страница

Моё исследование 18 октября 2026 года: 88 открытых источников по США, Европе, Индии и Китаю. Здесь 40 из них: документация процессоров, открытые протоколы, пилоты компаний, научные работы и разбор на конференции. Компании я не называю, ссылка ведёт на первоисточник. Проценты экономии, которые приводят поставщики, я на страницу не беру.

Внешняя авторизация

документация процессоров и платформ: кто ждёт ответа, сколько секунд и что происходит при молчании

Топливо и автопарк

что топливная карта знает о машине до оплаты и что приходит только после

Открытые протоколы

полномочия, идентичность агента, ограниченный платёжный инструмент, корзина и оплата API: разные слои, их нельзя подменять друг другом

Пилоты и запуски

сообщения компаний; статус пилота, анонса или документации указан в самом источнике, независимого замера эффекта нет

Научные работы и конференция

потоковый антифрод, безопасность мандатов и делегирования; препринты подписаны как препринты