Skip to main content
API 요청에 직접 비용을 지불하는 것 외에, Ace Data Cloud는 X402로 콘솔 주문을 결제하는 것도 지원합니다. 주문 결제와 API 호출의 핵심 프로토콜은 동일합니다: 첫 번째 요청은 402를 반환하고, 클라이언트는 PAYMENT-SIGNATURE를 서명한 후 동일한 요청으로 재시도합니다. 차이점은 주문 결제는 계정 토큰이 필요한 플랫폼 API에 속한다는 점입니다; 반면 x402.acedata.cloud의 AI API를 직접 호출하는 경우 X402만 사용할 수 있으며 API Token은 필요하지 않습니다.

주문 준비

Ace Data Cloud 콘솔에 들어가 결제할 주문을 선택하고, 주문 ID를 기록합니다. 아직 주문이 없다면, 요금제 페이지에서 결제 대기 주문을 생성할 수 있습니다. 주문 가격은 페이지에 표시된 내용을 기준으로 하며, X402 402 응답의 amount는 최종 서명 기준입니다.

계정 토큰 생성

주문 결제 요청에는 계정 토큰이 필요합니다. 플랫폼 Token 페이지를 열고, platform-v1-... 형식의 token을 생성합니다. 이후 요청에서는 다음을 사용합니다:
계정 토큰은 일반 API Token과 다릅니다. 일반 API Token은 API 크레딧을 소비하는 데 사용됩니다; 계정 토큰은 주문 결제와 같은 플랫폼 리소스를 계정을 대표하여 작업하는 데 사용됩니다.

402 트리거

먼저 PAYMENT-SIGNATURE 없이 한 번 요청을 보냅니다:
상태 402가 반환되며, 응답에는 accepts가 포함됩니다:
주문 결제는 공식 x402 v2를 사용합니다: x402Version은 2이고, network는 CAIP-2 식별자를 사용하며, 금액 필드는 amount입니다. 10 Credits 주문을 생성하고 402를 트리거한 프로그램 실행 결과:
다음 거래 기록은 이전 정책에 따른 과거 실측 샘플이며, 금액과 거래 해시는 원본 그대로 유지됩니다. 새 X402 주문에는 더 이상 결제 방식 할인이 적용되지 않습니다; 이번 402 응답의 amount를 서명 및 결제 기준으로 삼으십시오.
결과 설명:
  • 주문 생성에 성공한 후 상태는 Pending이며, 이때 아직 온체인 결제는 없습니다.
  • 첫 번째 pay/ 요청은 PAYMENT-SIGNATURE를 포함하지 않았으므로 HTTP 402를 반환합니다.
  • accepts는 Base exact와 Solana exact를 동시에 제공하며, 이 튜토리얼에서는 이후 Base를 선택합니다.
  • 주문 생성 시 가격은 1.26이었으며, 이전 X402 결제 할인 정책 기간에 결제되어 실제 서명 및 정산 금액은 1.2 USDC이고, 1200000 atomic USDC에 해당합니다.
여기서 resource는 서버가 반환하고 서명에 참여하는 필드이므로, 클라이언트는 그 안의 프로토콜, 경로 또는 주문 ID를 직접 수정해서는 안 됩니다.

서명 후 재시도

주문 결제는 @acedatacloud/x402-client 또는 acedatacloud-x402의 저수준 서명 함수를 재사용할 수 있습니다. 아래는 TypeScript 예시입니다:
동일한 주문을 Base exact로 서명하고 재시도한 후의 프로그램 실행 결과:
온체인 확인 결과:
결과 설명:
  • status 200은 플랫폼 주문 결제 인터페이스가 이번 PAYMENT-SIGNATURE를 수락했음을 나타냅니다.
  • has_x_payment_response True는 응답 헤더에 Base64로 인코딩된 PAYMENT-RESPONSE 영수증이 포함되어 있음을 나타냅니다.
  • settle_header.success=True 및 network=base는 Facilitator가 Base settlement를 완료했음을 나타냅니다.
  • 주문의 최종 상태는 Finished이고, pay_way는 X402이며, pay_id에는 온체인 트랜잭션 해시가 기록됩니다.
  • BaseScan의 Transfer 이벤트는 결제 주소가 플랫폼 수금 주소로 1200000 atomic USDC, 즉 1.2 USDC를 전송했음을 보여 줍니다.

성공 응답 및 영수증

주문 결제가 성공한 후 응답 본문은 주문 정보입니다. 플랫폼은 또한 응답 헤더 PAYMENT-RESPONSE에 Base64로 인코딩된 settlement response를 포함하며, 디코딩 후 일반적인 필드는 다음과 같습니다: 대사가 필요한 경우 주문 ID, 결제 지갑 주소, transaction 및 주문 최종 상태를 함께 저장하는 것이 좋습니다.

주의 사항

  • 주문 결제에는 플랫폼 계정 토큰이 필요하며, X402 지갑 서명만으로 완료할 수 없습니다.
  • amount는 USDC atomic units를 사용하며, 1200000은 1.2 USDC를 나타냅니다.
  • 수금 주소나 자산 주소를 직접 조합하지 말고, 402 응답의 accepts를 기준으로 하세요.
  • 동일한 PAYMENT-SIGNATURE가 반복 제출되면 Facilitator는 nonce를 기준으로 재생 공격 보호를 수행합니다.

결제 실패 응답

PAYMENT-SIGNATURE를 포함하지 않은 첫 번째 HTTP 402는 정상적인 결제 챌린지이며, 결제 실패를 의미하지 않습니다. 서명 후 검증 또는 settlement 실패 시에도 호환성 폴백으로 표준 문자열 error가 유지되며, 안정적인 오류 구조는 extensions.acedatacloud.paymentError에서 반환됩니다:
클라이언트는 우선 code에 따라 현지화해야 하며, 알 수 없는 code는 일반적인 결제 실패로 폴백합니다. charged는 3상태 필드입니다. 결제 전에 명확히 거부된 경우에만 false가 반환됩니다. 필드가 없으면 청구 상태를 알 수 없음을 의미하며, “청구되지 않음”으로 해석해서는 안 됩니다. 현재 주문이 Failed에 진입한 후에는 원래 주문으로 재시도할 수 없으므로, 지갑 문제를 수정한 후 새 주문을 생성하세요. 전체 PAYMENT-SIGNATURE, 지갑 서명, 권한 부여 payload, Facilitator 원본 진단 또는 RPC 응답을 기록하거나 제출하지 마세요. 고객 서비스 조사에는 주문 ID와 공개 오류 code만 필요합니다.