В предыдущей статье этой серии мы создали приложение x402, которое позволяло клиенту-роботу получать требование об оплате по протоколу HTTP 402, оплачивать его, повторять запрос и получать доступ к защищенному ресурсу.
Этот сценарий отлично работает, когда транзакция соответствует одному запросу. Тем не менее, во многих автоматизированных сервисах связь между оплатой и доставкой носит более долгосрочный характер. Агент может потреблять сгенерированный контент в течение нескольких секунд, получать последовательность результатов, оформлять подписку на ленту данных или оплачивать единицы выполненной работы по мере их завершения.
Stripe и Machine Payments Protocol (MPP) от Tempo созданы для программных платежей между агентами и сервисами. Этот протокол использует HTTP 402 для передачи требований об оплате, поддерживая при этом различные способы оплаты и намерения, включая как разовые списания, так и долгосрочные платежные сессии.
В этой статье вы научитесь создавать демонстрационный потоковый сервис на базе MPP в Fastly Compute, в котором сравниваются два подхода:
- Токен совместного использования платежа (Shared Payment Token, или SPT) от Stripe, который авторизует платеж, обеспеченный фиатными деньгами, до начала потоковой передачи.
Токен совместного использования платежа (Shared Payment Token, или SPT) от Stripe, который авторизует платеж, обеспеченный фиатными деньгами, до начала потоковой передачи.
- Нативная платежная сессия Tempo, которая увеличивает авторизованную сумму по мере потребления клиентом каждой единицы.
Нативная платежная сессия Tempo, которая увеличивает авторизованную сумму по мере потребления клиентом каждой единицы.
Оба сценария обеспечивают похожий пользовательский опыт в браузере, однако лежащие в их основе механизмы движения платежей различаются.
Краткое предупреждение
Код и реализации, представленные в этой статье, созданы исключительно в качестве экспериментального справочного демо для демонстрации концепций потоковой передачи MPP на Fastly Compute. Этот проект не готов к продакшену. Пожалуйста, изучайте, адаптируйте и тестируйте его на свой страх и риск, а перед внедрением в рабочие среды ознакомьтесь с разделом «Рекомендации для продакшена» в самом низу.
Когда оплата должна продолжаться вместе с доставкой
Обычный платный API-запрос имеет четкие границы. Клиент получает требование, производит оплату и получает ответ.
Потоковая передача делает эти границы менее очевидными. Сервис должен знать, какую сумму авторизовал клиент, должно ли разрешение увеличиваться по мере продолжения доставки и что происходит, если клиент отключается до того, как сервис завершил работу.
MPP отражает эти решения с помощью платежных намерений (payment intents).
Реализация со Stripe в этой демо-версии использует intent=charge. Она авторизует фиксированную сумму до начала потоковой передачи, а приложение учитывает доставку в рамках этого бюджета.
Реализация с Tempo использует intent=session. Она открывает платежный канал и увеличивает кумулятивную авторизацию по мере того, как клиент потребляет дополнительные единицы.
Демонстрационное приложение
Приложение предоставляет два потоковых маршрута:
Интерфейс в браузере позволяет проверить неоплаченное требование 402 для любого маршрута или запустить полный сценарий с оплатой.
По мере доставки ответа на экране отображаются следующие данные:
- выбранный платежный шлюз
выбранный платежный шлюз
- количество потребленных единиц
количество потребленных единиц
- цена за единицу
цена за единицу
- накопленная сумма
накопленная сумма
- событие окончательного расчета.
событие окончательного расчета.
В демоверсии используются вспомогательные инструменты плательщика на стороне сервера, чтобы ее можно было продемонстрировать без отдельного агента или расширения кошелька. Эти помощники нужны исключительно для того, чтобы упростить демонстрацию протокола.
Потоковая передача с финансированием через Stripe SPT
Сценарий со Stripe авторизует полный бюджет до начала доставки.
Сначала агент запрашивает /stripe-stream без платежных учетных данных. Сервис отвечает требованием MPP, в котором указаны способ оплаты Stripe и intent=charge.
Плательщик использует это требование для создания тестового токена совместного использования платежа (Shared Payment Token). Этот токен содержит способ оплаты, валюту, максимальную авторизованную сумму и время истечения срока действия. Плательщик упаковывает его в учетные данные MPP и повторяет запрос.
Сервис проверяет учетные данные и создает Stripe PaymentIntent. Как только платеж авторизован, начинается потоковая передача ответа.
В демонстрации по умолчанию авторизуется сумма $0.50, а поток делится на десять визуальных единиц. При начале доставки клиент получает событие с описанием авторизованного бюджета:
Каждое последующее событие включает текущую единицу и накопительную сумму, соответствующую доставленному потоку. Когда все единицы отправлены, сервис возвращает событие завершения и закрывает соединение. Ответ также содержит платежную квитанцию MPP (Payment-Receipt).
Счетчик для каждой единицы не означает отдельное списание через Stripe для каждого фрагмента. Один платеж на базе SPT авторизует настроенную сумму до начала потока. Затем приложение отслеживает прогресс доставки в рамках этого бюджета.
Если клиент останавливается раньше времени, демоверсия не возвращает неиспользованную сумму автоматически. В продакшн-версии потребуется определить, как обрабатывать частичное списание, кредиты, возвраты или неиспользованную авторизацию.
Нативные сессии MPP с использованием Tempo
Сценарий с Tempo связывает авторизацию более напрямую с потреблением.
Сначала браузер подписывается на эндпоинт конкретной сессии через Fastly Fanout:
Fanout удерживает долгоживущее соединение с браузером. Pushpin обеспечивает такое же поведение при локальной разработке.
Затем плательщик запрашивает первую единицу с адреса /tempo-stream. Сервис отвечает требованием MPP, указывая method=tempo и intent=session.
Плательщик открывает платежный канал и повторяет запрос. После проверки первой единицы Compute публикует ее в канале Fanout браузера.
Дополнительные единицы используют ту же сессию MPP. Плательщик увеличивает свою кумулятивную авторизацию, сервис проверяет новую сумму, а Compute публикует следующую единицу.
Менеджер сессий сохраняет платежный канал для последовательности конечных HTTP-запросов. Fastly KV Store хранит состояние сессии, чтобы запросы единиц и запросы управления могли использовать один и тот же канал.
Fanout — единственный долгоживущий транспорт в этой архитектуре. Браузер поддерживает одно потоковое соединение открытым, в то время как Compute обрабатывает отдельные операции оплаты и доставки как ограниченные запросы.
Это разделение полезно тем, что сессия MPP может логически продолжаться без необходимости для плательщика поддерживать еще одно внутреннее SSE-соединение внутри Compute.
После доставки последней единицы плательщик закрывает канал, а Tempo производит расчет накопительной суммы.
Две платежные модели, один и тот же опыт потоковой передачи
Интерфейс позволяет наглядно увидеть разницу между двумя сценариями.
Stripe SPT
Сессия Tempo
Использует intent=charge
Использует intent=session
Авторизует фиксированный бюджет до начала доставки
Увеличивает авторизацию по мере потребления
Использует Stripe PaymentIntent
Использует платежный канал и кумулятивные ваучеры
Учитывает единицы на уровне приложения
Связывает оплаченные единицы с нативной сессией
Возвращает платежную квитанцию (Payment-Receipt)
Производит расчет при закрытии сессии
Модель Stripe отлично подходит, когда сервису известна максимальная цена до начала доставки. Модель Tempo ближе к потреблению с оплатой по факту (pay-as-you-go), где авторизованная сумма увеличивается в ходе взаимодействия.
Потоковая передача на Fastly Compute
Для демонстрации потребовалось небольшое количество изменений во время выполнения. Приложение привязывает сгенерированные ответы SSE к времени жизни события fetch, обеспечивает совместимость с использованием метода Response.clone() в библиотеке MPP и направляет трафик Tempo RPC через поименованный бэкенд Fastly.
Эти изменения содержатся в самой демонстрации и позволяют логике платежей выполняться без буферизации прямой трансляции или создания еще одного долгоживущего соединения внутри Compute.
Где это можно использовать
Этот паттерн может поддерживать любой сервис, где ценность доставляется с течением времени или в измеримых единицах.
ИИ-сервис может авторизовывать бюджет и отчитываться о потреблении по мере выдачи сгенерированного контента. Провайдер данных может взимать плату за премиальную ленту. Веб-краулер может платить за лицензированный контент или структурированные данные. Один сервис может платить другому за последовательность операций обработки.
Подходящая модель оплаты зависит от сервиса. Некоторые приложения предпочтут фиксированный бюджет, утверждаемый до начала работы. Другим потребуется, чтобы авторизация платежа продвигалась параллельно с потреблением.
MPP позволяет использовать обоим подходам одну и ту же HTTP-платформу платежей, оставляя обработку базовой авторизации и расчетов платежной сети.
Соображения для продакшена
Этот репозиторий является демонстрацией, а не полноценным платежным прокси для продакшена.
Вспомогательные функции плательщика на стороне сервера следует удалить до того, как сервис будет выставлен на общее обозрение. Секреты Stripe, секреты подписания MPP и закрытые ключи должны храниться в Fastly Secret Store, в то время как конфигурация ценообразования и платежной сети должна быть перенесена в Config Store.
Включенный адаптер Fastly KV поддерживает последовательную демонстрацию Tempo с одним плательщиком. Продакшен-система с одновременной записью ваучеров или широким использованием в нескольких POP-узлах потребует атомарной обработки состояния сеанса.
Для полноценной реализации также потребуются привязка запросов, защита от повторного воспроизведения, лимиты расходов, ограничения частоты запросов (rate limits), наблюдаемость, идемпотентность и определенная политика для прерванных потоков и неиспользованных авторизованных бюджетов.
От платных запросов к платным потокам
Предыдущая демонстрация x402 показала, как автоматизированный клиент может платить за защищенный запрос. Эта демонстрация MPP расширяет эту модель на взаимодействия, в которых оплата и доставка происходят одновременно.
Процесс Stripe авторизует бюджет, обеспеченный фиатными деньгами, до начала потока. Процесс Tempo открывает нативный платежный сеанс и увеличивает кумулятивную авторизацию по мере потребления единиц.
Демонстрация также показывает, как Fanout может поддерживать долгоживущее клиентское соединение, в то время как Compute обрабатывает конечные операции оплаты и доставки позади него.
Полная реализация доступна в репозитории демонстрации на GitHub.
