Check specification

acp 1.0.0

ACP - Agentic Commerce Protocol

Validates ACP discovery metadata, protocol shape, endpoint safety, capabilities, cache guidance, and public metadata safety.

Assessment Suite
2026.06.10
Maturity
Informational
Category
Agent Ease of Use
Subcategory
Commerce Protocols

1. Abstract

Expose valid ACP discovery when this origin supports Agentic Commerce Protocol workflows.

ACP discovery lets agents find the seller's ACP API base URL, supported versions, transports, and stable services before attempting authenticated checkout-session negotiation.

2. Classification

Check ID
acp
Check version
1.0.0
Package path
lib/checks/acp/versions/1.0.0
Category
Agent Ease of Use
Subcategory
Agent Commerce
Check group
Commerce Protocols
Check group ID
commerce-protocols
Maturity
Informational
Scope
site
Check weight
1

3. Input And Output Contracts

Resources inspected
/.well-known/acp.json, /.well-known/acp, API-Version, Idempotency-Key, POST /checkout_sessions

4. Scoring Semantics

Step IDTitleWeightDescription
applicabilityDecide whether ACP applies0.1Detect ACP, agentic-checkout, or /.well-known/acp.json discovery signals.
discovery-fetchFetch ACP discovery0.15Fetch /.well-known/acp.json as the canonical ACP discovery proposal path, with /.well-known/acp as compatibility evidence.
document-shapeValidate ACP discovery shape0.2Validate protocol metadata, ACP name, date version, and supported_versions ordering.
endpoint-transportValidate ACP endpoint and transports0.15Validate api_base_url, HTTPS safety, transport declarations, and required REST support.
capabilitiesValidate ACP capabilities0.2Validate stable services, extensions, intervention types, currencies, and locales.
cache-and-errorsReview ACP cache and retry metadata0.05Inspect Cache-Control and Retry-After guidance for public discovery responses.
security-reviewReview ACP public metadata safety0.15Flag secrets, merchant-specific payment details, private endpoints, and unsafe public discovery metadata.

5. Package Documentation

ACP - Agentic Commerce Protocol Check v1.0.0

Status

Abstract

This check validates public Agentic Commerce Protocol discovery for origins that claim ACP or agentic-checkout support. It focuses on the proposed /.well-known/acp.json discovery document: protocol metadata, API base URL, transports, stable capabilities, cache guidance, and public metadata safety.

The check is a static discovery check. It does not create checkout sessions, send bearer credentials, complete payments, or prove live authorization or settlement.

Motivation

ACP discovery gives agents a safe preflight way to determine whether a seller supports ACP before authenticated checkout-session negotiation. A valid discovery document lets agents find the ACP API base URL, supported ACP versions, supported transports, and stable seller-level services without scraping human checkout flows or guessing API paths.

Public discovery should expose stable platform-level information only. Session-specific payment methods, payment handlers, payment service provider routing, merchant IDs, buyer data, credentials, and tokens belong in authenticated runtime flows, not in /.well-known/acp.json.

Normative Model

ACP is a beta, date-versioned commerce protocol for interactions between buyers, AI agents or AI platforms, businesses or seller platforms, and payment providers. The repository snapshot used for this check is date-versioned; the latest stable public snapshot found during research was 2026-04-17.

The ACP discovery RFC proposes:

  • GET /.well-known/acp.json
  • public unauthenticated access
  • JSON response body
  • cache guidance, with public, max-age=3600 recommended
  • a response object containing protocol, api_base_url, transports, and capabilities

The protocol object should identify ACP with name: "acp", use a date-based version, and list date-based supported_versions in chronological order ending with the current version.

The api_base_url should be a safe HTTPS URL. The transports array should include rest. Known transport values for this check version are rest and mcp.

The capabilities.services array identifies stable seller-level services. Known service values for this check version are checkout, orders, and delegate_payment.

Applicability

The check applies when any of these signals are present:

  • /.well-known/acp.json exists
  • /.well-known/acp exists as compatibility evidence
  • homepage, headers, docs, or public metadata mention Agentic Commerce Protocol, ACP, agenticcommerce.dev, /.well-known/acp.json, checkout_sessions, delegate_payment, API-Version, agentic checkout, or ChatGPT commerce integration

The check is not applicable when no ACP or agentic-checkout signal is visible. Generic payment acceptance, ordinary ecommerce checkout, x402, MPP, UCP, AP2, or unrelated payment metadata is not enough by itself to make ACP applicable.

Pass Criteria

The check passes static ACP discovery validation when:

  • /.well-known/acp.json returns HTTP 2xx
  • the response is JSON-compatible and parses as JSON
  • the document includes protocol, api_base_url, transports, and capabilities
  • protocol.name is exactly acp
  • protocol.version is a YYYY-MM-DD date string
  • protocol.supported_versions is a non-empty chronological array of date strings ending with protocol.version
  • api_base_url is a safe HTTPS URL without credentials, localhost, or private-network hosts
  • transports is a non-empty array and includes rest
  • capabilities.services is a non-empty array
  • optional extension spec and schema URLs are safe HTTPS URLs when present
  • optional currencies and locales are plausibly shaped
  • public discovery does not expose sensitive or session-specific payment metadata

