DEV Community: sms-florin

I added WebMCP to a live Stripe checkout in ~40 lines

sms-florin — Wed, 02 Sep 2026 05:35:13 +0000

Most "an AI agent buys something on a website" demos are toy stores built for the demo. I wanted to know if WebMCP could go onto a product that already takes real money — without rebuilding the checkout and without opening a security hole.

So I put it on my eSIM store. It sells data plans, has live Stripe billing, and has paying customers. Here's what that took.

What WebMCP is, in one paragraph

A web page calls document.modelContext.registerTool() to hand a browsing AI agent named, callable actions — instead of the agent reading your HTML and guessing which button to click. It's a W3C Community Group standard; ChatGPT's in-app browser added support in August 2026. No .well-known file, no manifest, no separate server. It's client-side JS.

The two tools

list_esim_plans — returns the live plan catalog (country, data, duration, price).
buy_esim_plan — takes a plan slug, creates a real Stripe Checkout session, and returns the URL to the agent. No money moves until a human enters card details on Stripe's own page. The tool starts a purchase; it doesn't complete a charge.

An agent goes from "find me a 7-day UK data plan" to a fully-formed Stripe checkout in two calls, no DOM scraping.

The registration

One client component, mounted on the page. On mount it feature-detects document.modelContext and, if present, registers the two tools. If absent — every normal browser — it's a silent no-op, so it ships to production safely. The whole file is ~40 lines of registration plus two execute() functions that each do one fetch.

Full source: https://github.com/flovoice53-tech/sms-florin-webmcp-demo

The one design decision that mattered

Not the protocol — the protocol is tiny. The decision was: the agent path reuses the human path.

The human "Buy" button and the buy_esim_plan tool both call the same createCheckoutSession() function. Same pricing, same metadata, same Stripe config. There is no separate "agent checkout" that can drift out of sync with the real one. The tool's endpoint just returns the session URL as JSON instead of doing a server-side redirect.

Safety

Feature-detected: no effect on any non-WebMCP browser.
buy_esim_plan cannot move money — worst case is a created-but-unpaid Stripe session that expires on its own.
The backing endpoints (GET /api/v1/esim-catalog, POST /api/v1/esim-checkout) are unauthenticated — same guest-checkout model the human form already uses — but IP rate-limited.

Result

It's live at https://flo-voice1.com/esim right now. Integration code (MIT): https://github.com/flovoice53-tech/sms-florin-webmcp-demo . 2-minute walkthrough: https://youtu.be/yd-2FVXbW8s

If you're wrapping an existing product: don't fork your checkout for the agent. Make the agent call the same function your button does.

WebMCP is not MCP: I wired real Stripe checkout into a browser AI tool, here's the code

sms-florin — Sun, 30 Aug 2026 06:20:43 +0000

WebMCP is not MCP: I wired real Stripe checkout into a browser AI tool, here's the code

WebMCP shipped as a spec four days ago (August 25, 2026, W3C Web Machine Learning Community Group), and the same day OpenAI added support for it in ChatGPT Desktop's browser. I spent yesterday wiring it into a live product — real inventory, real Stripe checkout, real money — instead of a toy demo, and I want to write down what that actually looks like in code, because most of what's out there right now is spec text and announcement posts.

WebMCP is not MCP. The name is doing you a disservice.

MCP (Model Context Protocol, Anthropic, late 2024) is a client-server protocol: your AI client — Claude Desktop, an IDE, whatever — connects out to a server process you run, over stdio or HTTP, and that server exposes tools. The server has no idea it's running inside a browser or a chat client. It just answers JSON-RPC calls.

WebMCP flips that. It's a browser API: document.modelContext.registerTool(). A web page, running in a user's actual browser tab, registers tools directly with whatever AI agent is embedded in or driving that browser. There's no separate server process, no protocol handshake, no client you have to configure to "connect" to your site. If the page is open and the browser is WebMCP-aware, the tools exist. If it's a normal browser, document.modelContext is undefined and nothing happens — it's naturally feature-detected, not an opt-in flag you flip.

Practically: MCP is "give an AI client a new server to talk to." WebMCP is "give this specific page's visitor's agent something to click for them, without it having to guess at your DOM." Same three letters in the acronym, unrelated plumbing.

What I built: two tools on a real product page

