Meet us at conferences around the world
SBC Summit Lisbon
SiGMA Europe
AI agents are moving from chat windows into commercial workflows — discovering products, building carts, running merchant operations. Anthropic’s commerce blueprint, backed by Mastercard and Visa, is the clearest signal yet. The question payment providers can’t dodge: how much access does an agent get, and who stays in control when it acts?
That question extends beyond consumer checkout. Payment teams also need to decide what an internal agent may investigate, which operations it may perform and how access can be withdrawn. The use cases differ, but both require permissions that the underlying systems can enforce.
On 2 September 2026, Anthropic released a blueprint for businesses building shopping and merchant agents with Claude. Mastercard and Visa are among the partners working with Anthropic to help clients and merchant communities use it.
The shopping agent supports product discovery, customer preferences, cart building and order enquiries. The merchant agent supports sales analysis, inventory monitoring, pricing recommendations and campaign preparation. Payment integration remains with the business, through its existing checkout or an agentic payments provider.
The reference implementation shows how this separation works: its demonstrations hand checkout to the host application, while merchant changes require a person’s approval before they are applied. Businesses remain responsible for their deployment’s authorisation and compliance controls. Claude Commerce Agents reference implementation.
For payment providers, this highlights the need for a defined handover into payment execution. A conversation can establish what a customer wants; connected systems must determine which actions are permitted and how the payment is completed.
Separately, Mastercard has admitted 22 companies to the first Agentic Commerce & Services cohort of its Start Path programme. Participants cover agent connectivity, identity, payment credentials, fraud assessment and merchant enablement. This complements the commerce blueprint announcement: businesses need both usable agents and infrastructure that can support their interactions. The Paypers’ report on the Start Path cohort.
The same shift is emerging beyond card networks: The Paypers reports that India’s UPI system may soon let AI agents make small payments under conditions set in advance. It’s a reminder that delegated-authority questions extend to national payment rails, not just card schemes.
Taken together, these developments suggest that agent adoption depends on connecting commercial intent with enforceable permissions. Identifying the account holder is part of that task. Establishing which agent acted, what it was permitted to do and whether its action stayed within that permission adds another layer.
For payment providers evaluating these models, evidence of authority should be part of integration design. If a purchase is challenged, operations teams need records that connect the instruction, the permission in force, the checks applied and the transaction outcome.
Those records should come from the systems enforcing and executing the workflow. Relying solely on the agent’s explanation of its own actions would leave an avoidable gap in an investigation.
The same principle applies inside a payment platform. An analyst’s agent needs reliable operational context to investigate a decline. An automation agent needs explicit permission for any resulting change. Payneteasy addresses these needs through MCP access to operational data and a separate UI API path for authorised back-office work.
Where a workflow requires action, the Payneteasy UI API provides a separate programmatic route to back-office operations. Its OpenAPI specification documents more than 130 services and more than 1,500 operations, with availability determined by account permissions.
Restricted tokens narrow access to selected methods within the issuing user’s rights. They can be time-limited and revoked, allowing teams to grant an integration or agent the permissions needed for a particular task.
For example, a team can use MCP to investigate payment performance and a separately authorised UI API integration to pull reports or carry out permitted merchant onboarding tasks. These are illustrative workflows: each requires the relevant tools, permissions and integration setup.
The operational benefit is the ability to introduce AI assistance into specific tasks while deciding separately which changes an agent is authorised to make.
Payneteasy MCP helps teams work with payment operations data through compatible AI assistants. Claude, ChatGPT or Codex can serve as the interface where the client supports the required MCP connection and authentication.
Through a configured connection, an assistant can query permitted transaction statistics, inspect individual orders and their processing trails, and read related platform records. Teams can use plain-language questions to connect performance trends with the operational detail behind them, reducing manual navigation between reports and records.
Payment execution stays outside the MCP access boundary by design, so teams can delegate investigation while retaining control over operational changes. Access is scoped and revocable, and the assistant receives no raw PAN or CVV.
Existing clients can review the UI API under Tools → API documentation in their Payneteasy back office. To explore the analysis workflow first, see how Payneteasy MCP connects assistants to payment operations data.
The announcements point to three decisions for any agent integration: what data it may access, what actions it may perform and what evidence the system retains.
For a consumer agent, that may mean enforcing a purchasing mandate before a payment proceeds. For an internal payment agent, it means providing useful investigative access and granting operational permissions separately where needed.
Payment providers can apply this approach to workflows available today. Start with a defined task, give the agent the access required to complete it, and make the transition from analysis to action an explicit part of the design.
No more approving every small purchase — an agent handles recurring payments like groceries within limits set in advance, saving time while keeping spending capped and reversible. It’s a proposed framework, not yet live.
No. Anthropic’s blueprint leaves payment integration to the business, through its existing checkout or an agentic payments provider. The reference demonstrations hand checkout to the host application; they do not charge cards themselves. Claude Commerce Agents reference implementation.
Providers should establish whose authority the agent uses, which transactions that authority permits, how limits are enforced and how permission can be withdrawn. The workflow should retain records linking the instruction, permission checks and payment outcome. The exact requirements depend on the payment method and implementation.
Yes. Data access and execution permissions can be configured separately. Payneteasy MCP lets compatible assistants query permitted operational records while payment execution remains outside its access boundary. Authorised back-office actions use a separate UI API integration with its own permissions. Payneteasy MCP Agent Access.
Thank you for reaching us. Your request has been sent successfully. We will get back to you as soon as possible.
Message was not sent
