10 Purchase Fields Your Agent Must Preserve From Approval to Refund

1. The buyer requirement that made the purchase acceptable

Write the job before recording the offer: who needs the purchase, what it must do and which conditions make it unsuitable. A named arrival deadline, required software right or accessibility need can matter more than a small price change. Keep mandatory conditions separate from preferences the buyer is willing to trade. The agent should carry this requirement version through checkout and aftercare.

Use a stable local purchase reference and an approval version. Attach the original evidence or a permitted snapshot, its retrieval time and the person or policy authorizing it. A later order identifier helps join the transaction but cannot reconstruct a missing approval. If a field was unknown at approval, preserve that uncertainty rather than filling it retrospectively from whatever the merchant delivered.

If the requirement changes, retain both versions and the person or policy authorizing the change. A later delivery date might be acceptable after the event moves; it should not appear to have satisfied the earlier deadline. This record makes the eventual outcome assessable against the decision actually approved.

2. The exact product, variant and rights

Product identity needs enough detail to distinguish a suitable replacement from a different purchase. Record the model or service, variant, condition, included features and any rights that materially affect use. A familiar product name may cover different storage sizes, subscription tiers, regions or licence types. A match on the headline name alone leaves those conditions unresolved.

Map the approved identity to the cart, confirmation and received item. If an identifier changes, retain the evidence connecting the old and new identifiers. Ask whether a substitute needs renewed approval even when its price is lower. An agent cannot authorize a reduction in the buyer’s requirements by describing a different item as equivalent.

For inspection, retain only the evidence needed for the declared decision. A product photograph might support condition, while an account entitlement supports access rights. Neither automatically proves the other. Keep a disputed condition open alongside the cash result.

3. The seller that carries the relevant obligation

Preserve the contracting seller’s identity through the listing, checkout and receipt. A marketplace, payment processor, fulfilment provider and seller can play different roles. The purchase record should show which party promises the product and which party is expected to handle the relevant support or refund. A payment descriptor alone may not answer that question.

A seller substitution can matter even when product and total price remain unchanged. The buyer may have approved an invoice requirement, service territory or support route tied to the original seller. Record the new party as a change needing evaluation, not as a spelling correction to the old record.

Define which changes require renewed approval. A seller substitution, materially different delivery date or changed product condition may matter even when the total falls. A permitted adjustment should say what may vary and by how much. This is a buyer-side method: the current AP2 specification supports structured authorization, but adoption and implementation must be checked for the actual merchant.

4. The quantity and its unit

Write quantity as a number and a unit. Three packs are different from three individual items; a ten-seat entitlement is different from ten separate personal licences. If a merchant splits an order, the line-level quantities should still reconcile to the approved total. The record needs to show whether a difference is a partial shipment, cancellation, replacement or unresolved omission.

Keep purchased, shipped, accepted, returned and outstanding quantities separate where those states matter. A partial delivery can be valid without closing the whole purchase. Conversely, an aggregate order status can hide the one missing line that made the purchase useful.

Set tolerances explicitly when the purchase legitimately permits variation. Do not infer permission from a lower final bill. The buyer’s approval should say whether a smaller quantity is acceptable and what happens to the unfulfilled balance.

5. The total-price scope the buyer approved

Preserve the approved currency, tax treatment, delivery costs, discounts and any amounts excluded from the displayed total. A price can change because the quantity changed, a delivery option changed or a previously unresolved charge became known. Keep the reason beside the amount; a final sum cannot explain those differences by itself.

Define the approval ceiling and what it includes. If tax is unresolved, label it unresolved and identify the condition under which the buyer will approve payment. An allowance for a known variable charge is different from unlimited authority to accept later fees. The agent should make that distinction visible before committing.

For example, an illustrative order contains a 200 CU device and 100 CU accessory. The device arrives; the accessory is replaced by a 40 CU alternative with approval. The expected final purchase amount becomes 240 CU. That conclusion requires the approved substitution record. A 240 CU final debit on its own would not establish that the correct device arrived or that the substitute met the buyer’s requirements.

6. The order-line links between the original and later events

Use a stable local purchase reference to join the approval to merchant order lines, shipments, replacements and adjustments. Keep the merchant identifiers as evidence rather than treating one identifier as the entire history. A split shipment or replacement can create new references without becoming an unrelated purchase.

Make the join rule explicit when the merchant changes identifiers. A replacement shipment may have a new order number, while a refund may retain the original payment reference. Record the relationship as a replacement or adjustment instead of pretending the identifiers are identical. If that relationship cannot be evidenced, retain an unmatched event. The person reconciling the purchase should be able to move from the approved line to the new reference without relying on an agent’s narrative memory.

Check the joins before accepting the totals. If two items have equal prices, a refund matching the expected amount can still belong to the wrong line. The useful record lets another operator trace a particular approved item through each later event without relying on the agent’s conversation history.

