An agent payment workflow needs three separately verified results: permission to act, a commerce
record, and confirmation from the payment system. A model’s answer or a successful local write
does not prove that funds moved.
The earlier agent-wallet SDK sample on this page used an unpublished interface. Use the
concrete service contracts below when building an integration.
Choose a first task
Define the boundary before execution
Record the permitted account, currency, amount, recipient, and operation. Give the agent access
to the required tools and require the server to enforce that scope. Keep credentials in the
configured connection, not in the task text.
Success: tool results identify the intended records and explain which system proves the
payment outcome. Start with this read-only check before authorizing a write.
Execute an authorized operation
Use the documented API or MCP tool for the selected service. Preserve its returned operation
ID and, where replay is supported, its original idempotency key and payload. Verify the final
result with the payment provider or network and reconcile it with the local commerce record.
A timeout creates uncertainty about the result. Look up the original operation before
resubmitting. A new idempotency key is a new attempt and can duplicate a payment.
Validate before rollout
Test an allowed operation, a rejected policy decision, a duplicate submission, and a lost
response in an isolated environment. For each, retain decision evidence, execution identity,
and the authoritative final state. See error handling
and the integration test plan. Last modified on September 21, 2026
