使用 Rails 和 ActiveMerchant 进行定期计费：最佳实践、陷阱、陷阱？

我们正在准备发布一个大型 Web 应用程序，该应用程序已经开发了一年。我们即将开始集成 ActiveMerchant 来处理该服务的经常性订阅费用。

我正在寻找有关考虑我们的要求（如下所列）的最佳实践的任何建议，以及针对常见陷阱或我应该特别考虑的特定问题的任何其他提示。我们将使用的支付网关是支付宝 http://www.paymentExpress.com.au因为它是为数不多的支持定期计费的网关之一，并且对于在美国境外运营的公司没有任何特殊条件。该应用程序背后的业务总部位于英国。

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

• 所有用户均可获得 30 天试用期
• 有不同的计划，包括免费的计划
• 价格较高的计划对其帐户中可以拥有的数据量（例如用户、项目等）有较大的限制
• 计费周期为每月，​​试用后开始
• 将会有折扣/优惠券代码，以便按计划等获得一年正常价格的一定百分比。
• 计划定价将随着功能的添加而变化

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

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

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

我应该透露一下，我们计划将很多代码库建立在SaaSy http://github.com/maccman/saasy/tree/master。 SaaSy 旨在用作单独的 Rails 应用程序，处理所有注册和帐户管理方面的事情。然而，这对我们来说不起作用，因为我们从一开始就没有计划这样做，并且使我们的应用程序适应这样的工作将是一个乏味的过程。因此，我们将从 SaaSy 中提取代码和想法并将它们合并到我们的应用程序中，这是一项相当不那么繁琐的任务。

我想补充的一件事是：请记住，您不需要使用网关内置的定期计费功能。一般来说，这些系统都是遗留系统，非常难以处理，我们在铁路世界中被宠坏了。

您只需将它们用于一个目的即可获得更大的灵活性（对信用卡进行计费，或许还可以存储信用卡以符合 PCI 合规性）。然后使用 cron 作业在 Rails 应用程序中滚动您自己的定期计费、付款时间的日期字段以及每个人支付的金额（如果他们使用优惠券）等。

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