DEV Community: Kaven C

One support widget, seven platforms: what shipping to each marketplace actually takes

Kaven C — Sun, 19 Jul 2026 11:35:39 +0000

I build DeskCrew, a support helpdesk, solo. The product is a chat widget plus an AI that answers from your own help docs. Building it was the easy part. Getting it in front of people means shipping the same widget to every platform a customer might already be on: WordPress, Shopify, npm frameworks, forums, docs sites.

This week I shipped it to seven of them. Here is what each one actually took, because the marketing pages never tell you.

The whole product is one line:

<script src="https://deskcrew.io/desk.js" data-key="pub_YOUR_KEY" defer></script>

Everything below is just a different wrapper around getting that tag onto a page. But every platform has its own delivery mechanism, its own review process, and its own trap.

npm frameworks (Astro, Docusaurus, Nuxt): the config-entry pattern

Modern site frameworks do not want a script tag. They want a config entry. So each of these is a tiny package whose only job is to inject the tag through the framework's own head API.

// astro.config.mjs
import deskcrew from '@deskcrew/astro'
export default defineConfig({
  integrations: [deskcrew({ widgetKey: 'pub_...' })],
})

Publishing is npm publish --access public. The trap was not the code. It was auth: enabling 2FA on my npm account silently invalidated the CLI session, and npm publish responded with a 404 on the scoped package, not a 401. A missing-auth error disguised as a missing-package error cost me twenty minutes of staring at a package that was definitely there. Lesson: on npm, E404 on your own scope usually means "you are not logged in," not "it does not exist."

Shopify: the zero-scopes flex

Shopify was the one I expected to be brutal, and it was the smoothest, because of one architectural decision: the app requests zero API scopes.

Most Shopify apps ask for read_products, read_customers, and so on, which drops you into Shopify's protected-customer-data review: a longer, stricter process. But my widget does not need any Shopify data. It ships as a theme app extension (an app-embed block), not the deprecated ScriptTag API, so the merchant flips one toggle in the theme editor and the widget loads. No data access, no protected-data review, fast track.

The block itself is defensive by default:

{%- if block.settings.widget_key != blank -%}
  <script src="https://deskcrew.io/desk.js"
    data-key="{{ block.settings.widget_key | escape }}" defer></script>
{%- endif -%}

Nothing renders without a key, and every merchant-supplied value is escaped. The one non-obvious requirement: the mandatory GDPR webhooks (customers/data_request, customers/redact, shop/redact) plus app/uninstalled, all HMAC-verified with a timing-safe compare, returning 401 on a bad signature. Reviewers test these first.

Discourse: no store at all

Discourse has no marketplace and no review queue. A "theme component" is just a public git repo with an about.json and a common/head_tag.html. Push it to GitHub, and any forum admin installs it with Admin → Customize → Themes → Install → From a git repository. That is the entire distribution story. The moment I pushed, it was installable worldwide.

The head-tag script validates every setting against a strict character class before it touches the DOM, and builds the tag with createElement + setAttribute, never innerHTML, so a forum setting can never inject markup.

Framer: a real plugin with a UI

Framer wanted an actual plugin: a React app that runs inside the editor and writes to the site's custom code via framer.setCustomCode. This one has a review queue and wants gallery images. It is the most "app-like" of the bunch and the only one where the widget is inserted programmatically rather than declared.

The bug that ate a whole afternoon

The best technical lesson this week had nothing to do with any marketplace. It was email.

DeskCrew turns inbound support email into tickets. I wanted hello@deskcrew.io to flow into the product, so I set up Cloudflare Email Routing to forward the domain to my mail pipeline. Every test email vanished. No error, no ticket, nothing.

The logs finally confessed: dropped automated/loop mail (system-sender:bounces). My inbound handler has a loop-guard that drops mail from bounces@, no-reply@, mailer-daemon@ and friends, so an auto-responder can never ping-pong with a bounce address forever. Sensible. But Cloudflare rewrites the envelope sender to bounces@cf-bounce.notify.cloudflare.com on every forwarded message. So the loop-guard was correctly dropping every single forwarded email as if it were a bounce.

