AI agent payments: what actually happens when your automation buys something

AI Agents · By Caleb Sakala · March 26, 2026

In early March 2026, Santander and Mastercard completed Europe's first live AI agent payment inside a regulated banking environment. An AI agent, operating with delegated authority from an account holder, executed a real financial transaction through a real bank. Legal teams spent months scoping the authorization parameters. Every edge case was pre-audited before the agent ever ran.

The coverage framed it as a milestone. It was. It was also a controlled proof of concept, and the engineering that made it work is almost nothing like what happens in a real AI automation workflow built by an ops team or a developer trying to give their agents purchasing capability.

The gap between that demo and the operational reality is where the real engineering questions live. For teams building automations that handle money, those questions don't have clean answers yet.

The decision point nobody talks about

Before any AI agent payment happens, the agent has to decide it should happen. In a single-purpose assistant, that decision is trivial: the user already made it. Book this flight. Reorder these supplies. The parameters are set in advance, and the agent executes inside them.

Automation workflows are different. The agent isn't fulfilling a pre-approved decision. It's running continuously in the background, discovering opportunities, and deciding whether those opportunities cross a purchasing threshold. A procurement agent monitoring vendor prices across five supplier platforms might run for weeks without recommending a purchase. Then it finds a vendor offering 23% below the current contract rate on a component the company buys at volume.

Should it flag? Should it buy? The answer depends entirely on where the authorization boundary was drawn when the workflow was built. For most teams building AI automations today, that boundary is either implicit or missing entirely. And when it's missing, the agent will show you exactly what it was allowed to do.

How AI agent payments actually work

Google's Agent Payments Protocol (AP2), Stripe's Machine Payments Protocol (MPP), and Visa's Trusted Agent Protocol all address the same foundational problem: proving that a human user actually authorized the agent to make a specific purchase.

The mechanism is similar across all three. The user issues a scoped payment credential to the agent (a token carrying spending limits, merchant category restrictions, and time constraints). When the agent initiates a transaction, the merchant verifies the token against the user's original authorization. Mastercard's verifiable intent framework extends this further, linking identity, intent, and action into a single privacy-preserving record that confirms the account holder authorized the agent, captures the specific instructions the agent received, and logs the agent-merchant interaction. The audit trail runs from human to agent to merchant with cryptographic proof at each step.

Stripe's MPP sessions primitive is genuinely useful for recurring procurement: instead of seeking per-transaction authorization, an agent establishes an upfront spending authorization (say, $10,000 in vendor category over 30 days) and draws against it without returning for human approval on each purchase. Coinbase's x402 protocol, launched in May 2025 with ERC-20 token support added in March 2026, addresses a separate problem entirely: AI agents paying other AI agents for services, in a machine-to-machine payment context where neither end of the transaction is human.

These solve the easy case. One agent, one authorization, one merchant, one transaction. Most real workflows don't look like that.

Where AI agent payments run into trouble

All of the standards above assume the agent holding the credential is the one making the purchase. For single-agent workflows, that assumption holds. For multi-step orchestration, it's almost never true.

Real automation workflows are trees, not linear sequences. An orchestration agent spawns a vendor-research sub-agent, which spawns a price-comparison sub-agent, which identifies a supplier and wants to place an order. The payment credential was issued to the orchestrator. The sub-agent at the end of the chain received a delegated research task, not a payment mandate. Nothing in AP2, MPP, or the Trusted Agent Protocol defines how an orchestrator passes scoped payment authority to a child agent with narrower constraints, nor how those constraints should be enforced as authority moves down the hierarchy.

Inter-agent payment delegation is not in any of the current standards. This is a known gap, and several platforms have had to develop internal workarounds. Chase Agents routes payment authority through explicit action-type distinctions, so research sub-agents cannot initiate spend regardless of what the parent orchestrator is authorized to do. Zapier's agentic automation layer handles this through manual credential assignment per workflow step. N8N requires teams to wire authorization themselves at each workflow node. All three approaches work, and none are portable across platforms, which is why a formal standard for hierarchical delegation matters.

