Build AI shopping around a trustworthy transaction

A shopper asks an assistant to find a compatible replacement part. The recommendation looks right. The assistant adds it to a basket and reports that the purchase is complete.

Behind the conversation, the selected variant is unavailable, shipping was estimated for the wrong region, and the payment state is unclear.

This fictional scenario illustrates why conversational shopping is a transaction-design problem. A fluent recommendation cannot compensate for an unreliable order.

Every step must preserve the relationship between what the buyer requested, what the business offered, and what the buyer authorized. That relationship continues through fulfillment, support, and any return.

Separate discovery from authority to purchase

Discovery helps a shopper understand options. A cart records a proposed selection. Checkout establishes the terms of a transaction. Payment and fulfillment carry their own responsibilities.

An assistant may be authorized to search a catalog without being authorized to spend money. A saved preference for a brand does not authorize a substitute at a higher price.

Write the boundary explicitly. For a first implementation, the assistant might compare products and assemble a basket while a trusted interface presents the final terms for the buyer’s approval.

Google’s May 2026 commerce update describes UCP-based shopping developments and a cross-retailer cart. This shows active product development; it does not establish that every merchant or shopping channel supports the same capabilities.

Choose an integration because it fits a specific customer journey and operating model. Do not rebuild a working storefront simply to attach an agent label to checkout.

Make the catalog capable of answering the question

Start with stable product identifiers, explicit variants, availability, current prices, supported regions, and relevant compatibility attributes. A persuasive description is not a reliable substitute for structured facts.

If a shopper asks for a replacement part compatible with a particular device, the system needs an authoritative compatibility relationship. Similar wording or appearance is insufficient.

Represent unknowns as unknowns. If compatibility cannot be established, the assistant should ask for a model number or refer the question to someone who can verify it.

Keep source timestamps and ownership visible to the integration. Product descriptions may change slowly while inventory changes rapidly. They should not inherit the same freshness assumption.

Audit a representative sample of catalog entries before implementing a sophisticated recommendation flow. The data-readiness checklist can help identify missing definitions, owners, and quality controls.

Use the same product identifier across discovery, cart, order, and support. Translation between identifiers is sometimes necessary, but it should be explicit and testable.

Define the transaction contract

A transaction contract states the information that must agree across systems. It also identifies which service is authoritative when values disagree.

The following is an illustrative contract for a fictional shop selling desk accessories. It is a design worksheet, not a required protocol schema.

Define how long a quote remains valid and which changes require the buyer to review it again. Do not silently replace a product or increase a total because the original request used broad language.

The UCP checkout specification provides a formal model for checkout interactions and terms. The UCP overview describes discovery and capability negotiation. Read the supported version and capabilities before implementing; a protocol name alone does not establish interoperability.

Bind approval to the terms the buyer saw

Consider an illustrative basket with a $24 item and $6 shipping, before any applicable tax. If shipping later becomes $12, the original $30 pre-tax presentation no longer describes the proposed purchase.

Return the changed terms to the buyer through the approved interface. Preserve a record of the selection, amount, currency, relevant conditions, and approval event according to the system’s retention policy.

Keep different purposes separate. Permission to complete a purchase is not automatically permission to enroll the customer in marketing or a subscription.

The assistant’s interpretation of a casual statement should not become unlimited purchasing authority. If a workflow supports delegated buying, define its scope, limits, expiration, and revocation through the relevant supported mechanisms.

For a small pilot, explicit approval of each final basket is easier to inspect than a broad standing instruction. The goal is to demonstrate a trustworthy transaction before expanding discretion.

Treat interrupted execution as a normal case

A timeout means the caller did not receive a timely answer. It does not prove the server did nothing.

If a payment or order request loses its response, use the supported operation identifier and status lookup to determine what happened before trying again.

Stripe’s idempotency documentation describes using keys to make supported requests retryable without repeating the same operation. Its behavior has defined conditions and retention rules; it is not a guarantee that an entire multi-system workflow can never duplicate work.

Choose keys that identify a specific intended operation. Reusing a key for a different basket is a different error from generating a new key for every retry.

Track the checkout, payment, and order identifiers together. If payment succeeds but order creation fails, an operator needs enough information to recover or reverse the transaction under the business’s approved process.

The integration-scoping lesson helps expose these responsibilities before they become production incidents.

Design the states customers can understand

