# Entire - Agent Payment Report

Entire has early payment signals, but needs clearer documentation.


- Domain: entire.io
- Category: Other
- Company type: other
- Payment systems found: None detected
- Agent interfaces found: None detected
- Payer platforms or methods: None detected
- Vendor roles: None cataloged
- Strongest evidence: **Not evaluated**
- Overall rank: #200 of 2354
- Score version: `agent-payments-v7`
- Last scanned: 2026-08-26T23:56:47.167+00:00

## Payment documentation

- No payment protocols documented.

## Scores

| Dimension | Score |
|-----------|-------|
| Payment readiness | 0 |
| Agent access | 36 |
| Overall readiness | 25 |

An em dash means there is not enough evidence to calculate that dimension. A public support claim is not treated as a completed payment.

## Payment Checks

Each section shows what was found, what still needs work, and the strongest available evidence. Not-applicable systems do not reduce the score.

### x402 payments

- Company signal: Not detected

#### Is at least one accepted payment option complete enough for a payer to execute?

- Status: Needs fix
- Result: No x402 payment challenge was available to check payment amount, network, asset, recipient, and resource details.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Populate at least one executable x402 V2 payment option with scheme, CAIP-2 network, asset, positive amount or maximum, payTo recipient, and exact resource binding. Generate the challenge through the official server scheme instead of hand-writing the payload.

#### Is the payment challenge protected from stale public caching?

- Status: Needs fix
- Importance: Recommended
- Result: No x402 payment challenge was available to check whether old challenges are blocked from caching.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Return Cache-Control: no-store on every unpaid x402 response and derive the challenge from the current request so changed routes, bodies, prices, or recipients cannot receive a stale cached challenge.

#### Is there a concrete paid endpoint or tool the agent can discover?

- Status: Needs fix
- Result: No public x402 paid endpoint was found for this company domain.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Publish the exact paid route and method in first-party OpenAPI/docs or x402 Bazaar, including price, network, asset, payee, protected result, and testnet instructions. The published route must return a complete x402 V2 PAYMENT-REQUIRED challenge on an unpaid request.

#### Are HTTP, MCP, and A2A x402 claims evaluated separately?

- Status: Not detected
- Result: Transport separation is not scored because no x402 protocol artifact was available.

#### Does an unpaid request return an x402 challenge?

- Status: Needs fix
- Result: No x402 endpoint was available for a test request without payment.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Return HTTP 402 directly from the documented paid route with a decodable x402 V2 PAYMENT-REQUIRED header; do not redirect or return a generic payment error. Ensure gateways and middleware preserve the payment header unchanged.

### MPP payments

- Company signal: Not detected

#### Can the agent understand the shared and method-specific payment terms before payment?

- Status: Needs fix
- Result: No payment terms were decoded.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Add the shared amount and currency or asset fields plus every field required by the selected MPP method and intent, such as recipient and resource description when applicable. Ensure the advertised terms exactly match the runtime payment handler.

#### Are MPP challenges cache-safe?

- Status: Needs fix
- Importance: Recommended
- Result: Cache headers were not scored because no MPP Payment challenge was detected.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Return Cache-Control: no-store on every MPP 402 response at both the application and edge layers so intermediaries cannot replay stale payment challenges.

#### Is the MPP challenge identifiable and bound to a payment intent?

- Status: Needs fix
- Result: No challenge identity was inspected.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Include a bound challenge id, realm, lowercase payment method, registered intent, and decodable method-specific request parameter in WWW-Authenticate: Payment. Generate and verify the challenge with the MPP SDK instead of concatenating header text.

#### Does an unpaid request return an MPP Payment challenge?

- Status: Needs fix
- Result: No Payment auth challenge was inspected.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Return HTTP 402 directly from the paid route with a syntactically valid WWW-Authenticate: Payment challenge. Use official MPP middleware and ensure reverse proxies preserve the authentication header.

#### Is the MPP service discoverable from the expected OpenAPI route?

