Stripe Shared Payment Tokens: How a Seller Accepts an Agent-Made Payment (2026)

What did Stripe just ship for agent payments?

On March 3, 2026, Stripe expanded Shared Payment Tokens (SPT) so an AI agent can complete a purchase on a customer’s behalf without ever seeing the underlying card or credentials. The expansion adds agentic network tokens from Mastercard Agent Pay and Visa Intelligent Commerce, plus buy-now-pay-later tokens from Affirm and Klarna — all provisioned through a single primitive.

Stripe’s own claim is that it’s the first and only provider supporting both agentic network tokens and BNPL tokens in agentic commerce through one primitive (Stripe blog). The longer context: this lands on top of card acceptance you already have, and the seller-side work is smaller than the launch noise suggests.

Here’s the part the launch blogs gloss over, and the part you need to get right: SPT is not a new payment rail that competes with Visa and Mastercard. It’s the developer integration layer that provisions those networks’ agentic tokens. The networks still issue and run the token; Stripe is the layer you integrate to provision it on the buy side and verify it on the sell side. If you frame it as a three-way “Stripe vs Visa vs Mastercard” fight, you’ll build the wrong mental model and probably the wrong code.

SPT lives inside the Agentic Commerce Protocol (ACP), the open standard (Apache 2.0) Stripe built with OpenAI for how agents and businesses coordinate checkout and securely share payment credentials. ACP is the conversation; SPT is the payment object that gets handed over inside it. If you’ve already wired up Stripe in your SaaS, most of what follows extends that foundation rather than replacing it.

What does a Stripe SPT payment look like end to end?

The end-to-end mechanics are simpler than the hype suggests. A customer authorizes an agent to buy on their behalf, choosing a payment method and a scope — a spend limit, or a specific purchase. Stripe then provisions an agentic network token (Mastercard or Visa) scoped to that intent and shares it with the agent. The Shared Payment Token the agent holds is represented by the shared_payment.granted_token object (id spt_…) — “SPT” and “granted token” are the same thing, not two separate objects. The agent presents that token to any seller accepting agentic payments, anywhere Mastercard or Visa is accepted. The seller — you — never receives the raw card.

The scope isn’t a vibe; it’s enforced data on the granted token. The usage_limits object carries currency, max_amount (in the currency’s minor unit, e.g. cents), and expires_at (a Unix timestamp). The agent’s requested charge has to fit inside those limits, and you’re the one who has to check. Because the same primitive also covers BNPL, an agent can present Affirm or Klarna financing without you building a separate integration for it — one path, multiple funding sources.

What does a seller actually have to build for agent payments?

In a normal checkout, a human is present. They land on your page, confirm the PaymentIntent in your UI, and you fulfill once payment confirms. With an agent payment, no human is at your checkout — the agent arrives already holding a pre-authorized token. That’s the whole delta, and it’s smaller than it sounds.

What stays the same: you still create a PaymentIntent, you still treat the verified webhook as the source of truth, and you still fulfill only after payment confirms. The discipline from verifying webhook signatures applies here without modification — a synchronous API response is a hint, the signed event is the truth.

What’s new is exactly one verification step. You receive a granted token, object type shared_payment.granted_token, and before you charge you must confirm the order fits its scope: the right currency, an amount at or under max_amount, not past expires_at, and not already deactivated. Tokens get deactivated when they’re consumed, expired, or revoked, exposed as a deactivated_at field (null while active) with a deactivated_reason. Listen for the shared_payment.granted_token.deactivated event and stop using that token the moment it fires. Treat SPT as a new payment method, not magic: same discipline as cards, one extra check.

The integration: accept, verify, charge

Here’s the seller-side shape. The code below is illustrative — these are preview-version API objects (the shared_payment.granted_token object, the granted-tokens retrieve endpoint, the payment_method_data field) and may change before GA, so verify against the seller docs. The current preview version is 2026-04-22.preview — pin it explicitly and re-check the docs, since preview versions can change before GA.

First, retrieve the granted token to inspect its scope:

# Illustrative — preview fields, verify vs Stripe docs
curl https://api.stripe.com/v1/shared_payment/granted_tokens/spt_123 \
  -u "$STRIPE_SECRET_KEY:" \
  -H "Stripe-Version: 2026-04-22.preview"

Then verify before you charge. The agent’s requested amount must fit inside the customer’s authorization, and the token must still be active. Compare expiry against the current time at charge time, not against when the order row was created:

# Illustrative — preview fields, verify vs Stripe docs.
# Verify the token's scope before charging.
import time

def order_fits_token(order, token):
    limits = token["usage_limits"]
    if token.get("deactivated_at") is not None:
        return False  # consumed, expired, or revoked
    if order["currency"] != limits["currency"]:
        return False
    if order["amount"] > limits["max_amount"]:     # minor units (cents)
        return False
    if int(time.time()) >= limits["expires_at"]:   # compare to now at charge time
        return False
    return True

