9 Checkout Fields Your Agent Should Justify Before Sharing

1. Phone number: what purchase task needs it?

A phone number may support delivery coordination or a required contact process. Ask which purpose applies to this purchase, which party receives the number and whether it is required or optional. Do not carry a number from the agent’s memory into a merchant form merely because the value is available.

Write what the merchant is doing for the buyer: delivering a physical item, enabling a digital service, issuing an invoice, processing a payment or satisfying an applicable restriction. These purposes can require different information. A record called “checkout data” is too broad to explain why a particular field should be shared.

The UK ICO’s data-minimisation guidance grounds the review in adequacy, relevance and necessity for the stated purpose. It is UK-specific guidance and is under review following legal changes. DN’s operational inference is narrower: the agent should be able to state why it is supplying each field, and preserve unanswered questions.

Record the purpose separately from consent to promotional messages. If the merchant cannot complete an approved delivery without phone contact, that is a concrete condition to present to the buyer. If it is optional, the user’s purchase instruction does not automatically authorize sharing it.

2. Date of birth: is the exact date necessary?

Identify whether the seller is checking an applicable age restriction, matching an account or asking for profile information. The same visible field can serve different purposes. The agent should retain the stated purpose and the precision requested before deciding that a full birth date belongs in the purchase.

Where an eligibility result or age band could answer the relevant question, check whether the merchant supports that less detailed route. Do not replace a required verified process with a guessed value. The operational question is whether the legitimate completion route needs the exact date, and who can approve sharing it.

Do not place personal values into the public worksheet. A useful entry is “date of birth: purpose not established,” not the actual date. The matrix is a review of fields and purposes, so it can be useful without becoming another store of the information it is trying to minimize.

For repeat purchases, treat the earlier decision as conditional evidence. A field justified for one restricted product may be unrelated to another purchase. Reusing the purpose rule is useful; assuming permanent approval for the information is not.

3. Gender: which service requirement depends on the answer?

Do not infer a buyer’s gender from a name, profile image or prior conversation to complete a checkout. Establish what the field changes in the service and whether the buyer has authorized supplying it. An unexplained mandatory field remains a question to resolve, even if an agent could invent a plausible answer.

A personalized product or service can have legitimate selection requirements, but those should be described concretely. The buyer may need a sizing choice, a service configuration or another preference. Check the required input rather than assuming a broad demographic label is an adequate substitute for what the purchase needs.

Where a field appears optional, confirm what happens when it is left blank through a permitted test or clear merchant documentation. Some interfaces label a field inconsistently with the later validation step. Record that mismatch as an implementation question. Do not fill it with fabricated information merely to finish the order. The buyer needs a supported completion route and a clear explanation of any information the merchant actually requires.

Keep optional profile completion separate from order completion. If the field can be omitted, record that supported route; if it cannot, show the buyer the unresolved purpose instead of quietly widening the scope of consent.

4. Street address for digital delivery: which part is for billing?

An electronically delivered item does not need a parcel destination, but that does not establish that the purchase needs no address or region information. Billing, tax or eligibility requirements can differ from delivery requirements. Identify the actual requested purpose and the minimum information the supported process needs.

Test a field decision against a changed transaction. A physical delivery may require an address that a digital-only purchase does not. A business invoice may require an organization name that a personal receipt does not. The matrix should record the condition that makes the field relevant, not attach a permanent necessary or unnecessary label to the field name. That conditional record is also easier to reuse safely: the next agent can see when the old conclusion stops applying.

Keep billing and delivery fields separate in the record. A saved shipping address should not be copied into a digital purchase merely because the form supports it. Equally, an agent should not omit a legitimate billing requirement based on the label digital. The relevant decision is specific to the product, buyer, region and payment route.

Record any mismatch between documentation and form validation. A field described as optional but required later is an implementation issue to clarify, not evidence that false data is acceptable.

5. Precise location: does region-level evidence answer the question?

Determine whether the purchase depends on a delivery destination, service area or current device location. Those are different facts. A merchant asking whether a service is available in a region may not need continuous location access. Check the supported alternative and preserve the precise scope of any permission.

Current Google UCP native-checkout documentation separates agent-assisted cart work from a user interface handling sensitive fulfilment and payment details. That illustrates a useful architectural distinction. It does not establish that every agent must or should hold all the fields later required to complete payment.

Keep an agent’s access separate from the checkout system’s needs. The user may be able to provide sensitive fulfilment details directly in a supported interface while the agent receives only completion status. The documented architecture is a boundary to inspect, not proof that every implementation already isolates the information correctly.