sms-florin sells phone numbers and eSIMs — the eSIM catalog page (/esim) is real: 10 SKUs across 5 countries, live Stripe Checkout, no test mode. I added a client component that registers two tools the moment the page mounts, and does nothing if document.modelContext isn't there:

// src/app/esim/webmcp-tools.tsx
"use client";

export function WebmcpTools() {
  useEffect(() => {
    const modelContext = (document as unknown as {
      modelContext?: { registerTool: (...) => Promise<void> };
    }).modelContext;
    if (!modelContext) return;

    const controller = new AbortController();

    modelContext.registerTool(
      {
        name: "list_esim_plans",
        description:
          "List available eSIM data plans (country, data amount, duration, price in USD).",
        inputSchema: { type: "object", properties: {} },
        execute: async () => {
          const res = await fetch("/api/v1/esim-catalog");
          return await res.json();
        },
      },
      { signal: controller.signal },
    );

    modelContext.registerTool(
      {
        name: "buy_esim_plan",
        description:
          "Start a real purchase for an eSIM plan by its slug (from list_esim_plans). " +
          "Navigates to a real Stripe checkout page — no charge happens until a human " +
          "enters card details there.",
        inputSchema: {
          type: "object",
          properties: {
            slug: { type: "string", description: "Plan slug, e.g. 'uk-1gb-7d'" },
          },
          required: ["slug"],
        },
        execute: async ({ slug }) => {
          const res = await fetch("/api/v1/esim-checkout", {
            method: "POST",
            headers: { "content-type": "application/json" },
            body: JSON.stringify({ slug }),
          });
          const data = await res.json();
          if (data.checkoutUrl) {
            window.location.href = data.checkoutUrl;
            return `Redirecting to checkout: ${data.checkoutUrl}`;
          }
          return data.error ?? "Could not start checkout.";
        },
      },
      { signal: controller.signal },
    );

    return () => controller.abort();
  }, []);

  return null;
}

Two things worth calling out. First, registerTool's execute runs in the page's own JS context, with the page's own cookies, origin, and CSP — it's not a sandboxed RPC to some remote definition. Second, the AbortController cleanup matters more than it looks: if this were a SPA route and the component unmounted, stale tools with closures over a dead page would otherwise sit registered.

Both tools call the same public JSON endpoints the page itself would use if this were rendered as an API instead of HTML — GET /api/v1/esim-catalog and POST /api/v1/esim-checkout. I didn't invent a new surface for the agent; I exposed the existing data and existing checkout flow as JSON, because a WebMCP tool's execute() needs to return a value or navigate — it can't do a server-side redirect the way a Next.js form action can.

Why the checkout logic lives in one shared function

The interesting design decision wasn't the tool registration, it was making sure the AI-agent path and the human path are provably the same Stripe session logic, not two implementations that can drift.

// src/lib/esim-checkout.ts
export async function createEsimCheckoutSession(
  slug: string,
): Promise<{ url: string } | { error: string }> {
  const plan = getEsimPlanBySlug(slug);
  if (!plan) return { error: "Invalid plan." };

  const planLabel = `${plan.label} ${plan.dataAmount} / ${plan.durationDays} days`;
  const stripe = getStripe();
  const session = await stripe.checkout.sessions.create({
    mode: "payment",
    payment_method_types: ["card"],
    billing_address_collection: "required",
    line_items: [{
      price_data: {
        currency: "usd",
        product_data: { name: `eSIM — ${planLabel}` },
        unit_amount: plan.priceCents,
      },
      quantity: 1,
    }],
    metadata: { type: "esim", packageCode: plan.packageCode, planLabel },
    success_url: `${APP_URL}/esim/success?session_id={CHECKOUT_SESSION_ID}`,
    cancel_url: `${APP_URL}/esim`,
  });

  if (!session.url) return { error: "Could not create the payment session." };
  return { url: session.url };
}

This one function is called from two places: the existing server action behind the human "Buy" button on /esim (which redirects the browser directly, Next.js-style), and the new /api/v1/esim-checkout route (which the buy_esim_plan tool calls, and which returns the URL as JSON instead of redirecting, because a fetch() inside execute() needs a value back, not a 303).

