对于我在大学的最后一个项目，我想编写自己的支付处理系统。它将有一个后端支付处理服务器和客户端（商家）前端。
我想让后端运行并等待来自客户端服务器即商家的连接/交易。然后，后端将发挥其魔力并向商家发送回复，说明付款是否已获得授权。
我知道支付处理器和银行之间的区别。我想开发支付处理器方而不是银行，这个系统也不会与任何真正的银行集成或使用真钱。
在实践中，支付处理器与开证行进行对话并在那里获得授权。我想我可以使用一个简单的帐号表和平衡数据库表。即客户是否有足够的钱。
我希望我关注这个项目的主要领域是编写后端服务器以保持健壮并同时处理请求。我还想专注于客户端和服务器之间的加密和安全性等。我想研究PCI合规性规定等。
现在是11月初，整个项目的截止日期是2012年3月中旬。
你们对我的想法有什么看法？你认为我能在时间上取得有价值的东西吗？
答案 0 :(得分：2)
你可能会做一个相当体面的嘲笑。在实践中，大多数支付网关使用自己的通信方案包裹较低级别的交换机，因此它们可以集成诸如欺诈检测之类的增值服务。实际上不需要实现低级别的通信标准。如果你想做一个体面的模型，而不是花时间从头开始编写大量的东西，那么坚持使用Java或.Net的更多面向业务的工具。
我建议使用IIS / .Net或Tomcat / JBoss / Java创建Web服务定义，以定义授权和结算的工作方式。您可以使用.Net / Java核心库中提供的工具实现PCI DSS所需的任何内容，而无需使用第三方库。
答案 1 :(得分：2)
之前出现了一个非常类似的问题，我回答here
你可能会有一些小的误解。支付服务处理器（或PSP）通常会与收单银行通话。然后是收单银行（在幕后）将授权请求重定向到相关的发卡机构。这是通过这种方式完成的，因为收单银行（您的商家使用的同一银行）想要尝试并确保您只能将资金存入（或从退款中提取资金）已获得授权的银行账户。
如果您希望获得认证的软件，那么您可以与您想要支持的每家收单银行合作，但这将涉及您完全实施与商家银行的通信，以获取授权请求和结束日结算。如果这只是一个模型系统，那么通过认证将是一个主要障碍，并且很可能不适合您建议的时间表。
相反，我会关注PCI-DSS合规性带来的挑战。加密卡详细信息很容易。编写secure key management系统更具挑战性。总体目标是将您的卡详细信息加密到数据库，并允许您的商家通过唯一令牌ID引用这些卡详细信息。这是PSP适应的一般模型，以便令牌ID可以安全地传递给您的商家/从商家传递，而卡片详细信息本身保持安全，并且仅在与商家银行通信期间解密（用于授权/结算等）
如果您想保持简单，那么您可以专注于验证将使用您的服务的商家的通信。您可以（例如）确保商家仅尝试结算少于（或等于）已经授权针对特定卡的金额。您可以采取保护措施，防止商家通过身份验证请求错误地淹没服务（这可能会迅速耗尽持卡人的可用资金！）
祝你好运，这是一个有很大范围的好主意。