Autonomous Payments
A payment your software completes without you present is still your payment. What decides that is the mandate you wrote before it happened.
What an autonomous payment is
An autonomous payment is one initiated and completed by software the buyer configured earlier, without the buyer present at the moment of the transaction. The phrase covers a spectrum rather than a state, and the distance between its ends is where the commercial risk lives. A standing order is autonomous and nobody worries about it, because the amount, the payee and the schedule were all fixed when it was set up. An agent given a budget and a goal is also autonomous, and almost nothing about the resulting transaction was fixed in advance.
Everything difficult follows from that gap. The narrower the prior configuration, the closer an autonomous payment is to a standing order and the less anybody has to decide afterwards. The wider it is, the more the transaction depends on a judgement the software made, and the harder it becomes to say what the buyer actually agreed to.
Where the authorisation actually sits
Payment systems were built on the assumption that the person paying is present and can be challenged. Authentication proves presence. Dynamic linking ties that authentication to a specific amount and a specific payee. An autonomous payment has neither a present person nor, usually, a predetermined amount and payee.
The construction that holds moves the decisive moment backwards. The authorisation is not given at the transaction. It was given when the mandate was configured, and it extends only as far as that configuration reaches. Which makes the mandate the object that matters, and makes three of its properties decisive. Its scope, meaning what may be bought and from whom. Its ceiling, meaning at what value and over what period. And its expiry, because an authorisation with no end is not one anybody would defend in front of a regulator.
A mandate naming a category and a number has authorised considerably less than the transactions it will be used to justify. That is not a technical shortfall. It is the whole of the exposure, and it is created by whoever writes the mandate rather than by the protocol carrying it. The delegation chain sets out how far that distance can run.
Autonomous payment initiation
Initiation is the part most organisations have already built without calling it that. Any system triggering a payment on a rule rather than on a click is initiating autonomously, and most enterprises run several, in procurement, in replenishment, in subscription management.
What changes with agents is that the rule is no longer deterministic. A replenishment system that orders when stock falls below a threshold produces a transaction anyone can reconstruct. An agent that decides a supplier is preferable this week produces one that nobody can, unless the reasoning was captured at the time.
The practical consequence is that initiation and evidence are the same project. A system that can initiate but cannot explain has moved the payment out of human hands without moving the accountability anywhere. That is the arrangement that fails at the first dispute, and it fails on the evidence rather than on the payment.
Autonomous payment risk
Four risks, and only the first is the one people name.
Fraud is the obvious one and it is the best defended. Card networks, tokenisation and agent registration all address it, and the incumbents are competent at it.
Attribution is the second and it is barely addressed. When a purchase is disputed, somebody has to say which mandate authorised it and who granted that mandate. Where that cannot be produced, the transaction has no owner, and an unowned transaction resolves against whichever party has the weakest record.
Scope drift is the third. Mandates granted for one purpose get reused for another because reissuing them is friction and nobody notices the widening. A mandate that has quietly grown is the agentic equivalent of a shared administrator password.
Exception handling is the fourth and it decides the others. What your system does when a transaction falls outside its mandate is a business decision with three answers, each costing something. Fail it and lose the sale. Escalate and lose the automation. Allow it inside a wider tolerance and carry the liability yourself. That decision is cheap in advance and expensive at the moment of the exception.
What to put in place
Four artefacts, and they are the same four whatever protocol you end up on. A mandate scope per transaction class, saying which purchases may proceed on a standing authorisation and which require a fresh one. An exception policy written before the exception, covering value, payee, expiry and mismatch between the good and the intent. An evidence trail sized to the retention a dispute requires rather than to the retention your logging happens to have. And a named person accountable for configuration, monitoring and release, because an accountability distributed across three functions sits nowhere.
None of that depends on choosing between the Agent Payments Protocol, the Agentic Commerce Protocol or x402. They differ on how a mandate travels and they agree that one has to. What they do not decide is how narrowly yours are drawn, which is the part that is yours and the part that determines the exposure.
The way in
Start by establishing what already initiates autonomously in your organisation, because in most cases something does and it predates the agent conversation. Then establish, for one transaction class, whether you could reproduce the authorisation for a purchase made six months ago in a form a regulator would accept.
Most organisations discover the answer to the second question during a dispute, which is the most expensive moment to discover it. Building the record is cheap while agent volumes are low and no revenue depends on it. It is not cheap afterwards. The wider framing is in agentic commerce governance, and the questions buyers actually ask are answered directly in the FAQ.
Start the conversation
We advise companies on agentic commerce, from first assessment through to a defensible implementation decision.
Contact contraco