Designing an Agentic Checkout: Delegated Authority, Stale Quotes, Retries

Designing a checkout system used to be an easy interview slot, since a reference solution circulated everywhere and a decent candidate could reproduce it in twenty minutes. The current variant inserts a software agent between shopper and seller, and nearly every assumption baked into the memorized solution breaks. There is no canonical article to memorize for it, and that is the very reason it keeps being asked.

Why it appeared

Three developments landed within a short window.

First, an open standard. The Agentic Commerce Protocol, run jointly by OpenAI and Stripe, specifies how shoppers, their agents, sellers and payment processors talk to each other. At its heart is a shared payment token: the agent can finish a purchase without ever laying eyes on the card credential, and the seller keeps the role of merchant of record.

Second, a rival design. Google's Agent Payments Protocol treats authority as signed mandates, carried as selective-disclosure JWTs. One mandate proves the user approved the purchase and another proves approval of the payment, and each can be open, recording constraints in advance, or closed, tied to one final cart.

Third, security research moved fast. A systematic study of AP2 lists 48 separate threats grouped in five families, with eight rated high severity, all shown to work on a live testbed instead of merely described. For an interviewer that is ideal material, since the failure modes are real and specific and no gimmick is needed to give the question depth.

The prompt as it arrives

Wording varies, but the requirements are consistently close to these:

1. A shopper asks an assistant to purchase something, possibly adding limits such as a maximum price or a deadline for delivery.
2. The agent looks through several sellers, weighs the options and settles on one.
3. The payment goes through while the agent never touches raw card data.
4. The shopper can inspect what was approved, and disputes can be sorted out later.
5. No purchase is ever duplicated or carried out beyond what the shopper actually consented to.

The fifth requirement deserves a second read, because everything difficult lives there. These five lines produce every hard sub-problem below, and a candidate who opens by laying out that comparison, and not by drawing boxes, has already separated from most of the field. Practicing real payments-infrastructure questions is a quick way to get fluent in the vocabulary needed, since ledgers, idempotency and settlement all appear here in agentic form.

Problem one: delegated authority

The buyer is absent at the moment of purchase, so something has to stand in for consent.

The weak answer keeps a payment method on file for the agent to charge after the user says yes. This breaks because a yes at 10:00 to a coffee grinder under 80 pounds does not cover whatever the agent picks at 10:04. A model, a chain of tools and perhaps a tampered product description all sit in that gap.

The standards handle it in three ways:

• Permission becomes a signed object with a defined scope, rather than the mere holding of a credential.
• That object splits intent from execution: an open mandate holds limits such as a price ceiling and a category, and a closed mandate attaches to one specific final cart.
• Payment credentials are replaced by a token valid for one merchant and one transaction, so a stolen token buys a single item a single time.

Points worth stating out loud: limit every grant by amount, merchant, category and expiry date; demand the closed form before any money moves, so that the signed item and the purchased item are identical; and regard the mandate as the authorization record itself, not as a wrapper that makes card use more convenient.

Problem two: state binding, or why thorough agents decide on stale data

Almost nobody raises this unprompted, and it can be measured.

A diligent shopping agent reads many offers before it chooses. Whichever offer wins was read at the start of the comparison, which means the more thorough the agent, the staler its best data point.

A simulation attached a figure to this. The agent queries each seller one after another, spending three to eight seconds on each, then reasons over everything for five to fifteen seconds and commits. Prices and stock change as a Poisson process, and the result is the chance that the chosen offer had already shifted by commit time.

What stands out is the pattern. Going from one seller to twenty multiplies the chance of a stale decision by about five at every churn rate, so the very behavior shoppers want undermines the agent's own inputs. With fairly aggressive dynamic pricing, one in three careful comparisons ends in an offer that has already changed.

The design consequences are concrete:

• Quotes are objects issued by the server, each with an ID and a brief lifetime.
• The final authorization attaches to a hash of the completed cart, which is exactly what a closed mandate provides.
• At capture the seller rechecks price and stock, and refuses on any mismatch instead of fulfilling quietly.
• A refusal path re-quotes and sends the shopper back a message if the change violates the limits they set.

