CN106575400A

CN106575400A - 具有消息转换的认证系统

Info

Publication number: CN106575400A
Application number: CN201580041565.7A
Authority: CN
Inventors: M·尼尔森; C·奥肯尼尔; K·纽兰; D·费舍尔
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 2014-07-30
Filing date: 2015-07-30
Publication date: 2017-04-19
Also published as: WO2016019163A1; EP3175409A1; US11282082B2; US20160034900A1; US20220164799A1; EP3175409A4; AU2015296239A1

Abstract

服务器计算装置经由交易中涉及的用户的计算装置从一方接收根据第一消息格式被格式化的认证请求消息，将此消息翻译成根据第二消息格式被格式化的修改的认证请求消息，并将修改的认证请求消息传送至授权计算机。服务器计算装置可以通过包括从接收的认证请求消息收集的数据以及基于接收的认证请求消息生成的风险分数来扩充修改的认证请求消息，所述数据描述用户、用户的计算装置和/或服务器计算装置和用户的计算装置之间的网络路径。此外，服务器计算装置从授权计算机接收根据第二消息格式被格式化的消息，并将此消息翻译成根据第一消息格式被格式化的消息，以便向用户的计算装置发送。

Description

具有消息转换的认证系统

相关申请交叉引用

本申请是2014年7月30日提交的美国临时申请号62/031,084的非临时申请并要求其优先权权益，其出于所有目的通过引用被全部并入本文中。

背景技术

在交易过程中，期望验证进行交易的用户以便避免诸如欺诈之类的问题。例如，在使用支付装置(例如，信用卡、借记卡或储值卡)的支付交易过程中，期望验证账户的持卡人的物主身份，以避免诸如未授权的使用的各种各样的问题。支付方认证是验证账户的持卡人的物主身份的过程。认证账户的持卡人的物主身份的最常用的方法按照常规在所谓的“卡出示(card present)”交易的过程中在销售点进行。卡出示交易涉及商家的代表拿着持卡人的卡，在支付卡终端刷卡以验证账户状态和信用额度可用性，然后检查以确定卡后面的签名是否与购买方的签名匹配。但是，对于“卡不出示(card not present)”的交易(诸如通过邮件或通过电话在线进行的那些交易)，执行支付方认证是更加困难的。VisaInternational Service Association(Visa国际服务联合会)已经开发了用于执行在线支付方认证的一个先前的系统，该系统被广泛实施，并称作3-D安全系统(或“Visa验证”系统)。

考虑到电子商务的持续预期的高增长，持续地改进并进一步开发用于对在线支付方进行认证的方法和系统是重要的。这会使包括持卡人、商家和金融机构在内的支付系统的所有参与方受益。认证在线购买交易的支付方会降低欺诈、争议、补偿、退款的水平，这又会接着降低与这些事件中的每一个相关的成本。对支付方进行认证还解决了消费者安全的关切问题，因此会使在线销售增长。

本发明的实施例单独和一起解决了这些和其它问题。

发明内容

本发明的实施例涉及与增强的支付方认证的技术有关的系统、方法、装置和存储指令的计算机可读介质。本发明的实施例把由消费者计算装置发送的根据一种消息格式的支付方认证消息翻译成可以更容易地被金融机构(诸如发行方)理解和处理的另一消息格式的消息。本发明的实施例可以把从金融机构接收的(特定消息格式的)消息翻译回在执行交易时通过互联网由消费者计算装置通常使用的不同的消息格式的消息。本发明的实施例还能够捕获顾客或装置信息，并在翻译的消息内向发行方呈现该信息，且一些实施例能够基于此信息执行附加的风险分析，并且能够在翻译的消息内向发行方提供风险分析的输出以在顾客认证和/或支付授权过程中使用。实施例允许发行方合并顾客认证和支付授权逻辑/系统，并且在支付授权阶段容易地使用来自顾客认证阶段的数据。

本发明的一个实施例涉及一种方法，包括：在服务器计算装置处从用户的计算装置接收针对交易的认证请求消息，所述认证请求消息根据第一消息格式被格式化并源自资源提供者计算装置，其中，所述交易涉及授权计算机。所述方法还包括由所述服务器计算装置基于所述认证请求消息生成根据第二消息格式被格式化的修改的认证请求消息；以及由所述服务器计算装置向所述授权计算机传送所述修改的认证请求消息，其中，所述授权计算机发起针对使用所述计算装置的所述用户的认证过程。在一些实施例中，所述第一消息格式包括超文本传输协议(HTTP)消息传送标准，且所述第二消息格式包括国际标准化组织(ISO)8583消息传送标准。在一些情况下，所述认证请求消息包括交易，并包括对于所述授权计算机做出针对所述交易的认证决策和授权决策足够的信息。

在一些实施例中，所述方法还包括在所述服务器计算装置处从所述授权计算机接收根据所述第二消息格式被格式化的认证响应消息，其中，所述认证响应消息包括授权结果。所述方法还可以包括由所述服务器计算装置向所述资源提供者计算装置传送所述认证响应消息。

在一些实施例中，所述认证请求消息可以是支付方认证请求消息，所述认证响应消息可以是支付方认证响应消息，所述资源提供者计算装置可以是商家计算装置，所述交易可以是金融交易，并且所述授权计算机可以是发行方计算机。

在一些实施例中，所述方法还可以包括由所述服务器计算装置基于接收的认证请求消息生成针对所述交易的风险评估值。在一些实施方式中，修改的认证请求消息包括所述风险评估值以及以下中的一个或多个：所述用户的所述计算装置的装置标识符；地理位置值，所述地理位置值标识所述用户的所述计算装置的地理位置；特征标识符，所述特征标识符标识所述用户的所述计算装置的技术能力；以及所述用户的所述计算装置的网络地址。

在一些实施例中，所述方法还可以包括在所述服务器计算装置处从所述授权计算机接收根据所述第二消息格式被格式化的认证响应消息；由所述服务器计算装置基于所述认证响应消息生成根据所述第一消息格式被格式化的修改的认证响应消息；以及由所述服务器计算装置向所述用户的所述计算装置传送所述修改的认证响应消息。

本发明的另一实施例涉及一种计算装置，包括：一组一个或多个处理器；一组一个或多个物理网络接口，所述一组一个或多个物理网络接口与所述一组处理器耦连并适于与一组一个或多个其它计算装置传送和接收消息；以及计算机可读存储介质，所述计算机可读存储介质与所述一组处理器耦连并存储指令。所述指令可以由所述一组处理器执行，这使所述计算装置执行一种方法，所述方法包括：从用户的计算装置接收针对交易的认证请求消息，所述认证请求消息根据第一消息格式被格式化并源自资源提供者计算装置，其中，所述交易涉及授权计算机；基于所述认证请求消息生成根据第二消息格式被格式化的修改的认证请求消息；以及向所述授权计算机传送所述修改的认证请求消息，其中，所述授权计算机发起针对使用所述计算装置的所述用户的认证过程。在一些实施例中，所述第一消息格式包括超文本传输协议(HTTP)消息传送标准，且所述第二消息格式包括国际标准化组织(ISO)8583消息传送标准。

本发明的另一实施例涉及一种方法，包括：由服务器计算机从服务器计算装置接收根据第二消息格式被格式化的修改的认证请求消息，其中，所述服务器计算装置基于来自用户的计算装置的根据第一消息格式被格式化的认证请求消息，生成所述修改的认证请求消息。所述方法还包括由所述服务器计算机发起针对使用所述计算装置的所述用户的认证过程。在一些实施例中，所述第一消息格式包括超文本传输协议(HTTP)消息传送标准，且所述第二消息格式包括国际标准化组织(ISO)8583消息传送标准。

在一些实施例中，所述方法还包括由所述服务器计算机生成根据所述第二消息格式被格式化的认证响应消息；以及由所述服务器计算机向所述服务器计算装置发送所述认证响应消息，其中，所述服务器计算装置生成根据所述第一消息格式被格式化的修改的认证响应消息。

在一些实施方式中，所述修改的认证请求消息包括风险评估以及以下中的一个或多个：所述用户的所述计算装置的装置标识符；地理位置值，所述地理位置值标识所述用户的所述计算装置的地理位置；特征标识符，所述特征标识符标识所述用户的所述计算装置的技术能力；以及所述用户的所述计算装置的网络地址。

附图说明

图1图解说明用于执行支付方认证的示例性支付系统的框图。

图2图解说明用于执行持卡人认证的示例性支付系统的框图。

图3图解说明根据本发明的实施例的具有增强的支付方认证的示例性支付系统的框图。

图4图解说明根据本发明的实施例的具有增强的支付方认证的示例性支付系统的框图。

图5图解说明根据本发明的实施例的用于执行金融交易的服务器计算装置中的流程。

图6图解说明根据本发明的实施例的用于翻译消息的服务器计算装置中的流程。

图7图解说明根据本发明的实施例的用于翻译消息的服务器计算装置中的流程。

图8图解说明可以用来执行本发明的实施例的计算机系统的高级框图。

具体实施方式

本发明的实施例可以提供用于执行交易和相关活动的示例性系统、装置和方法。尽管在下面提供的示例中可以参考这些交易，但实施例并不受限于此。即，本文中描述的系统、方法和设备可以用于任何适当目的。

在讨论本发明的实施例之前，描述一些术语可能对理解本发明的实施例是有帮助的。

“认证请求消息”可以是被发送至一个或多个计算装置以请求对交易的认证的电子消息。在一些实施例中，认证请求消息可以是被发送至支付处理网络和/或支付账户的发行方以请求对支付交易的认证的电子消息。在一些实施方式中，认证请求消息可以包括持卡人、商家和交易特定的信息。根据一些实施例的认证请求消息可以符合HTTP消息格式，其可以根据HTTP消息传送规范被定义，并且可以是HTTP“GET(获得)”或“POST(发布)”消息。

