FeaturesAgent RevenueHow detection worksStrategiesPricingFor agenciesBlogSign inStart free
Tactical docs · Agent revenue

Agent order evidence

What's in the evidence pack Tactical makes for each agent order, how to download and check it, and how to use it when an order is disputed. Not legal advice.

When Tactical attributes an order to an agent, it makes an evidence record for that order: what Tactical saw around the order, in one file you can hand to a payment processor, a marketplace or a customer when the purchase is disputed, charged back or returned. You get it as a PDF and as JSON.

When a record is made

  • For agent orders only: orders labeled Agent order (the platform says an agent placed it) or Agent order (session match) (the buyer matches a storefront session Tactical classified as an agent browser). An AI-referred order doesn't get one: a person placed it.
  • At the moment of attribution, because what it records doesn't last: a session's full page list expires 30 minutes after its last event, and sessions and product views are deleted after 90 days. A chargeback can arrive months later.
  • Kept with the order record while your store is connected, and deleted with your store's data. If the platform sends the same order again, the record is rebuilt to match the attribution beside it.
  • Where Tactical gets orders: WooCommerce today. On Shopify it waits on order access (why). Orders attributed before 27 September 2026 have no record.

Downloading it

In the dashboard, open Agent revenue. The Recent agent orders table lists the last 20 agent orders; the Evidence column has PDF and JSON links. An order attributed before evidence records existed shows "none".

For an older order, open this address while signed in to that store:

/dashboard/agent-revenue/evidence/ORDER_ID?format=pdf
/dashboard/agent-revenue/evidence/ORDER_ID?format=json

Only the store the order belongs to can download it; any other request gets a 404. The files are named agent-order-evidence-ORDER_ID.pdf and .json.

Checking a copy

The JSON is the record in canonical form (keys sorted, no whitespace). The PDF prints the SHA-256 hash of that JSON on every page, and the download carries it in an X-Evidence-SHA256 header. Hash the JSON file and compare:

Get-FileHash .\agent-order-evidence-ORDER_ID.json -Algorithm SHA256
shasum -a 256 agent-order-evidence-ORDER_ID.json

(The first is PowerShell, the second macOS or Linux. PowerShell prints the hash in capitals, so compare the two ignoring case.) A match shows the PDF, the JSON and Tactical's stored record are the same record. It isn't a signature: it doesn't prove who made the record or when.

What's in it (format version 2)

Section Fields
Header v (format version), kind (agent_order_evidence), generatedAt, store, synthetic
order id, platform, ts, total, currency, status, lineItems (productId, variationId, sku, name, qty, price)
attribution tier and tierLabel, confidence, estimated, method, agentId, agentCategory, agentType, channelMarker (the platform's marker, for an Agent order), pixelVisible (whether a browser pixel could have seen the order), sessionId
session startedAt, lastEventAt, durationSeconds, pagesViewed, entryPage, exitPage, viewedPages (paths in order, up to 50, or null once the list had expired), productsViewed (up to 100: productId, title, firstSeenAt, addedToCart, onOrder), cartEvents, checkoutInitiated, visitorType, agentType, agentScore, agentConfidence, intentLevel, signals (detectionMethod, datacenterIp, mouseEvents, scrollEvents, avgTimeBetweenPagesMs, referrerDomain, aiReferralSource, country). Null for an Agent order with no storefront session.
identity registryAgentId, displayName, operator, category, source (where the agent named itself: order_channel, buyer_user_agent or gate_decision; null if it never did), declared, verification
protocol name, sessionId, scopeGranted, sessionKind: reserved for agents that sign in under an identity protocol such as the Personal Agent Protocol. Always null today.
gate linked, windowHours (24), decisions (up to 100: ts, ruleId, intended, effective, mode, policyVersion, path, scopeAction), truncated
limitations Plain-language sentences about what this record can't show

Records made before 9 October 2026 are format version 1, which has no protocol section; their hash is unchanged.

identity.verification is verified when a Tactical Gate enforcement point verified the agent, not_verified when Gate decisions exist but none verified it, and not_checked when there are no Gate decisions. Gate decisions appear only for a store that runs Tactical Gate, which is in beta (join the Observe beta).

What it never holds

No buyer name, email, phone number, address, payment details, IP address or user agent. Page paths lose their query strings. Gate decisions are found with a one-way hash of the buyer's IP address and user agent, and that hash isn't stored in the record.

Its limitations

Each record lists the ones that apply to it. In short:

  • A session match is a match, not proof. It uses a hash of the buyer's browser user agent within 24 hours of the order, which anyone on the same browser version shares. It is high confidence when the session viewed a product on the order, and estimated when it only reached the cart or checkout.
  • An Agent order may have no session. The agent may have checked out without loading the storefront.
  • The classification is a judgement from how the browser behaved, not proof of who controlled it.
  • A declared identity is a declaration. A user agent can be copied. Tactical doesn't check agents' request signatures yet, so today no record calls an identity verified.
  • Gate decisions are sampled. Gate records every request it restricts, but allowed requests for only about 1 in 100 sessions.
  • Demo orders are synthetic. Orders on Tactical's demonstration store go through a sandbox checkout, with no payment taken and nothing shipped; synthetic is true and the PDF says so at the top.

Using it in a dispute

This is not legal advice. Your payment processor tells you what a dispute needs and by when; start there, and ask your processor or a lawyer about anything that matters.

  • Lead with the payment evidence. For an "I didn't authorise this" dispute, your processor's record of the payment and your history with the card carry most weight. The record adds what happened on your store before the order.
  • It isn't a Visa Compelling Evidence 3.0 submission. Those rules match earlier payments on the IP address or device (Stripe's summary), and this record deliberately holds neither.
  • Attach what answers the dispute's reason. Processors ask for short, relevant evidence (Stripe's guidance). You don't have to attach every page of the PDF.
  • Keep the limitations with it. They stop anyone reading more into the record than it holds.
  • Download what you may need. Records are deleted with your store's data if you disconnect it.

Background: Who's liable when an agent buys? · How agent orders are attributed

[email protected]
How detection worksDrop WatchAgent revenuePricingStrategies comparedPerformancePrivacyTerms