CN105590190A - 商户系统以及数据处理方法 - Google Patents

Abstract

<b>本申请公开了一种商户执行的交易数据的处理方法，包括：从用户处接收订单和支付请求信息；向所述用户发送消息，所述消息包含所述用户是否需要电子承兑的询问，所述电子承兑指用户通过电子票证的形式来进行承兑；在收到来自所述用户的需要电子承兑的确认后，将从所述用户处接收的支付请求信息以及与所述电子承兑相关的信息打包，并发送给支付网络；以及从所述支付网络接收所述支付网络根据打包信息所生成的电子支付凭证，所述电子支付凭证包含与所述电子承兑有关的信息。本申请还公开了一种商户系统。</b>

Description

商户系统以及数据处理方法

技术领域

本发明涉及交易数据处理，更具体来说，涉及一种商户执行的交易数据的处理方法以及商户系统。

背景技术

支付凭证也称为收银条，一般由POS终端在持卡人完成刷卡时打印，一般包含如下信息:商户号、商户名称、终端机编号、收单银行/收单机构、发卡行、交易卡号、交易类型、批次号、凭证号、交易时间、交易日期、消费金额等信息，如果是IC卡交易，则可能附加IC卡交易的相关验证信息。

支付凭证一般分为持卡人联、商户联和发卡机构联。分别供对应的各自的实体，主要用于发生争议时各自的凭据。这种凭证仅限于线下支付交易。

目前的线下支付凭证的局限性在于：1)仅作为支付行为的凭据，功能单一，场景有限；2)目前多数是纸质凭据，用户保存及使用均很麻烦，通常都是丢弃处理。

随着目前电子商务蓬勃发展，持卡人在线上使用银行卡完成支付时，通常是由商户提供支付完成的记录作为凭证，而没有一个像线下支付凭证一样权威可信的支付凭证。例如，在交易发送差错时用户无法提供有效的（例如经第三方确认的）支付依据，而只能通过商家提供的支付记录进行差错处理，这存在法律方面的风险。另一个问题是现在商户实现线上支付线下获取服务(O2O)时，必须给用户额外的凭证，如提货券、团购券或其他形式的电子票据，用户使用该电子票据在线下承兑相关服务。对于每个商家而言，它需要投入大量的资金、人力用于这个O2O服务平台的建立，很难推广到中小商户。

发明内容

为了解决上述问题，本申请给出一种提供有效（即官方或第三方确认）的线上支付凭证的技术实现方案。

根据本申请的一个方面，提供了一种商户执行的交易数据的处理方法，包括：从用户处接收订单和支付请求信息；向所述用户发送消息，所述消息包含所述用户是否需要电子承兑的询问，所述电子承兑指用户通过电子票证的形式来进行承兑；在收到来自所述用户的需要电子承兑的确认后，将从所述用户处接收的支付请求信息以及与所述电子承兑相关的信息打包，并发送给支付网络；以及从所述支付网络接收所述支付网络根据打包信息所生成的电子支付凭证，所述电子支付凭证包含与所述电子承兑有关的信息。

上述方法还可包括：将所述电子支付凭证提供给所述用户，使得其可使用该电子支付凭证在线下承兑相关服务。

在上述方法中，与所述电子承兑相关的信息包括所述用户已购买的服务信息或商品信息。

在上述方法中，所述电子支付凭证包括支付数据集合、服务信息集合以及签名，所述支付数据集合包含如下数据项：商户号、商户名称、终端机编号、收单机构、发卡行、交易卡号、交易类型、批次号、凭证号、交易时间、交易日期以及消费金额，所述服务信息集合包括如下数据项：商户名称、支付卡号、支付时间、支付日期以及物品或服务描述。

在上述方法中，所述签名由所述支付网络根据所述支付数据集合和所述服务信息集合来生成。

在上述方法中，所述电子支付凭证包括由所述商户定义的验证信息，所述验证信息包含所述用户的身份、支付状态、可获取的服务以及状态标识。