“修改的认证请求消息”可以是被发送至一个或多个计算装置以请求对交易认证的电子消息并且可以基于初始的或之前的认证请求消息被改动。在一些实施方式中，修改的认证请求消息可以包括持卡人、商家和交易特定的信息。在一些实施例中，修改的认证请求消息可以是被发送至支付处理网络和/或支付账户的发行方的电子消息并且可以从根据第一消息格式(例如HTTP标准)格式化的认证请求消息被翻译成根据第二消息格式(例如ISO标准)进行格式化。在一些实施方式中，修改的认证请求消息可以包括不是认证请求消息的一部分的附加信息(例如，装置数据、流量信息、风险信息、风险评估值等)。

“认证响应消息”可以是针对认证请求的电子消息应答。在一些实施例中，认证响应消息可以由发行金融机构(即发行方)或支付处理网络生成。在一些实施方式中，认证响应消息可以包括持卡人、商家和交易特定的信息。根据一些实施例的认证响应消息可以符合ISO 8583，ISO 8583是交换与消费者使用支付装置或支付账户所进行的支付关联的电子交易信息的系统的消息格式。认证响应消息可以包括认证结果(其还可以被称作认证确定)，其可以是账户发行银行(或者直接地或者通过支付处理网络)响应于电子消息中的认证请求向商家的访问装置(例如销售点终端)返回的指示对执行交易的用户的认证的值。

“修改的认证响应消息”可以是针对认证请求的电子消息应答，并且可以基于认证响应消息被改动。在一些实施方式中，修改的认证响应消息可以包括持卡人、商家和交易特定的信息。在一些实施例中，修改的认证响应消息可以是被发送至支付处理网络和/或支付账户的发行方以请求交易的电子消息，并且可以基于根据第二消息格式(例如ISO标准)被格式化的认证响应消息被翻译成根据第一消息格式(例如HTTP标准)进行格式化。在一些实施方式中，修改的认证响应消息可以包括不是认证响应消息的一部分的附加信息。

“授权请求消息”可以是被发送至支付处理网络和/或支付账户的发行方以请求对支付交易的授权的电子消息。根据一些实施例的授权请求消息可以符合ISO 8583，ISO8583是交换与消费者使用支付装置或支付账户所进行的支付关联的电子交易信息的系统的消息格式。授权请求消息还可以包括与“标识信息”对应的附加数据元素，标识信息包括例如服务代码、CVV(卡验证值)、dCVV(动态卡验证值)、到期日期等。授权请求消息还可以包括“交易数据”，诸如与当前交易关联的任何信息(例如，交易金额、商家标识符、商家位置等等)以及在确定是否标识和/或授权支付交易时可以使用的任何其它信息。

“授权响应消息”可以是由发行金融机构(即发行方)或支付处理网络生成的针对授权请求消息的电子消息应答。根据一些实施例的授权响应消息可以符合ISO 8583，ISO8583是交换与消费者使用支付装置或支付账户所进行的支付关联的电子交易信息的系统的消息格式。授权响应消息可以包括授权代码，其可以是账户发行银行(或者直接地或者通过支付处理网络)响应于电子消息中的授权请求消息向商家的访问装置(例如销售点终端)返回的指示对交易的批准的代码。代码可以用作授权的证据。如上文提到的，在一些实施例中，支付处理网络可以生成和/或向商家转发授权响应消息。

“服务器计算机”通常可以是功能强大的计算机或计算机集群。例如，服务器计算机可以是大型主机、小型计算机集群或像一个单元一样工作的一组服务器。在一个示例中，服务器计算机可以是耦连至网络服务器的数据库服务器。服务器计算机可以与实体关联，实体诸如商家、支付处理网络、钱包提供者、商家、认证云、收单方或发行方。

“计算装置”可以是能够处理并向其它电子装置传送信息的任何适当电子装置。计算装置可以包括处理器和耦连至处理器的计算机可读介质，计算机可读介质包括可由处理器执行的代码。计算装置还可以各自包括用于相互及与其它实体通信的外部通信接口。移动装置、持卡人装置、用户装置、消费者装置和服务器计算装置可以是示例类型的计算装置。

“服务器计算装置”可以是由服务器计算机操作的任何适当电子装置。在一些实施例中，服务器计算装置可以从服务器计算机接收消息，并向一个或多个其它实体发送消息。另外，服务器计算装置可以把从一个或多个其它实体接收的消息转发给服务器计算机。服务器计算装置可以是一种类型的计算装置。在一些实施例中，服务器计算装置可以由支付处理器或发行方计算机操作。

“授权计算机”可以包括对交易的授权中涉及的任何适当系统。授权计算机可以确定交易是否能够被授权，并且可以生成包括授权状态(还可以被称作授权决策)的授权响应消息。在一些实施例中，授权计算机可以是支付账户发行方计算机。在一些情况下，授权计算机可以存储一个或多个用户的联系信息。在其它实施例中，授权计算机可以授权涉及用户的非金融交易。例如，授权计算机可以做出关于用户是否可以访问某个资源的授权决策。在一些情况下，授权计算机可以是与内容提供实体关联的内容提供者服务器计算机，其管理可以由用户访问的一个或多个资源。

“资源提供实体”可以是可以使资源对用户可用的任何适当实体。资源提供实体的示例包括商家、卖主、供应商、物主、商人等等。在一些实施例中，这些实体可以是单个个体、个体组成的小团体或个体组成的较大团体(例如公司)。资源提供实体可以与一个或多个物理位置(例如，超市、商场、商店等)和在线平台(例如移动应用、电子商务网站、在线公司等)关联。在一些实施例中，资源提供实体可以使实物物品(例如商品、产品等)对用户可用。在其它实施例中，资源提供实体可以使数字资源(例如电子文档、电子文件等)对用户可用。在其它实施例中，资源提供实体可以管理用户对某些资源(例如密码、代码等)的访问。

“资源提供者计算装置”可以包括与资源提供实体关联的任何适当系统。在一些实施例中，资源提供者计算装置可以处理与资源提供实体关联的用户由此可以执行在线交易的移动应用和/或网站的功能。资源提供者计算装置还可以被称作资源提供者服务器计算机。

“风险评估值”可以包括对风险分析结果进行指示的值。风险评估值可以由下列中的一个或多个来表示：数字(例如数字分数)、字母、字母数字值、等级、阈值、范围、属性值对的集合或其它适当值。在一些实施例中，风险评估值可以由服务器计算装置生成，其可以与支付处理器或发行方计算机关联。在一些实施方式中，可以基于在发送至服务器计算装置的一个或多个消息(例如认证消息等)中包括的信息确定风险评估值。

“装置标识符”可以是包括可以用来标识计算装置的信息的任何适当指示符。计算装置可以与多个装置标识符关联。例如，示例性装置标识符可以包括制造商标识符、账户标识符、IP地址、IMEI号、SIM卡号和其它适当的标识符。在一些实施例中，一个或多个装置标识符可以被包括在HTTP消息的HTTP头部中。

“地理位置值”可以是指示计算装置的位置的任何适当值。在一些实施方式中，地理位置值可以指示一组坐标或一个区域，并且可以是适当的字符(例如，数字、字母数字等)的任何组合。在一些实施例中，地理位置值可以由计算装置的IP地址确定。例如，包括把特定IP地址与位置关联的信息的数据库可以用来确定地理位置值。还可以使用信号强度、GPS模块和其它适当的位置确定技术来确定地理位置值。

“特征标识符”可以是包括关于计算装置的一个或多个特性的信息的任何适当的指示符。特征标识符可以具有任何长度，并且可以包括可以被映射到某些特性的数字或字母数字字符。在一些实施例中，该一个或多个特性可以包括计算装置的技术能力和配置。例如，特征标识符可以指示在计算装置上cookies(小型文本文件)是否被启用，Flash多媒体播放器是否被安装和启用，以及JavaScript是否被启用。

“消息格式”可以是构成消息的任何数据格式。在一些情况下，根据消息格式被格式化的消息可以根据特定的消息传送标准被格式化。在一些实施例中，消息格式可以启用消息中的唯一的或系统特定的字段和数据元素。在一些实施例中，消息格式可以与不同的标准(例如，ISO标准、HTTP标准等)关联。

“超文本传输协议(HTTP)消息传送标准”可以是定义消息如何被格式化和如何通过万维网传输的协议。HTTP消息可以包括“GET(获得)”或“POST(发布)”消息，其中，“GET”消息可以从指定的资源请求数据，“POST”消息可以向特定的资源提交数据以用于处理。在一些实施例中，HTTP消息可以包括请求行、头部行和实体主体，请求行包括方法、URL和版本字段。基于此标准的HTTP消息可以包括这样的消息，其包含HTML、JavaScript、JSON、AJAX、XML等。在一些情况下，发送至用户的计算装置的和从用户的计算装置发送的消息可以根据与HTTP消息传送标准关联的HTTP消息格式被格式化。

“国际标准化组织(ISO)8583消息传送标准”可以定义消息如何被格式化以及如何由交换交易请求和响应的系统传输。ISO 8583消息传送标准是交换与消费者使用支付装置或支付账户所进行的支付关联的电子交易信息的系统的标准。ISO 8583消息传送标准可以定义消息格式，该消息格式包括消息类型标识符(MTI)、位图和数据元素。MTI可以是描述消息类型的4位数，包括相关的ISO 8583版本、消息类别、消息功能和消息起源。在ISO 8583标准内，位图可以指示哪些数据元素或数据元素子字段(例如在字段1到128之中)可以出现在ISO 8583消息中的别的地方。数据元素可以是携带与消息涉及的交易有关的实际交易信息的字段。标准可以定义特定数据字段的允许的内容、属性和字段长度。

在讨论本发明的实施例之前，参照图1和图2呈现关于支付方认证的一些背景。

I.示例性支付方认证系统

当用户希望通过互联网与商家进行在线购买时，用户把信用卡或借记卡账号、持卡人姓名、到期日期和/或印刷的卡验证值键入到(或以其它方式提供到)商家的结算页面上的相应字段中。在此情况下，卡的磁指纹或卡的可变数据在交易中不被使用，并且他们不可用于支付处理网络或发行银行帮助验证在交易期间卡实际上是存在的。因此，这样的在线购买存在较大的欺诈风险。例如，在销售点位置处的交易期间店员可能复制账户信息和印刷的验证值，并且随后稍后使用复制的信息进行在线购买。举另一示例，黑客可以在用户的计算机上(或网络内)安装间谍软件，以拦截账户信息和验证值，并使用此信息来在其它在线商家处进行欺诈性购买。因此，为了降低这些类型的欺诈的出现，已经开发了支付方认证系统。