If location evidence must be refreshed, record the event that triggers it. Do not convert a one-time purchase decision into an ongoing permission without a separate, clear basis.

6. Employer or job title: is it needed for the invoice or eligibility?

A business invoice may require an organization name while a personal job title serves no identified purchase purpose. A professional or business-only offer may have its own eligibility requirements. Preserve the distinction and check what the seller actually needs to establish the relevant fact.

Record the requesting party as well as the visible form. An embedded payment service, merchant, identity provider and optional analytics service can have different roles. The practical question is where this answer goes and which part of the purchase depends on it. Do not equate a single checkout screen with one data recipient.

Do not supply the buyer’s employer to every downstream recipient just because one invoicing step needs it. Record the recipient and role of the request. Where the purchase is personal, a stored work profile should not quietly determine the billing identity or make a business representation the buyer did not approve.

An unresolved purpose can change the approval decision without making the whole merchant unsuitable. Ask the bounded question first: can this specific purchase be completed through a supported route without the unrelated field?

7. Government identification: what verified process requires it?

Treat identity-document requests as their own decision. Record the exact evidence requested, the checking party, the stated purpose and the supported submission route. The agent’s general authority to buy a product does not explain whether it may obtain or transmit identity documents.

There are purchases for which identity or other eligibility checks are legitimate and necessary. The matrix does not tell an agent to evade them, provide false details or bypass a merchant’s access rules. It tells the operator to distinguish a required verified process from optional profile enrichment and unexplained collection.

Do not put document values or images into the public counter or a general-purpose audit note. Keep only the field category, evidence status and appropriate reference in the review. If the user must complete a verification directly, the agent can preserve the unresolved workflow state without handling the underlying document.

Use the same standard for alternatives: they must be legitimate, supported and adequate for the actual requirement. An easier path that bypasses a necessary eligibility check is not a valid completion route.

8. Contact-list access: why does this purchase require other people’s details?

Contact-list access is especially easy to misunderstand as a convenience permission. Sharing a referral with a friend and uploading a whole address book are different actions. The agent should not treat permission to buy a product as authorization for either. If a request cannot be justified within the approved task, pause that part of the workflow and ask a specific question.

Write the smallest action the buyer requested. Sending one supported referral, selecting one recipient and uploading an address book expose different scopes of information. The operator should be able to explain which action is needed and where the resulting information goes. A convenience label should not erase those differences.

If the purchase can proceed without the permission, keep the referral or social feature separate. If access is presented as mandatory, seek the stated purpose and any supported alternative. Do not fill the gap by assuming that information about the buyer’s contacts is covered by permission to use information about the buyer.

A field that was justified once should not become permanently approved for every merchant. The product, jurisdiction, payment route and purpose may change. Reuse the structure of the review, but recheck material differences before auto-filling stored context.

9. Marketing preferences: did the buyer approve this separate purpose?

Keep optional preferences separate from required order processing. If the agent completes a purchase for a user, that should not silently turn into a new instruction to join promotional messages or enrich a customer profile. Use the actual user authorization and applicable merchant process rather than assuming more data creates a better transaction.

Illustrative scenario: a digital research purchase has nine requested field categories. Six have a documented purchase purpose, two are optional preferences the buyer has not authorized, and one mandatory request remains unexplained. The useful conclusion is one blocking question plus two optional disclosures to omit or decide separately. It is not “67% compliant.”

For a team, the reusable asset is a documented purpose rule with an owner and review trigger. For example, a billing requirement can point to the finance team’s confirmed policy; delivery requirements can point to the carrier process. Exceptions should identify the specific reason, not silently expand the default record.

A good agent can say: this field is needed for the stated purchase purpose; this one is optional; and this one needs clarification. That is more useful than either filling every box or refusing all personal information. Keep the buyer’s decision visible at the point where information leaves the current context.

After the purchase, review what was retained in logs and downstream systems under the applicable policy. Limiting collection at checkout is only one part of handling personal data. It should connect to access, retention and deletion decisions without claiming that this small matrix completes those wider obligations.

Frequently asked questions

Primary sources

1. ICO: Data minimisation. UK guidance calls for adequate, relevant information limited to the purpose; guidance is under review following UK law changes. Reviewed 2026-11-11.
2. Google UCP: Native checkout overview. Native checkout distinguishes agent checkout activity, buyer interaction and downstream fulfilment. Reviewed 2026-11-11.

Related DN research

• AI Shopping Agents vs Human Buyers
• AI Agent Importer of Record