- Status: Needs fix
- Result: The MPP API host does not publish an OpenAPI file that lists paid operations.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Serve OpenAPI 3.1 from GET /openapi.json on the MPP API origin and add x-payment-info.offers to every paid operation. Generate offers from the same route and payment configuration used at runtime, document the 402 response, and make `mppx discover validate <openapi-url>` pass.

#### Is the MPP service publicly listed?

- Status: Needs verification
- Importance: Optional
- Result: Public listing is curated and not automatic after protocol validation.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: After the deployed endpoint exposes valid MPP discovery or a runtime Payment challenge, register its exact production URL in MPPScan and submit it to the public MPP service directory only if it accepts live MPP payments. Keep registry metadata synchronized with /openapi.json.

#### Is there a concrete payable resource or tool?

- Status: Needs fix
- Result: A URL, OpenAPI operation, or protocol mention is not enough to prove a concrete payable MPP resource.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Publish a concrete MPP-protected route in /openapi.json and configure that same route to return HTTP 402 with WWW-Authenticate: Payment when called without credentials. Do not count a generic paid API URL or registry listing as the protected operation.

#### Is the challenge bounded to the current request and validity window?

- Status: Needs fix
- Result: The challenge does not include enough request-bound payment terms to verify it safely.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Bind the MPP challenge to the protected method, URL, and material query or body fields, include a short expiration, and reject an Authorization: Payment retry when any bound value changes.

### UCP checkout

- Company signal: Not detected

#### Are declared external UCP service endpoints reachable?

- Status: Needs fix
- Result: No UCP service URLs could be checked because no public UCP setup file was found.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: For every external UCP service binding, publish the transport-specific HTTPS endpoint required by that binding and make it return the documented protocol response. Keep authentication requirements in the service contract; the public business profile itself must remain readable without credentials.

#### Is the UCP business profile publicly discoverable?

- Status: Needs fix
- Result: No usable UCP setup file was found at /.well-known/ucp.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Serve a schema-valid UCP business profile as public JSON at /.well-known/ucp over HTTPS without authentication. Generate it from typed configuration and validate it in CI with the official UCP schema tool.

#### Does the profile declare payment handlers?

- Status: Needs fix
- Result: The UCP setup file does not list valid payment handlers.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Add a payment_handlers registry to /.well-known/ucp and give every handler a valid reverse-domain identifier, released version, and optional configuration that matches the checkout implementation. Validate the registry against the UCP schema in CI.

#### Are signing keys published for message verification?

- Status: Not detected
- Result: No signed-message or webhook capability is claimed, so signing keys are not required.

#### Does the profile follow the UCP business-profile registries?

- Status: Needs fix
- Result: The UCP setup file uses the wrong structure for version, services, or payment handlers.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Set ucp.version to a released YYYY-MM-DD value and make every declared service, capability, and payment handler conform to its version, namespace authority, transport, spec, schema, and endpoint requirements. Remove orphaned or unsupported declarations.

### ACP checkout

- Company signal: Not detected

#### Are required checkout operations documented?

- Status: Needs fix
- Result: The ACP docs are missing required checkout actions: create, update, complete, cancel, and get.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Document create, get, update, complete, and cancel checkout-session operations in the public ACP contract with request and response schemas plus structured error models. Ensure each documented operation is backed by a reachable implementation.

#### Is ACP publicly discoverable through official discovery or a concrete conventional endpoint?

- Status: Needs fix
- Result: No valid ACP discovery file was found at /.well-known/acp.json.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Serve a schema-valid, unauthenticated /.well-known/acp.json at the seller origin with protocol.name, protocol.version, api_base_url, transports, and capabilities.services. If discovery is intentionally unavailable, expose a conventional ACP endpoint that accepts POST and returns structured ACP errors for malformed unauthenticated requests rather than HTML or a generic 404.

#### Is payment handling described without implying settlement?

- Status: Needs fix
- Result: The ACP docs do not clearly describe the payment provider, payment methods, or delegated payment flow.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Describe payment_provider, supported payment methods, PSP token handling, and delegated-payment behavior in the ACP contract. Bind delegated credentials to merchant, checkout id, amount, currency, expiry, payer, and one-time use, and expose the delegate-payment endpoint only when implemented.

