Inspect the example
Readexamples/agent-pays-vendor/src/0-policy.ts through 3-audit.ts in the product repository. Validate any example identifiers and policy values against the current schemas before using them. Sample amounts describe the example, not account limits or fees.
Configure policy and access
Use a provisioned agent vault and an active grant with the scopes required by your tools. A policy object constructed locally is not automatically saved as the agent’s live policy. For requests with a destination, the policy engine requires both an approved chain and a matching counterparty address, chain and token. Empty allowlists deny destinations. An absent amount cap leaves that amount axis uncapped; other gates still apply.Preview and submit
Usepayments.simulate where enabled to inspect the policy verdict. For a payment, use the current payments.initiate input schema rather than the mock response or commented request in the source example.
Choose an idempotency key for the payment and persist it before submission. Keep the same key and parameters when resolving an uncertain outcome.
Handle approval
A step-up response refers to the existing pending action. Open the supplied approval URL and use the approval prompt shown on your device. The URL-mode page is not fully connected in the current release; do not interpret its display as authorization or retry with a fresh payment key. Hard policy denials, including unapproved destinations and exceeded caps, cannot be bypassed with approval.Verify the outcome
Track the existing payment identifier and settlement status. An accepted request is not a settlement receipt. Where an on-chain receipt is available, inspect its transaction hash independently.audit.stream returns a cursor contract. The deployment must provide its SSE endpoint before you can subscribe. The mock event in the source example does not verify that endpoint.