Skip to content

[Feature/Roadmap] Implement ACP checkout support (Agentic Commerce Protocol) #5

Description

@SergeevDmitry

Context & Rationale

The gateway currently supports single-request commerce: invoke one resource,
settle one price and receive one result. ACP
adds a checkout model for agents that assemble and complete a purchase across
multiple requests.

Supporting ACP makes the gateway useful for merchants selling products through
agent-driven checkout, while the existing execution pipeline remains the only
path to final delivery.

Proposed Changes

  • Add an ACP adapter for the core checkout lifecycle: create, read, update,
    complete and cancel a checkout.
  • Persist checkout state behind an ACP-owned store and define expiry and
    terminal-state behavior.
  • Map checkout completion to exactly one execution, delivery and commerce
    receipt, with idempotent handling of retries.
  • Forward delegated payment data to the merchant's existing payment flow
    without storing or charging it in the gateway.
  • Declare the ACP capabilities the deployment actually supports and report the
    same scope through configuration, diagnostics and documentation.
  • Add protocol-level tests for successful checkout, cancellation, retries,
    invalid state transitions and unsupported capabilities.

Non-goals / Invariants Preserved

  • Product feeds, catalog synchronization, discounts, refunds, returns and
    post-delivery order changes are deferred.
  • The merchant remains the merchant of record; the gateway does not custody
    funds or payment credentials.
  • ACP-specific state and types do not become part of the canonical commerce
    model.
  • Checkout completion must not bypass the shared execution pipeline or produce
    duplicate delivery on retry.

Impact & Value

  • Extends the project from paid API-style calls to agent-driven retail checkout.
  • Gives merchants a standards-based integration while preserving their current
    backend and payment-provider relationships.
  • Establishes the state and idempotency pattern needed for future session-based
    commerce protocols.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions