Mastercard Agent Pay: What the Authorization Needs to Know

A card authorization was designed around a person. Somebody tapped, clicked or typed, and the issuer decided whether that person, with that card, at that merchant, looked right. The question “did the cardholder mean to buy this?” was mostly settled by the fact that the cardholder did it.

An agent breaks that. The user says “reorder groceries every week, keep it under a budget,” and then is not present for any of the purchases. The merchant sees an agent. The issuer sees a token. Everyone needs to know what the user actually allowed, and whether this purchase is still inside it.

This page covers what Mastercard Agent Pay is, what Verifiable Intent adds, and the state the authorization path needs to answer “still inside it?” correctly.

What Is Mastercard Agent Pay?

Mastercard Agent Pay is Mastercard’s agentic payments program. AI agents are registered and verified, then pay on a user’s behalf with Agentic Tokens: tokenized card credentials issued for agent use. The user controls what an agent may buy, and merchants and issuers can recognize the transactions an agent made.

Mastercard announced Agent Pay on April 29, 2025. The release says: “The program will require trusted AI agents to be registered and verified, after which they will be able to make secure payments on behalf of their users.” On control, it says “Consumers will have complete control over what the agent is allowed to purchase on their behalf.”

On September 30, 2025, Mastercard described Agentic Tokens as “dynamic digital credentials that empower AI agents to transact safely and transparently on the consumer’s behalf” and said they “have been built to register, verify and recognize agentic transactions.” The same post said that, with the launch of OpenAI’s Instant Checkout and the Agentic Commerce Protocol, “Mastercard Agent Pay and Agentic Tokens can be used on OpenAI’s platform for the very first time,” and that “Citi and US Bank cardholders are already enabled for Mastercard Agent Pay-powered transactions, with all U.S. Mastercard cardholders being equipped to do so by mid-November.”

How Merchants Recognize Agent Pay Traffic

Before any payment, a merchant’s site has to tell an approved agent from a bot. Cloudflare wrote in October 2025 that “Mastercard developed Agent Pay to help merchants distinguish legitimate, approved agents from malicious bots,” and that Agent Pay and Visa’s Trusted Agent Protocol both “leverage Web Bot Auth as the agent authentication layer.”

The agent signs its HTTP requests with HTTP Message Signatures. “Both protocols build on Web Bot Auth by introducing a new tag that agents must supply in the Signature-Input header, which indicates whether the agent is browsing or purchasing.” Registered agents’ public keys sit in a directory, so merchants and networks can “fetch the keys to validate these HTTP message signatures,” and to start, Mastercard would host the directory for Mastercard-registered agents. Per the same post, a merchant can then “identify a registered agent and distinguish whether a particular interaction is intended to browse or to pay,” “link an agent to a consumer identity,” and “indicate to agents how a payment is expected.”

A valid signature tells the merchant who sent a request and why. It says nothing about what that agent’s other workers have already spent.

Verifiable Intent: The Record of What Was Allowed

A token proves the credential. It does not prove the instruction. On March 5, 2026, Mastercard introduced Verifiable Intent, “a new open, standards-based trust layer for agentic commerce,” built with Google and “Aligned with Google’s Agent Payments Protocol (AP2) and Universal Commerce Protocol (UCP).” Mastercard says it “links identity, intent, and action into a single, privacy-preserving record,” and that it “will be integrated directly into Mastercard Agent Pay’s intent APIs.”

The specification is public. Its status line reads “Draft (v0.1). Maintained by Mastercard; open to multi-stakeholder contribution.” It defines a chain of signed SD-JWT credentials, one layer per party, listed below.

Each layer is signed with a key the layer above it names, and each is narrower and shorter-lived than the one before.

Immediate mode is a user confirming an exact cart. Autonomous mode is the interesting one: the user signs constraints, and the agent builds the final purchase inside them. The spec’s example is “Buy me a racket and some balls under $300 from Tennis Warehouse.”

Agent Pay for Machines

On June 10, 2026, Mastercard launched Agent Pay for Machines, which it says “builds on Mastercard’s Agent Pay program,” for payments between agents and the services they buy: “payments, some only fractions of a cent, to be completed quickly, programmatically and securely.” The release lists four foundational capabilities:

• Credentialing: “Every agent is credentialed, and with Verifiable Intent, can be recognized and transact with trust across ecosystems.”
• Permissioning: “Organizations can set authorization rules and spending limits that are programmatically enforced, ensuring transactions stay within defined parameters.”
• Transacting: “Verified participants can connect and transact across providers and systems, enabling continuous, high-frequency automated commerce.”
• Settling: “Supports reliable, guaranteed multi-rail settlement across cards, accounts and stablecoins.”

The release names more than 30 early supporters, including Adyen, Checkout.com, Cloudflare, Coinbase and Stripe, and Coinbase’s quote points to “open standards like x402” (see x402).

Machine payments sharpen the platform’s side of the problem. Limits set with Mastercard cover the transactions Mastercard sees. An agent that pays per call, many times a minute, and over more than one rail, still needs its own count of what it has committed before each authorization comes back.

Stateless Checks and Stateful Checks

