Skip to main content
X402 — це протокол платіжних транзакцій на основі HTTP 402, запропонований Coinbase: сервер у відповідь на запит без токена повертає 402 Payment Required, супроводжуючи його полем accepts: [...], яке перераховує прийнятні ланцюги / активи / ціни; клієнт підписує транзакцію локально (на EVM це Permit2 / EIP-712, на Solana — SPL token transfer авторизація), поміщає base64 закодований envelope у заголовок PAYMENT-SIGNATURE і повторно надсилає запит. Сервер перевіряє, а потім справжнім чином проводить розрахунок на ланцюзі, повертаючи бізнес-результат.
X402 клієнт Ace Data Cloud безпосередньо викликає цільовий API і використовує 402 Payment Required та accepts, отримані в реальному часі, як основу для ціни та підпису. Платіжні можливості Facilitator можна перевірити за адресою /.well-known/x402.
@acedatacloud/sdk та acedatacloud обидва надають гук paymentHandler: коли запит, надісланий SDK, отримує 402, викликається ваш інжектований обробник для отримання заголовка PAYMENT-SIGNATURE, після чого повторно надсилається оригінальний запит. Використовуючи @acedatacloud/x402-client / acedatacloud-x402 разом із SDK, весь процес повністю прозорий для бізнес-коду — вам потрібно лише client.openai.chat.completions.create(...), виглядає так само, як і в режимі токена, але на нижньому рівні оплата здійснюється за фактом використання, без необхідності попередньої зарядки. У цій статті:
  • Реально пройдено ланцюг «без токена + інжекція X402 обробника» на TS стороні (T12 перевірка)
  • Перераховані відмінності між двома підходами підпису для EVM / Solana
  • Надано три адаптації: режим приватного ключа viem, режим браузерного гаманця, режим Python EVMAccountSigner
  • Роз’яснено поле preferScheme / prefer_scheme, яке може бути проблемним

I. Огляд протоколу (обов’язково)

Успішний виклик X402 передбачає 3 HTTP RTT:
X402 envelope — це частина JSON, яка після кодування в base64 вставляється в заголовок PAYMENT-SIGNATURE. Структура (вибірково):
На верхньому рівні envelope знаходиться x402Version: 2, а об’єкт accepted оголошує вибрані scheme та network (ідентифікатор CAIP-2). preferScheme / prefer_scheme використовується для вибору переваги, коли сервер одночасно пропонує кілька схем. Якщо сервер пропонує лише exact, це поле буде проігноровано; якщо встановлено upto, але сервер не пропонує, буде повернено до першого відповідного варіанту.

II. TypeScript: браузерний гаманець + сервер viem два способи використання

Встановлення

Перевірені версії:

Повна підписка createX402PaymentHandler

Повертає (ctx) => Promise&lt;{ headers: Record<string, string> }> — це точно відповідає підпису гака paymentHandler SDK.

Використання 1: Браузер (MetaMask / WalletConnect)

Перший виклик у браузері викличе два запити на підпис: перший — це одноразове схвалення Permit2 для USDC (сума MaxUint256, записується в ланцюг); другий — підпис EIP-712 для X402 envelope (не записується в ланцюг, лише для перевірки facilitator). Подальші виклики потребують лише другого підпису, тому досвід виглядає як «один раз натиснути підпис → отримати результат».

Використання 2: Node сервер + приватний ключ viem (підходить для бекенду / CLI)

@acedatacloud/x402-client на TS стороні приймає лише EIP-1193 провайдер — він не управляє приватними ключами безпосередньо. У сценаріях Node / CLI стандартним підходом є використання viem для упаковки приватного ключа в WalletClient, а потім використання @ethereumjs/util або внутрішньої адаптації EIP-1193 viem.
Якщо вважаєте, що адаптація EIP-1193 у viem недостатньо стабільна, можна скористатися більш низькорівневим signEVMUptoPayment, самостійно з’єднавши accepts → signed envelope → PAYMENT-SIGNATURE header, пропустивши SDK хуки; проте рекомендується все ж обирати createX402PaymentHandler, щоб не підтримувати оновлення протоколу самостійно.

Використання 3: Solana

На ланцюзі Solana наразі використовується лише exact схема, тому preferScheme не діє на Solana.

Три, Python: режим приватного ключа

Python acedatacloud-x402 використовує пряме підписання приватним ключем (без абстракції EIP-1193), що більше підходить для серверів / виконавців завдань.

Встановлення

Перевірена версія:

EVM (Base / Skale)

Solana

Одноразове схвалення (тільки для EVM вперше)

EVM Base на X402 використовує Permit2, потрібно, щоб гаманець дав Permit2 контракту одноразове MaxUint256 схвалення. acedatacloud-x402 вбудовано approve_permit2:
Цю транзакцію потрібно виконати лише один раз, після чого всі X402 EVM платежі використовуватимуть це схвалення. Solana не потребує цього.

Чотири, реальна перевірка виконання

Тестова мета: TS SDK не передає токен, інжектує X402 обробник, може нормально створювати та ініціювати запити (не витрачаючи реальний USDC на ланцюзі для легкого тестування).
Вихід:
Результати показують:
  • Не передаючи apiToken, SDK створюється без помилок, що підтверджує, що X402 режим дійсно є законною альтернативою токену.
  • createX402PaymentHandler повертає функцію (хука), SDK використовує її лише при отриманні 402.
  • Реальне тестування платіжного процесу на ланцюзі, оскільки воно включає реальні витрати USDC, не включено в цей посібник; можна звернутися до X402 інтеграційного посібника для e2e прикладів.
Python сторона create_x402_payment_handler також провела таку ж перевірку — значення, що повертається функцією, є викликаним, при інжекції payment_handler=... AceDataCloud(...) створюється без помилок. Обидві сторони узгоджені за змістом.

П’ять, порівняння з «Bearer token режимом»