@x402api/agent-wallet-cli 0.2.5 → 0.2.7

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.5.
+be updated in place in version 0.2.7.
 
 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.5",
+  "version": "0.2.7",
   "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.5"
+    "@x402api/agent-wallet-core": "0.2.7"
   }
 }

package/skill/SKILL.md

@@ -53,6 +53,10 @@ compromised same-user host.
    address, exact network, asset contract/mint, and QR payload when funding is
    insufficient. Never ask the owner to fund ETH/SOL, send to the token
    contract/merchant recipient, or reveal/import a personal seed.
+6. For a one-off Base wallet balance or funding check, if the operator has not
+   supplied a credential-free Base RPC, set `X402API_BASE_RPC_URL` to the
+   official Base Mainnet endpoint `https://mainnet.base.org`. It is rate-limited
+   and suitable for interactive setup checks, not sustained production traffic.
 
 Keep Base, Solana, and TRON keys and addresses separate. TRON wallet management
 does not mean TRON payment support: the launch payer must reject TRON as coming
@@ -126,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

@@ -10,7 +10,10 @@ is present and uses a stable nonzero exit code.
 - `X402API_WALLET_PASSWORD_FILE`: optional owner-only, single-line passphrase
   file override. Without it, unlocking uses the managed file created by
   `wallet setup`.
-- `X402API_BASE_RPC_URL`: credential-free Base RPC URL.
+- `X402API_BASE_RPC_URL`: credential-free Base RPC URL. For one-off interactive
+  balance and funding checks, Base documents `https://mainnet.base.org` as its
+  official Base Mainnet endpoint. It is rate-limited and is not intended for
+  sustained production traffic.
 - `X402API_SOLANA_RPC_URL`: credential-free Solana RPC URL.
 - `X402API_TRON_RPC_URL`: credential-free TRON RPC URL.
 - `X402API_NOTIFICATION_URL`: credential-free x402api refill endpoint.
@@ -38,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.5 sets it only at wallet creation and
+daily or cumulative budget. Version 0.2.7 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
@@ -96,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

@@ -50,6 +50,11 @@ That operation belongs to trusted merchant server code—not this wallet.
 - 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.5
+artifacts, or protect a wallet on a compromised same-user host. Version 0.2.7
 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