图1图解说明用于执行支付方认证的示例性的传统的支付系统的框图100。为了提供更安全的在线交易过程，3-D安全系统(“Visa验证”系统)之前已经被开发并部署。此系统定义一个三域(3-D)模型，在此模型内，3-D安全系统中涉及的实体一起工作以认证并授权在线支付交易。

参照图1，3-D模型把支付系统分成如下的三个“域”：(1)发行方域110—包括发行方112和其顾客(例如，持卡人，包括用户111)的系统和功能；(2)收单方域130—包括收单方136和其顾客(例如，商家，包括商家132)的系统和功能；以及(3)互操作性域120—包括允许发行方域系统和收单方域系统在全球交互操作的系统、功能和消息(例如，购物和认证消息121、授权和支付消息123等)。在一些实施例中，购物和认证消息121可以在任何适当的通信网络上发送，并且授权和支付消息123可以由支付处理网络发送。第三方可以操作发行方域和收单方域中的许多系统。

用户111可以是与商家(诸如商家132)进行交易的持卡人。发行方112可以是维护用户的金融账户并经常向用户(诸如用户111)发行支付装置(诸如信用卡或借记卡)的商业实体(例如，银行或其它金融机构)。商家132可以是参与交易的实体，并且能够向用户出售商品和/或服务，并且可以由商家商务服务器操作。收单方136可以是与特定商家或相似实体有商业关系的商业实体(例如，商业银行或金融机构)。一些实体可以执行发行方功能和收单方功能两者。发行方112、商家132和收单方136可以各自由一个或多个服务器计算装置操作。

此“三个域”模型使得在在线购买过程中发行方(诸如发行方112)能够认证其持卡人(诸如用户111)，并给收单方(诸如收单方136)和商家(诸如商家132)提供能够包括各种技术方法的灵活架构。能够通过共同的协议和互操作性服务的使用实现发行方112和收单方136之间的互操作性。

图2图解说明用于执行持卡人认证的示例性支付系统的框图200。如图1中描述的，示例性支付系统可以包括发行方域110、互操作性域120和收单方域130。互操作性域120可以允许发行方域系统和收单方域系统在全球交互操作。

发行方域110可以包括使用计算装置的持卡人1、发行方访问控制服务器(ACS)102(也被称作访问控制服务器102)和发行方112。在一些实施例中，ACS 102可以是发行方112的一部分。发行方112可以由服务器计算装置操作，并且可以包括卡处理模块。卡处理模块可以包括实现发行方域110和互操作性域120之间的通信以用于交易处理的代码。

访问控制服务器102可以是存储和/或访问注册的持卡人账户和访问信息的服务器计算装置。ACS 102通常由发行方或其处理器操作，不过一些功能可以被“外包”给外部承包商。ACS 102验证持卡人参与到支付方认证程序中，在购买时执行持卡人验证并向商家提供数字签名的响应。

互操作性域120可以包括目录服务器122、交易路由服务124、尝试服务126、认证历史服务器128和支付处理网络129。在一些实施例中，目录服务器122、交易路由服务124、尝试服务126和认证历史服务器128可以由服务器计算装置125操作，服务器计算装置125可以由支付处理网络129操作。支付处理网络129可以包括用来支持并传送授权服务、异常文件服务和清算与结算服务的数据处理子系统、网络和操作，并且可以与发行方域110和收单方域130中的实体可操作通信。

在一些实施例中，目录服务器122包括由支付处理器操作的一个或多个服务器计算装置，其可以把认证请求从商家路由到发行方的访问控制服务器(例如，ACS 102)以便返回认证的结果。目录服务器122可以包括用于在各方之间路由消息的许多路由表。

在一些实施例中，交易路由服务124包括实现对认证请求和响应的处理的软件模块。交易路由服务124可以与服务器计算装置125或其它服务器计算装置的数据处理器结合接收认证请求和响应，并处理请求和响应以确保对商家(诸如商家132)的及时响应。

在一些实施例中，尝试服务126包括能够向商家提供尝试的认证响应的软件模块。在一些情况下，当持卡人或发行方可能没有加入认证程序或者ACS 102可能不能提供认证响应时，尝试服务126可以与服务器计算装置125或其它服务器计算装置的数据处理器结合提供尝试的认证响应。另外，当ACS 102没有对认证请求做出响应，以及证明商家曾在交易争议期间尝试对交易认证时，尝试服务126可以与服务器计算装置125或其它服务器计算装置的数据处理器结合提供替代(stand-in)处理。

在一些实施例中，认证历史服务器128包括由支付处理器操作的可以存储关于认证交易的数据的一个或多个服务器计算装置。认证历史服务器128可以用来在争议解决过程期间验证认证的交易，并提供信息。

收单方域130可以包括商家132、商家插件(或“MPI”)134、收单方电子商务支付网关135和收单方136。收单方136可以由服务器计算装置操作，并且可以包括卡处理模块。卡处理模块可以包括实现收单方域130和互操作性域120之间的通信以用于交易处理的代码。

在一些实施例中，MPI 134包括集成到商家132网站中的软件模块，其能够用来提供持卡人认证程序和商家的支付处理软件之间的界面。MPI 134可以验证用来对返回商家的认证响应签名的发行方的数字签名，或者此验证可以由单独的服务器、收单方136或第三方执行。MPI 134可以包括软件开发套件(SDK)、库文件或函数或其它软件模块。

在一些实施例中，收单方电子商务支付网关135可以提供特定的在线服务。收单方电子商务支付网关135可以与支付处理网络129可操作通信。在一些实施例中，由持卡人1操作的计算装置可以经由收单方电子商务支付网关135与支付处理网络129交互。

在持卡人1的账户已经被加入持卡人认证系统之后，可以使得持卡人1能够在任何参与商家处使用持卡人认证。具有持卡人认证的金融交易的步骤(和消息传送)现在在图2中使用编号步骤图示，并在本文中描述。

在步骤1，持卡人1完成购物。例如，持卡人1浏览参与商家的网站，向购物车添加物品，并提供用于结算的信息(例如，由键盘输入数据或通过使用电子钱包、商家一次点击服务或某种其它的填表格方法)。持卡人1随后可以确认购买(例如，通过点击或选择标记为“买”的按钮)，这触发支付表格(例如，发送HTTP POST消息)被提交到商家132。因此，商家132现在可以有用于执行金融交易的数据，包括为购买呈现的卡的主账号(PAN)。

在步骤2，商家插件134发起3-D安全处理。当持卡人1尝试完成购买或交易(例如，点击“买”按钮)时，商家服务器插件(MPI)134可以被激活。MPI 134可以向目录服务器122发送具有持卡人的提供的PAN和其它信息的请求，以确定卡是否在参与范围内—即，特定的卡是否被启用以供持卡人认证系统使用。

在步骤3，目录服务器122处理来自MPI 134的请求。在一些实施例中，目录服务器122认证商家(例如，使用数字证书)。如果商家认证成功，则目录服务器122可以向适当的访问控制服务器(ACS)102转发商家查询，以确定认证(或认证尝试的证明)是否可用于卡PAN。如果商家认证失败，则目录服务器122可以返回错误，且持卡人认证交易被终止。如果没有适当的ACS可用，或者持卡人没有参加持卡人认证系统，则目录服务器122可以向(互操作性域120内的)尝试服务路由请求，该尝试服务将代表发行方处理认证。

在步骤4，ACS 102对目录服务器122进行响应。发行方ACS 102(或如果发行方ACS102不可用，则是尝试服务126)可以基于卡的PAN确定持卡人认证是否可用，准备响应，并向目录服务器122发送响应。

在步骤5，目录服务器122向MPI 134返回ACS(或它自己的)响应。如果持卡人认证可用，则响应可以包括(互操作性域120内的)交易路由服务124的以及还有发行方ACS 102的定制URL(即统一资源定位器)，商家132将向该发行方ACS 102发送支付方认证请求。

在步骤6，MPI 134向ACS 102发送支付方认证请求。如果持卡人认证(或尝试认证的证明)不可用，则MPI 134可以建议商家商务服务器认证不可用，且处理继续步骤12(参见下文)。MPI 134可以使用在步骤5中接收的URL经由持卡人的装置(例如，在桌面计算机、移动装置或其它计算装置上运行的浏览器或应用)经由交易路由服务124向ACS 102发送支付方认证请求。支付方认证请求包含关于购买交易的信息。

在一些实施例中，MPI 134打开持卡人的计算机上的持卡人的浏览器上的通信帧或窗口或覆盖，并通过使用URL(可能连同ACS 102可以用来查明持卡人的卡的账号(PAN)的参数或数据)联系与发行方112关联的ACS 102来引导通信帧或窗口以加载资源。在一些实施例中，此URL标识(或“针对”)交易路由服务124。

例如，在一些实施例中，在步骤6，商家132(使用MPI 134和/或商家商务服务器)可以通过HTTP向持卡人1的计算装置传送消息。此消息可以包括交易路由服务124的URL，其使得持卡人1的计算装置使用该URL请求资源。因此，持卡人1的计算装置向交易路由服务124传送请求(在步骤7A，如本文下面描述的)—该请求又将最终被转发到发行方的访问控制服务器102。

在步骤7A，持卡人的计算装置可以使用该URL来使交易路由服务124与支付方认证请求联系，在步骤7B，交易路由服务124接收支付方认证请求，并将其转发至适当的发行方ACS 102。在一些实施例中，在步骤7A和7B中发送的消息可以是HTTP消息。

在步骤8A和8B，ACS 102格式化持卡人的认证请求，并从持卡人1接收响应。认证请求可以经由交易路由服务124返回至在持卡人1的计算装置上运行的浏览器/应用。在一些实施例中，这些消息中的每一个可以是HTTP响应消息。有效载荷可以使得持卡人1的计算装置显示“认证挑战”用户界面，且因此可以使用可应用于PAN的处理(例如密码、PIN输入等)对持卡人进行认证。

