Five purchase fields your agent should send before checkout

An agent can make a bad purchase with clean payment credentials and a valid checkout session. The weak point is often the handoff: the agent sends too little context to the system that decides whether it should pay. A title without a seller is easy to misread. A price without shipping can be wrong by the time the cart closes. A one-time item can hide a subscription term in the page text. Before any payment token is used, the agent should send five fields clearly enough that a separate check can say approve, review, or block.

The fields are simple. Merchant and payee. Item and quantity. Total price, currency, and recurrence. Delivery, refund, and fulfillment terms. User authority and spending rules. If any one is missing, the safest answer is delay. The user can still approve the purchase, yet the agent should not treat an incomplete record as permission to spend.

1. Merchant and payee

Start with the seller the money will reach. In a browser flow, that means the origin being charged, not a label copied from the page. In a protocol flow, it means the merchant identity the checkout or mandate binds to the transaction.

AP2's Checkout Mandate docs define an allowed-merchant constraint for open checkout mandates, and the example merchant object includes a name and website. The broader AP2 specification also assigns the merchant responsibility for the integrity of inventory, pricing, and discounts. That is the right shape: the agent should identify who owns the offer and who will complete the checkout.

For Watchpost, the seller field is the merchant domain. Watchpost cleans that domain and keys the merchant trust check from it. A seller display name can help the human read the record, but the domain is the field that keeps a hostile page from borrowing a trusted brand's name.

2. Item and quantity

The item field should name what the user is actually getting. A product ID alone is useful for the merchant, yet it is poor evidence for a person reviewing a verdict later. A human can read "USB-C cable, one metre, black." They cannot judge "sku_7b31" without another lookup.

OpenAI's Agentic Checkout spec models checkout sessions around line items, item quantities, totals, fulfillment, payment information, links, and messages. ACP's public Checkout reference exposes the same pressure in a more mechanical way: line items carry item IDs and quantities, while fulfillment and total fields can change as the checkout progresses.

That is why Watchpost asks for a product title and accepts a product URL, description, and raw listing HTML when the agent has them. The title gives the record a readable name. The extra text feeds the listing scan, which looks for hidden instructions, billing language, and price mismatch signals. See how Watchpost checks each purchase for the current three pillars.

3. Total price, currency, and recurrence

The amount should be the final total the agent knows immediately before payment. Search results and product pages are early hints. Checkout is where tax, shipping, discounts, service fees, and currency become the actual charge.

ACP's checkout reference treats total rows and fulfillment totals as separate pieces of the session. Its fulfillment examples show shipping, digital delivery, pickup, and local delivery options, each with totals that can affect the final amount. OpenAI's checkout examples also show line-item base amount, discount, subtotal, tax, and total fields inside a session.

For Watchpost, the payment field is an integer amount in minor units plus a three-letter currency code and a recurrence flag. "$15.99" becomes 1599 USD. The integer matters because payment systems should not compare floating-point money. The currency matters because Watchpost does not perform foreign-exchange conversion. If the purchase is priced in EUR and the user's rules are in USD, the system sends that mismatch to review instead of pretending the numbers are comparable.

Payment controls tend to focus on what can be spent, where, and for how long. The ACP delegated payment reference describes allowance constraints for maximum amounts, expiration times, and usage scope. Stripe's Issuing for agents documentation describes virtual cards for autonomous purchases with spend controls, real-time authorization decisions, and transaction visibility. Those controls are useful, but an agent still has to carry subscription facts from the page into the purchase check.

Watchpost has a direct recurrence flag. The default rules require review for recurring purchases unless the user has explicitly allowed them. That keeps a free trial, membership, or usage plan from sliding through as a small one-time checkout.

4. Delivery, refund, and fulfillment terms

A purchase is more than the charge. The agent should carry the terms that decide whether the order is useful: shipping method, delivery window, pickup or digital delivery, return policy, and any refund limits it can read. These details often arrive late, after the agent has already chosen an item.

ACP's agentic commerce documentation describes checkout sessions with cart management, fulfillment options, and payment processing. Its public checkout reference separates selected fulfillment options from line items and totals. AP2's checkout mandate example also shows shipping and return policy fields inside a merchant-signed checkout payload.

Watchpost does not yet have separate delivery and refund fields in the direct request. The agent should still include these terms in the product description or listing text when it has them. That gives the listing scan and the human reviewer a better record than "Total: $15.99" with no context about what happens after payment.

5. User authority and spending rules

The last field is the authority behind the purchase. What did the user ask for? What limits apply? Which agent is acting? When does the permission expire? A checkout can be valid and still exceed the task the user gave.

AP2 separates this clearly. Its specification says human-present flows involve the user approving a closed checkout and payment, while autonomous flows rely on open mandates that contain constraints. The same spec says closed mandates in autonomous mode must match the constraints in those open mandates. AP2's security notes also assume agents can be attackers and call out manipulated discovery, manipulated payment, and double-spend risks.

Stripe's spending controls documentation shows the payment-layer version of the same idea: limits can apply per authorization or over an interval, overlapping limits use the most restrictive control, and spending aggregation can lag briefly. A purchase-safety check should receive the agent name and the user's current rules so it can compare the request against the authority the agent actually has.

A usable payload

A practical direct check has this shape:

{
  "agent": { "name": "claude", "runtime": "desktop" },
  "merchant": { "domain": "example.com", "displayName": "Example Shop" },
  "product": {
    "title": "USB-C cable, one metre, black",
    "url": "https://example.com/products/usb-c-cable",
    "description": "One-time purchase. Ships in 3-5 business days."
  },
  "payment": { "amountMinor": 1599, "currency": "USD", "isRecurring": false }
}

More context is allowed when the agent has it. Raw listing HTML can improve the listing scan. A native ACP checkout session or AP2 cart mandate can go through Watchpost's protocol adapters, with the missing merchant and product context supplied beside it.

The action today is small: take one agent that can reach checkout and inspect the last payload it sends before payment. If you cannot point to the merchant, item, money terms, fulfillment terms, and authority, hold the purchase for review until the agent can.