Skip to main content
You don’t need this page to ship. Embedded checkout reads 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 a type 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.