nextAction for you, and so
does the Approvals SDK. Read on if you’re rendering payment UI yourself, relaying actions
through a channel Atoa doesn’t know about, or want to see what the embed switches on.
Every Agent Pay result carries one nextAction: the single thing that must happen next. It holds the ids,
amounts and links a renderer needs, so you never pick fields out of a raw response. With no UI, poll
nextAction.resolve until the status is terminal. In a chat, post nextAction.fallback.text.
The shape
Read approval fields from
data: data.approvalId, data.approvalUrl, data.clientSecret. The same three are
also mirrored at the top level of nextAction for backwards compatibility.
The catalogue [#the-catalogue]
Four types. That’s the whole set an Agent Pay call can return today.
Choosing a card, entering card details, verifying a contact, enrolling a passkey — those are steps inside a
PAY, APPROVAL or AUTHORIZE_CONTRACT flow, handled on Atoa’s pages. They never arrive as a nextAction you
have to render.
Handling a type you don’t know
When you get atype you don’t recognise, render fallback.text and fallback.url.
type is a plain string, not an enum, so Atoa can add action types without an SDK release. Every action type has
a usable fallback. The embed does this for you.
fallback.text never contains a clientSecret, so it’s safe to post to a chat or an email.
Amounts are pre-formatted
data.amount is { value, currency, display } — value is a decimal string, exactly as sent on the wire;
display is pre-formatted ("£45.00"). Print display; never format money yourself.