Use a small, explicit state model: proposed, awaiting approval, processing, confirmed, failed, or needs review. Add separate fulfillment states after confirmation.

A payment authorization, captured payment, confirmed order, and shipped order may occur at different times. Do not collapse them into a single “done” message.

Explain pending states with a reference and a next step. Avoid asking the shopper to submit another purchase when the first transaction is still being investigated.

Make recovery available through an ordinary support channel. Customers should not need to reconstruct an agent’s internal conversation to dispute a wrong item or ask about a charge.

Record the status transition that caused each customer-facing message. That makes it possible to investigate a misleading confirmation and fix its trigger.

Include fulfillment and returns in the first design

Commerce continues after checkout. The customer needs delivery information, a way to find the order, and an understandable route for cancellation or return where applicable.

Identify the responsible merchant and the support owner. An interface that combines products from several merchants may still involve separate policies and fulfillment responsibilities.

Present the relevant terms before purchase and retain an appropriate reference to the terms used. A later policy-page edit should not make it impossible to explain what was shown at checkout.

Define how partial fulfillment, substitutions, unavailable stock, and refunds are reflected in the conversation. Keep the source system authoritative for the actual state.

Do not make the assistant infer a refund decision from the customer’s frustration. It can gather information and explain an established process while the authorized policy and tools govern the action.

Build a sandbox test matrix with real failure shapes

Use synthetic catalog data and the payment provider’s supported test environment. Do not test error handling by creating unnecessary live charges.

Cover an ordinary purchase, an unavailable variant, a changed price, unsupported delivery, expired approval, a declined payment, a lost response, and a duplicated callback.

For every case, specify the expected customer message and the expected state of the cart, payment, and order. A good response with the wrong backend state is still a failed test.

Set release criteria appropriate to the pilot. Examples include no unapproved substitutions in the test set, no duplicate order for a retried operation, and a recoverable reference for every interrupted checkout.

Also test reconciliation: can a reviewer find every test payment’s related order or documented exception? This checks the operational bridge between systems rather than only the conversation.

Keep the test matrix versioned with the integration configuration. A new channel or payment handler can change the failure paths.

Assign each failed scenario to a responsible team. Catalog errors may belong to merchandising, payment uncertainty to a payments operator, and delivery failures to fulfillment. The assistant should surface the right evidence without becoming the assumed owner of every problem.

Include a reconciliation worksheet with checkout ID, operation ID, payment state, order state, customer message, exception owner, and next review time. Fill it with synthetic records from the test matrix. A row with a successful payment and no order must remain visibly unresolved until the approved recovery process finishes.

Review changes to transaction terms as carefully as code changes. A new shipping rule or return policy can alter what the buyer must see even when the conversational flow remains identical.

Choose a narrow first use case

A well-defined accessory catalog may be a better first project than products with complex eligibility, compatibility, or regulated purchasing requirements.

Begin with discovery and basket preparation if the merchant’s inventory and order processes are not ready for automated actions. That can still reduce effort without creating an unreliable checkout.

Measure correct product selection, completed approved orders, exceptions, support contacts, and recovery work. Conversation engagement alone does not establish commerce value.

Compare the new journey with the existing one on the same types of tasks. If customers need more clarification or support, investigate the reason before increasing traffic.

Show the entire transaction, not a polished recommendation

Present a sandbox recording or annotated sequence that includes product evidence, the proposed basket, approval, confirmed system states, and the final customer message.

Pair it with an interrupted example. Show how the workflow discovers the actual payment state and avoids asking the buyer to purchase twice.

Remove personal information, credentials, and payment details from any shared artifact. Label synthetic records and describe the capabilities that have not been tested.

The finished work should make a simple question answerable: can the buyer and the merchant both explain what was agreed, what happened, and who owns the next step?

Sources checked September 23, 2026. Product, price, and transaction examples are illustrative. Implement against the specific protocol and payment-provider versions your integration supports.

Continue the field guides: The contract behind a useful AI integration or AI customer service needs a case lifecycle, not just a good answer.

Try this

Choose one simple product and write a synthetic checkout scenario. Record the exact variant, quantity, delivery destination type, item price, shipping, tax assumption, and total shown to the buyer. Describe the approval required before a purchase and what would require approval again. Then walk through three failures: stock disappears, the price changes, and the payment response is lost. For each, identify the authoritative system, the next safe action, and what the customer sees. Share the resulting state diagram or transaction table with a clear sandbox label and no real customer or payment information.