{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "What is the Agent Payments Protocol (AP2)?",
"acceptedAnswer": {
"@type": "Answer",
"text": "AP2 is an open protocol that lets AI agents make payments on a user's behalf with verifiable, scoped authorization. Originally announced by Google in 2025 and donated to the FIDO Alliance in 2026, AP2 introduces mandates, cryptographically signed user-intent artifacts that bind an agent to a specific spending scope. AP2 sits on top of A2A (agent-to-agent) and MCP (Model Context Protocol) and is supported by 60+ partners including Mastercard, PayPal, Adyen, Coinbase, Etsy, Forter, Intuit, JCB, Revolut, Salesforce, and Worldpay."
}
},
{
"@type": "Question",
"name": "How does AP2 differ from traditional payment protocols?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Traditional payment protocols authorize a single human-initiated transaction at a time. AP2 authorizes an autonomous agent to transact within a bounded scope (max amount, merchant, expiry) over a period of time. The mandate is cryptographically signed by the user, presented by the agent at payment time, and verified by the merchant or payment service provider before settlement. This shifts the trust boundary from per-transaction approval to per-mandate approval and creates an auditable chain of agent activity."
}
},
{
"@type": "Question",
"name": "What is a mandate in AP2?",
"acceptedAnswer": {
"@type": "Answer",
"text": "A mandate is the core primitive of AP2. It is a cryptographically signed artifact that records the user's intent: which agent is authorized, what amount they may spend, at which merchant or category, and until when. Mandates are issued, used (potentially many times), revoked, or expired. Each lifecycle event becomes a verifiable record that payment infrastructure can stream, audit, and reconcile."
}
},
{
"@type": "Question",
"name": "How can RisingWave help monitor AP2 mandates in real time?",
"acceptedAnswer": {
"@type": "Answer",
"text": "RisingWave is a streaming database that ingests AP2 mandate events from Kafka or directly via SQL and maintains materialized views that always reflect the latest state: which mandates are currently active, how much each agent has spent under each mandate, and which uses violated scope (expired or revoked). Because the views update incrementally as new events arrive, payment platforms can detect rogue agent behavior in seconds rather than after a nightly batch run."
}
}
]
}
What Is the Agent Payments Protocol (AP2)? A Complete 2026 Guide
AI agents are starting to spend money. Not in the figurative sense of agents driving up cloud bills, but in the literal sense: an agent inside your inbox booking a flight, an agent inside your shopping app reordering groceries, an agent inside your CRM paying a vendor invoice. The question that fintech, banks, and merchants now have to answer is the same question that browsers and websites had to answer two decades ago. What does authorization look like when the entity making the request is not a human?
The Agent Payments Protocol (AP2) is the most credible answer that has emerged so far. Originally announced by Google in late 2025 and donated to the FIDO Alliance in early 2026, AP2 has rallied 60+ partners across cards, processors, marketplaces, and AI infrastructure, including Mastercard, PayPal, Adyen, Coinbase, Etsy, Forter, Intuit, JCB, Revolut, Salesforce, and Worldpay. It is the closest thing the industry has to a shared standard for agent-mediated commerce.
This guide explains how AP2 works, why mandates are the right primitive for agent payments, how AP2 composes with A2A and MCP, and how to monitor mandate events in real time with streaming SQL on RisingWave. Every SQL example in the operations section is verified on a live RisingWave v2.8.0 instance with real output included.
What Is the Agent Payments Protocol (AP2)?
AP2 is an open protocol for authorizing payments initiated by AI agents on behalf of human users. It defines a small set of message types, a verifiable artifact called a mandate, and a trust chain that ties the user's identity, the agent's identity, and the merchant or payment service provider together.
At a high level, AP2 answers four questions for any agent-initiated payment:
- Who is the user? The user authenticates once with their identity provider, typically via FIDO/WebAuthn or an equivalent passwordless flow.
- Who is the agent? The agent has a verifiable identity, often an OAuth client or a signed agent card, that the user has explicitly bound to their account.
- What is the agent allowed to do? The user signs a mandate that constrains the agent's spending: maximum amount per transaction, allowed merchant or category, and an expiry timestamp.
- What happened? Every issuance, use, revocation, and expiration of a mandate is an auditable event that flows through payment infrastructure.
AP2 is intentionally not a new payment rail. It does not replace cards, ACH, SEPA, or stablecoins. Instead, it is a layer of authorization metadata that travels alongside an existing payment, telling the merchant or processor: "this charge is being initiated by an agent, here is the mandate that authorizes it, and here is the cryptographic proof that the user signed it."
This narrow scope is part of why AP2 has gathered such broad ecosystem support so quickly. Card networks, processors, and PSPs do not need to rebuild their infrastructure to support AP2. They need to read mandates, verify signatures, and emit lifecycle events. The hard parts of payments (settlement, dispute, chargeback) remain unchanged.
Why AP2 Matters: The Agent Payment Trust Problem
Imagine an AI agent that handles a small business owner's expense reports. The owner wants the agent to pay invoices automatically up to $5,000 per vendor, only at vendors already in their accounting system, and only for the next 30 days. Without AP2, this is a hard problem:
- Sharing card credentials with the agent is a breach of card scheme rules and a liability if the agent is compromised.
- Issuing a virtual card per agent does not encode merchant constraints or vendor allowlists at the network level.
- Per-transaction approval defeats the purpose of automation.
- OAuth-style bearer tokens lack the cryptographic binding to user intent that fraud teams want.
AP2 sits exactly in the gap these alternatives leave open. The mandate is a signed record of user intent, not a credential. It is presented by the agent and verified by the merchant or processor. If the agent is compromised, the mandate is still scope-bounded, time-bounded, and revocable. If the agent acts within its mandate, the user has cryptographic proof of authorization for every charge.
For payment companies, the trust problem has another dimension: liability. Card scheme rules around card-not-present transactions and emerging agent-specific regulation both require some form of verifiable, scope-bounded user consent for delegated transactions. Mandates give every party in the flow (issuer, network, processor, merchant) a clean primitive to reason about. AP2 is doing for agent payments what OAuth did for API access: replacing shared credentials with scoped, revocable tokens.
How AP2 Works: Mandates and the Trust Chain
The mandate is the protocol's core data structure. Every mandate carries the following fields, signed by the user's authenticator:
- mandate_id: Unique identifier for the mandate.
- agent_id: Verifiable identity of the agent that the mandate authorizes.
- user_id: Identity of the user who issued the mandate.
- scope_amount_max: Maximum amount per transaction (or aggregate cap, depending on the variant).
- scope_merchant: The merchant, merchant category code, or allowlist that constrains where the agent can spend.
- scope_expiry: Absolute timestamp after which the mandate is invalid.
- signature: Cryptographic signature binding the above fields to the user's authenticator.
A typical AP2 flow looks like this:
- User intent. The user tells the agent what they want done, for example, "book me a flight to Tokyo under $1,200."
- Mandate request. The agent constructs a draft mandate with the proposed scope and presents it to the user for signing.
- User signing. The user reviews the mandate inside their authenticator (browser passkey, mobile app, hardware key) and signs it with their FIDO credential.
- Mandate issuance. The signed mandate is recorded as an
issuedevent in the payment platform's mandate ledger. - Agent action. The agent finds a flight, presents the mandate to the merchant or processor, and initiates a payment. This produces a
usedevent with the actual transaction amount. - Lifecycle. The mandate may be
usedagain (if the scope allows),revokedby the user at any time, or naturallyexpiredwhen the expiry timestamp passes. Each transition is an event.
The trust chain works in both directions. Forward, when the agent presents the mandate, the merchant verifies the user's signature and the scope before accepting the charge. Backward, when the platform sees a used event, it can trace it to the originating issued event and reconstruct exactly which user, which agent, and which scope authorized the payment.
This is the property that makes AP2 useful for fraud teams, risk teams, and compliance teams. Every cent that flows through the agent has a verifiable provenance, and every state transition is an event that can be streamed, alerted on, and audited.
AP2, A2A, and MCP: How the Protocols Compose
AP2 does not stand alone. It is the third piece of a stack that also includes A2A (agent-to-agent communication) and MCP (Model Context Protocol). Each protocol owns a different layer of the agent ecosystem, and they were designed to compose.
MCP is the protocol that connects AI agents to tools and data sources. An agent that needs to read a calendar, query a database, or call an internal API does so through an MCP server. MCP standardizes the wire format for tool definitions, tool calls, and tool results, so any MCP-aware agent can plug into any MCP server. If you want a deeper dive, the RisingWave blog post on connecting AI agents to MCP walks through how to expose a streaming database as an MCP server.
A2A is the protocol for agents talking to other agents. When a personal shopping agent needs to negotiate with a merchant's pricing agent, or when a travel agent needs to coordinate with an airline's reservation agent, A2A provides the message format, identity model, and capability discovery. A2A turns agent ecosystems from monolithic apps into composable networks.
AP2 sits on top. Once an agent has discovered another agent or a merchant via A2A, and has gathered the context it needs via MCP, it eventually has to pay. AP2 is the protocol that says: here is the mandate that authorizes this payment, here is the cryptographic proof, here is the scope.
The composition matters because real agent workflows touch all three layers. A booking agent uses MCP to read the user's calendar, A2A to talk to the airline's agent, and AP2 to pay for the ticket. The protocols are deliberately complementary: MCP for tools, A2A for agents, AP2 for money.
For platform builders, this means the data plane has to handle three different event streams: tool calls, agent messages, and mandate events. A streaming database like RisingWave is well suited to this because the same SQL primitives (sources, materialized views, sinks) handle all three uniformly.
AP2 Ecosystem: Who Is Building on It
The single most important fact about AP2 is the breadth of its ecosystem. As of early 2026, more than 60 organizations have signed on, spanning every layer of the payments stack:
- Card networks: Mastercard, JCB.
- Processors and acquirers: Adyen, Worldpay.
- Wallets and PSPs: PayPal, Revolut.
- Crypto and stablecoin rails: Coinbase.
- Merchants and marketplaces: Etsy, Intuit.
- Risk and fraud platforms: Forter.
- CRM and SaaS: Salesforce.
This breadth is what gives AP2 a chance to become a real standard rather than a niche specification. Card networks bring scale, processors bring rails, wallets bring user reach, fraud platforms bring trust, and merchants bring demand. None of them alone could push agent payments into the mainstream, but together they have the surface area to make it a default behavior across commerce.
The donation to the FIDO Alliance in 2026 was a deliberate move to keep the protocol vendor-neutral. AP2 inherits FIDO's identity primitives directly, so a passkey on a user's phone can sign a mandate the same way it signs a login. The network effects compound quickly: a merchant that integrates AP2 gets immediate access to agents from every wallet, processor, and CRM in the partner list.
For a flavor of how a real-time payment platform handles streaming workloads at production scale, Atome, the Southeast Asia BNPL provider, runs real-time risk management and credit decisioning on RisingWave. They cut their feature development cycle from weeks to a single day. The same patterns map directly to AP2: mandate events look a lot like authorization events, and the materialized views that catch fraud in BNPL flows look a lot like the views you would write to monitor agent spending.
Monitoring AP2 Mandate Events with Streaming SQL
Tested on RisingWave v2.8.0.
A payment platform that supports AP2 has to do three things continuously: know which mandates are currently active, track how much each mandate has been used, and catch any attempt to use a mandate that has expired or been revoked. All three are streaming problems. None of them are solvable cleanly with batch jobs because the latency between a rogue agent action and the resulting financial loss can be measured in seconds.
This section walks through a complete streaming SQL pipeline that ingests AP2 mandate events and maintains three materialized views that answer those three questions. Every query and output below was executed on a live RisingWave instance.
Mandate event schema
Mandate lifecycle events all share the same shape: the mandate metadata (id, agent, user, scope), the event type (issued, used, revoked, expired), an optional transaction amount when the event is a used, and a timestamp.
CREATE TABLE aap01_mandate_events (
mandate_id VARCHAR NOT NULL,
agent_id VARCHAR NOT NULL,
user_id VARCHAR NOT NULL,
scope_amount_max DECIMAL,
scope_merchant VARCHAR,
scope_expiry TIMESTAMPTZ,
signature VARCHAR,
event_type VARCHAR NOT NULL,
tx_amount DECIMAL,
event_time TIMESTAMPTZ NOT NULL
);
In production this table would be a Kafka source backed by your AP2 event broker. For this walkthrough we use direct inserts so the example is self-contained.
Sample data: a realistic mandate lifecycle
The dataset below covers five mandates, with each one exercising a different part of the AP2 lifecycle: multiple uses within scope, revocation followed by an attempted use, expiry followed by an attempted use, and short-lived single-use mandates.
INSERT INTO aap01_mandate_events VALUES
('mnd_001', 'agent_alpha', 'user_001', 500.00, 'amazon.com', '2026-05-10 12:00:00+00', 'sig_a1b2c3', 'issued', NULL, '2026-05-01 09:00:00+00'),
('mnd_001', 'agent_alpha', 'user_001', 500.00, 'amazon.com', '2026-05-10 12:00:00+00', 'sig_a1b2c3', 'used', 129.99, '2026-05-02 14:30:00+00'),
('mnd_001', 'agent_alpha', 'user_001', 500.00, 'amazon.com', '2026-05-10 12:00:00+00', 'sig_a1b2c3', 'used', 214.50, '2026-05-04 10:15:00+00'),
('mnd_002', 'agent_beta', 'user_002', 250.00, 'etsy.com', '2026-05-08 18:00:00+00', 'sig_d4e5f6', 'issued', NULL, '2026-05-01 11:00:00+00'),
('mnd_002', 'agent_beta', 'user_002', 250.00, 'etsy.com', '2026-05-08 18:00:00+00', 'sig_d4e5f6', 'used', 87.00, '2026-05-03 16:45:00+00'),
('mnd_002', 'agent_beta', 'user_002', 250.00, 'etsy.com', '2026-05-08 18:00:00+00', 'sig_d4e5f6', 'revoked', NULL, '2026-05-04 08:00:00+00'),
('mnd_002', 'agent_beta', 'user_002', 250.00, 'etsy.com', '2026-05-08 18:00:00+00', 'sig_d4e5f6', 'used', 62.00, '2026-05-05 09:30:00+00'),
('mnd_003', 'agent_alpha', 'user_003', 1000.00, 'travel.expedia.com', '2026-05-15 23:59:00+00', 'sig_g7h8i9', 'issued', NULL, '2026-05-02 08:00:00+00'),
('mnd_003', 'agent_alpha', 'user_003', 1000.00, 'travel.expedia.com', '2026-05-15 23:59:00+00', 'sig_g7h8i9', 'used', 312.40, '2026-05-02 15:20:00+00'),
('mnd_003', 'agent_alpha', 'user_003', 1000.00, 'travel.expedia.com', '2026-05-15 23:59:00+00', 'sig_g7h8i9', 'used', 189.75, '2026-05-03 11:00:00+00'),
('mnd_003', 'agent_alpha', 'user_003', 1000.00, 'travel.expedia.com', '2026-05-15 23:59:00+00', 'sig_g7h8i9', 'used', 420.10, '2026-05-04 14:00:00+00'),
('mnd_004', 'agent_gamma', 'user_004', 75.00, 'doordash.com', '2026-05-03 12:00:00+00', 'sig_j1k2l3', 'issued', NULL, '2026-05-01 07:30:00+00'),
('mnd_004', 'agent_gamma', 'user_004', 75.00, 'doordash.com', '2026-05-03 12:00:00+00', 'sig_j1k2l3', 'used', 34.20, '2026-05-04 13:00:00+00'),
('mnd_005', 'agent_beta', 'user_005', 300.00, 'uber.com', '2026-05-20 23:59:00+00', 'sig_m4n5o6', 'issued', NULL, '2026-05-03 10:00:00+00'),
('mnd_005', 'agent_beta', 'user_005', 300.00, 'uber.com', '2026-05-20 23:59:00+00', 'sig_m4n5o6', 'used', 24.80, '2026-05-04 18:30:00+00');
A few patterns to notice in this dataset:
mnd_002has an attemptedusedevent after arevokedevent. This is exactly what AP2 mandate enforcement is supposed to catch.mnd_004was used at 2026-05-04 13:00, after its scope_expiry of 2026-05-03 12:00. This is an expired-mandate violation.mnd_001,mnd_003, andmnd_005are healthy mandates with uses well within scope.
Materialized view 1: currently active mandates per agent
The first thing any operator wants to see is the live set of mandates that an agent could legitimately use right now. A mandate is active if it was issued, has not been revoked, and has not yet passed its scope_expiry.
CREATE MATERIALIZED VIEW aap01_active_mandates_mv AS
SELECT
m.mandate_id,
m.agent_id,
m.user_id,
m.scope_amount_max,
m.scope_merchant,
m.scope_expiry,
m.event_time AS issued_at
FROM aap01_mandate_events m
WHERE m.event_type = 'issued'
AND m.scope_expiry > NOW()
AND NOT EXISTS (
SELECT 1 FROM aap01_mandate_events r
WHERE r.mandate_id = m.mandate_id
AND r.event_type = 'revoked'
);
RisingWave maintains this view incrementally. When a new issued event arrives, the mandate appears here. When a revoked event arrives, it disappears. When the clock ticks past scope_expiry, it falls out. No batch job, no cron, no stale state.
Verified output:
mandate_id | agent_id | user_id | scope_amount_max | scope_merchant | scope_expiry | issued_at
------------+-------------+----------+------------------+--------------------+---------------------------+---------------------------
mnd_001 | agent_alpha | user_001 | 500.00 | amazon.com | 2026-05-10 12:00:00+00:00 | 2026-05-01 09:00:00+00:00
mnd_003 | agent_alpha | user_003 | 1000.00 | travel.expedia.com | 2026-05-15 23:59:00+00:00 | 2026-05-02 08:00:00+00:00
mnd_005 | agent_beta | user_005 | 300.00 | uber.com | 2026-05-20 23:59:00+00:00 | 2026-05-03 10:00:00+00:00
(3 rows)
Three mandates are currently active. mnd_002 is correctly excluded because it was revoked. mnd_004 is correctly excluded because its scope_expiry is in the past relative to today's date.
Materialized view 2: usage count and total spent per mandate
Once you can see active mandates, you want to know how each one is being used. This view aggregates used events per mandate, producing a usage count, a total spent figure, and the time bounds of activity.
CREATE MATERIALIZED VIEW aap01_mandate_usage_mv AS
SELECT
mandate_id,
agent_id,
user_id,
COUNT(*) AS use_count,
SUM(tx_amount) AS total_spent,
MIN(event_time) AS first_used_at,
MAX(event_time) AS last_used_at
FROM aap01_mandate_events
WHERE event_type = 'used'
GROUP BY mandate_id, agent_id, user_id;
This is the kind of aggregation that batch systems can do hourly. RisingWave does it continuously: every used event updates the corresponding row in this view in real time. A risk dashboard backed by this view always reflects the current spend, not the spend as of the last batch run.
Verified output:
mandate_id | agent_id | user_id | use_count | total_spent | first_used_at | last_used_at
------------+-------------+----------+-----------+-------------+---------------------------+---------------------------
mnd_003 | agent_alpha | user_003 | 3 | 922.25 | 2026-05-02 15:20:00+00:00 | 2026-05-04 14:00:00+00:00
mnd_001 | agent_alpha | user_001 | 2 | 344.49 | 2026-05-02 14:30:00+00:00 | 2026-05-04 10:15:00+00:00
mnd_002 | agent_beta | user_002 | 2 | 149.00 | 2026-05-03 16:45:00+00:00 | 2026-05-05 09:30:00+00:00
mnd_004 | agent_gamma | user_004 | 1 | 34.20 | 2026-05-04 13:00:00+00:00 | 2026-05-04 13:00:00+00:00
mnd_005 | agent_beta | user_005 | 1 | 24.80 | 2026-05-04 18:30:00+00:00 | 2026-05-04 18:30:00+00:00
(5 rows)
The view shows mnd_003 leading with \(922.25 spent across three uses, well within its \)1,000 per-transaction scope. mnd_001 is at \(344.49 across two uses against a \)500 scope. mnd_002 shows two uses totaling \(149.00, but one of those uses (the \)62.00 charge after revocation) is a violation that the next view will surface.
Materialized view 3: violation attempts (expired or revoked mandates)
The third view is the most important one for risk and fraud teams. It identifies every used event that landed against a mandate that was already revoked or already expired at the time of use.
CREATE MATERIALIZED VIEW aap01_expired_mandate_attempts_mv AS
SELECT
u.mandate_id,
u.agent_id,
u.user_id,
u.tx_amount,
u.event_time AS attempted_at,
i.scope_expiry,
CASE
WHEN u.event_time > i.scope_expiry THEN 'expired'
WHEN EXISTS (
SELECT 1 FROM aap01_mandate_events r
WHERE r.mandate_id = u.mandate_id
AND r.event_type = 'revoked'
AND r.event_time <= u.event_time
) THEN 'revoked'
END AS violation_reason
FROM aap01_mandate_events u
JOIN aap01_mandate_events i
ON u.mandate_id = i.mandate_id AND i.event_type = 'issued'
WHERE u.event_type = 'used'
AND (
u.event_time > i.scope_expiry
OR EXISTS (
SELECT 1 FROM aap01_mandate_events r
WHERE r.mandate_id = u.mandate_id
AND r.event_type = 'revoked'
AND r.event_time <= u.event_time
)
);
This view joins each used event to its originating issued event, then checks two conditions: did the use happen after scope_expiry, or was the mandate revoked before the use? Either condition flags the use as a violation, and the violation_reason column tells you which.
Verified output:
mandate_id | agent_id | user_id | tx_amount | attempted_at | scope_expiry | violation_reason
------------+-------------+----------+-----------+---------------------------+---------------------------+------------------
mnd_004 | agent_gamma | user_004 | 34.20 | 2026-05-04 13:00:00+00:00 | 2026-05-03 12:00:00+00:00 | expired
mnd_002 | agent_beta | user_002 | 62.00 | 2026-05-05 09:30:00+00:00 | 2026-05-08 18:00:00+00:00 | revoked
(2 rows)
Two violations surfaced. agent_gamma tried to charge \(34.20 against mnd_004 more than 24 hours after it expired. agent_beta tried to charge \)62.00 against mnd_002 more than 24 hours after it was revoked. In a real platform, both rows would be sinks into an alerting system that pages the on-call risk team, and the underlying payments would be blocked at the processor before settlement.
Why streaming SQL is the right fit for AP2
The pipeline above demonstrates three properties that AP2 monitoring needs and that streaming SQL provides naturally:
- Always-fresh state. The active-mandates view reflects the current truth of which mandates an agent could use right now. There is no batch lag.
- Compositional aggregations. The usage view is a simple
GROUP BYthat incrementally maintains counts and sums. Adding a per-agent or per-merchant cumulative view is one moreGROUP BYaway. - Cross-event correlation. The violation view joins
usedevents toissuedevents and checks forrevokedevents. RisingWave's incremental join engine maintains this correlation as new events arrive, without re-scanning the underlying table.
Three internal links worth following for the operational details: the materialized view documentation explains the incremental computation model, the Kafka source guide covers wiring up an event broker, and the post on connecting AI agents to MCP shows how to expose these views to agents directly so they can self-check their own mandates before transacting.
FAQ
What is the Agent Payments Protocol (AP2)?
AP2 is an open protocol that lets AI agents make payments on a user's behalf with verifiable, scoped authorization. Originally announced by Google in 2025 and donated to the FIDO Alliance in 2026, AP2 introduces mandates, cryptographically signed user-intent artifacts that bind an agent to a specific spending scope. AP2 sits on top of A2A (agent-to-agent) and MCP (Model Context Protocol) and is supported by 60+ partners including Mastercard, PayPal, Adyen, Coinbase, Etsy, Forter, Intuit, JCB, Revolut, Salesforce, and Worldpay.
How does AP2 differ from traditional payment protocols?
Traditional payment protocols authorize a single human-initiated transaction at a time. AP2 authorizes an autonomous agent to transact within a bounded scope (max amount, merchant, expiry) over a period of time. The mandate is cryptographically signed by the user, presented by the agent at payment time, and verified by the merchant or payment service provider before settlement. This shifts the trust boundary from per-transaction approval to per-mandate approval and creates an auditable chain of agent activity.
What is a mandate in AP2?
A mandate is the core primitive of AP2. It is a cryptographically signed artifact that records the user's intent: which agent is authorized, what amount they may spend, at which merchant or category, and until when. Mandates are issued, used (potentially many times), revoked, or expired. Each lifecycle event becomes a verifiable record that payment infrastructure can stream, audit, and reconcile.
How can RisingWave help monitor AP2 mandates in real time?
RisingWave is a streaming database that ingests AP2 mandate events from Kafka or directly via SQL and maintains materialized views that always reflect the latest state: which mandates are currently active, how much each agent has spent under each mandate, and which uses violated scope (expired or revoked). Because the views update incrementally as new events arrive, payment platforms can detect rogue agent behavior in seconds rather than after a nightly batch run.
Conclusion
AP2 is the most credible standard the industry has produced for agent-mediated payments. The mandate is the right primitive: scoped, signed, revocable, and auditable. The composition with A2A and MCP gives agent platform builders a complete stack for tools, agent-to-agent messaging, and money. The 60+ partner ecosystem and the donation to FIDO put AP2 on the path to becoming a default behavior across commerce.
What turns the protocol into a working payment platform, however, is the data plane. Mandate events have to be ingested, joined, aggregated, and audited continuously, with sub-second latency between a rogue agent action and the response. Streaming SQL on RisingWave lets you build that data plane with three materialized views and a handful of joins, instead of a custom Java pipeline and a separate serving database.
Ready to monitor agentic payments in real time? Try RisingWave Cloud free.
Join our Slack community to ask questions and connect with other developers building agentic payment infrastructure.
