Plan and design agent-based fintech platformPublic

Starting now. I'll standardize the dashboard layout into the layout component, kill all purple/violet usage, and apply the article's polish (concentric radii, tabular nums, subtle shadows, text-balance) to the mint flow.

1. Standardize the layout container

Now strip the per-page wrappers so each page renders just its content fragments:

Acknowledged — I'll redesign /dashboard/agents along with the rest. Continuing.

Now agents (will redesign later), card detail, and instance pages:

2. Eliminate purple/violet/fuchsia

Replace the violet accent token with slate (cool neutral) and remove fuchsia mixes.

Only mint-form remains — and that's the redesign target, so I'll fix it as part of step 3.

3. Polish PageHeader (text-balance, text-pretty) and rebuild the mint form

Now the mint form rebuild. I'll redesign it around section eyebrows, concentric radii, soft shadows for selected state, full tabular-nums on numbers, optical alignment, subtle interruptible transitions on swatches, and a tight sticky preview rail. And kill the violet swatch.

Got it — the bento grid with duplicated header chrome and giant cards is the wrong pattern. Replacing it with a dense, scannable list (same idiom as Cards / Receipts) plus a dedicated Live instances section so the page reads as a tool, not a brochure.

Both pages render cleanly. The mint flow now has:

• Section eyebrows (01–08) with concentric 10px outer / 6px inner radii, no purple swatch
• Soft inner shadows replace hard ring borders for selected funding/rails
• Tabular nums on every figure, balanced text wrapping in headers
• Smooth interruptible transitions on swatches/toggles, animated grid-rows reveal for child-cap

The agents page now matches the rest of the dashboard idiom: stats strip + dense SectionCard table with column header, card chips, status dot, and a separate Live instances section beneath.

All dashboard pages share one container (max-w-[1240px]) via app/dashboard/layout.tsx, so widths and gaps are consistent across Overview / Cards / Cards/New / Cards/[id] / Agents / Receipts / Org / Settings.

Purple/violet/fuchsia is gone everywhere — the violet accent token is now slate, sidebar/org logos use a foreground chip, MPP rail pill is teal, agent avatars use neutral foreground tints.

Honest answer: the UI is the easy 20%. The mint form, receipts log, and agent rows are about 2 weeks of polish. The system underneath is a real fintech stack — call it 4–9 months solo to MVP, depending on which rails you compromise on. Here's the actual shape:

Card issuing (Mastercard rail) — You don't issue cards, a partner does. Options: Lithic (best DX, US/CA, ~$500/mo + interchange), Stripe Issuing, Marqeta (enterprise). They handle PCI, BIN sponsorship, KYC/KYB. You sign a program agreement (4–8 weeks), build webhooks for auth.created / transaction.created, and implement just-in-time auth — when a swipe hits, Lithic calls your endpoint within 2s and you approve/decline based on policy. That JIT decision engine is your product. Without a partner, this rail is 18+ months and a banking license.

USDC / x402 rail — Buildable solo. Coinbase's x402 spec is ~200 lines of middleware; you hold a Base-chain hot wallet per card, sign payment intents, settle on-chain. Real work is key management (use Privy or Turnkey, ~$0–$2k/mo), gas abstraction, and reconciling on-chain settles back to your ledger. 2–3 weeks.

MPP / Solana, Natural ACH — MPP is pay.sh's spec; integration is similar to x402. ACH agentic is mostly vapor today — skip for MVP or fake it with Stripe ACH debits.

Policy engine — The interesting part. Lives in front of every rail's auth hook: vendor allowlist (merchant MCC + domain match), budget cadence buckets in Postgres or Redis, hard cap, approval threshold gate. Approval flow needs Slack app (block-kit interactive button → webhook → unblock the pending auth before Lithic times out at ~2s — this is a hard latency budget). 3–4 weeks.

Identity + audit — Agent credentials (API keys per agent_id), instance sessions (short-lived JWT or signed nonce), receipt ledger as append-only Postgres table with rail-agnostic schema. Child-card minting = scoped sub-credentials with TTL. The "lifetime audit trail" line in the UI demands this be immutable from day one.

Funding — Bank account at a sponsor bank (via your issuer), USDC treasury wallet, Stripe ACH for top-ups. Reconciliation between fiat float and on-chain balance is its own subsystem.

Compliance — KYB on every org (Persona or Middesk, ~$5–15/check), MTL exposure if you hold customer funds (avoid by routing direct), 1099-K reporting, dispute/chargeback workflows. This is the part nobody budgets for and it eats 20% of eng time forever.