例如，在步骤1点击“买”之后，持卡人1可以看到包含购买细节的用户界面，并且还可以看到用户界面元素(例如，在窗口或覆盖内，响应于在步骤8A处接收的认证请求消息(例如，HTML响应消息)的接收生成的)，其提示持卡人1提供其持卡人认证密码。持卡人1可以输入其密码并提交密码(例如，通过点击或选择标记为“提交”的按钮)。这可以触发另一消息(例如，HTTP消息)在步骤8B处被传送至交易路由服务124，并被转发至ACS 102，该另一消息可以包括密码或密码的表示。ACS 102可以确定所提供的密码是否正确。

在其它实施例中，代替向交易路由服务124传送的认证请求，发行方访问控制服务器102能够与持卡人的装置直接地通信，无需通过服务器计算装置125传送。

ACS 102可以格式化具有适当值的支付方认证响应，包括认证状态，并且如果适用，还有电子商务指示符(ECI)和/或持卡人认证验证值(CAVV)。CAVV可以用来确认已经执行认证或者尝试认证的证明。ACS 102可以用发行方的顾客认证签名密钥(例如由操作互操作性域120的支付处理器提供的)对支付方认证响应签名。此密钥可以允许商家132验证支付方认证响应源自有效的参与发行方，且消息在途中没有被篡改。

在步骤9A，ACS 102向交易路由服务124返回包括认证结果的签名的支付方认证响应，在步骤9B，交易路由服务124通过向持卡人的装置发送响应来朝向MPI 134转发响应。在一些实施例中，在步骤9A和9B处发送的所有消息是根据HTTP协议被格式化并被发送的。

在步骤9C，在一些实施例中，不管认证是否成功，ACS 102可以向认证历史服务器128发送包括相关数据的支付方认证响应的副本。在步骤9D，在一些实施例中，认证历史服务器可以提供支付方认证响应交易数据被接收的确认响应。认证历史服务器可以用作争议解决的数据库。

在步骤10，持卡人1的计算装置向MPI 134转发签名的支付方认证响应(在步骤9B接收的)。在步骤11，MPI 134可以处理接收的支付认证响应。MPI 134可以验证支付方认证响应上的签名以及响应中包括的其它数据，并且随后向商家商务服务器传送认证尝试的结果。

商家商务服务器可以基于从MPI 134接收的信息确定商家132是否可以继续授权和处理和/或处理交易。在一些实施例中，如果商家商务服务器向MPI 134建议认证失败，则商家可以从持卡人1请求另一支付表格。如果商家商务服务器确定继续授权是适当的，则在步骤11和12，商家商务服务器可以经由收单方电子商务支付网关135向收单方136发送授权请求。授权请求可以包括适合认证状态的电子商务指示符(ECI)和持卡人认证验证值(CAVV)(如果适用)。

在步骤13，收单方136可以向支付处理网络29发送授权请求。在一些情况下，商家商务服务器可以向支付处理网络129直接发送授权请求。在一些实施例中，授权请求可以是根据与ISO消息传送标准关联的ISO消息格式被格式化的消息。

在步骤14，支付处理网络29可以向发行方112发送授权请求，发行方112可以接收并处理该授权请求。在一些实施例中，发行方112或者支付处理网络129可以代表发行方112执行对CAVV的验证。

在步骤15，发行方112可以选择批准或拒绝授权请求(例如，基于不充足的资金、关闭的账户等)，并返回包括授权决策(例如，批准或拒绝)的授权响应。在一些实施例中，授权响应可以是根据与ISO消息传送标准关联的ISO消息格式被格式化的消息。发行方112可以向支付处理网络129发送授权响应。

在步骤16-18，支付处理网络129可以经由收单方136和收单方电子商务支付网关135向商家商务服务器转发授权响应。在一些实施例中，商家132可以向在持卡人1的计算装置上运行的浏览器或应用显示定单确认，包括关于定单、投递和顾客服务的细节。

II.示例性的增强的支付方认证系统

参照图2的系统200，传统上，发行方已经使用ISO类型的消息(例如，ISO 8583消息)以用于执行支付交易。因此，尽管图2的持卡人认证系统可以给涉及的各方提供益处，但有时发行方一直难以更新其现有的(或“遗留”)计算系统，以利用步骤7A、7B、8A、8B、9A、9B等中涉及的HTTP消息传送。

例如，即便当发行方已经实现包括这种基于HTTP的消息传送方案的系统时，发行方还维护HTTP系统以及现有的ISO类型的消息系统，这产生附加的复杂性、处理需求和维护时间和精力。因此，一些发行方可以选择通过与第三方签合同来“外包”HTTP消息传送功能。然而，功能的这种分裂导致发行方—在交易被批准或拒绝的金融交易处理的实际支付授权阶段期间—对刚完成的持卡人认证过程没有可见性，这可能会帮助在支付授权期间可能出现的风险评估分析。因此，图3呈现了消除这些问题的增强的支付方认证方案。出于简洁目的，参照图2给出的许多具体步骤和其描述可以包括在图3中，并且这些步骤不再详细重复。

图3图解说明根据本发明的实施例的具有增强的支付方认证的示例性支付系统的框图300。在一些实施例中，支付系统能够在由支付交易中涉及的实体所使用的不同消息传送格式(和/或协议)之间“即时(on-the-fly)”翻译。在此描绘的实施例中，系统300在交易路由服务124内包括翻译模块310及可选的风险分析模块320。而且，在描绘的实施例中，消息7B用消息7X替代，消息9A用消息9X替代，并且可选地，消息8A可以用消息8X替代。

如图3中所示，在一些实施例中，发行方112可以包括发行方访问控制服务器102和授权引擎103。如上文描述的，访问控制服务器102可以是存储和/或访问已注册的持卡人账户和访问信息的服务器计算装置。在一些实施例中，访问控制服务器102的一些功能可以驻存在授权引擎103处。

在一些实施例中，发行方访问控制服务器102可以从交易路由服务124直接地接收消息(例如，消息7X)，并处理该消息。例如，发行方访问控制服务器102可以接收消息，并确定该消息的消息类型(例如，消息是认证消息还是授权消息)。发行方访问控制服务器102然后可以在如下文描述的确定消息类型之后酌情执行进一步的处理。

不过，实施例并不局限于在其系统内具有访问控制服务器的发行方。如果发行方没有访问控制服务器，则可以采用不同的方法。例如，发行方可以接收消息并检测消息类型。发行方然后可以向授权引擎发送消息及消息类型的确定以用于进一步的处理。这可以允许不一定具有访问控制服务器的发行方仍然执行本文中描述的消息的翻译。而且，由授权引擎103使用的用于授权的欺诈算法可以用在认证过程中以补充认证算法。

在其它情况下，发行方可以既具有访问控制服务器又具有授权引擎，并且发行方可以定义如何分配可以由每一个执行的特定的处理。在一些情况下，授权引擎103可以向发行方访问控制服务器路由消息。下文的示例性流程描述可以从交易路由服务器124直接接收消息的发行方ACS 102。

翻译模块310可以包括软件模块，该软件模块包括能够实现对接收的消息的修改和对修改的消息的传输的代码。例如，翻译模块310可以把根据第一消息格式(例如，HTTP标准)被格式化的接收消息转换成根据第二消息格式(例如，ISO标准)被格式化的另一消息，以及把根据第二消息格式被格式化的接收消息转换成根据第一消息格式被格式化的另一消息。此外，翻译模块310可以在转换过程中将附加信息(例如，装置信息、交易信息、路由信息等)包括到消息中。在一些实施例中，翻译模块310可以与风险分析模块320通信，以接收风险信息，该风险信息可以被包括到消息中。

风险分析模块320可以包括软件模块，该软件模块包括能够基于接收的消息中的信息执行风险评估的代码。例如，风险分析模块320可以基于装置信息、网络信息和可以包括在接收的认证请求消息中的其它用户信息执行风险分析。风险分析模块320可以生成一个或多个风险分析输出值，其可以指示风险分析的结果。风险分析输出值可以包括风险评估值，其可以是任何适当数字、字母数字字符、范围、阈值或指示与认证关联的风险的其它值的组合。在一些实施例中，风险分析输出值，诸如风险评估值可以被包括在修改的认证请求消息中。

在本发明的实施例中，出现在持卡人1计算装置和发行方112之间的消息流(经由交易路由服务124)—根据第一消息格式(这里是HTTP消息)—被修改，使得持卡人计算装置继续根据第一消息格式传送/接收消息(例如，步骤7A、8B、9B)，而发行方ACS 102则使用第二消息格式(例如，ISO-类型的消息)通信(在步骤7X、8X和9X中的一个或多个处)。在一些实施例中，在持卡人计算装置和交易路由服务124之间的所有消息(例如，步骤7A、8B、9B)是使用HTTP进行的，并且在交易路由服务124和发行方112之间的所有消息(步骤3、4、7X、8X和9X)是使用ISO消息(例如，ISO 8583消息)进行的。在这样的实施例中，不需要商家132和/或商家插件134和/或持卡人1的任何改变，并且发行方112可以对已经使用ISO类型的消息的遗留系统进行简单调整，以允许其理解新的ISO类型的消息—且因此，不需要执行全新的消息格式、协议和/或外包持卡人认证过程。

因此，在一些实施例中，一旦接收到支付方认证请求消息(在步骤7A)，代替将其转发至发行方ACS 102，翻译模块310反而将支付方认证请求消息的部分(或全部)翻译成ISO消息。该ISO消息可以是传统上用于另一目的的现有ISO消息(例如，ISO 8583消息类型“授权消息”、“管理消息”等)或新类型的单用途或多用途ISO消息。随后在步骤7X，此翻译的ISO消息被发送至发行方(例如发行方ACS 102，不过也可以是另一类型的服务器计算装置，诸如专用的授权或风险服务器)。在步骤8X，发行方可以发送以ISO消息被格式化的认证请求，翻译模块310可以接收该认证请求，翻译成HTTP消息(例如，包括HTML、JSON、AJAX、XML等)，并发送，作为步骤8B的一部分。如上文描述的，步骤8B和现在的步骤8X(代替步骤8A)可以代表从持卡人计算装置和ACS 102往返流动的许多消息，并且所有的这些消息可以由翻译模块310来回翻译，使得持卡人计算装置发送/接收HTTP消息，并且发行方ACS 102发送/接收ISO消息。

