CN106815725B - 一种交易验证方法和装置 - Google Patents

Abstract

本发明实施例提供一种交易验证方法和装置，包括获取待验证案例，所述待验证案例是根据交易模板和待验证信息生成的，然后根据所述待验证案例生成验证交易报文，根据所述验证交易报文对所述待验证案例进行验证并确定验证结果，最后在所述验证结果与预设基准匹配时，将所述待验证信息记录为支持的交易属性，所述预设基准是根据所述待验证案例确定的。本发明实施例中根据交易模板和待验证信息自动生成待验证案例，同时对待验证案例的执行、验证结果收集也进行了自动化设计，从而提高了交易验证的速度，避免了人工收集和统计验证结果带来的出错问题，降低了人力投入的成本。

Description

一种交易验证方法和装置

技术领域

本发明实施例涉及监测领域，尤其涉及一种交易验证方法和装置。

背景技术

银联的全渠道平台作为前置***接入***银行卡信息交换***，负责除线下支付之外的所有支付渠道接入，主要支撑移动、互联网、语音等渠道前端产品，机构及大商户后台接入后端产品。支持消费、预授权、退货、查询、缴费、还款、转账、代收、代付、集成电路卡(Integrated Circuit Card，简称IC 卡)类等共计37项交易类型。银行通道方面，全渠道平台目前支持2.0无卡、 2.1无卡自助消费、2.1代收、2.1代付、2.1订购、自联银行代扣、“商对客” (Business-to-Customer，简称B2C)网银消费、多渠道代扣，多种银行扣款通道，且各通道支持银行不一，同一种通道各银行扣款交易要素也不尽相同。

面对复杂的交易组合和多样的银行通道，银联的对外服务部门需要精确了解全渠道平台在生产环境下的业务支持情况，以便在对外服务时做到有的放矢、提高服务质量。目前主要依赖一个简单的报文生成工具和自动测试工具 (quicktest Professional，简称QTP)来开展验证工作，存在如下问题：工具不够自动化，不但需要人工填写交易要素，同时验证结果需要人工进行汇总整理，从而使得记录的验证结果容易出错且人力成本投入较大。

发明内容

本发明实施例提供一种交易验证方法和装置，用以解决现有技术中监测支持交易属性的过程中人工操作容易出错且人力成本投入较大的问题。

本发明实施例提供了一种交易验证方法，包括：

获取待验证案例，所述待验证案例是根据交易模板和待验证信息生成；

根据所述待验证案例生成验证交易报文；

根据所述验证交易报文对所述待验证案例进行验证并确定验证结果；

在所述验证结果与预设基准匹配时，将所述待验证信息记录为支持的交易属性，所述预设基准是根据所述待验证案例确定的。

可选地，所述待验证案例是根据交易模板和待验证信息生成，包括：

所述待验证信息包括交易报文类型、验证的多方交易对象；

根据所述交易报文类型，确定所述交易报文类型对应的关联要素；

根据所述验证的多方交易对象，确定验证要素集；

根据所述交易模板、所述关联要素和所述验证要素集确定所述待验证案例。

可选地，所述根据所述待验证案例生成验证交易报文，包括：

所述验证的多方交易对象包括待验证银行卡的***；

根据所述待验证银行卡的***、所述交易报文类型对应的关联要素的取值方式确定所述交易报文类型对应的关联要素的具体取值和所述验证要素集的具体取值，其中，所述交易报文类型对应的关联要素的取值方式是根据预设规则确定的；

将所述交易报文类型对应的关联要素的具体取值和所述验证要素集的具体取值进行组装生成所述验证交易报文。

可选地，所述根据所述验证交易报文对所述待验证案例进行验证并确定验证结果，包括：

将所述验证交易报文发送至所述待验证银行卡的发卡行，以使所述待验证银行卡的发卡行对所述验证交易报文进行处理并反馈验证结果；

接收所述待验证银行卡的发卡行反馈的验证结果。

可选地，所述根据所述验证交易报文对所述待验证案例进行验证并确定验证结果之后，还包括：

在确定所述验证结果与预设基准不匹配时，将所述待验证信息记录为不支持的交易属性。

相应的，本发明实施例还提供了一种交易验证装置，包括：

获取模块，用于获取待验证案例，所述待验证案例是根据交易模板和待验证信息生成；

处理模块，用于根据所述待验证案例生成验证交易报文；

验证模块，用于根据所述验证交易报文对所述待验证案例进行验证并确定验证结果；

统计模块，用于在所述验证结果与预设基准匹配时，将所述待验证信息记录为支持的交易属性，所述预设基准是根据所述待验证案例确定的。

可选地，所述获取模块具体用于：

根据交易模板和待验证信息生成待验证案例；

所述待验证信息包括交易报文类型、验证的多方交易对象；

根据所述交易报文类型，确定所述交易报文类型对应的关联要素；

根据所述验证的多方交易对象，确定验证要素集；

根据所述交易模板、所述关联要素和所述验证要素集确定所述待验证案例。

可选地，所述处理模块具体用于：

所述验证的多方交易对象包括待验证银行卡的***；

根据所述待验证银行卡的***、所述交易报文类型对应的关联要素的取值方式确定所述交易报文类型对应的关联要素的具体取值和所述验证要素集的具体取值，其中，所述交易报文类型对应的关联要素的取值方式是根据预设规则确定的；

将所述交易报文类型对应的关联要素的具体取值和所述验证要素集的具体取值进行组装生成所述验证交易报文。

可选地，所述验证模块具体用于：

将所述验证交易报文发送至所述待验证银行卡的发卡行，以使所述待验证银行卡的发卡行对所述验证交易报文进行处理并反馈验证结果；

接收所述待验证银行卡的发卡行反馈的验证结果。

可选地，所述统计模块还用于：

所述根据所述验证交易报文对所述待验证案例进行验证并确定验证结果之后，在确定所述验证结果与预设基准不匹配时，将所述待验证信息记录为不支持的交易属性。

本发明实施例，获取待验证案例，所述待验证案例是根据交易模板和待验证信息生成，然后根据所述待验证案例生成验证交易报文，根据所述验证交易报文对所述待验证案例进行验证并确定验证结果，最后在所述验证结果与预设基准匹配时，将所述待验证信息记录为支持的交易属性，所述预设基准是根据所述待验证案例确定的。本发明实施例中根据交易模板和待验证信息自动生成待验证案例，同时对待验证案例的执行、验证结果收集也进行了自动化设计，从而提高了交易验证的速度，避免了人工收集和统计验证结果带来的出错问题，降低了人力投入的成本。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种交易验证方法的流程示意图；

图2为本发明实施例提供的一种验证案例生成的流程示意图；

图3为本发明实施例提供的一种***案例组装的流程示意图；

图4为本发明实施例提供的另一种交易验证方法的流程示意图；

图5为本发明实施例提供的一种交易验证装置的结构示意图。

具体实施方式

为了使本发明的目的、技术方案及有益效果更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

图1例性示出了本发明实施例提供的一种交易验证方法的流程，该流程可以由交易验证装置执行。

步骤S101，获取待验证案例。

步骤S102，根据所述待验证案例生成验证交易报文。

步骤S103，根据所述验证交易报文对所述待验证案例进行验证并确定验证结果。

步骤S104，在所述验证结果与预设基准匹配时，将所述待验证信息记录为支持的交易属性。

上述实施例中的待验证案例可以是从提前建立的验证案例集中获取，也可以在确定需要验证的特定交易时，实时建立的。在对验证案例进行验证时，可以取整个验证案例集执行，将验证案例集中每个验证案例作为待验证案例。也可以取单个验证案例作为待验证案例执行。本发明实施例中根据交易模板和待验证信息自动生成待验证案例，同时对待验证案例的执行、验证结果收集也进行了自动化设计，从而提高了交易验证的速度，避免了人工收集和统计验证结果带来的出错问题，降低了人力投入的成本。

具体地，待验证案例是根据交易模板和待验证信息生成的，其中待验证信息包括交易报文类型和验证的多方交易对象，具体实施中，可以在***中预设多种待验证信息，定期进行循环验证；也可以是基于用户需求，根据用户输入的信息得到待验证信息。本发明实施例提供了一种待验证案例的生成过程，如图2所示，包括以下步骤：

步骤S201，根据交易报文类型，确定所述交易报文类型对应的关联要素；

步骤S202，根据所述验证的多方交易对象，确定验证要素集；

步骤S203，根据所述交易模板、所述关联要素和所述验证要素集确定所述待验证案例。

具体实施中，交易模板包括***案例组装模板和验证案例组装模板，确定待验证案例的具体过程为：首先根据交易报文类型确定交易报文类型对应的关联要素，根据关联要素和***案例组装模板组装***案例，然后根据***案例、验证要素集以及验证案例组装模板组装待验证案例。

针对关联要素和***案例组装模板组装***案例，如图3所示，一种可实现方式包括以下步骤：

步骤S301，确定交易报文类型；

步骤S302，根据交易报文类型确定关联要素及关联要素的取值方式；

步骤S303，将关联要素按照***案例组装模板组装。

其中步骤S301中交易报文类型是根据交易类型、交易子类、产品类型、上送URL确定的。本发明实施例提供了一种交易报文类型确定的示例，如表1 所示。

表1 交易报文类型确定示例

表1中确定了一种消费交易报文，该消费交易报文对应的报文ID为0001，报文类型说明为网关支付产品消费，交易类型为01：消费，交易子类为01：消费，产品类型为000201：B2C网关支付，上送URL为后台URL。

在步骤S302中，确定交易报文类型后，根据***中预置的配置表，得到该交易报文类型对应的关联要素，并确定关联要素的取值方式，其中交易报文类型对应的关联要素即为与交易报文类型匹配的交易报文要素。一种交易报文类型包括很多关联要素，比如版本号、编码格式、证书ID、签名方法、签名、商户号、渠道类型、接入类型、证件类型等。关联要素的值产生规则不同，有些是固定取值，有些是按照固定逻辑规则产生的，有些是根据自定义规则产生的。具体实施中，可以设计两个配置表，两个配置表分别是交易报文要素表和交易报文要素关联表。根据这两个配置表可以得到该交易报文类型的关联要素及关联要素的取值方式。例如确定报文ID为0001的消费交易报文后，根据***中预置的配置表确定该消费交易报文对应的交易报文要素关联表，交易报文要素关联表中包括报文ID为0001的消费交易报文对应的所有关联要素的要素 ID，具体如表2所示。

表2 交易报文要素关联表示例

报文ID	要素ID	默认值
			0001	1	{value:5.0.0}
0001	2
			0001	3
0001	4
			0001	5
0001	6
			0001	7
0001	8
			0001	9
0001	10
			0001	11
0001	12
			0001	13
0001	14

如表2所示，报文ID为0001的消费交易报文对应有14个关联要素，要素ID分别为1至14,其中要素ID为1的关联要素取默认值，要素ID为2至 14的关联要素的具体取值方式需要查询交易报文要素表来获取。交易报文要素表中定义了各种交易报文类型对应的交易报文要素，定义的每个交易报文要素包括要素ID、父ID、要素域名、要素变量名、要素数据格式、要素取值说明、取值类型以及要素具体值。表3示例性示出了一种交易报文要素表。

表3 交易报文要素表示例

如表3所示，交易报文要素表中包括了14种交易报文要素以及各交易报文要素对应的具体取值方式。需要说明的是，交易报文要素表中的交易报文要素并不限于上述14种。根据表2中消费交易报文对应的关联要素的要素ID从表3中查询出相同的要素ID，然后根据相同要素ID对应的交易报文要素的具体取值方式确定消费交易报文对应的关联要素的具体取值方式。例如通过查询表3将要素ID为2的交易报文要素的具体取值方式确定为表2中要素ID为2 的关联要素的具体取值方式，最终确定报文ID为0001的消费交易报文中要素ID为2的关联要素父报文ID为2，要素域名为编码格式，要素变量名为encoding，要素数据格式为ANS1..20，要素取值说明为填写报文使用的字符编码， UTF-8|GBK|GB2312|GB18030，若不填写，默认取值：UTF-8，取值类型为1：固定值，要素具体值为{value:UTF-8}。同样的，根据相同的查询方式可以得到报文ID为0001的消费交易报文其它对应的关联要素的具体取值方式，其中交易报文要素的要素ID为12、13和14的交易报文要素对应同一个父报文ID。最后，***案例组装模板结合各关联要素的父报文ID和各关联要素得到***案例。

以下介绍验证要素集的一种实现方式，具体地，待验证信息中的多方交易对象包括银行卡性质、发卡银行以及上传至发卡行银行的验证要素。根据银行卡性质、发卡银行以及上传至发卡行银行的验证要素确定交易验证过程中的验证要素集。其中上传至发卡银行的验证元素根据银行卡性质不同对应的验证元素不同。比如对于借记卡和贷记卡对应的验证元素分别如表4和表5所示。

表4 借记卡验证元素示例

其中，●：代表上送正确值，

代表上送错误值，○：代表不上送。

表5 贷记卡验证元素示例

其中，CVN2为卡确认码/安全码，全称为Card Verification Number，●：代表上送正确值，

代表上送错误值，○：代表不上送。

表4中借记卡对应的上传至发卡银行的验证要素包括***、密码、手机号、姓名和证件号。在上传验证元素时可以采取不同的方式，比如***、密码、手机号、姓名和证件号均上传正确值，或者***、密码、手机号、姓名上传正确值，证件号码上传错误值等。表5中贷记卡对应的上传至发卡银行的验证要素包括***、有效期、CVN2、手机号、姓名和证件号，在上传验证元素时也可以采取不同的方式。由于针对每种交易类型确定交易报文类型，并结合发卡银行的相关信息确定验证案例，充分考虑了在线支付的业务复杂性，具有很强的针对性，能实现复杂业务场景的验证。

通过上述实施例得到待验证案例后，根据待验证案例中的信息生成验证交易报文。本发明实施例提供了一种具体实现方式为：验证的多方交易对象包括待验证银行卡的***，故根据待验证银行卡的***、交易报文类型对应的关联要素的取值方式确定交易报文类型对应的关联要素的具体取值和验证要素集的具体取值，其中，交易报文类型对应的关联要素的取值方式是根据预设规则确定的。然后将交易报文类型对应的关联要素的具体取值和验证要素集的具体取值进行组装生成验证交易报文。具体实施中，验证的多方交易对象中待验证银行卡的***可以人工输入或者提前存储于数据库中，使用时直接调用。为了更清楚地介绍验证交易报文的生成过程，本发明实施例提供以下示例。设定选取的待验证案例为验证交通银行卡是否支持借记卡的消费交易类型，通过用户输入的方式确定了交通银行卡的***，根据交通银行卡的***查询对应该交通银行卡的账户信息，账户信息包括用户姓名、手机号、证件号等，根据查询得到的账户信息结合借记卡的验证元素的组合形式得到用户需要上传至交通银行的验证要素的具体取值。进一步地，根据交易报文要素表确定消费交易类型对应的关联要素的具体取值方式，并结合用户输入的交通银行卡的***得到消费交易类型对应的关联要素的具体取值。将消费交易类型对应的关联要素的具体取值、验证要素集的具体取值按照报文要素层级组装成json(全称JavaScript ObjectNotation)字符串，组装成的json字符串即为生成的验证交易报文。需要说明的是本发明实施例在确定交易报文类型对应的关联要素的具体取值和验证要素集的具体取值时，并不仅限于通过输入待验证银行卡的***，还可以通过输入商户号、用户姓名、手机号码、证件号码及其结合等。

本发明实施例在生成验证交易报文之后，根据验证交易报文对待验证案例进行验证并确定验证结果，在验证结果与预设基准匹配时，将待验证信息记录为支持的交易属性，预设基准是根据待验证案例确定的。具体为将验证交易报文发送至待验证银行卡的发卡行，以使待验证银行卡的发卡行对验证交易报文进行处理并反馈验证结果。然后接收待验证银行卡的发卡行反馈的验证结果后将验证结果与预设基准对比，若确定验证结果与预设基准匹配时，将待验证信息记录为支持的交易属性。在确定验证结果与预设基准不匹配时，将待验证信息记录为不支持的交易属性。具体实施中，设定选取的待验证案例为验证交通银行卡是否支持借记卡的消费交易类型。业务运营监测平台确定了验证交易报文后，将验证交易报文发送至交通银行。交通银行在接收后对验证交易报文进行处理，根据验证交易报文中的消费交易报文对应的关联要素确定是否支持消费交易类型，根据验证信息中的验证要素集确定消费交易时用户需要上传至交通银行的验证要素。交通银行对验证交易报文处理完后反馈验证结果。业务运营监测平台在接收到反馈的验证结果后与预设基准进行对比，预设基准的设置方法可以为设置待验证案例的执行结果基准，也可以设置返回应答码基准，还可以设置应答报文某个域的基准。如果反馈的验证结果后与预设基准匹配，则说明交通银行支持借记卡的消费交易类型，同时确定了消费交易时用户需要上传至交通银行的验证要素。将消费交易类型、交通银行、借记卡以及验证要素确定为支持的交易属性。如果反馈的验证结果后与预设基准不匹配，则说明交通银行不支持借记卡的消费交易类型。将消费交易类型、交通银行、借记卡以及验证要素确定为不支持的交易属性。进一步地，将支持的交易属性记录到交易日志表中。在执行验证案例的过程中，业务运营监测平台发送验证交易报文一段时间后若没有得到反馈的验证结果，可以组装验证结果查询报文查询验证结果并根据查询结果更新交易日志表。如果超过10次查询没有得到验证结果，则认为该交易验证失败。通过验证多个验证案例可以得到待验证银行支持的各种交易类型以及验证要素上传要求。通过将同一个验证案例多次执行情况作对比分析，将验证结果发生变化的案例进行统计可以得到支持的交易属性的变迁历史。由于对验证案例执行、验证结果收集和验证结果统计分析进行了自动化设计，从而大大提高了交易验证的速度，减小了人工出错的概率。

为了更好的解释本发明实施例，下面通过具体的实施场景描述本发明实施例提供的一种交易验证方法的流程，设定需要验证发卡银行A是否支持借记卡的交易类型B交易，同时确定用户需要上传至发卡银行A的验证要素，如图4 所示，包括以下步骤：

步骤S401，根据交易类型B确定交易报文类型C，并配置交易报文类型C 的关联要素。

步骤S402，根据交易报文类型C的关联要素、发卡银行A、借记卡和上传至发卡银行A的验证要素组装待验证案例。

步骤S403，用户输入发卡银行A的银行卡***以及交易中的商户号。

步骤S404，根据发卡银行A的银行卡***以及交易中的商户号得到交易报文类型C的关联要素具体取值和验证元素的具体取值。

步骤S405，根据交易报文类型C的关联要素具体取值、发卡银行A、借记卡和验证元素的具体取值组装验证交易报文。

步骤S406，将验证交易报文发送至全渠道联机***。

步骤S407，全渠道联机***调用无卡路由服务获取路由信息，并向***银行卡信息交换***发起交易请求。

步骤S408，***银行卡信息交换***将交易转发给发卡银行A并将发卡银行A反馈的验证结果返回给全渠道联机***。

步骤S409，全渠道联机***将验证结果返回给业务运营监测平台。

步骤S410，业务运营监测平台获取到验证结果后和该验证案例的预设基准做比对并记录验证结果和比对结果。

本发明实施例，获取待验证案例，所述待验证案例是根据交易模板和待验证信息生成，然后根据所述待验证案例生成验证交易报文，根据所述验证交易报文对所述待验证案例进行验证并确定验证结果，最后在所述验证结果与预设基准匹配时，将所述待验证信息记录为支持的交易属性，所述预设基准是根据所述待验证案例确定的。本发明实施例中根据交易模板和待验证信息自动生成待验证案例，同时对待验证案例的执行、验证结果收集也进行了自动化设计，从而提高了交易验证的速度，避免了人工收集和统计验证结果带来的出错问题，降低了人力投入的成本。

基于相同构思，图5示例性的示出了本发明实施例提供的一种交易验证装置的结构，该装置可以执行交易验证的流程。

如图5所示，该装置包括：

获取模块501，用于获取待验证案例，所述待验证案例是根据交易模板和待验证信息生成；

处理模块502，用于根据所述待验证案例生成验证交易报文；

验证模块503，用于根据所述验证交易报文对所述待验证案例进行验证并确定验证结果；

统计模块504，用于在所述验证结果与预设基准匹配时，将所述待验证信息记录为支持的交易属性，所述预设基准是根据所述待验证案例确定的。

可选地，所述获取模块501具体用于：

根据交易模板和待验证信息生成待验证案例；

所述待验证信息包括交易报文类型、验证的多方交易对象；

根据所述交易报文类型，确定所述交易报文类型对应的关联要素；

根据所述验证的多方交易对象，确定验证要素集；

根据所述交易模板、所述关联要素和所述验证要素集确定所述待验证案例。

可选地，所述处理模块502具体用于：

所述验证的多方交易对象包括待验证银行卡的***；

根据所述待验证银行卡的***、所述交易报文类型对应的关联要素的取值方式确定所述交易报文类型对应的关联要素的具体取值和所述验证要素集的具体取值，其中，所述交易报文类型对应的关联要素的取值方式是根据预设规则确定的；

将所述交易报文类型对应的关联要素的具体取值和所述验证要素集的具体取值进行组装生成所述验证交易报文。

可选地，所述验证模块503具体用于：

将所述验证交易报文发送至所述待验证银行卡的发卡行，以使所述待验证银行卡的发卡行对所述验证交易报文进行处理并反馈验证结果；

接收所述待验证银行卡的发卡行反馈的验证结果。

可选地，所述统计模块504还用于：

所述根据所述验证交易报文对所述待验证案例进行验证并确定验证结果之后，在确定所述验证结果与预设基准不匹配时，将所述待验证信息记录为不支持的交易属性。

本发明实施例，获取待验证案例，所述待验证案例是根据交易模板和待验证信息生成，然后根据所述待验证案例生成验证交易报文，根据所述验证交易报文对所述待验证案例进行验证并确定验证结果，最后在所述验证结果与预设基准匹配时，将所述待验证信息记录为支持的交易属性，所述预设基准是根据所述待验证案例确定的。本发明实施例中根据交易模板和待验证信息自动生成待验证案例，同时对待验证案例的执行、验证结果收集也进行了自动化设计，从而提高了交易验证的速度，避免了人工收集和统计验证结果带来的出错问题，降低了人力投入的成本。

本领域内的技术人员应明白，本发明的实施例可提供为方法、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、 CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和 /或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/ 或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (8)

1.一种交易验证方法，其特征在于，包括：

根据交易报文类型，确定所述交易报文类型对应的关联要素；

根据银行卡性质、发卡银行以及上传至发卡行银行的验证要素确定验证要素集；

根据所述关联要素和***案例组装模板确定***案例；

根据所述***案例、所述验证要素集以及验证案例组装模板确定待验证案例；

根据所述待验证案例生成验证交易报文，所述验证交易报文包括待验证信息的具体取值；

根据所述验证交易报文对所述待验证案例进行验证并确定验证结果；

在所述验证结果与预设基准匹配时，将所述待验证信息记录为支持的交易属性，所述预设基准是根据所述待验证案例确定的。

2.如权利要求1所述的方法，其特征在于，所述根据所述待验证案例生成验证交易报文，包括：

所述验证的多方交易对象包括待验证银行卡的***；

根据所述待验证银行卡的***、所述交易报文类型对应的关联要素的取值方式确定所述交易报文类型对应的关联要素的具体取值和所述验证要素集的具体取值，其中，所述交易报文类型对应的关联要素的取值方式是根据预设规则确定的；

将所述交易报文类型对应的关联要素的具体取值和所述验证要素集的具体取值进行组装生成所述验证交易报文。

3.如权利要求2所述的方法，其特征在于，所述根据所述验证交易报文对所述待验证案例进行验证并确定验证结果，包括：

将所述验证交易报文发送至所述待验证银行卡的发卡行，以使所述待验证银行卡的发卡行对所述验证交易报文进行处理并反馈验证结果；

接收所述待验证银行卡的发卡行反馈的验证结果。

4.如权利要求3所述的方法，其特征在于，所述根据所述验证交易报文对所述待验证案例进行验证并确定验证结果之后，包括：

在确定所述验证结果与预设基准不匹配时，将所述待验证信息记录为不支持的交易属性。

5.一种交易验证装置，其特征在于，包括：

获取模块，用于根据交易报文类型，确定所述交易报文类型对应的关联要素，其中，所述交易报文类型是根据交易类型、交易子类、产品类型、上送URL确定的；根据验证的多方交易对象，确定验证要素集；根据交易模板、所述关联要素和所述验证要素集确定待验证案例；

处理模块，用于根据所述待验证案例生成验证交易报文，所述验证交易报文包括待验证信息的具体取值；

验证模块，用于根据所述验证交易报文对所述待验证案例进行验证并确定验证结果；

统计模块，用于在所述验证结果与预设基准匹配时，将所述待验证信息记录为支持的交易属性，所述预设基准是根据所述待验证案例确定的。

6.如权利要求5所述的装置，其特征在于，所述处理模块具体用于：

所述验证的多方交易对象包括待验证银行卡的***；

根据所述待验证银行卡的***、所述交易报文类型对应的关联要素的取值方式确定所述交易报文类型对应的关联要素的具体取值和所述验证要素集的具体取值，其中，所述交易报文类型对应的关联要素的取值方式是根据预设规则确定的；

将所述交易报文类型对应的关联要素的具体取值和所述验证要素集的具体取值进行组装生成所述验证交易报文。

7.如权利要求6所述的装置，其特征在于，所述验证模块具体用于：

将所述验证交易报文发送至所述待验证银行卡的发卡行，以使所述待验证银行卡的发卡行对所述验证交易报文进行处理并反馈验证结果；

接收所述待验证银行卡的发卡行反馈的验证结果。

8.如权利要求7所述的装置，其特征在于，所述统计模块还用于：

所述根据所述验证交易报文对所述待验证案例进行验证并确定验证结果之后，在确定所述验证结果与预设基准不匹配时，将所述待验证信息记录为不支持的交易属性。

Images