Ax402 Seller Platform

Ax402 is a platform for monetizing HTTP APIs with per-request payments. A seller connects an upstream API, prices individual routes, and publishes a gateway URL. When a buyer calls that gateway without payment, Ax402 returns an HTTP 402 response with payment requirements. After the buyer signs and retries the request, the gateway verifies payment and proxies the call upstream.

It is not a card checkout product or a generic API gateway admin panel. The seller experience is where configuration, billing, settlements, and account security actually live. That is the surface I worked on.

The work sits in a pnpm monorepo built on Atlas, a front-end foundation I also use on other projects. The seller app is the main product surface. A Fumadocs documentation site and shared UI packages sit alongside it. An operator admin app is reserved in the repo but not implemented.

The problem

x402 handles payment at the protocol layer. It does not give sellers a place to create APIs, import OpenAPI specs, verify domains, inspect settlement activity, review income, or manage billing plans.

The front-end problem was making that infrastructure feel like a product. Setup spans multiple steps, two environments, wallet and token semantics, and security requirements like MFA and passkeys. On top of that, the seller frontend was migrated from a standalone repository into the monorepo without breaking public URLs or auth behavior.

Most of the difficulty was not rendering forms. It was keeping long, failure-prone workflows understandable while the underlying payment model stayed strict.

What I worked on

I contributed across the Ax402 client monorepo with the seller app as the primary delivery surface.

Seller dashboard. I helped build the authenticated shell, onboarding flows, API management interfaces, billing and income panels, account security settings, and the embedded developer workbench. I also worked on the public marketing pages and interactive product previews.

Platform integration. I contributed to the typed SDK integration through a BFF session boundary, sandbox and production environment switching, and adoption of Atlas UI primitives with Ax402-specific theme layers.

Documentation. I worked on the public docs site covering integration paths for buyers, SDKs, plugins, CLI, and MCP.

The through-line: turning protocol-level payment infrastructure into a usable seller product.

Architecture

The seller app is a Next.js App Router application in TypeScript with Tailwind CSS v4.

Session boundary. Auth tokens stay in httpOnly cookies. The browser talks to a typed SDK client that routes through a BFF proxy. The proxy sets and clears the session on login and logout, then forwards authorization to the backend API. Client JavaScript never holds the token.

Environment model. Sandbox and production are first-class. The UI persists the seller’s environment preference, sends the appropriate header on requests, and re-fetches state when they switch workspaces.

UI system. Seller imports shared primitives from Atlas UI and adds dashboard layout helpers, brand tokens, and legacy style compatibility for visual continuity after the migration.

State and data. Environment and sandbox wallet state live in React Context. Page data is fetched locally with useState and useEffect. The repo documents a proposed move toward React Query and a more unified data layer, but that is not in place yet.

Monorepo layout. Product apps (seller, docs), shared packages (ui, theme, umami), and an Atlas reference app (web) share tooling, lint config, and component conventions.

Product surfaces

Dashboard. Overview analytics, API list, facilitator visibility, income ledger and payout requests, billing plan management, and settings for API keys, appearance, and notifications.

API management. Create APIs, configure endpoints with per-route USDC pricing, manage domains and TLS status, import OpenAPI specs, set upstream authentication, and operate batch settlement settings from a tabbed detail view.

Onboarding. Intent-based flows for a product tour, sandbox demo, wrapping your own API, or full production setup with DNS verification and readiness checks.

Workbench. An embedded shell and API explorer for inspecting unpaid 402 responses and running paid gateway requests from inside the dashboard.

Sandbox wallet. In sandbox mode, a wallet panel supports faucet funding, balance visibility, and payment approvals during testing.

Marketing and docs. Product pages for gateway, facilitator, SDKs, paywall, and plugins in the seller app. A separate docs site for integration guides and API reference.

Engineering details

Security-first authentication. Email and password login, TOTP MFA, WebAuthn passkeys, email verification, password reset, and waitlist gating. Session handling stays behind the BFF rather than in client-side storage.

Guided setup flows. Production API setup is a multi-step flow: upstream URL, wallet configuration, endpoint creation, OpenAPI import, DNS guidance, and readiness probes. Breaking it into stages keeps a long process navigable.

Typed backend integration. A vendored Ax402 SDK provides typed access to auth, APIs, endpoints, domains, settlements, and billing. App-level helpers normalize responses where SDK types lag backend fields, particularly around income and billing.

Dual-environment UX. Sellers work in sandbox and production without leaving one application. Environment preference syncs to the backend.

Operational polish. Environment schema validation, SEO metadata, sitemap and robots configuration, security headers, cookie consent, and consent-aware analytics integration.

Targeted tests. Unit coverage focuses on payment token rules, billing helpers, passkey error handling, workbench command parsing, and marketing pricing merge logic. UI and end-to-end coverage is limited.

Tradeoffs

Migration constraints. Preserving URLs, auth behavior, and feature parity during the monorepo move meant keeping some legacy patterns, including page-local data fetching, rather than refactoring everything at once.

Protocol vs. product language. Sellers should not need facilitator internals to price an endpoint. The UI exposes what matters for daily operation and pushes deeper context to docs and workbench tooling.

Data fetching spread. Without a unified cache layer, fetching logic is distributed across pages and panels. The codebase itself flags this as the main area for future modernization.

Marketing and product together. Shipping marketing pages in the same app keeps content aligned with the product, but increases surface area and requires clear separation between public and authenticated shells.

What I would improve next

These are the improvements I would make next as the product matures.

Unified data layer. Adopt React Query and consolidate seller API access, as proposed in the repo’s modernization ADR.

Test coverage. Add component and integration tests for auth, billing, and setup flows. Current coverage is strong on lib logic, thin on UI.

Consent alignment. Move seller cookie consent to the shared Atlas consent package used elsewhere in the monorepo.

SDK packaging. Un-vendor the SDK once a stable published package is available.

Admin surface. Implement the reserved operator app when the backend contract is ready.