Skip to main content
X402는 Coinbase가 제안한 “HTTP 402 청구”의 온체인 결제 프로토콜입니다: 서버는 토큰이 없는 요청에 대해 402 Payment Required를 반환하고, accepts: [...] 필드를 포함하여 수용 가능한 체인 / 자산 / 가격을 나열합니다; 클라이언트는 로컬에서 권한을 서명한 후 (EVM에서는 Permit2 / EIP-712, Solana에서는 SPL 토큰 전송 권한), base64로 인코딩된 envelope을 PAYMENT-SIGNATURE 헤더에 넣어 재전송합니다. 서버는 검증 후 실제로 체인에서 결제하고 비즈니스 결과를 반환합니다.
Ace Data Cloud의 X402 클라이언트는 직접 목표 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(...)를 사용하면 되며, 토큰 모드와 똑같이 보이지만, 기본적으로 호출에 따라 결제되며 사전 충전이 필요하지 않습니다. 본문:
  • TS 측의 “무 토큰 + X402 핸들러 주입” 경로를 실제로 연결했습니다. ([T12 검증](#네 실제 실행 검증))
  • EVM / Solana 두 가지 서명 경로의 차이를 나열했습니다.
  • viem 개인 키 모드, 브라우저 지갑 모드, Python EVMAccountSigner 모드 세 가지 적합성을 제시했습니다.
  • preferScheme / prefer_scheme 이라는 쉽게 실수할 수 있는 필드를 명확히 설명했습니다.

일, 프로토콜 개요 (필독)

성공적인 X402 호출은 3개의 HTTP RTT를 포함합니다:
X402 envelope은 JSON의 일부분으로, base64로 인코딩되어 PAYMENT-SIGNATURE 헤더에 삽입됩니다. 구조(발췌):
envelope의 최상위는 x402Version: 2이며, accepted 객체를 사용하여 이번에 선택한 scheme과 network(CAIP-2 식별자)를 선언합니다. preferScheme / prefer_scheme은 서버가 여러 가지 scheme을 동시에 제공할 때 선호도를 선택하는 데 사용됩니다. 서버가 exact만 노출하면 이 필드는 무시됩니다; upto를 설정했지만 서버가 노출하지 않으면 첫 번째 일치 항목으로 되돌아갑니다.

이, TypeScript: 브라우저 지갑 + 서버 viem 두 가지 사용법

설치

실제 테스트한 버전 번호:

createX402PaymentHandler 완전 서명

반환 값은 (ctx) => Promise&lt;{ headers: Record<string, string> }>로, SDK의 paymentHandler 훅 서명과 정확히 일치합니다.

사용법 1: 브라우저 (MetaMask / WalletConnect)

첫 번째 호출 시 브라우저는 두 번의 서명 요청을 표시합니다: 첫 번째는 Permit2에 대한 USDC의 일회성 승인(금액은 MaxUint256, 체인에 기록됨); 두 번째는 X402 envelope의 EIP-712 서명(체인에 올라가지 않으며, facilitator 검증을 위해서만 사용됨). 이후 호출은 두 번째 서명만 필요하며, 경험상 “서명 한 번 클릭 → 결과 받기”로 보입니다.

사용법 2: Node 서버 + viem 개인 키 (백엔드 / CLI에 적합)

@acedatacloud/x402-client는 TS 측에서 EIP-1193 provider만 수용합니다 — 개인 키를 직접 관리하지 않습니다. Node / CLI 시나리오에서는 표준 방법으로 viem를 사용하여 개인 키를 WalletClient로 포장한 후, @ethereumjs/util 또는 viem 내부의 EIP-1193 적응을 사용합니다.
viem의 EIP-1193 적응이 충분히 안정적이지 않다고 생각되면, 더 낮은 수준의 signEVMUptoPayment를 사용할 수 있으며, accepts → signed envelope → PAYMENT-SIGNATURE header 경로를 직접 연결하여 SDK 훅을 건너뛸 수 있습니다. 그러나 여전히 createX402PaymentHandler를 우선 선택하는 것이 좋습니다. 프로토콜 업그레이드를 직접 유지 관리할 필요가 없습니다.

사용법 3: Solana

Solana 체인에서는 현재 오직 exact scheme만 노출되므로 Solana에서는 preferScheme이 작동하지 않습니다.

삼、Python: 개인 키 모드

Python의 acedatacloud-x402는 개인 키로 직접 서명하는 경로를 따릅니다(이것은 EIP-1193 추상화가 없습니다), 서버 측 / 작업 실행기에 더 적합합니다.

설치

실제 테스트 버전 번호:

EVM(기본 / Skale)

Solana

일회성 승인(오직 EVM 최초)

EVM Base에서 X402는 Permit2를 사용하므로, 지갑은 USDC에 대해 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 모드”와의 비교

여섯, 일반적인 함정

  1. chat 클래스는 preferScheme=upto 여야 합니다: exact를 사용하면 facilitator가 maxAmountRequired(실제 사용량이 아님)에 따라 USDC를 차감합니다.
  2. Node 측에서 createX402PaymentHandler에 원시 개인 키를 전달하지 마세요: TS 패키지는 { privateKey }를 수용하지 않으며, EIP-1193 provider로 포장해야 합니다(추천: viem WalletClient).
  3. 첫 호출은 이중 서명입니다: 첫 번째로 Permit2 approve에 서명(온체인, 가스 필요), 두 번째로 X402 envelope에 서명(온체인 아님). 이후 호출은 두 번째 서명만 남습니다.
  4. Solana에는 Permit2 개념이 없습니다: 직접 SPL 토큰 전송 권한에 서명하며, approve가 필요하지 않습니다; 그러나 현재 Solana 체인에서는 exact만 지원합니다.
  5. 비즈니스 오류와 결제 오류 구분: 402 → 핸들러 실패 시 X402SignError를 발생시킵니다(구체적인 유형은 체인에 따라 다름); 이후 재전송 시 비즈니스 인터페이스의 오류(401 / 422 / 5xx)는 여전히 일반 SDK 예외로 분류됩니다.
  6. viem에 가장 안정적인 적합한 작성법: evmProvider: walletClient as any는 타입 검사를 잃지만 호환성이 가장 좋습니다; 타입을 유지하고 싶다면 viem의 .transport.request로 { request } 객체를 따로 포장하여 전달해야 합니다.

더 알아보기