An AI agent can decide to pay someone all day long. What it can't do is actually move the money — that requires a bank connection, a ledger, a compliance posture, and someone willing to be liable when a bot sends $40,000 to the wrong account. Payman is the layer that closes that gap: it gives an agent a funded wallet and a set of rules you control, so it can send real money to a human, another agent, or a crypto wallet — but only inside limits it has no power to change.

If your agent only reads and reasons, you don't need this. The moment it should disburse — pay a contractor, settle an invoice, pay another agent for a task, push a marketplace payout — you need money movement that is automatic in execution and bounded in authority. That's the whole product.

The model: fund, then fence#

Payman's design is one idea repeated everywhere: the agent proposes, the policy disposes. You fund a wallet — in USD or USDC — and then you define the fence around it: per-transaction caps, daily limits, approval thresholds above a certain amount, and an allowlist of approved payees. The agent operates inside that fence. It never holds raw access to the underlying funds, and it can't rewrite its own limits.

Every payment is validated against the policy before it settles, then logged and auditable. That matters for two reasons a founder feels immediately: you can prove after the fact exactly what the agent paid and why, and — more important — a compromised or prompt-injected agent can't exceed the ceiling you set. The worst case is bounded by your caps, not by the agent's judgment. That's the correct way to think about any agent that touches money: assume it will occasionally be wrong or manipulated, and size the blast radius accordingly.

Who it's for#

Builders shipping agents that need to send money without a human clicking pay each time. Bill-pay and procurement agents. Marketplace payout bots. Agents that pay other agents — the emerging pattern where autonomous services settle with each other, the same problem the agent payment protocols are racing to standardize. Payman is the pragmatic, bank-backed way to do it today, without waiting for a protocol war to resolve.

Start in five minutes — on test money#

You request an invite, register, and enable Developer Mode to get a clientId and clientSecret. Then it's a normal SDK:

# Python
pip install paymanai
# TypeScript (Node 20+)
npm install @paymanai/payman-ts
import { PaymanClient } from "@paymanai/payman-ts";
import "dotenv/config";

const payman = PaymanClient.withCredentials({
  clientId: process.env.PAYMAN_CLIENT_ID!,
  clientSecret: process.env.PAYMAN_CLIENT_SECRET!,
});

// Drive it in natural language — the whole loop, on test funds:
await payman.ask("List all wallets and their balances");
await payman.ask("Create a payee of type Test Rails named John Doe");
await payman.ask("Send 10 TSD to John Doe");

The key detail: TSD is "Test Dollars," Payman's sandbox currency. You can build and run the entire create-payee-then-pay flow before a single real cent moves — which is exactly how you should be prototyping anything that spends money. The ask() interface is the fast path; under it, the same operations are available as direct API calls (amountDecimal plus a paymentDestinationId) when you want deterministic control instead of a natural-language instruction. PayKit, Payman's toolkit, drops the same capabilities into Vercel AI SDK, LangChain, and MCP so your existing agent can call it as a tool.

What it costs#

Payman charges transaction fees on live payments — a small percentage plus a flat fee per transaction, in the shape of Stripe's model. There is no simple public self-serve price list: the real number depends on your payment workflows, banking rails, approval controls, and volume, so live pricing is a sales conversation, not a pricing page. The practical read for a team of one: build and validate against TSD for free, prove the workflow, and only then find out what production costs for your volume.

The honest caveats#

Two things to weigh. First, this is infrastructure with a human behind the counter — custody sits with Fifth Third Bank, processing runs through Stripe, and Payman reports SOC 2 and PCI compliance. That's reassuring for a payments product and also means onboarding isn't instant self-serve; there's an invite and, for production, real KYC.

Second, letting an agent hold a wallet is only as safe as the fence. The policy layer is the security boundary, not the model — so the entire discipline is setting caps before you turn the agent loose, and setting them lower than feels necessary. If you wouldn't hand the equivalent authority to a brand-new employee on day one, don't hand it to the agent either. Payman gives you the fence; sizing it is still your job. For the manual-approval end of the same spectrum, compare it against taking your first agent payment through Stripe directly — Payman's edge is that the default path is bounded autonomy, not a human in the loop on every charge.

Bottom line: if you're building an agent that should move money on its own, Payman is the shortest path from "it can decide to pay" to "it can pay, safely" — provided you treat the spending caps as the real product and the SDK as the easy part.