{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is the difference between Mastercard Agent Pay, Visa Intelligent Commerce, and Stripe Agentic Commerce?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Mastercard Agent Pay is a network-level framework built on Agentic Tokens and Verifiable Intent artifacts that prove an agent acted within user-granted authority. Visa Intelligent Commerce, anchored by the Trusted Agent Protocol (TAP), is Visa's parallel network framework that lets agents present cryptographic credentials to merchants. Stripe Agentic Commerce Suite is a developer-first platform built around Shared Payment Tokens (SPTs) and the Stripe Agent Toolkit for Python and TypeScript, designed for direct embedding inside agent codebases."
      }
    },
    {
      "@type": "Question",
      "name": "Are Mastercard Agent Pay, Visa Intelligent Commerce, and Stripe Agentic Commerce interoperable?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Partially. The Agent Payments Protocol (AP2), originally proposed by Google and donated to the FIDO Alliance in 2026, defines a vendor-neutral mandate format. As of April 2026, payment service providers can emit AP2 Mandates that Mastercard accepts as Verifiable Intent. Stripe and Visa have both signed onto AP2 as well, so a single agent can in principle present a mandate that any of the three frameworks can validate. The internal token formats remain framework-specific."
      }
    },
    {
      "@type": "Question",
      "name": "What are Stripe Shared Payment Tokens (SPTs)?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Shared Payment Tokens are short-lived, single-merchant payment credentials that Stripe issues to an agent on behalf of a user. Each SPT is scoped to one seller, time-bounded with an expiry, capped to a maximum amount, and emits a fully observable lifecycle of issued, used, expired, or revoked events. SPTs let an agent transact at a specific merchant without ever holding a long-lived card number."
      }
    },
    {
      "@type": "Question",
      "name": "What data infrastructure do agentic payment frameworks require?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "All three frameworks generate high-volume event streams covering token issuance, authorization, capture, decline, and revocation. Building on top of them requires a system that can ingest these events with low latency, join them with user and risk context, maintain real-time aggregations for fraud and quota enforcement, and persist an immutable audit trail. A streaming SQL database such as RisingWave provides this layer by maintaining incrementally updated materialized views over the live event stream and sinking the same stream to an Apache Iceberg lakehouse for long-term audit."
      }
    }
  ]
}

Mastercard Agent Pay vs Visa Intelligent Commerce vs Stripe Agentic Commerce: 2026 Comparison

In 2026, AI agents do not just answer questions. They book flights, reorder supplies, negotiate with vendors, and increasingly, they pay. Every major payment network has now released a framework for agentic commerce, and three stand out in production: Mastercard Agent Pay, Visa Intelligent Commerce, and the Stripe Agentic Commerce Suite. Each one tries to solve the same hard problem from a different angle: how do you let a non-human entity move money on behalf of a human, without losing the security, observability, and accountability that human-driven commerce takes for granted?

This article is a side-by-side comparison of the three frameworks. We look at the token primitives each one introduces, the security model behind those primitives, the ecosystems already shipping with them, and the developer experience of integrating them into a real product. We do not pick a winner. The right framework depends on whether you are a marketplace, an issuer, a software platform, or all three.

We do, however, end with the part of the stack that is the same across all three: the data infrastructure required to make any of these frameworks observable, governable, and trustworthy in production. That is where streaming SQL comes in.

A Brief History of Agentic Payments

The agentic commerce stack came together quickly between 2024 and 2026.

• 2024: Anthropic published the Model Context Protocol (MCP), giving agents a standard way to call tools. Payments was an obvious tool to expose, but no payment-specific protocol existed yet.
• April 2025: Google announced the Agent Payments Protocol (AP2) as a vendor-neutral specification for "Mandates," cryptographically signed artifacts that prove a user authorized an agent to spend within specific limits.
• May 2025: Visa announced Visa Intelligent Commerce and the Trusted Agent Protocol (TAP), defining how agents identify themselves to merchants and how merchants verify them.
• 2025 (later): Mastercard launched Agent Pay with two new primitives: Agentic Tokens (a token type extending EMVCo network tokenization to agent-initiated flows) and Verifiable Intent (the artifact format that travels with each agentic transaction).
• 2026: Stripe released the Agentic Commerce Suite, introducing Shared Payment Tokens (SPTs) and making the Stripe Link wallet directly usable by agents. URBN (Anthropologie, Free People, Urban Outfitters), Etsy, Coach, Kate Spade, Ashley Furniture, Revolve, Halara, and Abt all came online during the launch quarter.
• April 2026: Google donated AP2 to the FIDO Alliance, making the protocol community-governed. By the same month, more than 60 partners (including Mastercard, Visa, Stripe, Adyen, PayPal, and Coinbase) were aligned on AP2, and Mastercard announced that PSPs could emit AP2 Mandates as Verifiable Intent artifacts that Mastercard's network accepts directly.

