Ready to stop fighting your ledger?
Formance is a programmable core ledger that unifies fiat and stablecoin postings, enforces budgets in the write path, and preserves attribution from mandate to settlement.
An AI agent that retries a timed-out payment doesn't wait for morning. By the time your reconciliation team sees the discrepancy, the agent has moved on to the next thousand transactions.
For fintech and payment service provider (PSP) infrastructure engineers, agentic payments remove the human and compress the timeline. But without a proper supportive network, it can ripple through infrastructure, causing issues across systems.
Before fintechs and PSPs can ship support for this shift, engineering and financial teams need a working grasp of what agentic payments are, how they differ from human-initiated flows, and where budget controls, exactly-once execution, and audit trails have to live once no human is in the loop.
This guide covers the four payment models, the five-layer stack, card-versus-stablecoin sequencing, and the accounting layer no current protocol addresses, and one that Formance openly supports.
Agentic payments are payments initiated and executed by AI agents on behalf of a human or organization, under delegated authority. They run under pre-set rules, spending limits, and verified intent, spanning everything from micro-transactions for data to booking complex services at machine speed.
Three components make agentic payments work.
The benefits of agentic payments are efficiency, control, and an expanded reach into commerce that manual checkout can't serve. Agents remove human bottlenecks from repetitive, high-frequency tasks, and let organizations set spend caps per agent while the agent’s machine-speed settlement handles small payments that reduce processing time.
The four models of agentic payments are human-in-the-loop checkout, stored credentials with approval, virtual cards with controls, and agent-native stablecoin wallets. Simon Taylor laid out this framework in Fintech Brainfood.
The four models are grouped by who controls the money movement and how much human sign-off each transaction requires, running from maximum human control to full agent autonomy.
Human-in-the-loop checkout keeps final payment approval with the user because the agent finds and presents the purchase, and a human approves every transaction.
ChatGPT's Instant Checkout, where the user confirms each cart before payment executes, illustrates the conservative end of agentic payments. Human-in-the-loop checkout maps directly onto existing checkout infrastructure and preserves human control, but it also preserves the same checkout friction the agent was meant to remove.
With stored credentials, the agent inherits authority from the user's wallet, the same pattern as card-on-file or Apple Pay, and can spend against it across multiple purchases. Corporate travel is an example: an agent books flights within policy and requests manager approval on the final booking.
However, this agent model lacks separate credentials and operates on the user's identity and payment method. The stored-credential models remain experimental, limited in volume, and still emerging as the industry hasn't converged on security standards for this model or on how it will interact with existing wallets, cards, and rails.
In the virtual-card model, the agent gets its own payment credential: a virtual card with defined spend controls, including merchant category restrictions and single-use or expiry limits. The agent is the customer, with its own payment credential and its own onboarding path.
Merchant-category restrictions, single-use expiry, and per-transaction caps are all familiar across modern issuing programs. Virtual-card infrastructure can support card issuance with real-time authorization decisions and spend controls at the card or cardholder level. Card controls and card-rail data still bound the agent.
In the agent-native stablecoin wallet model, the agent controls its own funded, programmable wallet, typically a stablecoin-based wallet. The x402 path points toward agents paying without humans in the loop. The x402 uses stablecoins as its settlement method and gives the AI agent a wallet that can spend stablecoins at any endpoint that supports x402.
The stablecoin wallet model fits the long-term goal of agent autonomy, but acceptance remains the practical constraint while fraud models and wallet standards remain open questions.
The agentic payments stack has five layers: agent communication (MCP and A2A), trust and identity, mandates, transaction protocols, and payment rails. Whichever of the four models an agent uses, the same five-layer stack sits underneath every transaction.
Model Context Protocol (MCP) and Agent-to-Agent (A2A) are the two protocols that let agentic payment systems communicate. They carry the messages that turn a payment intent into a coordinated, executable transaction across the rest of the stack.
MCP connects an agent to the tools and data it needs to act (payment APIs, catalog systems, wallet balances, and mandate stores) through a JSON code client-host-server interface that exposes tools, resources, and prompts to the model driving the agent.
A2A handles how one agent talks to another. A2A lets a buying agent delegate sub-tasks to a merchant agent, a treasury agent, or an approval agent, and coordinate a payment flow without sharing internal memory or proprietary logic.
Know Your Agent (KYA) is an agent equivalent of Know Your Customer (KYC). Before an agent transacts, it registers with a network or issuer, receives a cryptographic identity credential tied to its operating principal, and presents that credential (plus the scope of what it's allowed to do) on every payment attempt. Acquirers, issuers, and merchants can then verify the agent's identity and its delegated authority at authorization time, rather than trying to reconstruct it after settlement.
The card networks are the furthest along in productizing KYA. Mastercard Agent Pay, announced April 29, 2025, issues Agentic Tokens: cryptographic credentials that change over time or by context, sit on top of existing tokenization, and require agents to be registered and verified before transacting. Visa Intelligent Commerce takes a similar approach, provisioning agent-specific payment tokens layered with step-up cardholder verification and Passkey-based authentication. Both networks are turning "agent identity" into a first-class credential the rest of the stack can rely on.
The mandates layer is how an agent gets, and proves, permission to spend. Google's Agent Payments Protocol (AP2) is the emerging standard here.
Before an agent transacts, the user (or the organization delegating authority) signs a mandate: a digital document that spells out what the agent is allowed to do, and for how much. The agent carries the mandate through the payment flow and presents it to merchants, processors, and issuers as proof of authority.
If anyone alters the mandate after signing, the signature breaks and the payment fails verification, so the signer can't later deny it, and no one can forge one.
AP2 defines three types of mandate:
The mandate sequence creates a non-repudiable audit trail. In a dispute, the mandate chain provides cryptographic proof of what was approved and which actors signed each step. AP2 uses Payment Mandates to authorize payments within the flow.
The Agentic Commerce Protocol (ACP) standardizes checkout between an AI surface and merchant systems.
OpenAI and Stripe introduced ACP on September 29, 2025, with the protocol powering ChatGPT's Instant Checkout. The specification was published under Apache 2.0 and is co-maintained on GitHub as an open standard. Stripe issues a Shared Payment Token scoped to a specific merchant and cart total while ChatGPT passes the token to the merchant, who processes it with their existing processor.
Checkout renders in the AI surface, but the merchant stays merchant of record and keeps settlement, refunds, and chargebacks. Instant Checkout initially supported a limited merchant set at launch, while broader merchant onboarding was expected to follow.
Settlement still happens on a payment rail. Cards, ACH, and stablecoins each carry different trade-offs on speed, cost, reversibility, and acceptance. Card rails bring batch settlement and mature chargeback processes.
Automated Clearing House (ACH) is slower and tied to bank operating windows. x402 is an open standard that uses the HTTP 402 "Payment Required" status code to support stablecoin payments for machine-speed settlement. For very small transactions, fixed card fees can overwhelm the value of the payment.
x402 is still experimental: transaction volumes are small, throughput varies by chain, and merchant acceptance is limited. Stablecoin payments are generally difficult to reverse once confirmed on-chain. However, rare chain reorganizations before finality and issuer/admin intervention such as freezes or seizures can still affect settled transactions.
Agents will transact on card rails first because card acceptance is broad and the control and dispute frameworks exist today. Stablecoin settlement follows as fleets scale.
In the cards-first version, the agents use scoped, single-use virtual cards first because they work for the transaction sizes, dispute frameworks, and merchant acceptance that exist today. Acceptance is broad, and mature controls already run on existing infrastructure.
Early card-based implementations favor card rails. Agentic payment implementations on existing card networks emphasize fraud controls and chargeback rights, and card-first implementations lean on single-use virtual card credentials to cap exposure per transaction.
Stablecoin-first adoption still faces coordination friction because buyers need to move fiat into stablecoins, merchants need to accept them, and the parties need to agree on the stablecoin and chain.
Stablecoins earn their place where card rails physically cannot follow: sub-dollar machine-to-machine payments and 24/7 programmable settlement.
At fleet scale, sub-wallet hierarchies also matter. A treasury can fund one parent wallet and programmatically allocate scoped budgets to hundreds of agent sub-wallets, with real-time visibility into what each agent holds and spends.
The likely end state uses both card rails and stablecoin settlement. But whichever rail settles the payment, none of the layers above answer the question a CFO will ask: what did the fleet actually spend?
Agentic payments need a ledger because the stack only proves an agent was allowed to spend, not what it actually spent, whether it spent it once, or which mandate authorized the money that moved.
Accounting is the missing layer in the agentic payments stack: none of the current protocols answer what a fleet actually spent or whether each transaction executed exactly once. Together, AP2, ACP, x402, Visa Intelligent Commerce, and Mastercard Agent Pay address authorization, authentication, checkout, tokenization, or payment-rail mechanisms for agent-initiated commerce.
But they fail to answer three questions in particular:
Overlooking the accounting layer has already proved expensive in human-led systems. On August 11, 2020, Citibank intended to send an interest payment and instead made an accidental $900 million payout to Revlon's lenders because there was no ledger-enforced control between authorization and execution.
If human-led systems can lose hundreds of millions in minutes without ledger-enforced controls, an autonomous agent fleet is a much larger blast radius. Four things have to move into the ledger itself: budgets that agents spend against, exactly-once posting so retries don't double-charge, attribution that ties every settled payment back to the agent and mandate behind it, and human-on-the-loop approvals for the actions that carry real consequences.
A production-grade agentic payment system needs four things: ledger-enforced budgets, idempotency keys on every write, full attribution back to the agent and mandate, and human-on-the-loop approvals for high-consequence actions.
Ledger-enforced budgets mean the agent's spend limit lives as a funded account in the ledger, not as a counter in application code. When the agent's monthly budget account is the source of every posting, double-entry enforcement and atomic multi-posting at the database level ensure each transaction is balanced and succeeds or fails as one unit.
In Numscript, Formance's purpose-built language for describing financial transactions, a procurement agent paying a $48,000 infrastructure invoice looks like this:
// AGENT_INVOICE_PAYMENT
// Event: procurement agent pays a $48,000 infrastructure invoice from its funded budget
// Note: account segments accept [A-Za-z0-9_] only; hyphenated IDs live in metadata
send [USD/2 4800000] (
source = @platform:agents:procure07:budget
destination = @counterparties:vendors:datacenter:payable
)
set_tx_meta("event_type", "agent_invoice_payment")
set_tx_meta("agent_id", "procure-07")
set_tx_meta("mandate_id", "intent-8841")
set_tx_meta("task_id", "gpu-capacity-q3")
set_tx_meta("budget_period", "2026-07")
The transaction must succeed or fail as a unit. The write path rejects partial state and after-the-fact soft warnings.
An idempotency key is a unique identifier attached to every write, so a retried request produces one posting instead of two. Exactly-once execution depends on making retries safe, and the check has to survive the client's retry behavior. A key that expires too early is a double-charge waiting to happen.
In practice, the idempotency key should be part of the write path that creates the ledger transaction or payment instruction, and the resulting transaction should be traceable to the key. An agent that retries twenty times should produce one posting.
Full attribution means every settled payment can be traced back to the agent, task, and mandate that authorized it, via metadata on the ledger transaction. Each ledger posting sits inside a Ledger transaction that carries identifiers for the agent and mandate, with the task ID when needed, as in the Numscript example above.
The AP2 mandate chain provides an append-only audit trail of payment-related authorization steps, and Formance Ledger transaction metadata can identify which settled posting an AP2 flow produced. Reconciliation can flag drift between ledger balances and payment service provider settlement reports at configurable intervals.
Human-on-the-loop approvals let a human supervise and intervene while routine executions continue, unlike human-in-the-loop workflows that stop for review each time. For fleets, use thresholds: agents can execute autonomously for low-risk actions, while meaningful consequences trigger confirmation. Every approval decision is recorded for audit trails.
Agentic payments cannot run at scale without a ledger underneath them. AP2, ACP, x402, Visa Intelligent Commerce, and Mastercard Agent Pay will keep fragmenting and converging, but none of them answer what a fleet actually spent, whether every transaction executed exactly once, or which agent and mandate authorized which settled payment.
Build the accounting layer once, in the storage layer, and every authorization protocol your agents adopt can lean on the same primitives: double-entry accounting, atomic transactions, transaction-level metadata, and reconciliation against PSP settlement. Your team stops re-implementing core accounting controls per protocol, and your finance team gets the same answer to "what did the fleet spend?" regardless of which rail the payment took.