Checkout & Intents

The current frontend uses managed payment intents under the integration surface. This repository does not ship a published @chainwalk/sdk package, so examples here use the actual REST routes mounted by the backend.

The hosted checkout requests a managed payment address during preflight, waits for funds to reach that address, and then advances the purchase on the server. Clients do not build alternate checkout modes locally.

Create an intent

bash

POST /v1/integration/tenants/{tenant}/payments/intents
X-API-Key: $PAYWALL_API_KEY
Content-Type: application/json

{
  "resource_type": "plan",
  "resource_id": "pro_30",
  "wallet": "0xabc...",
  "token": "USDT",
  "chain_id": 84532
}

Preflight and purchase

bash

POST /v1/integration/tenants/{tenant}/payments/intents/{intent_id}/preflight
X-API-Key: $PAYWALL_API_KEY

bash

POST /v1/integration/tenants/{tenant}/payments/intents/{intent_id}/purchase
X-API-Key: $PAYWALL_API_KEY

Tip

Preflight returns the managed payment address for the current intent. Once funds arrive at that address, the backend executes the purchase against the same intent id.

Confirm settlement

bash

POST /v1/integration/tenants/{tenant}/payments/intents/{intent_id}/confirm
X-API-Key: $PAYWALL_API_KEY
Content-Type: application/json

{ "tx_hash": "0x..." }

Issue a checkout token

bash

POST /v1/integration/tenants/{tenant}/payments/checkout/token
X-API-Key: $PAYWALL_API_KEY
Content-Type: application/json

{
  "resource_type": "plan",
  "resource_id": "pro_30",
  "token": "USDT",
  "chain_id": 84532,
  "ttl_seconds": 900
}

Info

Checkout tokens scope the same payment-intent routes to a specific resource and chain. The backend validates those claims when a checkout token is present, but the base integration flow also works directly with a paywall API key and the same managed payment address lifecycle.