Skip to main content
createAgentPayTools(atoa) returns tool definitions you can hand to any model, plus a call() dispatcher that runs whatever the model picks. The tools can only do what your API key permits. Spending limits live on the contract and are enforced by Atoa’s servers, so the model can’t exceed them.

Wire-up

The definitions carry the usage guidance a model needs — required fields, defaults, when to ask the user — so you don’t write tool prompts yourself.

The loop

The loop works with any model provider: hand the model the definitions, run what it calls, feed the result back.

The tools

23 tools. Each maps to the SDK method of the same name — parameters and behaviour are identical, so the reference covers both.

Setup & sandbox

Contracts

Payments

Refunds

Customers & stores

Approvals: the human stays in charge

There is no approval tool. When send_payment or an off-session collect_payment returns a nextAction, show nextAction.approvalUrl to the right person and wait for their decision — the business owner for a payout, the customer for a charge. The model can’t approve its own payment, and the one-time code or passkey is only ever entered on Atoa’s page. Every payment an agent makes is a normal Paymentlist_payments and get_payment give it (and you) the full audit trail.

No AI required

The tools are a thin layer over the SDK. Without a model in the loop, call the same operations directly — atoa.payment.collect(...), atoa.payment.send(...) — for identical behaviour.

Prefer MCP?

The hosted Atoa MCP server exposes Atoa’s tools to Claude, Cursor, VS Code, and any other MCP-compatible client — no SDK integration needed.

Rendering results

Tool results that need a human — a pay-link, a contract authorisation, an approval — carry a nextAction. Pass that action to AtoaUI.mount() in a web UI with embedded checkout, or post nextAction.fallback.text in a text channel.