CN108352012A

CN108352012A - 支付交易的验证

Info

Publication number: CN108352012A
Application number: CN201680067201.0A
Authority: CN
Inventors: M·科林奇; P·斯梅茨
Original assignee: Mastercard International Inc
Current assignee: Mastercard International Inc
Priority date: 2015-09-18
Filing date: 2016-09-15
Publication date: 2018-07-31
Also published as: AU2016323168A1; US10504116B2; MX2018003170A; JP2018534659A; CA2999127A1; WO2017048917A1; US20170083915A1; CA2999127C; GB201516617D0; EP3350760A1

Abstract

描述了一种用于提供用支付设备进行的交易的用户认证和用户同意的方法。采取用户认证步骤来验证用户有权使用支付设备，并且采取用户同意步骤来验证用户同意交易。用户认证步骤与用户同意步骤是分开的。还描述了适于执行该方法的支付设备。

Description

支付交易的验证

相关申请的交叉引用

本申请要求2015年9月18日提交的序列号为No.1516617.6的英国申请的申请日的优先权和权益，其在此通过引用其整体结合进来。

技术领域

本公开涉及用于支付交易的验证，并且尤其涉及与支付设备的使用相关联的验证。

背景技术

在使用支付设备(例如接触式集成电路卡，非接触式集成电路卡或具有数字钱包的移动设备)的支付交易中，使用授权和同意来确保支付交易。授权确保支付设备被允许执行支付交易，并且这通常通过与支付设备的发行方核对来执行。例如，如果支付设备被用户报告为丢失或被盗，则授权可以由发行方撤销。

同意确保支付设备的用户同意支付设备用于特定支付交易中。例如，在使用集成电路卡作为支付设备的“芯片和PIN”支付交易中，当支付设备的用户通过在交互点(POI，例如支付交易终端)上提供他们的PIN来验证他们的身份时，一旦支付设备连接到POI，就暗示用户同意。

授权和同意的组合意味着欺诈用户不能执行非接触式扒窃、窃听攻击或在支付设备的用户只打算执行一次时执行两次连续的交易。图1示出非接触式扒窃装置，其中具有虚拟POI的欺诈用户10非常靠近具有非接触式支付设备14的用户12。

通常，非接触支付交易采用支付交易所赋予的值的上限，除非使用持卡人验证方法(CVM)。这为用户提供了速度和便利，因为他们不必采用验证方法。

消费者设备持卡人验证方法(CDCVM)越来越多地用于包括具有数字钱包的移动设备的支付设备。由于验证提供的安全性，CDCVM的使用通常会允许支付交易的值增加。CDCVM涉及支付设备的用户在支付设备本身上验证他们的身份。在使用CDCVM的支付交易期间，在POI或纸质收据上不需要额外的客户动作来验证消费者，例如签名或PIN。例如，移动设备可以被布置为接收PIN和/或包括用于验证用户的身份的生物测量传感器。支付设备然后可以与POI一起使用以进行支付交易。

本公开的目的是解决与现有技术相关的缺点。

发明内容

在一个方面，本公开提供了一种用于提供用于与支付设备进行的交易的用户认证和用户同意的方法，包括验证用户有权使用支付设备的用户认证步骤，和验证用户同意该交易的用户同意步骤，其中用户认证步骤与用户同意步骤是分离的。用户认证步骤可以包括消费者设备持卡人验证方法(CDCVM)。该用户认证步骤可以在交易上下文之外进行，但可以保持在交易上下文中。用户同意步骤可以是在交易过程中进行的明确的用户同意。在实施例中，用户同意可以是从用户或设备动作或用户或设备上下文推断的隐式用户同意。另一方面，还提供了适于执行上述方法的装置。

在本申请的范围内，明确地意欲为，可以独立地或以任何组合来看待在前面段落中、在权利要求书中和/或在以下描述和附图中阐述的各个方面、实施例、示例和替代方案，并且尤其是其各个特征。也就是说，所有实施例和/或任何实施例的特征可以以任何方式和/或组合进行组合，除非这些特征不相容。申请人保留更改任何原始提出的权利要求或相应地提出任何新的权利要求的权利，包括修改任何原始提交的权利要求以从属于和/或包含任何其他权利要求的任何特征—尽管最初并未以这种方式要求权利—的权利。

附图说明

上面已经通过背景技术描述了图1，其中：

