Agentic Payments: How AI Agents Move Money

Your AI agent retries a payment 20 times in 200 milliseconds. Ten are cleared, and your fraud system flags none of them. Your reconciliation team finds out the next morning, when the customer disputes every duplicate, and the auditor asks who authorized the purchase.

The duplicate-charge pileup is what agentic payments look like when AI agents move money on top of infrastructure built for human pace. AI agents retry on timeout, spin up helper agents that retry on their own, and work at machine speed.

What Are Agentic Payments?

Agentic payments are payments triggered, sequenced, and completed by an AI agent without a human in the loop. The AI agent reads live financial state, such as balances, conditions, and external events. The agent then decides how the money should move and executes the transaction end-to-end.

In practice, that can look like a finance agent sending a payout to a marketplace seller, or a treasury agent moving funds between an account and a partner bank to keep enough cash on hand.

4 Models of Agentic Payments

The four models differ in who controls the money movement and how much a human signs off on each transaction. The level of human sign-off drives what the agent is allowed to spend on, who handles the disputes, and what your logs need to capture.

Model 1: Agent with human in the loop

The agent finds items and builds the cart, and a human confirms before money moves, using payment tokens that are time-limited and capped in amount. In the fintech industry, that could be an autonomous payouts agent that assembles a list of supplier transfers from invoice data and then requires approval from a finance lead before initiating any fund transfers.

Model 2: Agent with stored credentials

The agent holds or calls a pre-approved credential and spends within preset limits, with no human sign-off per transaction. The credential is tokenized, tied to an agent's identity, and comes with rules you can set, such as per-session, per-merchant limits, and spending caps. Stripe's Agent Toolkit, with its Shared Payment Tokens, is the cleanest example of this model in production.

Model 3: Agent with a virtual card

A dedicated virtual card enforces spending rules set by the card network or issuer, so the controls remain predictable regardless of what the agent does. This is the model behind Visa's Intelligent Commerce and Mastercard's Agent Pay, both of which issue tokenized credentials scoped to a specific agent with spend controls enforced at the network level. A webhook handles each purchase attempt, and if the issuer or network doesn't return an approval or a decline within a short time window, the agent uses a preconfigured default.

Model 4: Agent with its own wallet

The agent holds a digital asset wallet and settles payments directly on a ledger or blockchain using digital assets such as stablecoins, without routing through a traditional payment processor. Coinbase's x402 protocol is the most developed example, embedding stablecoin payments directly into HTTP and enabling agents to pay APIs and other agents directly. Volume is still small relative to card networks, but the rails are live.

While each model gives the AI agent a different level of autonomy, every agentic payment still runs through the same lifecycle once the agent decides to spend.

How an AI Agent Moves Money

Every agent payment goes through the same six steps: determining the intent, authorizing it, selecting the rail, running it, settling it, and retrying if it fails. Each step hands a specific output — an intent, an authorization, a rail choice, or a transaction ID — to the next.

Step 1: Structure the intent

The agent reads an instruction and forms a view of what payment to make. That view becomes a structured transaction record that the rest of the system can execute, verify, and audit. A marketplace payout with a 10% platform fee is not a natural language instruction. It is a posted transaction with a named source account, a named destination account, and a precise amount.

Step 2: Authorize

Once intent has been structured, the payment system enforces the rules. If the source account does not have sufficient funds, the transaction does not proceed. Rule enforcement needs to live in the payment system rather than in the agent's code, because any control placed within the agent inherits the same probabilistic quality as the model that drives the agent.

Step 3: Pick the rail

With authorization confirmed, the system selects a payment rail based on the transaction's cost, speed, and reversibility. Production setups typically maintain connections to multiple rails simultaneously and apply routing rules at runtime rather than hardcoding a rail choice into each transaction. Payment connectivity modules and orchestration layers sit between agents and the rails, translating structured intent into rail-specific calls.

Step 4: Execute

