diff --git a/agent.html b/agent.html index fd6f61b..f70ef0f 100644 --- a/agent.html +++ b/agent.html @@ -27,6 +27,7 @@
A product can have one policy or many. Multi-tier ladders (think Basic / Pro / Max) are first-class: when a product has two or more public policies, the buy page renders a tier picker and the buyer chooses before paying. The displayed tier is selected from a ?policy=<slug> URL hint, then the highlighted ("most popular") policy if any, then the cheapest. Tier ordering on the picker is operator-controlled via drag-and-drop in the admin UI (or tier_rank in the API).
You can also attach private policies for manual issuance, e.g. a longer-duration "Lifetime" comp for conferences, a richer-entitlement "Internal" tier for support cases. Private policies don’t appear on the buy page; the admin API issues them directly.
+By default a Keysat instance sells for one business. On first boot it creates a single default merchant profile from your operator name, and every product you create attaches to it. If you only ever run one business, you can ignore profiles entirely: everything works against the default.
+On the Pro and Patron tiers you can run more than one business from the same instance. A merchant profile is one business identity, and it owns:
+{invoice_id} substituted), or the Keysat receipt page if you leave it blank.So one operator, on one Start9, can sell Recaps under the Recaps brand (settling to the Recaps wallet) and Aurora under the Aurora brand (settling to the Aurora wallet) side by side, with separate checkout branding and separate books. Keysat is still not a shared SaaS: two independent sellers each run their own box. What profiles add is multiple businesses under one operator.
+ +| Concept | What it is |
|---|---|
| Default profile | Auto-created on first boot, exactly one per instance. A product with no explicit profile resolves to it. |
| Payment provider | One configured BTCPay or Zaprite account, attached to a profile. A profile can have more than one. |
| Rail | A buyer-facing payment method: Lightning, on-chain, or card. BTCPay serves Lightning and on-chain; Zaprite adds card. |
| Rail preference | A tie-breaker for when a profile has two providers that both serve the same rail: it sets which one wins. |
Manage all of this in the admin UI under Merchant profiles: create a profile, set its branding, connect BTCPay or Zaprite to it, mark one as the default, and attach products. Connecting a provider to a profile uses the same one-click authorize handshake as Connect BTCPay in setup, just scoped to the profile you start it from.
+ +Running one business? Skip this. The default profile is created for you and every product uses it automatically. Merchant profiles only start to matter when you want a second brand or a second wallet on the same instance, which is a Pro and Patron capability.
+Four kinds:
@@ -182,6 +211,7 @@