使用 PayPal 与 Amazon FPS 修改订阅
我一直在考虑设置严重依赖于用户频繁且大幅修改订阅的能力的 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 的免费增值？）。我无法使用各种可用的订阅服务。因为它们通常不支持上述功能，并且因为我需要直接访问 PayPal 或 Amazon FPS API，以便以后通过市场问题发挥聪明才智。
这让我想到了我的问题。我应该选择哪个支付平台以便于管理订阅？请给我指明正确的方向，我只有这么多时间。但我也没有时间做出错误的决定。请提供您的偏好证据，如果可能的话，请详细说明您比较这两个系统的工作。谷歌拥有唯一的其他支付平台，目前他们的订阅系统正处于测试阶段。如果您提出其他更好的系统，请提供大量充分的理由，因为我需要一个人们会感到舒服的流行支付引擎！
-FT
I have been looking at setting up web applications that rely heavily on the ability for users to frequently and substantially modify subscriptions. I may be using marketplace features as well, and I need a system that supports both seamlessly.
I have seen multiple horror stories about the complexity of modifying subscriptions, including double billing, or cutting users off at the wrong time.
I sincerely hope, for instance, that this article http://talklikeaduck.denhaven2.com/2007/09/02/how-to-cure-the-paypal-subscription-blues
is out of date. The use cases that I have in mind are even more complex than the ones that he mentioned. For a sampling of what I would like to do:
- Support multiple subscriptions and
subscription types/levels. For
instance one user might have 1 Plan A
billed monthly at $10 and 10 plan C
billed at $50 per month and 1 Plan D
billed at $100 per year. - Support changing of arbitrary payment amounts. For instance, user was on the $40 per month plan, but then changes that to a $100 per month plan. Then cancels, then signs up again at $50 per month before the $100 period was up. The user should still get $100 of service for the month that he paid $100 for, and then should change to the $40 per month plan.
- Allow for payments of subscription amounts between my users. So one user might initiate a payment of 50% of whatever amount he has paid into the system so far. My application will be handling these types of marketplace style operations and these payments should work in the context of subscriptions...
It does not appear that there is an Open Source PHP library that does what I need either with Amazon or Paypal. So I am looking forward to coding this myself. (be glad to be proved wrong here, perhaps a Freemium for PHP?). I cannot use the various subscription services that are available. Because they generally do not support the features above, and because I need to have direct access to the PayPal or Amazon FPS API for later cleverness via marketplace issues.
Which brings me to my question. Which payment platform should I choose for ease of managing subscriptions? Please send me in the right direction, I only have so much time. But I also do not have time to make the wrong decision. Please provide evidence for your preferences, and if possible detail your work comparing the two systems. Google has the only other payment platform and currently their subscription system is in beta.. If you propose some other better system, please provider tons of good reasons, because I need a popular payment engine that people will feel comfortable with!
-FT
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我看到你在 12 月份就问过这个问题...如果你还没有找到答案，我根据我处理与你的业务问题几乎相同的经验提供一些建议。
您考虑使用哪种 PayPal API？在使用 PayFlow XML API 时，我发现推出自己的订阅服务要容易数千倍。如果您使用的 API 支持根据之前成功的交易 ID 创建“参考交易”，那么您可以通过跟踪用户的订阅金额、跟踪已支付的金额以及创建运行的计费脚本来省去您的麻烦。在每日定时任务中，检查每个用户是否需要付款（以及多少），然后为每个用户创建参考销售。
当然，不要忘记，在开始定期计费之前，您必须明确征求用户的许可，并且应该有良好的定期计费和隐私政策。这种设置的一个问题是，您几乎需要创建自己的脚本来管理人们的订阅和付款 - 幸运的是，我将 PayPal 定期计费添加到已经内置订阅和会计的 Web 应用程序上。
如果您需要有关如何解决此问题的任何建议，请告诉我！
I see you asked this question back in December... if you haven't found an answer yet, I have some suggestions based on my experience with a business problem almost identical to yours.
Which PayPal API are you thinking of using? In using the PayFlow XML API, I found it was thousands of times easier to just roll my own subscription service. If the API you're using supports creating 'reference transactions' based on the previous successful transaction ID, you may save yourself a headache by keeping track of users' subscription amounts, keeping track of what's been paid, and creating a billing script that runs on a daily cronjob, checking each user to see if they need to pay (and how much), and then creating a reference sale for each of them.
Of course, don't forget that you have to explicitly ask for users' permission before you start billing them on a recurring basis, and there should be a good recurring billing and privacy policy. One trouble with this setup is that you pretty much need to create your own scripts to manage people's subscriptions and payments -- fortunately, I was tacking PayPal recurring billing onto a web app that already had subscriptions and accounting built-in.
Let me know if you need any suggestions on how to go about this!