Answer or decline a user action
Submit the values described by the action’s responseSchema, or decline to abandon the purchase. Declining is a first-class outcome, not an error path: the run stops immediately and the checkout fails with user_cancelled.
The response is the full checkout, re-serialized, with pendingUserAction gone.
Values for card, credentials and otp actions are fully redacted in the audit record and the raw copy goes to a transient, delete-on-read store consumed by the one step that types it.
Requires the checkouts.write scope.
Authorizations
Authorization: Bearer ck_test_… or ck_live_…. There is no other auth scheme — no query-string keys, no request signing, no OAuth.
Path Parameters
The checkout id returned at creation.
The pendingUserAction.id from the checkout. A new action gets a new id every time — never cache one.
Body
Response
Resolved. The full checkout, without pendingUserAction.
The whole state of one run. This is what you poll.
succeeded, failed and cancelled are terminal; nothing leaves them.
queued, running, awaiting_user_action, succeeded, failed, cancelled Yours. Stored and echoed back untouched; never sent to a merchant, and not searchable.
Append-only, ordered by sequence. Build your UI around this rather than a spinner.
Your own id for the end user this purchase is for. Absent when the checkout is not tagged to one. Set explicitly at creation, or stamped from the authenticating key's binding.
"user_a91f"
Absent when no profile was attached, and absent after the referenced profile was deleted.
Present once a browser session exists. Not a URL you can watch at — a pointer to the endpoint that mints one.
Present only while the run is blocked. At most one per checkout at a time.
Present only on a succeeded checkout.