根据本申请的另一个方面，提供了一种商户系统，包括：第一接收单元，用于从用户处接收订单和支付请求信息；第一发送单元，用于向所述用户发送消息，所述消息包含所述用户是否需要电子承兑的询问，所述电子承兑指用户通过电子票证的形式来进行承兑；打包单元，用于在收到来自所述用户的需要电子承兑的确认后，将从所述用户处接收的支付请求信息以及与所述电子承兑相关的信息打包，并发送给支付网络；以及第二接收单元，从所述支付网络接收所述支付网络根据打包信息所生成的电子支付凭证，所述电子支付凭证包含与所述电子承兑有关的信息。

商户系统还可包括：第二发送单元，用于将所述电子支付凭证提供给所述用户，使得其可使用该电子支付凭证在线下承兑相关服务或商品。

在上述商户系统中，与所述电子承兑相关的信息包括所述用户已购买的服务信息或商品信息。

在上述商户系统中，所述电子支付凭证包括支付数据集合、服务信息集合以及签名，所述支付数据集合包含如下数据项：商户号、商户名称、终端机编号、收单机构、发卡行、交易卡号、交易类型、批次号、凭证号、交易时间、交易日期以及消费金额，所述服务信息集合包括如下数据项：商户名称、支付卡号、支付时间、支付日期以及物品或服务描述。

在上述商户系统中，所述签名由所述支付网络根据所述支付数据集合和所述服务信息集合来生成。

在上述商户系统中，所述电子支付凭证包括由所述商户定义的验证信息，所述验证信息包含所述用户的身份、支付状态、可获取的服务以及状态标识。

附图说明

在参照附图阅读了本发明的具体实施方式以后，本领域技术人员将会更清楚地了解本发明的各个方面。本领域技术人员应当理解的是：这些附图仅仅用于配合具体实施方式说明本发明的技术方案，而并非意在对本发明的保护范围构成限制。

图1是根据本申请的实施例、交易数据的处理流程。

具体实施方式

下面介绍的是本发明的多个可能实施例中的一些，旨在提供对本发明的基本了解，并不旨在确认本发明的关键或决定性的要素或限定所要保护的范围。容易理解，根据本发明的技术方案，在不变更本发明的实质精神下，本领域的一般技术人员可以提出可相互替换的其它实现方式。因此，以下具体实施方式以及附图仅是对本发明的技术方案的示例性说明，而不应当视为本发明的全部或者视为对本发明技术方案的限定或限制。

线上线下一体化是移动互联网时代的典型特征，线上线下打通的方式之一是通过支付，本申请的技术方案提出一种新型的多功能电子支付凭证及处理系统，可在完成支付过程后，将用户支付后商家需给付用户的物品以电子的形式记录在支付凭证中，用户可凭证该凭证在线下享受自己购买的服务或获得相应的商品。同时本申请的技术方案揭示了处理该多功能电子支付凭证数据的方法和系统。

根据本申请的一个实施例，提供了一种商户执行的交易数据的处理方法，包括：从用户处接收订单和支付请求信息；向所述用户发送消息，所述消息包含所述用户是否需要电子承兑的询问，所述电子承兑指用户通过电子票证的形式来进行承兑；在收到来自所述用户的需要电子承兑的确认后，将从所述用户处接收的支付请求信息以及与所述电子承兑相关的信息打包，并发送给支付网络；以及从所述支付网络接收所述支付网络根据打包信息所生成的电子支付凭证，所述电子支付凭证包含与所述电子承兑有关的信息。

参考图1。图1根据本申请的一个实施例示出了支付凭证数据处理的整个过程。首先，如步骤1所示，持卡人在商户网站浏览，并生成订单，确认支付。随后，商户网站提示持卡人选择支付方式并完成支付信息的输入后，提示持卡人所订购的服务是否需要通过电子票的形式进行承兑，如果用户选择该功能，则商户系统记录用户的选择结果，将该服务的承兑信息和支付请求信息一起打包后向支付网络发起支付请求（步骤2）。接着，支付网络收到支付请求后首先向发卡行发起支付请求，如果支付失败，则直接返回支付失败的结果给商户；如果支付成功，则生成支付凭证，同时将该笔交易的服务承兑信息记入支付凭证，同时对该支付凭证进行签名。之后将支付结果及包含服务承兑信息的支付凭证返回给商户（步骤3）。然后，商户提示持卡人支付结果，同时显示支付凭证给持卡人，商户通常将该支付凭证保存在商户网站系统当中，同时也保存在商户给用户提供的手机APP当中（步骤4）。