McKinsey projects the global agentic commerce market will reach between $3 trillion and $5 trillion by 2030. 87% of financial institutions surveyed by Nevermined identified trust as the single biggest barrier to adoption. That trust gap isn't primarily about fraud detection or token security. It's about confidence that a transaction record accurately reflects authorization that flowed correctly through every step of the workflow, not just that the top-level orchestrator had a valid credential when it started.

The regulatory complication most builders aren't thinking about

Teams building in the US have some room to experiment here. American payment regulations are relatively permissive about agentic authorization at the workflow level. Teams deploying in Europe or the UK face a harder constraint.

PSD2's Strong Customer Authentication requirements mandate clear human authorization for payment orders within the EU and UK. The current regulatory framework has no mechanism for AI agents to serve as the authorizing principal in their own right. The Santander demo worked because the authorization structure was pre-approved at the account level before the agent ran. The agent didn't authenticate autonomously; it operated within a pre-authorized scope that a human established explicitly. For automations that need to operate in European markets, the authorization boundary must sit before the agent acts, not as a catch inside the agent's logic. That constraint is more significant than most API documentation for the new payment protocols acknowledges.

How to configure AI agent payments correctly

The practical answer is to treat payment authority as a workflow-level permission, not an agent-level default. Nothing in the current standards forces this approach. The default path leads somewhere bad.

The failure mode is common: configure a spending credential at the automation level, assign it to the orchestrator, and let downstream sub-agents inherit purchasing capability through tool access. Every agent in the workflow that can reach the payment tool can trigger a purchase. Fast to build. A genuine problem when the fourth sub-agent in a research chain places an order the workflow was never supposed to initiate.

The correct pattern is scope reduction at each delegation boundary. The orchestrator holds a credential authorizing category X up to amount Y. When it spawns a vendor-research sub-agent, that agent gets a read-only credential with no purchasing capability at all. If it surfaces an opportunity, it returns a recommendation, not an action. The orchestrator evaluates whether that recommendation clears its authorization constraints before executing. Chase Agents expresses this as a routing distinction built into the workflow configuration: a research agent returns purchase_recommendation objects that route to an approval step, while only the orchestrator holds the tool access to initiate purchase calls. The spend boundary stays exactly where the user originally configured it.

For teams building without a managed platform, manual tool isolation achieves the same result. A sub-agent that only needs to read prices and compare suppliers simply should not have a payment tool in its tool list, regardless of what credentials its parent holds. It's more setup work than inheritance, and it requires actually tracing which agents in the workflow need what capabilities. That trace is exactly what most teams skip when they're moving fast.

One useful test before a workflow goes to production: for every agent in the pipeline, ask whether it needs to initiate a purchase or just surface information. The second job is far more common. Keeping those two roles separated at the tool-access level is how the authorization chain stays clean without waiting for the protocol standards to formalize what should happen next.

What the next 18 months look like

The inter-agent delegation gap will close. The FIDO Alliance's digital wallet work and the OpenID Foundation's agent authorization group both have hierarchical delegation on their roadmaps. The most likely near-term outcome is a derivative credential standard where a child agent's payment authority is cryptographically bound to be a strict subset of its parent's, with the full delegation chain auditable from the original human authorization down to every sub-agent that touched the workflow. Stripe's MPP session architecture is the closest existing approximation of what that will look like.

When that standard exists, the manual scoping described above becomes automated enforcement. The workflow design decisions don't disappear (someone still has to decide where the authorization boundaries belong), but the enforcement stops being something each team builds from scratch.

The Santander demo proved that payment infrastructure and regulatory frameworks can accommodate AI agents. That was a real question eighteen months ago. The question now isn't whether AI agent payments work. It's whether the authorization architecture inside any given workflow is actually correct.

That question doesn't get answered by reading the AP2 specification. It gets answered by tracing the chain, step by step, before any of it touches a production environment.