// src/app/api/v1/esim-checkout/route.ts
export async function POST(request: NextRequest) {
  const ip = await getClientIp();
  if (!checkRateLimit(`esim-checkout:${ip}`, 10, 60 * 60 * 1000)) {
    return NextResponse.json({ error: "rate limited" }, { status: 429 });
  }

  const body = await request.json().catch(() => null);
  const parsed = buyEsimSchema.safeParse(body);
  if (!parsed.success) {
    return NextResponse.json({ error: "Invalid plan." }, { status: 400 });
  }

  const result = await createEsimCheckoutSession(parsed.data.slug);
  if ("error" in result) {
    return NextResponse.json({ error: result.error }, { status: 400 });
  }

  return NextResponse.json({ checkoutUrl: result.url });
}

Same Zod validation (buyEsimSchema), same rate limiting (checkRateLimit, keyed on IP, 10/hour on checkout, 60/minute on catalog reads), same Stripe session creation. The only fork in the road is the last line: redirect vs. JSON. Everything a human path already had to get right — bad slugs, abuse, Stripe error handling — the agent path gets for free, because it's not a separate implementation, it's the same function with a thinner wrapper.

The catalog endpoint is the boring half, deliberately:

// src/app/api/v1/esim-catalog/route.ts
export async function GET(request: NextRequest) {
  const ip = await getClientIp();
  if (!checkRateLimit(`api:esim-catalog:${ip}`, 60, 60 * 1000)) {
    return NextResponse.json({ error: "rate limited" }, { status: 429 });
  }

  return NextResponse.json({
    plans: ESIM_CATALOG.map((plan) => ({
      slug: plan.slug,
      country: plan.country,
      dataAmount: plan.dataAmount,
      durationDays: plan.durationDays,
      priceCents: plan.priceCents,
    })),
  });
}

It's the exact same ESIM_CATALOG array that renders the pricing cards on the page, just mapped to JSON instead of JSX. No agent-only pricing, no shadow catalog that can go stale relative to what a human sees.

Why "no toy demo" is the whole point

It would be easy to build a WebMCP tool that calls a mock endpoint and prints a fake confirmation — a lot of the example repos floating around right now do exactly that, understandably, since the spec is four days old. I wanted to know what actually breaks when the tool is wired to a live Stripe account instead.

The honest answer: nothing broke, because the design constraint I put on myself was that no money moves inside execute(). buy_esim_plan does not charge a card. It creates a Stripe Checkout Session and hands back a URL. The agent (or the human driving it) still lands on checkout.stripe.com, still has to type in a real card number, still sees Stripe's own fraud checks and 3-D Secure flow. The WebMCP tool's entire job is to save the human the five clicks of picking a plan from a page — it deliberately stops exactly at the boundary where PCI scope and "did a human actually authorize this charge" would become real questions. That boundary isn't a workaround I bolted on for the demo; it's just where a Checkout Session naturally ends and Stripe's hosted page begins, so it cost nothing to keep the agent path honest.

That's also why I didn't try to make the tool "smarter" — no auto-selecting a plan based on inferred intent, no skipping the redirect. A buy_esim_plan tool that silently picked the most expensive plan or found a way to skip the human at the card page would be a much more interesting attack surface than a useful feature.

Code and live product

Demo repo (extracted, minimal, MIT): https://github.com/flovoice53-tech/sms-florin-webmcp-demo
Live page these tools are actually registered on: https://flo-voice1.com/esim (open it in a WebMCP-aware browser and document.modelContext will be populated; anywhere else, the page just works like a normal Next.js page, because that's all it is otherwise).

If you're building on WebMCP and hit anything about the execute()-can't-redirect constraint, or how you're structuring shared logic between the human path and the tool path, I'd genuinely like to compare notes — leave a comment.

A real inbox for your test suite, no signup: I built receivemail.dev

sms-florin — Fri, 28 Aug 2026 06:36:24 +0000

Ever needed to test a signup flow, a "verify your email" link, or a password reset — and had to either burn a real personal inbox or wire up some heavyweight mail-testing service just to check one email arrived?

I built receivemail.dev for exactly that. One API call gets you a real, receiving email address. No signup, no account, no SMTP config.

# create a mailbox (default: expires in 15 min)
curl -X POST https://receivemail.dev/mailboxes
# => {"address":"a1b2c3d4e5f6@receivemail.dev","expiresAt":"...","secret":"..."}