The payment is submitted to the selected rail alongside an idempotency key. Either all postings in a transaction succeed, or none do. For an agent distributing a payout across three sellers in a single batch, a failure on any one posting rolls back the entire transaction, leaving the books consistent.

Step 5: Settle

Execution and settlement are distinct events that often occur at different times. The system records when a transaction was posted, while settlement occurs when the external rail confirms the transfer.

The posting timestamp and the settlement timestamp need to be tracked separately, because a system that treats posting and settlement as the same event will produce inaccurate balance records as soon as any timing gap appears between them. A bi-temporal ledger model — tracking both when an event was recorded and when it became effective — is what lets you answer “what was the balance at this [time]?” even when late events arrive.

Step 6: Retry or fall back

When a rail fails, the system retries the payment automatically using the same idempotency key, so that repeated attempts resolve to a single intended transaction rather than accumulating as separate charges.

If the primary rail is unavailable, the system routes to the next available option before surfacing a failure. Every attempt, along with its status and associated metadata, is recorded so that the full history is available for audit and debugging.

While these six steps map a strong execution of agentic payments, they must be built on a solid infrastructure.

What Agent Payments Need From Your Infrastructure

Five things define agent payments that can run safely in production: idempotency, rule-based authorization, agent identity, all-or-nothing multi-step payments, and tamper-proof logs.

1. Idempotency at machine scale

With human payments, a duplicate submission is an edge case. With agent payments, retries are normal. Agents hit network timeouts, lose connections before they get a response, and sometimes restart mid-job. Idempotency keys usually expire after a set time, which can cause failures for long-running agent jobs that span multiple sessions.

2. Rule-based authorization

When a human pays, intent and execution happen in the same moment.

With agents, intent and execution are split: the user approves at the time, and the agent actually pays an amount (maybe hours or days later), after planning and tool calls the user never sees. You need spending caps, merchant category limits, and time-limited permissions, all enforced by the infrastructure.

3. Agent identity

While traditional payment authentication answers one question, “Is this the real cardholder?”, agent payments need to answer two questions: “Who is the agent and who approved it?”

Adding human credentials into an agent's context gets the agent past the auth check, but creates a worse problem as the agent now has all of the human's spending power with none of the limits a proper machine credential would have.

4. All-or-nothing multi-step payments

Agent payments touch multiple systems (such as inventory, the payment processor, fulfillment, and the core ledger), and a single-database transaction can't cover all of them.

The infrastructure requires a series of small transactions, with each step committing immediately and, if anything fails, a reversal step undoing what came before. Every step needs a matching reversal step, designed and tested before you ship.

5. Tamper-proof logs

Built-in agent session logs only live as long as the session. Clients can save them afterward, but by default, they're gone after the session. Financial recordkeeping rules require logs to be retained for years, so session logs alone aren't enough. You need a logging layer below the agent that records every tool call, every auth context, and every agent ID, so the session can't be skipped.

These five requirements define what good infrastructure looks like, but missing any one of them produces failure modes.

Where Agent Payment Infrastructure Breaks

Each of the five infrastructure requirements maps to a specific failure in production: retry storms, authorization drift, identity collapse, orchestration breakage, and audit gaps.

Retry storms (missing: idempotency)

When a parent agent spawns sub-agents to do work in parallel, each sub-agent has its own retry logic. If the parent doesn't share a single idempotency key, each sub-agent retry creates a new charge, and the number of duplicates grows with the number of sub-agents. The scenario at the top of this piece — one charge retried until many duplicates clear — is what a retry storm looks like in the wild.

Authorization drift (missing: rule-based authorization)

If a credential is issued without merchant category limits or similar controls at the network or issuer level, the agent can buy things its reasoning deems fine but that the user never intended to allow. After the job ends, if the credential isn't rotated or revoked, subsequent calls continue to use it, including those made after the agent has been compromised or misconfigured.

Identity collapse (missing: agent identity)