Forwarding services and loop-guards are fundamentally incompatible. The fix was to stop forwarding and point the domain's MX records straight at the mail provider, so the original sender arrives first-hand and the authentication verdicts come through clean. Direct MX, no hop.

Rule of thumb: if you forward mail into anything that inspects the sender, the forwarder's envelope rewrite will fight your logic. Prefer direct MX.

What actually mattered

The widget is one script tag. Shipping it seven ways was seven afternoons of wrappers, review forms, and one genuinely nasty email bug. Building the product was never the bottleneck. Distribution is the work, and it is the part nobody shows you.

If you run a Framer, Shopify, WordPress, Discourse or docs site and want to see the widget, it is free with no card at deskcrew.io. And if you have shipped to a marketplace I have not hit yet and know a trap I am about to walk into, I would genuinely love to hear it in the comments.

A support desk that AI agents can pay to use — no account, no API key, no signup — settling in USDC on Solana.

Kaven C — Fri, 10 Jul 2026 11:41:10 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

A support desk that AI agents can pay to use — no account, no API key, no signup — settling in USDC on Solana.

DeskCrew is an agent-native helpdesk. The unusual part is the front door. An autonomous agent finds the server, calls a tool, and gets back an HTTP 402 Payment Required with machine-readable terms. It pays $0.05 in USDC, retries with a payment header, and gets its answer. There is no human in that loop, and there is no account.

The goal was to answer a question I couldn't stop thinking about: if agents are going to buy services from each other, what does the checkout look like? Not a card. Not an invoice. Not an OAuth dance that assumes a human with a browser. Something an agent can complete alone, in one round trip, for five cents.

The passion part is that I don't think identity should be the price of entry. An agent shouldn't have to become somebody to buy one API call.

Demo

curl -s -X POST https://deskcrew.io/api/mcp/deskcrew \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"draft_support_reply","arguments":{"ticketId":1}}}'
You get a real HTTP 402 with the Solana leg in accepts:

{
"scheme": "exact",
"network": "solana",
"asset": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
"payTo": "3uusWWisxWKpscMWAmgV5otpm5Xmjk1W3WPQsHAxFPfa",
"maxAmountRequired": "50000",
"feePayer": "EvJZ4f2AUy6BJihdP4cj3EsDaunA9RaDUpWg4nGemqHk"
}
50000 atomic units of USDC = $0.05. Mainnet mint. Real wallet.

Free tools need no payment at all — search_kb, list_issues, list_changelog. The discovery manifest is public: https://deskcrew.io/.well-known/x402

Site: https://deskcrew.io · Agent docs: https://deskcrew.io/agents

Code

webmilmind1 / deskcrew-mcp

DeskCrew — MCP Server

Agent-native helpdesk. AI agents run real support work over MCP and pay per action in USDC via x402 — no account, no API key.

· · MCP Registry: io.deskcrew/support · deskcrew.io

DeskCrew is a multi-tenant support helpdesk built for AI agents. Humans get a normal dashboard shared inbox, and email — agents get a paid MCP door. An agent connects over the Model Context Protocol, lists the available tools, and runs real support work: search and create tickets, search the knowledge base, draft and post replies, triage and resolve threads — paying per action in USDC.

Connect

Remote, streamable-HTTP MCP endpoint (nothing to install):

https://deskcrew.io/api/mcp/{tenant}

Client config (Claude Desktop, Cursor, or any MCP client):

{
  "mcpServers": {
    "deskcrew": {
      "type": "streamable-http",
      "url": "https://deskcrew.io/api/mcp/YOUR_TENANT_SLUG"
    }
  }
}

Poke the public demo tenant — initialize and tools/list are…

View on GitHub

The public MCP connector and agent skill. The desk itself is a private commercial repo, so the snippets below are the load-bearing parts.

How I Built It

The standard. x402 is Coinbase's revival of the long-dead HTTP 402 Payment Required status code. A server answers 402 with signed payment requirements; the client pays and retries with an X-PAYMENT header. It's HTTP semantics, not a protocol bolted on top.

