Beta · integration with A-Comm engineering. These docs help merchant engineering teams evaluate A-Comm. Access, configuration, testing, and launch are coordinated with our team.
Help shoppers buy
A voice and text agent on your storefront helps shoppers find products, build a cart, and proceed through your checkout.
Understand the journey
Capture stated needs, product choices, and shopping friction to help your teams investigate the customer experience.
Review what happened
Retrieve and verify transaction evidence, export records, and assemble supporting evidence for disputes.
How the systems connect#
A-Comm embeds the agent in your storefront and connects it to your commerce systems through your MCP connector or an API. Your team retains its existing catalog, cart, checkout, and payment-processing setup. We configure and validate the connection together.
Your storefront → A-Comm agent → your commerce systems
Merchant
Your storefront
Shoppers interact with the embedded agent by voice or text.
↔Voice
text
A-Comm
Voice and Text Shopping agent
Uses connected commerce tools, requests shopper confirmation, and captures signals and transaction evidence.
↔MCP or API
Merchant
Commerce systems
Your catalog, cart, checkout, and fulfillment systems. Payments use your existing processing setup.
Information captured during the supported workflow
Merchant signals
Observations about customer needs, choices, and friction. The fields your team receives and their delivery method are agreed during integration.
Transaction evidence → Vault
Journey evidence captured from session creation, with an evidence ID for retrieval even without a purchase. Payment authorization seals the transaction chain; later fulfillment and dispute records remain linked.
Signals and transaction evidence serve different purposes. Neither means that every conversation becomes a completed, sealed transaction.
What is available in beta#
| Capability | Current scope |
|---|
| Storefront agent | Voice and text shopping connected to merchant commerce systems through MCP or an API, with A-Comm engineering. |
| Shopping and checkout | Product discovery, cart, checkout, and payment authorization within the workflow configured for the merchant. |
| Merchant signals | Capture of shopping observations; merchant access and delivery are scoped for the pilot. |
| Journey and transaction evidence | Capture from session creation, retained under an evidence ID even without conversion. Authorization seals the transaction chain, with verification, export, and linked fulfillment and dispute records. |
| Dispute support | Dispute receipt and evidence assembly. Submission through A-Comm is not available currently. |
| Access and launch | Coordinated by A-Comm. We agree the test environment and validate the workflow before any shopper launch. |
During onboarding, we confirm which actions, payment flows, and evidence outputs are included in your pilot. A completed test does not by itself enable live transactions.
Who these docs are for#
Merchant engineering teams evaluating an agent on their own storefront. Use these pages to understand the system boundaries, the work each team owns, and the information available from the integration.
Your next step is a conversation with A-Comm engineering. Bring your storefront, catalog and checkout interfaces, the journey you want to support, and the teams that will evaluate the results.
Connect your commerce systems#
We work with your existing MCP connector or API to connect the agent to the catalog and commerce actions it needs. The integration is configured for your merchant environment; A-Comm coordinates access and setup with your engineers.
MCP is a standard way to expose tools to an AI application. An API can also provide the commerce operations needed for the integration. Your team supplies the available interfaces, their documentation, and a test environment; A-Comm works with you on the connection and tool mapping.
We scope the integration around your merchant workflows. During onboarding, we agree which information the agent can access, which actions it can perform, and which requests remain with your team or existing systems.
| Commerce area | Merchant interfaces and information | Scope to confirm with A-Comm |
|---|
| 1. Customer context and permissions | Guest or signed-in identity, available customer context, and permissions to access information or act. | How the shopper is identified, what context the agent may use, and which actions require confirmation. |
| 2. Discovery, product information, and offers | Product search, variants, availability, pricing, promotions, and approved product or policy information. | Which sources the agent uses, how offer eligibility is checked, and how unavailable or uncertain information is handled. |
| 3. Cart and delivery configuration | Cart contents, quantities, recipients, addresses, delivery options, and the merchant-calculated total. | Whether the agent shares the storefront cart, which changes are permitted, and how the shopper confirms the basket and delivery details. |
| 4. Checkout and payment authorization | The merchant’s existing checkout, payment handoff, and authorization results. | How shopper approval and payment results are associated with the transaction, and how pending, declined, or interrupted flows are handled. |
| 5. Order confirmation and status | Merchant order creation, order identifiers, confirmation details, and order-status information. | How successful order creation is confirmed and how the session, cart, payment, merchant order, and evidence record are linked. |
| 6. Fulfillment and delivery updates | Order, shipment, pickup, or digital-delivery updates from the merchant’s connected systems. | Which sources supply updates, whether the agent reads status or performs any permitted action, and how updates reach the correct evidence record. |
| 7. Customer service and human handoff | Approved support policies, customer-authorized order information, and support contact or case-management interfaces. | Which questions the agent can answer, which lookups or service actions are available, and how unresolved requests reach a human with the relevant context. |
| 8. Changes, cancellations, returns, and refunds | Merchant eligibility rules and interfaces for order changes, cancellation, returns, exchanges, replacements, refunds, or credits. | Which requests the agent can explain or initiate, which actions are permitted, and which approvals and operations remain with the merchant’s team or systems. |
| 9. Dispute evidence preparation | Dispute details, merchant order and payment references, and available transaction evidence. | The receipt route, evidence matching, assembly, and review responsibilities. Submission through A-Comm is not available currently; the merchant uses its existing submission process. |
Use your existing checkout and payments, or use one of our industry partners.#
The agent works through the merchant’s connected checkout and payment-authorization flow. The merchant retains its existing payment-processing setup; A-Comm connects and validates that workflow with your engineers.
Payment details belong in the checkout’s payment interface, not in a conversation with the agent. Shopper confirmation, processor authorization, and evidence sealing are separate events: the integration must associate the payment result with the correct transaction record.
Before a pilot runs, we agree the payment flows to include, how authorization reaches the evidence record, and which operations are simulated or use live systems. The same check applies to card and wallet flows included in the pilot.
Customer context, with the shopper’s permission#
In pilots that include connected customer context, shoppers can authorize access to supported sources to help the agent understand their needs. For a gifting journey, this can include relevant recipients, occasions, preferences, and budget cues.
Context requests are associated with the shopper’s session. The agent uses the permitted information to personalize the experience, while the merchant-facing context-signal export excludes names, email addresses, and raw source content.
Information required to complete an approved purchase—such as a recipient’s name or delivery email—is handled separately through the merchant’s commerce workflow.
Context-derived signals can indicate where shopping intent originated. They support review of the journey; they do not by themselves establish that a purchase is legitimate.
During onboarding, we agree the supported sources, consent experience, permitted uses, and information available to the merchant.
What each team owns#
Your engineering team
- Provide catalog, cart, checkout, and fulfillment interfaces and a test environment.
- Define permitted actions, shopper confirmations, and storefront placement.
- Maintain the merchant’s commerce systems and payment-processing relationship.
- Name the teams that will review signals and evidence.
A-Comm engineering
- Coordinate access, credentials, and integration configuration.
- Connect and configure the agent for the agreed workflow.
- Configure evidence capture and agree signal access and delivery.
- Work with your team to test behavior, review outputs, and prepare the pilot.
Before launch, both teams agree how to handle failures, credential renewal, support, and rollback. The pilot checklist records those decisions.
Merchant signals#
A conversation adds customer-stated context to the shopping journey. The agent captures observations that can help merchant teams investigate what shoppers wanted, what they chose, and where the experience became difficult.
| Observation | Question for your team | Potential use |
|---|
| Stated needs, budget, occasion, or timing | What is the shopper trying to accomplish? | Merchandising and relevant messaging |
| Searches, choices, and alternatives | Where does demand meet—or miss—the available catalog? | Product discovery and assortment review |
| Repeated errors or unsuccessful steps | Where is the shopping workflow breaking down? | Customer experience and product improvements |
| Permissions and agent actions | What did the shopper authorize, and what did the agent do? | Operations and risk review |
These are observations for your team to interpret, not measured improvements in conversion or automated fraud decisions. Agent-side capture, merchant-accessible signals, and evidence stored in the Vault are distinct. We agree the available fields, access, and delivery method for your pilot.
From shopping activity to a sealed record#
Capture begins when a session is created on your integrated storefront. Signals and evidence from discovery, customer intent, and cart activity are associated with an evidence ID, whether or not the shopper completes a purchase. Captured pre-authorization evidence is retained under that ID.
When the required payment-authorization evidence is captured, the transaction chain seals. Later fulfillment updates and dispute or chargeback records are linked to the same journey without rewriting the sealed history.
Illustrative sequence
- 1 · CaptureSession and discovery
Create the evidence record at session start. Capture journey signals, intent, and permissions under its evidence ID.
- 2 · BuildCart and actions
Link recorded activity to the confirmed basket and transaction.
- 3 · SealAuthorization
Seal when the required authorization evidence has been captured.
- 4 · UpdateFulfillment and disputes
Link later fulfillment updates and dispute records to the journey without rewriting the sealed history.
Journeys without a completed purchaseA shopper can discover products and build a cart without authorizing a payment. The captured signals and evidence are still stored under an evidence ID and remain available for review. The record remains unsealed because no payment was authorized. Non-conversion does not mean that the journey was not captured.
Capture reliabilityCapture is best-effort: a Vault outage does not block checkout, so evidence may be missing or incomplete. This is separate from a shopper choosing not to purchase. During pilot validation, we confirm retention and retrieval, and how to detect and review capture gaps.
Retrieve, verify, and export#
A-Comm supports retrieval, verification, and export of captured transaction evidence. Verification checks the integrity of the recorded chain. It does not establish that every event was captured, that every assertion is true, or that a dispute will be resolved in the merchant’s favor.
Your team can retrieve a journey’s captured records using its evidence ID, including journeys that never produce an order. An evidence ID identifies the record; it does not, by itself, mean the record is sealed. During integration, we establish the access route and how the evidence ID relates to the session, cart, and any subsequent order or payment references.
The pilot walkthrough includes a journey without a completed purchase and an authorized purchase. Together, we review the captured signals, retrieve the available evidence records, verify and export the transaction evidence, and check how later fulfillment or dispute records are linked.
We also agree which order or delivery system supplies fulfillment updates and how those updates reach the record. An embedded agent alone does not connect every downstream system.
What the evidence records#
An artifact is a typed record within the evidence chain. The following describes the core transaction sequence; which records are present depends on how far the workflow progressed and what was captured.
| Artifact | Purpose |
|---|
intent | The purchase the shopper set out to make. |
delegation | The authority or session context under which the agent acted. |
policy | The applicable permissions or allowance and recorded policy result. |
cart | The confirmed basket and transaction amount. |
authorization | The payment-authorization evidence required to seal the chain. |
fulfillment | Subsequent order or delivery updates from the connected source. |
These are conceptual descriptions, not request schemas. A-Comm provides the applicable API contract and examples during onboarding.
Current beta boundaryA-Comm supports dispute receipt and evidence assembly. A-Comm does not submit disputes or dispute responses to processors or networks.
How evidence preparation works#
- Receive the dispute. During integration, we configure how dispute information enters the agreed workflow and which references connect it to the merchant’s order.
- Find the associated evidence. Link the dispute to the available transaction record and identify missing information.
- Assemble material for review. Prepare supporting evidence from the captured records. Your team reviews it for completeness and relevance.
- Use your existing submission process. Your team handles submission and deadlines through its processor or dispute-management workflow.
The receipt path is part of the integration scope. Embedding the storefront agent does not automatically connect every processor’s dispute feed.
What a reviewer should check#
- The evidence belongs to the disputed merchant order.
- The relevant actions and authorization are present in the captured record.
- The export can be verified and any missing evidence is understood.
- Additional material required by your submission process is supplied from the appropriate merchant systems.
The agent’s evidence is one input to a dispute response. A-Comm does not guarantee network acceptance or dispute outcomes. Its current capture does not include device or IP evidence; any such supporting material must come from another source.
Use this checklist with A-Comm engineering to define and validate your pilot. It is a shared readiness review; completing it does not automatically enable production access.
Agree the scope#
| Check | Decision or result to record |
|---|
| Workflow and environment | Included journeys, test versus live operations, permitted actions, and excluded flows. |
| Merchant connections | Catalog, cart, checkout, payment-authorization, and fulfillment sources connected for this pilot. |
| Agent experience | Store identity, storefront placement, supported interactions, and required shopper confirmations. |
| Information handling | What is captured, what the merchant receives, who has access, and the retention and deletion arrangements. |
| Credentials and maintenance | Who manages server credentials and embed configuration; expiry, renewal, and replacement procedures. |
Validate the complete journey#
| Check | Expected review |
|---|
| Purchase flow | Run the agreed journey from discovery through cart, shopper confirmation, and payment authorization. |
| Evidence access | Retrieve discovery-only, abandoned-cart, and authorized-purchase journeys by evidence ID. Check the links to session, cart, and order references; verify and export the transaction evidence. |
| Fulfillment updates | Confirm an update from the agreed source reaches the correct transaction record. |
| Signals | Confirm which fields the merchant can actually access and how they are delivered. |
| Incomplete and failed flows | Review abandonment, failed authorization, unavailable catalog, and missing evidence behavior. |
| Dispute preparation | Review receipt and evidence assembly if included. Confirm who owns submission through the existing merchant process. |
Agree operation and launch#
- Assign support contacts and a process for reporting agent or evidence failures.
- Agree how to disable the agent or roll back the integration.
- Record credential renewal and integration-change responsibilities.
- Confirm the rollout scope and launch decision with both engineering teams.
For help, contact devs@a-comm.ai with the time, environment, and relevant order or transaction reference. Do not send API secrets or payment details.
Access and API documentation#
All beta access is coordinated with A-Comm engineering. During onboarding, we provide the applicable service addresses, authentication requirements, request and response examples, and error-handling guidance for your integration.
We also establish the route for obtaining transaction identifiers, reviewing records, and renewing credentials. Keep server credentials out of storefront code; use the storefront configuration supplied for your integration.
This public documentation explains the offering and integration boundaries. Account-specific configuration and the implementation walkthrough are completed with our team.
AEP and the Vault#
The A-Comm Evidence Protocol (AEP) defines the structure and verification of transaction evidence. The Vault is A-Comm’s service for storing and retrieving those records.
AEP · the protocol
Defines evidence artifacts, their sequence, and how record integrity can be verified.
Vault · the service
Stores the captured evidence and supports retrieval, verification, and export for the integration.
For protocol details, read the AEP specification or its source repository. Reading or implementing the protocol does not provision access to A-Comm’s hosted services.
Glossary#
- Merchant signals
- Observations captured during shopping that help merchant teams investigate customer needs, choices, and friction.
- Artifact
- A typed evidence record, such as intent, cart, or authorization.
- Chain
- A sequence of linked evidence records associated with a transaction. A pre-authorization chain can remain unsealed.
- Evidence ID
- An identifier for the journey’s evidence record, created when the storefront session starts. The record remains available even if no purchase occurs; the ID does not, by itself, mean the record is sealed.
- Seal
- The integrity boundary established when the required authorization evidence is captured. Later fulfillment updates and linked dispute records do not rewrite the earlier sealed records.
- Verification
- Checking recorded evidence against its integrity checks. Completeness and the truth of the underlying assertions require separate review.
- MCP
- Model Context Protocol: a standard interface through which an AI application can use tools exposed by another system.
- API
- An interface through which software requests data or actions from another system.
- Payment authorization
- The processor’s approval for a payment. It is distinct from the shopper’s permission and does not, by itself, describe settlement or delivery.
Documentation updates#
16 September 2026. Beta merchant evaluation documentation: assisted integration, merchant signals, transaction evidence, dispute preparation, and joint pilot validation.