Lemon Squeezy

Lemon Squeezy 把托管结账、订阅、数字文件与软件许可证放在同一套 Merchant of Record（MoR）流程里。它能代开发者处理覆盖市场的销售税和买家账单，但不会自动解决“哪位用户、哪台设备、哪个商品版本应该获得什么权限”。软件团队真正需要设计的是订单、订阅、许可证密钥、激活实例与本地账号之间的映射。

先把许可证对象关系建完整

一次性商品可为许可证设置有效期与激活上限；订阅商品的密钥通常随订阅有效，并在订阅实际到期后失效。应用数据库至少应保存本地用户 ID、store_id、product_id、variant_id、订单或订阅 ID、license key ID 和当前授权状态。只保存用户输入的密钥字符串，会让换版本、退款和多设备管理都失去可靠依据。

激活接口不是一次“查真伪”

1. 客户端把密钥交给自己的后端，不在应用里暴露后台 API 凭据。
2. 后端调用 License API 的激活端点，提交 license_key 与可识别设备的 instance_name。
3. 激活成功后保存返回的 instance.id；后续验证和停用都需要它。
4. 除检查 valid 外，还要比对 store_id、product_id 或 variant_id，避免同一商店里其他商品的真密钥误解锁当前产品。

官方 License API 当前限速为每分钟 60 次请求，不适合让每个界面操作都实时调用。较稳妥的做法是本地缓存短期验证结果，并在启动、联网恢复或固定间隔重新验证。

换机与订阅取消要走不同状态

客户自助和服务端事件各负其责

Customer Portal 可让客户查看订单、管理订阅和下载内容。带签名的 Portal URL 当前有效期为 24 小时，因此用户点击“管理账单”时应从最新 Customer 或 Subscription 对象获取新链接，不宜永久写进数据库；无签名入口则会走邮件 magic link。若允许套餐升级或降级，还应在 Portal 设置里明确可切换的变体，并给用户提供返回产品的链接。

Webhook 接收端必须用 signing secret 校验请求头 X-Signature，保存事件后尽快返回 HTTP 200，再异步更新订单与权限。非 200 响应会触发自动重试，因此处理器要按事件或对象 ID 幂等。结账成功页只负责告诉用户“订单正在处理”，不能代替服务端发货。

上线前用一张矩阵验收收款与授权

• 一次性订单：首次激活、重复激活、达到设备上限、旧设备停用、新设备重新激活。
• 订阅订单：初购、续费成功、续费失败、主动取消但周期未结束、最终到期。
• 售后：全额或部分退款后，许可证与本地权益是否按既定政策变化。
• 恢复：Webhook 重复、乱序或短暂失败后，本地状态能否由平台对象重新校正。

2026-09-14 核对的官方价格页列出基础交易费 5% + 50 美分，国际交易、PayPal、订阅付款和部分提现还可能产生附加费。低客单价或国际客户较多时，应按真实支付方式计算净收入；可结合 独立开发者收款平台对比评估。访问地址：https://www.lemonsqueezy.com/