AgentPay SDK: Payment Rails for Agents That Need Approval Before They Spend
An open SDK for agentic payments. Let AI agents make payments, hold funds, and move money across chains with policy enforcement and human approval built in.
At a glance
- What is it?
- AgentPay SDK is an MIT-licensed Rust and Node toolkit that gives AI agents two ways to move money: Link-backed fiat cards and a self-custodial crypto daemon, both gated by policy and human approval. The design is opinionated toward local custody and explicit consent, and the documentation is uneven about what happens when either side fails.
- Who is it for?
- Adopt AgentPay SDK if you are building an agent that must spend real money and you want the approval step to live in the user's Link app or in a local signing daemon rather than in your own server. Do not adopt it if you need Windows support for the Rust runtime, or if you expect the README to explain what happens when a spend request is denied, times out, or is replayed.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 100 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap AgentPay fills: agents that can spend, without handing over the wallet
Most agent frameworks treat tool calls as free. The moment a tool call moves money, the failure modes change: a hallucinated merchant name becomes a real charge, a retry loop becomes duplicate payments, and a prompt injection becomes a transfer. AgentPay SDK exists to put a boundary between the agent's decision and the settlement of funds. The README frames it as two payment paths. Fiat with Link means the user binds a Link account, approves each spend request inside the Link app, and the agent receives a one-time card credential or a Link-backed machine-payment token. Crypto with a local wallet means a self-custodial daemon constructs, signs, and broadcasts transactions while the wallet and approval path stay on the operator's machine. The audience is narrow and specific: teams shipping agents that need to buy something on a user's behalf, and users who are unwilling to pre-fund a custodial balance for that agent to draw down. If your agent only reads data, this SDK is the wrong layer.
Two rails, one CLI: how the fiat and crypto paths actually differ
The two paths are not variations on one mechanism. The fiat path is a request-and-approve loop mediated by Link. The agent asks for a card with a merchant, a URL, an amount, and a context string. The user approves that exact purchase in the Link app before any credential can be used, per the README's own example context. What comes back is a one-time card credential written to a local file with mode 0600, with stdout kept redacted. The crypto path is a local daemon that holds the key material and broadcasts transactions itself. The README describes the daemon as constructing, signing, and broadcasting, which places signing entirely on the operator's machine. Both paths funnel through the same `agentpay` CLI, and both are described as carrying policy enforcement and human approval, though the README does not spell out the policy schema. That is the first real gap. You can see the approval surface in the fiat flow (the Link app) and infer the custody model in the crypto flow (local keys), but the enforcement layer itself is asserted in the project description rather than demonstrated in the material available.
Installing it: the bootstrap script, the environment variables, and what gets written where
The documented fast path is a single command: `curl -fsSL https://wlfi.sh | bash`. The script is interactive by default. It can choose an install directory, download a prebuilt macOS or Linux runtime bundle instead of compiling Cargo or pnpm workspaces, bootstrap Node 20+ if the machine lacks it, and install `agentpay` into a dedicated `AGENTPAY_HOME`. It also detects AI agent targets and installs skill packs for Codex, Claude, Cline, Goose, Windsurf, OpenClaw, portable `~/.config/agents`, legacy `~/.agents`, and matching workspace directories, plus adapters for `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `.github/copilot-instructions.md`, `.clinerules/agentpay-sdk.md`, and a Cursor rule pack. Non-interactive installs set the payment path explicitly with `AGENTPAY_SETUP_PAYMENT_METHOD=fiat`, `=crypto`, or `=none`. The legacy `AGENTPAY_SETUP_RUN_ADMIN_SETUP=yes` still maps to the crypto wallet path. If you only want the skill files and adapters, `curl -fsSL https://wlfi.sh | bash -s -- --skills-only` skips the runtime entirely and installs no `agentpay` binary, no Node, and no wallet files. Source installs run `pnpm install`, `pnpm run build`, `pnpm run install:cli-launcher`, and `pnpm run install:rust-binaries`, with the launcher and Rust runtime both landing in `~/.agentpay/bin`. The README is explicit that Windows does not yet support the Rust daemon or runtime from source, and offers `AGENTPAY_SKIP_RUST_INSTALL=1 pnpm install` for JavaScript-only work on Windows.
The approval loop in practice: what `agentpay link card` returns and what stays redacted
The clearest concrete behaviour in the README is the card creation call. It takes `--payment-method-id`, `--merchant-name`, `--merchant-url`, `--amount`, `--context`, and `--output-file`. The amount in the example is `3500`, and the example context explains that the user will approve the exact purchase in Link before any card credential can be used. Two design choices stand out. First, full card credentials go to a local file with mode 0600 while stdout stays redacted, which means the secret never has to pass through a log line or a terminal scrollback if you route the output correctly. Second, the context string is a required part of the request, which pushes the agent to state why it is spending. That is a useful audit artifact, but it is also plain text supplied by the agent, so it should be treated as a claim rather than a verified reason. The README also mentions `agentpay link payment-methods --json` for listing methods and an advanced passthrough surface under `agentpay link`, including `spend-request`, `mpp`, and `serve`. Third-party programs can call the facade directly through exported functions such as `createLinkCard`, `listLinkPaymentMethods`, and `onboardLinkAccount`, though the README excerpt cuts off mid-import.
Where the design gets thin: policy, failure handling, and the Windows boundary
The project description promises policy enforcement and human approval built in. The README shows the human approval surface clearly for fiat and implies local control for crypto, but it does not document the policy schema, the default limits, or what a denied spend request returns to the caller. For a payments SDK that is a significant omission, because the interesting cases are all negative: a spend request that the user rejects, one that expires before approval, one that the agent retries, and one where the daemon is offline when the transaction should broadcast. None of those are covered in the material available. There is also a platform boundary worth stating plainly. The Rust daemon and runtime are documented as macOS and Linux only, with Windows unsupported from source. Managed wallet bootstrap (`agentpay admin setup`, `agentpay admin tui`, `agentpay admin reset`, `agentpay admin uninstall`) is likewise macOS and Linux, using `launchd` on macOS and system `systemd` on Linux, with auth storage in macOS Keychain or Linux Secret Service. If your build fleet is Windows, you are limited to the JavaScript workspace and the skills-only path. The README also notes that the installer does not configure browser-based relay or web approval services, which is consistent with the local-custody stance but does mean you cannot fall back to a hosted approval UI out of the box.
How it compares to Coinbase AgentKit and Stripe's agent tooling
The closest comparison in the agentic payments space is Coinbase AgentKit, which also targets agents that transact onchain. The difference is where the key and the approval live. AgentKit's documented pattern centres on a wallet provider abstraction with hosted options, and its action providers are designed to plug into frameworks like LangChain. AgentPay SDK takes the opposite stance: the README describes a self-custodial daemon that constructs, signs, and broadcasts locally, with managed wallet setup through `launchd` or `systemd` rather than a hosted signer. That is a real trade-off. Local custody removes a trusted third party from the signing path, and it also means you own the operational burden of keeping the daemon running, rotated, and reachable. On the fiat side the comparison is different again. Stripe's agent tooling and Link's own spend-request flow put approval in a consumer app the user already trusts. AgentPay SDK wraps that flow rather than replacing it, which is why `agentpay link onboard` exists as a first-class command. If you want one SDK that covers both fiat and onchain from a single CLI and you are willing to run a daemon, AgentPay is the more unified surface. If you only need onchain and you want a managed signer, AgentKit's model is less work to operate.
Upgrades, reinstalls, and what the MIT licence does and does not cover
Upgrading is documented as rerunning the installer: `curl -fsSL https://wlfi.sh | bash` for one-click installs, or the four-command source sequence for source installs. There is one specific caveat worth flagging. If you change Rust daemon code from a source checkout, the README says to rerun `npm run install:rust-binaries` so the root-managed daemon picks up the new binaries under `~/.agentpay/bin`. If you only need to reconnect an existing local vault after refreshing the runtime, `agentpay admin setup --reuse-existing-wallet` avoids a full re-bootstrap. The release cadence visible in the material is roughly monthly across v0.3.1, v0.4.0, and v0.5.0, with v0.5.0 dated 2026-06-08. That is a pre-1.0 project, and the README does not describe a stability guarantee or a deprecation policy for the CLI surface, so pinning a version and reading the release notes before upgrading is the reasonable posture. The licence is MIT. That permits commercial use, modification, and redistribution with the copyright notice and permission notice retained, and it disclaims warranty. It does not grant trademark rights, and it does not cover the Link service, the World Liberty Financial hosted endpoints, or any blockchain you connect the daemon to. Those are governed by their own terms. Nothing here is legal advice; if you are shipping this inside a regulated payments product, the licence file is the starting point, not the answer.
Editorial conclusion
Adopt AgentPay SDK if you are building an agent that must spend real money and you want the approval step to live in the user's Link app or in a local signing daemon rather than in your own server. Do not adopt it if you need Windows support for the Rust runtime, or if you expect the README to explain what happens when a spend request is denied, times out, or is replayed. Before committing, verify three things against your own environment: that `agentpay link card` writes credentials to a 0600 file on your filesystem as described, that `agentpay admin setup` picks up your platform's keychain or Secret Service for auth storage, and that the policy enforcement path is documented beyond the one-line mention in the project description.
Community notes