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

Question

我正在寻求实现具有REST API功能和卡验证模式（CVM）的EMV芯片读取器/支付处理器解决方案：信用卡的芯片和签名以及借记卡的芯片和PIN。

这是我需要的流程：

1. 基于Web的POS将交易发送到服务器。

2. 系统将保存交易信息（订单号，产品号，总数等）。服务器将API请求发送到EMV，以开始信用卡/借记卡付款过程。 HTTP本地网络连接。

3. EMV通过HTTP从服务器接收API请求，并开始捕获付款过程。 连接到付款网关以处理付款。注意：EMV必须具有REST API功能。

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

5. 服务器将答案发送给主机以完成交易，具体取决于收到的答案。

以前有人实施过这种解决方案吗？如果是这样，使用了哪种解决方案（Square，Clover等）？

Answer 1

您的问题并不真正属于stackoverflow-它不是编程，您没有显示任何代码，也没有描述您的工作以及到目前为止的工作。

您所描述的是零售ECR协议的非常通用的描述。有许多变体和实现，有些可能会公开REST。一些服务器可能与将REST API公开给POS的中央服务器一起使用，另一些服务器将在EFT终端侧具有侦听端口（通常应该对多少个连接以及什么是连接源进行防火墙限制）。几乎所有的收单方或PSP都将实现某些实现（但是不一定要使用REST over HTTP），因此您可能要从本地服务提供商入手，因为它们可能会在接收方法，支持的卡方案等方面最好地反映您的需求。

Answer 2

您本可以添加一个简单的插图来使交互更加清晰。 EMV是规范或标准FYI。

在第2步中，您是说您拥有一个通过EMV认证的终端，该终端公开了一个API，服务器可以调用该API来发起使用卡的交易？在这种情况下，HTTP连接位于服务器和终端之间，而芯片和终端连接是直接的。对吗这是可行的。

第3步。既然终端已经与APDU中的卡进行了通信，并且手头有一个密码（ARQC，它要求您将请求发送给发行方进行验证-Onilne），那么您就需要与收单方进行通信。这种沟通取决于您的实现。您可以通过SOAP或REST或其他任何方式来实现它。

步骤4。如果存在ARPC，则应将其转发给卡，卡将对其进行验证并确保响应来自正确的发行者。否则，它可能会向收单方发送冲销（如果响应被批准）。如果ARPC已通过验证，请致电主机以更新付款。

无论如何，如果您正在寻找服务器直接与卡通信的解决方案，则它很可能无法工作，因为它将无法满足APDU之间的可接受时间表。

您还没有告诉您的问题。您是否要确定提议的体系结构的可行性？