Skip to main content
Three questions define a setup: who can 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 its own SDK key.

​
Who does what

The owner can be a person, a team, or a business that runs agents for its customers. A platform that integrates Conto for its customers keeps each customer’s policies in its own workspace. A merchant’s invoice or checkout page cannot approve the payment or change your policies.

​
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. Each agent has an environment: DEV (the default), STAGING, or PROD. Only PROD agents can pay from mainnet wallets.

​
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, and 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 status values and recovery steps.

​
Where controls apply

Organization policies apply to every agent in the organization. Assigned policies apply to one 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. A wallet limit of 0 blocks all payments through that link, and null removes the cap. Omitted limits get defaults. See Defaults before changing caps. Test allow, review, and deny to see these rules together.

​
Who signs

The code that signs must get a Conto approval before it signs or uses credentials. Do not give the model unrestricted payment keys and rely on it to follow the rules. A changed amount, recipient, currency, or material purchase detail needs a fresh check.
  • Managed wallets use request, then execute. Conto signs after your controls pass.
  • External wallets use approve, your own transfer, then confirm. Your agent signs, and Conto cannot block a transfer sent outside its flow. See wallet custody.
  • x402 and MPP clients call pre-authorization before they sign a payment or fund a session. An approved grant reserves the amount against your limits for 10 minutes. The client still signs and pays.
  • Connected cards (Builder and Enterprise): Conto releases a single-use, merchant-locked, amount-capped credential only after policy, limits, and the purchase authorization the cardholder verified all allow the purchase. The agent never sees the underlying card. Cards have their own spending controls, separate from wallet limits. See connected cards.

​
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

Run the quickstart, choose an integration, or read API conventions for units and identifiers.