图1是非接触式扒窃的示意性表示。现在将仅通过举例的方式参照剩余的附图详细描述本公开的一个或多个实施例，其中：

图2是根据本公开的实施例的支付设备的示意性框图；

图3是根据本公开的实施例的同意风险管理器模块的示意图；

图4是根据本公开的实施例的过程的流程图；

图5示出了用于非接触式磁条实施例的移动支付应用程序中的密码的生成；

图6示出了由移动支付应用程序使用的、以转换要使用CVC3和ATC作为图5的实施例的容器携带的信息的过程；

图7示出了由POS终端使用以将不可预测的数和图6中生成的信息集成到轨道数据中的过程；

图8示出了交易管理系统使用以提取使用用于图5的实施例的轨道数据携带的数据的过程；以及

图9示出了由交易管理系统使用以验证由用于图5的实施例的移动支付应用程序产生的密码的过程。

具体实施方式

用于非接触式支付交易的CDCVM方案可以涉及即时CDCVM，延长CDCVM或持久CDCVM。即时CDCVM是发生在特定支付交易的上下文中的验证。

延长CDCVM的是在与支付交易不同的上下文中执行的验证机制，并且可能会在实际支付交易之前进行。例如，如果支付设备使用密码来解锁诸如电子邮件访问的其他功能，则在支付设备上访问电子邮件的时候执行的用户验证可以被重新使用(在预定的时间限制内)，以将验证作为支付交易的部分递送而不要求用户再次提供验证。

持久CDCVM涉及在支付设备上的初始用户验证，此后支付设备可用于后续支付交易，而不需要针对每笔交易的特定用户验证。通常，用于持久CDCVM的支付设备保持验证状态，直到支付设备发生变化。例如，监控用户脉搏的智能手表可用于在第一次验证后保持CVM持久性。在智能手表从用户移除的情况下，在执行另一个成功验证之前，该验证不再有效。

同意被定义为指示持有该设备的人同意支付交易的任何动作或一系列事件。同意可以通过在支付交易的上下文中执行的动作被明确地表达，或通过在支付交易之前或期间执行的一系列事件和动作来隐式地表达。在后者的情况下，事件和动作的组合以及事件和动作的顺序表明，如果用户不同意这种交易，则这样的顺序或组合的同意很可能不会发生(而不是每个事件或动作自己)

当使用即时CDCVM进行用户验证时，自动执行(即明确给出)同意，因为用户必须与支付设备或与支付消费者设备交互以捕获认证和同意。

目前，在移动设备上使用数字钱包作为支付设备时，必须以CDCVM的形式向用户提供明确同意。明确同意依赖于一键通(one-for all)验证机制，例如按下按钮、提供秘密值或做出手势(如屏幕解锁)。明确同意的缺点是它需要在可以输入验证机制之前打开支付应用程序。

在某些情况下，支付应用程序在交易执行时打开-例如通过在终端上轻敲电话。如果用户在交易可完成之前必须按下按钮或做出手势，则意味着正在进行的交易需要中断以让用户在继续交易之前提供明确的同意-从而导致双击情景，在执行非接触式交易时，在第一次敲击和第二次敲击之间给出明确的同意。在某些情况下，

由于接受环境的技术限制(例如，在使用不支持双击的概念的销售点终端时)，商家将必须在第一次敲击击下后重启交易。当使用延长或持久CDCVM时，这可以被看作是使用明确同意进行低价值或高价值交易的移动支付解决方案的部署的阻碍因素。在远程支付过程—例如基于云的支付—中出现类似的问题。

本公开的实施例提供了一种数字钱包，其被布置为确定用户是否隐式地提供同意进行支付交易。该确定是基于与支付应用程序和不同事件的相关性可能不直接相关的上下文而做出的，绕过了对数字钱包进行任何额外的用户动作(或交互)的需要，如将是作为背景技术讨论的明确同意所需要的。

图2示出根据本公开的实施例的支付设备100。在该实施例中，支付设备100是智能手机。支付设备100包括数字钱包模块102。数字钱包模块102包括钱包处理器104，同意风险管理器模块106，通信模块108和支付应用程序模块110。同意风险管理器模块106、通信模块108和支付应用程序模块110各自可操作地连接到钱包处理器104。

