Skip to main content
Start with three questions: who is allowed to spend, which wallet they can use, and which controls must pass. The agent owner or budget holder owns that configuration through their organization; the agent uses a separate runtime credential. The merchant is the recipient, not the policy authority. See buyer-side control.

​
Resource relationships

One wallet can serve multiple agents with different limits. An agent can have multiple wallets. Use walletId when the payment must use a particular wallet or chain. A key authenticates the agent; wallet access and policy evaluation constrain its payments.

​
Three records, three purposes

A payment request is the intent and authorization decision. An approval request is the human review record when a workflow needs a decision. A transaction records execution and settlement progress. These IDs are not interchangeable. For example, a research agent requests 12 pathUSD. Its policy requires review above 10 and denies above 15. The payment request waits for review. An authorized human decides; the application checks the original payment request. Execution creates a transaction, which may still be processing. The application waits for completion before treating the purchase as paid. See the payment lifecycle for actual status values and recovery steps.

​
Where controls apply

Organization policies apply at organization scope. Assigned policies apply to the relevant agent or wallet. All applicable controls must pass; a high-priority allow does not override a denial. Priority determines evaluation order. Wallet limits are another layer. A policy that permits 50 does not override a wallet cap of 20. Wallet creation, link creation, and updates have different omission/default semantics: use Defaults before changing caps. Explicit zero wallet limits are uncapped; suspend the agent or use a deny control to stop spending. Test allow, review, and deny to see these rules together.

​
Who signs, and who can bypass the path?

Read wallet ownership and custody before choosing the production model.

​
Three testing terms

  • Anonymous sandbox: simulated settlement, no signer or funded wallet needed.
  • Testnet: actual blockchain transactions using test tokens.
  • Mainnet: actual blockchain transactions using real funds.
A receipt with settlementMode: "live" identifies an onchain transfer and can still be a testnet transfer. Verify its chain as well as its status. Check flows and prerequisites.

​
Next steps

Make your first payment, choose an integration, or read API conventions for units and identifiers. For connected payment cards, use card management. Card assignments and wallet assignments have separate spending controls.