In this essay
A merchant exposes a checkout to an agent. The agent can read an offer and create a checkout session, but it cannot complete the purchase because the delivery information is missing. After the buyer supplies it in another interface, the agent continues using the old session state.
That is a useful UCP checkout integration test. It examines one purchase across a handoff, where an apparently simple protocol connection can lose the current facts.
Pin the contract for the test
This article uses the UCP checkout specification dated 2026-04-08, read on 25 October 2026. The date in the URL identifies the version being discussed; it does not prove that the page's bytes can never change. Keep the retrieved version and the actual merchant implementation details with the test evidence.
The specification distinguishes states including incomplete, requires_escalation, ready_for_complete, complete_in_progress and completed. It describes buyer continuation through a continue_url when escalation is required. Finalization needs the trusted user interface unless the specified AP2 Mandates extension is supported. A ready_for_complete state alone is not purchase authority.
Those are protocol-specific boundaries. The following trace is an original test design for a fictional mug purchase, not a claim that a merchant or agent has passed it.
Trace the current offer through the buyer handoff
| Test point | Evidence to retain | Result that must not be inferred |
|---|---|---|
| Read the offer | Merchant, item, quantity, current terms and the negotiated capability/version | That an advertised capability proves a working purchase |
| Create or inspect checkout | The checkout identity, actual state and missing information | That session creation is an order |
| Request buyer continuation | The supported continuation route and the reason for escalation | That visiting the route means the buyer approved payment |
| Return from the buyer interface | A fresh checkout read and the current terms, state and authority evidence | That the pre-handoff state is still current |
| Perform permitted completion | The applicable authorized completion path and its operation evidence | That a request or processing state establishes an order |
| Establish completed outcome | The merchant's completed result and order reference, linked to this purchase | That a local agent message is the merchant's confirmation |
If delivery information changes the total or supported terms, the purchase must remain within the actual authorization. The implementation needs a supported path to obtain any additional buyer decision rather than treating the original request as unlimited permission.
Record negotiated version, checkout identity, terms, actual state and missing buyer information.
Use the supported continuation route, then refresh checkout state and terms.
Keep the incomplete or unresolved state and original checkout. Do not infer purchase approval.
Ready_for_complete is capability state. Apply trusted-UI finalization or the supported mandate extension and actual purchase authority.
Stop completion and obtain the required buyer decision through the supported route.
Recover the original checkout result. Do not create another purchase.
Proceed only when the merchant outcome is establishedOnly a completed result with the related order reference establishes the completed purchase. Other outcomes remain explicit.
The trace uses the dated 2026-04-08 UCP checkout specification. It is a proposed scenario, not a merchant integration test or proof of interoperability; unresolved completion never authorizes another purchase.
Keep the unresolved branch visible
During the test, delay the completion response. The agent should retain the same checkout and investigate its actual state through the supported contract. A processing or unknown outcome should remain visible to the buyer and support team. It must not lead automatically to another purchase.
A completed result should be associated with the original checkout and the merchant order reference. The support team should be able to retrieve that association without reading the agent's conversation as if it were the system of record. Duplicate-purchase recovery deals with the wider execution problem when several workers handle one intent.
Also test a buyer who abandons the continuation interface. The test should end with an honest incomplete or unresolved outcome, as applicable, rather than a fabricated successful conversion.
Define what this test proves
A successful controlled trace demonstrates the specific merchant, agent, protocol version, payment arrangement and scenario tested. It does not establish interoperability with every agent or readiness for every commercial exception.
The broader payment-product readiness checklist covers the surrounding operating responsibilities. The permission-to-buy discussion separates authority from technical access, and the protocol comparison explains the different layers.
Keep the final test record small enough to inspect: the starting offer, checkout identity, handoff evidence, refreshed state, authorized completion path and merchant order reference. When one is missing, state precisely what the integration has demonstrated and what remains open.
Closing thought and further reading
An agent can create a checkout without completing a purchase. Test the buyer handoff, refreshed state and merchant outcome for one pinned protocol version.
Ideas that continue the thread.
View all essays
Need help applying this to your business?
Explore practical support for payment operations, product decisions, program delivery and AI automation, grounded in the challenges behind this essay.