The AI took the order. Now what?

I got an order through Juniper. Then the shopper asked when it would ship.

That was the bit I wrote about in the Stripe checkout field note. The conversation could continue after the purchase. Useful. But the answer in that sandbox came from the store’s shipping policy. It wasn’t looking at a warehouse, an allocated order or a parcel moving toward somebody’s house.

That gap is where I want to spend more time.

Getting a shopping agent through checkout gives the business an order to deal with. Now somebody has to keep everything the customer was just told straight while inventory, money and fulfillment move at different speeds.

Two items. One trip.

Take a hypothetical order. A fleece and a shell, bought for a trip next Friday. The fleece is available now. The shell is backordered for three weeks.

An agent could correctly find both products, select the right sizes, calculate the basket and complete checkout. It could succeed at every one of those steps and still fail the shopper if it implied both items would arrive for the trip.

“Usually ships in two business days” is a perfectly ordinary policy. Applied to that shell, it’s also a fairly effective way to ruin somebody’s Thursday.

Before the shopper agrees to buy, I want the system to return the fulfillment options for those actual lines, quantities and destination. If the merchant supports split shipping, show what ships now and what waits. If it holds the whole order, say that. If there isn’t a reliable arrival estimate, keep that uncertainty visible.

The agent can help the person decide whether the fleece alone is useful, whether an available shell would work, or whether to leave it. The stock and delivery commitments need to come from the systems that can make them.

This is the practical end of the website becoming infrastructure. Once another interface can sell your products, it needs access to the rules and facts your checkout depended on. Including the inconvenient ones.

The protocol has somewhere to put this

Shopify’s June 17 developer announcement opened self-service access to its agentic commerce infrastructure through UCP and Catalog API. More developers can build the path from discovery to checkout. That’s useful progress.

And the Universal Commerce Protocol’s order model already accounts for life after purchase. It separates what was bought, fulfillment and subsequent adjustments.

More specifically, it distinguishes delivery expectations from fulfillment events. What the buyer should expect to arrive, and what actually happened. Expectations can change or split; shipment events reference particular line items and quantities.

That distinction matters. The fleece leaving the warehouse mustn’t turn into “your order has shipped” in a conversation about both items.

The standard gives the parties a way to exchange that information. The merchant still has to populate it from its operating systems. If the order management system knows the shell is delayed and the agent’s order view doesn’t, the customer gets the older, more cheerful version of reality.

I’d want the agent to know which items an answer covers, when the underlying state was last checked, and whether a delivery date is an estimate. A single order-level status loses too much.

“We’ll charge it when it ships” has some plumbing behind it

Keep the same order. The merchant wants to collect payment as each shipment goes out.

Now the payment design matters quite a lot.

With Stripe, separate authorization and capture lets you reserve funds on eligible payment methods and collect them later. That authorization has an expiry. The applicable window depends on the payment method and transaction; a three-week backorder cannot simply assume the original hold will still be available.

There is another catch with the fleece. For most payments, a partial capture releases the remaining amount. You don’t automatically get to collect for the fleece today and come back for the shell against the same authorization. Stripe has multicapture support for eligible payments, but eligibility and the authorization window still matter.

Another design is to set up the payment method for later use, then initiate payments as fulfillment becomes ready. A SetupIntent doesn’t collect money. It also doesn’t guarantee that a charge three weeks later will succeed.

The customer needs to agree to that arrangement. Stripe documents permission for future off-session payments, including how amounts will be determined. A later payment can still need customer authentication and recovery.

So the shell becomes available and the payment fails. What happens next?

I’d want the fulfillment workflow to hold the affected shipment, give the customer a secure way to resolve payment, and make that state available to the agent. The exact sequence belongs to the merchant’s payment and release policy. It needs an owner before the customer reaches it.

For a split order, I’d also want an explicit record of which quantities and amounts each payment covers, including the applicable tax, shipping and discounts. Asking a model to work out the remaining balance from the transcript would be a strange place to save engineering time.

These are design choices for the example, not a claim that my sandbox already runs a complete OMS and shipment-payment lifecycle.

Then the customer cancels the shell

The fleece has shipped. The customer finds another shell and asks the agent to cancel the delayed one.

The request is simple. The result depends on what is true at that moment.

The backend needs to check the customer’s access to the order, identify the remaining line and quantity, and enforce cancellation eligibility against current fulfillment state. If warehouse release is happening concurrently, the operation needs a defined outcome. The agent can’t settle that race by sounding confident.

And the financial result depends on what happened earlier. There might be an unused authorization to release, a captured amount to refund, or a future collection that must now be prevented. “Refunded” is a specific outcome. So is “cancellation requested.”

UCP can represent post-order adjustments. Recording an adjustment still needs to follow the actual cancellation and payment work. The record alone doesn’t stop a parcel.

This is where the agent and microservices comparison becomes useful again. Suppose cancellation succeeds but the response is lost. The next attempt needs to resolve the same request, without creating a second refund or inventing a fresh operation.

Stripe’s idempotent requests help protect the payment call. The wider workflow still needs a durable identity for the business operation and a way to reconcile its result. One API’s retry protection doesn’t make an OMS, payment provider and warehouse share a transaction.

Nor can the integration assume events arrive neatly. Stripe explicitly documents out-of-order delivery and duplicate webhook events. The agent should read a reconciled view of the order, rather than treat the last message received as the final truth.

This is the demo I’d ask to see next

I’d run that one order all the way through. Show the split before purchase. Ship the fleece. Let the shell’s date move. Exercise the later payment failure. Then request cancellation while fulfillment is trying to proceed.

Lose a response somewhere in there and try again.

At each step, compare what the agent tells the shopper with the order, shipment and payment records. Can a support person reconstruct what was promised, what was approved and what actually happened without reading the entire conversation and guessing?

That’s the next proof I want from this work. The customer should be able to come back to the same conversation, ask about the shell, and get an answer that accounts for the fleece already on its way.

They still have a trip next Friday.

Related coverage

I also spoke with Billy Hurley at IT Brew about checkout failure states and the responsibilities behind taking orders online: Why “Place order” can be a dangerous button on a website, published October 6, 2026. More interviews and media coverage.