7. The fulfilment state and who reported it

Record what was promised, dispatched, received, accepted, rejected or returned for each relevant line. Preserve the source of the assertion. A merchant confirmation, carrier event and buyer inspection provide different evidence, even when their timestamps are close. None should silently overwrite the others.

Google’s order-lifecycle documentation illustrates why post-purchase data belongs outside a simple checkout-complete flag. DN’s proposed record adds the buyer’s expected state beside the merchant’s event. Keep who reported each fact: a carrier scan, merchant assertion and buyer inspection are different evidence, even when their timestamps are close.

Keep completion conditions tied to the buyer’s job. Delivery to a building might still leave installation, access or inspection unresolved. State whether those steps are in the agent’s assigned scope and who owns any remaining work. A financially reconciled order can therefore remain operationally incomplete.

8. The payment events that actually moved cash

Stripe’s capture reference demonstrates the distinction between authorization and capture. Its refund-status guidance also shows why refund initiation is not equivalent to cash received. These are implementation examples, not a universal timing promise. Use the states and evidence available from the actual payment provider and bank.

The cash equation is deliberately narrow: posted net payment = posted debits − posted refunds. Keep pending authorizations and pending refunds beside that number. Do not subtract a promised refund from actual money paid, and do not count an authorization again when the corresponding capture posts. Where bank and merchant records conflict, preserve both with their timestamps and assign a reconciliation owner.

Choose an explicit cutoff time for every reconciliation. A refund reported by the merchant after that cutoff belongs in the next version; it should not rewrite the historical result. Record whether the comparison uses the bank posting date, the provider event time or the merchant event time. This prevents a timing difference from being mistaken for a permanent loss and lets another operator reproduce the state that prompted the original escalation.

9. The adjustment that explains each refund or reversal

Join a cancellation, return, substitution or agreed discount to the resulting adjustment. Record the amount requested, the provider’s current state and the cash actually posted at the chosen cutoff. A promised refund is useful evidence of expected action; it should not be counted as received money.

In the illustrative order, 300 CU has posted as debits. The merchant has initiated a 60 CU refund, but no refund has posted. There is also a separate 100 CU pending hold. The calculator reports 300 CU posted net payment against the 240 CU expected final amount: a 60 CU reconciliation difference. It also displays the 60 CU pending refund and 100 CU hold separately.

That difference does not by itself prove an overcharge. It identifies a state requiring follow-through. If the 60 CU refund posts, net payment becomes 240 CU. If the hold remains, it is still an unresolved liquidity question even though the posted amount now matches. If delivery remains unconfirmed, the purchase still cannot be called fully completed.

The unchanged calculator above intentionally displays posted cash, pending refunds and holds separately. It summarizes entered totals; the underlying record must still establish which adjustment belongs to which line. A positive reconciliation difference identifies follow-through work and does not, by itself, prove an unlawful overcharge.

10. The remaining obligation and the owner who will close it

Set completion conditions before asking the agent to buy: approved identity preserved, relevant fulfilment accepted, charges reconciled, required adjustments received and remaining disputes assigned. Some purchases need a continuing warranty or service record after financial closure. That is a separate retained obligation, not a reason to leave the accounting permanently ambiguous.

Give each exception an owner and next review date. For a pending refund, record the provider’s actual reference and stated next step. For a disputed substitution, retain the approval boundary. For a missing parcel, retain the line and fulfilment references. Avoid attaching unnecessary personal information to a general audit record; use the minimum evidence needed to resolve the issue.

A final amount of 240 CU can conceal two offsetting errors: an incorrect extra charge and an unrelated refund of the same size. Therefore reconcile at the event and line level before accepting the aggregate. The local calculator is a useful summary of entered totals; it cannot detect missing events, verify bank evidence or infer which refund belongs to which order.

Retain an explicit close date and the evidence supporting it. In a second synthetic case, two 50 CU charges and a 50 CU refund produce the expected 50 CU net payment. The duplicated charge and its reversal still belong in the history because they explain temporary cash use and preventable repair work. Matching totals should make the record easier to resolve, not erase how it reached that state.

Frequently asked questions

Primary sources

1. Google UCP: Order lifecycle. Post-purchase order, fulfilment and adjustment records are separate from checkout completion. Reviewed 2026-11-11.
2. AP2 v0.2 specification. Current v0.2 uses open/closed CheckoutMandate and PaymentMandate; use the current terminology rather than older Intent/Cart examples. Reviewed 2026-11-11.
3. Stripe: Capture a PaymentIntent. Authorization and capture are distinct payment states; capture may be less than the amount authorized. Reviewed 2026-11-11.
4. Stripe: Understanding refund statuses. A refund request or pending refund is not the same as money received by the customer. Reviewed 2026-11-11.

Related DN research

• AI Agent Outcome Receipts
• AI Shopping Agents vs Human Buyers
• AI Agent Wrong Payment Liability