@x402api/agent-wallet-cli 0.2.3 → 0.2.4

package/README.md

@@ -13,7 +13,7 @@ The CLI runs on the buyer or agent host; merchant integrations do not host it
 or receive its keys. A wallet's funded token balance is spend authority, and
 `wallet create --maximum-payment-atomic N` can add a per-payment ceiling. The
 ceiling is not a daily, cumulative, or merchant-specific permission and cannot
-be updated in place in version 0.2.3.
+be updated in place in version 0.2.4.
 
 Run `x402api help --json` for the machine-readable command summary. Unlock
 material is accepted only from standard input or an owner-only file named by

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@x402api/agent-wallet-cli",
-  "version": "0.2.3",
+  "version": "0.2.4",
   "description": "Command-line wallet for autonomous x402 purchases.",
   "license": "MIT",
   "repository": {
@@ -38,6 +38,6 @@
     "lint": "tsc --noEmit -p tsconfig.json"
   },
   "dependencies": {
-    "@x402api/agent-wallet-core": "0.2.3"
+    "@x402api/agent-wallet-core": "0.2.4"
   }
 }

package/skill/references/cli-reference.md

@@ -34,7 +34,7 @@ x402api wallet sweep --wallet NAME --to ADDRESS --json
 `--maximum-payment-atomic` is an optional canonical decimal in atomic units for
 the wallet's supported payment asset. It is enforced on each authorization and
 returns `payment_limit_exceeded` when the exact amount is larger. It is not a
-daily or cumulative budget. Version 0.2.3 sets it only at wallet creation and
+daily or cumulative budget. Version 0.2.4 sets it only at wallet creation and
 does not provide a policy-update command.
 
 Unlocking commands additionally require `X402API_WALLET_PASSWORD_FILE` or an

package/skill/references/merchant-integration.md

@@ -32,6 +32,28 @@ authorization, and must not be added to this exact V1 envelope. The wallet
 creates its own `buyerPaymentIdentifier` when it authorizes a selected payment
 requirement.
 
+## Programmatic charge handoff
+
+A merchant may create a variable-price challenge with the tenant-authenticated
+x402api `POST /v1/charges` endpoint before writing the wallet request envelope.
+That operation belongs to trusted merchant server code—not this wallet.
+
+- The merchant uses the current template `active_version.id` as
+  `resource_version_id`; a resource UUID or `pay_...` public payment ID is not a
+  substitute.
+- One active template may allow multiple rails. The merchant charge supplies
+  exact runtime amounts for a non-empty subset; the wallet independently
+  validates and selects one returned `PAYMENT-REQUIRED.accepts` alternative.
+- The request envelope receives only the exact credential-free protected
+  request and canonical `PAYMENT-REQUIRED` challenge. It never contains the
+  tenant API credential, `resource_version_id`, or a tenant-side API request.
+- Retiring or replacing a template is a merchant concern. The wallet validates
+  the exact issued challenge and must not discover, guess, or rewrite a
+  template UUID.
+
+See the tenant integration guide at
+https://x402api.com/docs/payments/x402/programmatic-charges.
+
 ## Payment submission or artifact handoff
 
 `payment authorize` writes an owner-only artifact once and records its digest

package/skill/references/safety.md

@@ -9,7 +9,7 @@ Base, Solana, and TRON.
 
 An optional `maximumPaymentAtomic` value adds a local ceiling to each payment.
 It does not limit aggregate or daily spend, restrict merchants, revoke existing
-artifacts, or protect a wallet on a compromised same-user host. Version 0.2.3
+artifacts, or protect a wallet on a compromised same-user host. Version 0.2.4
 sets this value only when creating a wallet and has no policy-update command.
 
 Show the exact network, token contract or mint, public address, and requested