Agent-Ready Checkout: Approve the Total, Then Verify the Payment

A shopper asks an assistant to buy a compatible laptop charger for no more than 60. The product costs 49. Shipping adds 6 and an assumed tax adds 11: the total is 66. The shop has not found an agent-payment problem yet. It has found an offer outside the shopper’s budget. The amounts use one unspecified currency and are an illustrative calculation, not a tax recommendation.

Now suppose the shopper approves a revised 66-total purchase through a supported route. The payment request times out. Did it fail, or did the provider charge the customer while the response was lost? “Try again” is a dangerous answer if it means creating another payment.

These two moments explain agent-ready checkout better than a list of protocol logos. First, prove that the current purchase is allowed. Then establish what actually happened. The fictional electronics shop below is a teaching example, not a live sales result.

Quote the whole purchase, not just the item

The original 60 limit does not cover a 66 final total; the difference is 6. Do not silently reinterpret the limit as an item-only budget or split the payment to evade it. Present a permissible alternative or obtain the required fresh approval. Changing delivery, quantity, connector, currency or seller may also change what was approved.

A useful quote identifies the exact variant and compatible device requirements, item amounts, discounts, tax, shipping, currency, delivery estimate and any other applicable charges. State validity and stock-reservation conditions. If a relevant term changes, revalidate and refresh authority rather than charge an obsolete quote. A cart alone does not guarantee a reserved item.

Not every buyer needs the same route. A shopper may approve on your own checkout page, transfer a cart or use an eligible in-assistant integration. Google’s native-checkout guide describes a supported checkout lifecycle, not universal enrolment. Confirm the route and version your merchant can actually use.

Ask four different trust questions

Recognising the caller, proving the shopper’s authority, using a valid payment credential and assessing the transaction are related checks, not substitutes. The table separates them. An agent can be genuine and still request an unauthorised purchase; a shopper can approve a purchase that normal controls must nevertheless refuse.

AP2’s mandate model distinguishes direct approval of a cart from delegated instructions for later action. Apply the actual supported mandate and its limits; a chat transcript alone is not a verified mandate.

FIDO’s April 2026 announcement describes standards-development work based on AP2 and Verifiable Intent contributions. It is not a certificate that every merchant integration is interoperable today.

Question	Evidence to check	What it cannot replace
Who is calling?	Supported caller/session verification	Buyer authority or permission for every endpoint
What did the buyer allow?	Current exact cart or scoped delegation	Payment processing and fraud controls
May this credential be used?	Provider-validated scope, amount and validity	Product suitability or all customer intent
What happened to the transaction?	Verified provider and merchant records	Settlement, delivery or dispute outcome by itself

A token narrows access; it does not prove everything

Stripe’s current seller guide describes seller-scoped Shared Payment Tokens with usage and expiry limits, including recurring configurations. Do not assume a universal bank-issued, one-use, thirty-minute credential.

Ask which provider validates the grant, which seller and currency it covers, what amount and use conditions apply, and how expiration or revocation is enforced in your integration. Match the credential to the approved purchase and current account permissions. A valid payment credential alone does not establish product compatibility or the customer’s intended quantity.

Keep credentials out of prompts, model memory, screenshots, analytics and ordinary logs. Store only necessary protected references and evidence under the applicable retention policy. Tokenization does not remove your responsibility for access control, secure handling and the payment-compliance obligations of your chosen flow. Use supported provider libraries rather than inventing cryptography.

A timeout means unknown until you reconcile it

Create a durable local operation reference before the consequential request, and bind it to the approved order and payload. Retries of that same operation must not become fresh charges. Concurrent requests also need local duplicate protection; a new key on each click defeats the intention.

After a timeout, query the existing provider/session reference and process authenticated evidence. If still unknown, retain that state, explain it to the shopper and queue a bounded reconciliation with backoff, jitter, an attempt limit and an owner. Do not announce payment failure, release all safeguards or fulfil twice merely because your request ended.

Stripe’s idempotency rules differ by API version: v1 can replay a saved server error, and a pruned key may create a fresh request. Do not blindly switch keys to escape an error.

Distinguish payment authorisation, capture, merchant order acceptance, settlement and fulfilment. A screen saying success or an assistant reporting “paid” is not your sole evidence. Stripe’s webhook guidance calls for signature verification and handling duplicate or out-of-order events. Validate the actual provider state and make local effects safe to repeat.

Keep fraud checks and customer permissions

A signed request can help establish a caller under a supported trust scheme. It is not an allow-all rule for product, order and payment endpoints. Verify the expected issuer or key, audience and freshness where required, and enforce the endpoint’s current permissions and limits. A forged “AI agent” header proves nothing.

Use relevant fraud signals without treating absent mouse movement as a complete decision. A verified agent still needs transaction checks; unverified automation is not automatically fraud. Depending on the case, deny the request, request supported additional verification or direct the buyer to a normal authorised route. Human confirmation does not override a legal prohibition, stolen credential or unresolved security failure.

Scope status and return actions to the verified buyer or authorised representative and the correct account/order. Keep private stock, addresses, invoices and payment data out of public discovery responses. Set safe rate limits and monitor replay, velocity and attempts to turn one approval into multiple orders.

Keep evidence through receipt, return and dispute

Confirm the actual order reference, items, total, currency and current status through the route the buyer can use. Provide an agreed support/contact path; a legitimate relay address is not automatically invalid. Do not rely solely on the assistant to deliver a receipt. Tracking or shipped status is not proof of delivery.

For a return, check the applicable policy, legal rights, received goods and authorised remedy separately from the payment operation. Stripe’s refund guidance returns funds to the original method and distinguishes failed refunds and permitted alternatives. Follow the documented exception process instead of improvising an unrelated transfer.

Retain the approved quote/version, authority reference, provider references, relevant policy, customer communications and fulfilment evidence with restricted access. Do not retain a usable token as an audit attachment. Check refund/dispute overlap to avoid double reimbursement, and reconcile the refund’s final result.

Ask the acquirer or payment provider who handles each dispute type, authentication step, evidence deadline and liability condition for your actual programme. A signed mandate can be useful evidence without guaranteeing a dispute win or transferring every loss. Do not infer a universal liability rule from a marketing announcement.

Pilot the failure paths before expanding

Use an eligible sandbox and approved test identities, not production card details. Test the 66 total against the original 60 limit, changed cart after approval, expired or revoked credentials, wrong seller/currency, duplicate completion, timeout after provider success, delayed and replayed events, incompatible product, private status access and partial refund/dispute overlap.

Have an operator demonstrate the end-to-end records: one approved purchase, the intended payment outcome, one fulfilment decision and a traceable customer remedy. Assign unknown payments a response deadline, escalation and stop condition. A sandbox pass does not prove live market eligibility or every issuer’s behaviour; confirm those separately with the provider.

Track approved attempts, successful captures, unknown outcomes, duplicate incidents, fulfilment errors, support workload and refunds/disputes with explicit denominators and observation windows. Expand only when the team can reconcile orders and money and recover from the failures. The useful promise is a controlled purchase journey, not an autonomous sale at any cost.

Part 3 of the AI shopping series. Read purchase routes and merchant readiness and product discovery and GEO alongside this checkout guide.

Reviewed 5 November 2026. Anichur Rahaman is the creator of StoreConsole. Scenarios and amounts are illustrative; payment-programme terms and supported capabilities vary.