In short: by mid-2026, the field has consolidated around three production frameworks plus one shared protocol layer. The interesting differences are now in implementation detail and ecosystem fit.

Mastercard Agent Pay: Agentic Tokens and Verifiable Intent

Mastercard Agent Pay is a network-level framework, meaning it works at the same layer as EMVCo tokenization and 3-D Secure. It introduces two primitives.

Agentic Tokens are a new token type designed specifically for agent-initiated payments. Like an existing network token, an Agentic Token replaces the underlying card credential. Unlike an existing network token, it carries metadata identifying the originating agent, the user who authorized it, and the policy under which it was minted. The token is bound to a specific agent identity, which means a stolen Agentic Token cannot be silently reused by a different agent without detection.

Verifiable Intent is the artifact that accompanies a transaction. It is a structured, cryptographically signed object that captures what the user wanted the agent to do. In a typical flow, the user grants the agent authority to "buy a return flight to Paris under $800 between June 5 and June 8." That intent is hashed, signed, and stored. When the agent eventually transacts, the Verifiable Intent travels alongside the authorization and merchants can validate that the transaction falls within the original scope.

What stands out:

• Network-native: Issuers and acquirers see Agent Pay flows in their existing rails. There is no separate processor to integrate.
• Strong intent binding: Verifiable Intent is the most explicit "what did the user actually agree to?" artifact among the three frameworks.
• AP2 acceptance: As of April 2026, PSPs can mint AP2 Mandates and Mastercard's network treats them as valid Verifiable Intent. This is the clearest interoperability guarantee shipped so far.

Where it is heavier:

• Network framework, not a developer SDK. To build directly on Agent Pay you typically work through an issuer, processor, or PSP.
• Best fit for issuers and large merchants who already operate in network rails.

Visa Intelligent Commerce: Trusted Agent Protocol

Visa announced Intelligent Commerce in May 2025 as its parallel framework. The centerpiece is the Trusted Agent Protocol (TAP), which defines how agents present credentials to merchants and how merchants verify them.

TAP works by issuing each agent a cryptographic identity. When the agent transacts, it presents a TAP credential alongside the payment. The merchant uses Visa's verification endpoints to confirm the agent's identity and the user's authorization scope. Visa positions TAP as a complement to its existing tokenization service, not a replacement.

Visa Intelligent Commerce reuses much of Visa's existing fraud and risk infrastructure. Visa Advanced Authorization, Visa Risk Manager, and Visa Token Service all extend their signal coverage to include agentic indicators (the agent identity, the agentic token type, the presence or absence of a TAP credential).

What stands out:

• Familiar to Visa-integrated stacks: If your acquirer already supports Visa Token Service, layering on TAP is incremental rather than green-field.
• Risk reuse: Established Visa fraud tooling extends to agentic flows from day one.
• Multi-network ambition: TAP is designed to be issuer-agnostic at the protocol level.

Where it is less mature:

• Public technical documentation is thinner than the other two frameworks as of mid-2026.
• The agent ecosystem story is still developing; Visa has named partners but the visible production deployments lag Stripe's.

Stripe Agentic Commerce Suite: Shared Payment Tokens (SPT)

Stripe takes a developer-first approach. The Agentic Commerce Suite is a layer on top of the existing Stripe API, accessed through the Stripe Agent Toolkit (Python and TypeScript). The toolkit ships drop-in tools for major agent frameworks, so integrating payments into a LangChain, LangGraph, OpenAI, or Anthropic agent reduces to a few lines of code.

The standout primitive is the Shared Payment Token (SPT):

• Scoped to one seller: An SPT is valid only at the specific merchant identity it was issued for. An SPT for Etsy cannot be used at Coach.
• Time-bounded: Each SPT carries an expiry. After it expires the token is dead at the network layer.
• Amount-bounded: SPTs include a maximum amount. Authorization beyond that amount is refused.
• Observable lifecycle: Each SPT emits structured events for issued, used, expired, and revoked. These events stream out of Stripe in the same way as standard payment events.

Stripe also extended the Stripe Link wallet so it can be invoked directly by an agent (April 2026). This means a checkout flow that previously required a human click on the Link button can now be completed end to end by an agent that holds the right SPT and Link grant.

The launch ecosystem is the strongest of the three. URBN (Anthropologie, Free People, Urban Outfitters), Etsy, Coach, Kate Spade, Ashley Furniture, Revolve, Halara, and Abt all went live with agentic checkout during 2026.

What stands out:

• Best developer experience: The Stripe Agent Toolkit is opinionated and ships with examples for every major agent framework.
• Strong primitive choice: SPTs are simple to reason about (one merchant, one window, one cap) and cleanly mapped to events.
• Marketplace-friendly: Connect, Stripe's marketplace product, integrates SPTs natively, which is why you see early adoption skewed toward marketplaces and DTC platforms.

Where it is narrower:

• Stripe Agentic Commerce sits on Stripe rails. If your stack does not already use Stripe, adopting it means adopting Stripe broadly.
• The framework is processor-level, not network-level. SPTs ride on top of underlying network tokens (Visa, Mastercard, AmEx) rather than replacing them.

Side-by-Side Comparison Table

The differences between the three frameworks are easier to see when laid out together.

The pattern here is not that one framework is better. It is that each one solves the problem at a different layer of the stack. Mastercard and Visa operate at the network layer, where they can compel issuers and acquirers to participate. Stripe operates at the processor layer, where it can move fast on developer experience and ecosystem onboarding. AP2 sits across all of them as a shared mandate format.

Common Data Infrastructure Requirements

Whichever framework (or combination of frameworks) you choose, the data infrastructure problem looks remarkably similar. All three produce high-volume event streams, all three need real-time risk evaluation, and all three need an immutable audit trail to satisfy compliance and dispute resolution.

The shared requirements:

1. Low-latency event ingestion. Token lifecycle events (issued, used, expired, revoked), authorization events, and merchant capture events arrive constantly. Batch ETL is too slow for risk and quota use cases that need to act within the authorization window.
2. Continuous joins with user and policy context. A raw payment event is not enough. To decide whether a charge is in policy, you need to join it with the user's spending mandate, the agent's identity, and the seller's eligibility. These joins must update incrementally as new events arrive.
3. Stateful aggregations for risk and quotas. Per-user spend over rolling windows. Per-agent decline rates. Per-merchant velocity. Cross-framework anomalies (a user transacting through three different frameworks in five minutes is unusual). All of these are streaming aggregations.
4. Immutable audit trail. Verifiable Intent artifacts, TAP credentials, and SPT lifecycle records all need to be retained for regulatory review and dispute defense. The most cost-effective long-term store is a lakehouse format like Apache Iceberg.
5. Cross-framework normalization. If you use more than one framework (most non-trivial deployments will), you need a unified event schema so a single dashboard, alert, or fraud rule covers all of them.
6. Fast point lookups. Customer support, dispute investigation, and compliance review all want sub-second answers to questions like "show me every event for this token."

The standard pattern in 2026 is a streaming SQL layer that ingests payment events from Stripe webhooks, Mastercard message queues, and Visa event APIs, normalizes them into a unified schema, maintains real-time aggregations as materialized views, and sinks the same events to Iceberg for long-term audit. The streaming SQL layer is what closes the loop between raw payment events and the operational decisions a platform actually needs to make.

Monitoring Agentic Payments Across Frameworks with Streaming SQL

Here is a concrete example of the unification pattern in RisingWave. We define a single event table that absorbs events from all three frameworks. Each event carries a framework tag so we can compare them side by side.

CREATE TABLE aap03_agent_payment_events (
    event_id BIGINT,
    framework VARCHAR,         -- 'mastercard' | 'visa' | 'stripe'
    token_id VARCHAR,
    agent_id VARCHAR,
    user_id VARCHAR,
    amount NUMERIC,
    status VARCHAR,            -- 'authorized' | 'completed' | 'declined'
    event_time TIMESTAMPTZ
);

In production this table would be backed by sources reading from Kafka, Stripe webhooks, or a vendor-specific bus. For this example, we seed it with 15 representative events covering all three frameworks.

Once events flow in, we build a per-framework rollup as an incrementally maintained materialized view. The view stays current as new events arrive, with no recomputation.

CREATE MATERIALIZED VIEW aap03_unified_payment_view AS
SELECT
    framework,
    COUNT(*) AS total_events,
    COUNT(*) FILTER (WHERE status = 'completed') AS completed,
    COUNT(*) FILTER (WHERE status = 'declined') AS declined,
    ROUND(
        100.0 * COUNT(*) FILTER (WHERE status = 'completed')::NUMERIC / COUNT(*),
        2
    ) AS success_rate_pct,
    SUM(amount) FILTER (WHERE status = 'completed') AS completed_amount
FROM aap03_agent_payment_events
GROUP BY framework;

Querying the view produces a single dashboard row per framework:

 framework  | total_events | completed | declined | success_rate_pct | completed_amount
------------+--------------+-----------+----------+------------------+------------------
 mastercard |            4 |         2 |        1 |             50.0 |          1180.00
 stripe     |            7 |         7 |        0 |            100.0 |           453.68
 visa       |            4 |         3 |        1 |             75.0 |           560.00

Note that the Mastercard counts include an authorized event that is neither completed nor declined yet, which is exactly the kind of in-flight state that batch dashboards miss.

The next view tackles cross-framework behavior. Most users settle into a single framework. A user who transacts through two or three frameworks in a short window is worth a closer look, especially if amounts are unusual. We define an anomaly view that surfaces them automatically.

CREATE MATERIALIZED VIEW aap03_cross_framework_anomalies AS
SELECT
    user_id,
    COUNT(DISTINCT framework) AS framework_count,
    STRING_AGG(DISTINCT framework, ',' ORDER BY framework) AS frameworks_used,
    COUNT(*) AS total_events,
    SUM(amount) AS total_amount
FROM aap03_agent_payment_events
GROUP BY user_id
HAVING COUNT(DISTINCT framework) >= 2;

The output flags the users who deserve a second look:

  user_id  | framework_count |    frameworks_used     | total_events | total_amount
-----------+-----------------+------------------------+--------------+--------------
 user_1001 |               3 | mastercard,stripe,visa |            5 |       533.99
 user_1004 |               2 | stripe,visa            |            2 |       338.39

Both views update incrementally as new events arrive. There is no scheduled job, no batch pipeline, and no separate "real-time copy" of the data. The same SQL definitions also work as the contract for downstream consumers: a fraud service can subscribe to changes on aap03_cross_framework_anomalies and react in seconds. For long-term audit, the source table can be sunk to Iceberg with a single CREATE SINK statement, giving you queryable history without doubling your write path.

This is the pattern that scales as you add frameworks. Adding a fourth framework next year does not change the dashboard or the anomaly logic. You just add a new value to the framework column.

FAQ

What is the difference between Mastercard Agent Pay, Visa Intelligent Commerce, and Stripe Agentic Commerce?

Mastercard Agent Pay is a network-level framework built on Agentic Tokens and Verifiable Intent artifacts that prove an agent acted within user-granted authority. Visa Intelligent Commerce, anchored by the Trusted Agent Protocol (TAP), is Visa's parallel network framework that lets agents present cryptographic credentials to merchants. Stripe Agentic Commerce Suite is a developer-first platform built around Shared Payment Tokens (SPTs) and the Stripe Agent Toolkit for Python and TypeScript, designed for direct embedding inside agent codebases.

Are these frameworks interoperable?

Partially. The Agent Payments Protocol (AP2), originally proposed by Google and donated to the FIDO Alliance in 2026, defines a vendor-neutral mandate format. As of April 2026, payment service providers can emit AP2 Mandates that Mastercard accepts as Verifiable Intent. Stripe and Visa have both signed onto AP2 as well, so a single agent can in principle present a mandate that any of the three frameworks can validate. The internal token formats remain framework-specific, so cross-framework reuse of an actual token is not the goal. Cross-framework reuse of the user's mandate is.

What are Stripe Shared Payment Tokens?

Shared Payment Tokens are short-lived, single-merchant payment credentials that Stripe issues to an agent on behalf of a user. Each SPT is scoped to one seller, time-bounded with an expiry, capped to a maximum amount, and emits a fully observable lifecycle of issued, used, expired, or revoked events. SPTs let an agent transact at a specific merchant without ever holding a long-lived card number. If an SPT leaks, the blast radius is bounded by all three constraints simultaneously.

What data infrastructure do agentic payment frameworks require?

All three frameworks generate high-volume event streams covering token issuance, authorization, capture, decline, and revocation. Building on top of them requires a system that can ingest these events with low latency, join them with user and risk context, maintain real-time aggregations for fraud and quota enforcement, and persist an immutable audit trail. A streaming SQL database such as RisingWave provides this layer by maintaining incrementally updated materialized views over the live event stream and sinking the same stream to an Apache Iceberg lakehouse for long-term audit.

Conclusion

The agentic payments landscape in 2026 is not a winner-take-all market. Mastercard Agent Pay, Visa Intelligent Commerce, and the Stripe Agentic Commerce Suite each solve the same problem at different layers of the stack, and most serious deployments will end up using at least two of them. AP2 makes that combination practical, since the user's mandate can travel across frameworks even when the underlying tokens cannot.

What does not change with framework choice is the data infrastructure underneath. Token lifecycle events, intent artifacts, authorization decisions, and decline patterns all need to be ingested, joined, aggregated, and audited continuously. That is the layer where streaming SQL, Apache Iceberg, and incremental view maintenance pay off. A single pipeline that absorbs events from all three frameworks and exposes them as live materialized views gives platform engineers and risk teams a unified view that is impossible to assemble from per-framework dashboards.

Ready to build a unified observability layer for agentic payments? Try RisingWave Cloud free and stand up your first cross-framework materialized view in minutes.

Join our Slack community to discuss your agentic payment stack with engineers from teams running production agentic commerce today.