line_items (typically item.id only as a hint), buyer context fields, and fulfillment address when known. In responses, you own all business logic — pricing, tax calculation, inventory validation, fulfillment options, payment handler declaration, and messages[]. Never derive pricing or availability from Alexa+‘s request values.
The session contract, schema structure, and .well-known/ucp profile format are grounded in the open UCP spec — your session logic, schema validation, and profile structure are reusable when connecting to additional AI agent services that support UCP. The payment handler declarations (com.amazon.payments.*) are Amazon-specific and would need to be updated with each service’s native handler declarations. Additional capabilities such as dev.ucp.shopping.catalog and dev.ucp.shopping.orders can be declared alongside the checkout capability without modifying your existing endpoints.
Operations
You host these endpoints at a base URL declared in your.well-known/ucp profile. All endpoints use HTTPS with TLS 1.3 minimum and JSON request/response bodies.
| Operation | Method | Path | Required? | Notes |
|---|---|---|---|---|
| Create | POST | /checkout-sessions | Required | Body requires line_items |
| Get | GET | /checkout-sessions/{id} | Required | Read-only; returns full current state. Required for crash recovery — Alexa+ re-fetches state after network failures |
| Update | PUT | /checkout-sessions/{id} | Required | Full-resource replace — caller resends the full object |
| Complete | POST | /checkout-sessions/{id}/complete | Required | Payment credential arrives here |
| Cancel | POST | /checkout-sessions/{id}/cancel | Optional | Transitions session state only — not an order cancellation. TTL expiration handles cleanup if you don’t hold inventory or pre-auth funds at session creation |
Request and response headers
Request headers
Alexa+ sends the following headers on every call:Response headers
201 for Create, 200 for all other successful operations — including business failures like payment declines (HTTP 200 + messages[]). Use 4xx/5xx only for protocol errors such as auth failures, idempotency conflicts, or malformed requests.
Create
POST /checkout-sessions
Alexa+ sends line_items and buyer context. You respond with the full checkout object — including totals, payment handler declaration, and any recoverable messages for fields still needed.
Create request fields
Create request example
Create response example (201)
incomplete + a recoverable message tells Alexa+ to collect the missing field and call Update. The ucp.payment_handlers block declares which payment handlers this session accepts — Alexa+ uses this to negotiate the credential before calling Complete.
Get
GET /checkout-sessions/{id}
Returns the full current state of the checkout session. This is a read-only operation. Alexa+ uses Get for crash recovery — it re-fetches state after network failures to determine the correct next step.
No request body is required. The response is the full checkout object in its current state.
Update
PUT /checkout-sessions/{id}
Full-resource replace. The caller resends the complete object with updated fields. Alexa+ typically calls Update after collecting a shipping address or fulfillment selection from the buyer, or after updates to item quantities.
Update request example
Update response example (200)
ready_for_complete tells Alexa+ all required fields are present — it proceeds to payment acquisition and calls Complete.
Complete
POST /checkout-sessions/{id}/complete
Alexa+ sends the payment credential based on the handler. You process payment and respond with the completed order. The request body contains only the payment instrument — no line items or totals.
The handler_id in the request reflects the customer’s payment selection — amazon_pay_network_token if they paid with their Amazon wallet, partner_card_on_file if they selected a saved card from your system. Alexa+ always sends exactly one instrument.
Complete request example
Complete response — success (200)
Complete response — payment declined (200)
On a payment decline, return HTTP200 with status incomplete and a payment_failed message. Use descriptive messages to enable Alexa+ to suggest remedial steps to the buyer. Don’t return a 4xx.
Cancel
POST /checkout-sessions/{id}/cancel
Transitions the session to canceled state. This isn’t an order cancellation — it only affects the checkout session. Sessions that aren’t explicitly canceled expire based on their expires_at TTL (default 6 hours).
Cancel is optional. If you don’t hold inventory or pre-auth funds at session creation, TTL expiration handles cleanup automatically.
Object definitions
Checkout object
Every Alexa+ checkout response must return the full checkout object.Required fields
ucp.status is optional — defaults to “success” and should be omitted in normal responses. Set "status": "error" only for protocol-level failures where no session resource is created. Business errors (payment declined, out of stock, missing fields) are conveyed via messages[].
Field names and payload structure align with the UCP checkout schema. You can validate payloads against public UCP schemas at any time. For additional reference, see:
Session lifecycle
- Sessions default to a 6-hour TTL (
expires_at). - Completed sessions are immutable.
- Non-terminal sessions are cancelable if Cancel is implemented.
Status transitions
incomplete→ready_for_complete→completedcanceled— reachable from any non-completed state
Status and Alexa+ behavior
Fulfillment object
The fulfillment object carries the shipping destination and method. Alexa+ includes this in Update requests when a delivery address is known. Your backend validates the address, calculates shipping cost and tax, and returns updatedtotals[] in the response.
Errors and messages
All checkout session responses must include amessages[] array (may be empty). Each message carries a type, code, and severity (for errors) that determines how Alexa+ processes and displays it.
Messages are discriminated by type: error, warning, or info. The content field defaults to plain text when content_type is omitted; set content_type: "markdown" for rich text rendering.
Message structure
Error severity levels
When multiple messages are present, they are processed in priority order:recoverable errors before escalating. Only when no recoverable errors remain does Alexa+ initiate handoff for requires_buyer_input / requires_buyer_review errors.
Warning presentation types
Warning messages use thepresentation field to control rendering. Default is "notice" when omitted.
"presentation": "disclosure" for regulatory or legal notices (allergens, Prop 65, age restrictions, subscription terms). Disclosure messages must include content; image_url should be provided.
Disclosure example with markdown rendering:
content_type: "markdown" for rich text rendering. When omitted, content defaults to plain text.
Standard error codes
Payment methods
Alexa+ implements two payment handlers. At least one must be included in your.well-known/ucp profile. You must also include the ucp.payment_handlers block in every checkout session response — Alexa+ reads this to negotiate the credential type before calling Complete.
com.amazon.payments.network_token— Alexa+ delivers an encrypted DPAN and cryptogram from the buyer’s Amazon wallet. You decrypt the credential and submit it to your PSP as a standard network-token transaction.com.amazon.payments.stored_payment_method— The buyer selects a card already saved in their account with you. Alexa+ returns the chosen card’s ID at Complete. No sensitive card details are shared with Alexa+.
Network Token (com.amazon.payments.network_token)
Alexa+ charges a card from the buyer’s Amazon wallet. You receive an encrypted token only you can decrypt.
Prerequisite: Requires Amazon Pay merchant onboarding. Refer to the Network Token Integration Guide provided by your Solutions Architect.
Profile declaration:
payment node entirely. Alexa+ reads ucp.payment_handlers to know which handlers this session accepts.
- Decrypt and process the credential per the Network Token Integration Guide provided by your Solutions Architect
- Return
completed+orderon success, or HTTP 200 with apayment_failedmessage on decline
billing_address is sourced from the buyer’s Amazon wallet and provided by Alexa+ at Complete. Use it for Address Verification if needed. Stored Payment Method doesn’t include a billing_address — you already hold it on file.
Stored Payment Method (com.amazon.payments.stored_payment_method)
The buyer pays with a card already saved in their account on your system. You return a list of cards in response to Create; Alexa+ returns the chosen card’s ID at Complete. No sensitive card details are shared with Alexa+.
Prerequisite: Requires account linking — saved methods are scoped to the linked user’s OAuth token.
Profile declaration:
brand and last_digits at minimum.
- Validate that
payment_method_idbelongs to the account-linked user’s payment instrument - Validate that
payment_method_idwas one of the IDs returned by you in theCreateresponse
Discovery profile
The/.well-known/ucp profile tells Alexa+ what your integration supports. It declares your base URL, capability, and payment handlers. Serve it at https://your-domain.com/.well-known/ucp with Content-Type: application/json.
Alexa+ fetches this profile during onboarding and periodically to detect changes. Serve with a short cache TTL (15 minutes recommended).
For Alexa+-only integrations, profile negotiation is simplified — Alexa+ fetches your profile during onboarding and uses it directly. The full UCP negotiation protocol (runtime profile comparison per call) is only needed when supporting additional UCP-compatible agents beyond Alexa+.
Full profile example
Profile fields
Handler registration rules
- Each handler entry must have a unique
idwithin the handler namespace available_instrumentsdeclared here are the outer bounds — a session response may narrow constraints but must not advertise instruments not declared in the profile- Alexa+ selects the best mutual handler per session by comparing this profile against its own
Handler versioning
The checkout contract is pinned to the declared UCP spec version (2026-04-08). Each payment handler also carries a date version declared in your profile. What you build against a pinned version keeps working — the contract never changes under you. New optional fields may be added; anything requiring code changes ships as a new dated version with side-by-side support.

