Cheat sheet — the engineering deck, slide by slide

The point

Survive twenty minutes of being stared at. Say nothing.

Say

• It runs itself while the room fills. If someone asks early: the dots are agents passing traffic — blurple requests, green settlements, red rejections. “That's the talk in one picture.”
• Press → once when you're ready; the cover never eats the arrow key.

The point

Promise the room that nothing in the next half hour is mocked.

Say

• Three characters: a real shop (a-ok.shop — real t-shirts, real Stripe checkout), a real agent (literally a page on my website), and Stripe between them as wallet and processor.
• At the end, the agent buys something with real money, live, and we watch it happen on the wire.
• Don't oversell. The deck's whole credibility is that every claim is backed by something running.

The point

Receipts first so the room trusts the next forty minutes — then flip credibility into the agency push.

Say

• The receipts, briskly — don't linger, confidence reads better at speed: my day job is PM for Stripe Atlas, and agents are the moonlighting that stuck — a seat on the agent steering committee, MPP in production on the merchant you'll see tonight, revisions to the Agentic Commerce Protocol, and the early Stripe Projects team enabling agentic infrastructure provisioning.
• Then the turn, and it's the talk's best line: none of that produced this demo. I'm a PM, not a software engineer, and nobody assigned me this — I built it nights and weekends, willing to be bad at it in public until it worked.
• Land the push: the distance between “that looks interesting” and “I have a working thing to show you” is a decision, not a credential. Go make it, and ship the thing.
• Contacts are on this slide; you'll point back at them at the close.

The point

Name precisely why today's checkout breaks when the buyer is software.

Say

• Every step of online checkout silently assumes three things: a browser to draw the pages, a person to click through them, and a place to land when the bank bounces you back after approval.
• Take the person away and no step refuses the agent — it just strands it. There's no error, no signal, nothing. That silence is the problem.

Jargon, translated

“a redirect back when the bank is done”

the “confirm it's really you” bounce to your bank and back. It assumes there's a browser to come back to. An agent has none.

The point

MPP is three small additions to plain web requests — nothing to install, nothing exotic.

Say

• When software tries to buy, the shop answers with response code 402, “Payment Required.” It's been reserved in the web's rulebook for exactly this since 1997 and almost nothing has ever used it. MPP finally activates it.
• Attached to that answer: the price and how to pay — carried in the same kind of envelope field that every website login already uses. Nothing new had to be invented.
• The buyer then sends the identical request again with payment attached, and the shop completes the order it refused a second ago.
• The dark panel is a real captured response from the shop, not an illustration. Point at the three bold things: the 402, the payment header, and “amount: 5” — five cents.

Jargon, translated

header (WWW-Authenticate / Authorization)

envelope fields on a web request — the addressing information around the message, not the message itself.

base64url blob

the full order details packed into one long header-safe string of text, so the receipt travels inside the envelope.

“no wallet in the merchant's database”

the shop never stores anyone's payment credentials for this. Nothing sensitive lands on their side.

The point

The whole purchase in four hops. Drive it with → and narrate each beat.

Say

• One: the agent asks to buy. Two: the shop quotes — that's the 402. Three: the wallet mints a pass worth exactly the quote. Four: the agent asks again, identically, pass attached — the shop charges it and hands back a receipt.
• The thing to emphasize: the pass is minted after the price exists. That ordering is the entire security model — you can't scope a pass to a price you haven't seen.

The point

Safety comes from scope, not secrecy. This is the slide that makes everything after it reasonable.

Say

• What the agent hands over is a cheque written for one purchase — not a card. Minted after the quote, worth exactly that amount, dead the moment it's used.
• Worst case if it leaks: someone buys the same five-cent sticker again. There is nothing else it can buy.
• If the shop tries to charge more than it quoted, Stripe declines it. Honesty is enforced by the network, not assumed of the merchant.
• Right-hand panel: the payment request itself carries the full order — items, total, currency. The agent decides from data it holds, not from trusting a summary rendered somewhere else.

Jargon, translated

spt_

Stripe's single-use payment token — the cheque. The prefix is just how Stripe names them.

“the challenge is self-describing”

everything needed to decide whether to pay is inside the message itself. No second source to trust.

The point

Place the talk on Stripe's official map before deriving what it unlocks.

Say

• The machine-payments team frames demand as five levels of delegation — from “no more forms” up to “you set a budget and the system handles the rest,” and past that, needs anticipated without asking.
• Levels four and five cannot exist on human checkout. There's no one at the screen to click. That's the moment payment itself has to become machine-native — and it's where this talk lives.
• Serving agents takes five pillars: discovery, identity, checkout, payments, fraud. Today is the payments pillar end to end. You'll meet discovery and identity again on the closing slide, as open problems.

The point

The sticker is a stand-in. Derive the buyers this shape makes possible.

Say

• The official line, worth quoting verbatim: let agents improvise in discovery, never in payment. Agents are non-deterministic; MPP constrains the one step that moves money.
• Four things fall out. No person needed → procurement at machine speed: inventory reorders at 3am off a threshold. No prior trust needed → agents paying agents for data, compute, or work — the scoped token is the relationship. One round trip per transaction → paying per API call or per query, down to stablecoin amounts where cards stop making sense. Cap bound to the quoted price → delegated budgets enforced by the rails, not by the prompt.
• Land the warning panel honestly: none of this runs at volume yet. What follows is deliberately the smallest instance of the shape — one merchant, one item, every wire visible — because the mechanics are identical at every size above it.

Jargon, translated

co-authored with Tempo

