Selling access — Recued Docs

A seller runs capabilities on their own server — tools, automations, an operated knowledge base — and sells or grants access to them through a customer door. Customers connect from any MCP client or any OpenAI-compatible chat client; they do not need Recued. Commerce runs on your own rails: Recued takes no commission, mediates no payment, and routes none of the traffic — zero percent, forever.

#The shape of a sale

Access is sold in tiers — basic, pro, whatever fits your product. Each tier is backed by a customer contract template: an ordinary contract you author in your contracts surface, carrying exactly the tools and scopes that tier grants, plus its usage policy — period allowances and per-minute rate limits, counted in tool calls and chat turns, never in model tokens.

Templates are a hard ceiling. Automation can issue, extend, and close customer access stamped from a template, but nothing — not a payment webhook, not a recipe, not even a compromised provider account — can widen a grant beyond what you authored. The worst a forged subscription event can produce is the access a paying customer would have gotten.

#Where the money moves

Commerce is yours, in either mode:

Manual — an invoice, a comp, a trial, another storefront. You open and close access directly; Recued records the lifecycle, not the payment.
Provider-automated — a payment provider drives the lifecycle, Stripe first. Subscription events issue, extend, swap tiers, and close access against your tiers automatically. The event handling is not something you wire up yourself: it installs as one pack. See Turning on provider automation.

Checkout is provider-hosted; card data never approaches your server — your public reception page renders a link to the checkout and nothing more. You are the merchant of record: taxes, refunds, and invoices live with you and your provider. Recued does not issue invoices, hold balances, prorate plans, or keep a money ledger. It opens and closes the door.

#The customer lifecycle

A subscription starts, or you grant access manually. A customer access row is stamped from the tier's template.
The customer receives a claim link by mail — never the raw token. The claim page shows the token once, alongside the door endpoints and copy-paste configuration for Claude Desktop, Cursor, a generic MCP client, or an OpenAI-compatible client.
Renewals extend access. Plan changes swap the tier. A failed payment opens a grace window you control — 72 hours by default — rather than cutting a customer off at the first retry; a cancellation, refund, or dispute closes access immediately. Each of those defaults is per-status and yours to change.
A leaked token is reissued — the replacement invalidates the old one, with fresh claim delivery.

One-time purchases fit as time-boxed passes: a fixed-duration issue whose usage policy bounds total consumption.

#What customers get

A customer token is just another contracted actor at the same enforcement boundary: it reaches exactly the tools its tier grants, under per-customer rate and period limits, with every call attributed and audited. Three door surfaces cover the common product shapes:

MCP tools — your granted tools appear in the customer's own agent.
Peer chat — another Recued asks your server's AI over the MCP relationship.
OpenAI-compatible endpoint — a base URL plus API key for chat clients, when the product is "ask my operated knowledge" rather than "call my tools from your agent."

Self-service happens through the same door: a status operation returns the customer's own usage, limits, tier, and period end — so "how much have I used" is a question their AI answers directly. There is no separate customer web portal to run.

#Turning on provider automation

Two packs, installed once from the marketplace:

Stripe for Sellers — the bounded set of Stripe operations selling actually needs. Deliberately not the full Stripe API: granting it does not hand your automations the rest of your account.
Seller Subscription Payment Events — the whole billing lifecycle in one install. Checkout completion, renewal, failed payment, cancellation, plan change, and entitlement change are six handlers behind a single webhook binding, so you select one delivery endpoint and the lifecycle works rather than assembling it event by event.

Then enroll your Stripe connection, pick the delivery endpoint the pack asks for, and run Initialize / Synchronize to seed one tier template per Stripe entitlement. You author each template's grants in the contracts surface — that step is yours by design and nothing else can do it for you.

Two things worth knowing before you install:

Installing subscribes that endpoint to all seven event types. They are parts of one lifecycle, not a menu, so the choice is the pack rather than the event. What each handler does stays yours: the per-status policy above decides whether a failed payment means grace, immediate close, or nothing at all.
The events only remove the wait. A periodic reconciliation reads your provider directly and converges customer state on its own schedule, so a server that was offline through a delivery window still catches up, and a webhook you never received cannot silently strand a customer. The events make the lifecycle react in seconds instead of at the next sweep.

Refunds and disputes are the one place you pick instead of install: Revoke Access cuts a customer off when a charge is fully refunded or disputed, Flag for Review only raises a notice — including on partial refunds — so you can adjudicate case by case. They ship as two packs because a seller wants one or the other, never both.

#Running as a seller

Settings → Seller is the readiness view: your door, tiers, customers, mail sender, and payment wiring in one place, with the grants themselves always authored by you in the contracts surface. Practical rules:

Sell from an always-on reachable server — a small VPS, not a home IP. <handle>.recued.net is the starter name; serious sellers graduate to a custom domain on their own DNS.
Dry-run your provider's test mode end-to-end before going live.
Your uptime is your customers' uptime.
Prefer prepaid flat tiers, a base fee with overage, or time-boxed passes. Pure usage-billed arrears is deliver-then-collect: a failed period-end invoice claws back nothing already consumed.

#What this changes for everyone else

Nothing. If you never sell, contracts, doors, and approvals behave exactly as before, and customer rows never appear among your normal contracts. The marketplace stays free to browse, install, and publish — selling access is a capability of your server, not a marketplace fee.

Grants and approvals — the boundary customer calls pass through.
AI chat and MCP — the door surfaces customers connect to.
Reachability — giving your server a stable public name.