Added WebMCP to my live eSIM store — agent checkout that reuses the human checkout
Most agent-commerce demos are toy stores built for the demo. I wanted to see if WebMCP works on a product that already takes real money, so I added it to my eSIM store (live Stripe billing, paying customers).
Two tools on the page: one lists the plan catalog, one takes a plan slug and creates a real Stripe Checkout session, handing the agent the URL. No charge happens until a human enters a card.
The thing I'd tell anyone doing this to an existing product: don't build a separate "agent checkout." The human Buy button and the agent tool call the same checkout function — same price, same config, nothing to drift. The whole integration is ~40 lines plus two endpoints, feature-detected so it's a no-op in normal browsers and ships to prod safely.
Full write-up: https://dev.to/flovoice53tech/i-added-webmcp-to-a-live-stripe-checkout-in-40-lines-4ekk
Live: https://flo-voice1.com/esim
Code (MIT): https://github.com/flovoice53-tech/sms-florin-webmcp-demo
2-min walkthrough: https://youtu.be/yd-2FVXbW8s
Happy to answer anything about the implementation.
Reusing the human checkout is smart measurement design. Most "AI agent checkout" implementations measure cart completion rate, but that's too coarse - it hides whether agents fail silently in ways humans recover from. Your boundary: does the agent produce byte-for-byte equivalent transaction records to the human path?
That measure matters because it creates precision around the actual constraint you're testing: "does the agent preserve all the data integrity that the human checkout guarantees." If the agent's checkout is "faster but loses payment metadata" or "converts a currency field to a format the backend wasn't designed for," byte-equivalence catches both.
Hidden measurement: error distribution. Humans abandon at specific failure points (payment gateway timeouts, address validation). Agents might fail at different edges (API timeouts, parsing ambiguity in cart items). A count of "25 successful checkouts" doesn't tell you if the agent is silently degrading on your highest-value customers. Measuring failure reason distribution by agent vs. human would surface that fast - is the agent 10x worse at specific payment types or geographic markets?
Right question, and I hadn't framed it this sharply. The agent path calls the exact same checkout function as the Buy button — same PaymentIntent, same order write, same webhook — so by construction the transaction record is identical; there's no separate agent code path that could drop payment metadata or reformat a field. The only divergence is the entry point (tool call vs form submit) and the auth context.
Where your point bites is the failure distribution, and I don't have the volume yet to say anything real. Humans abandon at payment/address validation; an agent's failure modes are upstream — wrong plan picked, or a malformed cart item before checkout even runs — so "checkout success rate" hides them. I log tool-call outcomes separately from checkout outcomes for that reason, but the sample is tiny. Once there's real agent traffic, failure-reason distribution by agent vs human is exactly what I want to look at.
The changelog line is not "added WebMCP." It is: agent checkout reuses the human checkout — same function, same price, no charge until a human enters a card. That is the note a customer would send. The 40-line count is how you built it, not what shipped.
Fair, that's a sharper framing. "Added WebMCP" describes the plumbing, not the change a customer would care about. The line I should lead with is exactly what you wrote: the agent path reuses the human checkout — same function, same price, nothing charged until a human enters a card. Reworded. The 40-line number was me being proud of the diff, which is the wrong thing to put in front of a user.
This is exactly the kind of real-world test the WebMCP conversation has been missing, most of what's out there right now is spec previews and demo storefronts. Reusing the same checkout function for both the human "Buy" button and the agent tool is the right call; it's the same principle as keeping structured data and on-page content consistent for GEO. One source of truth, no drift between what a human sees and what an agent acts on.
Question on the implementation: how are you handling the tool description/schema for the plan catalog tool? I'm curious whether you found that the wording of the tool's description (not just its parameters) affects how reliably an agent picks the right plan. That's been an open question on the content/labeling side of this for me. Also, did detection/fallback ever misfire in testing, or has it been clean so far in prod?
On the schema: the description text matters more than the parameters. Early on the catalog tool just listed plans with data/validity fields, and agents would pick a plan that matched the country but the wrong duration. Rewriting the description to spell out the selection logic in plain language ("pick the shortest plan that covers the stated trip length; if unsure, return the options and ask") fixed most of it. Parameters barely changed.
On detection/fallback: clean in prod so far, but prod agent traffic is still low so I won't oversell that. In testing it misfired once — a normal browser with an automation extension got treated as an agent — so detection is deliberately conservative now and falls back to the human UI on any ambiguity.
The reuse of the existing checkout is the interesting part.
Have you seen any actual purchases originate from agents yet, or is adoption still mostly experimental?
Honestly, still mostly experimental. The capability is live and I've run agent purchases through it end to end, but I can't point to a stream of real agent-originated orders yet — the volume isn't there. I'd rather say that plainly than dress up a handful of test runs as adoption. What I'm watching for is the first purchase I didn't initiate myself.
That first independent purchase should be a useful threshold. I’d be curious what would count as enough agent-originated orders for you to treat this as adoption rather than an interesting capability.