最后，在步骤9X，ACS 102将以ISO类型消息返回认证结果，翻译模块310又将该认证结果翻译回HTTP消息，并在步骤9B向持卡人计算装置发送。

在一些实施例中，交易路由服务124还包括风险分析模块320，风险分析模块320可以从持卡人1计算装置和交易路由服务124之间的通信采集信息(例如，在消息7A、8B和/或9B处)。此信息可以包括持卡人计算装置的装置标识符、装置指纹、来自由持卡人计算装置使用的cookies的值、由持卡人计算装置使用的网络地址(例如，IP地址)、持卡人的消息的流量/网络路径的标识符、以前提到的任何数据值的散列和/或交易路由服务124从其与持卡人的交互中可访问的任何其它数据值(例如，来自用来传输数据的任何协议头部的任何值，包括但不限于IP头部值、TCP/UDP头部值、HTTP头部值等)。

风险分析模块320可以处理此信息(例如，向风险分析服务发送查询)，并且可以生成其自己的(多个)风险分析输出值(例如，一个或多个风险分数)。在一些实施例中，一些或所有的被采集的信息和/或风险分析输出值可以在由步骤7X、8X和9X代表的ISO类型的消息中的一个或多个内被提供至发行方ACS102。在一些实施例中，风险分析模块320可以转换被采集的信息，包括但不限于将持卡人装置的IP地址翻译成标识持卡人装置的地理位置的地理位置值(基于地理位置数据库)。发行方ACS 102然后可以接收采集的信息和/或风险分析输出值，并且可以基于此数据作为其持卡人认证和/或随后的支付授权决策的基础。因此，发行方ACS 102可以获得对通常不可获得的持卡人和/或由持卡人使用的计算装置的附加的了解，以便更好地执行认证和/或支付授权。

图4图解说明根据本发明的实施例的具有增强的支付方认证的示例性支付系统的框图400。在一些实施例中，支付系统能够在由支付交易中涉及的实体所使用的不同的消息传送格式(和/或协议)之间“即时”翻译，以及作为认证过程的一部分完成授权过程。出于简洁目的，参照图2给出的许多特定步骤及其描述可以被包括在图4中，且这些步骤不再详细重复。

在此描绘的实施例中，系统400在交易路由服务124内包括翻译模块310和可选的风险分析模块320。而且，与参照图2讨论的实施例相比，在所描绘的实施例中，消息7A用消息47A代替，消息7B用消息47X代替，消息8A用消息48X代替，消息9A用消息49X代替，并且消息8B用消息48B代替。进一步，几个步骤可以被省略，包括步骤9B、9C、9D和步骤10到14，原因是此实施例可以合并认证和授权过程。

图4中所示的步骤1到6可以与参照图2描述的步骤1到6相似。在持卡人1的计算装置和商家132之间发起交易之后，可以执行步骤47A。

在步骤47A，持卡人1的计算装置可以向服务器计算装置125发送认证请求消息。该认证请求消息可以包括认证信息和授权信息，使得发行方112可以在接收到认证请求消息时执行认证和授权过程。在一些实施例中，除了可以用来认证持卡人1的信息之外，认证请求消息还可以包括可以在典型的授权消息中发送的所有字段(例如，消息类型指示符为0100)。例如，认证请求消息可以包括装置标识符、商家标识符、卡验证值(CVV)、交易金额等。认证请求消息可以根据第一消息格式(诸如HTTP消息格式)被格式化。

服务器计算装置125可以接收认证请求消息，并将所接收的消息转换成修改的认证请求消息。翻译模块310可以处理认证请求消息，以生成修改的认证请求消息，该修改的认证请求消息可以根据第二消息格式(诸如ISO消息格式)被格式化。翻译模块310可以在修改的认证请求消息中包括由风险分析模块320基于接收的认证请求消息生成的风险分析结果。翻译模块310还可以在修改的认证请求消息中包括在接收的认证请求消息中包括的认证和授权信息。这可以确保可以被发行方112用于认证和授权过程的任何数据可以在修改的认证请求消息中获得。

在步骤47X处，服务器计算装置125可以向发行方112发送修改的认证请求消息。发行方112随后可以基于所接收的修改的认证请求消息发起认证和授权过程。这是可行的，原因是修改的认证请求消息以能够被发行方112的授权系统处理的消息格式(例如，ISO格式)被格式化，并且因此，可以包括通常不可用的认证信息。在一些实施例中，发行方访问控制服务器102和授权引擎103可以执行特定的认证和授权过程。然而，在发行方112不具有访问控制服务器系统的一些实施例中，授权引擎103能够执行认证和授权过程，使得能够使用没有访问控制服务器系统的发行方执行图4的流程。

在一些实施例中，一旦接收到修改的认证请求消息，发行方112可以选择执行步进(step-up)认证，其中，在步骤48X，可以生成挑战并经由服务器计算装置125发送至持卡人1的计算装置。在步骤48X发送至服务器计算装置125的消息可以根据第二消息格式(例如，ISO格式)被格式化，并包括挑战请求。一旦从发行方112接收到消息，服务器计算装置125可以由翻译模块310翻译所接收的消息以根据第一消息格式(例如，HTTP格式)被格式化。

在步骤48B，服务器计算装置125可以向持卡人1的计算装置发送根据第一消息格式(例如，HTTP格式)被格式化的包括挑战请求的消息。持卡人1随后可以执行挑战(例如，回答安全问题)，并将响应输入到其计算装置中。根据第一消息格式(例如，HTTP格式)被格式化的包括挑战响应的消息可以被发送回服务器计算装置125。

服务器计算装置125随后可以由翻译模块310将接收的消息翻译成根据第二消息格式(例如，ISO格式)被格式化的包括挑战响应的消息，并且随后在步骤48X，向发行方112返回翻译的消息。

发行方112随后可以接收根据第二消息格式(例如，ISO格式)被格式化的包括挑战响应的消息，并验证挑战响应。如果挑战响应能够被验证，则发行方112可以认证持卡人1，并分析授权信息(例如在步骤47A和47X发送的)以确定授权结果。随后，发行方112可以生成根据第二消息格式(例如，ISO格式)被格式化的包括授权结果的授权响应消息。在一些实施例中，此授权响应消息可以表示请求响应消息功能(例如通过消息类型指示符0110)。在一些实施例中，授权响应消息可以被称作包括授权结果的认证响应消息。

在步骤49X，发行方112可以向服务器计算装置125发送授权响应消息。随后，授权响应消息可以经由支付处理网络129、收单方136和收单方电子商务支付网关135被发送至商家132，如步骤15到18中显示的。在向商家132发送授权响应消息之前，授权响应消息可以由服务器计算装置132进一步修改。例如，在将授权响应消息传送回商家132之前，由服务器计算装置132确定的风险分数可被添加到授权响应消息。商家132可以接收包括授权结果的授权响应消息，并确定交易是否应当被完成。

图4中描述的实施例能够实现授权过程与认证过程的结合。由于发行方可以在根据与发行方的系统兼容的ISO消息格式被格式化的单个消息中接收认证和授权信息，所以可以从分开执行认证和授权过程的典型的交易流程中省略几个步骤。与图3中所示的过程流相比，图4中的过程流具有较少的步骤，并且因此可以提高交易速度以及降低执行认证和授权处理所需的计算资源。

对图4中所示的方法的其它变形也是可行的。例如，替代通过支付处理网络129、收单方136和网关135发送授权响应消息，服务器计算装置125能够直接向商家132发送回授权响应消息，或者授权响应消息可通过由持卡人1操作的装置路由，并传送到商家132。

III.示例性方法

示例性系统的方法在下文参照图3和图4并进一步参照在本文中的其它图中呈现的系统元件描述。不过，下文描述的方法本质上是示例性的，不旨在是限制性的。根据本文中描述的一些实施例的方法可以包括(或省略)下文描述的一些或所有步骤，并且可以包括与本文中描述的不同顺序的步骤。

图5图解说明根据本发明的实施例的用于执行金融交易的服务器计算装置中的流程500。在一些实施例中，流程500由图3和图4的交易路由服务124执行，但在其它实施例中，一些或所有流程500可以由包括但不限于目录服务器122、交易模块310和风险分析模块320的实体执行。

在块405，流程包括在服务器计算装置处从用户的计算装置接收针对交易的认证请求消息。在一些实施例中，认证请求消息可以是支付方认证请求消息，并且交易可以是金融交易。支付方认证请求消息是根据第一消息格式被格式化的，并由资源提供者计算装置(例如商家计算装置)发起，并且金融交易涉及由授权计算机(例如发行方)提供的用户的账户。在一些实施例中，第一消息格式是根据HTTP消息传送标准定义的，并且支付方认证请求消息可以是HTTP“GET”或“POST”消息。在一些实施例中，由用户的计算装置用来发送支付方认证请求消息的URL是从商家服务器计算装置接收的，并且因此，支付方认证请求消息可以认为是由商家发起的并通过(或经由)用户计算装置路由的。

可选地，在一些实施例中，流程包括在块410处，由服务器计算装置基于认证请求消息生成风险评估值410。风险评估值可以基于从用户计算装置所发送的支付方认证请求消息(或其它消息)采集的信息的一个或多个项目。风险评估值可以是数字分数(例如，在0-100、1-100、1-10等之间的值)、字母数字值、属性值对的集合等。

在块415处，流程500包括由服务器计算装置基于认证请求消息生成修改的认证请求消息。修改的支付方认证请求消息是根据第二消息格式被格式化的，第二消息格式在一些实施例中是ISO消息格式，并且在一些实施例中是ISO8583消息格式。在一些情况下，在块420A处，修改的支付方认证请求消息包括生成的风险评估值。在一些实施例中，在块420B处，修改的支付方认证请求消息包括关于持卡人和/或持卡人的计算装置和/或由计算装置发送的流量的网络路径的被采集信息。

如上文描述的，被采集信息可以包括以下中的一个或多个：持卡人计算装置的装置标识符、装置指纹、来自由持卡人计算装置使用的cookies的值、由持卡人计算装置使用的网络地址(例如IP地址)、持卡人的消息的流量/网络路径的标识符、标识计算装置的技术能力或配置的特征标识符(例如cookies是否被启用，Flash多媒体播放器是否被安装/启用，JavaScript是否被启用等)、之前提到的任何数据值的散列和/或任何其它数据值(例如，来自用来传输数据的任何协议头部的任何值，包括但不限于IP头部值、TCP/UDP头部值、HTTP头部值等)。在一些实施例中，一些被采集信息可以被转换(例如转换成地理位置值)并被包括在修改的支付方认证请求消息中。

在块425处，流程500包括由服务器计算装置向授权计算机的第二服务器计算装置传送修改的认证请求消息，其中，授权计算机发起针对使用计算装置的用户的认证过程。在一些实施例中，授权计算机可以是发行用户的账户的发行方计算机。在一些情况下，修改的支付方认证请求消息是根据ISO消息格式被格式化的ISO类型的消息，并且可以由执行支付授权的相同的服务器计算装置(或服务器计算装置组)接收。

在块430处，流程500包括在服务器计算装置处从第二服务器计算装置接收根据第二消息格式被格式化的认证响应消息。在一些实施例中，支付方认证响应消息是根据ISO消息格式被格式化的。

在块435处，流程500包括由服务器计算装置基于接收的认证响应消息生成根据第一消息格式被格式化的修改的认证响应消息。在一些实施例中，修改的支付方认证响应消息包括使用HTTP格式化和传输的数据(例如，HTML、JavaScript、XML等)。

在块440处，流程500包括由服务器计算装置向用户的计算装置传送修改的认证响应消息。在一些实施例中，修改的认证响应消息可以包括认证结果，以帮助商家确定交易的处理是否可以继续。

在认证之后的稍后时间，可以发起交易的授权过程。此授权过程可以利用根据第二消息格式(例如，ISO标准)被格式化的授权消息。例如，服务器计算装置可以向发行方发送根据第二消息格式被格式化的授权请求消息，并从发行方接收根据第二消息格式被格式化的授权响应消息。因此，根据第二消息格式被格式化的消息可以用于认证过程和授权过程两者。

此特征具有几个优点。例如，这能够实现访问控制服务器或关联的发行方计算机放弃系统处理与多个消息传送标准关联的多个消息传送消息格式的需要，帮助合并顾客认证和支付授权逻辑/系统，以及在授权阶段中利用通常可能不可用的来自认证阶段的数据。这能够带来更好的交易授权，原因是可以考虑与用户、用户的计算装置和交易的网络信息有关的更多相关数据。

图6图解说明根据本发明的实施例的用于翻译消息的服务器计算装置中的流程600。在一些实施例中，翻译的消息可以是修改的消息。图6包括根据与HTTP标准关联的第一消息格式被格式化的第一消息510、包括翻译模块310和风险分析模块320的服务器计算装置125和根据与ISO标准关联的第二消息格式被格式化的第二消息540。在一些实施例中，服务器计算装置125可以具有与针对图3中的服务器计算装置125描述的那些特征相似的特征，服务器计算装置125包括交易路由服务，该交易路由服务可以包括翻译模块310和风险分析模块320。

在一些实施例中，第一消息510可以是根据HTTP消息格式(例如HTTP请求消息)被格式化的支付方认证请求消息。例如，操作计算装置的用户可能希望与商家执行在线交易，这可以执行支付方认证。用户的计算装置可以经由服务器计算装置125向ACS传送认证请求消息。服务器计算装置125、第一消息510和第二消息540的特性在下文描述。

服务器计算装置125可以包括数据处理器125A和计算机可读介质125B，计算机可读介质125B包括翻译模块310和风险分析模块320。计算机可读介质125B可以耦连至数据处理器125A，计算机可读介质125B包括可由数据处理器125A执行的用于执行本文中描述的方法的代码。翻译模块310可以包括能够实现根据HTTP消息格式被格式化的第一消息510的处理并生成根据ISO消息格式被格式化的修改的消息—第二消息540的代码。在一些实施例中，翻译模块310可以包括信息采集子模块310A、格式转换子模块310B和消息生成子模块310C。风险分析模块320可以基于由服务器计算装置125采集的信息执行风险评估。

在一些实施例中，服务器计算装置125可以与风险信息数据库520和消息格式数据库530通信，其可以包括用于帮助服务器计算装置125执行翻译模块310和风险分析模块320的功能的信息。在一些实施例中，风险信息数据库520和消息格式数据库530可以包括一个或多个软件库和配置文件和/或可以是第三方数据库。

消息格式数据库530可以包括关于和消息传送标准关联的一个或多个消息传送格式的任何信息。例如，消息格式数据库530可以包括与和第一标准关联的消息格式和与第二标准关联的消息格式有关的字段类型、属性和长度。此外，消息格式数据库530可以包括关于和第一标准关联的消息格式有关的字段以及与第二标准关联的消息格式有关的字段的相关性信息。

在一些实施例中，存储在消息格式数据库530中的信息可以是发行方特定的。例如，消息格式数据库530可以包括与多个发行方有关的多个数据记录，其中，每个发行方可以具有字段类型、属性和长度的不同配置。在一些情况下，某些发行方可以具有另一发行方可能不使用的定义的唯一字段。因此，与每个发行方关联的每个数据记录可以包括指示发行方特定的配置的信息。因此，服务器计算装置125可以检测与交易有关的发行方(例如由发行方标识符)，并查询消息格式数据库530以寻找与特定的发行方有关的信息，并利用该信息用于翻译过程。

风险信息数据库520可以包括可能有助于执行风险分析的任何信息。例如，风险信息数据库520可以包括历史交易信息、历史风险分析输出和与历史交易和风险分析结果有关的统计资料。

第一消息510可以包括请求行512、头部行514、空白行516和实体主体518，请求行512包括方法512A字段、URL 512B字段和版本512C字段。方法512A字段、URL 512B字段和版本512C字段可以分别被空格隔开，且请求行512可以由回车(CR)和换行(LF)结束。方法512A字段可以指示第一消息510包含哪种类型的请求。方法512A字段可以采用几种不同的值，包括“GET”、“POST”和“HEAD(头)”。URL 512B字段可以包括可以将第一消息510引导至支付认证请求打算要被发送至的实体的URL。例如，URL 512B字段可以包括交易路由服务的URL，该交易路由服务可以是服务器计算装置125的一部分(参见图3和图4)。在一些实施例中，URL512B字段中包括的URL可以在用户的计算装置处从与商家关联的商家服务器计算装置接收。版本512C可以表示第一消息510的HTTP版本(例如，HTTP/1.0、HTTP/1.1)。

第一消息510还可以包括头部行514，其可以提供HTTP交易的一个或多个参数。例如，头部行514可以包括围绕由第一消息510请求的资源的信息或从中发送第一消息510的服务器或计算装置的行为。在一些实施方式中，头部行514中包括的头部字段可以是冒号隔开的名称值对。例如，头部字段“Accept:text/html(接收：文本/html)”可以指示发送第一消息510的浏览器准备接收响应于其请求的HTML文本。每个名称值对的结尾可以由回车和换行字符序列终止。所有头部行514的终止可以通过由空白行516指示的附加的回车和换行字符序列指示。头部行514中包括的头部字段可以包括与交易关联的任何适当的操作参数。

第一消息510还可以包括实体主体518。在一些实施例中，在第一消息510被发送时实体主体815可以不被使用。例如，第一消息510可以是“GET”消息(由方法512A字段指示)，其可以仅从服务器请求资源，而没有在实体主体518中包括信息。在另一示例中，第一消息510可以是“POST”消息(由方法512A字段指示)，其可以使用实体主体518。在此情况下，实体主体518可以包括由用户输入到浏览器中的用户输入信息，其可以被发送至服务器。

第二消息540可以是国际标准化组织(ISO)8583消息，其可以包括消息类型指示符542。消息类型指示符542可以是四位数的数字字段，其指示ISO8583版本、消息类别、消息功能和消息起源。

消息类型指示符542的位置1可以指示ISO 8583版本，如由下面的表中的示例性值和对应含义示出的。

消息类型指示符542的位置2可以指示消息类别，如由下面的表中的示例性值和对应含义示出的。当根据HTTP消息格式被格式化的认证消息被翻译成根据ISO消息格式被格式化的修改消息时，修改的消息可以被生成作为ISO类型的消息，其传统上被用于另一目的(例如，ISO 8583消息类型“授权消息”、“管理消息”等)。在一些实施方式中，修改的消息可以被生成作为新类型的单用途或多用途ISO消息。

值	含义
		x0xx	被ISO预留
x1xx	授权消息
		x2xx	金融消息
x3xx	文件动作消息
		x4xx	撤销和退款消息
x5xx	协调消息
		x6xx	管理消息
x7xx	收费消息
		x8xx	网络管理消息
x9xx	为ISO使用预留

消息类型指示符542的位置3可以指示消息功能，如由下面的表中的示例性值和对应含义示出的。

消息类型指示符542的位置4可以指示消息起源，如由下面的表中的示例性值和对应含义示出的。消息起源可以指示关于发起交易的实体的信息。

值	含义
		xx0x	收单方
xx1x	收单方重复
		xx2x	卡发行方
xx3x	卡发行方重复
		xx4x	其它发起者
xx5x	其它发起者重复
		xx6x至xx9x	为ISO预留

第二消息540还可以包括位图544，其可以是包含关于在第二消息540中哪些数据元素字段(在数据元素546中)存在或不存在的信息的字段。在一些实施例中，位图544可以由十六进制数字代表。位图544中的每个位可以对应于数据元素，其中，0值可以指示相应的数据元素不存在，且1值可以指示相应的数据存在。例如，十六进制值“0xB210”可以对应于位值“1011001000010000”，其可以指示数据元素1、3、4、7和12的存在。尽管此示例出于简洁示出了总共16个对应的数据元素，但位图544通常可以是与64个数据元素对应的16个十六进制字符。在一些实施例中，位图544可以包括与数据元素1到64对应的第一位图和与数据元素65到128对应的第二位图。在一些实施方式中，第一位图的第一位的1值可以指示第二位图存在。在其它实施例中，附加位图可以对应附加数据元素存在。

第二消息540可以包括数据元素546，其实际上可以包含关于交易的信息。ISO消息格式可以规定每个数据元素的格式、属性和长度。例如，可以给每个数据元素分配特定的允许内容(例如，数字、字母数字、特殊字符、二进制等)和允许的长度(例如，固定的、低于设置最大值的可变长度等)。在一些情况下，可以具有可变长度的数据元素可以在长度指示符之后(例如，前两位指示长度)。数据元素546可以包括与数据字段1到128对应的ISO定义的数据元素，其可以各自与类型和使用关联。例如，可以为主账号(PAN)定义数据字段2，且数据字段2可以具有可变长度高达19位并在前两位中包括长度指示符的数字类型。

在一些实施例中，翻译的第二消息540可以包括通常可能不在ISO类型的消息格式中定义的数据元素字段。例如，唯一的字段可以被加入数据元素546内，以包括从第一消息510提取的数据。在一些实施例中，附加字段可以作为一个或多个子字段被输入到现有的ISO定义的数据元素字段中。例如，数据元素字段可以为每个子字段分配数据元素字段内的特定的位数。这可以使得第二消息540能够包括附加信息，而无需改变接收消息的另一实体可以能够处理的字段类型。在一些实施例中，数据元素字段可以包括标记标识符元素、长度元素和值元素。标记标识符元素可以是指示数据元素的特性的值(例如，装置特定的标识符、商家特定的标识符等)，长度元素可以是指示值元素的长度的值，且值元素可以包括与数据元素关联的实质值。

如上文描述的，第一消息510和第二消息540可以具有明显不同的格式。服务器计算装置125能够基于接收到第一消息510生成修改的消息—第二消息540。在一些实施例中，第一消息510可以是根据HTTP消息格式被格式化的支付方认证请求。

在步骤501处，第一消息510可以被发送至服务器计算装置125(例如，图3的步骤7A)。一旦接收到第一消息510，服务器计算装置125可以由翻译模块310的信息采集子模块310A提取第一消息510中包括的信息。

信息采集子模块310A可以包括实现从第一消息510获得数据的代码。在一些实施例中，信息采集子模块310A可以使用消息格式数据库540中包括的信息来识别第一消息510的字段的特性。例如，由于第一消息510是HTTP消息，因而信息采集子模块310A可以从消息格式数据库540检索与HTTP消息格式有关的信息。此信息可以包括第一消息510中包括的字段的类型(例如，方法、URL、版本等)、格式(例如由CRLF在头部字段之间的划分、头部字段中的名称值对、字段长度等)和其它适当信息。因此，信息采集子模块310可以与数据处理器125A结合从第一消息510提取包括头部行514中的数据的信息，这可以包括交易的一个或多个操作参数。在一些实施例中，头部行514可以包括关于从其发送第一消息510的用户的计算装置的信息以及与计算装置有关的网络信息。

在一些实施例中，信息采集子模块310A可以向风险分析模块320发送从第一消息510提取的信息。如上文描述的，该信息可以包括装置信息(例如，装置标识符、装置指纹、网络地址和来自由装置使用的cookies的值、网络地址等)和网络信息(例如，IP地址、消息的流量和网络路径的标识符、来自由装置使用的cookies的值等)。

风险分析模块320可以包括能够基于接收的消息中的信息执行风险评估的代码。风险分析模块320可以接收由信息采集子模块310A获得的信息，此信息然后可以被用于风险分析。在一些实施例中，风险分析模块320可以与数据处理器125A结合向风险分析服务发送查询，风险分析服务可以是服务器计算装置125或其它第三方实体的一部分。在一些情况下，风险分析模块320可以使用风险信息数据库520中存储的信息来执行风险评估。例如，风险信息数据库520可以包括围绕用户和执行交易的计算装置的历史信息。风险分析模块320可以与数据处理器125A结合确定与历史信息相比，接收的信息中是否存在任何异常模式。最后，风险分析模块320可以与数据处理器125A结合生成与第一消息510关联的一个或多个风险分析输出(例如风险分数、风险评估分数等)。在一些实施例中，风险分析输出可以被发送至消息生成子模块310C。在获得可被包括在修改的消息中的信息之后(例如由信息采集子模块310A提取的数据以及由风险分析模块320输出的风险分析)，格式转换子模块310B可以发起对第一消息510的转换。

格式转换子模块310B可以包括能够确定可以用来在两种模式之间翻译消息的信息的代码。格式转换子模块310B可以与数据处理器125A结合，确定与第一消息510的第一消息格式(例如HTTP标准)和第二消息540的第二消息格式(例如ISO标准)之间的字段类型的相关性有关的信息。在一些实施例中，此信息可以从消息格式数据库530检索，该消息格式数据库530可以存储第一消息格式和第二消息格式之间的相似字段类型的映射。例如，消息格式数据库530可以指示第一消息510的头部行514中存储的某些头部字段可以与第二消息540的数据元素546中的特定的数据元素字段关联。

在一些实施例中，消息格式数据库530还可以存储与根据HTTP消息格式的相关联头部字段和根据ISO消息格式的数据元素中的每一个关联的字段类型、属性和长度。因此，这可以使得格式转换子模块310B能够与数据处理器125A结合确定第一消息510如何可以被解析以便提取适当的字段值以及如何将值插入到第二消息540的适当字段中。消息生成子模块310C然后可以基于第一消息510使用由格式转换子模块310B确定的此信息来生成修改的消息—第二消息540。

消息生成子模块310C可以包括能够基于接收的消息生成修改的消息的代码。在一些实施例中，消息生成子模块310C一开始可以与数据处理器125A结合确定要被生成的修改消息的长度(例如由消息格式数据库530中存储的信息)，并且随后初始化具有所确定的长度的第二消息540。随后，消息生成子模块310C可以与数据处理器125A结合将由信息采集子模块310A提取的信息以及在一些情况下由风险分析模块320确定的风险分析输出插入到第二消息540中。在一些实施例中，可以根据由格式转换子模块310B确定的ISO消息格式，基于与如何适当地将信息插入到第二消息540中有关的指令，插入信息。例如，消息生成子模块310C可以基于从格式转换子模块310B接收的信息识别以把来自第一消息510的内容插入到数据元素546的相应的数据元素字段中，以及更新与插入的数据元素字段对应的位以具有值“1”，以便根据ISO消息格式格式化第二消息540。

在步骤502处，服务器计算装置125可以完成第二消息540的生成，并向发行方访问控制服务器传送第二消息540(例如，图3的步骤7X)。在一些实施例中，发行方访问控制服务器然后可以发起对执行交易的用户的认证。

上面描述的实施例具有几个优点。例如，一些实施例使得访问控制服务器或关联的发行方计算机放弃系统处理多个消息传送格式(例如，HTTP标准和ISO标准)的需要，这能够节约计算资源。另外，一些实施例允许发行方合并顾客认证和支付授权逻辑/系统，这在发行方被局限于使用ISO类型的消息用于授权，同时传送HTTP消息用于认证时可能通常是不可行的。进一步，一些实施例使得发行方能够在支付授权阶段容易地使用通常不可用的来自顾客认证阶段的数据(例如，从第一消息510提取的并包括在第二消息540中的装置和网络信息)，原因是实施例使得发行方的认证和授权系统能够处理具有单个消息格式的所有消息。

尽管上面的实施例描述了HTTP消息和ISO消息之间的翻译，但实施例并不受限于此。例如，图6的流程和系统可以适用于在任何其它消息传送格式之间的消息翻译。在一些实施例中，图6中的流程可以适用于把ISO消息翻译成HTTP消息(例如，与图3的步骤8X、9X、9A、9B对应)，其中，被格式化为ISO消息的第一消息从发行方被发送至包括翻译模块的服务器计算装置，该服务器计算装置然后生成被格式化为HTTP消息的第二消息，其基于接收的ISO消息被发送至用户的计算装置。参照图7描述一种示例性情况。在一些实施方式中，消息可以不针对金融交易。

图7图解说明根据本发明的实施例的用于翻译消息的服务器计算装置中的流程700。在一些实施例中，翻译的消息可以是修改的消息。图7包括根据与ISO消息格式关联的第二消息格式被格式化的第一消息640、包括翻译模块310和风险分析模块320的服务器计算装置125和根据与HTTP消息格式关联的第一消息被格式化的第二消息610。在一些实施例中，服务器计算装置125可以具有与针对图3和图4中的服务器计算装置125描述的那些特征相似的特征，服务器计算装置125包括交易路由服务，该交易路由服务可以包括翻译模块310和风险分析模块320。

第一消息640可以是ISO消息(例如，ISO响应消息)，包括消息类型指示符642、位图644和数据元素646。消息类型指示符642、位图644和数据元素646的可能的值在图5中描述。在流程700的一些实施例中，第一消息640可以从发行方或ACS接收，并且可以在数据元素646内包括由发行方或ACS提供的信息(例如认证结果)。

在步骤601处，服务器计算装置125可以接收第一消息640(例如，图3的步骤9A)。服务器计算装置125然后可以把根据ISO消息格式被格式化的第一消息640翻译成根据HTTP消息格式被格式化的修改的信息。流程700的一些部分可以与图6的流程600相似。例如，信息采集子模块310A可以与数据处理器125A结合从第一消息640提取信息。格式转换子模块310B可以与数据处理器125A结合访问消息格式数据库530以确定基于ISO消息格式的第一消息640的字段类型、属性和字段长度、基于HTTP消息格式的要被生成的第二消息610的字段类型、属性和字段长度以及ISO消息格式和HTTP消息格式的字段之间的相关性。在一些情况下，格式转换子模块310B可以向消息生成子模块提供关于如何将信息适当地插入到第二消息610中的指令。消息生成子模块310C然后可以基于由格式转换子模块310B提供的指令初始化第二消息610，并将由信息采集子模块310A提取的信息插入到第二消息610中。

第二消息610可以是HTTP消息(例如，HTTP响应消息)，包括状态行612、头部行614、空白行616和实体主体618，状态行612包括版本612A字段、状态代码612B字段和短语612C字段。版本612A字段可以指示用于第二消息610的HTTP版本，状态代码612B字段可以是指示请求的结果的数字代码，且短语612C可以在字中包括请求的结果(例如，“请求成功”)。版本612A字段、状态代码612B字段和短语612C字段可以分别由空格隔开，且状态行612可以由CRLF终止。

头部行614可以包括一个或多个字段，包括与HTTP交易有关的信息，并且在一些实施例中，可以以名称值对表示。每个头部字段可以由CRLF隔开，并且头部行614的终止可以由空白行616所示出的附加的CRLF指示。

实体主体618可以包括要与第二消息610一起发送的数据。在一些实施例中，实体主体618可以包括第一消息640的数据元素646中包括的信息。例如，发行方可以在第一消息640中的数据元素646的数据字段中包括认证结果，其可以由服务器计算装置125插入到第二消息610的实体主体618中。在一些实施方式中，实体主体618可以包括HTML、JSON、JavaScript、XML等。

在步骤602处，服务器计算装置125可以完成根据HTTP消息格式被格式化的第二消息610的生成(例如，图3的步骤9A)。在一些实施例中，第二消息610可以被发送至执行交易的用户的计算装置。

IV.示例性系统/计算机设备

图8图解说明可以用来实现本发明的实施例的计算机系统的高级框图800。图8中所示的子系统经由一个或多个系统总线802互连。附加子系统包括打印机810、键盘818、固定磁盘820和监视器812，监视器812耦连至显示适配器814。外围设备和输入/输出(I/O)装置耦连至I/O控制器804，并且可以通过本领域已知的许多手段中的任何一种(诸如串行端口816或通用串行总线(USB)端口)连接到计算机系统。例如，串行端口816或外部接口822能够用来将计算机设备连接至诸如互联网的网络(例如，广域网、局域网等)、鼠标输入装置、触摸屏或扫描器。经由系统总线802的互连允许一个或多个处理器808与每个子系统通信，并控制来自系统存储器806或固定磁盘820的指令的执行以及数据在子系统之间的交换。系统存储器806和/或固定磁盘820可以具体化为非瞬态计算机可读存储介质。非瞬态计算机可读存储介质可以存储指令，这些指令在由一个或多个处理器808执行时引起计算机系统实现本文中描述的方法和流程。

用于包含代码或代码部分的存储介质和计算机可读介质可以包括本领域已知或使用的任何适当介质，包括存储介质和通信介质，诸如但不限于在用于存储和/或传输数据(诸如计算机可读指令、数据结构、程序模块或其它数据)的任何方法或技术中实现的易失性和非易失性、可移动和不可移动介质，包括RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字通用盘(DVD)或其它光存储、磁带盒、磁带、磁盘存储或其它磁存储装置、数据信号、数据传输或可以用来存储或传送期望数据并且可以由计算机访问的任何其它介质。基于本文中提供的公开和教导，本领域技术人员会认识到实现各实施例的其它方式和/或方法。

以上描述是示意性的不是限制性的。本领域技术人员在阅读本公开后，会明白本发明的许多变形。因此，本发明的范围可以不参照上文的描述确定，而是可以参照所附权利要求连同其全部范围或等同物确定。可以理解，如上面描述的本发明可以使用以模块化或集成方式的计算机软件以控制逻辑的形式实现。基于本文中提供的公开和教导，本领域技术人员可以知道并意识到使用硬件及硬件和软件的组合实现本发明的其它方式和/或方法。本申请中描述的任何软件组件或功能可以实现为使用任何适当计算机语言(比方说例如Java、C、C++、Python或Perl)，使用例如传统的或面向对象的技术由处理器执行的软件代码。软件代码可以存储为计算机可读介质(诸如随机存取存储器(RAM)、只读存储器(ROM)、磁介质(诸如硬盘或软盘)或光介质(诸如CD-ROM))上的一系列指令或命令。任何这种计算机可读介质还可以驻存或在单个运算设备内，可以位于或在系统或网络中的不同运算设备上。

尽管上文把许多实施例描述为包括不同的特征和/或特征的组合，但本领域技术人员在阅读本公开后可以理解在一些情况下，这些组件的一个或多个可以与上文描述的任何组件或特征组合。即，来自任一实施例的一个或多个特征可以与任何其它实施例的一个或多个特征组合，而不偏离本发明的范围。

除非明确指示有相反的意思，“一(a)”、“一(an)”或“所述(the)”的叙述旨在表示“一个或多个”。提及“第一”组件并不必需要求提供第二组件。而且，除非明确指出，否则提及“第一”或“第二”组件并不将被引用组件限制到具体位置。

Claims

1.一种方法，包括：

在服务器计算装置处从用户的计算装置接收针对交易的认证请求消息，所述认证请求消息根据第一消息格式被格式化并源自资源提供者计算装置，其中，所述交易涉及授权计算机；

由所述服务器计算装置基于所述认证请求消息生成根据第二消息格式被格式化的修改的认证请求消息；以及

由所述服务器计算装置向所述授权计算机传送所述修改的认证请求消息，其中，所述授权计算机发起针对使用所述计算装置的所述用户的认证过程。

2.根据权利要求1所述的方法，还包括：

由所述服务器计算装置基于接收的认证请求消息生成针对所述交易的风险评估值。

3.根据权利要求2所述的方法，其中，所述修改的认证请求消息包括所述风险评估值。

4.根据权利要求1所述的方法，其中，所述修改的认证请求消息包括以下中的一个或多个：

所述用户的所述计算装置的装置标识符；

地理位置值，所述地理位置值标识所述用户的所述计算装置的地理位置；

特征标识符，所述特征标识符标识所述用户的所述计算装置的技术能力；以及

所述用户的所述计算装置的网络地址。

5.根据权利要求1所述的方法，其中，所述第一消息格式包括超文本传输协议(HTTP)消息传送标准。

6.根据权利要求1所述的方法，其中，所述第二消息格式包括国际标准化组织(ISO)8583消息传送标准。

7.根据权利要求1所述的方法，还包括：

在所述服务器计算装置处从所述授权计算机接收根据所述第二消息格式被格式化的认证响应消息；

由所述服务器计算装置基于所述认证响应消息生成根据所述第一消息格式被格式化的修改的认证响应消息；以及

由所述服务器计算装置向所述用户的所述计算装置传送所述修改的认证响应消息。

8.一种计算装置，包括：

一组一个或多个处理器；

一组一个或多个物理网络接口，所述一组一个或多个物理网络接口与所述一组处理器耦连并适于与一组一个或多个其它计算装置传送和接收消息；以及计算机可读存储介质，所述计算机可读存储介质与所述一组处理器耦连并存储指令，所述指令在由所述一组处理器执行时使所述计算装置执行一种方法，所述方法包括：

从用户的计算装置接收针对交易的认证请求消息，所述认证请求消息根据第一消息格式被格式化并源自资源提供者计算装置，其中，所述交易涉及授权计算机；

基于所述认证请求消息生成根据第二消息格式被格式化的修改的认证请求消息；以及

向所述授权计算机传送所述修改的认证请求消息，其中，所述授权计算机发起针对使用所述计算装置的所述用户的认证过程。

9.根据权利要求8所述的计算装置，所述方法还包括：

10.根据权利要求8所述的计算装置，其中，所述修改的认证请求消息包括所述风险评估值。

11.根据权利要求8所述的计算装置，其中，所述修改的认证请求消息包括以下中的一个或多个：

所述用户的所述计算装置的装置标识符；

所述用户的所述计算装置的网络地址。

12.根据权利要求8所述的计算装置，其中，所述第一消息格式包括超文本传输协议(HTTP)消息传送标准。

13.根据权利要求8所述的计算装置，其中，所述第二消息格式包括国际标准化组织(ISO)8583消息传送标准。

14.根据权利要求8所述的计算装置，所述方法还包括：

15.一种方法，包括：

由服务器计算机从服务器计算装置接收根据第二消息格式被格式化的修改的认证请求消息，其中，所述服务器计算装置基于来自用户的计算装置的根据第一消息格式被格式化的认证请求消息，生成所述修改的认证请求消息；以及

由所述服务器计算机发起针对使用所述计算装置的所述用户的认证过程。

16.根据权利要求15所述的方法，还包括：

由所述服务器计算机生成根据所述第二消息格式被格式化的认证响应消息；以及

由所述服务器计算机向所述服务器计算装置发送所述认证响应消息，其中，所述服务器计算装置生成根据所述第一消息格式被格式化的修改的认证响应消息。

17.根据权利要求15所述的方法，其中，所述修改的认证请求消息包括所述风险评估值。

18.根据权利要求15所述的方法，其中，所述修改的认证请求消息包括以下中的一个或多个：

所述用户的所述计算装置的装置标识符；

所述用户的所述计算装置的网络地址。

19.根据权利要求15所述的方法，其中，所述第一消息格式包括超文本传输协议(HTTP)消息传送标准。

20.根据权利要求15所述的方法，其中，所述第二消息格式包括国际标准化组织(ISO)8583消息传送标准。

21.根据权利要求1所述的方法，其中，所述认证请求消息包括交易金额，并包括对于所述授权计算机做出针对所述交易的认证决策和授权决策足够的信息。

22.根据权利要求1所述的方法，还包括：

在所述服务器计算装置处从所述授权计算机接收根据所述第二消息格式被格式化的认证响应消息，其中，所述认证响应消息包括授权结果；以及

由所述服务器计算装置向所述资源提供者计算装置传送所述认证响应消息。