Permissioned spending.
A focused path to launch.

What exists today

The private customer build contains invited accounts, persistent Stripe sandbox cards, payment permissions, test USDC funding, plans, test billing, and transaction history. The processor contains authorization policy, a local ledger, lifecycle handling and reconciliation. Availability of individual provider features depends on sandbox configuration.

The public walkthrough is an illustration. The private build is test-only. No real revenue, customer traction, loss reduction or live program approval is claimed.

The initial customer hypothesis

Control-conscious online spenders, including people comfortable holding USDC. Validate whether explicit payment approval creates enough value to earn repeat use and payment. Final customer eligibility and geography depend on an approved provider program.

How the system fits together

The wallet captures user intent and authenticates ownership. The processor owns permissions, balances, subscription entitlements and transaction history. Provider adapters translate external events into this local authority. Finalized funding is credited before spending; blockchain requests stay outside the card authorization path.

The architecture deliberately keeps two services with distinct responsibilities. A new payment rail should change the provider integration, while preserving the same customer permission model.

The USDC path

Base Sepolia testnet funding demonstrates deposit confirmation and ledger attribution. The live goal is provider-approved stablecoin funding connected to controlled card spending. Custody, conversion, withdrawals, eligible networks and customer account ownership remain explicit program decisions.

Accepting stablecoins at a merchant checkout is a separate capability from holding customer stablecoins and backing issued cards. The production plan must validate each independently.

What investment should unlock

1. Customer evidence: a defined invited cohort, activation, repeat protected purchases, paid intent, and support cost.
2. Program access: written provider approval for the audience, geography, funding and card model.
3. Production engineering: isolated live adapters, audited money-state transitions, durable recovery, security review and operational ownership.
4. A capped pilot: approved employees, small exposure limits, daily reconciliation and a rehearsed incident response.

Funding amount, runway, valuations and milestone targets should follow the operating budget and cohort evidence. They are not asserted in this brief.

The business model to validate

Personal, Plus and Pro plans are represented in test billing. Evaluate subscription revenue and realized net interchange against funding, transaction, fraud, dispute, support and infrastructure costs. Deposits are not revenue; an approval is not a captured payment.

What still stands between MVP and live money

Provider eligibility, onboarding and custody responsibilities; production funding and card adapters; independent security review; webhook and reconciliation recovery; backup restoration; support, disputes and incident coverage. Live Stripe keys are blocked by this release because the existing adapters contain sandbox-only behavior.

Stripe describes use-case approval, live-mode access and employee testing in its Issuing launch guidance. Its Financial Accounts documentation and stablecoin payments documentation describe separate capabilities; none establish Pluribus eligibility.