Stripe's Agentic Commerce Suite answers a question most builders hadn't fully framed yet: when the thing on the other end of your checkout is software, not a person, how does the money move? The suite's answer is two primitives, not one — and the single most useful thing to understand before you write a line of code is which of them you actually need. Pick wrong and you'll spend a day forcing a shopping-cart flow onto an API that should just charge per request.

Here's the whole decision in one sentence: if an agent is buying a cart from your store, use Shared Payment Tokens; if an agent is paying to use your API, use the Machine Payments Protocol. Everything below is detail on those two paths.

Path 1 — Shared Payment Tokens: an agent checks out at your store#

A Shared Payment Token (SPT) is what you accept when a customer's shopping agent completes a purchase on your storefront. The agent doesn't hand you a card number. It grants your Stripe account a token that is deliberately hard to abuse: it is scoped to your merchant (it can only be charged at your store), capped to the approved cart total (a charge over the amount is impossible), and expires in minutes (no room for replay). Stripe rejects any charge that comes from the wrong seller, exceeds the remaining amount, or arrives after expiry.

The payoff for you is that an SPT drops straight into the Stripe API you may already use. You create a PaymentIntent with the token and confirm it:

const paymentIntent = await stripe.paymentIntents.create({
  amount: cartTotal,          // must be ≤ the token's approved ceiling
  currency: 'usd',
  payment_method: sharedPaymentToken,
  confirm: true,
  payment_method_options: {
    card: { request_delegated_payment: true },
  },
});

That's the integration. If you can already take a card payment, you can take an agent payment — the SPT is just a payment method with guardrails baked in. You can also retrieve the granted token to inspect its limits before charging (card brand, last four, currency, expires_at, and the maximum amount), which is worth doing so you fail loudly instead of letting Stripe reject a charge you could have caught first.

The security model is the quiet win here: a Shared Payment Token is scoped, capped, and short-lived by construction. A token that leaks after the sale is worth almost nothing to an attacker — wrong merchant, over the cap, or already expired.

Use this path for storefronts, marketplaces, and one-off purchases where there's still a human intent behind the buy and your product is a cart of goods or services.

Path 2 — Machine Payments Protocol: an agent pays your API#

The Machine Payments Protocol (MPP), co-authored by Stripe and Tempo, is for the other case: the buyer isn't a person's shopping assistant, it's autonomous software paying to consume something you meter — an API call, a dataset, a compute job. MPP is a payment protocol built on plain HTTP, and it hangs off one status code. When a client requests a paid resource, your server answers HTTP 402 Payment Required with the price. The client authorizes the payment, retries the request, pays, and gets the resource plus a receipt. If that request/402/pay/retry loop sounds familiar, it's the same shape as x402, the pay-per-request scheme now baked into edge platforms — MPP is Stripe's settlement layer under that pattern, and it slots alongside the other agent-payment protocols worth knowing.

Because it's just middleware over your existing routes, the code is small. The mppx TypeScript SDK provides framework middleware you import from mppx/server:

import { requirePayment } from 'mppx/server';

// Charge 2 cents per call before serving the handler
app.get('/v1/enrich',
  requirePayment({ amount: 0.02, currency: 'usd' }),
  (req, res) => {
    res.json(runEnrichment(req.query));
  });

The first request returns a 402 with payment details; the agent authorizes and retries; the second request runs your handler and returns a receipt alongside the data. MPP settles across stablecoins (via the Tempo network) as well as cards and buy-now-pay-later through SPTs — so the same endpoint can bill a crypto-native agent and a card-backed one without you branching on payment method.

This is the right model for micropayments and metered access, where wrapping every $0.02 call in a full checkout session would be absurd.

Test it today, without a card#

You don't need a real card — or a real agent — to try either path. Stripe's link-cli can provision one-time shared payment token credentials from your personal Link account; install its skills or register it as an MCP server from link.com/agents, and you can issue test SPTs by hand. For MPP, build against the sandbox first and only request the Stablecoins and Crypto payment method in your Dashboard when you're ready for live mode.

The one decision that matters#

Everything else is implementation. Before you start, answer one question: is the agent buying a cart, or paying for access? A cart means a human is somewhere in the loop and you want SPTs and a PaymentIntent. Access means the buyer is software paying per request and you want MPP and a 402. Get that right and both integrations are an afternoon; get it wrong and you'll feel the friction on the first endpoint.