@paybox-sh/sdk 0.7.0 → 0.8.1

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
@@ -1,12 +1,13 @@
1
1
  # @paybox-sh/sdk
2
2
 
3
- Typed Node SDK and `paybox` CLI for the Paybox agent API. It mirrors the MCP tool
3
+ Typed Node SDK and `paybox` CLI for the PayBox agent API. It mirrors the MCP tool
4
4
  surface — `list_credentials`, `request_payment`, `claim_payment_credentials`,
5
5
  `request_wallet_sign`, `request_secret`, `request_swap`, `discover_services`,
6
6
  `pay_x402`, `use_service`, `get_portfolio`, `get_buy_link`,
7
- `request_account_change`, `get_request`, and the plugin tools (`world_*`,
7
+ `request_account_change`, `get_request`, and read-only plugin tools (`world_*`,
8
8
  `hyperliquid_*`) — but talks to the REST API directly, with no MCP host and no
9
9
  signing iframe.
10
+ Geofenced World money tools are MCP-only.
10
11
 
11
12
  Wallet signing is **non-custodial and runs in-process**: the SDK reuses the exact
12
13
  signing core from the wallet-sign iframe (`@paybox/mcp-app`), builds the chain
@@ -20,18 +21,26 @@ pnpm add @paybox-sh/sdk # library
20
21
  npx @paybox-sh/sdk login # or use the CLI directly
21
22
  ```
22
23
 
24
+ Driving this CLI from an agent? [`SKILL.md`](SKILL.md) ships in the package and
25
+ describes the install and login flow as an agent skill: what the human has to do
26
+ (approve wallets, paste one signing key), and what the agent should not do
27
+ around it.
28
+
23
29
  ## CLI
24
30
 
25
31
  ```bash
26
32
  # Authenticate: OAuth in the browser (approve with a passkey), or store a key.
27
33
  # `paybox login` is a guided two-step: OAuth, then it opens the app to provision
28
34
  # a wallet signing key and prompts you to paste the `pbxk1.` token back.
29
- paybox login # OAuth 2.1 + PKCE, then provision a key
35
+ # The OAuth step is a device-code grant, so the browser that approves does not
36
+ # have to be on the machine running the CLI.
37
+ paybox login # device-code OAuth, then provision a key
30
38
  paybox login --no-provision # OAuth only, skip the key step
31
39
  paybox login --key pbx_live_… # personal API key instead (no OAuth)
32
- paybox login --signing-key pbxk1.… # supply the signing key non-interactively
40
+ PAYBOX_SIGNING_KEY=pbxk1.… paybox login # supply the signing key non-interactively
33
41
 
34
42
  paybox credentials # list usable credentials
43
+ # `--credential <id>` below is the `credential.id` from that list, not the wallet name.
35
44
  paybox pay --credential <id> --merchant Acme --url https://acme.com --amount 1999
36
45
  paybox secret --credential <id> --purpose "deploy" # one-time token
37
46
  paybox secret --credential <id> --raw # raw value (grant-gated)
@@ -44,13 +53,13 @@ paybox discover --raw "weather api" # debug: uncurated compact summaries
44
53
  paybox pay-x402 --credential <id> --url https://svc/api --accepts @accepts.json
45
54
  paybox use-service --credential <id> --url https://svc/api # paybox pays + fetches
46
55
  paybox claim <request_id> # claim an approved payment's card (one-time)
47
- paybox buy-link --credential <id> --amount-usd 50 # MoonPay on-ramp URL for a wallet
56
+ paybox buy-link --credential <id> --amount-usd 50 # defaults EVM funding to Base
57
+ paybox buy-link --credential <id> --destination eip155:1 --currency eth
48
58
  paybox account-change --note "need a wallet grant" # manage_url for the user to open
49
59
  paybox request <request_id> --wait # poll a pending request
50
60
 
51
61
  # Plugins (enable them in the paybox app first)
52
62
  paybox world markets --status active # browse prediction markets
53
- paybox world buy --credential <id> --mint <outcome-mint> --size 10 --wait
54
63
  paybox hyperliquid markets # spot discovery
55
64
 
56
65
  paybox version # installed version (+ update check)
@@ -66,13 +75,8 @@ clears `~/.config/paybox` and prints the `npm rm -g` line (a package can't remov
66
75
  its own binary). For project installs use `pnpm up`/`pnpm rm`, or `npx
67
76
  @paybox-sh/sdk@latest` to always run the latest without installing.
68
77
 
69
- `sign`, `swap`, `pay-x402`, `use-service`, and the `world` trade commands
70
- complete in-process when a `pbxk1.` signing key is configured and the operation
71
- clears immediately (autonomous grant). When the grant requires approval — World
72
- trades always do — pass `--wait`: the CLI waits for your passkey approval in the
73
- app and then signs in-process (there is no signing window on this surface).
74
- Without `--wait` the command returns `pending_approval`; approve in the app,
75
- then re-run or poll `paybox request <id>`.
78
+ `sign`, `swap`, `pay-x402`, and `use-service` can complete in-process with a
79
+ configured `pbxk1.` key. World buy/sell/redeem are MCP-only.
76
80
 
77
81
  For a Solana `swap` the SDK re-pins a fresh recent blockhash immediately before
78
82
  signing (parity with the signing window — the quote-time blockhash expires
@@ -93,14 +97,18 @@ import { PayboxClient } from "@paybox-sh/sdk";
93
97
  const paybox = PayboxClient.fromConfig(); // reads ~/.config/paybox + env
94
98
  // or: new PayboxClient({ apiKey: "pbx_live_…", signingKey: "pbxk1.…" });
95
99
 
96
- const creds = await paybox.listCredentials();
100
+ const { credentials, ungranted } = await paybox.listCredentials();
97
101
  const pay = await paybox.requestPayment({
98
- credentialId: creds[0].credential.id,
102
+ credentialId: credentials[0].credential.id,
99
103
  merchant: "Acme",
100
104
  merchantUrl: "https://acme.com",
101
105
  amountCents: 1999,
102
106
  });
103
107
 
108
+ // Ungranted credentials the user owns but hasn't granted this connector — pass
109
+ // an id to request_account_change's `add` to ask for access.
110
+ console.log(ungranted.map((c) => `${c.name} (${c.kind})`));
111
+
104
112
  const sig = await paybox.requestWalletSign({
105
113
  credentialId: walletId,
106
114
  chain: "eip155:8453",
@@ -134,6 +142,10 @@ env vars on shared Windows machines.
134
142
 
135
143
  ## Develop
136
144
 
145
+ `pnpm-lock.yaml` also contains the `../mcp-app` importer because this SDK
146
+ consumes the iframe's signing core through `file:../mcp-app`. The iframe build
147
+ shares this dependency resolution but keeps its installed modules separate.
148
+
137
149
  ```bash
138
150
  pnpm install
139
151
  pnpm typecheck
package/SKILL.md ADDED
@@ -0,0 +1,121 @@
1
+ ---
2
+ name: PayBox CLI setup
3
+ description: >-
4
+ Install and log in to the PayBox CLI (@paybox-sh/sdk) so an agent can pay,
5
+ sign, and hold wallet, card, and secret credentials on the user's behalf. Use
6
+ when the user says "install PayBox", "set up PayBox", "instalar PayBox", or
7
+ asks an agent to connect their PayBox wallet.
8
+ ---
9
+
10
+ # PayBox CLI setup
11
+
12
+ The user asks to install PayBox. Two things need them: they approve wallet
13
+ access with a passkey, and they paste one signing key. Everything else is yours,
14
+ and they should not see it happen.
15
+
16
+ ## Install
17
+
18
+ ```bash
19
+ npm install -g @paybox-sh/sdk
20
+ ```
21
+
22
+ The CLI runs wherever you run it, which is often not the user's own machine.
23
+ That is fine: login uses an OAuth device-code grant, so the browser that
24
+ approves does not have to be the one the CLI can reach.
25
+
26
+ Never delete or overwrite an existing config directory. To isolate a run from
27
+ credentials the user already has, point `PAYBOX_CONFIG_DIR` at a fresh
28
+ directory.
29
+
30
+ ## Log in
31
+
32
+ Run this once, in the same turn the user asks:
33
+
34
+ ```bash
35
+ paybox login
36
+ ```
37
+
38
+ Add `--base-url` and `--app-url` for an environment other than the default.
39
+
40
+ The command drives the whole flow itself. Do not reimplement any of it: it
41
+ registers a client, starts device authorization, prints a verification URL and a
42
+ short user code, tries to open that URL locally, polls until the user approves,
43
+ then opens the signing-key page and prompts for the key.
44
+
45
+ Login writes progress to stderr as plain prose, not JSON. Watch for the
46
+ verification URL and the `Code:` line.
47
+
48
+ ### Step 1 — Authorize wallets
49
+
50
+ The moment login prints the verification URL and code, put **one** message in
51
+ front of the user: a markdown link labeled **Authorize wallets** pointing at that
52
+ URL, plus the code.
53
+
54
+ Send that link even though the CLI also tries to open a browser. When the CLI
55
+ is not on the user's machine, that local open is useless or invisible, and your
56
+ message is the only way they reach the page.
57
+
58
+ The user approves in the browser. If the link opens the PayBox mobile app and
59
+ errors instead, have them open it in a browser.
60
+
61
+ Then wait. The poll is the continue signal. Do not ask the user to type `done`,
62
+ confirm, or send a screenshot, and do not end your turn while login is running.
63
+ If the code expires before they approve, run `paybox login` again for a fresh
64
+ one rather than reusing the old link.
65
+
66
+ ### Step 2 — Paste the signing key
67
+
68
+ After approval, login opens the signing-key page and prompts for the key.
69
+ Present a **masked input** for the `pbxk1.` value and write what the user gives
70
+ you to that prompt's stdin.
71
+
72
+ Pass it through the prompt, or set `PAYBOX_SIGNING_KEY` before running `login`
73
+ when nothing is attached to stdin. Never pass it as `login --signing-key <value>`
74
+ on the command line: an argument lands in shell history and is visible to anyone
75
+ who can list processes.
76
+
77
+ Do not ask the user to click the signing-key link, it is already open. Do not
78
+ show the key field before that page has opened, and do not open it twice.
79
+
80
+ Wallet signing is non-custodial: the key stays on the user's machine and PayBox
81
+ never holds it. Never print, log, or echo it.
82
+
83
+ ### Step 3 — Confirm
84
+
85
+ ```bash
86
+ paybox --json whoami
87
+ ```
88
+
89
+ `canSign` must be `true`. If it is `false` the key did not save; redo step 2
90
+ rather than continuing, because signing and swaps will fail without it.
91
+
92
+ ## What the user sees
93
+
94
+ From the install request until `canSign` is `true`, exactly two messages, in
95
+ this order:
96
+
97
+ 1. The **Authorize wallets** link plus the code.
98
+ 2. The masked `pbxk1.` field, after the signing-key page has opened.
99
+
100
+ Nothing else. No "Installing…", "Opening…", "Got it", no CLI version, package
101
+ manager, config path, or request id, and no narration of a retry or fallback. If
102
+ something is blocked, switch approaches quietly. If you have nothing they need
103
+ to act on, send nothing.
104
+
105
+ Match the user's language. Default to English unless they write otherwise.
106
+
107
+ Once `canSign` is `true`, show them what they now have: `paybox --json
108
+ credentials` for the granted wallets, then `paybox --json portfolio --address
109
+ <wallet>` for balances. Every `--credential` takes the `credential.id` from that
110
+ list; a wallet's name is not an id and the command will refuse it. Render a
111
+ compact table, never addresses or raw JSON. The CLI cannot create wallets; it
112
+ uses what the user granted during authorization.
113
+
114
+ ## A setup that went wrong
115
+
116
+ - The user had to prompt you after approving wallet access.
117
+ - The key field appeared before the signing-key page opened.
118
+ - You asked the user to click the signing-key link, or to type `done`.
119
+ - You opened either page twice.
120
+ - Setup chat contained anything besides those two messages.
121
+ - A token, API key, or `pbxk1.` value reached the transcript.