@x402api/agent-wallet-cli 0.2.6 → 0.2.7
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md
CHANGED
|
@@ -13,7 +13,7 @@ The CLI runs on the buyer or agent host; merchant integrations do not host it
|
|
|
13
13
|
or receive its keys. A wallet's funded token balance is spend authority, and
|
|
14
14
|
`wallet create --maximum-payment-atomic N` can add a per-payment ceiling. The
|
|
15
15
|
ceiling is not a daily, cumulative, or merchant-specific permission and cannot
|
|
16
|
-
be updated in place in version 0.2.
|
|
16
|
+
be updated in place in version 0.2.7.
|
|
17
17
|
|
|
18
18
|
Run `x402api wallet setup --json` once on a fresh host. It idempotently creates
|
|
19
19
|
a high-entropy managed unlock file under the private x402api data root; the
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@x402api/agent-wallet-cli",
|
|
3
|
-
"version": "0.2.
|
|
3
|
+
"version": "0.2.7",
|
|
4
4
|
"description": "Command-line wallet for autonomous x402 purchases.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"repository": {
|
|
@@ -38,6 +38,6 @@
|
|
|
38
38
|
"lint": "tsc --noEmit -p tsconfig.json"
|
|
39
39
|
},
|
|
40
40
|
"dependencies": {
|
|
41
|
-
"@x402api/agent-wallet-core": "0.2.
|
|
41
|
+
"@x402api/agent-wallet-core": "0.2.7"
|
|
42
42
|
}
|
|
43
43
|
}
|
package/skill/SKILL.md
CHANGED
|
@@ -130,6 +130,10 @@ the exact artifact and buyer payment identifier. Never authorize the same
|
|
|
130
130
|
request again merely because a submission result is unknown. Local abandonment
|
|
131
131
|
does not revoke a signature or reverse settlement.
|
|
132
132
|
|
|
133
|
+
When `payment status` includes `lastPaymentId`, preserve it as the merchant's
|
|
134
|
+
durable reconciliation handle. It is public settlement metadata, not a new
|
|
135
|
+
authorization, and it never permits replacing the existing artifact.
|
|
136
|
+
|
|
133
137
|
Stop on unsupported profiles, changed request bytes, corrupt artifacts,
|
|
134
138
|
expired challenges, unexpected recipients, or contradictory settlement data.
|
|
135
139
|
Do not work around these errors by changing networks, assets, wallets, or
|
|
@@ -41,7 +41,7 @@ x402api wallet sweep --wallet NAME --to ADDRESS --json
|
|
|
41
41
|
`--maximum-payment-atomic` is an optional canonical decimal in atomic units for
|
|
42
42
|
the wallet's supported payment asset. It is enforced on each authorization and
|
|
43
43
|
returns `payment_limit_exceeded` when the exact amount is larger. It is not a
|
|
44
|
-
daily or cumulative budget. Version 0.2.
|
|
44
|
+
daily or cumulative budget. Version 0.2.7 sets it only at wallet creation and
|
|
45
45
|
does not provide a policy-update command.
|
|
46
46
|
|
|
47
47
|
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.
|
|
|
99
99
|
`pay` combines authorization and first submission; explicit commands are safer
|
|
100
100
|
when a merchant-specific integration owns the request lifecycle.
|
|
101
101
|
|
|
102
|
+
If the merchant returns a canonical x402api settlement UUID as `paymentId` or
|
|
103
|
+
`payment_id`, `payment status` exposes it as `lastPaymentId`. HTTP `202`, `503`,
|
|
104
|
+
timeout, or restart never clears that identifier or replaces the authorization.
|
|
105
|
+
|
|
102
106
|
## Stable error routing
|
|
103
107
|
|
|
104
108
|
- `password_required`, `wallet_locked`: request operator unlock assistance;
|
|
@@ -50,6 +50,11 @@ That operation belongs to trusted merchant server code—not this wallet.
|
|
|
50
50
|
- Retiring or replacing a template is a merchant concern. The wallet validates
|
|
51
51
|
the exact issued challenge and must not discover, guess, or rewrite a
|
|
52
52
|
template UUID.
|
|
53
|
+
- After authorization, trusted merchant code submits the exact artifact to
|
|
54
|
+
`POST /v1/charges/{charge_id}/payments` with its tenant API credential. The
|
|
55
|
+
wallet never receives that credential. The merchant should return the
|
|
56
|
+
durable `payment_id` as `paymentId` so the wallet can retain it across `202`,
|
|
57
|
+
`503`, process restart, and exact reconciliation.
|
|
53
58
|
|
|
54
59
|
See the tenant integration guide at
|
|
55
60
|
https://x402api.com/docs/payments/x402/programmatic-charges.
|
|
@@ -9,7 +9,7 @@ Base, Solana, and TRON.
|
|
|
9
9
|
|
|
10
10
|
An optional `maximumPaymentAtomic` value adds a local ceiling to each payment.
|
|
11
11
|
It does not limit aggregate or daily spend, restrict merchants, revoke existing
|
|
12
|
-
artifacts, or protect a wallet on a compromised same-user host. Version 0.2.
|
|
12
|
+
artifacts, or protect a wallet on a compromised same-user host. Version 0.2.7
|
|
13
13
|
sets this value only when creating a wallet and has no policy-update command.
|
|
14
14
|
|
|
15
15
|
Show the exact network, token contract or mint, public address, and requested
|