使用第三方计费/订阅系统 (ChargeBee) 的 SaaS 应用程序设计

Question

我已经构建了一个 SaaS 解决方案，目前可以免费使用。我刚刚开始为用户提供按月或按年进行升级和付费的能力。

我想卸载所有“困难”的东西，以便我可以专注于构建一个好的产品。我所说的“困难”是指支付处理、后端管理功能、计费分析、PCI 合规性等。

我使用 ChargeBee 和 Stripe 作为网关。

但是，我不确定如何构建应用程序。我是一名全栈开发人员，但我知道我的架构知识有限，我不想通过构建一个糟糕的解决方案来逼迫自己。

注册过程如下：

1. [我的应用程序] 用户输入他们的电子邮件、密码，然后选择他们想要的计划
2. [在 ChargeBee 上托管] 用户被重定向到托管的 ChargeBee 付款页面并输入他们的帐单详细信息
3. [我的应用程序] 用户被重定向回我的应用程序，响应中包含订阅/用户数据

现在我的主要问题是：

• 我应该在两个应用程序（我自己的应用程序和 ChargeBee 应用程序）中存储和依赖哪些数据？
• 当用户进入我的域后，我如何知道为用户提供什么访问级别 - 我是在我的中间件中 ping ChargeBee 以了解用户的计划，还是应该将这些数据也保存在我自己的应用程序中和 ChargeBee 一样（比如双重会计？）

我没有看到一直 ping ChargeBee 以返回订阅信息的问题，但那又是“正确”的做法吗？如果是这样，我应该在登录时为用户缓存 ChargeBee 信息吗？

谢谢， 乔

Answer 1

我没有发现一直 ping ChargeBee 以返回订阅信息的问题，但那又是“正确”的做法吗？如果是这样，我应该在登录时为用户缓存 ChargeBee 信息吗？

我认为这里没有任何正确的答案。但请注意，Chargebee 的 API 调用次数限制为每分钟 150 次。缓存可能是错误的来源，因此如果您可以选择，我更愿意直接查询 Chargebee。

Answer 2

首先，请注意我创立了 Cheddar，它是 ChargeBee 的竞争对手。

恭喜您决定使用订阅管理服务提供商。通常，人们自己构建并在以后后悔......

我想说，一般来说，您应该避免存储 ChargeBee 提供的任何东西，反之亦然。保持这种双重存储同步可能会有问题。我对 ChargeBee 如何适应商家应用程序的访问控制并不十分熟悉，但我猜他们希望他们会以您建议的方式对信息进行 ping 操作。

您会希望避免以不合理的水平访问他们的 API。很容易陷入这样一种架构，即在每个页面视图上都从上游请求当前信息。您已经考虑到了，似乎……以下是您可能考虑的其他一些问题：

1. 在每个页面视图上调用上游 API 的开销会使您的应用程序在最终用户看来速度很慢。
2. 如果上游服务不可用，您的应用程序也是如此。

使用基本缓存机制来缓解这些问题是一个不错的方法。显然有很多方法可以做到这一点。只需保持到期时间较短即可。说，1小时。你可以在路上延长它。如果您想更进一步，并假设 ChargeBee 支持 webhook，您可能会考虑将您的应用设置为侦听可能会更改用户状态并相应地使该用户的任何缓存无效的相关挂钩。

Answer 3

我也使用了一年多的有条纹的 Chargebee，我觉得它很可靠。我认为根据您的流程，您应该存储 customerId，如果需要，还应该存储 subscriptionid 和客户的一些基本数据。