CAI 결제 루프: SaaS 제품이 호스팅 액션, x402 및 결제 의무를 사용하여 에이전트 결제를 받는 방법

SaaS(Software as a Service) 제품이 AI 에이전트가 자신의 서비스를 비용 지불하도록 하려면, 단순한 접근 방식은 청구서를 생성하고 에이전트가 이를 사람에게 전달하여 신용카드를 꺼내도록 기대하는 것입니다. 이는 에이전트 워크플로우를 깨뜨립니다. 에이전트는 체크아웃 양식이 아니라 코드에서 호출할 수 있는 결제 주소가 필요합니다.

CAI는 바로 그 주소를 제공합니다. 결제 루프(billing loop)는 세 가지 계층으로 작동합니다: 호스팅 액션을 통한 일회성 체크아웃, x402를 통한 요청당 청구, 그리고 결제 의무(payment mandates)를 통한 반복 지출입니다. 각 계층은 동일한 수탁형 지갑 인프라(custodial wallet infrastructure)를 기반으로 구축되며, 제품의 결제 스택 내에서 각각 고유한 역할을 수행합니다.

계층 1: 호스팅 액션을 통한 일회성 체크아웃

새 사용자가 귀하의 SaaS에 가입하고 플랜을 선택한 후 체크아웃 페이지에 도달합니다. 백엔드에서 Stripe 양식을 보여주는 대신, action_type: "deposit"과 금액을 포함하여 POST /create-hosted-action을 호출합니다. CAI는 호스팅 액션 URL을 반환합니다.

POST /create-hosted-action
Content-Type: application/json
Authorization: Bearer ***
...

응답:

{
  "ok": true,
  "url": "https://cai.com/act/abc123..."
...

귀하의 앱은 사용자를 해당 URL로 리디렉션합니다. 사용자는 자신의 CAI 지갑 잔액을 보고 토큰을 선택한 후 결제를 확인합니다. 내부적으로, 사용자의 CAI 계정은 가맹점 주소로 수탁 이체(custodial transfer)를 실행합니다. 완료되면 웹훅이 발생하고 구독이 활성화됩니다.

가맹점 계정도 없고, 카드 네트워크도 없으며, 제3자 프로세서로 리디렉션할 필요도 없습니다. 사용자의 CAI 지갑 자체가 결제 수단이며, 호스팅 액션 URL이 체크아웃 페이지입니다.

계층 2: x402를 통한 요청당 청구

API 및 에이전트 대상 서비스의 경우, 체크아웃 페이지는 너무 느립니다. 에이전트는 동일한 요청에서 결제를 하고 응답을 받아야 합니다. 바로 여기에 x402 (HTTP 402 Payment Required)가 사용됩니다.

귀하의 API 엔드포인트는 다음과 같은 결제 인증(payment challenge)과 함께 HTTP 402를 반환합니다:

호출 에이전트는 CAI에 도전 과제(challenge) 세부 정보와 함께 POST /x402-payment-prepare를 호출하고, 사용자가 확인하거나 (또는 사전 승인된 위임장(mandate)이 이를 커버하며), POST /x402-payment-execute가 결제를 정산합니다. 에이전트는 증거(proof)와 함께 원래 API 호출을 재시도하고, 서버는 응답을 반환하기 전에 온체인에서 거래를 검증합니다.

청구는 월별이 아닌 요청당입니다. 사용자는 실제로 사용하는 만큼만 지불하며, 에이전트는 신용카드를 입력할 필요가 없습니다.

Tier 3: 위임장(payment mandates)을 통한 반복 지출

요청당 승인은 소액 결제에는 유효하지만, 에이전트가 건당 $2를 지불하는 일일 배치 작업(daily batch jobs)을 실행할 때는 무리가 됩니다. 사용자는 모든 요청을 확인해야 하므로 자동화의 목적에 위배됩니다.

위임장이 이를 해결합니다. 사용자는 POST /payment-mandate-create로 위임장을 생성합니다:

{
  "merchant_domain": "api.example.com",
  "max_amount_per_payment_usd": "5"
... 
}

사용자는 호스팅된 URL을 통해 위임장에 승인합니다 (일회성). 그 후, 일일 한도 및 건당 한도 내에서 api.example.com으로부터 발생하는 모든 x402 결제는 자동 정산됩니다. 에이전트는 사용자에게 방해를 주지 않고 지불하며, 위임장은 에이전트가 오작동할 경우 피해액을 제한합니다.

전체 루프

이를 종합하면, SaaS 청구 세션은 다음과 같이 작동합니다:

1. 발견 (Discovery): 에이전트는 wallet_balances를 호출하여 사용자가 자금을 보유하고 있는지 확인합니다. 그렇지 않다면, create_deposit_link가 충전 URL을 전송합니다.
2. 결제 (Checkout): 일회성 결제의 경우, action_type: "deposit"이 포함된 create-hosted-action 또는 플랜별 금액으로 진행됩니다.
3. 실행 (Execution): 사용자가 호스팅 액션 페이지에서 확인합니다. CAI는 정산(settle)을 위해 POST /wallet-custodial-transfer를 호출합니다.
4. 검증 (Verification): 웹훅이 POST /transfer-status와 함께 트랜잭션 해시(tx hash)를 호출하여 정산을 확인합니다.
5. 영수증 (Receipt): 거래는 GET /wallet-activity-list에 나타나고, 확인 이메일은 사용자의 @cai.com 메일함으로 도착합니다.
6. 반복 (Repeat): 제품이 x402를 지원하는 경우, 후속 요청은 결제 페이지 없이 승인(mandate) 흐름을 통해 진행됩니다.

이것이 대체하는 것

CAI 청구 루프는 SaaS가 별도로 필요로 했을 세 가지 시스템을 대체합니다: 결제 처리기(payment processor)(Stripe 등), API 액세스를 위한 요청별 청구 계층, 그리고 구독을 위한 반복 청구 시스템입니다. 이 모든 것이 하나의 수탁 지갑(custodial wallet)과 하나의 API 계약으로 통합됩니다.

안전장치(guardrails)가 내장되어 있습니다: 모든 결제에 걸쳐 일일 $200 자동 한도, 신규 수취인 확인 단계(사용자가 각 가맹점의 첫 결제를 명시적으로 확인해야 함), 그리고 무분별한 지출을 방지하는 승인 상한선이 있습니다. 사용자는 통제권을 유지하고; 에이전트는 그 범위 내에서 빠르게 움직입니다.

이 패턴에 대한 버그 보고 및 피드백은 항상 읽고 있습니다 -- 댓글로 회신해 주시면 팀에서 24시간 이내에 답변드리겠습니다.