终端和发行者之间的通信 - EMV Transaction答案

【问题标题】：Communication between terminal and issuer - EMV Transaction终端和发行者之间的通信 - EMV Transaction
【发布时间】：2016-07-23 21:59:30
【问题描述】：

我正在研究 EMV 技术并寻找终端和发行者之间的通信（请求/响应）以进行授权/在线密码检查。

我知道仅在终端上进行离线数据认证检查，然后终端将数据发送给发行者。我想知道授权过程需要发送哪些数据。

我对 DE 元素知之甚少（例如 DE-55 元素 - 包含 Amount、Authorised(Numeric)、Amount、Other(Numeric)、ApplicationCryptogram(AC) 等数据）。

谁能给我一个链接/文档，我可以在其中查看终端和发行人之间以什么格式进行的通信内容和方式，以进行授权（密码验证）、在线 PIN 码检查、CVV 验证等等。

抱歉我的英语不好。

【问题讨论】：

标签： terminal emv

【解决方案1】：

终端仅与收单方通信。终端和收单行之间的通信由 Compass+、OpenWay 等收单行主机系统决定，其他具体实施您可以询问您的主机提供商（更容易询问银行将哪个终端作为销售点）。通常，所有协议都基于 ISO8583，因此您可以在那里阅读。您还可以在EMV Book 4，12 Acquirer Interface 找到一些信息。

EMV 书 4：

批量交易时应使用授权消息捕获的数据。金融交易报文应在以下情况下使用在线数据采集由收单机构执行。离线建议当支持时，应在批处理数据捕获中传送。一个在线建议或逆转消息应实时传输，类似地授权或金融交易消息。

【讨论】：

我同意亚历山大的观点。在终端和收单方/商户服务提供商之间实现了数百种协议。后面是卡方案相关的网络接口，主要基于 ISO 8583。这里是卡支付系统协会使用的核心 ISO 8583 类规范的一些参考 - blog.iso8583.info/2016/02/…
@Alexandar ，您写道 - 通过“授权请求”按顺序批量发送到主机的离线消息（如果我没记错的话）。你能解释一下吗？除了离线身份验证（在终端完成）和密码验证（在收单行完成）之外，还有 CVV 验证和 Pin 验证 - 如果配置文件是在线 pin，这两个验证通常由银行 - 发卡行完成，如果我错了请纠正我的话。此处收单行向发卡行发送请求以进行这两个验证，如果是，则使用相同的 ISO 8583 标准。
@Arjun 关于离线，当终端执行离线交易时，它应该在某个时间（通过Acquirer）向Issuer（通过Acquirer）发送有关交易的信息，但不是立即。例如，终端在白天收集离线交易数据，并在一天结束时将所有这些收集的数据发送给主机。有关详细信息，请查看收单方主机实现。密码验证也在发行人处完成。您几乎是对的，一般而言，收单方向支付网络发送请求，而支付网络向发行方发送请求。然后反过来。
如果收单方和发行方不同，它们之间会有一个接口，这将是一个iso8583接口。即使在这种情况下，收单方所做的验证也非常少（不需要密钥 1、2 3）。它将从终端获取数据，[处理]，通过iso8583接口发送给发行者，接收来自发行者的响应，进行日志记录和批处理等，将响应发送回终端。当您发送给发行人时，在 iso8583 消息中，您将提供我在之前的帖子中所说的所有数据字段。这包括交易 + emv 数据字段。
发行人在 iso8583 消息中回复您，数据元素 39 将告诉您交易的命运。通过“处理”，我的意思是如下所示，您可能有多个发行人。决定将交易发送给谁。检查到期日期，卡校验位等，如果失败则拒绝（在大多数情况下，这将被终端本身拒绝）。将 PIN 块从终端 PIN 密钥转换为特定于发行者的区域 PIN 密钥

【解决方案2】：

发行人做了几件事 1. 验证卡，例如状态、到期日期、PIN 等 2. 验证帐户，例如。账户状态、可用资金、账户允许的交易类型等。 3.通过ARQC验证卡的真实性 4.生成ARPC让卡知道发卡人是正品。 5. 使用 issuer 脚本发送 post issue 操作。如果您使用 POS 或 NDC+/D912 标准（如果您使用 ATM），您可能主要以 ISO8583 格式发送数据。 PIN 作为在终端 PIN 密钥下加密的 PIN 块发送。如果主机是发行者，它可以执行 HSM 命令 DC 并验证 PIN。有关格式和预期数据，请参阅 HSM 文档。 CVV 是跟踪的一部分，并且通过 HSM 命令 CY 进行验证。到期日期可从轨道获得。服务代码也可用，但请确保它是 iCVV 的服务代码。现在考虑到上述要求，我可以说需要将以下数据发送到主机。消息类型平底锅代码数量本地日期和时间痕迹到期数据（如果您要发送跟踪数据，则不是强制性的） POS 入口代码 PAN 序列号轨道2 终端编号商户编号收单方货币代码芯片数据包括 CDOL1 中使用的所有标签（这对于您的 HSM 命令 KQ/KX 来说已经足够了） ARQ 密码 PIN 锁定，以防选择在线 PIN CVM

试试这个，如果需要更多信息，请告诉我。

【讨论】：

是一次性将所有需要的数据发送到发卡行/收单行还是发送多个 ISO8583 消息？哪些数据由收单方验证，哪些由发行方验证？我认为 pin 检查和 cvv 由发行方验证...你能告诉我，收单方和发行方是否有任何定义的任务，这将有助于了解收单方和发行方的功能。
按照术语，收单方是获取交易的人和发行卡的发行人。如果是ONUS交易交易，收单方和发行方将是同一实体。假设您在同一家银行的终端上试用该银行的卡。 OFUS 交易意味着您正在获取其他一些发卡行的银行卡。
假设您使用 POS 作为收单设备，您可以将我上面提到的所有数据在同一个 iso8583 消息中发送给收单方（ONUS 时也是发卡方）。您可以通过 iso8583 规范查看相应字段，这些字段在所有实现中或多或少都相同。数据元素 55 是其中之一，将包含 EMV 相关数据。
一般情况下，收单方除了数据格式外，不会对数据做太多验证。然后它将数据传递给发行者。正如我在之前的帖子中提到的，发卡行对您发送的数据进行所有检查，例如 PIN、CVV、卡状态、帐户状态、EMV 验证等。顺便说一句，你在做什么。