Payman AI is useful when the primary job is giving an agent controlled access to wallets, payees, payment requests, and approval policies. Paybond is the SDK to reach for when a paid tool call also needs a spend limit checked before it runs, proof the work happened, and a signed receipt afterward — so you do not build that spend-governance middleware yourself. It works across agent runtimes and covers authorization, evidence, receipts, settlement, refunds, and disputes around paid tool calls.
Decision table
| Requirement | Paybond Kit | Payman AI |
|---|---|---|
| Wrap arbitrary paid tool calls before execution | Best fit | Use when the tool call is fundamentally a Payman payment action |
| Spend limit plus a per-operation permission check (capability token) | Best fit | Payment-policy fit |
| Proof of work and a receipt tied to that outcome | Best fit | Payment record fit |
| Refund, review, dispute, or release decision around a completed task | Best fit | Payment-workflow oriented |
| Agent wallet, payee, or direct payment send flow | Rail-adjacent, not the wallet product | Best fit |
| SDK boundary for OpenAI, Claude, Gemini, MCP, LangGraph, and custom tools | Best fit | Depends on the payment integration path |
Practical rule
Use Payman AI when the work is "give an agent a controlled way to send payments." Use Paybond when the work is "authorize this paid operation before it runs, keep proof of what happened, and support release, refund, review, or dispute based on the outcome."
Many production stacks can use both: Paybond governs the paid tool-call and settlement record, while a payment rail or wallet provider moves funds where configured.