Every send happens under a SEND contract: the account owner authorises it once at their bank, and Atoa enforces
its per-payment and period caps on every draw.
Set up the contract
Send a payout
payment.send takes an array of instructions — one element for a single payout — and returns one Payment per
instruction, in order, plus a nextAction (TS) / next_action (Python) for the owner’s approval.
Sandbox: the recipient account decides the outcome — 040004 / 12345678 settles COMPLETED; 10000002 and
10000003 fail with a failureReason. Fetch the authoritative list with atoa.sandboxTestAccounts() rather than
hardcoding.
SCA on a payout
The business owner approves every payout on Atoa’s page with a one-time code or a passkey before money moves.
After the decision, read each payment’s outcome — business failures come back as FAILED payments you branch on,
not thrown errors.
To keep the owner in your own web UI, embed the approval with the
Approvals SDK instead of sharing the URL — pass nextAction.clientSecret to
confirmApproval. Declined payments read back FAILED with failureReason: APPROVAL_DECLINED; lapsed,
APPROVAL_EXPIRED. In sandbox, open the approvalUrl and force either decision.
Batches
Up to 20 instructions per call; each orderId unique within the batch; results in the order you sent. A batch
is one send call, so it carries one nextAction — the owner approves it once.
Update or revoke
contract.update returns a fresh authorizationUrl — the existing limits stay enforced until the owner
re-approves. contract.revoke is terminal; further sends are rejected.
On production these calls move real money to real accounts. Keep amounts small and beneficiaries verified
while testing, and switch to environment: "production" only when you’re ready.