处理 M/chip 快速交易答案

【问题标题】：Handling M/chip fast transactions处理 M/chip 快速交易
【发布时间】：2017-03-29 14:17:53
【问题描述】：

我正在进行 m-tip 交易，但我坚持使用 M-TIP05-USM.Test.01.Scenario.01f。根据 M-TIP 2.0 Build 225 Test Definition Reference 在离线 pin 验证之后下一步应该是“The Issuer Script command is sent after First GEN AC - [RA120]”。我收到“在第二代 AC 中，终端请求 AAC - [R3]”属性：CONTACT.APDU(CLA=80,INS=AE)[2].COMMAND:BYTE.3.BIT.7-8 预期：'00' 收到：'01'

并且交易被批准。有什么建议吗？

【问题讨论】：

标签： emv verifone mastercard

【解决方案1】：

在 我收到“在第二代 AC 中，终端请求 AAC - [R3]”

当你做 GEN AC 时，在参考控制参数中，终端会告诉芯片它期望什么样的密码。在你的情况下表示终端请求 AAC（参考控制参数为 0x00。如果您期待 ARQC，它应该是 0x80 或者如果是 TC 0x40（如果是 CDA 卡，还需要考虑第 5 位。请查看来自EMV Book 3 的下图）。 在你的情况下您需要确定是什么导致您的终端请求 AAC( 这意味着终端不想继续交易）。

也许您可以从 TVR 获得一些东西，将 TVR 与 TAC 相匹配 - 拒绝（终端操作代码）。

在并且交易被批准。有什么建议吗？

不应批准 AAC 返回的交易。你是怎么过的终端认为交易已获批准。

【讨论】：

感谢您的回答。现在我看到我犯了错误。在第一个 GEN AC 终端请求 ARQC，这很好，但在第二个 GEN 中应该是 AAC 请求，但现在有 TC - 这就是交易被批准的原因。所以问题是，我必须在第二个 GEN 中更改终端请求 AAC。
了解交易获得批准的原因。终端不会无缘无故要求拒绝。您要测试的情况是什么？您的案例应该清楚地解释申请 AAC 的原因。你从哪里得到这个输出 - CONTACT.APDU(CLA=80,INS=AE)[2].COMMAND:BYTE.3.BIT.7-8 Expected: '00' Received: '01' ？按照这个（检查我发布的图片），您应该请求 TC（不是 AAC）并且您的交易将被批准。你得到发行者脚本模板 71 吗？在这种情况下，您应该在第二代 AC 之前发送。