构件
Lugo · 账号与计费
成熟度：内部生产使用装进你自己环境的账号、钱包与收款底座：一套登录通行你的所有应用，一个钱包承接所有扣费，每一笔钱从下单到退款都有账可查。
每个客户独立一套：自己的域名、数据库、身份源与密钥。我们自己的全部产品也跑在它上面。
交付就绪 · internal_auth— 需处理有服务调用内部接口被拒（invalid_key）—— 这类故障平时是静默的，这里会被点名
它做什么
钱路上的每一步，都能对上账。
你的应用不必各自造用户体系、各自接支付。账号在这里注册，钱包在这里扣费， 支付回调在这里验签落账，退款原路返回，渠道对账单每天自动比对。
细节
四件事，按需展开。
账号与登录：一次登录，所有应用通行。
基于 OIDC 的单点登录，支持通行密钥（Passkey）、两步验证与社交登录； 企业已有的身份源（如 Okta、Entra ID、Keycloak）经 OIDC 联合登录接入， 员工名单可经 SCIM 2.0 自动同步成组织成员。
组织之间的数据隔离由数据库行级安全（RLS）强制执行，不只靠应用代码自觉。
钱与账：多家渠道，一本账。
支付宝与微信支付直连、Stripe、对公转账等渠道注册进同一个收款中心： 回调逐笔验签并核对商户、金额与订单号；漏掉的回调由主动查单兜底； 退款幂等、原路返回；渠道日对账单自动下载比对。 对公转账按附言码自动核销，网银流水可导入并查重。
支付密钥在控制台粘贴即生效，不用重启。发票与红字冲销单可直接下载； 销售方主体没配置时，接口拒绝出票，而不是替你编一个。
渠道对账 · 支付宝— 一致日对账单与平台台账逐笔比对，金额与笔数相符
订单 · 回调缺失— 已查单补账未收到渠道回调 —— 主动查单确认已支付后入账，并留下补账记录
权益：应用离线判断用户能用什么。
订阅与套餐换算成一张签名的权益令牌，你的应用用公开的 entkit 校验库 在本地验签，就知道这个账号能用什么，不必每次回源查询。
签名密钥在安装时于你的环境里生成，只归你所有；不存在由我们签发的许可证。
安装与交付就绪：装完，看板全绿才算完。
一条命令安装：单机用 Docker Compose，集群用 Helm。每一步要么跳过、要么收敛， 失败后重跑同一条命令就从断点继续。
安装终点是控制台里的「交付就绪」看板：数据库迁移、内部鉴权、登录回跳、 支付、邮件、短信等逐项亮绿、黄或灰。灰表示功能未开启，不算错误； 黄的每一项都写明去哪里修。
接口以 OpenAPI 3.1 描述，在你的实例上可以在线浏览与调试； 服务等级指标有一页公开的状态页。
我们自己这套的接口规范公开可读，无需登录： 在线 API 参考 · openapi.yaml。
即将上线
一个账号、一个钱包、所有产品。
Hub、Tally、Kova、鹿途用同一个账号登录，从同一个钱包扣费。 钱包按产品列出本月各花了多少、扣了几笔；从任何一个产品去充值，付完一键回到原来的产品。
边界与现状
它现在在哪儿，不做什么。
- 现状：作为我们自己全部产品的账号与计费底座，在我们的准生产环境运行； 客户私有安装的流程已在全新环境中演练过。
- 在线收款（支付宝、微信支付直连）的下单、回调、退款与对账代码已就绪并有测试覆盖， 但还没有用真实商户号跑通过。首个真实商户开通前，请把它当作「就绪待验证」，不是「已交付」。
- 一套安装只服务一个客户。设置、产品目录、品牌与支付在一套安装内是全局的， 不做一套服务多客户的白标。
- 身份源目前固定为 Zitadel；企业自有身份源通过联合登录接入，不替换它。
- 数据导出、凭据自动轮换等能力代码已在，但默认关闭。在你的部署里开启并验证之前， 请把它们当作「可用但未开」。
- 不做资金代收代付：你的钱进你自己的商户号。
想看它装进你的环境是什么样，写信到 contact@lurus.cn；部署与接入细节见 文档，或先读 方法。