Agentic payments: how AI agents pay with permission

What makes a payment agentic?

A standing order repeats a predefined instruction. An agent may instead interpret a goal, compare options and propose a transaction: renew a subscription within budget, purchase a permitted service or pay an approved invoice. The autonomy lies in choosing among allowed actions, not in acquiring unrestricted access to an account.

AI is one possible decision-making component. Payment authority should remain enforceable even when the model misunderstands an instruction or a merchant page contains malicious instructions. A prompt such as “never spend more than €50” is guidance to the model; a server-side limit is a control over the actual payment request.

A permission-first payment flow

1. Describe the goal.The owner gives the agent a task. A shopping goal or invoice is input, not yet payment authorization.
2. Grant bounded authority.A reviewed mandate identifies the agent, permitted recipients, amount limits, expiry and circumstances requiring approval.
3. Validate the proposed transaction.A trusted service checks identity, mandate status, remaining budget and payment details independently of the agent's explanation.
4. Use the payment provider's flow.The provider applies its own permissions, authentication and risk controls. A mandate is not a way around bank authorization.
5. Track the result.The system records the decision and follows the payment through its actual status, rather than treating an API acknowledgement as settlement.

Where should a person stay involved?

Human review is valuable when the proposed recipient is new, the amount exceeds a limit, the invoice is ambiguous or the action cannot easily be reversed. The approval screen should show the payee, total price, currency and scope of authority being granted. A vague “continue” button is a poor record of a consequential decision.

An agent can prepare a payment without being allowed to submit it. Another operating model permits execution inside a narrowly defined envelope. Choosing between those models depends on the use case and the provider's requirements; “agentic” does not mean that every payment should be unattended.

Design for refusal, retries and uncertainty

A revoked mandate, expired credential or exhausted budget should produce an understandable refusal. Concurrent requests need consistent budget accounting. Retrying after a timeout must not create a second payment accidentally: the system needs a stable request identity and a way to reconcile the first attempt.

Keep authorization evidence, the submitted payment and the reported outcome distinguishable. This makes it possible to answer “who permitted what?” without claiming that a signed receipt proves money has settled. Refunds, disputes and changes of recipient need their own policies.

Why European payment and identity rails matter

In Europe, the design sits alongside open banking, payment authentication and euro transfer infrastructure. PSD2 and its PSD3/PSR revision concern the payment-services framework; EUDI wallets concern identity and credential presentation; SEPA concerns payment schemes. They solve related but different problems. See the European Commission's payment-services overview.

The architecture can be useful on existing rails. It should not depend on a future digital euro becoming available, or assume that a digital identity credential is itself permission to transfer funds. The European rails guide explains those boundaries.