Before an Agent Can Pay, Define Who Can Stop It
Payment Capability Is Not Payment Authority#
Visa announced Intelligent Commerce Connect in April 2026. The pilot supports payment initiation, tokenization, spend controls, and authentication for agentic transactions. In March, Santander and Mastercard had completed a live end-to-end agent payment in a controlled environment with predefined limits and permissions.
Those developments do not mean that payment networks have opened without controls. They show the opposite: agent-initiated payments are being built around authentication, limits, identity, and existing regulated infrastructure.
For an operator, the immediate question is narrower. What authority will this agent receive inside your business, and who can stop it?
Separate the payment classes#
“Can initiate a payment” is too broad to be a useful permission. A recurring invoice from an approved supplier is different from a first payment to a new account. A customer refund differs from a purchase. A retry after a failed transaction carries a different duplicate-payment risk from the original attempt.
List those classes separately. For each one, record:
- allowed counterparties;
- transaction and cumulative limits;
- required evidence;
- conditions requiring human approval;
- conditions that stop execution entirely; and
- the person responsible for exceptions and disputes.
An agent should receive authority for a defined class, not general access to a payment method.
Make intent reconstructable#
When a payment is questioned, the team should be able to reconstruct more than the final amount. Keep a record of the request, the agent's identity, the policy and limit applied, the approval if one was required, and the transaction result.
This is part of the direction payment providers are taking. Mastercard describes Agent Pay as making agents visible, governed participants in the payment flow. Visa describes authentication and spend controls as core capabilities.
Those network controls do not replace the business's own approval policy. They provide infrastructure on which that policy can operate.
Treat ambiguity as a reason to pause#
Simple amount thresholds are useful but incomplete. A modest payment to a changed bank account may deserve more scrutiny than a larger recurring payment to a verified supplier.
Define the changes that force a human decision: a new counterparty, amended account details, an unusual frequency, a mismatch between the purchase record and invoice, or an instruction arriving through an untrusted channel.
The goal is not to make an agent judge every ambiguous situation correctly. It is to make the agent recognize situations where it lacks authority to decide.
Name the owner before the first exception#
Existing payment and dispute rules still apply when an agent initiates the transaction. The company operating the agent will need people who can investigate, provide evidence, reverse an internal action where possible, and respond through the relevant payment process.
Assign that responsibility by payment class. A procurement payment, customer refund, and card purchase may have different owners even if they use the same technical integration.
Agentic payment infrastructure is becoming real, but the operating design should stay deliberately constrained during pilots. Start with a narrow payment class, explicit limits, complete records, and a tested approval path. Expand authority only after the team can explain how both a normal payment and a disputed one are handled.
The integration proves that an agent can initiate a transaction. Your authorization design determines whether it should.
Acrein Group designs agent permissions and the human approval, exception, and evidence paths that surround consequential actions.