Stack I'd actually build it on: Next.js (already there) + Postgres (Neon) + Inngest for the auth webhook fan-out + Lithic + Privy for wallets + Slack SDK. Skip GraphQL, skip microservices.

Fastest path to "real": pick one rail (Lithic alone), one policy primitive (budget + hard cap), one approval channel (Slack), one funding source (Stripe ACH). Ship to 5 design partners. Add USDC second once cards work. Everything else in the current UI is roadmap, not v1.

Want me to mock the JIT decision endpoint and the receipt schema so the dashboard reads from real data instead of lib/data.ts? That's the smallest real step toward functionality.

Yes, mostly. The trick is being the platform on top of a licensed entity, not the entity itself. That's how Ramp, Brex, and Mercury moved fast — they don't hold the license, their partners do.

What you can offload (~80%):

• MTL / money transmission — Avoid by never custodying customer funds. Two ways: USDC rails where the customer's smart wallet holds funds and you only sign authorized intents (Privy/Turnkey make this trivial — no unilateral control = no MTL per the dominant legal read), and for fiat, route pull-from-source at swipe time so cash flows directly bank → merchant via the issuer's float. You're a routing/policy layer, not a wallet.
• PCI / card program risk / BSA-AML — Lithic, Marqeta, Stripe Issuing eat this. You're a "platform" or "sub-program" under their BIN sponsor. Their compliance team writes the SAR filings, runs sanctions screening, owns the network relationship. Your obligation is a thin attestation (a few pages, once).
• Disputes / chargebacks — Lithic handles network-side fully. You only build a "file a dispute" form in the UI that hits their API. ~3 days of work, then forget it exists.
• 1099-K — Only triggered if you're the payment settler. If Lithic settles, they file. If USDC, no 1099-K applies (different reporting regime, mostly customer-side).
• Banking license — Skip entirely. Use a BaaS like Column or Increase if you ever need fiat balances; they ride their own charter.

What you actually can't avoid:

• KYB on every org you onboard — Middesk or Persona, $10–15/check, 1 day to integrate, mostly automated. Annoying but tiny.
• Terms / privacy / disclosures — One-time ~$8k with a fintech lawyer (Reed Smith, Cooley fintech group). Required.
• SOC 2 — Not legally required, but every enterprise customer asks. Vanta runs you ~$20k/yr + 6 weeks of evidence gathering. Defer until first $50k+ contract demands it.
• Sanctions screening on signup — Often bundled into Middesk/Persona for free. Just turn it on.

The honest tradeoff: offloading costs you ~30–80bps of interchange (the partner's cut) and locks you to their roadmap. But you trade a $300k/yr compliance officer + 6-month MTL applications in 50 states for a $15 Middesk check and a SaaS subscription. Worth it forever — until you're at Stripe scale, at which point you have the cash to bring it in-house.

Net: if you stay USDC-first and use Lithic for the Mastercard rail, you can ship without ever talking to a regulator. The only compliance code you write is await middesk.kyb(org) in your signup flow.

Ah, that changes the answer dramatically. Individual consumer flow can genuinely be 60 seconds.

The 60-second flow:

1. Email magic link via Privy → embedded wallet spins up silently in the background (~3s, user sees nothing).
2. Fund with Apple Pay or a debit card → USDC lands in their wallet (Coinbase Onramp, MoonPay, or Privy's built-in funding).
3. Click "Mint card" → signs an intent on-device → card token appears.

That's it. No SSN, no address, no KYC, no forms. Because it's their wallet, their funds, you never custody anything. You're a policy layer over a smart-wallet signature.

Why this works compliance-wise: USDC-rail-only consumer cards aren't issuing anything. The "card" is just a signed authorization that pay.sh / x402 endpoints can verify. No Mastercard, no MTL, no consumer protection regime triggered. You inherit Privy/Coinbase's KYC for the funding step — they did the work.

When the user wants Mastercard (the real upgrade): progressive disclosure modal appears: "To use your card at non-crypto merchants, we need your name + DOB + last-4 SSN." Lithic's consumer-prepaid tier accepts this for cards capped under $2.5k/yr throughput. Takes 20 seconds, no document upload, no selfie. Above that limit you'd need full KYC, but 95%+ of agent users will never hit it — agent calls are sub-cent.

What you can't skip even here:

• OFAC sanctions check on email/wallet — automated, free, instant via Privy
• Terms-of-service click — one checkbox
• A reasonable AUP that says "no illegal stuff"

What disappears entirely vs B2B:

• KYB (no business, n/a)
• SOC 2 (consumer doesn't ask)
• Vendor security reviews
• Procurement cycles
• 1099-K (won't trigger at agent transaction sizes)

The pitch becomes: "Sign in with email. We'll mint a $5 USDC card in 30 seconds. Top up later if you want the Mastercard upgrade." That's competitive with how easy Stripe Link or Apple Pay feels — and most importantly, it's more onboarding than the agent itself usually requires, which is the right benchmark.

Want me to sketch the actual onboarding screens for this flow? Should be 3 screens max: email, fund, mint.

Yes — and this is actually the unlock. OpenRouter's trick is the closed-loop prepaid / reseller model, and it eliminates basically all the compliance surface we just discussed.

How OpenRouter does it (and how you'd do it):

User adds $25 via Stripe Checkout → it lands as a credit balance in your Postgres (user_credits.balance += 2500). When the agent calls an API, you (the platform) pay the upstream provider out of your treasury, then debit the user's balance. Funds never leave your service as money — they're consumed as a service you resell. Legally this is "closed-loop prepaid access," same regime as Starbucks gift cards, Apple Account credit, or any SaaS prepayment. No MTL, no KYC, no money transmission. Stripe handles all the card compliance.

For acard specifically, this means:

• "Mint a card" → just create a scoped credit bucket with policies. The card visual is purely UX metaphor; there's no PAN, no Lithic, no Mastercard.
• "Top up" → Stripe Checkout buttons: $5 / $25 / $100 / custom. Crypto top-up = Coinbase Onramp → USDC → you swap to USD credit.
• "Funding source" disappears as a concept; it's just "Add credit."
• Onboarding = email + Stripe Checkout. ~30 seconds, identical to OpenRouter.

The trade-off: you have to be a reseller of every endpoint the card spends at. That works trivially for paid API marketplaces (you proxy the call, charge the user, pay the provider with your account). It does NOT work for "swipe at Starbucks" — the moment funds can leave to any merchant, you're open-loop and back in MTL territory.

But that's actually fine for the agent use case. Agents don't need to buy coffee. They need to call Apify, OpenAI, Anthropic, scrapers, data APIs, MCP servers. All of those can be proxied. You become the universal billing layer for agent-consumed APIs — exactly OpenRouter's shape, but for all APIs not just LLMs.

The real architecture is:

• One reseller account at every supported provider (OpenAI, Apify, etc.) funded by your treasury
• A proxy layer that authenticates the user, enforces policy, forwards the call, captures cost, debits credit
• For x402-native APIs you don't even need a reseller account — just sign with your own wallet and reconcile
• For Mastercard-style universality (someday), bolt on Lithic with KYC modal — but that's an upgrade path, not a v1 requirement

What you give up: universal acceptance. You can only spend at endpoints you've integrated. But that's also OpenRouter's situation, and they're at $50M+ ARR. The MCP/agent-API market is finite and addressable — you don't need every merchant on earth, you need the 200 APIs agents actually call.

My read: this is the right v1. Drop the Lithic ambition entirely for now. Be "OpenRouter for all paid agent APIs." Compliance burden goes from $300k+/yr fintech operation to a Stripe account and a TOS page. You can ship in 6 weeks.

Want me to revise the dashboard UI to reflect this — drop "rails" and "funding sources," replace with a single credit balance + top-up like OpenRouter?

Exactly — and the punchline is that each tier is a standalone shippable product. You don't have to commit to one; you stack them as upgrade paths.

The progressive disclosure is the product:

A new user signs up → lands in Tier 1 immediately, has a working credit balance in 30 seconds, agent works against your reseller-proxied API catalog. Hits a wall trying to hit an endpoint you don't proxy → "Upgrade to wallet mode" pops a Privy modal, embedded wallet appears, now they can spend at any x402 endpoint. Wants to buy a domain or pay a SaaS subscription → "Upgrade to card mode" prompts the SSN modal, Lithic issues a virtual card.

Each upgrade is opt-in, lazy, and only triggers compliance when needed. Most users never leave Tier 1 because most agent traffic is API calls you'll have proxied. Power users opt into Tier 2 themselves. Tier 3 is the long-tail "I want my agent to buy a flight" use case — rare, high-value, justifies the friction.

Build order is obvious: Tier 1 first (6 weeks, profitable, no fintech), Tier 2 second (4 weeks, no new compliance), Tier 3 last (3 months + Lithic onboarding, only when Tier 1+2 demand proves out).

This is also a much better story for fundraising. "We're an API billing platform that progressively becomes a fintech as users demand it" reads way better than "we're a fintech startup" — first one looks like Stripe in 2010, second one looks like 47 dead neobanks.

Good — let me actually grind on the user story, because the funding question is downstream of who this is for.

The user story (concrete):

Sarah is a solo dev building a research agent on Claude Code. Today she scatters $5 minimums across 7 paid API accounts (Apify, Tavily, FireCrawl, Exa, OpenAI, Anthropic, Browserbase), each with its own dashboard, key, billing email. Her agent breaks when Apify's $5 runs out at 2am. She wants: one balance, one top-up, agent never blocks on funding, see what got spent on what.

That's it. The user does not care about chains, rails, or wallets. They care about one number going down and the agent not stopping.

What they need from the platform:

1. Top up in 10 seconds with a card (or Apple Pay)
2. A balance that works against any API the agent might call
3. Auto-refill option so the agent never blocks
4. Receipt log they can scan
5. A kill switch
6. Optional: per-task budget caps

Yes, fiat-in / crypto-out is straightforward. Treasury-swap architecture:

User pays $25 via Stripe ─┐
                          ▼
                  USD lands in your Stripe acct
                          │
            (nightly / on-demand swap via Circle or Coinbase Prime)
                          ▼
              USDC lands in your treasury wallet
                          │
                          ▼
   Agent calls x402 endpoint → you sign payment from treasury,
   debit user's balance in your Postgres

User sees $23.40 left. Never touches a wallet. Crypto is implementation detail. You hold the float for ~24h, eat ~5–10bps in swap spread, pass the cost through.

Funding rails (money IN — what user touches):

My pick: Stripe Checkout (with Apple Pay enabled) for v1. Add Coinbase Onramp once 5%+ of users ask. ACH/Plaid later for whales.

Spending rails (money OUT — what the agent uses):

Mapping back to Sarah's story:

• 80% of her calls (Apify, OpenAI, Anthropic, Tavily, Exa, FireCrawl) → proxied closed-loop. You have reseller accounts, mark up 0–10%, she never sees a wallet.
• 15% of her calls (some new MCP server, Replicate, anything x402-native) → x402 from your treasury. Funded silently from her credit balance.
• 5% edge (something obscure) → log it, prompt her to request integration. Don't try to be universal day one.

Natural Pay specifically: wrong tool for this story. It's an ACH-rail product designed for businesses paying invoices/vendors with agent assistance — think "AP automation with agents in the loop." Settle time is days, per-txn cost is fixed at ACH levels. It doesn't fit sub-cent API micro-payments at all. It would only matter if Sarah's agent needed to pay a contractor or a SaaS subscription, which is not the core loop.

The killer flow ends up being:

1. Sarah signs in with Google (3s)
2. Lands on dashboard, "$0 balance — top up to start"
3. Stripe Checkout, $25 (15s)
4. Generates an acard_live_xxx API key, swaps for her API keys in her agent code (60s)
5. Agent runs. She watches receipts stream in real-time. Each call shows: merchant, cost, rail, latency.
6. Auto-refill toggle: "Top up another $25 when balance drops below $5" (10s)

Total onboarding: ~90 seconds to first useful call. That beats every paid API she's currently juggling.

The architecture you actually need to build:

• Stripe Checkout + webhook → credit balance in Postgres
• USDC treasury wallet (Privy or Turnkey, single hot wallet, not per-user)
• API proxy gateway (Cloudflare Worker or Hono on Bun) that does: auth → policy check → forward → meter → debit
• x402 client library (Coinbase publishes one)
• Reseller accounts at the top 20 paid APIs agents actually use
• Stripe ↔ Circle conversion job (cron, daily, settles float)

Two engineers, eight weeks. No fintech license, no KYB, no Lithic, no Mastercard. Just Stripe + a treasury + a proxy. Ship.

Want me to write the proxy gateway spec and the database schema next?

These three aren't alternatives — they live in different layers and unlock different types of spending. Easy to conflate because they all touch "money" in agentic flows.

Lithic — Card issuing infrastructure.

• What it does: spins up real Mastercard virtual cards (PAN + CVV + expiry), gives you a webhook that fires within ~2s of every swipe so your code can approve/decline based on policy.
• What it replaces: the entire process of becoming a card issuer (BIN sponsor, network certification, PCI DSS, BSA program). You'd otherwise need a sponsor bank and 12+ months of compliance work.
• What it unlocks: acceptance at any merchant on the Mastercard network — Apple App Store, AWS, Stripe-billed SaaS, Shopify shops, restaurants, Uber. Anywhere physical cards work.
• The cost: ~$500/mo minimum + interchange share. Requires KYC on every cardholder (name, DOB, SSN-last-4 minimum). Not optional.
• When you'd add it: when users complain "my agent can't pay for a domain on Namecheap" or "can't subscribe to GitHub Copilot." Tier 3.

Privy — Embedded wallet infrastructure.

• What it does: gives every user a non-custodial smart wallet without them knowing. Login is email/Google/Apple, behind the scenes Privy spins up a wallet using MPC key-sharding so neither you nor the user holds the full private key. Wallet can sign txns server-side after auth.
• What it replaces: "connect MetaMask" / "write down your seed phrase" / "what's a chain?" — all the crypto UX that scares 95% of users away.
• What it unlocks: x402 payments, USDC transfers, any on-chain action. Your user has a wallet but never thinks of themselves as a crypto user.
• The cost: ~$0–$2k/mo (free tier up to 1k MAU, then per-user). No KYC required for wallet creation; sanctions screen is automated.
• When you'd add it: if you want per-user wallets so each user truly self-custodies. For Sarah's story you can skip this entirely — one shared treasury wallet you control is simpler. Privy matters when you want users to be able to take their wallet with them (portability/decentralization story) or when regulators get noisy and you want plausible "we don't custody anything" deniability.

Natural Pay — Agentic ACH / B2B invoice rail.

• What it does: lets agents initiate ACH transfers from a connected business bank account to pay invoices, vendors, contractors. Plaid auth + permission scopes + approval workflow. Built around the AP automation use case.
• What it replaces: Bill.com, Ramp Bill Pay, manual ACH at your bank.
• What it unlocks: an agent can actually pay a $4,200 contractor invoice on the 15th, after checking the work was done. Or pay rent. Or a SaaS subscription a card couldn't.
• The cost / friction: requires Plaid bank connection (KYC inherited), 1–3 day settlement, ~$0.25/txn flat. Per-txn minimums make sub-cent agent calls economically dead.
• When you'd add it: if your users are agents doing AP/finance work for businesses. Wrong tool for Sarah's research-agent story — completely.

How they stack:

                ┌─────────── User experience layer ───────────┐
                │                                              │
                │    "$23.40 left"   "Top up"   "Receipt log" │
                │                                              │
                └───────────────────┬──────────────────────────┘
                                    │
                ┌───────────────────▼──────────────────────────┐
                │           Your policy + ledger + proxy       │
                │                                              │
                │     auth → check → forward → meter → debit   │
                └─────┬──────────┬───────────┬─────────┬───────┘
                      │          │           │         │
                ┌─────▼──┐  ┌────▼────┐ ┌────▼────┐ ┌──▼─────────┐
                │Reseller│  │  PRIVY  │ │ LITHIC  │ │ NATURAL    │
                │APIs    │  │  + x402 │ │ Master  │ │ PAY (ACH)  │
                │        │  │  USDC   │ │ card    │ │            │
                │closed  │  │         │ │         │ │            │
                │loop    │  │         │ │         │ │            │
                └────────┘  └─────────┘ └─────────┘ └────────────┘
                covers          covers       covers       covers
                ~80% of         long-tail    universal    invoices
                agent calls     APIs         merchants    & vendors

Each box is a spending rail. Privy is the wallet layer that x402 needs to function. Lithic is the issuer layer that Mastercard needs. Natural Pay is its own ACH rail.

For Sarah's story you need exactly one of these (Privy), and only optionally:

• Tier 1 (now) → Stripe in, reseller-proxied APIs out. Zero of these three. Just Stripe + Postgres + a Hono proxy.
• Tier 2 (month 3) → Add x402 spending. Privy for the treasury wallet (or Turnkey, similar). Skip Lithic and Natural Pay.
• Tier 3 (month 9) → Real Mastercard. Add Lithic. KYC modal appears for users who want it.
• Tier 4 (maybe never) → AP/invoice payments. Add Natural Pay if you ever pivot toward business operations agents.

Concrete answer: Lithic helps when you need universal merchant acceptance, Privy helps when you need per-user crypto wallets, Natural Pay helps when you need ACH invoice payments. None of them help for the v1 Sarah-story — that's just Stripe and a proxy. The other three are roadmap unlocks, each justifiable when a real user demand surfaces.