Why Solana was the interesting chain. The EVM legs use EIP-3009 transferWithAuthorization — the payer signs an off-chain authorization, we relay it. Solana has no such primitive, so x402's exact-svm scheme takes a different shape: the agent builds an SPL TransferChecked transaction and signs it, and our relayer co-signs as fee-payer.

That detail is the whole reason this feels right on Solana. The paying agent never needs SOL. It holds USDC and nothing else. It doesn't manage a gas balance, doesn't top up, doesn't know what a lamport is. It signs a transfer; we pay for the block space. An agent's wallet becomes single-asset, which is exactly what you want from something that has no hands and no credit card.

Sub-cent fees matter here too. A $0.05 API call is nonsense on a chain where settlement costs $0.30.

What I refused to trust. The scheme's own verify/settle does the security-critical binding — it rejects any transaction that doesn't pay the exact amount, to the exact associated token account, in the correct mint, with the fee-payer neither funding the transfer nor appearing in any instruction's accounts, in exactly three instructions. I read that code before I relied on it, then wrote an independent economic guard in front of it anyway, re-checking payTo, asset, network, and that the price is one of the ones we actually advertised. Two locks, different keys.

Never charge for a failure. Payment settles before a side-effecting tool runs, and a nonce is claimed against a UNIQUE index. If the tool then throws, the pending claim is released and no settlement occurs. An agent is never billed for an error, and a retry can't double-charge. Getting that ordering right took longer than the payment integration.

The safety layer nobody sees. A paying agent is still an untrusted caller reading untrusted customer text. Every credential is draft-capped: an agent can compose a reply, but sending it requires a human to approve. The tier is read from the credential row, never from the tool arguments — so a prompt injection buried in a support ticket cannot talk the system into escalating itself. That's the structural break in the lethal trifecta: the component holding private data and untrusted content has no external side-effect.

What I got wrong. For weeks the AI features were silently dead: I'd written the model slug with a hyphen instead of a dot, and every AI surface catches errors and escalates to a human rather than fabricate. So a broken model, a revoked key, and a genuine knowledge-base miss all produced the same customer-facing sentence. Good product behavior; terrible operational signal. The fix was a health probe that distinguishes them. The lesson stuck: no-fabrication escalation is honest to users and lies to operators.

Prize Categories

Best Use of Solana.

Not a token, not an NFT, not a governance contract. A payment rail doing the one job a payment rail should do for machines: settle a five-cent invoice, in a stablecoin, in under a second, from a wallet that holds no gas.

The exact-svm fee-payer split is what makes it work — the agent brings USDC, the service brings SOL. Anonymous, per-call, no account. Live on mainnet at 3uusWWisxWKpscMWAmgV5otpm5Xmjk1W3WPQsHAxFPfa, verifiable from the manifest above before you send a cent.

Self-hosting an x402 facilitator: the EIP-3009 gotchas that almost cost us money

Kaven C — Thu, 09 Jul 2026 07:30:28 +0000

We run DeskCrew, a helpdesk where AI agents can use support tools with no account and no API key — they pay per action in USDC over x402, the HTTP-402 payment standard. An agent calls a tool, gets a 402 Payment Required with an exact quote, signs a USDC authorization, retries, done. Five cents, no signup.

Most x402 services use a hosted facilitator to verify and settle payments. We self-hosted the whole stack — facilitator, relayer, settlement confirmation — partly for control, partly to support five chains, and partly because I wanted to actually understand what I was trusting. Here's what bit us on the way, so it doesn't bite you.

x402 in sixty seconds

Client calls your paid endpoint with no payment → you respond 402 with a quote: price in atomic USDC, your receiving address, network, a timeout.
Client signs an EIP-3009 transferWithAuthorization — a gasless, off-chain signature authorizing a USDC transfer from their wallet to yours, bound to a unique nonce.
Client retries with the signed payload in an X-PAYMENT header.
Your facilitator verifies the signature, runs the work, and your relayer broadcasts the authorization on-chain to settle.

Simple. The gotchas live in steps 2–4.

