我希望用REST API功能和卡验证模式（CVMS）实现EMV芯片读取器/付款处理器解决方案：信用卡的芯片和签名用于借记卡。
这是我需要的过程流程：
-
基于Web的POS将事务发送到服务器。
-
保存交易信息（订单号，产品编号，总计等）。服务器向EMV发送API请求，以开始信用/借记卡付款过程。HTTP本地网络连接。
-
EMV通过HTTP从服务器接收API请求，并开始捕获付款过程。连接到处理付款的付款网关。注意：EMV必须具有REST API功能。
-
付款网关处理付款并将答案发送回EMV，将答案发送回服务器以更新交易记录。
-
服务器将答案发送给主机以最终确定交易，具体取决于收到的答案。
以前有人实施过这种解决方案吗？如果是这样，使用了哪种解决方案（正方形，三叶草等）？
您的问题实际上并不属于stackoverflow - 它不是编程，您尚未显示任何代码，也没有描述您在做什么以及到目前为止所做的事情。
您描述的是零售ECR协议的相当通用描述。有许多变体和实现，有些可能暴露出休息。有些人可能与中央服务器合作，将REST API暴露于POS，而另一些则在EFT终端侧有一个侦听端口（通常应该对多少连接以及什么连接源等有一些防火墙限制）。几乎所有收购方或PSP都会具有某种实现（但是不一定要在HTTP上休息），因此您可能需要从本地服务提供商开始，因为它们可能会最好地反映您的需求，而在接受方法，支持卡方案等方面，。
您可以添加一个简单的例证以使交互更清晰。EMV是规格或标准fyi。
在步骤2中。您是说您有一个EMV认证的终端，该终端揭示了API，服务器可以打电话给使用卡启动交易？在这种情况下，HTTP连接在服务器和终端之间，芯片和终端连接是直接的。正确的 ？这是可以的。
步骤3。现在，终端已经与APDUS的卡通信，并且已在手头上有一个密码图（ARQC，要求您将请求发送给发行者进行验证 - Onilne），您需要与收购方进行通信。这种沟通取决于您的实施。您可以通过肥皂或休息或其他任何东西来做。
步骤4.如果存在ARPC，则应将其转发到卡，该卡将验证并确保响应来自正确的发行者。否则，它可能会向收购方发送反转（如果批准了响应）。如果ARPC已验证呼叫主机以更新付款。
在任何情况下，如果您正在寻找服务器将直接与卡通信的解决方案，则很可能无法正常工作，因为它将无法满足APDU之间的可接受时间表。
您尚未告诉您的问题。您是否要确定所提出的架构的可行性？