# trigger your app's email, then poll:
curl https://receivemail.dev/mailboxes/a1b2c3d4e5f6@receivemail.dev/messages \
  -H "Authorization: Bearer <secret from above>"
# => {"address":"...","messages":[{"from_address":"...","subject":"...","body_text":"..."}]}

That secret returned at creation is the only credential — there's no login. It's the same "just enough auth, no account system" pattern as a lot of the disposable-testing tools I like using myself.

How it's built: fully serverless — Cloudflare Email Routing receives the actual mail, a Worker parses it and stores it in D1, a small REST API serves it back. No shared infra with anything else I run, so it's isolated by design.

It's free. Cloudflare's free tier (100k Worker requests/day, 5M D1 reads/day, unlimited Email Routing) covers this comfortably at the traffic I'd expect, so there's no billing to worry about — 20 mailbox creates/min per IP, 60-minute max lifetime, that's the whole limit.

Source: https://github.com/flovoice53-tech/receivemail-worker

I also build sms-florin (rent a real UK phone number for SMS/OTP testing) and otp-watch (synthetic monitoring — does your OTP actually arrive, and how fast?) — this fills the email-side gap in the same "test real verification flows without burning a real identity" story.

Feedback welcome, especially if you hit the rate limits and need something higher-volume.

Your uptime monitor checks if your API returns 200. It doesn't check if your OTP actually arrives.

sms-florin — Thu, 27 Aug 2026 02:48:49 +0000

Every synthetic-monitoring tool (Checkly, Pingdom, Better Stack, Datadog Synthetics) can tell you your signup endpoint responded correctly. None of them tell you whether the SMS or email your OTP provider promised to send actually showed up in a real inbox or a real phone — or how long it took. You usually find out the same way your users do: a support ticket, or a spike in abandoned signups you can't explain.

So I built otp-watch — a small hosted service that answers exactly that question, live at https://otpwatch.flo-voice1.com.

How it works

You ask it for a real target, trigger your own verification send to it (same as you would for a real user), then poll for what happened:

# get a key, no signup
curl -X POST https://otpwatch.flo-voice1.com/keys \
  -H "Content-Type: application/json" -d '{"email":"you@example.com"}'

# start a check
curl -X POST https://otpwatch.flo-voice1.com/checks \
  -H "Authorization: Bearer otpw_..." \
  -H "Content-Type: application/json" \
  -d '{"channel":"sms","timeoutSeconds":120}'
# => {"id":"...", "target":"+447...", "status":"pending"}

# now trigger your own OTP send to that number/address, then poll:
curl https://otpwatch.flo-voice1.com/checks/<id> -H "Authorization: Bearer otpw_..."
# => {"status":"received", "latencyMs":4213}

channel is sms (a real UK phone number) or email (a real disposable mailbox). Whichever you pick, otp-watch doesn't touch your app at all — it just answers "did anything arrive at this target, and when."

What it deliberately doesn't do

No scheduling — bring your own cron/CI. A GitHub Actions job that runs every 30 min and fails on timed_out is the alerting; I didn't want to rebuild PagerDuty for v1.
No webhooks yet — you poll GET /checks/:id.
SMS is UK-only for now (real GOIP hardware behind it, not a VoIP/virtual number — same infrastructure as sms-florin).
No billing yet. It's free while unproven — each SMS check rents a real number, so the cost is real, just absorbed on my side for now.

Scoped this tightly on purpose (built in about a day) rather than a full monitoring platform — happy to extend it (more countries, webhooks, scheduling) if there's real interest.

If you're also testing signup flows with an AI agent, agent-identity-mcp uses the same underlying phone/email primitives from the agent side — disposable identity for testing vs. delivery monitoring for production are two sides of the same infrastructure.

Repo: https://github.com/flovoice53-tech/otp-watch
Live: https://otpwatch.flo-voice1.com

Testing an AI shopping agent's checkout flow? There's no sandbox for that yet — so I built one

sms-florin — Wed, 26 Aug 2026 06:46:59 +0000

If you're building or evaluating an AI agent that can shop and check out on its own, you've probably run into the new "agentic commerce" protocols: ACP (OpenAI + Stripe + Meta), AP2 (Google), and UCP. They define how an agent talks to a merchant to create a checkout session, apply a payment token, and get an order back.

