{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "What is agentic commerce?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Agentic commerce is a transaction model in which an AI agent acts on behalf of a human user to complete purchases. The user states a goal and a budget. The agent resolves merchants, negotiates terms, and executes payment under a scoped mandate. Frameworks like Stripe Agentic Commerce, Mastercard Agent Pay, Visa Intelligent Commerce, and Google AP2 define the protocols that make this safe and auditable."
}
},
{
"@type": "Question",
"name": "What infrastructure does agentic commerce need?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Agentic commerce needs five infrastructure layers: an agent execution layer, an identity and mandate layer that issues scoped tokens, a payment processor integration layer, a real-time fraud and risk layer, and an audit and observability layer. The data plane must process events with sub-second latency because every layer reads and writes state that downstream layers depend on within the same transaction window."
}
},
{
"@type": "Question",
"name": "Why is real-time data critical for agentic payments?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Agents act in seconds. A mandate issued at T+0 may be redeemed at T+15 seconds, and a fraud signal at T+30 seconds is too late to prevent settlement. Real-time materialized views update incrementally as agent events and payment events arrive, so the risk layer always sees the freshest state. Batch pipelines that refresh every hour cannot keep up with agent decision velocity."
}
},
{
"@type": "Question",
"name": "How does RisingWave fit into an agentic commerce stack?",
"acceptedAnswer": {
"@type": "Answer",
"text": "RisingWave is the streaming database that ingests agent events and payment events from Kafka, joins them with mandate and merchant data, and continuously maintains materialized views for risk scoring, funnel analytics, and audit. It serves these views to downstream services through a PostgreSQL-compatible interface, eliminating the need for separate stream processors, OLAP databases, and serving layers."
}
}
]
}
An AI agent receives a goal: book a flight to Tokyo for under $900 next Tuesday. Within twelve seconds it has resolved three airlines, compared seat maps, asked the user to confirm an upgrade, requested a payment mandate, and authorized the charge with the merchant's processor. The user never opened a browser tab.
Multiply that by ten million agents acting on behalf of ten million users, and you have the load profile of agentic commerce in 2026. Stripe shipped its Agentic Commerce Protocol with OpenAI, Mastercard launched Agent Pay with Agentic Tokens, Visa rolled out Intelligent Commerce, and Google published AP2 (Agent Payments Protocol) as an open standard. Every major rail now has a framework for agents to transact. What is missing in most production stacks is the data plane underneath them.
This article is an end-to-end blueprint for that data plane. We walk through the five architectural layers of agentic commerce, explain why streaming infrastructure beats batch at every layer, and demonstrate the core risk and funnel views with verified streaming SQL on RisingWave v2.8.0. The audience is payment platform engineers, fintech architects, and CTOs who are wiring agentic capabilities into existing payment stacks.
What Is Agentic Commerce?
Agentic commerce is the model in which an autonomous AI agent acts as the buyer instead of a human clicking checkout. The human declares an intent ("buy the cheapest noise canceling headphones under $300") and a scope ("single purchase, US merchants only"). The agent then performs merchant discovery, comparison, negotiation, and payment without further input.
Three properties separate agentic commerce from traditional checkout:
- The buyer is software. The agent is identified by a cryptographic key, not a session cookie. Identity propagates from the agent runtime through the merchant API into the payment rail.
- The mandate is scoped. Instead of handing over a card on file, the user issues a Shared Payment Token (Stripe SPT), an Agentic Token (Mastercard), or a signed payment mandate (AP2). The token encodes amount limits, merchant categories, and an expiration window.
- Velocity is non-human. A human checks out two or three times a day. An agent fleet may attempt thousands of payments per second. The fraud profile shifts from per-card heuristics to per-mandate and per-agent behavior.
These properties mean the underlying infrastructure has to look different from a traditional payment stack. The five layers below are what we have seen converge across early production deployments.
The Five Layers of Agentic Commerce Architecture
Every agentic commerce stack we have reviewed in 2026 decomposes into the same five layers. Each layer has its own data infrastructure requirements.
flowchart LR
A[Agent Layer<br/>LLM runtime, planner, tool calls] --> B[Identity & Mandate Layer<br/>SPT / Agentic Token / AP2 mandate]
B --> C[Payment Processor Layer<br/>Stripe / Mastercard / Visa / network]
C --> D[Fraud & Risk Layer<br/>real-time scoring, mandate enforcement]
D --> E[Audit & Observability Layer<br/>event log, lineage, compliance]
A -. events .-> F[(Streaming Data Plane<br/>RisingWave)]
B -. events .-> F
C -. events .-> F
D -. signals .-> F
F -. risk decisions .-> D
F -. dashboards & audit .-> E
1. Agent layer
The agent layer is where the LLM runtime, the planner, and the tool-calling loop live. Each agent emits structured events: intent_declared, merchant_resolved, cart_built, payment_initiated, tool_call_failed. These are the equivalent of clickstream events in classic e-commerce, but they describe a deterministic chain of reasoning steps rather than mouse movements.
Data infrastructure needed. A high-throughput event stream (Kafka, Kinesis, or Redpanda) with strict ordering per agent_id. Schemas should be versioned because new tool types arrive every week. The stream must support replay so the audit layer can reconstruct any agent run.
2. Identity and mandate layer
This layer issues the cryptographic mandate that authorizes a payment. Stripe's SPTs, Mastercard's Agentic Tokens, and AP2's signed mandates all share the same shape: a token bound to (user_id, agent_id, scope, max_amount, expiration). The mandate is the trust boundary between the user and the agent.
Data infrastructure needed. A low-latency key-value store for active mandate lookup, plus a streaming join against the payment stream to enforce scope at redemption time. The enforcement check itself must be a streaming operation because mandates can be revoked while a payment is in flight.
3. Payment processor layer
This is where the network rails do their work: authorization, network tokenization, settlement. Whether the back end is Stripe, Adyen, an issuer-direct integration, or a card network, the data interface is the same: a stream of payment lifecycle events (authorized, captured, settled, declined, refunded, chargeback).
Data infrastructure needed. Change data capture (CDC) from the processor's database into your streaming layer, or webhook ingestion into a Kafka topic. Either way, you need exactly-once semantics because duplicating a settled event corrupts your books.
4. Fraud and risk layer
Agent fraud looks different from human fraud. Agents do not fat-finger their addresses or use stolen cards in unfamiliar countries. Instead, they are exploited through prompt injection, replay attacks against mandates, and recursive agent loops that drain budgets through repeated micro-transactions. The risk layer needs signals that humans never produced: per-agent payment velocity, mandate-utilization ratios, and tool-call entropy.
Data infrastructure needed. A streaming database that joins agent events with payment events in real time and exposes the resulting risk scores back to the processor decision service. This is the layer where streaming SQL pays its largest dividend: rule logic written once, updated incrementally, served at sub-second latency. Atome runs exactly this kind of streaming risk layer for BNPL underwriting on RisingWave, processing approval decisions across millions of borrowers without standing up a separate Flink cluster.
5. Audit and observability layer
Every agent decision and every payment event must be reconstructible for compliance, dispute resolution, and model training. Regulators are already asking how agentic systems make purchase decisions, and "the LLM said so" is not a valid answer.
Data infrastructure needed. An immutable event log, ideally landed in Apache Iceberg for cheap retention; lineage tracking from intent through settlement; dashboards for fraud analysts and finance teams. SHOPLINE built a similar pattern for their global e-commerce platform, using RisingWave to power real-time order analytics and operational dashboards across millions of merchants.
Why Streaming Beats Batch for Agentic Payments
A common temptation is to bolt agentic features onto an existing batch warehouse: dump agent events nightly, score them in Spark, push results back to the production database in the morning. This pattern fails for agentic commerce in three concrete ways.
Decision latency. A mandate may live for sixty seconds. The risk layer must score the redemption attempt before the processor authorizes it. A batch pipeline that refreshes hourly is two orders of magnitude too slow.
Mandate enforcement is stateful. A mandate with a $200 max can be partially redeemed across multiple payments. The remaining balance has to be tracked across events, not recomputed from scratch on every authorization request. Streaming materialized views maintain this state incrementally; batch jobs reload it from disk every run.
Audit is continuous. Regulators expect agentic transactions to be auditable in near real time. Building a fresh audit table once a day means a compromised agent can cause hours of damage before anyone notices. A streaming log captures every event as it happens.
A streaming database like RisingWave collapses the stream processor, the OLAP serving layer, and the materialized view server into one system. The risk layer, the funnel analytics, and the audit dashboards all read from the same continuously updated state. Compared to stitching together Flink, ksqlDB, and Druid, the operational footprint is much smaller, and the developer interface is plain SQL.
Building the Real-Time Risk Layer with SQL
Below we build the core of the data plane: agent event ingest, payment ingest, and two materialized views that show per-agent activity and the intent-to-settlement funnel. Every query is verified on RisingWave v2.8.0 against localhost:4566.
Schemas: agent events and payments
CREATE TABLE aap02_agent_events (
event_id VARCHAR PRIMARY KEY,
agent_id VARCHAR NOT NULL,
user_id VARCHAR NOT NULL,
event_type VARCHAR NOT NULL,
payload JSONB,
event_time TIMESTAMPTZ NOT NULL
);
CREATE TABLE aap02_payments (
payment_id VARCHAR PRIMARY KEY,
agent_id VARCHAR NOT NULL,
user_id VARCHAR NOT NULL,
mandate_id VARCHAR NOT NULL,
merchant VARCHAR NOT NULL,
amount DECIMAL NOT NULL,
status VARCHAR NOT NULL,
event_time TIMESTAMPTZ NOT NULL
);
In production, both tables would be replaced by Kafka sources wired to your agent runtime and your payment processor's webhook fan-out.
Sample data: four agents, three flows
We seed the tables with three realistic agentic flows: a one-shot purchase by agent_alpha, a recurring weekly grocery order by agent_beta (three weeks of redemptions against a single recurring mandate), a hotel booking by agent_gamma that gets stuck at authorized, and a duplicate-retry pattern from agent_delta where the second attempt is correctly declined.
INSERT INTO aap02_agent_events VALUES
('evt_001', 'agent_alpha', 'user_42', 'intent_declared', '{"goal": "buy noise canceling headphones under 300", "budget": 300}', '2026-05-06 09:00:00+00'),
('evt_002', 'agent_alpha', 'user_42', 'mandate_issued', '{"mandate_id": "mnd_001", "scope": "single_purchase", "max_amount": 300}', '2026-05-06 09:00:30+00'),
('evt_003', 'agent_alpha', 'user_42', 'merchant_resolved', '{"merchant": "audio_store", "product": "XM5", "price": 279.00}', '2026-05-06 09:01:00+00'),
('evt_004', 'agent_alpha', 'user_42', 'payment_initiated', '{"payment_id": "pay_001", "amount": 279.00}', '2026-05-06 09:01:15+00'),
('evt_005', 'agent_beta', 'user_77', 'intent_declared', '{"goal": "weekly grocery order", "budget": 150}', '2026-05-06 10:00:00+00'),
('evt_006', 'agent_beta', 'user_77', 'mandate_issued', '{"mandate_id": "mnd_002", "scope": "recurring_weekly", "max_amount": 200}', '2026-05-06 10:00:20+00'),
('evt_007', 'agent_beta', 'user_77', 'payment_initiated', '{"payment_id": "pay_002", "amount": 142.50}', '2026-05-06 10:05:00+00'),
('evt_008', 'agent_gamma', 'user_99', 'intent_declared', '{"goal": "book hotel in tokyo", "budget": 800}', '2026-05-06 11:30:00+00'),
('evt_009', 'agent_gamma', 'user_99', 'mandate_issued', '{"mandate_id": "mnd_003", "scope": "single_purchase", "max_amount": 800}', '2026-05-06 11:30:15+00'),
('evt_010', 'agent_gamma', 'user_99', 'payment_initiated', '{"payment_id": "pay_003", "amount": 750.00}', '2026-05-06 11:35:00+00'),
('evt_011', 'agent_delta', 'user_11', 'intent_declared', '{"goal": "buy gpu for workstation", "budget": 2500}', '2026-05-06 12:00:00+00'),
('evt_012', 'agent_delta', 'user_11', 'mandate_issued', '{"mandate_id": "mnd_004", "scope": "single_purchase", "max_amount": 2500}', '2026-05-06 12:00:30+00'),
('evt_013', 'agent_delta', 'user_11', 'payment_initiated', '{"payment_id": "pay_004", "amount": 2399.00}', '2026-05-06 12:01:00+00'),
('evt_014', 'agent_delta', 'user_11', 'payment_initiated', '{"payment_id": "pay_005", "amount": 2399.00}', '2026-05-06 12:01:30+00'),
('evt_015', 'agent_beta', 'user_77', 'intent_declared', '{"goal": "weekly grocery order", "budget": 150}', '2026-05-13 10:00:00+00'),
('evt_016', 'agent_beta', 'user_77', 'mandate_issued', '{"mandate_id": "mnd_002", "scope": "recurring_weekly", "max_amount": 200}', '2026-05-13 10:00:20+00'),
('evt_017', 'agent_beta', 'user_77', 'payment_initiated', '{"payment_id": "pay_007", "amount": 138.20}', '2026-05-13 10:04:30+00'),
('evt_018', 'agent_beta', 'user_77', 'intent_declared', '{"goal": "weekly grocery order", "budget": 150}', '2026-05-20 10:00:00+00'),
('evt_019', 'agent_beta', 'user_77', 'mandate_issued', '{"mandate_id": "mnd_002", "scope": "recurring_weekly", "max_amount": 200}', '2026-05-20 10:00:20+00'),
('evt_020', 'agent_beta', 'user_77', 'payment_initiated', '{"payment_id": "pay_008", "amount": 155.10}', '2026-05-20 10:04:30+00'),
('evt_021', 'agent_alpha', 'user_42', 'intent_declared', '{"goal": "buy replacement earpads", "budget": 60}', '2026-05-06 09:25:00+00'),
('evt_022', 'agent_alpha', 'user_42', 'mandate_issued', '{"mandate_id": "mnd_005", "scope": "single_purchase", "max_amount": 60}', '2026-05-06 09:25:20+00'),
('evt_023', 'agent_alpha', 'user_42', 'payment_initiated', '{"payment_id": "pay_006", "amount": 49.00}', '2026-05-06 09:29:30+00');
INSERT INTO aap02_payments VALUES
('pay_001', 'agent_alpha', 'user_42', 'mnd_001', 'audio_store', 279.00, 'settled', '2026-05-06 09:01:30+00'),
('pay_002', 'agent_beta', 'user_77', 'mnd_002', 'fresh_grocer', 142.50, 'settled', '2026-05-06 10:05:30+00'),
('pay_003', 'agent_gamma', 'user_99', 'mnd_003', 'tokyo_hotels', 750.00, 'authorized', '2026-05-06 11:35:30+00'),
('pay_004', 'agent_delta', 'user_11', 'mnd_004', 'gpu_warehouse', 2399.00, 'settled', '2026-05-06 12:01:15+00'),
('pay_005', 'agent_delta', 'user_11', 'mnd_004', 'gpu_warehouse', 2399.00, 'declined', '2026-05-06 12:01:45+00'),
('pay_006', 'agent_alpha', 'user_42', 'mnd_005', 'audio_store', 49.00, 'settled', '2026-05-06 09:30:00+00'),
('pay_007', 'agent_beta', 'user_77', 'mnd_002', 'fresh_grocer', 138.20, 'settled', '2026-05-13 10:05:00+00'),
('pay_008', 'agent_beta', 'user_77', 'mnd_002', 'fresh_grocer', 155.10, 'settled', '2026-05-20 10:05:00+00');
Per-agent activity view
The first materialized view consolidates everything we know about each agent: how many events it produced, how many distinct event types it cycled through, how many payments it initiated, the dollar volume, and the settled-vs-declined ratio. CTEs aggregate each side independently before joining, which avoids the double-counting trap of joining raw events to payments.
CREATE MATERIALIZED VIEW aap02_per_agent_activity AS
WITH event_stats AS (
SELECT
agent_id,
user_id,
COUNT(*) AS event_count,
COUNT(DISTINCT event_type) AS distinct_event_types,
MIN(event_time) AS first_event,
MAX(event_time) AS last_event
FROM aap02_agent_events
GROUP BY agent_id, user_id
),
payment_stats AS (
SELECT
agent_id,
user_id,
COUNT(*) AS payment_count,
SUM(amount) AS total_payment_amount,
SUM(CASE WHEN status = 'settled' THEN 1 ELSE 0 END) AS settled_payments,
SUM(CASE WHEN status = 'declined' THEN 1 ELSE 0 END) AS declined_payments
FROM aap02_payments
GROUP BY agent_id, user_id
)
SELECT
e.agent_id,
e.user_id,
e.event_count,
e.distinct_event_types,
COALESCE(p.payment_count, 0) AS payment_count,
COALESCE(p.total_payment_amount, 0) AS total_payment_amount,
COALESCE(p.settled_payments, 0) AS settled_payments,
COALESCE(p.declined_payments, 0) AS declined_payments,
e.first_event,
e.last_event
FROM event_stats e
LEFT JOIN payment_stats p
ON e.agent_id = p.agent_id AND e.user_id = p.user_id;
This view is the per-agent fact table that the risk layer reads. RisingWave maintains it incrementally through incremental view maintenance, so each new event updates the relevant row without rescanning the source tables.
Verified output
agent_id | user_id | event_count | distinct_event_types | payment_count | total_payment_amount | settled_payments | declined_payments | first_event | last_event
-------------+---------+-------------+----------------------+---------------+----------------------+------------------+-------------------+---------------------------+---------------------------
agent_alpha | user_42 | 7 | 4 | 2 | 328.00 | 2 | 0 | 2026-05-06 09:00:00+00:00 | 2026-05-06 09:29:30+00:00
agent_beta | user_77 | 9 | 3 | 3 | 435.80 | 3 | 0 | 2026-05-06 10:00:00+00:00 | 2026-05-20 10:04:30+00:00
agent_delta | user_11 | 4 | 3 | 2 | 4798.00 | 1 | 1 | 2026-05-06 12:00:00+00:00 | 2026-05-06 12:01:30+00:00
agent_gamma | user_99 | 3 | 3 | 1 | 750.00 | 0 | 0 | 2026-05-06 11:30:00+00:00 | 2026-05-06 11:35:00+00:00
(4 rows)
Three signals jump out immediately. agent_delta shows a 50% decline rate on a single mandate, the classic agentic retry-loop signature. agent_gamma has one payment that never moved past authorized, suggesting a stuck settlement that needs investigation. agent_beta shows three settled payments against three distinct intent cycles, the expected pattern for a recurring weekly mandate.
Intent-to-settlement funnel view
The funnel view tracks the canonical agentic conversion stages: intent declared → mandate issued → payment initiated → payment settled. The conversion ratio between any two stages is a direct quality metric for the agent and a fraud signal when ratios drift far from baseline.
CREATE MATERIALIZED VIEW aap02_payment_funnel AS
WITH event_counts AS (
SELECT
agent_id,
SUM(CASE WHEN event_type = 'intent_declared' THEN 1 ELSE 0 END) AS intents,
SUM(CASE WHEN event_type = 'mandate_issued' THEN 1 ELSE 0 END) AS mandates,
SUM(CASE WHEN event_type = 'payment_initiated' THEN 1 ELSE 0 END) AS payments_initiated
FROM aap02_agent_events
GROUP BY agent_id
),
settled_counts AS (
SELECT
agent_id,
COUNT(*) AS payments_settled
FROM aap02_payments
WHERE status = 'settled'
GROUP BY agent_id
)
SELECT
e.agent_id,
e.intents,
e.mandates,
e.payments_initiated,
COALESCE(s.payments_settled, 0) AS payments_settled,
ROUND(
100.0 * COALESCE(s.payments_settled, 0) / NULLIF(e.payments_initiated, 0),
1
) AS initiated_to_settled_pct
FROM event_counts e
LEFT JOIN settled_counts s ON e.agent_id = s.agent_id;
Verified output
agent_id | intents | mandates | payments_initiated | payments_settled | initiated_to_settled_pct
-------------+---------+----------+--------------------+------------------+--------------------------
agent_alpha | 2 | 2 | 2 | 2 | 100.0
agent_beta | 3 | 3 | 3 | 3 | 100.0
agent_delta | 1 | 1 | 2 | 1 | 50.0
agent_gamma | 1 | 1 | 1 | 0 | 0
(4 rows)
The funnel makes the agent_delta retry pattern unambiguous: 1 intent, 1 mandate, but 2 payment_initiated events. The processor correctly declined the duplicate. In a fraud monitoring console, you would alert any agent where payments_initiated > mandates over a rolling window. Likewise, agent_gamma with 0% initiated-to-settled is the canary for a payment that is hanging at the authorization step.
Why these views are the foundation
These two materialized views are deliberately small. They give you per-agent state and per-funnel-stage counts, which is enough to drive a real-time risk console, a finance dashboard, and a compliance audit log. Layering richer signals on top is straightforward in SQL: mandate utilization (settled amount divided by max_amount), velocity (settled payments per minute), or composite risk scores in the style of the streaming SQL fraud scoring approach.
Reference Architecture: Putting It Together
The diagram below shows how the five layers connect through a streaming data plane in a complete agentic commerce stack. Every arrow is an event stream, and every materialized view is recomputed incrementally as those streams update.
flowchart TB
subgraph Agents
A1[Agent runtime A]
A2[Agent runtime B]
A3[Agent runtime N]
end
subgraph Mandates
M[Mandate service<br/>SPT / Agentic Token / AP2]
end
subgraph Processor
P[Stripe / Mastercard / Visa]
end
subgraph Streams
K1[(Kafka: agent_events)]
K2[(Kafka: mandates)]
K3[(Kafka: payments)]
end
subgraph DataPlane[RisingWave Streaming Database]
MV1[per-agent activity MV]
MV2[payment funnel MV]
MV3[mandate utilization MV]
MV4[risk score MV]
end
subgraph Consumers
R[Risk decision API]
D[Analyst dashboard]
I[(Iceberg audit log)]
end
A1 --> K1
A2 --> K1
A3 --> K1
M --> K2
P --> K3
K1 --> DataPlane
K2 --> DataPlane
K3 --> DataPlane
MV1 --> MV4
MV2 --> MV4
MV3 --> MV4
MV4 --> R
MV1 --> D
MV2 --> D
DataPlane --> I
R -. authorize / decline .-> P
A walkthrough of one transaction:
- The agent emits
intent_declared,merchant_resolved, andpayment_initiatedto theagent_eventstopic. - The mandate service issues a Shared Payment Token, publishes a
mandate_issuedevent to themandatestopic, and exposes the token to the agent. - The agent presents the token at the merchant. The merchant calls the processor. The processor publishes
authorized, thensettledto thepaymentstopic. - RisingWave consumes all three streams and continuously updates
per_agent_activity,payment_funnel,mandate_utilization, and the compositerisk_scoreview. - The processor's decision API queries the
risk_scoreview via PostgreSQL wire protocol before authorizing the next payment for the same agent. If the score crosses a threshold, the API declines the transaction. - The analyst dashboard reads the same views for fraud investigation and finance reporting.
- The full event log lands in Iceberg for long-term audit.
The key property of this architecture is that the same materialized views serve both the operational decision path (millisecond latency, used by the processor) and the analytical path (dashboards, audit). There is no separate ETL into a data warehouse, no nightly snapshot of state, and no copy of the truth that lags by hours.
FAQ
What is agentic commerce?
Agentic commerce is a transaction model in which an AI agent acts on behalf of a human to complete purchases under a scoped mandate. The user states a goal and a budget; the agent resolves merchants, builds the cart, and executes payment using a token issued specifically for that transaction. Frameworks like Stripe Agentic Commerce, Mastercard Agent Pay, Visa Intelligent Commerce, and Google AP2 define the protocols that make this safe and auditable.
What infrastructure does agentic commerce need?
Five layers: an agent execution layer (LLM runtime and tool-call loop), an identity and mandate layer (issues scoped tokens like SPTs or Agentic Tokens), a payment processor integration layer (talks to Stripe, Mastercard, Visa, or your issuer), a real-time fraud and risk layer, and an audit and observability layer. Underneath all five sits a streaming data plane that ingests events from each layer and continuously maintains the joined views that downstream services depend on.
Why is real-time data critical for agentic payments?
Agents operate at non-human speeds: a mandate may live for sixty seconds, and a payment may settle within five seconds of intent. Risk decisions, mandate enforcement, and audit logging all need to read state that is at most milliseconds old. Batch pipelines that refresh hourly cannot keep up; by the time they run, the agent has already moved money. Streaming materialized views update incrementally as each event arrives, keeping the data plane synchronized with agent decision velocity.
How does RisingWave fit into an agentic commerce stack?
RisingWave is the streaming database that sits between your event streams (Kafka, Kinesis, Redpanda) and your downstream consumers (risk APIs, dashboards, audit log). It ingests agent events, mandate events, and payment events, joins them in real time, and serves continuously updated materialized views through a PostgreSQL-compatible interface. That eliminates the need to run a separate stream processor (Flink), an OLAP database (Druid, Pinot), and a serving layer. Customers like Atome and SHOPLINE already use this pattern for real-time risk and operational analytics in production.
Conclusion
Agentic commerce is not a new payment rail. It is a new buyer profile that puts pressure on every layer of the existing stack. The agent layer produces orders of magnitude more events than human checkouts. The mandate layer demands sub-second enforcement. The fraud layer needs new signals that did not exist for human users. The audit layer faces new regulatory expectations.
The connecting tissue across all five layers is the data plane. A streaming database collapses the stream processor, the OLAP store, and the serving layer into one system that runs on plain SQL. Every view you build against your agent and payment streams is incrementally maintained, queryable through the standard Postgres protocol, and ready to feed both the operational decision path and the analytics path.
If you are wiring agentic capabilities into an existing payment stack, start with the two views in this article: per-agent activity and the intent-to-settlement funnel. They give you the operational visibility you need to safely roll out agentic checkout, and they are the substrate on which richer mandate-utilization and risk-scoring views will sit.
All SQL in this article runs on RisingWave v2.8.0 against localhost:4566. You can replicate it on your own cluster by following the quickstart guide.
Ready to build the data layer for agentic commerce? Try RisingWave Cloud free →
Join our Slack community to discuss agentic payment architectures with other engineers building this stack today.
