ruby-on-rails - 使用 Rails 和 ActiveMerchant 重复计费 : Best practices, 陷阱，陷阱？

Question

我们正在准备发布一个在过去一年中一直在开发的大型网络应用程序。我们即将开始集成 ActiveMerchant 的过程，以处理该服务的经常性订阅费用。

我正在寻找关于考虑到我们的要求(如下所列)的最佳实践的任何建议，以及关于常见陷阱或我应该特别考虑的具体问题的任何额外提示。我们将使用的支付网关是 PaymentExpress因为它是为数不多的支持定期计费的网关之一，并且对在美国境外运营的公司没有任何特殊条件。此应用程序背后的业务位于英国以外。

应用程序的用户创建一个带有子域的帐户，他们可以在其中访问和自定义应用程序及其数据。以下是可能会影响计费方式的一些要求/功能:

• 所有用户都有 30 天的试用期
• 有不同的计划，包括免费的
• 价格较高的计划对其帐户中可以拥有的数据量(例如用户、项目等)有更大的限制
• 结算周期为每月，​​试用后开始
• 将提供折扣/优惠券代码，以在计划等一年的正常价格基础上获得一定比例的折扣。
• 计划定价会随着功能的添加而改变

我可以预见的具体障碍包括以下内容:

• 当他们违反较低级别计划的计划限制时如何处理降级。
• 信用卡过期或付款未通过时的行为(可能强制执行只读模式)
• 当计划定价发生变化时，我们希望在一段时间内(例如 6 个月)为现有用户提供以前的价格，然后开始收取更高的费率。如果计划价格下降，将立即生效。

其他有用的建议是关于应用程序流程的任何内容。应如何向用户呈现计费表单？什么时候需要信用卡信息？应如何发送、存储和访问发票？

我应该透露一下，我们计划将大量代码库作为 SaaSy 的基础. SaaSy 旨在用作单独的 Rails 应用程序，处理所有注册和帐户管理方面的事情。然而，这对我们不起作用，因为我们从未从一开始就为此计划过，而且要使我们的应用程序适应这样的工作将是一个乏味的过程。因此，我们将从 SaaSy 中提取代码和想法并将它们合并到我们的应用程序中，这是一项相当简单的任务。

Answer 1

我想补充一点:请记住，您不需要使用网关中内置的定期计费功能。一般来说，这些系统是遗留的并且很难处理，我们在 rails 世界中被宠坏了。

仅将它们用于一个目的(为信用卡计费，也许还存储信用卡以符合 PCI)，您将获得更大的灵 active 。然后在你的 Rails 应用程序中使用 cron 作业滚动你自己的经常性账单，一个他们付款的日期字段，以及每个人支付的金额(如果他们使用优惠券)等。

举个小例子:有时人们会在月中取消包月。他们想确保在下次付款前不会忘记取消。我见过的大多数网关定期计费都会立即终止帐户(或向您发送一条消息表明这一点)。实际上，用户已经支付了月底的费用，应该再获得 2 周的访问权限。如果您已在 rails 中滚动自己的定期计费，则可以执行此操作，但如果您使用的是网关定期计费，则不能这样做。只是一个小例子。