验证免费增值产品中的订阅服务是否有效的方法

Question

我们有一个免费增值产品，这意味着如果按月付费就可以使用某些功能； 如果未付费，则免费功能仍然可用。

以下是我正在考虑的处理方式，但想检查一下：

1）当有人购买订阅时，会创建一个定期计费计划。

2) 用户将有一个字段 (paid_up) 设置为“y”

3) 当用户重新登录时，身份验证脚本检查paid_up 是否为“y”。 如果是，它会创建一个会话令牌

4）我想我需要一个批处理脚本来切换切换。 想知道如何做吗？ 存储上次成功处理信用卡的日期？

Answer 1

当然，您将创建一个名为“last_ payment”的列。 如果使用 MySQL，您可以将其创建为日期字段。 每次您收到每月付款时，我假设信用卡计费公司都会将一些内容发布到您网站上的脚本中。 （即 paypal 发送 IPN）。 每次收到此消息时，您都会执行一个查询，例如：

UPDATE members SET `last_payment`=CURDATE() WHERE user_id='$user_id';

我建议在 CRON 上运行一个每 24 小时运行一次的脚本，并执行此查询：

UPDATE members SET paid_up='N' WHERE DATEDIFF(CURDATE(),last_payment) > '30';

这将更新 30 天或更长时间未付款的所有记录，并将 pay_up 字段设置为 N。然后您的正常登录代码就可以工作了。

如果您不想使用 CRON，您可以将您的登录查询更改为如下所示：

SELECT 1 FROM members WHERE 
username='$user' AND password='$password'
AND DATEDIFF(last_payment) <= '30';

顺便说一句，您的信用卡处理公司可能有一种在取消订阅时向您发送 POST 的方法，这将使您能够将 pay_up 字段设置为 N。

希望这会有所帮助。 如果您有任何疑问，请随时发表评论:)

Answer 2

我将从另一端进行此操作，并有一个付费字段，其中存储了付费更新日期。 这样，您就可以让用户取消该子项目，但仍然可以享受他们所付款项的好处。

Answer 3

如果定期计费流程是您自己运行的，您可以将这些检查作为流程的一部分。 我从算法上思考这个问题的方式是这样的：

对于每个到期的客户
    在其帐户上运行计费
    如果成功：
        将重试次数重置为 0
        将他们标记为付费客户
        继续下一个帐户
    否则：
       增加重试计数器
        向客户发送警报
       如果重试计数器达到最大值：
         
切换开关将它们标记为免费

如果其他程序运行计费并只告诉您结果，您可以批量执行相同的操作，只需将“在其帐户上运行计费”替换为“读取上次计费尝试的结果”即可。 您的重试计数器会实施类似宽限期的措施，假设您的账单按每日计划运行，这样他们就有机会解决账单问题，而不是仅仅因为他们的卡过期或类似原因而撤销其高级功能。

Answer 4

之前已经写过其中一些内容，您应该做一些事情。

首先，正如其他人提到的，您需要某种paid_through_date 字段。 出于多种原因，这一点很重要，但最主要的是，它为您提供了额外的灵活性，例如，在您的服务器出现故障时，您决定用户应该获得额外一天的免费服务。 只需将其 pay_through_date 值推迟一天即可。 这也使得免费试用变得易于实施。

其次，不要使用像 Authorize.net 的自动定期计费之类的东西，即使您正在使用订阅系统。 您希望完全控制付款的安排时间，而在大多数情况下，将责任转移给您的网关并不是一个好主意。 大多数网关允许您在其服务器上存储信用卡。 他们会返还给您该卡的 ID，您可以根据该中间 ID 而不是卡本身收取费用。

第三，记录所有交易。 我怎么强调都不为过。 事实上，您也应该将此日志公开给用户。 基本上只是一张表格，列出了他们已支付的所有款项、金额和最终余额。 将发票放入此表中也是很常见的。 发票的金额为正数，付款和信用额为负数，用户只需将所有内容相加即可获得最终余额。 如果需要，您可以很容易地向该表中引入任意积分。

运行每 24 小时触发一次的 cron 脚本，检查用户生成发票所需的内容。 这个 cron 脚本应该具有三个关键属性：首先，如果它由于某种原因没有运行，您不应该损失一天的费用。 其次，如果它每天运行一次以上，或者中途中止并重新运行，那么它不应该向人们收取两次费用。 第三，如果服务器上的日期意外更改为 2090 年，它不应自动向所有用户收取数百万美元的费用。 同样，重置到过去的日期（特别是 1970 年 1 月 1 日）也会导致它引发地狱。 根据我的经验，夏令时很少是一个问题。

我认为这涵盖了大部分重要内容，但计费系统中总是存在一些需要注意的小问题。