具有REST API功能的EMV芯片阅读器/支付处理器解决方案

我希望实现一个EMV芯片读写器/支付处理器解决方案，具有RESTAPI功能和卡验证模式（CVMs）：信用卡芯片和签名，芯片和借记卡PIN

以下是我需要的流程：

基于Web的POS将事务发送到服务器

保存交易信息（订单号、产品号、总数等）。服务器向EMV发送API请求，以启动信用卡/借记卡支付流程。HTTP本地网络连接

EMV通过HTTP接收来自服务器的API请求，并开始捕获支付过程。 连接到支付网关以处理支付。注意：EMV必须具有RESTAPI功能

支付网关处理支付并将应答发送回EMV，EMV将应答发送回服务器以更新交易记录

服务器将应答发送给主机以完成事务，具体取决于收到的应答

---

以前有人实现过这种解决方案吗？如果是这样，使用了哪种解决方案（正方形、三叶草等）？

您可以添加一个简单的说明，以使交互更加清晰。EMV是一种规范或标准供参考

在步骤2中。你的意思是说你有一个EMV认证的终端，它公开了一个API，服务器可以调用该API来启动一个卡交易？在这种情况下，HTTP连接在服务器和终端之间，芯片和终端的连接是直接的。对的这是可以做到的

第三步。既然终端已经与APDUs中的卡进行了通信，并且手头有一个密码（ARQC，它要求您将请求发送给发卡机构进行验证-Onilne），那么您需要与收单机构进行通信。此通信取决于您的实现。你可以通过肥皂或休息或其他方式来做

第四步。如果存在ARPC，则应将其转发给卡，卡将对其进行验证，并确保响应来自正确的发卡机构。否则，它可能会向收单机构发送撤销（如果回复获得批准）。如果ARPC已验证，请呼叫主机更新付款

在任何情况下，如果您正在寻找一种服务器将直接与卡通信的解决方案，那么它很可能无法工作，因为它将无法满足APDU之间可接受的时间线

---

你还没有告诉我你的问题。您是否正在尝试确定您所提议的体系结构的可行性？

您的问题实际上不属于stackoverflow——它不是编程，您没有显示任何代码，也没有描述您正在做什么以及到目前为止您做了什么

您所描述的是零售ECR协议的非常通用的描述。有许多变体和实现，有些可能会公开REST。有些可能与向POS公开REST API的中央服务器一起工作，另一些可能在EFT终端端有一个侦听端口（通常在连接数量和连接源等方面应该有一些防火墙限制）。几乎任何收单机构或PSP都会有一些实现（但不一定是HTTP上的REST），因此您可能希望从您当地的服务提供商开始，因为他们可能最能反映您在接受方法、支持的卡方案等方面的需求。

您要求的是“流程”但接下来继续准确地描述这一点。您是否正在开发自己的解决方案？为什么您提到Square&Clover（也有您描述的类似流程）？你有实际的编程问题吗？