_PRODUCT/
AI Agent Payments: Protocols, Rails, and Ledger Requirements
By Formance Staff
Flows
Loading article content
Loading table of contents
Loading author
In February 2024, a British Columbia tribunal ruled Air Canada liable for a refund its chatbot invented on the fly, after the airline argued the chatbot was "a separate legal entity responsible for its own actions." The tribunal disagreed.
Moffatt v. Air Canada is the leading edge of a bigger payments problem: when an AI agent commits your company to a charge, no protocol or rail records show who authorized what, and no liability framework supports it.
AI agent payments initiate transactions without human approval and retry at machine speed against rails that provide no agent-specific accountability.
This article delivers a protocol map across AP2, ACP, x402, and TAP, a rail comparison across cards, stablecoins, and bank transfers, and the ledger invariants that secure AI agent payments.
AI agents void the assumption that every layer, from authorization through dispute resolution, requires human approval for every transaction.
This means the controls, audit trails, and liability rules that worked for human-initiated payments no longer apply to agent-initiated ones.
Three specific breakages follow this transaction: the human-authorization model is gone, the liability framework predates agents by five decades, and machine speed outruns the human-era controls meant to catch bad payments. Each maps to a different structural gap in the stack.
Legacy payment controls assume a human clicked, swiped, or signed to originate the transaction.
Agent-initiated payments work on a model in which an agent holds a delegated credential that can originate hundreds of payments per minute against a mandate the human signed once, weeks earlier.
Authorization becomes structural and mandate-based, which leaves traceability, consent, and liability as open questions.
US payment liability rules predate agent-initiated payments by roughly five decades, and each was written around a consumer who personally authorized a specific transfer.
The Electronic Fund Transfer Act (EFTA) and Regulation E govern unauthorized electronic fund transfers, and the Truth in Lending Act (TILA) and Regulation Z govern certain prepaid-account protections. EFTA and TILA date to 1978 and 1968.
No new consumer-protection statute has landed for agent-initiated transactions. The Federal Reserve, OCC, and FDIC have continued to scope how existing model risk guidance applies to generative and agentic AI.
Human-era payment controls, such as daily velocity limits, manual review queues, and four-eyes approval, were tuned for transaction rates a person could plausibly generate.
They fail open when the originator is a machine issuing thousands of calls per minute, because application-layer checks race against concurrent retries and lose.
AP2, ACP, x402, and TAP do not provide a complete record of what the agent did because each protocol covers only a distinct slice of the transaction path. AP2 handles authorization, ACP handles checkout, x402 handles execution, and TAP handles identity.
AP2, the Agent Payments Protocol, handles mandate-based authorization and was released on September 16, 2025.
AP2 expresses mandate authorization as three cryptographically signed verifiable credentials: Intent Mandate, Cart Mandate, and Payment Mandate. All three are signed with the Elliptic Curve Digital Signature Algorithm (ECDSA).
The Payment Mandate travels to the network and issuer carrying agent-presence signals and human-present or not-present modality. AP2 is rail-agnostic, backed by card networks, payment service providers (PSPs), and platforms. AP2 defines what an agent may spend, but the money settlement sits outside AP2's scope.
The Agentic Commerce Protocol (ACP) handles delegated checkout by issuing a vault token bounded by allowance constraints, including allowance.max_amount and allowance.expires_at.
The merchant handles processing, refunds, and chargebacks, which settle on the merchant's existing PSP rails. ACP is a live specification for how an agent hands over a bounded payment credential.
x402 handles payment execution natively inside the Hypertext Transfer Protocol (HTTP) request-response cycle. A server answers an unpaid request with HTTP 402, the agent retries with payment proof, and settlement happens on-chain or via a facilitator, with stablecoins such as USD Coin (USDC) used in some implementations.
Governance moved to neutral ground when the Linux Foundation launched the x402 Foundation with the protocol as its founding contribution. x402 keeps no durable account of what a fleet has spent.
The Trusted Agent Protocol (TAP) verifies an agent's identity to merchants at checkout, backed by a card network. TAP confirms whether the agent at the storefront is who the agent claims to be.
A wave of non-interoperating protocols, including the Merchant Payments Protocol (MPP) and the Universal Commerce Protocol (UCP), launched within months of TAP and extended the protocol list beyond TAP.
Whichever protocol wins, every settlement still has to land in one system of record, which makes the ledger database decision the durable one. Formance is a programmable, rail-agnostic ledger purpose-built for money movement at scale, giving engineering teams a durable system of record that sits beneath whatever protocols and rails they adopt.
A rail-agnostic record layer, like Formance Ledger, means protocol churn doesn't force re-architecture; instead, when the protocol field consolidates, the ledger that holds your balances remains intact.
Agents settle across three rail types: card rails, stablecoin rails, and bank transfers. Each has a different finality and recourse profile.
Card rails route agent payments through tokenized credentials on the Visa and Mastercard networks, with settlement running T+1 to T+3 through the acquirer and PSP.
A card authorization is a pending hold. The final amount may post as authorized, post lower, or drop off entirely, so the ledger balance needs distinct pending and posted states, or agents will spend against holds that never post.
Chargeback rights give a multi-day window to unwind a bad transaction, and interchange fees typically run 2–3%.
Card networks are extending the model directly to agents with Mastercard's Agent Pay for Machines, adding agent credentials and spending controls across cards and stablecoins.
Stablecoin rails settle agent payments on-chain in stablecoins such as USD Coin (USDC), reaching settlement finality in seconds once the network hits the confirmation threshold the sender selected.
There is no payment-level dispute recourse because a confirmed transfer is final, and any refund has to be a new counter-transfer initiated by the recipient.
Adjusted stablecoin transaction value now runs around $390B annually, and the rail is the default for x402-style HTTP-native execution where machine-speed finality matters more than reversibility.
Bank transfers split into two rails that should be modeled separately. ACH runs as batches with 1–3 day settlement and remains reversible within the return window, which puts it near cards on the reversibility-vs-speed axis.
Wire transfers, cleared through networks such as the Clearing House Interbank Payments System (CHIPS), settle same-day and are treated as near-final, which puts them near stablecoins.
Agents settle across three rail types: card rails, stablecoin rails, and bank transfers. Each has a different finality and recourse profile.
| Rail | Settlement window | Finality | Dispute recourse | Typical cost |
| Card (Visa, Mastercard) | T+1 to T+3 | Reversible until chargeback window closes | Chargeback rights over a multi-day window | ~2–3% interchange |
| Stablecoin (e.g., USDC) | Seconds, once confirmation threshold is met | Final on confirmation | None at the payment layer; refunds require a counter-transfer | Network gas fees (variable, typically sub-cent to low-cent range) |
| ACH | 1–3 days, batched | Reversible within the return window | Return codes within the ACH return window | Low flat fee per transaction |
| Wire (e.g., CHIPS) | Same-day | Treated as near-final | Effectively none once settled | Flat fee per transfer (typically 10–30+) |
AI agent payments are safe only when four invariants are embedded into the infrastructure: ledger-enforced budgets, write idempotency, immutable mandate attribution, and same-day rail reconciliation.
Enforce each invariant at the storage layer because application-level controls race against themselves the moment concurrent retries land.
Give each agent a ledger account funded with its budget. Every spend debits that account through a double-entry posting, and the ledger rejects the next transaction once the balance hits zero.
A stable idempotency key on every payment request collapses a retry storm into one ledger posting. An agent fleet retrying failed calls can duplicate settlements continuously across every vendor, so retries must reuse the same key and produce one posting
A procurement fleet operates against a $2,500,000 monthly budget account and one agent settles a $48,000 data-feed invoice. The request uses an idempotency key built from the mandate ID and invoice number, and tags the posting with the agent ID, mandate ID, and authorizing protocol.
In Numscript, Formance's language for financial transactions, the posting is:
Accounts: @platform:agents:procurement:fleets:7:budget holds fleet 7's procurement budget; @merchants:dataFeeds:payable holds the amount owed to the merchant.
Movement: $48,000 moves from the fleet budget to the merchant payable account.
// AGENT_INVOICE_PAYMENT
// Event: procurement fleet 7 pays a $48,000 data-feed invoice
send [USD/2 4800000] (
source = @platform:agents:procurement:fleets:7:budget
destination = @merchants:dataFeeds:payable
)
set_tx_meta("event_type", "agent_invoice_payment")
set_tx_meta("invoice_id", "inv001")
set_tx_meta("agent_id", "agt001")
set_tx_meta("mandate_id", "mnd001")
set_tx_meta("authorizing_protocol", "ap2")If the agent retries twenty times, the integration reuses the same key and creates one posting. One invoice, one posting, one debit.
Every posting must carry the agent ID, mandate ID, and authorizing protocol, so "which agent, under which authorization, spent what" is one query away.
The identifiers already come through upstream from AP2's signed Payment Mandate and ACP's payment metadata. The ledger just stores them on the posting. Nothing is edited or deleted; corrections land as reversal entries, and this is what ledger immutability gives you.
Reconcile internal postings against what each rail actually settled every day, not once a month: card spend against processor reports, stablecoin transfers against chain data, bank transfers against bank statements.
Name source accounts by rail so every posting keeps its origin. At agent volumes, a month of undetected drift is thousands of transactions no one can trace. The account-naming and reconciliation patterns are laid out in money movement architecture.
The record layer outlives the protocol choice, so decide on the ledger first.
Treat protocol adapters as swappable components at the edge of your system, and enforce the four invariants at the storage layer from day one.
You need a ledger that survives agent traffic, enforces double-entry and atomic transactions, carries agent, mandate, and protocol identifiers on every posting, and reconciles same-day against what processors and chains actually settled. That combination avoids situations like Air Canada. It is what we have built into Formance Ledger.
Clone the Formance Ledger on GitHub, run it locally, and post your first agent-attributed transaction.
The four protocols mostly occupy different layers: AP2 handles authorization mandates, ACP handles delegated checkout, x402 handles HTTP-level execution, and TAP handles agent identity.
A production stack can compose several of the four. Some emit post-settlement receipts or status signals, but none provides the durable, reconciled system of record required to account for agent spend.
Use the rail that matches your reversibility requirement: cards when you need dispute recourse, and stablecoins when the selected network and confirmation policy meet your speed and finality requirements at an acceptable cost. Use bank transfers where counterparties require them.
Different transaction paths may require different rails, so design the record layer to be rail-agnostic from the start.
Concurrent retries commonly expose weak idempotency controls first. Application-level deduplication that survived human-speed traffic fails under concurrent machine-speed retries, and duplicate settlements follow. Budget checks in application code fail next, for the same race-condition reason.