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