这可能是一个主观问题，但我会尝试一下。
SO 上已经存在许多围绕订阅计费管理的问题。我目前正在开发一个 SaaS 解决方案，该解决方案需要完全自动化的计费系统。
当我问这个问题时，我并不是在寻找关于实施特定支付网关或类似内容的建议。相反，我希望获得有关采取何种方法的建议。
我需要的功能是一个可以处理升级、降级、定期计费、取消等的系统。最初仅适用于一种产品，但随着时间的推移，可能会要求系统可以处理多种产品（我所说的产品是指根本不同的产品）产品，而不是同一产品的不同变体）。
在我看来，当您需要这样的解决方案时，有多种可能的方法：
- 自己编写一个计费服务器，支持此功能并与每个产品解耦，以便它可以处理多个独立产品。
- 使用托管解决方案，例如 Recurly、Chargify、Spreedly 或 CheddarGetter。
使用托管解决方案的优点显然是您不需要 PCI 认证，问题已外包，而且启动和运行速度要快得多。然而，这些优势是有代价的：您的产品最重要的支持功能 - 即计费不在您的控制范围内。此外，您的控制力和灵活性也较少。
你会怎么办？如果我们超越 PCI 要求，我肯定更愿意拥有一个可以完成此类工作的内部编码系统。另一方面，我从许多来源听说，编写这样的系统是一件痛苦的事情。
任何建议都将受到高度赞赏。另外，如果您建议自己编码，那么任何关于如何做到这一点的经验或者是否有任何开源项目（无论语言如何，我追求的不是代码而是结构）我都可以从中受益意思很多。
This might be a subjective question, but I'll give it a go.
There are already a number of questions on SO that revolves around subscription billing management. I am currently working on a SaaS solution that will require a fully automated billing system.
What I am not looking for when asking this question is not advice on implementing towards a specific payment gateway or stuff like that. Instead I'd like advice on what kind of approach to take.
The functionality that I need is a system that can handle upgrades, downgrades, recurring billing, cancellations, etc. Initially for one product only, but it might over time be a requirement that the system can handle multiple products (by products I mean fundamentally different products, not different variations of the same product).
As I see it there are a number of possible approaches when you need a solution like this:
- Code a billing server yourself that supports this and is decoupled from each product so that it can handle multiple independent products.
- Use a hosted solution like Recurly, Chargify, Spreedly or CheddarGetter.
The advantage of using a hosted solution is obviously that you don't need PCI certification, the concern is outsourced and it is a lot faster to get up and running. These advantages come at a cost however: The most important support function for your product - i.e. the billing is not in your control. Additionally you have less control and flexibility.
What would you do? If we look beyond the PCI requirements I would definately prefer to have a system coded in-house that could do this kind of job. On the other hand I've heard from numerous sources that coding a system like this is a pain.
Any advice is highly appreciated. Also, if you advice to code it yourself, any experiences on how to do it or if there are any opensource projects (no matter the language, what I'm after is not the code but the structure) that I can benefit from would really mean alot.
发布评论
评论（5）
我们正在从 PayPal 定期计费转向 CheddarGetter。我强烈推荐 CheddarGetter，我们评估了您提到的所有 4 个。 （Chargify 紧随其后）。 CG 支持论坛也很棒。在 http://support.cheddargetter.com 上发布问题（售前、技术等） /讨论/问题，您通常会在一天内得到清晰简洁的答案。
除非你有一个开发和支持团队无所事事地等待工作，否则我认为在大多数情况下，投入任何资源来构建内部都是错误的。专注于您的核心产品并满足客户的需求。让负责计费、催款、按比例分摊、开具发票等工作的人员/公司专注于从客户那里收款。
如果需要，您随时可以编写自己的内部计费系统。但如果你现在就开始这样做，你可能会发现自己陷入了与你的业务和核心能力相去甚远的细节之中，并且在那些正在打造出色产品并快速迭代的轻量级、更有活力的竞争对手面前失去了优势。
We're in the process of moving from PayPal recurring billing to CheddarGetter. I highly recommend CheddarGetter, and we evaluated all 4 you mention. (Chargify came in a close second). The CG support forums are great as well. Go post a question (pre-sales, technical, etc.) up on http://support.cheddargetter.com/discussions/questions and you'll usually get a clear and concise answer within a day.
Unless you have a development and support team sitting idly waiting for work, I think in the majority of cases it would be a mistake to devote any resources toward building this in-house. Focus on your core product and meeting your customers' needs. Let people/companies who live and breath billing, dunning, prorating, invoicing, etc. focus on collecting your money from your customers.
You can always write your own in-house billing system down the road if you need to. But if you start with that now, you'll likely find yourself mired in details that are far removed from your business and core competency and lose your edge to lighter more dynamic competitors who are building great products and iterating quickly.
还有一个混合答案：我的 SaaS Rails Kit（如果您在 Rails 上构建）。您不必从头开始自己构建它，但您确实可以灵活地将计费代码置于您的应用程序中，在您的控制之下并且可自定义。您仍然需要具有较低级别的 PCI 合规性，因为 CC 信息正在传输您的服务器，但您不必担心存储卡信息时涉及的更严格的合规性要求，因为套件将卡信息传递给信用卡网关并将其存储在那里。
There's also a hybrid answer: my SaaS Rails Kit (if you are building on Rails). You don't have to build it yourself from scratch, but you do get the flexibility of having the billing code in your app, under your control, and customizable. You still have to have a lower level of PCI compliance, since CC info is transiting your server, but you don't have to worry about the more strict compliance requirements involved when storing card info, since the Kit passes on the card info to the credit card gateway and stores it there.
Braintree 有一个 透明重定向 API，让您无需通过服务器传递信用卡数据即可保持控制。您将信用卡表格托管在您的网站上，但将其直接提交给 Braintree。类似的东西可能会为您提供所需的灵活性，而无需担心 PCI 合规性。
选择提供商时请记住，许多公司不会让您获取客户的信用卡数据如果您决定离开，请返回。披露：我在布伦特里工作。
Braintree has a Transparent Redirect API that allows you to maintain control without passing credit card data through your servers. You host the credit card form on your site, but submit it directly to Braintree. Something like that might give you the flexibility that you're looking for without needing to worry about PCI compliance.
Keep in mind when choosing a provider that many companies won't let you get your customers' credit card data back if you decide leave. Disclosure: I work for Braintree.
我不太有资格回答这个问题，但似乎在很多商业情况下，答案是“购买”而不是“自己做”。购买现成的解决方案风险较小，可以节省时间，从而降低总体成本。
I'm not really qualified to answer this, but it seems that in a lot of business situations the answer is "buy it" rather than "do it yourself." Purchasing off-the-shelf solutions is less risky and saves time, resulting in lower overall cost.
另一个不错的选择...
http://developers.freshbooks.com/billing
Another great option...
http://developers.freshbooks.com/billing