Agentic Commerce Payments: Secure Tokens, Real Control

AI agents are already sitting in the checkout seat. Stripe’s Instant Checkout in ChatGPT is an early proof: a buyer can discover a product in a conversation and complete a purchase without leaving the chat. That’s a real shift in distribution—and a real shift in payments infrastructure.

Here’s the uncomfortable part: most of the assumptions that make online payments work (and keep fraud manageable) were built for humans clicking buttons. Agentic commerce breaks those assumptions. A bot can click “Buy” perfectly. A human can’t always explain why a charge looks suspicious. And traditional “possession of a credential” signals—like having a saved card—stop being useful when an AI agent is acting on someone’s behalf.

This post is part of our AI in Payments & Fintech Infrastructure series, and I’m going to take a firm stance: agentic commerce won’t scale on vibes, screenshots, or fragile session-based trust. It needs new primitives—permissioning, identity, and risk signals that are explicit and enforceable in code. Stripe’s Agentic Commerce Protocol (ACP) and Shared Payment Tokens (SPTs) are a clear attempt to build that layer.

Why agentic commerce breaks traditional payments trust

Answer first: In agentic commerce, you can’t treat “the agent has the card details” as proof the user intended the purchase; you need explicit, scoped authorization that survives automation.

Traditional payments stack a few implicit trust signals:

• The user is present (typing, clicking, completing 3DS when challenged)
• The device/browser session looks consistent
• The card credential is in the right place at the right time
• Fraud tools infer intent from behavioral patterns

Agentic commerce flips the model. The “user” may be a human who gave a high-level instruction (“order my usual skincare”) and the “actor” is an AI agent executing steps—searching, comparing, selecting variants, applying coupons, and checking out.

That introduces three infrastructure problems that matter immediately to payment teams:

1) Permissioning has to be machine-readable

If your only control is a UI confirmation, your controls disappear the moment checkout happens inside an AI surface. Permissions need to be scoped (who/what/when/how much) and enforceable by the payment rails, not just by product design.

2) Fraud and bot defense get tangled

You want to welcome “high-intent automation” (a legitimate agent acting for a real customer) while rejecting low-trust automation (bots testing cards, account takeover scripts, synthetic identities). If you treat all automation as fraud, you’ll block a channel customers actually like. If you treat automation as safe, you’ll get burned.

3) Disputes become an intent problem, not a credential problem

Disputes often come down to “I didn’t authorize this.” In an agentic flow, a customer might not remember the exact moment the agent executed the payment—even if they did authorize it within constraints. Your infrastructure needs auditable authorization trails and clear customer controls.

Shared Payment Tokens (SPTs): a payments primitive built for agents

Answer first: Shared Payment Tokens are designed to let AI agents initiate payments using user-granted permission—without exposing card credentials—and with constraints that can be enforced in real time.

Stripe introduced Shared Payment Tokens (SPTs) as a new payment primitive for agentic commerce. The key idea is simple and strong: separate “permission to pay” from “access to credentials.”

Instead of passing card details around (or forcing the user to re-enter them in every agent surface), an SPT represents:

• A buyer-approved authorization
• A preferred payment method (without revealing it)
• A set of constraints (scope, limits, revocation)

From an infrastructure viewpoint, SPTs matter because they’re:

• Programmable by design: scope to a specific merchant, limit by time/amount, revoke anytime, observe via webhooks.
• Reusable: supports saved payment methods so repeat purchases don’t degrade into repeated friction.
• Secure and interoperable: credentials aren’t exposed; Stripe positions SPTs as compatible with agentic token directions on card networks.
• Fraud-aware: when used on Stripe, SPT transactions can benefit from Radar plus agent-specific signals that help separate legitimate agent behavior from bot activity.
• Integration-friendly: SPTs work with PaymentIntents, which means Stripe-integrated teams don’t need a ground-up rebuild.

A good “new primitive” test is: does it reduce risk and reduce complexity? Scoped tokens do both—because you stop forcing every AI surface to reinvent consent, storage, and credential handling.

What the end-to-end flow looks like (and why it’s sane)

Answer first: The flow keeps credentials with the AI platform and tokenizes intent for the merchant, so merchants can accept agent-driven purchases with minimal stack changes.

Stripe describes a flow that looks like this:

1. Buyer creates or reuses a saved payment method with the AI platform.
2. Buyer clicks “Buy,” and the AI platform issues an SPT scoped to the business, with a usage limit tied to the checkout total.
3. AI platform sends the SPT identifier to the business via API.
4. Business uses the SPT to create a PaymentIntent.
5. Stripe processes the payment, enforces token controls, and applies fraud detection.

This is an important architectural choice: the merchant doesn’t have to accept raw credentials from the agent. The agent doesn’t have to learn the merchant’s custom checkout logic. And the token constraints provide a common enforcement layer.

If you’re building payments infrastructure, that separation is what you want:

• The AI platform focuses on user experience + authorization capture.
• The merchant focuses on fulfillment, post-purchase support, refunds.
• The payments layer enforces the rules consistently.

Snippet-worthy truth: Agentic commerce scales when “intent” becomes a token with limits—not a screenshot of a chat message.

Why this is really about transaction routing, risk, and control

Answer first: Agentic commerce isn’t a new checkout page; it’s a new distribution channel that demands smarter routing and stronger risk controls at the infrastructure layer.

If you run payments, you already care about three numbers:

• Authorization rate (how many payments succeed)
• Fraud/disputes (how many payments you regret)
• Cost to process (fees + operational overhead)

Agentic commerce touches all three.

Smarter routing needs better context

Payments “routing” isn’t just picking an acquirer. It’s the entire decision chain: whether to challenge, whether to step up authentication, whether to block, whether to allow retries, and how to handle edge cases like partial fulfillment.

In agentic flows, the transaction context can be richer:

• The token scope (merchant, amount cap, expiration)
• The agent identity and platform reputation
• A history of agent-mediated purchases

That context makes it easier to route intelligently:

• High-confidence token + consistent behavior: approve with minimal friction
• Weird patterns (rapid attempts, mismatched totals, strange merchant scope): step up verification or block

The strategic point for AI in payments is this: better context lets you reduce friction without increasing losses. That’s what infrastructure teams actually want.

Fraud prevention becomes “bot discrimination,” not “bot blocking”

Stripe notes a real issue: agentic commerce challenges fraud systems that assume possession of a credential is a trust signal.

In practice, you need to distinguish:

• Authorized automation: the agent is executing a permissioned purchase
• Unauthorized automation: card testing, scripted checkout abuse, account takeover

A token like SPT gives you a clean dividing line: was there explicit permission? was it within constraints? That’s far more actionable than guessing intent from typing speed.

What businesses asked for: catalog, brand, identity

Answer first: Merchants want to participate in agentic commerce without being commoditized, so they need control over product data, checkout brand, and customer identity.

Stripe’s roadmap highlights three merchant demands that I’ve seen echoed across platforms and marketplaces:

1) Real-time product and pricing controls

If AI agents are going to recommend and purchase items, merchants need a structured way to publish:

• Product attributes (variants, bundles, subscriptions)
• Live availability (inventory constraints matter during peak season)
• Real-time pricing (promos, region pricing, dynamic shipping)

This becomes especially relevant in December when inventory and delivery promises are fragile. Agentic surfaces that show stale stock or wrong delivery dates will create refunds, support tickets, and disputes.

2) Brand control at checkout

Merchants don’t want to be reduced to a line item in a chat transcript. They want:

• Their upsells and cross-sells
• Their policies and disclosures
• Their post-purchase relationship

That’s why an extensible checkout embedded inside AI agents is more than a UX detail. It’s a retention and margin issue.

3) Customer identity and trust controls (via wallets)

Stripe’s plan to extend the foundation through Link points to a bigger infrastructure trend: identity continuity across AI surfaces.

If a customer buys through multiple agent experiences, they still expect:

• A unified purchase history
• Easy refunds and receipts
• Controls like spending limits and explicit permissions

From a fintech infrastructure standpoint, that’s the bridge between “payments tokenization” and “portable identity + authorization.”

Practical checklist: how to prepare your payments stack for agentic commerce

Answer first: You don’t need to rebuild payments, but you do need to upgrade your authorization model, risk instrumentation, and post-purchase operations.

If you’re a platform, merchant, or fintech building for AI-driven commerce workflows, here’s what I’d prioritize over the next quarter:

1) Treat permissioning as a first-class object

• Support scoped authorization (merchant, amount, time window)
• Log and retain authorization evidence
• Build revocation paths (customer support and self-serve)

2) Instrument risk signals specific to automation

• Rate limits and anomaly detection around “agent-like” traffic
• Separate automated high-intent purchase flows from generic bot traffic
• Align fraud rules with token scope (don’t override the token’s guardrails)

3) Tighten your catalog and pricing surfaces

• Provide structured product feeds (variants, shipping, subscriptions)
• Sync availability in near real time
• Add guardrails for substitution and partial fulfillment

4) Update dispute and refund playbooks

• Map disputes to authorization scope (“within limits” vs “out of bounds”)
• Make it easy to present proof of user-granted permission
• Ensure agents can request refunds, but require confirmation for high-risk cases

5) Design for identity continuity

• Unify receipts and order tracking across channels
• Consider wallet-based identity and purchase history as a retention feature

The real opportunity: infrastructure that makes AI commerce trustworthy

Agentic commerce payments are going to expand because they reduce customer effort. The winners won’t be the companies with the flashiest demo—they’ll be the ones who make agent-mediated payments auditable, reversible, and resistant to abuse.

Stripe’s direction—ACP plus Shared Payment Tokens plus wallet-based controls—signals where the industry is heading: programmable trust at the infrastructure layer. That fits the broader narrative of AI in payments: using AI and structured signals to improve fraud detection, acceptance, and transaction decisioning without turning checkout into an obstacle course.

If you’re evaluating agentic commerce, don’t start by asking whether the UI is “cool.” Start by asking whether your infrastructure can answer three questions instantly: Who authorized this? What were they authorizing? Can we prove it and enforce it?