我一直在考虑设置严重依赖用户频繁和大量修改订阅的能力的 Web 应用程序。我可能也在使用市场功能,我需要一个可以无缝支持这两种功能的系统。

我见过多个关于修改订阅的复杂性的恐怖故事,包括重复计费或在错误的时间切断用户。

我真诚地希望,例如,这篇文章 http://talklikeaduck.denhaven2.com/2007/09/02/how-to-cure-the-paypal-subscription-blues

已过期。我想到的用例比他提到的更复杂。对于我想做的事情的样本:

  • 支持多个订阅和
    订阅类型/级别。为了
    例如,一个用户可能有 1 个计划 A
    每月以 10 美元和 10 美元的 C 计划计费
    每月收费 50 美元和 1 个计划 D
    每年收费 100 美元。
  • 支持更改任意支付金额。例如,用户使用每月 40 美元的计划,但随后将其更改为每月 100 美元的计划。然后取消,然后在 100 美元期限结束之前以每月 50 美元的价格再次注册。用户在支付 100 美元的那个月仍应获得 100 美元的服务,然后应更改为每月 40 美元的计划。
  • 允许在我的用户之间支付订阅金额。因此,一个用户可能会开始支付他迄今为止已支付到系统中的任何金额的 50%。我的应用程序将处理这些类型的市场样式操作,这些付款应该在订阅的上下文中工作...

  • 似乎没有一个开源 PHP 库可以满足我在 Amazon 或 Paypal 中的需求。所以我很期待自己编码。 (很高兴在这里被证明是错误的,也许是 PHP 的 Freemium?)。我不能使用 various subscription services that are available 。因为它们通常不支持上述功能,并且因为我需要直接访问 PayPal 或 Amazon FPS API,以便以后通过市场问题获得聪明才智。

    这让我想到了我的问题。为了便于管理订阅,我应该选择哪个支付平台?请给我正确的方向,我只有这么多时间。但我也没有时间做出错误的决定。请提供您偏好的证据,如果可能,请详细说明您比较两个系统的工作。谷歌拥有唯一的其他支付平台,目前他们的订阅系统处于测试阶段。如果你提出其他更好的系统,请提供大量充分的理由,因为我需要一个人们会感到舒服的流行支付引擎!

    -FT

    最佳答案

    我看到您在 12 月份问过这个问题……如果您还没有找到答案,我会根据我在遇到与您几乎相同的业务问题方面的经验提出一些建议。

    您打算使用哪个 PayPal API?在使用 PayFlow XML API 时,我发现推出自己的订阅服务要容易数千倍。如果您使用的 API 支持基于之前成功的交易 ID 创建“引用交易”,那么您可以通过跟踪用户的订阅金额、跟踪已支付的金额以及创建运行的计费脚本来避免头疼在每天的 cronjob 中,检查每个用户是否需要支付(以及支付多少),然后为每个用户创建一个引用销售。

    当然,不要忘记在开始定期计费之前必须明确征求用户的许可,并且应该有良好的定期计费和隐私政策。这种设置的一个问题是您几乎需要创建自己的脚本来管理人们的订阅和付款——幸运的是,我将 PayPal 定期计费附加到一个已经内置了订阅和会计的网络应用程序上。

    如果您需要有关如何解决此问题的任何建议,请告诉我!

    关于php - 使用 PayPal 与 Amazon FPS 修改订阅,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/4489101/

    10-16 14:49