至此，用户（持卡人）已经从商户处成功获得了电子支付凭证。该电子支付凭证由支付网络或发卡行（第三方）出具，具有一定的权威性。

在一个具体的实施例中，电子支付凭证包括支付数据集合、服务数据集合以及签名三部分。

例如，支付数据集合可包括商户号、商户名称、终端机编号、收单银行/收单机构、发卡行、交易卡号、交易类型、批次号、凭证号、交易时间、交易日期、消费金额等数据项。在IC卡交易的情况下，支付数据集合还可能包括IC卡交易的相关验证信息。

服务数据集合可包括商户名称、支付卡号、支付时间、支付日期、所购物品或服务等数据项。在一个实施例中，服务数据集合同时还可包括验证信息的数据项。

在一个具体的实现中，电子支付凭证记录为如下所示：

这三部分信息可采用TLV格式，也可采用其他的格式进行定义。签名密钥为支付机构的的签名密钥，可以是对称密钥，也可以是非对称密钥。在一个实施例中，签名由支付网络根据支付数据集合和服务数据集合来生成。在又一个实施例中，签名为支付数据集合和服务数据集合的顺序组合。

在服务数据集合中，验证信息是指商户自定义的一组信息，商户线下的验证设备可通过NFC、二维码、蓝牙或音频等技术方便地读取该信息，从而验证线下用户的身份、支付状态及可获取的服务。

在应用场景中，持卡人在线上商户购物时，如果商户或支付网关提供了用户系统，则电子支付凭证可保存在对应的用户系统中，如果没有用户系统，则其可生成电子文件供用户自行下载。

以下继续结合图1来介绍电子支付凭证的验证过程。持卡人在商户APP中选择某个支付凭证，选择支付凭证当中的服务信息，同时根据手机硬件的配置及验证设备的支持情况，选择验证的通讯方式，可选的方式有NFC、二维码、蓝牙或声波等。之后持卡人将手机靠近商户的电子票验证设备，电子票验证设备通过NFC、二维码、蓝牙或声波等方式读取手机上支付凭证中的服务信息（步骤5）。验证设备将读取的服务承兑信息在本地进行验证，也可发送到后端系统进行验证（步骤6）。如果联机验证，后端系统验证信息的有效性后将验证结果发达给验证设备（步骤7）。验证设备提示持卡人验证结果，商户根据验证结果为持卡人提供相应的服务（步骤8）。

对于那些将支付凭证保存在商户或支付网关的用户系统中的支付凭证，由用户系统提供支付凭证的使用和验证，可通过手机APP来进行使用。当用户使用支付凭证时，用户在APP当中选择某个支付凭证，APP显示支付凭证的支付信息和服务信息，如果服务信息包含验证信息，当用户手机靠近商户的线下验证设备，验证设备通过NFC、二维码或蓝牙设备进行信息的读取，验证信息的有效性，验证过程如下：首先。验证支付凭证的签名是否正确；其次，如果签名正确，则验证服务数据集合中的数据是否正确，该步骤可能和商户的后端应用系统进行交互；最后，如果上述两步验证成功，则支付凭据验证成功，否则验证失败。

在一个实施例中，验证结果可由验证设备以语音、文字或其他方式告知商户和持卡人，同时可选的，如果商户验证设备所涉及的系统和APP互通，则可将验证结果通知到APP，更新服务信息中的状态标识。

如图1所示，本申请中的商户系统可包括：商户网站、商户后端系统以及电子票据线下验证设备。但本申请的技术方案并不局限于此。本领域技术人员可以理解，本申请的商户系统可通过硬件、软件或硬件与软件的结合来进行实现。在一个实施例中，商户系统可包括：第一接收单元，用于从用户处接收订单和支付请求信息；第一发送单元，用于向所述用户发送消息，所述消息包含所述用户是否需要电子承兑的询问，所述电子承兑指用户通过电子票证的形式来进行承兑；打包单元，用于在收到来自所述用户的需要电子承兑的确认后，将从所述用户处接收的支付请求信息以及与所述电子承兑相关的信息打包，并发送给支付网络；以及第二接收单元，从所述支付网络接收所述支付网络根据打包信息所生成的电子支付凭证，所述电子支付凭证包含与所述电子承兑有关的信息。