同意风险管理器模块106被布置成确定是否给予用户的隐式同意以进行支付交易，如下面参考图3更详细地描述的。通信模块108被布置成在支付交易期间向POI和从POI传送数据。在该实施例中，通信模块108包括与POI进行通信的近场通信设备。支付应用程序模块110包括具有一个或多个支付应用程序的安全元件，用于在支付交易期间处理支付交易数据。

数字钱包模块102利用来自用户行为及其与支付设备100的交互或来自支付设备100自身的可用信息，例如通过创建事件的特定顺序，以便确定用户明确地执行了与实际支付之前的支付意图一致的动作。如果此动作提供足够的证据以呈现同意，则将其评定为令人满意的条件，以报告同意被提供给支付应用程序模块110中的支付应用程序，从而避免支付应用程序从用户寻求明确同意的需要。

图3更详细地显示了同意风险管理器模块106。同意风险管理器模块106包括配置模块120、计时器122和决策模块124(在图3中标记为“专家系统”)。配置模块120包括关于如何处理对同意风险管理器模块106的输入的指令。计时器122被配置为提供可信时间信息以便支持有效性检查。确定模块124被布置为处理对同意风险管理器模块106的输入并且确定是否正在提供隐式同意。

确定模块124被布置为处理可从支付设备100获得的输入信息148，包括：

·用户动作和行为信息150；

·交易环境信息152；

·支付设备信息154；

·终端数据156；

·环境信息158；

·专有检查数据160；以及

·其他信息162。

用户动作和行为信息150包括以下中的一个或多个：

·在交易开始之前提供同意；

·访问数字钱包模块102(例如，如果它在之前关闭)；

·从支付应用程序模块110选择支付应用程序(如果数字钱包模块102已经被访问)；

·如果支付设备是翻盖手机，打开翻盖手机并通过这样做启用NFC接口；

·与敲击一致来检测移动(例如，通过支付设备100上的陀螺仪)；以及

·检测日光(例如，如果之前由于支付设备100在口袋/手提包中而变暗)。

交易环境信息152是与支付交易相关联的信息，由同意风险管理器模块106针对该与支付交易相关联的信息确定隐式同意。

支付设备信息154包括以下各项中的一个或多个：

·与使用支付设备100的近场通信事件相关联的信息；

·支付设备100的相对于关于发起支付交易的商家的信息的本地化信息(例如，当在该品牌的商店/商场之一中使用商家品牌数字钱包时)。这可能需要针对已知的数据清单的检查，或针对数据库或验证服务的在线检查；

·在商店购物时的SSID(Wi-Fi接入点)(在这种情况下，隐式的同意将由商业规则驱动，其中商家会喜欢收银台处的交易速度)；

·检测支付设备100上最近使用相机扫描QR码(当QR用于触发远程支付处理时)；

·在执行远程支付时检测屏幕指向给用户的脸部(或眼睛)。这可能不一定涉及面部识别(因为生物特征验证由使用CDCVM的认证所涵盖)，但是对于远程支付，在购物和结账处理期间，预期与能够看到/读取在支付交易中使用的支付设备100的屏幕上显示的信息的用户有一定水平的用户交互；以及

·当使用支付设备100上的移动应用程序内的“应用程序内购买”来触发远程支付时，检查移动应用程序是否实际安装并在用于执行支付交易的支付设备100上运行。该检查可以扩展到合法的配套设备(例如智能手表，腕带…)，其可以被认为是被信任并且被授权进行交易。

终端数据156包括以下中的一个或多个：

·检测特定的商家类别代码(例如，用于传输网络的代码)，可选地检测特殊交易金额(例如零价值交易)，以便检测其中根据某些业务决策隐式同意将成为规则的特殊交易；

·如果交易是连续执行的，则交易详情(如金额)是相同的；以及

·检测由用户在定期和一致的基础上执行的交易类型(商家，金额……)(例如，每个工作日早上支付1欧元购买报纸或羊角面包)。在该基础中，用户的反复动作(即，用户习惯)被翻译为隐式同意。

环境信息158包括以下各项中的一项或多项：

·检测由支付设备100的计时器122(或对可信在线时钟服务的查询)报告的时间与针对该商家的商店所报告的开放时间之间的兼容的时间段；

·评估支付设备100的即时速度和高度以估计其是否符合在交易数据和本地化信息中所报告的接受环境和位置(例如以每小时70英里的速度在实体店进行交易将被评为异常，而以每小时500英里在10,000英尺处进行的交易将是飞行中交易)；以及

·将用于支付交易的商家名称与最后使用的网页或在移动设备或合法配套设备(例如智能手表，腕带……)上使用的内置应用程序匹配，以触发远程支付过程。

专有检查数据160包括从专有检查的结果确定的信息。例如，专有检查可被定义来回答与递送与给定商家品牌相关联的数字钱包(例如来自商店ABC/零售商XYZ的数字钱包)相联系的一些特定需求。

图4示出了根据本公开的实施例确定是否给出隐式同意的过程200。过程200由判定模块124执行并且包括：

步骤202-接收用户动作和行为信息150；

步骤204-接收交易环境信息152；

步骤206-接收支付设备信息154；

步骤208-接收终端数据156；

步骤210-接收环境信息158；

步骤212-接收专有检查数据160；

步骤214-接收其他信息162；

步骤216-从定时器122接收时间信息；

步骤218-使用配置模块120中的指令，基于从步骤202至216接收到的数据确定是否隐示了同意；以及

步骤220-将来自步骤218的确定输出到支付应用程序模块110，以便其执行支付交易。

当决策模块124输出授予隐式同意，则支付交易可以在没有来自用户的额外交互的情况下完成(这与满足认证的条件是分开的)。在决策模块124不能授予隐式同意的情况下，将使用支付设备100上的CDCVM获得明确同意。

