简体   繁体   English

ISO 8583 消息中的 ARQC PDOL 和 ICC 数据

[英]ARQC PDOL and ICC data in ISO 8583 message

I have successfully generated a ARQC by satisfying the PDOL required by the ICC.我已经通过满足ICC要求的PDOL成功生成了ARQC。 The ARQC required the following PDOL tags. ARQC 需要以下 PDOL 标签。

9F66 TTQ
9F02 Amount Authorised
5F2A Transaction Currency Code
9A Transaction Date
9F37 Unpredictable Number

The AID returned from ICC从ICC返回的AID

06 01 11 03 A00000 0F83000000000000000000006975A844

The Cryptogram Version Number as above 17 (11 Hex)密码版本号如上 17 (11 Hex)

My question, when I submit the transaction to the acquiring bank for authorisation via a ISO8583 host to host connection, in the ICC related data element do I only populate the EMV tags required by the PDOL and response Tags, or do I submit all ICC tags including for example the 'Terminal Verification Results' which was not required as per PDOL ?我的问题是,当我通过 ISO8583 主机到主机连接将交易提交给收单银行进行授权时,在 ICC 相关数据元素中,我是只填充 PDOL 和响应标签所需的 EMV 标签,还是提交所有 ICC 标签包括例如根据 PDOL 不需要的“终端验证结果”?

Based on the CVN 17 the required fields to validate Cryptogram is基于 CVN 17,验证密码的必填字段是

9F02 Amount
9F37 Unpredictable Number
9F36 ATC
9F10 CVR

Unfortunately this is a question you should ask to your acquirer.不幸的是,您应该向收单方提出这个问题。 The usual is that you populate all the data you have, especially because some of them may be used for risk management rather than cryptogram calculation.通常是您填充您拥有的所有数据,特别是因为其中一些可能用于风险管理而不是密码计算。 List of mandatory data elements is usually longer than what is required purely for cryptogram generation.强制性数据元素列表通常比纯粹生成密码所需的要长。 Second thing is that your application should not interpret proprietary data elements like Issuer Application Data unless you are required (remember there are other card application specifications and you might have trouble differentiating them on the acceptance side).第二件事是您的应用程序不应解释专有数据元素,如发行方应用程序数据,除非您需要(请记住,还有其他卡应用程序规范,您可能无法在接受端区分它们)。 Side note - AID is not IAD, 9F10 is not CVR.旁注 - AID 不是 IAD,9F10 不是 CVR。

Agree with comment from Michal.同意 Michal 的评论。

Acquirer require much more EMV tags to transfer them to Card Issuer side and identify correct card profile and finally validate Cryptogram.收单方需要更多的 EMV 标签才能将它们传输到发卡方并识别正确的卡配置文件并最终验证密码。 The list of EMV data can be different in small details and place of these EMV Values transferred in ISO 8583 message. EMV 数据列表的小细节和这些 EMV 值在 ISO 8583 消息中传输的位置可能有所不同。 Refer to your Acquirer ISO 8583 specification.请参阅您的收单机构 ISO 8583 规范。

The short summary of EMV tags and other fields required by Acquirer Interface you may see in EMV specification Book 4, Article "Authorisation Request".您可以在 EMV 规范第 4 册“授权请求”文章中看到收单方接口所需的 EMV 标签和其他字段的简短摘要。

Keep in mind that contactless cards, like your Visa PayWave may need to transfer own specific Tags depending of Card Brand Specification.请记住,非接触式卡(例如您的 Visa PayWave)可能需要根据卡品牌规范传输自己的特定标签。

In most simple terms, what your card is doing here is generating a cryptogram based on elements in CDOL (elements, its order and size, will be mentioned in payment scheme docs for each CVN) .用最简单的术语来说,您的卡在这里所做的是根据 CDOL 中的元素生成密码(元素、其顺序和大小将在每个 CVN 的支付方案文档中提及) So at the issuer end it should get the same elements to validate the cryptogram( and optionally to generate the response cryptogram ).因此,在发行方端,它应该获得相同的元素来验证密码(并可选择生成响应密码)。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM