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, режим браузерного гаманця, режим PythonEVMAccountSigner - Роз’яснено поле
preferScheme/prefer_scheme, яке може бути проблемним
I. Огляд протоколу (обов’язково)
Успішний виклик X402 передбачає 3 HTTP RTT:PAYMENT-SIGNATURE. Структура (вибірково):
x402Version: 2, а об’єкт accepted оголошує вибрані scheme та network (ідентифікатор CAIP-2).
preferScheme / prefer_scheme використовується для вибору переваги, коли сервер одночасно пропонує кілька схем. Якщо сервер пропонує лише exact, це поле буде проігноровано; якщо встановлено upto, але сервер не пропонує, буде повернено до першого відповідного варіанту.
II. TypeScript: браузерний гаманець + сервер viem два способи використання
Встановлення
Повна підписка createX402PaymentHandler
(ctx) => Promise<{ headers: Record<string, string> }> — це точно відповідає підпису гака paymentHandler SDK.
Використання 1: Браузер (MetaMask / WalletConnect)
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
exact схема, тому preferScheme не діє на Solana.
Три, Python: режим приватного ключа
Pythonacedatacloud-x402 використовує пряме підписання приватним ключем (без абстракції EIP-1193), що більше підходить для серверів / виконавців завдань.
Встановлення
EVM (Base / Skale)
Solana
Одноразове схвалення (тільки для EVM вперше)
EVM Base на X402 використовує Permit2, потрібно, щоб гаманець дав Permit2 контракту одноразовеMaxUint256 схвалення. acedatacloud-x402 вбудовано approve_permit2:
Чотири, реальна перевірка виконання
Тестова мета: TS SDK не передає токен, інжектує X402 обробник, може нормально створювати та ініціювати запити (не витрачаючи реальний USDC на ланцюзі для легкого тестування).- Не передаючи
apiToken, SDK створюється без помилок, що підтверджує, що X402 режим дійсно є законною альтернативою токену. createX402PaymentHandlerповертає функцію (хука), SDK використовує її лише при отриманні 402.- Реальне тестування платіжного процесу на ланцюзі, оскільки воно включає реальні витрати USDC, не включено в цей посібник; можна звернутися до X402 інтеграційного посібника для e2e прикладів.
Python сторонаcreate_x402_payment_handlerтакож провела таку ж перевірку — значення, що повертається функцією, є викликаним, при інжекціїpayment_handler=...AceDataCloud(...)створюється без помилок. Обидві сторони узгоджені за змістом.