Warning Criteria

Warnings include:

  • ACP-like or agentic-checkout signals exist, but active ACP support is not clearly claimed and /.well-known/acp.json is missing
  • discovery exists only at /.well-known/acp
  • discovery is present but lacks cache guidance or max-age
  • unknown transport, service, intervention, extension, currency, or locale values appear but the document is otherwise well-formed
  • optional extension declarations are malformed or omit useful name, spec, or schema metadata
  • a temporary discovery response uses 429 or 503 in a way that can be retried

Failure Criteria

Failures include:

  • active ACP support is explicitly claimed, but /.well-known/acp.json is missing, unreachable, non-JSON, or malformed
  • discovery omits protocol, api_base_url, transports, or capabilities
  • protocol.name is not acp
  • protocol.version is missing or not date-based
  • protocol.supported_versions is missing, empty, not date-based, not chronological, or does not end with protocol.version
  • api_base_url is missing, non-HTTPS, credential-bearing, localhost, private-network, or otherwise unsafe
  • transports is missing, empty, or lacks rest
  • capabilities.services is missing or empty
  • public discovery exposes merchant IDs, buyer or customer information, payment methods, payment handlers, PSP routing, payment credentials, bearer tokens, API keys, private keys, raw card-like data, or raw payment tokens
  • 429 or 503 discovery responses omit Retry-After

Evidence Model

The check emits step-level evidence for:

  • applicability signals and explicit active ACP claims
  • canonical and compatibility paths checked, status codes, content types, cache headers, and retry headers
  • JSON parse result
  • protocol.name
  • protocol.version
  • supported version count, ordering status, and current-version match
  • api_base_url safety summary
  • transport list and unknown transport values
  • service list and unknown service values
  • extension count and URL validation summary
  • intervention type, currency, and locale summaries
  • security flags for secrets, merchant IDs, private endpoints, raw payment data, or unsafe public metadata

Evidence must not include full discovery bodies, bearer tokens, API keys, payment tokens, raw card data, buyer information, merchant IDs, private keys, or complete sensitive URL query strings.

Validation/Scoring Steps

  • applicability (0.10): detect ACP and agentic-checkout signals.
  • discovery-fetch (0.15): fetch /.well-known/acp.json, with /.well-known/acp as compatibility evidence only.
  • document-shape (0.20): validate JSON, required top-level fields, ACP protocol name, date version, and supported version ordering.
  • endpoint-transport (0.15): validate api_base_url, HTTPS safety, transport declarations, and required REST support.
  • capabilities (0.20): validate services, extensions, interventions, currencies, and locales.
  • cache-and-errors (0.05): validate cache guidance and Retry-After behavior.
  • security-review (0.15): flag secrets, merchant-specific payment details, raw payment data, private URLs, and unsafe public metadata.

Standard Behavior

If no ACP or agentic-checkout signal is visible, the result is not_applicable.

If ACP-like or agentic-checkout signals are visible but active ACP support is not clearly claimed and /.well-known/acp.json is missing, the result is warning.

If active ACP support is explicitly claimed and /.well-known/acp.json is missing, unreachable, non-JSON, or malformed, the result is fail.

If canonical discovery exists and has a valid ACP discovery shape, the result passes static discovery validation.

If discovery exists only at /.well-known/acp, the result warns unless a future ACP version documents that path.

If discovery contains unsafe sensitive data or merchant-enumeration data, the result fails.

Non-Standard And Real-World Behavior

The ACP discovery document is currently described by an ACP RFC proposal. The IANA Well-Known URI registry did not list acp during the research pass for this version, so the check describes /.well-known/acp.json as the ACP discovery proposal path rather than an IANA-registered well-known URI.

OpenAI and Stripe are reference ecosystem participants. Public platform onboarding requirements can differ from bare protocol conformance; a valid ACP discovery document does not guarantee listing in ChatGPT or any other AI platform.

Some sellers may expose only checkout, while seller platforms may expose checkout, orders, and delegated payment as stable services. Concrete payment method and payment handler availability is intentionally session-specific and should not be required in public discovery.

Non-Goals And Limitations

This check does not:

  • execute checkout
  • create, update, complete, or cancel checkout sessions
  • send bearer tokens
  • generate or submit payment credentials
  • prove live payment acceptance, authorization, settlement, or fulfillment
  • validate merchant-specific payment methods or payment handlers from public discovery
  • treat ordinary human checkout as ACP support
  • treat UCP, x402, MPP, AP2, or generic payment metadata as ACP support
  • validate every OpenAPI or JSON Schema detail
  • fetch every extension schema
  • attempt seller-platform merchant enumeration

References

Source: lib/checks/acp/versions/1.0.0/docs.md

6. Version Changelog

acp v1.0.0 Changelog

  • Validates ACP discovery at /.well-known/acp.json with /.well-known/acp as compatibility evidence.
  • Checks ACP protocol metadata, date-based versions, API base URL safety, transports, services, cache guidance, and public metadata safety.
  • Distinguishes static ACP discovery from authenticated checkout-session and payment execution.

Source: lib/checks/acp/versions/1.0.0/changelog.md