Only if it fits do you create the PaymentIntent, passing the token via payment_method_data[shared_payment_granted_token]. Stripe clones the underlying PaymentMethod and processes it — the raw card never reaches you:

# Illustrative — preview fields; note the Idempotency-Key for agent retries
curl https://api.stripe.com/v1/payment_intents \
  -u "$STRIPE_SECRET_KEY:" \
  -H "Stripe-Version: 2026-04-22.preview" \
  -H "Idempotency-Key: order_5f3c-attempt" \
  -d amount=1000 \
  -d currency=usd \
  -d "payment_method_data[shared_payment_granted_token]=spt_123" \
  -d confirm=true

Confirm fulfillment only off the verified webhook, never off that synchronous response alone. The agent is buying on someone else’s authorization; the signed event is your evidence the money actually moved.

Why idempotency and a feature flag are non-negotiable

Agents retry. An autonomous client re-sends a request on a timeout far more readily than a human clicking a button gives up — there’s no hesitation, no “did that go through?” pause. Pass an Idempotency-Key on the PaymentIntent create call so a retry doesn’t double-charge the customer’s scoped token. Then make fulfillment idempotent on your side too: key it to the PaymentIntent id so a replayed webhook doesn’t ship the order twice. None of this is new advice — it’s the same idempotency hygiene you already owe card payments, just with a more impatient client on the other end.

Now the opinion, clearly labeled as mine: build this behind a flag. The rails launched in 2026 and are early. Availability, country coverage, and agent adoption are all still ramping, and the API is on a preview version. A flag lets you enable agent checkout per region or per merchant and kill it fast if something misbehaves — a network token edge case, a deactivation you didn’t handle, an agent that retries pathologically. Verify country availability before you enable it for any market, because the agentic acceptance layer is rolling out market by market and is not uniform yet. The agents doing the buying are autonomous software; treat their traffic with the same caution you’d give any new, lightly-tested integration touching money.

How do agent payments reach LATAM, and where do stablecoins stand?

For sellers in Mexico and the rest of LATAM, the reach is genuinely broad: agentic payments ride the same Visa and Mastercard acceptance you already have. You’re not waiting on a brand-new network to reach your market. But confirm SPT availability in your specific country before flipping it on — the agentic layer is launching market by market, and “Visa is accepted here” is not the same as “agentic acceptance is live here.” Check, don’t assume.

Spanish-first UX still matters, and the agent doesn’t change that. If an agent is buying for a Mexican customer, your fulfillment, receipts, and error states should still be localized. The agent is a channel, not an excuse to ship a worse experience — the human who authorized it will read the receipt.

On stablecoins, be careful. People will ask whether agents can settle in stablecoins under Mexican rules, and the honest answer is that the regulatory picture — including the Ley Fintech — is evolving, and country availability is not guaranteed. Get qualified compliance and legal advice before building any stablecoin settlement path. Don’t take a blog’s word for it, including mine; nothing here is legal advice. The pragmatic move today is to ship the card and BNPL agentic path that’s actually integrable now, and watch the stablecoin rules rather than betting on them.

FAQ

Does the agent see my customer’s card? No. That’s the entire point of SPT — the agent gets a scoped token, and the card or credentials are never exposed to it. You don’t see the raw card either; Stripe clones the underlying PaymentMethod server-side.

Is this a new rail that competes with Visa and Mastercard? No. Stripe SPT is the integration layer that provisions Visa Intelligent Commerce and Mastercard Agent Pay network tokens. The networks still issue and run the tokens. Stripe is the layer you integrate, not a competing rail.

What do I actually have to build as a seller? Accept the granted token, ideally via ACP. Verify its usage_limits and active status. Create a PaymentIntent with the token via payment_method_data[shared_payment_granted_token]. Fulfill idempotently off the verified webhook. That’s it.

Can agents pay with BNPL? Yes. Stripe expanded SPT to cover Affirm and Klarna tokens through the same single primitive, so financing comes along the same path you already built for network tokens.

Is it production-ready? It’s live but early (2026), launched on a preview API version (2026-04-22.preview). Treat it as shippable-behind-a-flag, not a finished, universally-available feature.

Ship it behind a flag

The agent-pays-for-the-customer future is real and partially shippable today, and SPT is the cleanest primitive I’ve seen for it — one object that carries the customer’s authorization, its scope, and its expiry, across both network tokens and BNPL.

So do the unglamorous part well. Verify the token’s scope, fulfill idempotently off the verified webhook, and keep the whole thing behind a flag until adoption and availability catch up. Build the card and BNPL path now; track the stablecoin rules instead of betting on them. The engineers who treat this as just-another-payment-method — with exactly one extra verification step — will ship calmly while everyone else is still arguing about the hype. If you want the rest of the payments groundwork this sits on top of, that’s over in the integrations guides.