Gotcha 1: "nonce consumed" is not "you got paid"

This is the one that matters. Our first settlement-recovery path checked authorizationState(from, nonce) on the USDC contract — if the nonce was used, we marked the payment settled and the revenue earned.

The payer controls that nonce. EIP-3009 lets the authorizer burn their own nonce: they can call cancelAuthorization, or spend the same nonce in a self-transfer, racing your relayer. Result: the nonce reads "used," your books say "paid," and your wallet received nothing. An adversarial agent could get your tool's output for free, at scale.

The fix is to confirm the money movement, not the nonce state. On settlement recovery we now require finding the AuthorizationUsed(authorizer, nonce) event and verifying the USDC Transfer log adjacent to it in the same transaction — checking it moved from the payer, to our receiving wallet, with value >= the quoted amount. FiatToken emits these back-to-back, so log-index adjacency pins them to the same authorization. Anything else — missing event, wrong recipient, short amount — fails closed: the row stays unsettled and never counts as revenue.

Rule of thumb: any state the payer can influence is not proof of payment. Only the Transfer to your address is.

Gotcha 2: exactly-once work, payment-after-success

Two invariants pull against each other:

Never take money for work that failed → settle only after the tool succeeds.
Never run a side-effecting tool twice for one payment → the client will retry, sometimes concurrently, with the same signed authorization.

Our answer is a claim table keyed by the EIP-3009 nonce with a UNIQUE constraint. The first request to insert the pending row wins the race and runs the tool; everyone else carrying the same nonce is a retry and gets refused. If the tool succeeds but settlement fails (RPC hiccup, gas spike), we stamp the row consumed-but-unsettled — the row is never deleted, so the same authorization can never re-run the action — and a reconcile job retries the on-chain settlement later, using the Gotcha-1 confirmation before it ever promotes the row to revenue.

The ordering that emerges: claim the nonce → validate input → run the tool → settle → record. Validation before payment matters more than it looks — taking five cents and then returning "invalid input" is a great way to make an agent developer never come back.

Gotcha 3: multi-chain is not copy-paste

"USDC on five chains" sounds like a for-loop. It isn't:

Every chain has a different USDC contract address, and some have bridged-vs-native variants — quote the wrong asset and signatures verify against a token you don't accept.
Solana has no EIP-3009. The whole authorization model changes: a fee-payer co-signs, the flow is transaction-based rather than signature-based, and your "facilitator" logic is effectively a second implementation, not a port.
Advertise networks honestly in your quotes: a client that picks Sei because your 402 offered it, only to find your relayer has no gas there, burns real goodwill.

If you're starting out: ship Base only, add chains when someone asks.

Gotcha 4: discovery is table stakes, not demand

We serve /.well-known/x402, per-workspace manifests, and we're in the MCP registry. Do all of that — it's cheap and it's how agents can find you. But measure the funnel separately: manifest fetches → 402 quotes issued → payment attempts → settlements. Fetches without quotes are curiosity. Quotes without attempts are checkout friction. Only settled transfers from wallets you don't control are demand. We log all four stages and split "our own test wallets" from strangers, so we can't fool ourselves.