Stripe's own test mode covers the payment half fine — test cards, test API keys. But there's no hosted "fake merchant" you can point your agent at to verify the protocol half: does your agent correctly create a session, handle a 422 idempotency conflict, parse the order response, retry politely? You either mock it yourself from the spec, or risk finding out against a real merchant.

So I built acp-sandbox — a small hosted mock merchant implementing the ACP checkout API, live at https://acp-sandbox.flo-voice1.com.

What it does

It implements the real checkout_sessions lifecycle from ACP's 2026-04-17 spec: create, retrieve, update, complete, cancel. Responses match the actual CheckoutSession/Order/Error schemas for the fields it supports — I pulled the OpenAPI spec directly rather than guessing field names.

# get a test key, no signup
curl -X POST https://acp-sandbox.flo-voice1.com/keys \
  -H "Content-Type: application/json" -d '{"email":"you@example.com"}'

# create a session against the demo catalog
curl -X POST https://acp-sandbox.flo-voice1.com/checkout_sessions \
  -H "Authorization: Bearer acps_test_..." \
  -H "Content-Type: application/json" \
  -d '{"line_items":[{"id":"item_demo_headphones","quantity":1}],"currency":"usd"}'

Every request/response is logged per API key (GET /logs), so you can see exactly what your agent sent when something doesn't work.

What it deliberately doesn't do (yet)

No real payment processing — complete always succeeds once you send any payment_data.
No OAuth delegate_authentication flow.
No fulfillment options (shipping/pickup) — every session goes straight to ready_for_payment.
Fixed demo catalog (4 items), not a real product feed — feed ingestion is a merchant-onboarding concern, not something your checkout-testing agent needs to exercise.

ACP is still beta (5 spec revisions in about 7 months), so this will need upkeep as the protocol moves. Scoped tightly on purpose rather than trying to cover AP2/UCP too — happy to extend it if there's real interest.

If you're also building agent-identity-mcp or similar (disposable email/phone for AI agents to use as a buyer identity), it pairs directly with this — identity on one side, a merchant to check out with on the other.

Repo: https://github.com/flovoice53-tech/acp-sandbox
Live: https://acp-sandbox.flo-voice1.com

How to Set Up Two-Factor Authentication Without Using Your Personal Phone Number

sms-florin — Wed, 26 Aug 2026 05:55:45 +0000

Many account ecosystems push new and recovered accounts toward two-factor authentication, which requires at least one trusted phone number to receive verification codes. That's inconvenient if you're setting up a test account for development, managing an account for a device pool, or don't want a personal account tied to your own number.

Steps

