@x402api/agent-wallet-cli 0.2.6 → 0.2.8

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.6.
+be updated in place in version 0.2.8.
 
 Run `x402api wallet setup --json` once on a fresh host. It idempotently creates
 a high-entropy managed unlock file under the private x402api data root; the

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@x402api/agent-wallet-cli",
-  "version": "0.2.6",
+  "version": "0.2.8",
   "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.6"
+    "@x402api/agent-wallet-core": "0.2.8"
   }
 }

package/skill/SKILL.md

@@ -130,6 +130,10 @@ the exact artifact and buyer payment identifier. Never authorize the same
 request again merely because a submission result is unknown. Local abandonment
 does not revoke a signature or reverse settlement.
 
+When `payment status` includes `lastPaymentId`, preserve it as the merchant's
+durable reconciliation handle. It is public settlement metadata, not a new
+authorization, and it never permits replacing the existing artifact.
+
 Stop on unsupported profiles, changed request bytes, corrupt artifacts,
 expired challenges, unexpected recipients, or contradictory settlement data.
 Do not work around these errors by changing networks, assets, wallets, or

package/skill/references/cli-reference.md

@@ -41,7 +41,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.6 sets it only at wallet creation and
+daily or cumulative budget. Version 0.2.8 sets it only at wallet creation and
 does not provide a policy-update command.
 
 On a fresh host, `wallet setup` atomically creates one high-entropy managed
@@ -99,6 +99,10 @@ bounded response body and `PAYMENT-RESPONSE` evidence in owner-only files.
 `pay` combines authorization and first submission; explicit commands are safer
 when a merchant-specific integration owns the request lifecycle.
 
+If the merchant returns a canonical x402api settlement UUID as `paymentId` or
+`payment_id`, `payment status` exposes it as `lastPaymentId`. HTTP `202`, `503`,
+timeout, or restart never clears that identifier or replaces the authorization.
+
 ## Stable error routing
 
 - `password_required`, `wallet_locked`: request operator unlock assistance;

package/skill/references/merchant-integration.md

@@ -31,6 +31,10 @@ integration. It is not the buyer payment identifier, does not affect the token
 authorization, and must not be added to this exact V1 envelope. The wallet
 creates its own `buyerPaymentIdentifier` when it authorizes a selected payment
 requirement.
+`challengeDigest` is the authoritative `charge_digest` returned by x402api
+programmatic charge creation. Copy it unchanged. Do not derive it from
+`PAYMENT-REQUIRED`; that hash is not the frozen server challenge and the wallet
+rejects it before signing.
 
 ## Programmatic charge handoff
 
@@ -45,11 +49,17 @@ That operation belongs to trusted merchant server code—not this wallet.
   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
+  request, canonical `PAYMENT-REQUIRED` challenge, and authoritative
+  `charge_digest` mapped to `challengeDigest`. 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.
+- After authorization, trusted merchant code submits the exact artifact to
+  `POST /v1/charges/{charge_id}/payments` with its tenant API credential. The
+  wallet never receives that credential. The merchant should return the
+  durable `payment_id` as `paymentId` so the wallet can retain it across `202`,
+  `503`, process restart, and exact reconciliation.
 
 See the tenant integration guide at
 https://x402api.com/docs/payments/x402/programmatic-charges.

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.6
+artifacts, or protect a wallet on a compromised same-user host. Version 0.2.8
 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