When you can't tell which agent made which payment, you can't resolve disputes. Without a permanent record of which agent paid and what it was allowed to do at the time, you have the transaction but not the proof. Disputes where the customer says “I didn’t buy that, my AI did” behave differently from regular chargebacks and are harder to resolve if you can’t show which agent acted and under what policy.

Orchestration breakage (missing: all-or-nothing multi-step payments)

When inventory, tax, payment, and fulfillment each commit independently, a partial failure leaves the books in a state no one can clean up. A checkout pilot can fail in production because inventory doesn’t sync in real time or tax handling is missing. These are engineering failures that the agent can’t recover from because no reversal path was built in.

Audit gaps (missing: tamper-proof logs)

Without an immutable record of every tool call, auth context, and agent ID, you can't reconstruct what happened, which means you can't satisfy internal audit, financial reporting, or chargeback-evidence requirements when they come due. Agent payments add new paths for money to move; without durable logs, the new payment paths become blind spots.

While each of these failures has a different trigger point, they all share one cause: payment guarantees were left to the agent's code instead of the infrastructure supporting it. The fix is a programmable ledger.

How A Programmable Ledger Fixes Each Failure

A programmable ledger handles idempotency, identity, authorization, orchestration, and logging infrastructure to support the AI agent. The ledger creates rules that stay predictable no matter what the agent does.

These capabilities overlap in practice — atomic multi-step payments rely on idempotency, and audit logs depend on upstream identity capture. Each fix also has costs we're not enumerating here, including the fact that tighter idempotency can block legitimate reuses, append-only logs grow storage linearly, and atomic rollback adds latency that some rails can't absorb.

Still, each fix targets one specific failure:

Retry storms → Shared idempotency

Idempotency keys are propagated across the entire agent setup (parent, sub-agents, and fallback paths), so retries are recorded as a single entry on the ledger rather than N duplicate charges. This also underpins atomic multi-step payments, since safe rollback requires safe retry.

Authorization drift → Rules enforced by the system, not the agent

Spending caps, merchant category limits, and time-limited permissions are enforced by the credential and ledger, not by the agent's reasoning. Enforcement only works if agent identity is captured upstream, since the rules are tied to who is acting.

Identity collapse → Append-only logs tied to agent identity

Every action is stamped with the agent ID and the permissions it had at the time, and corrections are handled by adding reversal entries. This is the foundation the audit logs sit on; without identity capture, tamper-proof logs still can't answer "which agent did this?"

Orchestration breakage → Atomic multi-step payments

Each step in a payment is committed with a matching reversal step, so any partial failure rolls back cleanly across inventory, processor, fulfillment, and ledger. If the retry path isn't idempotent, a failed rollback that gets retried can leave the books in a worse state than the original partial failure.

Audit gaps → Tamper-proof, bi-temporal logs

Every event is recorded with bi-temporality, tracking both when it was recorded and when it was effective, so you can reconstruct any agent payment at any point in time and hand the record to an auditor. The logs are only as good as the identity and authorization metadata stamped into each entry.

The five-failures-to-five-fixes map only holds if the infrastructure supporting agent payments is one you can inspect.

Agent Payments Need Verifiable Infrastructure

Agent payments shrink the audit window from days to minutes. By the time a reconciliation team sees a discrepancy, the agent has already moved on to the next thousand transactions.

Without the right infrastructure, the discrepancy between executed transactions and provable records compounds with every automated decision. Auditability has always been the test for fintech infrastructure—answered through reconciliation runs with a human to reconstruct what happened.

Agent payments compress that timeline and remove the human entirely, which means the infrastructure itself has to answer the question: Can you prove what the agent did?

A programmable ledger ensures that what happened matches what you can prove by encoding the guarantees that matter for agent payments—idempotency, agent identity, rule-based authorization, atomic multi-step payments, and bi-temporal logs—in the ledger itself rather than in the agent's code. The rules stay predictable no matter what the agent does, and predictable rules are only valuable if they can be verified.

Formance is open source because a layer that sits at the center of money movement has to withstand inspection, defend itself under audit, and outlive whatever agent runs on it.