CDCVM数据用于将关于用户同意和用户认证的信息携带到发行方授权系统(或交易管理系统)。CDCVM同时用于远程和非接触式支付。CDCVM数据在非接触式EMV解决方案(EMV规范可在https://www.emvco.com/specifications.aspx中找到)中以及针对数字安全远程支付(DSRP)使用两个字节(字节1或B1，字节2或B2)承载。该CDCVM数据也可以用于在EMV交易协议中生成密码。下面详细描述CDCVM数据的示例性组成，同样也是基于磁条的解决方案。对于磁条解决方案，只有一个数字可用于CDCVM数据，因此使用码本解决方案-这也在下面详细描述。

在根据本公开实施例的CDCVM数据中，不仅提供CVM的性质和同意的存在(和性质)，而且还提供CDCVM方法的优势、延长或持续同意上的控制的优势、以及同意方法的优势。这些优势可以由交易方案提供商或发卡机构评定。

根据这种方法的CDCVM数据可以被认为具有三个层：CDCVM方法，CDCVM质量和CDCVM完整性。方法可能包括PIN，密码，图案，生物识别(指纹、虹膜、脸部)或方法组合(通常“你是什么”和“你知道的东西”)。质量可能与PIN的数字位数、密码的字符数(以及字符类型的要求)、点的数量或图案的复杂度以及生物特征的错误接受率有关。

在考虑完整性时，需要考虑用于捕获CDCVM的组件C和作为使用CDCVM验证结果的应用程序的组件A两者。这里重要的是，是否使用可信用户输入来提供密码安全机制以确保过程的有效性-这需要由设备的操作系统来支持。

这里描述的实施例将评级标识为未定义的、弱的、中等的或强大，但不提供上面讨论的品质价值在评级上的特定映射-这将通常由发卡机构根据发卡机构自己的安全模型确定。这应用于CDCVM方法，且也应用于控制延长或持久CDCVM。

对于低价值交易(LVT)，可能并不总是需要CDCVM-例如，在类卡模型用于设备上的支付应用程序时。同意用于确保设备的持有人同意当前的交易。

在没有延长CDCVM和持久CDCVM的情况下，欺诈者从卡上收集的数据只有资格用于低价值交易-除非欺诈者可以说服用户使用即时CDCVM进行身份认证。但是，如果支付应用程序使用延长CDCVM或持久CDCVM，那么欺诈性地收集的数据也可用于高价值交易。在这种情况下，同意是确保设备持有人同意高价值交易的守护者。

如上所述，同意可以是明确或隐式的(例如上下文导出的)-这应与CDCVM进行通信。可以通过递送同意评级提高信息的质量。这样，如果没有递送有关用于递送隐式同意的方法的专有信息，发行方就有可能限定交易。因此，对同意给出评级也是合乎需要的。还需要确定并传达CDCVM是否在用于提供同意的相同设备上被捕获。

明确同意是提供同意的标准方法。这种方法依赖于标准的机制，例如按下按钮，提供秘密的值(本质上是一种认证)或做出一种手势(如屏幕解锁)。任何这些机制都由支付应用程序捕获和处理。它们被系统地应用，并且它们不依赖于额外的上下文信息-例如用户在最近几秒钟内打开它们的钱包并选择了卡片这一事实。

隐式同意的基本思想是让支付设备上的钱包确定该同意实际上是基于可能与支付应用程序和不同事件的关联不直接相关的上下文来提供的，绕过了需要在钱包应用程序中输入的额外用户动作的需要。如上所述并且如图3所示，这可以通过同意风险管理器来实现。通常，钱包可以利用(leverage)来自用户行为的可用信息及其与设备的交互或设备本身(创建事件的特定顺序)，以便确定用户明确地执行了与实际支付之前的支付意图一致的动作。如果此动作提供了足够的证据以呈现同意，则将其评定为令人满意的条件以报告向支付应用程序提供了同意，从而避免支付应用程序要求用户执行额外的动作的需要。

优选地，CDCVM和使用定义的一组代码和值的同意信息，所述代码和值不知道用于获取CDCVM和同意信息的技术。下面将更详细地阐述示例性方法。在使用设备上的钱包提供此类信息时，优选将这些信息保密，例如通过包含在交易过程中使用的密码中(用于基于EMV的解决方案的AC，用于基于磁条的解决方案的CVC3)。

在此类信息作为交易的一部分携带时，可以采用以下原则：

CDCVM和同意信息可以合并为CDCVM数据；

在EMV中，2字节的字段可以用来携带CDCVM数据并用于生成密码(AC)；以及

在磁条中，对轨道1和轨道2数据的处理有显著地更大的限制和问题，轨道数据的一个数字用于携带使用CDCVM码本编码的CDCVM数据的子集-来自码本的相关值用于生成密码CVC3。

现在将更详细地描述EMV和磁条解决方案。

在EMV解决方案中，可以携带以下信息：

◆CDCVM信息：

o TUI信息

■是否使用了TUI？(未知/是/否)-请注意，TUI可以基于TEE或使用如基于SE的其他方法。

■操作系统是否支持TUI？(是/否)

o使用的CDCVM方法是什么？(方法的标识符-包括无CDCVM的情况)

o CDCVM方法的评级是什么？(没有评级定义/强/中等/弱)

o CDCVM的类型是什么？(未知/即时/延长/持久)

o对延长/持续CDCVM的控制的评级是什么？(无评级定义/强/中等/弱)

◆同意信息：

o同意类型是什么？(明确/隐式)

o同意方法的评级是什么？(未定义评级/强/中等/弱)

在根据EMV规范工作时，可以使用DE55或DE48字段-例如在使用DE55时，可以将CDCVM数据添加到携带信息中的发行方应用程序数据(IAD)，以作为交易数据的一部分。

CDCVM数据是一个2字节的字段。第一个字节可以如下表1中所示的来表示，而第二个字节可以如表2所示的来提供。注意，这些表还包含关于将用于确定下文关于基于磁条的解决方案详细描述的CDCVM码本的值的输入的信息。

表1-CDCVM数据字节1

表1-CDCVM数据字节2

CDCVMB2 b5的值可根据表3中如下列出的使用情况由钱包设置。

表3–同意和CDCVM使用情况

现在将详细描述磁条解决方案。因为基于磁条的解决方案受到更多约束，不可能携带信息的2个字节。可以采用的措施是在轨道数据中分配一个数位，以及使用它来携带从十个值的码本获得的一个值。示例性的码本在下面的表4中阐述。

表4-CDCVM码本

使用DE48字段(DE48SE28)的新的子元素，CDCVM数据或CDCVM码本信息可作为交易的一部分来传送，作为不知道携带信息所需要的技术细节的一系列代码或值。信息可以使用下列一系列子字段以易于解释的格式呈现给用户：

·子字段1–同意的类型

·子字段2–同意方法的评级

·子字段3–安全级别

·子字段4–CDCVM方法类别

·子字段5–CDCVM方法

·子字段6–CDCVM的类型

·子字段7–可信用户输入(TUI)信息

·子字段8–CDCVM方法的评级

·子字段9–延长/持久CDCVM的控制的评级

·子字段10–CDCVM和同意的捕获

各个子字段的示例性格式阐述如下。

子字段1—同意的类型

这是其中由CDCVM码本提供的信息可能比在EMV解决方案中更受限的区域。存在三种可能的同意类型值：

·0–隐式

·1–明确或隐式

·2–明确

提供了转换表，如下表5：

表5-同意的类型

子字段2-同意方法的评级

CDCVM码本解决方案中可能不提供此信息。同意方法的评级有五种可能的值：

·0–未定义评级

·1–交易数据中未提供评级

·2–弱

·3–中等

·4–高

下表6是同意方法的评级的转换表。

表6-同意方法的评级

子字段3-安全级别

此子字段用于报告CDCVM和同意信息的安全级别-完整性。此子字段可能有三个值：

·0–包含在密码生成中，但密码验证失败

·1–不包括在密码生成中

·2–包含在密码生成中，且密码成功验证

下表7是安全级别的转换表

表7-安全级别

子字段4-CDCVM方法类别

此子字段与EMV和磁条方法两者都有关。此子字段可能有四个值：

表8-CDCVM方法类别

子字段5-CDCVM方法

该子字段与EMV和磁条方法两者都相关，但在磁条方法中仅可提供有限的信息。可提供以下值：

·ANY–任何CDCVM方法(生物特征或非生物特征)

·BIO–生物特征CDCVM方法

·FAC–面部

·FGP–指纹

·IRI–虹膜

·MFA–多因素认证(你是什么以及你知道什么)

·NBI–非生物特征CDCVM方法

·NCD–无CDCVM

·PAS–密码

·PAT–图案

·PIN–PIN

·RFU–还未分配标识符(保留以用于以后使用)

·WHE–窗口(你好)

下表9是用于CDCVM方法的转换表

表9-CDCVM方法

子字段6-CDCVM的类型

该子字段与EMV和磁条方法两者都相关，但磁条方法中只可提供有限的信息。有六个可能的值。

·0–无CDCVM

·1–未知

·2–持久

·3–持久或延长

·4–延长

·5–即时

下表10是用于CDCVM的类型的转换表

表10-CDCVM的类型

子字段7-TUI信息

该子字段与EMV和磁条方法两者都相关，但在磁条方法中只可提供有限的信息。有六种可能的值。

·0–无CDCVM

·1–CDCVM但未使用TUI

·2–CDCVM但未使用TUI(环境支持TUI)

·3–CDCVM但未使用TUI(环境不支持TUI)

·4–CDCVM，带有TUI的未知使用

·5–CDCVM，带有TUI

下表11是用于TUI信息的转换表

表11-TUI信息

子字段8-CDCVM方法的评级

此子字段可能在磁条方法中并未提供。有六个可能的值。

·0–无CDCVM

·1–未定义评级

·2–在交易数据中未提供评级

·3–弱

·4–中等

·5–高

下表12是用于CDCVM方法的评级的转换表

表12-CDCVM方法的评级

子字段9-对延长/持久CDCVM的控制的评级

该子字段在磁条方法中可能并未提供。存在7个可能的值。

·0–无CDCVM

·1–不可用

·2–未定义评级

·3–交易数据中未提供评级

·4–弱

·5–中等

·6–高

下表13是用于对延长/持久CDCVM的控制的评级的转换表

表13-延长/持久CDCVM上的控制的评级

子字段10-CDCVM和同意的捕获

在磁条方法中可能不会提供此子字段。有三种可能的值。

·0–在不同设备上执行的CDCVM和同意的捕获

·1–未包括在交易数据中

·2–在同一设备上执行的CDCVM和同意的捕获

下表14是用于CDCVM和同意的捕获的转换表

表14-CDCVM和同意的捕获

现在将参考图5至9描述现有磁条实现方式的适应以在CDCVM码本中递送额外信息。EMV解决方案不需要相应的讨论，因为用于向发行方递送信息的该方法实质上与现有方法相同，只需要在具有扩展能力的字段中添加额外的子字段数据。

磁条数据根据位图进行编码。PAN(主帐号)可以从传统的16位数字PAN扩展直到19位数字，以允许通过磁条模型传送额外信息。以下描述了跟踪数据的管理，以便最小化对授权系统的影响，同时使用一个通用模型来递送2位数字的应用程序交易计数器(ATC)，3位数字的密码(CVC3)，以及三位数字的不可预测的数(UN)，以及1位数字的nUN值(所有这些术语在上面引用的EMV规范中进一步描述)。

根据该实施例的位图管理的一般原理如下：

-对于任何PAN长度(16,17,18或19)，使用单个模型来管理轨道1。

-位图轨道1对于PCVC3是0000000F0000，对于PUNATC是00000010F000。

-轨道2基于PAN长度进行调整以便携带服务代码(SVC)和PSN(当使用19位PAN、默认值设置为0时值并未被携带)

-位图轨道2对于PCVC3是00F0，对于PUNATC是020E。

-nUN值始终设置为3。

以下信息被携带：

◆AA(A₂A₁)其中A₂A₁是应用程序交易计数器(ATC)的值；

◆CCCC(BC₃C₂C₁)其中B是码本的值，C₃C₂C₁是CVC3的值(即密码)；

◆UUU(U₃U₂U₁)其中U₃U₂U₁是不可预测的数(UN)的值。

此处未显示完整的位图，但是其可以由本领域技术人员使用这些原理根据需要来导出。下面参考图5至9示出使用基于云的支付系统使用单个密码(AES)来支持端到端非接触式磁条交易流程所需的五个步骤。系统中的功能元件是移动支付应用程序(支付设备上的钱包的组件)，POS终端(POS)和交易管理系统(TMS)。

图5描述了使用适当的会话密钥(这里是SK_CL_MCBP)生成密码。初始化矢量(IV)，不可预测的数(UN)和应用程序交易计数器(ATC)都作为输入提供，其中CDCVM码本值提供附加输入(B)。当用户认证完成时使用PINIV值，否则使用IV。注意根据需要为ATC计数器和为密码使用十六进制到十进制转换。

图6示出了由移动支付应用程序使用来将使用CVC3和ATC作为容器携带的信息进行转换的过程。由MPA针对为轨道1定义的CVC3容器和为轨道2定义的CVC3容器递送相同的值。

图7示出了由销售点(POS)终端使用的过程，以将UN和由MPA(CVC3，ATC)提供的值集成到轨道数据中。

图8示出了由交易管理系统使用来提取使用轨道数据携带的数据的过程。

图9示出了由交易管理系统使用来验证由移动支付应用程序生成的单个密码的过程。B(码本)信息可以用于定义要用于密码验证的IV的类型。

在不脱离本公开的范围的情况下可以对以上示例做出许多修改。

Claims

1.一种用于对利用支付设备进行的交易提供用户认证和用户同意的方法，包括：

用户认证步骤，以验证用户有权使用所述支付设备；和

用户同意步骤，以验证用户同意所述交易，其中，所述用户认证步骤与所述用户同意步骤是分离的。

2.如权利要求1所述的方法，其中，所述用户认证步骤包括消费者设备持卡人验证方法(CDCVM)。

3.如权利要求1所述的方法，其中，所述用户认证步骤在交易上下文之外进行，但是保持在交易上下文中。

4.如权利要求1所述的方法，其中，所述用户同意步骤是在交易过程内做出的明确的用户同意。

5.如权利要求1所述的方法，其中，所述用户同意是从用户或设备动作或用户或设备上下文推断的隐式用户同意。

6.如权利要求1所述的方法，其中，在交易中提供所述用户认证步骤和所述用户同意步骤的结果。

7.如权利要求6所述的方法，其中，所述用户同意步骤的结果包括同意的类型。

8.如权利要求6所述的方法，其中，所述用户同意步骤的结果包括所述用户同意步骤的评级。

9.如权利要求6所述的方法，其中，所述用户认证步骤的结果包括所使用的用户认证的类型。

10.如权利要求6所述的方法，其中，所述用户同意步骤的结果包括所述用户认证步骤的评级。

11.如权利要求6所述的方法，其中，根据EMV协议传送所述用户认证步骤和所述用户同意步骤的结果。

12.如权利要求6所述的方法，其中，所述用户认证步骤和所述用户同意步骤的结果作为磁条轨道数据被传送。

13.如权利要求12所述的方法，还包括在所述交易中传送之前，将所述用户认证步骤和所述用户同意步骤的结果编码为编码值。

14.一种包括处理器的支付设备，所述处理器被编程为执行以下步骤以为利用所述支付设备进行的交易提供用户认证和用户同意，所述步骤包括：

用户认证步骤，以验证用户有权使用所述支付设备；和

15.如权利要求14所述的支付设备，其中，所述支付设备适于在交易中提供所述用户认证步骤和所述用户同意步骤的结果。