2012-02-23 56 views
1

我将很快提供一些基于Web的服务,并且我正在开发订阅系统。用户每月支付(或者可以提前几个月支付),但我提供不同的软件包。不同的软件包允许他们每天使用系统x分钟。订阅套餐并存储它们

因此,例如

包一个让他们使用它一天
套餐二让他们使用它一天
套餐三让他们使用它一天

10分钟5分钟2分钟

等等。这些都是每月。

我现在的方法可以让我设置他们的包和他们的订阅何时结束。我想改变它,以便他们可以有多个包。

我的问题是这样的:

他们买一包。他们使用它两天,并决定他们想升级到另一个软件包。他们购买第二包。现在他们有2个月的时间(减去两天),但是它将包装二。从本质上来说,他们仅仅为套餐一的价格获得了两个月的套餐。

所以我的想法是这样的:

我可以单独存储每一笔交易,并在当包结束设定每笔交易和封装它。然后我可以SELECT `package` FROM `packages` WHERE `status`='active????' ORDER BY `package` DESC LIMIT 1;这将允许我选择他们的高级包,并给他们,直到那个变得不活动,然后恢复到较小的包。问题是这个`status`='active'没有跟踪日期。我怎样才能正确地做到这一点?

回答

0

我曾与“每分钟付费”的交易,这是一个恐怖的故事。至少我提出的场景是因为客户端时间和服务器端可以是两个不同的世界(例如暂停加载的流式视频与用户在页面上的日期差异决定的实际时间)。

这是我们如何处理它 - 除了平衡打嗝补偿 - 用户购买分钟简单明了。如果他们升级,他们将根据他们在购买新的分钟后收取的价格按比例分摊未使用的分钟数。这样,如果在退款发生后收费时出现问题,您不会失利。 退款不是文字交易。它会转储到与用户相关的余额中,然后按比例分摊的金额降低升级价格。将付费分钟数恢复为零 - 在添加新的升级分钟数之前。

系统中的漏洞通过将每个“单元”减少到最低的形式并将经济基于该数字而解决。所以没有“包装”可言。根据购买用户的时间,用户数量和每分钟成本只有几分钟。这样,如果您的费率发生变化,则不会影响可能预付多年的旧用户。

请注意,这是一个简化的例子。实际的系统非常复杂。

对于您的情况,每日限制只是一个关系表,它可以在单个负载的基础上存储日期和集体页面时间,但是您选择确定该时间。没有一个试图积累的条目,但是您可以收集尽可能小的个人条目,并尽可能地将它们汇总。如果有人抱怨说他们的电脑冻结了,并且他们的时间超出了他们的控制范围,这将为您节省大量时间。 因此,当您的总和脚本检测到分钟已达到或超过他们目前的限制,它只是拒绝访问。

0

你应该只有一个包。升级时应减去新旧包装中使用的分钟数。只要保留旧的包是历史记录。