Agentic Payments Architecture: How AI Agents Pay Safely in 2026
When an autonomous agent clicks buy on your behalf, a deceptively hard systems question sits underneath the transaction: how does every party in the chain know the agent was actually authorized, for exactly this purchase, and no more? Agentic payments architecture is the set of protocols, credentials, and control planes that answer that question without handing a language model your raw card number and hoping for the best. The industry spent 2025 and 2026 converging on a shared shape: express human intent as a signed, scoped mandate; bind a network token to a specific agent and merchant; and keep a non-repudiable audit trail so disputes and fraud controls have something concrete to reason about. This post takes the systems view – the message flows, the trust boundaries, the failure modes – not a buyer’s guide.
Disclaimer: this article analyzes payment systems architecture and protocol design only. It is not financial, investment, tax, or legal advice, and names no product as an endorsement.
What this covers: the trust problem, scoped mandates and delegated authority, how AP2, ACP, Visa Intelligent Commerce and Mastercard Agent Pay work at a systems level, a four-stage flow, step-up auth, fraud controls for agent traffic, and non-repudiation via signed mandates.
Context and Background
For thirty years, card-not-present payments assumed a human sat behind the browser. Risk engines leaned on that assumption: device fingerprints, mouse movement, session cookies, a person who could be challenged with a one-time passcode. Autonomous agents break every one of those signals. An agent has no thumbprint, reuses infrastructure across thousands of users, and can fire requests faster than any person. If you simply gave an agent a stored card, you would have built the perfect fraud vector: a credential with unbounded authority operating at machine speed with no reliable way to prove who told it to spend.
The response, developed across networks, processors and platform vendors through 2025-2026, reframes the problem around delegated, provable authority. Instead of trusting the agent, the system trusts a cryptographic artifact the user signed – a mandate – and binds spending to a token that only works inside the mandate’s boundaries. Google published the Agent Payments Protocol (AP2) in September 2025 with mandates modeled as W3C Verifiable Credentials. OpenAI and Stripe shipped the Agentic Commerce Protocol with a merchant-and-cart-scoped Shared Payment Token. Visa and Mastercard extended their existing network tokenization services to carry an agent identity and consent scope. The primitives differ in encoding, but the architecture rhymes. Understanding that shared shape is the point of this article, and it builds directly on ideas we cover in card tokenization and PCI DSS vault architecture.
Agentic Payments Reference Architecture
Figure 1: The reference control plane – user intent flows into an agent, which obtains a scoped credential from a mandate service before transacting with a merchant and settling through the card network into an immutable ledger.
Figure 1 traces the full path a purchase takes. The user establishes intent and delegated authority. The agent runtime carries that authority but cannot mint spending power on its own; it must obtain a scoped credential from a mandate and credential service, which persists the signed artifact in a verifiable credentials store. When the agent reaches a merchant, the merchant returns a signed cart, and the resulting tokenized payment travels through the payment service provider to the card network’s token service, to the issuer for authorization, and finally to settlement and clearing. Every step writes to an immutable ledger and audit store. A parallel path handles step-up authentication and human review for anything the policy engine flags as high risk, routing the decision back to the user before authorization proceeds.
The architecture is best understood as three planes. The identity and authorization plane decides whether the agent may spend and how much – this is where mandates, scopes and step-up logic live. The payment plane moves value using network tokenization and existing rails, so that agentic traffic settles over the same clearing infrastructure as any card transaction. The evidence plane captures signed proofs and ledger entries so that disputes, reconciliation and fraud investigation have a durable, non-repudiable record. Separating these concerns matters: the identity plane changes fast as protocols evolve, the payment plane is deliberately conservative, and the evidence plane must outlive both for the life of any dispute window.
Directly answering the core question: an AI agent pays safely when a human-signed, scope-bounded mandate authorizes a network token that is cryptographically bound to that specific agent and merchant, verified for scope and replay at authorization time, and recorded in a non-repudiable audit log. No single component trusts the agent’s word; each verifies a signed artifact.
The trust boundary and delegated authority
The central design move is to stop treating the agent as a principal with its own authority and start treating it as a holder of delegated authority. In access-control terms, the user is the resource owner, the mandate is a constrained delegation, and the agent is a confused-deputy risk that the scope exists to contain. A confused deputy is a component tricked into misusing authority it legitimately holds; a compromised or prompt-injected agent is exactly that. The mitigation is not to make the agent smarter but to make the authority narrow enough that misuse is bounded. If the mandate permits at most 40 USD at one merchant within a two-hour window, the worst-case blast radius of a hijacked agent is 40 USD, not the whole account.
Where the credential is minted and held
A recurring architectural decision is where the scoped credential lives. Broadly there are three patterns. In the issuer-held pattern, the network or issuer mints an agentic token bound to the agent and merchant, keeping key material inside the existing token vault – this is the Visa and Mastercard approach, extending Visa Token Service and the Mastercard Digital Enablement Service. In the platform-held pattern, a payment platform issues a short-lived, merchant-scoped token after the user authenticates – this is the Shared Payment Token model. In the wallet-held pattern, the user’s wallet signs verifiable credentials directly and the agent presents them – closest to AP2’s mandate model. Each pushes the trust anchor to a different party, with real consequences for revocation latency, offline capability, and who bears liability when something goes wrong.
Agent identity and attestation
Scope-bounded authority only holds if the identity the mandate binds to is itself trustworthy, which makes agent identity a first-class concern rather than an afterthought. Two distinct questions live here. First, is this the specific agent instance the user delegated to, or an impostor presenting a captured credential? That is answered by binding the mandate to a per-instance key and requiring the agent to prove possession of the corresponding private key at transaction time, so a stolen credential without the key is inert. Second, is the agent running in an environment that has not been tampered with? That is the harder attestation problem, and 2026 architectures answer it partially – through platform-level agent registration, signed runtime attestations, and network-side agent registries such as the trusted-agent schemes the card networks introduced. The honest engineering position is that runtime attestation for agents remains less mature than the mandate layer above it. That gap is precisely why the mandate is scoped tightly and the evidence plane records provenance: the architecture assumes the agent environment may eventually be compromised and bounds the damage rather than betting on perfect agent integrity. Designing as if attestation is strong when it is not is a common and dangerous mistake in early deployments.
From Intent to Settlement: The Four-Stage Flow
Figure 2: A mandate-scoped transaction in sequence – the user signs intent, the agent obtains a scoped credential, presents a cart mandate to the merchant, and initiates a tokenized payment the network verifies for scope and replay before authorization.
Figure 2 shows the runtime message flow for a single purchase, and it is worth walking through as four distinct stages because each stage has its own failure surface and its own verification obligations. The stages are intent capture, mandate issuance, agent-initiated transaction, and settlement with audit.
Stage one – intent capture. The user expresses what they want, ideally with enough structure that it can be bounded: a product or category, a maximum price, a merchant or allowlist, and a validity window. In AP2 this becomes an Intent Mandate; in a card-network flow it becomes the consent policy attached to the agentic token. The critical systems property is that intent is captured as signed data, not as free text the agent might paraphrase or hallucinate. The signature ties a specific human authorization to a specific machine-readable constraint set, and it is the root of the entire non-repudiation story that pays off at dispute time.
Stage two – mandate issuance. The mandate service validates the user’s signature, checks the request against account-level policy, and issues a scoped credential. This is where the abstract intent becomes an enforceable object: spend limits, per-transaction caps, merchant allowlists, category restrictions, a start and expiry time, and a binding to the specific agent’s key. In AP2 the artifact is a W3C Verifiable Credential; in the Stripe and OpenAI model it is a Shared Payment Token scoped to a merchant and cart total; in the Mastercard model it is an Agentic Token that binds a tokenized card credential to an agent, a merchant scope, and a consent policy. Encoding differs, semantics converge.
Stage three – agent-initiated transaction. The agent presents the merchant with a cart, receives a signed cart mandate confirming price and items, and initiates payment using the token. The network’s token service performs the decisive checks here: is the signature valid, is the transaction inside the mandate’s scope and time window, is this a replay of a previously seen token or nonce, and does the anomaly score clear threshold. Only if all pass does authorization route to the issuer. This is the enforcement point that makes the whole model safe – the mandate is not merely advisory metadata, it is checked before value moves.
Stage four – settlement and audit. Once authorized, the transaction settles over standard clearing rails, and the evidence plane records the signed intent, the signed cart, the authorization result, and a durable audit reference. Idempotency keys ensure that a retried request does not double-charge, and reconciliation ties the ledger entry back to the mandate that authorized it. This is where agentic payments meet conventional ledger and double-entry architecture: the agentic layer adds provenance, but settlement discipline is unchanged.
To make the flow concrete, consider an illustrative worked example – the numbers are chosen for clarity, not drawn from any product. A user delegates grocery ordering with a mandate capped at 60 USD per transaction, 200 USD cumulative over seven days, restricted to two named merchants, groceries only, bound to agent key X. The agent assembles a 48 USD cart at merchant A. At the network token service, five checks run in order: the mandate signature validates in well under a millisecond; the 48 USD amount clears both the 60 USD per-transaction cap and the remaining 200 USD cumulative allowance; merchant A is on the allowlist; the nonce has not been seen before; and the anomaly score, built from velocity and provenance features, sits below threshold. Authorization proceeds. Now suppose the agent immediately tries a second 48 USD cart. The cumulative counter is now at 48 USD with 152 USD remaining, so the amount still clears – but a velocity feature notes two purchases within seconds from the same agent and nudges the anomaly score up. If it crosses threshold, the second transaction routes to step-up rather than authorizing autonomously. This is the mandate doing exactly what it was designed to do: permitting the intended behavior while making runaway spend structurally difficult.
Scoping the mandate precisely
Scope is the whole game, and precision matters more than breadth. A well-formed mandate constrains at least five dimensions: monetary (per-transaction cap and cumulative limit), merchant (a specific merchant or an allowlist), temporal (a validity window, ideally short), categorical (permitted product categories), and agent-binding (the public key of the exact agent instance authorized to spend). The tighter each dimension, the smaller the blast radius of any compromise. A mandate that says up to 500 USD, any merchant, valid 30 days is barely better than a stored card. A mandate that says up to 45 USD at this grocery merchant within four hours, groceries only, agent key X is a genuinely bounded delegation. These numbers are illustrative, chosen to make the scoping dimensions concrete rather than to describe any specific product’s defaults.
Network tokenization and cryptographic proof
Under the mandate sits the same network tokenization machinery that already protects card-on-file transactions, extended with two agent-specific fields: an agent identifier and a session or consent scope object. The token is a surrogate for the real PAN, useless outside its bound context, and it inherits the network’s existing lifecycle controls for suspension and revocation. Layered on top, passkeys and cryptographic proof – Mastercard uses Payment Passkeys built on the FIDO and WebAuthn model – let the user authorize high-value or first-time delegations with a hardware-backed signature rather than a phishable password. The combination means that even if the agent’s transport is intercepted, the token is scope-locked and the authorizing signature cannot be forged.
It is worth being precise about what the passkey actually signs, because that detail carries the security weight. A passkey is an asymmetric key pair whose private half never leaves the user’s device or hardware authenticator. When the user approves a delegation, the authenticator signs a challenge bound to the specific mandate parameters – the amount ceiling, the merchant scope, the agent key – so the signature attests to those exact terms, not to a generic login. This is what makes phishing structurally ineffective: an attacker who tricks the user into approving something can only obtain a signature over whatever terms were actually presented and bound, and a mismatched relying-party origin causes the authenticator to refuse outright. In the agentic setting this matters twice over, because the thing being authorized is not a single payment but a policy that will license many future machine-initiated payments. Getting a hardware-backed, terms-bound signature at delegation time is therefore the highest-leverage authentication moment in the whole flow, and architectures that skimp on it – accepting a soft credential to establish a broad mandate – undermine every downstream control no matter how well the later stages are engineered.
Deeper Walk-Through: Authorization Logic and Decision Matrix
Figure 3: The authorization decision path – each agent request is checked for a valid mandate signature, scope and time window, per-transaction and velocity caps, and anomaly score, with step-up or human review as the escape hatch before any approval.
Figure 3 makes the authorization logic explicit as a decision cascade. The order matters because it is arranged cheapest-and-most-decisive first. Signature validation is a fast cryptographic check that rejects forged or malformed mandates outright. Scope and window checks are simple comparisons that reject anything outside the delegation. Cap checks require a small amount of state – how much has this mandate already spent – and gate the request against per-transaction and velocity limits. Only the surviving requests reach the anomaly model, which is the most expensive and least deterministic stage. Anything the caps or anomaly score flags does not fail closed silently; it routes to step-up authentication or human-in-the-loop review, giving the user a chance to approve genuinely intended high-risk purchases.
Human-in-the-loop is not a fallback for a broken system – it is a designed tier. The right architecture defines risk bands and a policy for each. Low-risk transactions inside a tight mandate proceed autonomously. Medium-risk transactions – a new merchant, a value near the cap, an unusual category – trigger a lightweight step-up such as a passkey tap. High-risk transactions – large amounts, first delegation to a new agent, a mandate that would need widening – require explicit human confirmation before authorization. The systems challenge is making step-up asynchronous-friendly, because the human may not be present the instant the agent wants to transact. That usually means the agent holds a pending state, notifies the user out of band, and resumes only after a signed approval arrives.
The following decision matrix summarizes how the major architectural choices trade off. It is a systems comparison of mechanisms, not a ranking or recommendation.
| Design dimension | Wallet-held mandates (AP2 style) | Platform token (ACP style) | Network agentic token (Visa / Mastercard style) |
|---|---|---|---|
| Trust anchor | User wallet signs credentials | Payment platform issues token | Issuer or network token vault |
| Credential form | W3C Verifiable Credential | Merchant-scoped Shared Payment Token | Agentic token extending VTS or MDES |
| Scope binding | Intent, cart, payment mandates | Merchant plus cart total | Agent id plus merchant plus consent policy |
| Revocation path | Wallet or issuer revokes VC | Platform expires or revokes token | Network lifecycle controls |
| Non-repudiation | Strong, chained signatures | Token plus platform records | Network authorization records |
| Best fit | Open multi-party ecosystems | Chat and platform checkout | Existing card rails at scale |
None of these is universally superior. Wallet-held mandates give the cleanest non-repudiation chain and the most open interoperability but demand mature wallet infrastructure. Platform tokens offer the smoothest integration for an agent that lives inside a single platform’s checkout. Network agentic tokens reuse decades of settlement and dispute machinery, which is why they scale onto existing card rails with the least merchant re-engineering. Most real deployments in 2026 combine them – a wallet-signed mandate authorizing a network token, recorded through a platform – rather than picking one purely.
Dispute, chargeback, and non-repudiation
Non-repudiation is the quiet superpower of the mandate model, and it is worth spelling out because it changes the economics of disputes. In a conventional card-not-present transaction, the evidence a merchant can muster is circumstantial: an IP address, a shipping match, a device fingerprint. When a cardholder claims I never authorized this, the burden of proof is genuinely hard to discharge, which is why friendly fraud and chargeback abuse are chronic costs. The mandate model replaces circumstantial evidence with a cryptographic chain. The intent mandate proves the user asked for a class of purchase. The cart mandate proves the merchant offered exactly these items at exactly this price. The payment authorization proves the network moved value within the mandate’s bounds. Each link is a signature over specific data, and each is persisted in the evidence plane with an audit reference that ties it to the settled transaction.
That chain reshapes disputes in both directions. For a genuinely unauthorized charge – say a compromised agent that transacted outside its mandate – the absence of a valid, in-scope mandate is itself strong evidence favoring the cardholder, and the audit trail localizes exactly where the break occurred. For a disputed-but-legitimate charge, the signed intent and cart make it far harder to falsely claim non-authorization, because the cardholder’s own key signed the delegation. The systems obligation is discipline in the evidence plane: signatures must be stored immutably, clock-stamped, and retained for the full dispute window, which for card schemes can run many months. An architecture that logs a summary string instead of the actual signed artifacts has thrown away the very thing that makes agentic disputes tractable. This is also where regulatory strong-customer-authentication rules intersect the design: the passkey or step-up signature that authorized a high-value delegation doubles as the authentication evidence a scheme or regulator may require, so capturing it is both a fraud control and a compliance artifact.
Idempotency and reconciliation
Agent traffic makes idempotency non-negotiable. An agent that times out mid-request will retry, and without an idempotency key keyed to the mandate and cart, a retry becomes a duplicate charge. The discipline is standard – the client generates a unique key per logical operation, the server records the first result against that key and returns the same result for any replay – but the stakes are higher because agents retry aggressively and without human judgment. Reconciliation then ties every settled transaction back to the mandate that authorized it, so that finance and fraud teams can answer which delegation produced this charge deterministically. This is where the evidence plane earns its keep: the audit reference from stage four is the join key between the payment ledger and the mandate store.
Provenance and replay defense
Replay is a distinctive agent-era threat. Because agents pass signed artifacts between components, an attacker who captures a valid mandate or token wants to reuse it. Defenses are nonces bound into each authorization, short mandate validity windows, and per-transaction sequence numbers checked at the network token service. Provenance goes further: the system records which agent instance, on which infrastructure, presented the credential, so that a token suddenly appearing from unexpected provenance can be scored as anomalous even if its signature is technically valid within its window.
Velocity deserves its own treatment because agent traffic breaks the assumptions baked into human-centric fraud models. A human buyer generates a handful of transactions an hour at most, with natural gaps for browsing and decision-making; those rhythms are load-bearing features in conventional risk scoring. An agent can legitimately fire dozens of small purchases in seconds – restocking a pantry, rebalancing a subscription bundle – and a naive velocity model would either flag all of it as fraud or, if tuned loose enough to permit it, become useless. The architectural answer is to compute velocity per mandate and per agent key rather than per card, so the cap that matters is the cumulative spend the user actually authorized, not a generic account-level heuristic. This is why the cumulative and per-window limits in the mandate are not redundant with network fraud controls; they are the primary control, and the network anomaly model becomes a secondary safety net that watches for provenance and pattern deviations the mandate cannot express. Getting this layering right – mandate caps as the hard boundary, anomaly scoring as the soft one – is one of the sharper distinctions between an agent-native payment design and a card system with an agent bolted on.
Trade-offs, Gotchas, and What Goes Wrong
Figure 4: The failure taxonomy – authorization abuse, integrity failures, and operational failures, each converging on the same mitigation of bounded mandates and a durable audit trail.
Figure 4 organizes the failure surface into three families. Authorization abuse covers over-scoped mandates and prompt-injection hijacks, where the agent does something the user never intended. The mitigation is not perfect prompt hygiene – that is unattainable – but tight scopes that bound the damage and step-up gates on anything sensitive. A red-teaming literature is already emerging on prompt-injection attacks against these protocols, which is precisely why the architecture leans on cryptographic scope rather than model behavior.
Integrity failures cover replay of a signed token and cart tampering after consent. The gotcha here is subtle: it is not enough for the user to sign intent if the cart the agent finally submits differs from what the user approved. That is why the cart mandate exists as a separate signed artifact – the merchant confirms the exact price and items, and a mismatch between the intent mandate and the cart mandate is a hard reject. Systems that skip the cart-signing step leave a window for an agent to be steered toward a different, more expensive purchase.
Operational failures cover duplicate charges from missing idempotency and silent partial settlement, where an authorization succeeds but capture or