Candidates tend to forget the last point. Rejecting a stale order is correct behavior, and without a re-quote loop a pricing bug has merely become a reliability bug.

Problem three: retries, and the agent's worthless idempotency key

Idempotency keys come up in every answer, but there is a catch hiding in the usual setup.

Normally the client generates a key and sends the same one when retrying. Agents undermine that. If a response disappears, an agent often does not resend the identical request; it plans again, which yields a new request with a new key, and the server treats it as a fresh intent.

That behavior was modeled directly instead of assumed, with 5% of responses lost after the charge had already happened and up to three attempts:

• When the agent mints a new key per attempt, 4.98% of orders are charged twice, for 1.052 charges per order on average.
• When the key is derived on the server from the cart binding, duplicates drop to 0.00% and every order is charged exactly once.

The simulated 4.98% lines up with the closed-form probability of 5.00%, which makes sense because a duplicate occurs exactly when the first response goes missing.

The takeaway: build the idempotency key from something the shopper approved, not from something the caller made up. The hash that ties the closed mandate to the cart already serves, so no extra work is needed.

Problem four: who is the merchant of record

This is a business question dressed as a systems one, and it decides the data model.

• With a shared token, the seller stays merchant of record, so the agent platform avoids liability for settlement, tax and chargebacks.
• If instead the platform buys and resells, life gets easier for the agent while a whole regulated area comes along with it.
• State the assumption early, within two minutes, since refunds, tax and disputes all follow from it.

Problem five: auditability as a requirement

One of the five threat families in the AP2 analysis is entirely about accountability, meaning evidence retention and auditability. People skip it, yet it decides whether a dispute is resolvable six months later.

Per transaction, store immutably:

• Both forms of the signed mandate, open and closed.
• The precise cart hash that was approved, plus the cart contents behind it.
• The quote ID together with when it was issued and when it expires.
• The agent and model version that acted, and the delegation under which they acted.
• Each rejection and its reason, because rejections prove that controls were working.

A reference path

A clean answer walks one purchase end to end:

1. The shopper states a goal with limits, and the platform issues an open mandate bounded by amount, category and expiry.
2. The agent collects offers from candidate sellers, and each seller answers with a quote carrying an ID and an expiry.
3. The agent chooses one and asks for a final cart, which the seller signs.
4. The platform creates a closed mandate tied to that cart's hash, verifying it against the open mandate's limits.
5. A payment token is issued for that seller and that amount only.
6. The seller rechecks price and stock and then captures, with an idempotency key derived from the cart hash.
7. All artifacts from steps one to six are written to the audit store before any reply goes out.
8. A mismatch at step six returns to step two, or to the shopper if the change exceeds their limits.

Each of the eight steps exists because some specific failure would otherwise go unprotected, and linking each step to its failure is what an interviewer is really scoring.

Scoring a practice answer

Credit goes to answers that:

• state the delegation model within two minutes and then keep to it;
• split the open grant from the closed commitment and say why both are needed;
• bring up staleness unprompted, ideally with a ballpark number;
• build idempotency from approved state, not from what the caller supplies;
• treat the audit trail as a requirement instead of mere logging.

Credit is lost by answers that:

• picture the agent as a speedy human, when most of the difficulty comes from how it differs from one;
• give the agent any kind of reusable credential;
• assume a retry is the same request sent again;
• design a rejection with no next step;
• push liability and merchant-of-record questions to the end, although they determine the data model.

Why this prompt is worth preparing

Polish stopped being a useful hiring signal once a slick answer to every classic prompt became available for nothing. Agentic checkout is a present-day case where that shortcut is missing. The protocols are only months old, the threat research is newer, and the trade-offs have not settled into agreement.

That makes the prompt reward the skill standard question banks no longer exercise: reasoning from constraints that were truly understood. Learning it well also prepares for whatever question replaces it, since the core move does not change. Ask what changes once whatever sits on the other side of the API is no longer a human.