Agenticom is a Ballerine-powered community for updates, resources, and discussion across the agentic commerce space.
Over the last quarter, members have raised practical questions on how consent, merchant representation, evidence, and ongoing oversight should work as AI agents take a more active role in commerce.
Many of those questions center on what happens when an AI agent chooses a merchant, summarizes a policy, acts within a delegated budget, or completes a purchase that the user later disputes.
They touch familiar areas of payment risk, but the buying journey now includes a system that may interpret or act on the shopper’s behalf.
A standard authorization record can confirm that a payment was approved without capturing the user’s full instruction, the information the agent relied on, or the promise the buyer understood.
Agentic commerce generally describes buying journeys in which an AI agent helps a user search, compare, decide, purchase, or complete related tasks.
The agent may only assist with discovery, or it may act within authority the user has granted. For risk teams, this means that steps once performed directly by the shopper can be interpreted or executed by another system.
The payments ecosystem is already building infrastructure for the authorization and trust layer. Mastercard’s Agent Pay Acceptance Framework describes agent registration, trusted-agent recognition, purchase-intent data, and traceable agentic transactions.
Google’s Agent Payments Protocol (AP2) uses cryptographically signed mandates to preserve evidence of the user’s instructions and the cart that was approved.
Both initiatives address important transaction-level questions, while merchant legitimacy, policy accuracy, fulfillment, and post-approval changes still require separate risk controls.
The questions raised by community members tend to involve five parts of the transaction. They are closely related, and a single complaint may involve several of them at once.
A useful investigation would compare the information the merchant published, the version the agent accessed, the representation shown to the user, the authority the user granted, the final checkout terms, and the fulfillment outcome.
That sequence gives the reviewer a better chance of identifying whether one party made the error or whether several gaps combined.
A cardholder may challenge an agent-driven purchase even when the payment credentials were valid and the authorization succeeded.
The source of the complaint could be a product that fell outside the user’s instructions, a price or merchant the user did not expect, or a policy that was represented differently from the one the merchant applied.
Hypothetical example: A shopper asks an agent to buy a returnable product below a set price. The merchant’s agent-facing data still shows a 30-day return period, although the item was recently changed to final sale.
The correct product arrives and the payment is authorized, but the merchant refuses the return.
The resulting dispute would turn on the shopper’s instruction, the data available to the agent, the policy that was presented, and the merchant’s actual terms.
These transactions remain within existing card-brand monitoring environments. Visa’s public overview of the Visa Acquirer Monitoring Program states that VAMP consolidates fraud and dispute programs, includes enumeration criteria, and uses a lifecycle risk-management approach.
The overview does not describe a separate agentic-commerce category. The practical issue for PSPs and acquirers is whether agent-driven activity contributes to the fraud and dispute patterns they already manage, and whether the supporting records are strong enough to explain the transaction.
For this article, agentic commerce readiness means that a merchant and its payment provider can support agent-assisted discovery and purchasing with defined controls.
Technical connectivity alone does not answer whether the merchant is eligible, its data is current, its terms can be represented accurately, or its operations can meet the promise presented to the buyer.
Before enabling a merchant, the review can be incorporated into merchant underwriting and organized around six practical areas:
AI agents use merchant and product information to form recommendations and complete tasks. Outdated prices, missing restrictions, or ambiguous terms can therefore affect the result presented to the shopper.
In this article, “policy drift” refers to a gap between the policy the merchant or PSP approved and the policy or claim the agent later presents.
The gap may come from an interpretation error, a delayed update, or a merchant change that was never reflected in the agent-facing data.
Examples might include quoting an old return window, recommending an item that is no longer available, presenting a conditional discount as guaranteed, or continuing to surface a merchant after its catalog expands into a restricted category.
None of those examples is offered as a measured industry trend. They illustrate the types of changes an ongoing control program should be able to identify.
For that reason, merchant monitoring may need to cover more than the registered website and transaction stream.
Relevant surfaces can include agent-facing feeds, policies, claims, related domains, complaint patterns, and changes to the merchant’s actual business model.
When a complaint involves an agent, the reviewer needs enough information to reconstruct the commercial journey rather than relying on the payment record alone.
The exact evidence will depend on the protocol and the parties involved, but a practical case file would usually bring together:
The same evidence can support monitoring. Useful signals may include agent source, consent scope, product-data freshness, policy clarity, repeated agent errors, dispute concentration, promise-to-delivery mismatches, related domains, and post-approval merchant changes.
A stale field on its own may be a routine data-quality problem. Several connected signals, especially when they recur, warrant a closer review.
A potential risk arises when an agent routes users to an undisclosed storefront, related entity, alternate domain, or product that sits outside the merchant profile the PSP approved.
This is a hypothetical control scenario rather than a claim that agentic commerce is already producing transaction-laundering trends at scale.
The user may see a coherent buying journey while the PSP sees only the merchant identity attached to the payment.
Reviewing that scenario would require a trace from the user request and agent recommendation through the storefront, legal entity, checkout, and final transaction.
A registered-URL check may not provide enough context when the commercial path spans several offers or related entities.
A workable program can build on existing merchant-risk controls rather than creating a separate governance layer.
The main additions are to define where agents may act, retain the context they create, and revisit the merchant when that context changes.
Set channel eligibility before launch. Document which merchants, categories, geographies, transaction values, and risk tiers may participate in agent-driven commerce.
Bring the agentic use case into underwriting. Review catalog ownership, update frequency, fulfillment, claims, dispute history, customer support, and related domains before the channel is enabled.
Clarify data ownership and update timing. Assign responsibility for each agent-facing data field and agree how quickly product, price, policy, or restriction changes must be reflected.
Preserve agent and consent context. Capture the agent source and available consent signals, distinguishing between a recommendation, cart preparation, a specifically approved purchase, and broader delegated authority.
Monitor outcomes as well as approvals. Review complaints, disputes, policy gaps, abnormal behavior, merchant changes, and differences between what was represented and what was delivered.
Define what happens when risk changes. Set criteria for re-review, remediation, restriction, suspension, and offboarding, and retain the evidence behind each material decision.
This keeps the program grounded in controls risk teams already use while adding the context needed to review an agent-driven journey.
The operating model can then be updated as protocols, card-brand requirements, and commercial practices mature.
Ballerine’s Trusted Agentic Commerce Enablement Platform is designed around initial readiness and continuous governance.
The platform assesses merchant eligibility and legitimacy, supports agent-specific policy controls, and creates readiness profiles for agent-platform evaluation.
After enablement, it monitors catalog and inventory integrity, policy drift, merchant-legitimacy signals, behavioral anomalies, and changes in the merchant’s risk profile, with alerts, remediation workflows, and audit-ready evidence for PSP teams.
The platform is intended to work alongside agent and payment infrastructure by providing a merchant-risk layer that connects what the agent is permitted to represent with what the merchant is currently able to offer and deliver.
Agentic commerce introduces another decision-maker into a transaction that already involves the buyer, merchant, platform, and payment provider.
For PSPs and acquirers, practical preparation means confirming merchant eligibility, keeping agent-facing data current, defining the user’s authority, retaining the records needed to reconstruct the journey, and reviewing the merchant again when its products or policies change.
As the standards mature, teams that can trace the path from the user’s instruction to the merchant’s final outcome will be better placed to support agent-driven commerce while keeping disputes, fraud exposure, and compliance questions manageable.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
