Machine Payments Protocol на Solana

Machine Payments Protocol (MPP) застосовує семантику HTTP-автентифікації до платежів. Сервер надсилає виклик у відповідь на неоплачений запит, клієнт повертає платіжні облікові дані, а сервер після прийняття платежу повертає квитанцію.

MPP розділяє три аспекти:

• Намір (intent) описує комерційну взаємодію, наприклад одноразовий charge або тарифікований session.
• Платіжний метод описує, як переміщується вартість. Метод Solana підтримує нативний SOL і токени SPL для платежів charge.
• HTTP-транспорт передає виклики, облікові дані, квитанції та помилки.

MPP публікується як набір Internet-Drafts. Вважайте поточні специфікації джерелом істини та пам’ятайте, що деталі можуть змінюватися, доки чернетки перебувають у розробці.

HTTP-обмін

MPP використовує стандартні поля HTTP-автентифікації замість спеціальних платіжних заголовків протоколу:

Виклик містить згенеровані сервером ID, realm, метод, намір, закодований платіжний запит і строк дії. Облікові дані повторюють виклик і додають платіжне підтвердження, специфічне для методу. Сервер має перевірити обидві частини: дійсний переказ, що належить до іншого виклику, не повинен розблоковувати ресурс.

Одноразові платежі Solana

Намір charge у Solana підтримує два типи облікових даних:

• Режим pull використовує підписану транзакцію. Клієнт підписує переказ і надсилає транзакцію на сервер. Сервер перевіряє її, за потреби додає підпис платника комісії, транслює, підтверджує та повертає підпис транзакції у квитанції.
• Режим push використовує підпис транзакції. Спочатку клієнт транслює транзакцію, потім надсилає підтверджений підпис на сервер. Сервер отримує та перевіряє транзакцію, перш ніж повернути ресурс.

Режим pull уможливлює спонсорування комісій за транзакції сервером і логіку повторних спроб на стороні сервера. Режим push корисний, коли гаманець вимагає, щоб клієнт сам надсилав транзакцію, але в ньому не можна використати спонсорування комісій сервером.

Нормативні поля та правила перевірки дивіться в специфікації Solana charge.

Додавання платежу MPP до Express API

Solana Pay Kit надає актуальну інтеграцію TypeScript для MPP і x402. Встановіть його разом з Express:

pnpm add @solana/pay-kit @solana/kit@^6.9.0 express
pnpm add --save-dev @types/express tsx

Цей мінімальний приклад використовує хостингову пісочницю Surfpool і публічного демонстраційного отримувача пакета. Він призначений лише для локальної розробки:

import express from "express";
import { createPayKit, usd } from "@solana/pay-kit";

const pay = await createPayKit({
  accept: ["mpp"],
  rpcUrl: "https://402.surfnet.dev:8899"
});

const app = express();

app.get("/report", pay.express(usd("0.01")), (_req, res) => {
  res.json({ report: "Paid report" });
});

app.listen(4567, () => {
  console.log("Paid API listening on http://127.0.0.1:4567");
});

Запустіть його та порівняйте неоплачений запит із запитом, що підтримує платіж:

pnpm tsx server.ts
curl -i http://127.0.0.1:4567/report
pay --sandbox curl http://127.0.0.1:4567/report

Обробник маршруту запускається лише після того, як middleware прийме платіж.

Тарифіковані сесії

Використовуйте session Solana MPP, коли клієнт здійснюватиме багато дрібних пов’язаних платежів. Сесія відкриває ончейн-платіжний канал із максимальним депозитом, а потім використовує кумулятивні підписані ваучери в міру зростання використання. Сервер може перевіряти ваучери офчейн і пізніше розрахувати найвищу прийняту суму.

Це корисно для інференсу з тарифікацією за токенами, завантажень з тарифікацією за байтами, живих даних і повторних викликів інструментів. Це не те саме, що надсилання окремого ончейн-платежу за кожну подію.

Називайте сесію сесійним платежем, платіжним каналом або обмеженою повторюваною авторизацією. Називайте її потоковим платежем лише тоді, коли сервіс і платіжний контракт справді тарифікують потік використання.

Перевірка у продакшені

Для кожного платежу Solana charge сервер має перевірити щонайменше таке:

• Виклик автентичний, не прострочений, прив’язаний до цього запиту та призначений для цього realm.
• Транзакція використовує очікувану мережу, актив або mint, отримувача, суму та програму токенів.
• Будь-які інструкції платника комісії або associated token account явно дозволені й не можуть вичерпати кошти підписувача сервера.
• Транзакція успішно виконана на потрібному рівні підтвердження.
• Підпис транзакції ще не було використано.
• Перевірка повторного використання та операція споживання є атомарними на всіх екземплярах сервера.

Для сесій також зберігайте стан каналу, прийняту кумулятивну суму та позначку розрахунку (settlement watermark) у спільному сховищі. Задокументуйте, як клієнти повертають невикористані кошти, якщо сервер стане недоступним.

Пов’язані ресурси

• Специфікації MPP
• Документація протоколу MPP
• Solana Pay Kit
• Огляд агентних платежів
• Готовність до продакшену