问题标签 [billing]

开源的东西，或者便宜的东西。最好在 php 中，将考虑其他语言。我主要在寻找干净的代码，这是一个很好的地方。我不需要任何 CMS 功能。

我从事编程多年，也做过一些专业的编程项目。我最近有一个朋友问我要创建一个电子商务网站，但我不得不拒绝她，因为我从来没有开发过可以计费的 Web 应用程序。我将来可能还需要编写一个基于订阅的 Web 服务。我的问题是，我什至如何开始计费？我从来没有找到这方面的指南，而且我几乎不知道银行账户是如何运作的，因为我不管理自己的账户（我只有 16 岁，所以我有一个借口）。

我不知道答案是否取决于语言，但如果是我感兴趣的语言是 Python、C/C++ 和 Java。

我正在使用 App Engine RemoteApiServlet 和 Bulkloader 将数据加载到数据存储中。由于我上传的数据集很大（一百万个实体），我在我的应用程序上启用了“计费”并设置了最大值。每日预算为 5 美元，之后为 10 美元。

在我加载实体后，使用 App Engine 管理控制台，我确定我需要为 CPU 小时支付约 7 美元的费用（因为我最终使用了约 70 个 CPU 小时）。然而，当我查看计费历史时，我只收取了 0.05 美元（用于存储）和 0.0 美元的 CPU 小时数。

我想知道这是否是预期的？使用 RemoteApiServlet 批量加载是否不按 CPU 小时计费？如果是，当我将最大每日预算设置为 5 美元并超过我的 CPU 配额时，我开始从服务中获取 HTTP 503。如果 RemoteApiServlet 的使用免于计费，那么为什么我会看到 503 错误？

我正在 Azure 中设计一个 Web 服务。是否可以按最终用户计量实际的 Azure 平台使用成本？Azure 是否向最终用户提供计费服务？

我们希望将计费功能添加到我们的 Rails 驱动的 Web 应用程序中。我遇到了两个可以做到这一点的插件——Service Merchant（免费）和SaaS Rails 套件（需要花钱）。

有人对这些插件（或其他具有相同功能的插件）有一些经验吗？你会推荐哪一个？

谢谢！

我的一个客户正在为一个项目使用州外程序员。他无法真正弄清楚程序员实际上做了多少工作，所以他担心钱可能会付诸东流。

我想知道，是否可以使用 SVN 或 GIT 存储库来计算或估计实际完成了多少实际工作？比如找出两个修订版或给定时间段之间的差异，并对已完成的工作进行总结/概述？

显然，您可以简单地在某些代码中添加或删除空格，SVN 会在提交时将其视为更改，但这并不意味着实际完成了任何工作。也许有一些方法或脚本可以考虑所有这些事情，并可能分析文件大小等方面的差异并确定完成了哪些工作。

当然，您可以手动手动检查修订并对其运行差异，但能够获得更多关于所有内容的摘要会更有帮助。

无论如何，那里有这样的东西吗？

我正在尝试使用我的 flex 应用程序让亚马逊支付工作，如下所示：http: //miti.pricope.com/2009/07/11/using-amazon-flexible-payment-system-with-flex/

我完全按照他说的做了，我已经下载了文件并更改了访问密钥和密钥。当我在本地主机或生产服务器上运行它时，我得到“签名不匹配”

我还需要什么才能让它工作？还有什么我需要他忘记包括的东西吗？

我需要解决一个问题，即分析页面上的电子商务报告显示的销售额比 Magento 报告少 30%。

我想知道我将分析代码与销售交易放在哪里？付款后在成功页面？
在我们的电子商务中，我们使用第三方计费应用程序让用户导航到另一个页面，我猜，有时用户只是不返回成功页面。所以我想这可能是问题所在。

谢谢，
乔

我目前正在为我的一个客户开发一个 Web 应用程序。该客户要求使用小型计费模块。客户端 istelf 是小型 SIP 提供商。有几种定价项目、计划等。它们都是不同类型的付款，如一次性、每月、每年。有没有关于 blling 系统架构的最佳实践、好书、文章？

顺便说一句，基于 symfony 框架的网络应用程序。

任何帮助表示赞赏！

我的公司目前正在为我们的客户建立一个在线计费门户。我很好奇这个问题在开发人员和测试人员之间来来回回：当显示客户希望支付的金额的输入表单时，您是否将默认设置为客户所欠的最大金额？当我支付自己的账单时，环顾一下网站，我倾向于看到三种不同的设置：

1. 最大欠款在输入中
2. 什么都没有放入
3. 支付最大值、最小值或您自己的输入的按钮选项

一般来说，我们同意您的最大和最小金额应该显示在屏幕上的某个地方（当网站可以显示欠款时，去寻找您的账单很烦人）。是否有标准或看起来最友好的标准？选项 1 很好，因为它都在那里，但可能会惹恼客户，或者客户可能会在没有意识到的情况下意外支付大笔款项（听起来很愚蠢，但你知道它会发生在某人身上）。选项 2 给客户一种付款控制的感觉，但让他们每次都必须输入金额而烦恼。选项 3 看起来是一个中间立场，但当 1 和 2 看起来更简单、更清晰时，它似乎有点不必要的工作和维护。