Selling access — Recued Docs

A seller runs things on their own server. That can be tools or automations. It can be a knowledge base they look after. The seller sells or gives access to them through an access type they open on purpose: MCP tools, MCP chat, or an OpenAI-compatible endpoint. Customers connect from any MCP client or any OpenAI-compatible chat client. They do not need Recued. Money moves on your own payment system. Recued takes no cut. It handles no payment. It carries none of the traffic. Zero percent, forever.

#The shape of a sale

You sell access in tiers. A tier can be basic, pro, or whatever fits your product. Each tier is backed by a customer contract template. That is a normal contract you write in your contracts screen. A contract is the saved list of what one actor may do. The template holds just the tools and scopes that tier grants. It also holds the usage policy. That says how much a customer may use per period. It also says how many calls per minute are allowed. Usage is counted in tool calls and chat turns. It is never counted in model tokens.

A template is a hard ceiling. Automation can open, extend, and close customer access stamped from a template. But nothing can widen a grant past what you wrote. Not a payment webhook (a message another service sends to your server when something happens). Not a recipe. Not even a hacked provider account. What is the worst a fake subscription event can do? It can give the access a paying customer would have gotten.

#Where the money moves

The money is yours to handle, in either mode:

Manual: an invoice, a free pass, a trial, another store. You open and close access yourself. Recued writes down when access opens and closes, not the payment.
Provider-automated: a payment provider drives the whole flow. Stripe, Paddle, and Lemon Squeezy are supported. Subscription events work by themselves. They open, extend, swap tiers, and close access against your tiers. You do not wire up the event handling yourself. It installs as one pack. See Turning on provider automation.

Checkout is hosted by the provider. Card details never come near your server. Your public reception page shows a link to the checkout and nothing more. You are the merchant of record. That means the business the customer buys from, in the eyes of the law. Taxes, refunds, and invoices live with you and your provider. Recued does not send invoices. It does not hold money. It does not work out part-period charges. It keeps no money ledger. It opens and closes access.

#The customer lifecycle

A subscription starts, or you give access by hand. A customer access row is stamped from the tier's template.
The customer gets a claim link by mail. The mail never carries the raw token. The claim page shows the token once. Next to it are the addresses to connect to. There are also copy-and-paste settings to use. They cover Claude Desktop, Cursor, a plain MCP client, and an OpenAI-compatible client.
A renewal extends access. A plan change swaps the tier. A failed payment opens a grace window that you control. It is 72 hours by default. So a customer is not cut off at the first retry. A cancellation, a refund, or a dispute closes access right away. Each of those defaults is set per status. You can change them.
If a token leaks, you issue a new one. The new one kills the old one. The customer gets a fresh claim link.

One-time purchases work as time-boxed passes. A pass lasts a fixed time. Its usage policy caps how much can be used in total.

#What customers get

A customer token is just one more actor with a contract. It stands at the same gate as everything else. It reaches just the tools its tier grants. It has its own rate and period limits. Every call is marked with its name and written in the audit diary. Three access types cover the common product shapes:

MCP tools: the tools you granted show up in the customer's own agent.
Peer chat: another Recued asks your server's AI over the MCP link.
OpenAI-compatible endpoint: a base URL plus an API key for chat apps. Use it when the product is "ask my operated knowledge". Do not use it for "call my tools from your agent."

Self-service goes through the same access. A status operation returns the customer's own usage, limits, and tier. It also says when the period ends. So "how much have I used?" is a question their own AI can answer. You do not run an extra customer website.

#Turning on provider automation

Every provider works the same way. Two packs, installed once from the marketplace:

The seller catalog: Stripe for Sellers, Paddle for Sellers, or Lemon Squeezy for Sellers. Only the operations that selling really needs. On purpose, this is not the provider's whole API. Granting it does not hand your automations the rest of your account.
The events pack: the whole billing lifecycle in one install. Its handlers sit behind one webhook binding. They cover checkout done, renewal, failed payment, and plan change. They also cover cancelling. Pause and resume are covered where the provider has them. So you pick one delivery endpoint and the flow works. You do not build it event by event.