#### Are open ACP support and platform-specific ChatGPT support separated?

- Status: Needs fix
- Result: Platform-claim separation was not scored because no valid ACP discovery document was found.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Label open ACP protocol support separately from ChatGPT or Instant Checkout participation. Publish platform approval or certification evidence only when it exists, and remove wording that implies platform endorsement from proposal metadata alone.

#### Can agents understand products before checkout?

- Status: Not detected
- Result: No ACP product-feed or product-catalog service is advertised; checkout-only ACP does not require a feed.

#### Does the contract require authenticated, signed, idempotent requests?

- Status: Needs fix
- Result: The ACP API is missing required request safety headers.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Document and enforce Authorization, Signature, Timestamp, API-Version, Request-Id, and Idempotency-Key on the ACP operations where each control applies. Specify signature canonicalization and replay windows, and test that repeated state-changing requests return the original result without duplicate payment or fulfillment.

### AP2 authorization

- Company signal: Not detected

#### Is the audit trail model documented?

- Status: Needs fix
- Result: The AP2 docs do not explain how receipts, refunds, support outcomes, and dispute records are kept.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Define how signed mandates, payment references, receipts, refunds, support outcomes, and dispute evidence are retained and correlated. Add retention, lookup, and redacted-export tests so an auditor can reconstruct the authorized purchase without exposing payment credentials.

#### Are autonomous-payment limits represented in the contract?

- Status: Needs fix
- Result: The AP2 permission limits are incomplete.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Represent merchant, item or SKU, maximum amount, currency, payment method, expiry, recurrence, and required confirmation limits in the mandate contract. Add negative tests proving that changed carts, merchants, totals, currencies, or expired mandates require rejection or reauthorization.

#### Is AP2 support discoverable through a real commerce or agent transport binding?

- Status: Needs fix
- Result: No AP2 connection was found in a UCP file or A2A agent card.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Add the exact AP2 extension URI https://github.com/google-agentic-commerce/ap2/v1 to the implemented A2A Agent Card, or publish dev.ucp.shopping.ap2_mandate in the UCP profile. Identify the AP2 role, endpoint, authentication, and mandate input/output schemas for that binding.

#### Are mandate types and schemas documented?

- Status: Needs fix
- Result: The AP2 checkout and payment permission form schemas are missing.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Publish the AP2 v0.2 Checkout Mandate and Payment Mandate schemas using the registered mandate.checkout.1, mandate.checkout.open.1, mandate.payment.1, and mandate.payment.open.1 VCT values that the implementation accepts. Validate representative valid and invalid artifacts against the pinned schemas.

#### Does AP2 evidence link to an underlying payment rail without claiming that rail passed?

- Status: Needs fix
- Result: The AP2 records do not show how the permission links to the payment or order.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Name the underlying payment rail and publish the exact authorization, capture or settlement, order, and mandate identifiers used to correlate the AP2 mandate chain with the resulting payment. Verify the linkage during payment processing and reconciliation.

#### Can the agent identify who signs and verifies each mandate?

- Status: Needs fix
- Result: The AP2 signature and verification-key details are incomplete.
- Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence.
- How to fix: Document and implement deterministic verification for every mandate signature, including signer role, algorithm, issuer, audience, key discovery, credential chain, trust anchor, timestamp, and expiry. Fail closed before payment when any signature or trust check is missing or invalid.

### Agent access

#### AI content-use preferences

- Status: Passed
- Result: Content Signals found in robots.txt

#### AI crawler access

- Status: Passed
- Result: No AI-specific bot rules; wildcard rules apply to all crawlers including AI bots

#### Authenticated bot identity

- Status: Not detected
- Result: Web Bot Auth directory not found (informational only)

#### Markdown availability

- Status: Needs fix
- Result: Site returned status 500 for markdown request
- Why it matters: Agents may fail to discover, read or authenticate against the public website.
- How to fix: Add content negotiation so important public pages return equivalent Markdown when requested with Accept: text/markdown while HTML remains the browser default. Return Content-Type: text/markdown, include Vary: Accept, and test that headings, links, and code examples remain usable.

