PAYMENT-SIGNATURE를 서명한 후 동일한 요청으로 재시도합니다.
차이점은 주문 결제는 계정 토큰이 필요한 플랫폼 API에 속한다는 점입니다; 반면 x402.acedata.cloud의 AI API를 직접 호출하는 경우 X402만 사용할 수 있으며 API Token은 필요하지 않습니다.
주문 준비
Ace Data Cloud 콘솔에 들어가 결제할 주문을 선택하고, 주문 ID를 기록합니다. 아직 주문이 없다면, 요금제 페이지에서 결제 대기 주문을 생성할 수 있습니다. 주문 가격은 페이지에 표시된 내용을 기준으로 하며, X402 402 응답의amount는 최종 서명 기준입니다.
계정 토큰 생성
주문 결제 요청에는 계정 토큰이 필요합니다. 플랫폼 Token 페이지를 열고,platform-v1-... 형식의 token을 생성합니다.
이후 요청에서는 다음을 사용합니다:
402 트리거
먼저PAYMENT-SIGNATURE 없이 한 번 요청을 보냅니다:
accepts가 포함됩니다:
x402Version은 2이고, network는 CAIP-2 식별자를 사용하며, 금액 필드는 amount입니다.
10 Credits 주문을 생성하고 402를 트리거한 프로그램 실행 결과:
다음 거래 기록은 이전 정책에 따른 과거 실측 샘플이며, 금액과 거래 해시는 원본 그대로 유지됩니다. 새 X402 주문에는 더 이상 결제 방식 할인이 적용되지 않습니다; 이번 402 응답의 amount를 서명 및 결제 기준으로 삼으십시오.
- 주문 생성에 성공한 후 상태는
Pending이며, 이때 아직 온체인 결제는 없습니다. - 첫 번째
pay/요청은PAYMENT-SIGNATURE를 포함하지 않았으므로 HTTP 402를 반환합니다. accepts는 Baseexact와 Solanaexact를 동시에 제공하며, 이 튜토리얼에서는 이후 Base를 선택합니다.- 주문 생성 시 가격은
1.26이었으며, 이전 X402 결제 할인 정책 기간에 결제되어 실제 서명 및 정산 금액은1.2USDC이고,1200000atomic USDC에 해당합니다.
resource는 서버가 반환하고 서명에 참여하는 필드이므로, 클라이언트는 그 안의 프로토콜, 경로 또는 주문 ID를 직접 수정해서는 안 됩니다.
서명 후 재시도
주문 결제는@acedatacloud/x402-client 또는 acedatacloud-x402의 저수준 서명 함수를 재사용할 수 있습니다. 아래는 TypeScript 예시입니다:
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이벤트는 결제 주소가 플랫폼 수금 주소로1200000atomic USDC, 즉1.2USDC를 전송했음을 보여 줍니다.
성공 응답 및 영수증
주문 결제가 성공한 후 응답 본문은 주문 정보입니다. 플랫폼은 또한 응답 헤더PAYMENT-RESPONSE에 Base64로 인코딩된 settlement response를 포함하며, 디코딩 후 일반적인 필드는 다음과 같습니다:
대사가 필요한 경우 주문 ID, 결제 지갑 주소,
transaction 및 주문 최종 상태를 함께 저장하는 것이 좋습니다.
주의 사항
- 주문 결제에는 플랫폼 계정 토큰이 필요하며, X402 지갑 서명만으로 완료할 수 없습니다.
amount는 USDC atomic units를 사용하며,1200000은1.2USDC를 나타냅니다.- 수금 주소나 자산 주소를 직접 조합하지 말고, 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만 필요합니다.