Then add the connection. Point the provider's webhook at the endpoint the pack asks for. The pack also asks for a category. It is the group your tiers and their customers belong to. Keep the default unless you sell separate products whose tier keys would clash. Open Settings → Seller → Setup → Providers and run Synchronize tiers. It makes one tier per Stripe entitlement feature. On Paddle or Lemon Squeezy it makes one per product. An entitlement feature is what a paid plan says the customer gets. You write each tier's grants in the contracts screen. That step is yours by design. Nothing else can do it for you.

#Before you install the provider pack

Two things to know first:

The install signs that endpoint up for all seven event types. They are parts of one flow. They are not a menu. So you choose the pack, not the event. What each handler does stays yours. The per-status policy above decides what a failed payment means. It can mean a grace window, an instant close, or nothing at all.
The events only remove the wait. A regular check reads your provider straight. It lines up customer state on its own timer. So a server that was offline when an event was sent still catches up. A webhook you never got cannot quietly leave a customer stuck. The events just make it all react in seconds. Without them it waits for the next check.

Refunds and disputes are the one place where you choose instead of install. Revoke Access cuts a customer off when a charge is fully refunded or disputed. Flag for Review only raises a notice. It does that even on partial refunds. So you can judge case by case. They ship as two packs. A seller wants one or the other, never both.

#Selling through Paddle or Lemon Squeezy

Each provider is a self-contained lane from checkout to close. Its own seller catalog and events pack. Its own webhook endpoint and tiers. Adding one never touches another. Lemon Squeezy has no automatic webhook setup. You paste the endpoint into its dashboard yourself.

With Paddle and Lemon Squeezy, tiers come from your products. A subscription always says which product it is for. So renewals, plan changes, and the normal check all line up against that product id. Lemon Squeezy asks for your store id as well. Its product list is per store.

Both providers are the merchant of record. That means they add tax on top of your price and pay you out. So Recued compares your offer amount with the price before tax. Set the offer amount to the product's price and the numbers match.

One-time passes work on both providers too, and need no product at all. A pass is a tier you create by hand, with a duration. The offer names it. On Paddle, the checkout carries the pass as an inline item. The item has the offer's price and name. You also pick a tax category for each offer. Nothing is saved to your Paddle catalog. On Lemon Squeezy, a checkout always needs a variant. So you create one single-payment variant once, at any price. Every pass checkout then pins the offer's price and name on it, for that checkout only. The buyer pays, the pass pack confirms the payment, and the claim link goes out by mail. Each pass pack asks for its own webhook endpoint. That holds on Stripe too. The pass pack watches for its own paid sessions, apart from the subscription events pack.

#What differs with Paddle and Lemon Squeezy

Some differences you will see:

Paddle pauses and resumes subscriptions. A pause opens the grace window you set for it. A resume extends access again on the same customer row.
A Lemon Squeezy cancellation keeps access until the paid period ends. Only the expiry closes it.
Lemon Squeezy cannot read a checkout's custom data back. The order key rides only in its signed webhook. So each handler checks the tie a second way. The subscription's order must be the order your server recorded.
There is no Lemon Squeezy missed-grant sweep. Its API does not say which subscriptions your server sold. The regular check still lines up every customer it already knows.

Neither pack has been driven against a live provider account yet. The handlers were built from the provider docs. Try them in the provider's test mode first.

#Running as a seller

Settings → Seller is where you run things. Each area is its own screen: overview, offers, orders, tiers, customers, usage, and setup. Every screen, every record, and every setup step has its own address. So you can bookmark a tier, or link a customer straight to their order. The grants themselves are always written by you in the contracts screen. Some practical rules:

Sell from a server that is always on and reachable. A small VPS (a rented server that stays on), not a home IP. <handle>.recued.net is the starter name. Serious sellers move on to a custom domain on their own DNS.
Test your provider's test mode from start to finish before you go live.
Your uptime is your customers' uptime.
Prefer prepaid flat tiers. Or a base fee with extra charges past a limit. Or time-boxed passes. Pure pay-after-use billing means you deliver first and collect later. The invoice comes at the end of the period. If it fails, you cannot take back what was already used.

#What this changes for everyone else

Nothing. If you never sell, contracts, outside access, and approvals work just as before. Customer rows never show up among your normal contracts. The marketplace stays free to browse, install, and publish. Selling access is something your server can do. It is not a marketplace fee.

Grants and approvals: the gate that customer calls pass through.
AI chat and MCP: the access types customers connect through.
Reachability: giving your server a steady public name.