Skip to main content
Agent Pay lets your AI agent take payments and make payouts, inside limits a human approved once. Atoa enforces those limits on its own servers, so nothing the model does can go past them.
An agent panel feeding the Atoa payment rail, which collects money in from a customer and sends money out to a payee.

Your agent asks; the customer approves in your own UI; Atoa enforces the caps on every payment after that.

How it works

Two calls. Your server creates a payment and sends its nextAction to the browser; your browser shows it.
The same result works without a browser: it carries a pay-link you can send, or a nextAction your agent can read.

Contracts and limits

A contract is a human’s standing approval. They set it up once — a cap per payment, a cap per period, an expiry date, and a direction — and after that your agent can move money inside it without asking again. Atoa checks every charge against the contract on its own servers. A payment over the cap is refused there, not in your code. Two things still need a person: setting the contract up, and Strong Customer Authentication (SCA) on payouts and off-session charges, where the approver enters a one-time code or uses a passkey on Atoa’s page.
Your agent calls Atoa, which enforces consent and caps, then collects money in from a customer or sends money out to a payee.

Collect or send

Decision tree: which way is the money going? Receiving splits on whether the customer is here now — yes is a pay-link (payment.collect, no contract), no is an off-session charge (payment.collect under a COLLECT contract). Sending is payment.send under a SEND contract the owner authorises once.
  • Customer presentpayment.collect returns a pay-link/QR. No contract. → Collect
  • Customer not presentpayment.collect with a contractId, under a COLLECT contract the customer approved once. → Collect
  • Paying outpayment.send under a SEND contract the account owner approved once. → Send

Get started

Get a sandbox API key from the Atoa dashboard and set it in your environment. Sandbox and production keys are separate.
Create a client and register your agent. Registering twice with the same key returns the same agent, so it’s safe to run on every start. The example generates a signing key in memory — in production, load it from your secrets manager or keep it out of your process entirely with a KMS signer. See Authentication for the other ways to pass credentials.

Collect your first payment

Create a payment on your server, then show it. In sandbox, choose the Atoa Test Bank in the checkout and pick the outcome yourself.
To show the checkout inside your own product instead of sending a link, send req.next_action from your server to the browser and mount it:
Browser
Full walkthrough: Embedded checkout.

Send your first payout

Create a SEND contract, approve it once at the authorizationUrl, then send. Every payout pauses for the business owner’s approval before money moves. In sandbox the recipient account decides the outcome — list the accounts with atoa.sandboxTestAccounts().
That’s a payout in sandbox. Every payout and every off-session charge returns an approval step like this one — see Collect and Send.

Next steps

Embedded checkout

Render the payment inside your own product.

Collect — money in

Pay-links, off-session charges, SCA, refunds.

Send — money out

Payouts, SCA, batches, contract limits.

AI agents & tools

Hand the SDK to your model as tools.

Reference

Auth, methods, types, errors, sandbox, go-live.

Download the notebook · run it locally

The full flow as a runnable Jupyter notebook — pip install atoa-agent-pay, add a sandbox ATOA_API_KEY, run.