Agent Checkout: The Order, Payment and Fulfilment Records a Merchant Must Join
An agent can complete checkout while the merchant still owns the order, payment result and fulfilment. A practical record and failure map for operators.
Agent checkout is a handoff between the agent platform and the merchant's order and payment systems. A completed checkout, a paid transaction, a fulfilled order and a refund are separate records.
An agent checkout needs a durable join from the customer's instruction and platform checkout ID to the merchant order ID, payment object and fulfilment or refund events. The merchant remains the authority for its accepted order and payment processing in OpenAI's commerce documentation; UCP likewise gives the business the authoritative checkout and order responses. A completed checkout does not by itself prove payment settlement or delivery. If the response or an event is lost, query the authoritative state and reconcile before retrying or fulfilling.
An agent can return a cheerful “ordered” message while the merchant is still processing checkout, the payment method is still resolving, or the parcel has not been handed over. The operational job is to preserve the link between those states. A missing link creates the familiar incidents in an unfamiliar wrapper: duplicate orders, fulfilment against unpaid orders, and refunds that support can see but the agent cannot explain.
This article follows the merchant's records after an agent initiates a purchase. The protocol comparison explains what ACP, UCP, AP2 and Visa TAP specify. The payment lifecycle explains authorization, capture and settlement. Neither replaces the merchant's order-to-payment join.
Four records that should never collapse into one
| Record | Question it answers | What it cannot prove alone |
|---|---|---|
| Customer instruction and agent checkout | What the user asked the agent to attempt and which checkout the platform submitted | That the merchant accepted an order or that the issuer approved payment |
| Merchant order | What the merchant accepted, its line items, total and fulfilment promise | That payment has settled or every item has shipped |
| Processor payment object | What happened to the payment attempt, authorization, capture or refund | That the merchant delivered what was sold |
| Fulfilment and post-order events | What shipped, was delivered, canceled, returned or adjusted | That a refund reached its final payment status |
This is PaymentBrief's join map, not a required schema imposed by every protocol. In UCP's Order capability, the order has its own id and a required checkout_id; line items, fulfilment data and optional adjustments live with that order. That gives the platform a way to follow the merchant's order without pretending the platform owns it. OpenAI's commerce concepts likewise put acceptance, charging and confirmation on the merchant's systems. These are descriptions of their respective integrations, not a claim that they interoperate.
OpenAI's March 2026 product update shifted its emphasis toward discovery and merchant checkout. The existence of ACP checkout documentation therefore does not mean every merchant currently checks out inside ChatGPT.
Checkout completion can still be in progress
UCP's checkout specification defines a complete_in_progress state: the business has accepted a completion request and is still processing it. The platform must observe the business's subsequent state. If completion and cancellation race, a cancellation is effective only when the business reports canceled. Neither the agent's local message nor a lost network response settles that question.
The payment system has its own state. Stripe's PaymentIntent reference distinguishes processing, requires_capture and succeeded. In a manual-capture flow, an authorization is not a capture; even a successful payment outcome is not evidence that goods were delivered. A merchant must use the payment events appropriate to its processor and method, then join them back to its order. The payment-link reference covers the same separation for reusable links.
The lost-response table
| Failure | What the documentation establishes | Operator response — PaymentBrief guidance |
|---|---|---|
| Complete request times out | UCP gives the business authoritative checkout state; Stripe's keyed API requests have documented retry behaviour | Query the checkout and payment object before submitting another completion or creating another order. Preserve the same business reference. |
| Merchant has an order; payment still processes | UCP order and processor payment are separate records; Stripe exposes a processing state | Hold fulfilment pending the method's confirmed payment outcome, with a defined exception policy for risk-approved delivery. |
| Platform misses an order update | UCP sends full order snapshots by webhook and recommends Get Order for reconciliation or on-demand retrieval | Verify webhook signatures, deduplicate events and reconcile missed updates from the merchant order. Do not treat delivery as exactly once. |
| Customer cancels during completion | UCP says cancellation can race completion and only a business-reported canceled is effective | Read the final checkout state. If an order already exists, follow the merchant's post-order cancellation and payment process. |
| Partial refund after shipment | UCP can record a refund adjustment separately from fulfilment; Stripe exposes a separate Refund object | Join the refund to its original payment and affected line items, then reconcile the actual refund status. |
Stripe's idempotency rule is useful but narrow: a keyed POST returns the first result on a matching retry, including an error result, and keys may be removed after at least 24 hours. It does not make the merchant order, agent platform and PSP one atomic database. The operator still needs an order-level duplicate guard and a reconciliation path for uncertain outcomes. UCP and ACP have their own request contracts; use the version actually integrated.
Cancellation is not a refund instruction
The word “cancel” hides two different jobs. Before a checkout completes, a platform may try to cancel that checkout under the relevant protocol. After the merchant has accepted an order, changing or canceling it is a post-order operation. UCP's order model treats adjustments, including refunds and cancellations, separately from fulfilment events. A processor refund is another action again: Stripe's Refunds API creates a refund object against the original payment or charge. A checkout cancellation cannot be used as evidence that money was returned.
The refund operations runbook owns refund controls, dispute overlap and reconciliation across payment methods. The agent-specific addition is the platform handoff: the buyer's agent must not display “refunded” based solely on the merchant accepting a cancellation request.
The launch test
Run one test purchase, one uncertain-response retry and one post-order refund in the actual integration. From records alone, identify the customer's instruction, platform checkout ID, merchant order ID, processor payment ID, final payment event, each fulfilment event and the refund's final outcome. Confirm who sends each status to the buyer and how a missed event is recovered. That is the smallest useful evidence chain between an agent's promise and the merchant's ledger.
For authority and revocation controls before the purchase, use the agent payment-controls guide. For what each agentic protocol contributes, use the ACP/UCP/AP2/TAP comparison.
Sources & methodology (7)
OpenAI says ChatGPT calls a merchant's checkout endpoints, while the merchant validates the request, decides whether to accept or decline the order, charges the payment method through its existing processor and confirms the order; checkout and payment state remain on merchant systems
Checked:
OpenAI's March 2026 product update says it is focusing on product discovery and allowing merchants to use their own checkout after the initial Instant Checkout design did not offer the desired flexibility
Checked:
UCP's checkout capability makes the business authoritative for checkout state; a completion can enter complete_in_progress; platforms query Get Checkout for the outcome and treat a cancellation as effective only once the business reports canceled
Checked:
UCP orders contain a merchant-provided order ID and associated checkout ID, line items, fulfilment, and optional post-order adjustments; the business sends full order snapshots by webhook, with Get Order used for reconciliation or on-demand retrieval
Checked:
Stripe's PaymentIntent states distinguish payments still processing, authorized for later capture, and succeeded
Checked:
Stripe's refunds API creates a separate Refund object linked to a charge or PaymentIntent
Checked:
Stripe idempotency keys let a client repeat a POST request under the same key, with the first result returned on a matching retry; keys can be pruned after at least 24 hours
Checked:
Source types explained in our Methodology.
By Shaun Toh · Director, Digital Payments · Razer