在一个实施例中，上述商户系统还可包括：第二发送单元，用于将所述电子支付凭证提供给所述用户，使得其可使用该电子支付凭证在线下承兑相关服务或商品。

综上，本申请的技术方案定义并标准化了线上支付凭证，该线上支付凭证由支付网络或发卡行进行签名，为用户提供了进一步的法律保障。此外，本申请的技术方案将线上支付所产生的服务信息和支付凭证进行了耦合，方便用户和持卡人线下享受或使用服务，为商户提供简单易用的线上线下一体化的技术支撑。

上文中，参照附图描述了本发明的具体实施方式。但是，本领域中的普通技术人员能够理解，在不偏离本发明的精神和范围的情况下，还可以对本发明的具体实施方式作各种变更和替换。这些变更和替换都落在本发明权利要求书所限定的范围内。

Claims (12)

1.一种商户执行的交易数据的处理方法，包括：

从用户处接收订单和支付请求信息；

向所述用户发送消息，所述消息包含所述用户是否需要电子承兑的询问，所述电子承兑指用户通过电子票证的形式来承兑从商户处购买的物品或服务；

在收到来自所述用户的需要电子承兑的确认后，将从所述用户处接收的支付请求信息以及与所述电子承兑相关的信息打包，并发送给支付网络；以及

从所述支付网络接收所述支付网络根据打包信息所生成的电子支付凭证，所述电子支付凭证包含与所述电子承兑有关的信息。

2.如权利要求1所述的方法，还包括：将所述电子支付凭证提供给所述用户，所述电子支付凭证作为用户已经在指定商户完成支付行为的凭据；所述用户可使用该电子支付凭证在线下承兑相关服务。

3.如权利要求1所述的方法，其中，与所述电子承兑相关的信息包括所述用户已购买的服务信息或商品信息。

4.如权利要求1或3所述的方法，其中，所述电子支付凭证包括支付数据集合、服务信息集合以及签名，所述支付数据集合包含如下数据项：商户标识、商户名称、终端机编号、收单机构标识、发卡机构标识、交易卡号、交易类型、批次号、凭证号、交易时间、交易日期以及消费金额，所述服务信息集合包括如下数据项：商户名称、支付卡号、支付时间、支付日期以及物品或服务描述。

5.如权利要求4所述的方法，其中，所述签名由所述支付网络根据所述支付数据集合和所述服务信息集合来生成。

6.如权利要求1或5所述的方法，其中，所述电子支付凭证包括由所述商户定义的验证信息，所述验证信息包含所述用户的身份、支付状态、可获取的服务以及状态标识。

7.一种执行如权利要求1所述的方法的商户系统，其特征在于，包括：

第一接收单元，用于从用户处接收订单和支付请求信息；

第一发送单元，用于向所述用户发送消息，所述消息包含所述用户是否需要电子承兑的询问，所述电子承兑指用户通过电子票证的形式来进行承兑；

打包单元，用于在收到来自所述用户的需要电子承兑的确认后，将从所述用户处接收的支付请求信息以及与所述电子承兑相关的信息打包，并发送给支付网络；以及

第二接收单元，从所述支付网络接收所述支付网络根据打包信息所生成的电子支付凭证，所述电子支付凭证包含与所述电子承兑有关的信息。

8.如权利要求7所述的商户系统，还包括：第二发送单元，用于将所述电子支付凭证提供给所述用户，使得其可使用该电子支付凭证在线下承兑相关服务或商品。

9.如权利要求7所述的商户系统，其中，与所述电子承兑相关的信息包括所述用户已购买的服务信息或商品信息。

10.如权利要求7或9所述的商户系统，其中，所述电子支付凭证包括支付数据集合、服务信息集合以及签名，所述支付数据集合包含如下数据项：商户标识、商户名称、终端机编号、收单机构标识、发卡机构标识、交易卡号、交易类型、批次号、凭证号、交易时间、交易日期以及消费金额，所述服务信息集合包括如下数据项：商户名称、支付卡号、支付时间、支付日期以及物品或服务描述。

11.如权利要求10所述的商户系统，其中，所述签名由所述支付网络根据所述支付数据集合和所述服务信息集合来生成。

12.如权利要求7或11所述的商户系统，其中，所述电子支付凭证包括由所述商户定义的验证信息，所述验证信息包含所述用户的身份、支付状态、可获取的服务以及状态标识。