Giving your AI agent a wallet: my Alfred moment
Batman doesn't book his own dinner reservations. Alfred does. Bruce says "I need a table for two, somewhere quiet," and it just happens. The reservation, the payment. Handled.
That's the promise everyone keeps making about AI agents, except there's always been one wall they slam into: the checkout page. Your agent can research flights for an hour, compare seat maps, read three hundred reviews of an aisle seat, and then it hits a credit card form and turns around to ask you to type sixteen digits. Alfred, but he has to wake Bruce up every time the bill comes.
That wall is coming down right now. I used it last week to buy movie tickets. More on that at the end, there's a Spider-Man involved. In my world DC and Marvel are colliding: a Wayne-manor butler running errands for a Spider-Man premiere. The multiverse can cope.
Why agents need wallets at all
Think about what an agent without payment access actually saves you. It saves you the searching. But the last mile, the part where money moves, still needs your hands on the keyboard. And that last mile is where most of the friction lives: filling forms, fetching your card, doing 3D Secure dances on your phone.
The naive fix is terrible: paste your real card number into the agent's context. Please don't. The card sits in logs, in conversation history, in whatever the agent decides to memorize. One prompt injection on a sketchy website and your card is off buying gift cards in a country you can't pronounce.
The real fix is what the payments industry has been quietly building: scoped, short-lived, agent-bound credentials. The agent never sees your real card. It gets a credential tied to an amount you approved, valid for a matter of hours, and it expires on its own. Less "here's my wallet, Alfred" and more "here's twenty bucks for the movies."
Stripe's link-cli: a wallet your agent can actually use
Stripe shipped link-cli, an open source CLI that lets an agent request payment credentials from your Link wallet. The design is the interesting part: the agent doesn't hold your card, it holds the ability to ask. You approve, Stripe mints a short-lived virtual card for that purchase (valid for 12 hours, meant to be used once), and the agent completes checkout with it.
Setup is one line:
npm i -g @stripe/link-cli
Then you log in, which links the CLI to your Link account (the same Link you've probably used at a hundred checkouts without noticing):
link-cli auth login
link-cli auth status
List what payment methods your wallet holds:
link-cli payment-methods list
Now the fun part. When your agent wants to buy something, it creates a spend request. Notice how much context it has to declare: who the merchant is, what's being bought, exact line items, exact total.
link-cli spend-request create \
--payment-method-id csmrpd_xxx \
--merchant-name "Stripe Press" \
--merchant-url "https://press.stripe.com" \
--context "Purchasing 'Working in Public' from press.stripe.com" \
--amount 3500 \
--line-item "name:Working in Public,unit_amount:3500,quantity:1" \
--total "type:total,display_text:Total,amount:3500" \
--request-approval
That --request-approval flag is the whole security model in four words. You get pinged, you see exactly what the agent wants to spend and where, you approve. Only then does this work:
link-cli spend-request retrieve lsrq_001 --include card
That returns a virtual card the agent can use at the merchant's checkout. Not your card. A disposable one, tied to the amount you just approved and expiring within hours. There are hard caps too: $5,000 per request and per day, $20,000 a month.
And for merchants that speak the newer machine-to-machine protocols, the agent skips the checkout form entirely:
link-cli mpp pay https://climate.stripe.dev/api/contribute \
--spend-request-id lsrq_001 \
--method POST
Here's the flow in one picture:
The thing I like most: this is boring infrastructure. Tokens, scopes, approvals. Boring is exactly what you want between an LLM and your bank account.
Mastercard and Visa are already in the water
If you think this is a Stripe experiment, the card networks would like a word. Both giants announced their agentic frameworks back in April 2025 and have been rolling them into production since.
Mastercard Agent Pay uses what they call Agentic Tokens, built on the same MDES tokenization rails that already power your phone's tap-to-pay. An Agentic Token binds a card credential to a specific agent, a specific merchant scope, and a specific consent policy. So ChatGPT or Copilot can finish a checkout without ever holding your PAN. In June they went further and launched Agent Pay for Machines, aimed at fully autonomous machine-to-machine payments, where one machine pays another while you sleep.
Visa Intelligent Commerce is the same idea from the other camp: an API suite combining tokenization, authentication, and payment instructions. Their Intelligent Commerce Connect product gives merchants and agent builders one integration that supports four agent payment protocols at once: Trusted Agent Protocol, Machine Payments Protocol, Agentic Commerce Protocol, and Universal Commerce Protocol. Visa has already run authenticated agent transactions across nine Asia-Pacific markets including Singapore, India, Australia, and South Korea, and they've publicly predicted millions of consumers will complete purchases through agents by this holiday season.
Four competing protocols in the same paragraph should tell you where we are: the messy, exciting, pre-standardization phase. Same energy as 2010-era mobile payments, right before everything consolidated.
The Spider-Man test
Enough theory. Spider-Man: Brand New Day tickets went on sale, and I wanted the Thursday premiere before the good seats vanished.
Old me: open the ticketing site on my phone, fight the seat map, fumble for my card, get a 3DS push notification, approve it, lose my selected seats because the session timed out, start over. You know this pain.
This time I told Alfred - My Butler Agent, roughly: "Two tickets, Spider-Man: Brand New Day, July 30 evening show, aisle seats if you can get them, cap it at what two premiere tickets should cost." The agent found the showtime, picked the seats, created a spend request with the cinema as the merchant and the exact total. My phone buzzed with an approval prompt showing merchant, amount, line items. One tap. The agent got its short-lived card, checked out, and a minute later this landed in my inbox:
Thursday, July 30. Booked while I was playing Valorant. The credential the agent used expired hours later, so even if that cinema's checkout page leaked everything tomorrow, the blast radius is one movie night.
Total human effort: one sentence and one tap. Alfred would approve.
Where this goes
The pattern generalizes fast. Groceries reordered when the pantry runs low, or flights actually booked when the fare drops instead of another price alert at 3 AM. The hard problem left is trust: who's liable when an agent buys the wrong thing? That's what those competing protocols are racing to answer. But the primitive exists now. An agent with a scoped wallet, a spending cap, and an approval loop is a real butler.
Anyway. Alfred - My Butler Agent bought the tickets, my calendar is blocked for Thursday, and I will be enjoying Spider-Man: Brand New Day in a seat I did not have to fight a seat map for.
Now I just have to wait for the rest of the world to accept that the future of shopping is telling your computer "handle it" and queuing for another round of Valorant. Some of us are already living in it. With great purchasing power comes great responsibility. Thankfully, mine is capped per transaction.