MPP is an open standard Stripe wrote together with Tempo — not a proprietary Stripe API.

SPTs and stablecoins

the standard supports both normal card rails (via the single-use tokens) and stablecoins — the latter for payments too small for card economics.

The point

The same URL answers twice, and the shop remembers nothing in between.

Say

• Three endpoints. The catalog is free to read. The purchase endpoint, called bare, prices the order and answers 402. The same endpoint, called with one extra header, charges and confirms. The only difference between refusal and completion is one header.
• The important non-feature: the shop writes nothing down between the two calls. No cart, no hold on stock, no timer running. Come back an hour later, you just get a fresh quote.
• Which means an abandoned handshake costs the shop literally nothing — that's why this is cheap to operate.

Jargon, translated

“no payment session, no reservation row, no state machine”

three ways of saying “the shop keeps no memory between the ask and the payment.” Nothing is created that can leak, expire, or need cleanup.

The point

Two codebases, built separately from a written spec, met at the wire and worked.

Say

• The merchant half lives in the shop's repo; the buyer half lives in mine. The buyer was written against the written description and the wire format — it never read the seller's source.
• They interoperated the first time. That's the actual proof the protocol is real, and it's the sentence to leave this slide on.

The point

The merchant's entire first half: price the order, then decline it with the quote attached.

Say

• It's one function. It prices the order exactly the way checkout already does, answers “not yet — here's what it costs,” and forgets the conversation ever happened.
• The two side panels are war stories, and their real message is how small the sharp edges were. Feel free to compress them into one line: “the hardest bugs we hit were a two-character encoding detail and a string-versus-number disagreement.”

Jargon, translated

base64url, not base64

the order details ride inside a header, and the usual way of packing text into a string uses two characters that aren't legal there. There's a header-safe variant with those two swapped. We used the wrong one, Stripe's own decoder tool refused to read it, and one commit fixed it. It stays in the deck because it's the honest size of what “hard” looked like on this project.

amounts as strings

different parts of the tooling disagree about whether an amount is the number 5 or the text “5.” The fix is to accept both — thirty seconds of defensive code. Tell your team so they don't lose an afternoon to it.

The point

Read the credential, make one Stripe call, done. Retry-proof by construction.

Say

• First thing the shop does is check the credential's first four characters. Anything that doesn't look like a real Stripe token is turned away at the door, before Stripe is ever involved — which is also what makes rehearsing with pretend credentials safe.
• The charge itself is one call, labeled with the order number. If a nervous agent retries after a timeout, Stripe recognizes the label and returns the same charge instead of making a second one.
• Say why that matters: double-charge protection matters far more when the customer is a retry loop than when it's a person who would notice.

Jargon, translated

PaymentIntent

Stripe's record of one payment attempt.

confirm: true

create the payment and charge it in a single step, instead of create-then-confirm.

idempotency key

the label (here, the order id) that lets Stripe detect “I've seen this exact request before” and return the original result instead of charging twice.

The point

The agent's whole job is four steps: ask, check the cap, mint, replay.

Say

• Ask and get quoted. Check the quote against the spending cap. Mint the pass for exactly the quote. Send the identical request again with the pass attached.
• “Identical” is literal: the order text is written down once and that exact text is sent both times, because the quote was issued against the first rendering — even re-typing it could shuffle the fields.
• The line that lands with security people: the cap is checked after the shop quotes and before anything chargeable exists. There is no sequence of events where sweet-talking the model helps, because the check isn't in the model.

Jargon, translated

amountMinor / minor units

the amount in cents. 5 means five cents.

The point

Four layers between an agent and money — and only one of them is the prompt, listed last on purpose.

Say

• One: spending is off unless a deliberate switch is flipped. Deploying this deck cannot quietly become the ability to charge a card.
• Two: a hard cap, applied to the number the shop quoted — not to anything the model said.
• Three: the pass itself covers one purchase at one price. If every other layer failed at once, the damage is one sticker.
• Four: a person confirms. Real, useful — and the weakest layer, because a determined mistake could talk its way through it. That's exactly why it's listed last.
• Slow down here. This is the slide skeptics respect, and the honesty about layer four buys more credibility than it costs.

The point

Run-book, not prose. The demo proves the mechanism; you narrate the wire.

Say

• Before starting: glance at the badge for whether settlement is live or the run stops at the handshake. Either way the wire trace is the show.
• Use the first suggestion — “What's in the catalog? Buy the cheapest thing in it.” It exercises discovery, not just the purchase.
• Narrate the right-hand column as it streams: catalog fetch → the 402 with the quote → cap check → mint → the identical replay → 200 and a receipt.
• If the model or the venue wifi misbehaves: the “Run the handshake” button drives the exact same purchase code with no AI in the loop. On stage, a demo with one dependency beats a demo with two.
• Close it with: “that was a real order, on the shop's normal payment rails.”

The point

End on candor, then hand the room the first move and your contacts.

Say

• Real today: the protocol pieces, two independently written codebases interoperating, merchant-side settlement, and everything they just watched.
• Not settled: the buyer-side mint is private preview — the merchant half is buildable today from public docs, the wallet half needs access. Refunds and disputes have no MPP-shaped answer yet. And there's no standard way to discover that a merchant speaks MPP — the two missing pillars from the map slide.
• The part worth stealing: one route and one verifier, a few hundred lines beside an existing store. If you have an ordering endpoint and a Stripe account, you're closer than it sounds — and the failure mode of trying is a 402 nobody calls.
• Then the ask: machine-payments@stripe.com, and if you build something with MPP in public, tag @backseatvc and @jeff_weinstein on X.