The constraints spec registers eight types. Six of them matter here; read them by what the verifier needs to evaluate them:

The first four compare one purchase against the signed constraints. The last two do not. When agent_recurrence is present, the spec requires the mandate to carry both an amount_range and a budget. Its validation algorithm says to “Retrieve cumulative_spent from the payment network’s mandate tracking state,” add the new amount, and fail if the result exceeds max. The spec is explicit: “Payment networks MUST maintain stateful tracking of cumulative spend per L2 mandate pair when a mandate.payment.budget constraint is present.”

So the network keeps its own running total, inside its own systems. That is where the spec puts the final check. It leaves two questions the network can’t answer for you.

What the Agent Platform Must Know Before It Submits

The network checks one mandate’s spend at authorization. The agent platform decides whether to submit at all, and it usually knows things the network does not:

Spend in flight. An agent that has built L3 credentials for a purchase that hasn’t authorized yet has spent that money as far as its next decision is concerned.

Budgets that span mandates. A company may give a procurement agent a monthly cap across many users’ mandates, or a household may share one grocery budget across two assistants. No single mandate carries that total.

Platform policy. A per-merchant ceiling the platform set last week, a merchant it paused an hour ago, a retry limit after declines.

Call it authorization-time context: everything the decision to submit a payment has to read, at the moment it submits. If it is stale, the network still declines the overspend on a budgeted mandate. But the decline comes after the agent picked the item, held the cart and told the user, and for budgets the network never sees, nothing declines at all.

A Worked Failure: Two Workers, One Mandate

The numbers below are illustrative, built to show the mechanism.

A shopping platform runs agent workers on a queue. A user signs an Autonomous mandate for weekly household orders: agent_recurrence, a per-order amount_range, and a budget of USD 300.00. The platform tracks spend in a table that a job updates from authorization responses every 30 seconds.

At 09:00:00 the table says USD 230.00 spent. Two tasks for the same user land on two workers: a cleaning-supplies reorder for USD 45.00 and a pantry restock for USD 52.00. Both workers read USD 70.00 remaining. Both build carts, hold them with merchants, sign L3 credentials and submit.

The first authorizes. The network’s tracked total for the mandate is now USD 275.00. The second would take it to USD 327.00, so the network declines it on the budget constraint, as specified. The pantry merchant releases a held cart, the user gets a “your order failed” message, and the worker retries on the next cycle against a total that still says USD 230.00 until the job runs.

Nothing in Agent Pay or Verifiable Intent failed. The network did exactly its job. The platform decided on context that was 30 seconds old and did not count its own in-flight spend. That is a race condition between agents, and the user experiences it as an unreliable assistant.

How to Hold Mandate Spend State

Give the platform its own ledger, and make the reserve one transaction that covers every budget the purchase touches.

-- Before the agent signs L3 (Postgres-style SQL)
BEGIN;

UPDATE mandate_budgets
SET    reserved = reserved + :amount
WHERE  mandate_id = :mandate_id
  AND  spent + reserved + :amount <= max_amount
RETURNING mandate_id;            -- zero rows: over the mandate budget, ROLLBACK

UPDATE org_budgets               -- a cap that spans many mandates
SET    reserved = reserved + :amount
WHERE  org_id = :org_id
  AND  spent + reserved + :amount <= monthly_cap
RETURNING org_id;                -- zero rows: over the org cap, ROLLBACK

INSERT INTO purchase_intents (intent_id, mandate_id, org_id, agent_id, merchant, amount, status)
VALUES (:intent_id, :mandate_id, :org_id, :agent_id, :merchant, :amount, 'reserved');

COMMIT;
-- On authorization: move amount from reserved to spent.
-- On decline or L3 expiry (~5 minutes): release it.
-- Every path touches mandate_budgets before org_budgets, so two workers can't deadlock.

Under READ COMMITTED, each conditional UPDATE waits for a concurrent update to the same row and re-checks its WHERE clause, so two workers cannot both reserve past a cap. Tie each reservation’s lifetime to the L3 credential’s, so an abandoned purchase frees its budget when it can no longer authorize.

If every budget is one row and the agent count is small, that is all you need. It gets harder when the decision also reads derived context: spend by this agent across all users today, declines by merchant in the last ten minutes, how often this mandate’s purchases are being retried. Those are aggregates over a table that every worker writes to, and they have to be current when the agent decides.

Where Tacnode Fits

Tacnode holds the platform’s side of the loop: the decision context each agent reads before it submits, and the decision it writes after. The authorization stays with Mastercard and the issuer, and the network’s budget check stays where the spec puts it.

Mandate budgets, org caps, per-agent limits and purchase intents are state the platform owns. Held in the Tacnode Context Lake™, they are covered by full ACID transactions: two workers cannot both reserve past a cap, because the reservation is a committed write. Derived context, such as spend per agent per day or declines per merchant, is computed on demand against the latest committed data in the same snapshot. Authorization results come back as writes and become context for the next purchase.

That is the context gap closed for one decision: the agent submits with an accurate picture of what it has already committed. For the same pattern on other rails, see x402 and Visa Intelligent Commerce.

FAQ