#### Agent discovery DNS

- Status: Needs fix
- Result: DNS records that help agents find agent files were not found.
- Why it matters: Agents may fail to discover, read or authenticate against the public website.
- How to fix: Publish DNS-AID ServiceMode SVCB or HTTPS records such as _index._agents and _a2a._agents with the required alpn and endpoint parameters. Sign the discovery zone with DNSSEC and verify that validating resolvers return authenticated records.

#### Agent discovery links

- Status: Passed
- Result: Found agent-useful Link relations: describedby

#### robots.txt

- Status: Passed
- Result: robots.txt exists with valid format

#### Sitemap

- Status: Passed
- Result: sitemap.xml exists with valid structure

#### A2A agent card

- Status: Not detected
- Result: This check was excluded from scoring for this scan.

#### Agent Skills index

- Status: Needs fix
- Result: Agent Skills index not found
- Why it matters: Agents may not find the correct machine interface or operation.
- How to fix: Serve /.well-known/agent-skills/index.json with a $schema value and a skills array containing name, type, description, URL, and SHA-256 digest for each published skill. Verify every skill URL resolves and its digest matches the served content.

#### API catalog

- Status: Needs fix
- Result: API Catalog returned status 500
- Why it matters: Agents may not find the correct machine interface or operation.
- How to fix: Serve /.well-known/api-catalog as application/linkset+json with a linkset array. For each API, provide an anchor plus service-desc links to current OpenAPI documents, service-doc links to documentation, and status links to health information.

#### Ard

- Status: Not detected
- Result: This check was excluded from scoring for this scan.

#### Agent authentication guidance

- Status: Needs fix
- Result: auth.md returned HTML instead of Markdown
- Why it matters: Agents may fail to discover, read or authenticate against the public website.
- How to fix: Serve /auth.md with agent registration, authorization, scopes, and failure-recovery instructions, and publish the related OAuth protected-resource metadata. Include only revocable sandbox credential instructions—never embed production secrets—and document registration and revocation URLs where supported.

#### MCP server discovery

- Status: Needs fix
- Result: MCP Server Card not found
- Why it matters: Agents may not find the correct machine interface or operation.
- How to fix: Serve an MCP Server Card at /.well-known/mcp/server-card.json with serverInfo.name and version, the real transport endpoint, capabilities, authentication requirements, and callable tool schemas. Validate that the advertised transport and tools match the running MCP server.

#### OAuth sign-in discovery

- Status: Needs fix
- Result: OAuth sign-in setup metadata was not found.
- Why it matters: Agents may fail to discover, read or authenticate against the public website.
- How to fix: For protected APIs, publish /.well-known/oauth-authorization-server or /.well-known/openid-configuration with a consistent issuer, authorization_endpoint, token_endpoint, jwks_uri, and supported grant types. Add tests that fetch every referenced endpoint and reject issuer mismatches.

#### Protected API metadata

- Status: Needs fix
- Result: OAuth API access metadata was not found.
- Why it matters: Agents may fail to discover, read or authenticate against the public website.
- How to fix: Serve /.well-known/oauth-protected-resource with the API resource identifier, authorization_servers that can issue tokens for it, and scopes_supported. Keep the resource and issuer values consistent with token audience validation in the API.

#### Browser tools (WebMCP)

- Status: Needs fix
- Result: No WebMCP tools detected on page load
- Why it matters: Agents may not find the correct machine interface or operation.
- How to fix: Register browser tools with navigator.modelContext.provideContext(), giving each tool a stable name, description, JSON Schema inputSchema, and execute callback. Expose only actions the page can actually perform and return structured authentication, payment, validation, and cancellation errors.

## Executed Agent Tests

| Agent | Status | Score |
|-------|--------|-------|
| Claude Code | Not run | — |
| Codex | Not run | — |

## Services and Endpoints

- No endpoint inventory attached.

## External Website Benchmarks

- No external website benchmark attached.

External scores provide website context and do not contribute to Lightsage's payment-readiness score.

## Evidence

- No public evidence attached.

Page URL: https://lightsage.com/agent-experience-arena/payments/entire-io