Rent a number — an instant rental covers the initial verification.
During account setup (or in the account's security settings), add the rented number as a trusted phone number and request a code.
It sends a verification code by SMS within seconds on a working number.
Enter the code from your rental's status page to complete verification.

Instant or monthly?

An instant rental covers the initial setup. If you plan to keep the trusted number on the account long-term (some ecosystems occasionally re-verify it), a monthly rental keeps it reachable instead of a one-off.

How to Verify an International Trading Platform Without Using Your Personal Phone Number

sms-florin — Wed, 26 Aug 2026 05:54:23 +0000

Many international trading platforms ask for phone verification at signup and can prompt for it again on login from a new device or location. As with any financial platform, that permanently links your real number to a financial account — not ideal if you're testing, running more than one account, or would rather keep that number private.

Steps

Rent a number for the platform you're signing up with — an instant rental is enough to get through signup.
Enter the rented number, with country code, on the platform's phone-verification step.
It sends an SMS code, typically within seconds.
Enter the code shown on your rental's status page to finish verifying.

Instant or monthly?

Instant covers a single signup. If you're keeping the account long-term and expect the platform to re-verify by SMS on future logins, a monthly rental keeps the same number reachable instead of expiring right after the first code.

How to Verify a Social Network Account Without Using Your Personal Phone Number

sms-florin — Wed, 26 Aug 2026 05:54:22 +0000

Most large social networks let you sign up with either an email or a phone number, but they frequently prompt for phone verification anyway — especially on new accounts, when logging in from a new device, or after an automatic security flag asks you to "confirm it's really you." That's inconvenient if you're testing a signup flow, managing a second account for a project, or don't want a social network holding your personal number.

Steps

Rent a number for the social network you're signing up with — an instant rental covers the one-time verification.
When the platform asks for a phone number (at signup, or in a "confirm your identity" security prompt), enter the rented number with its country code.
It sends a verification code by SMS, usually within seconds.
Enter the code from your rental's status page to finish verifying.

Instant or monthly?

An instant rental is enough for a one-time signup or security check. If you expect the platform to text the same number again later (repeated login-approval prompts on a new account are common), a monthly rental keeps it reachable instead of releasing it right after the first code.

How to Verify a Productivity Suite Account Without Using Your Personal Phone Number

sms-florin — Wed, 26 Aug 2026 05:53:24 +0000

Many productivity suites let you sign up with just an email, but frequently ask for a phone number anyway — during signup as an extra security step, or later when a login looks unusual and it wants to "verify it's you." That ties a real number to the account just to get past a routine check, which is a problem if you're testing a signup flow, managing more than one account, or don't want it tied to your personal number.

Steps

Rent a number for the account you're setting up — an instant rental covers the one-time verification.
When it asks for a phone number (at signup, or in a security-verification prompt), enter the rented number with its country code.
It sends a verification code by SMS, usually within seconds.
Enter the code from your rental's status page to finish verifying.

Instant or monthly?

An instant rental is enough for a one-time signup or security check. If you expect repeated verification prompts on the same account, a monthly rental keeps the number reachable instead of releasing it right after the first code.

How to Verify a Photo-Sharing App Without Using Your Personal Phone Number

sms-florin — Wed, 26 Aug 2026 05:52:48 +0000

Popular photo-sharing apps increasingly ask for phone verification at signup, after a suspicious-login flag, or when creating an additional account on the same device. If you manage a second account for a business, a project, or testing, tying every one of them to your own number gets messy fast — and their own device/number fingerprinting can flag multiple accounts sharing a number differently than it flags a fresh one.

Steps

Rent a number for the app — an instant rental covers a one-time signup or recovery code.
Enter the number (with country code) wherever the app's flow is asking for it — signup, "Confirm your number", or the account-recovery form.
The app sends a 6-digit code by SMS, usually within a few seconds.
Enter the code from your rental's status page to finish verification.

Instant vs. monthly

An instant rental is fine for a one-off signup. If the account is for an ongoing project (a business page, a bot-adjacent account you'll need to re-verify into later), a monthly rental keeps the same number reserved so a future 'suspicious login' prompt can text the same number again instead of locking you out with no way to receive the new code.

How to Verify an Online Payment Account Without Using Your Personal Phone Number

sms-florin — Wed, 26 Aug 2026 05:52:45 +0000

Online payment platforms often ask for phone verification when opening a new account, and again for certain security prompts later (a login from an unrecognized device, enabling two-factor authentication). Freelancers and sellers running a separate business account, or anyone testing a checkout integration, often want that number to be independent of their personal line.

Steps

Rent a number for the payment platform you're signing up with — an instant rental is enough for the initial verification code.
Enter the number (with country code) in the platform's phone-verification step, during signup or when prompted for a security check.
It texts a verification code, usually within seconds.
Enter the code from your rental's status page to finish.

Worth knowing for a business account

If this number is for an ongoing business account rather than a one-off signup, a monthly rental keeps it reserved so the platform can text the same number again for future security checks, instead of the number becoming unreachable right after the first code.

How to Verify an Online Shopping Account Without Using Your Personal Phone Number

sms-florin — Wed, 26 Aug 2026 05:52:08 +0000

Most large shopping platforms don't require a phone number to create an account, but they push two-step verification hard during signup and account-security prompts, and enabling it (or resolving a suspicious-activity check) means handing over a number that gets an SMS code. Not ideal if you're testing a signup or checkout flow, running a second account, or don't want a shopping platform holding your personal number.

Steps

Rent a number for the shopping platform you're signing up with — an instant rental covers the one-time verification.
On the platform's two-step verification or security-check screen, enter the rented number with its country code.
It sends a verification code by SMS, usually within seconds.
Enter the code from your rental's status page to finish verifying.

Instant or monthly?

An instant rental covers a one-time setup. If you expect the platform to text the same number again later — repeated two-step prompts are common on an account used for testing — a monthly rental keeps it reachable instead of releasing it right after the first code.