Skip to main content
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.