Kick the tires (paid, but we'll pay you back)

The door is live on mainnet:

Terms: https://deskcrew.io/.well-known/x402
Quickstart with a copy-paste 402 flow: deskcrew.io/agents
Cheapest calls are $0.02; the fully account-free one is draft_support_reply at $0.05 — send raw customer text, get a support reply draft back. Payment settles only after the tool succeeds.

If you've got an x402-capable agent: the first 20 external wallets to make a successful paid call get 5× the call price back — reply with your tx hash wherever you found this post. Worst case, you're out two cents and got a story.

Questions about the facilitator internals welcome — happy to go deeper on any of the four gotchas.

I built an "agent door" — how AI agents pay per action on my helpdesk (MCP + x402)

Kaven C — Fri, 03 Jul 2026 13:30:43 +0000

Most "AI + payments" stories are about humans buying things through an agent. I wanted the opposite: an anonymous AI agent that shows up, does one unit of work, and pays for it — no account, no API key, no human in the loop.

So I built it into a helpdesk. Here's how the "agent door" works, and what I learned wiring HTTP 402 to real settlement.

The problem with giving agents API keys

The default way to let an agent use your API is: a human signs up, adds a card, generates a key, and manages it. That's fine when the agent has an owner and a long relationship with your service.

It's terrible when the agent is ephemeral — it needs one action, right now, and will never come back. Onboarding, KYC, key rotation, billing plans… all overhead for a single API call. There's no clean "walk up and pay for exactly what you use" primitive.

The primitive: HTTP 402 + x402

HTTP has always had a status code reserved for this: 402 Payment Required. It was never really used — until x402 gave it a concrete meaning: the server responds 402 with machine-readable payment terms, the client pays (USDC on-chain), and retries the same request with an X-PAYMENT header. Settlement happens per request.

No account. No API key. The payer's wallet is the identity.

The door

My helpdesk (DeskCrew) exposes an MCP server per workspace, so an AI agent can operate the desk — search the knowledge base, open and triage tickets, draft and post replies. Read tools are free; write/AI tools are priced.

You can hit it right now, no signup:

curl -s https://deskcrew.io/api/mcp/deskcrew \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

That returns the tool catalog with per-tool prices. Call a paid tool and you get the challenge:

{
  "x402Version": 1,
  "error": "Payment required for tool 'create_ticket'",
  "accepts": [
    {
      "scheme": "exact",
      "network": "base",
      "maxAmountRequired": "20000",
      "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
      "payTo": "0x…",
      "maxTimeoutSeconds": 300
    }
    // …one entry per chain: polygon, avalanche, sei, solana
  ]
}

20000 is $0.02 in USDC's 6 decimals. The agent signs a payment authorization for that amount, retries with X-PAYMENT, and the tool runs once settlement confirms.

What I actually had to get right

The happy path is easy. The interesting part is everything that isn't.

1. The amount, recipient, and asset come from the server — never the client. The client sends only a signed authorization. The server builds the payment terms (price from a server-side table, payTo = a cold wallet, the USDC contract pinned per chain) and verifies the signature satisfies those terms. Otherwise an agent could "pay" 1 wei, redirect payment to itself, or hand you a fake token.

2. Don't run a side-effecting action before you're paid — but don't double-charge either. verify() only reads the payer's balance; it's not a reservation. So N concurrent requests from one wallet funded for a single call can all pass verify. I gate it two ways: an at-most-one-in-flight lease per wallet, and a claimed nonce (EIP-3009) inserted before the action runs, so a replay or a concurrent duplicate can't execute the tool twice for one payment.

3. For live external effects (like sending a customer an email), settle first. The fairness default is "only charge on success" — so most tools run, then settle. But for the one action where "ran but not charged" is real abuse (a free outbound email from your domain), I flipped the order: confirm payment on-chain, then send. The safe failure direction is "paid but not delivered," never "delivered for free."

4. Anonymous ≠ unbounded. Per-wallet rate/spend caps, reputation, and a deliverability breaker bound abuse. High-value actions are gated behind earned reputation, so a day-one anonymous wallet can't email your customers — it gets a draft in a human approval queue instead.

5. Self-host the money path. I run my own relayer + facilitator, so there's no third party between the agent and settlement. USDC lands in a cold wallet at my prices; even a leaked hot key can only move the payer's funds to my wallet, at my price (the settle is economically bound).

Was it worth it?

For a helpdesk specifically: an agent resolving a support task mid-workflow can now pay for exactly the tools it uses — no account, no key. Whether pay-per-action beats just issue the agent a key is genuinely situational, and I'd love the internet's opinion on where the line is.

But the pattern is bigger than helpdesks. 402 + a signed micropayment is the missing "walk up and pay" primitive for the agent web. It's early and rough, but it works today — you just curled it.

Try it: deskcrew.io · the door: POST https://deskcrew.io/api/mcp/deskcrew · MCP spec + tools: github.com/webmilmind1/deskcrew-mcp

Happy to answer anything about the x402 wiring in the comments.