CN117217921A - 交易数据处理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请提供一种交易数据处理方法、装置、设备及存储介质。涉及数据处理技术领域。该方法包括：接入标准企业资源计划ERP接口；接收用户端发送的交易请求，根据所述交易请求完成在线支付，以得到支付信息；通过调用所述标准ERP接口将所述支付信息发送至商户平台系统，以使所述商户平台系统根据所述支付信息得到用户的消费数据，并通过调用所述标准ERP接口将用户的消费数据发送至所述福利平台系统；保存所述消费数据，完成交易。本申请的方法解决了现有技术中无法实现消费数据在线下商店门店和企业的福利平台之间的交互的问题。

Description

交易数据处理方法、装置、设备及存储介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种交易数据处理方法、装置、设备及存储介质。

背景技术

目前有大多数企业对于下发员工福利采用线下消费的模式，对于线下消费这种模式大多数企业会选择提供线下商店的消费券的方式，员工拿着消费券到线下门店消费。

使用消费券到线下门店消费的方式只需要和企业的福利平台谈妥合作事宜，将员工信息告知给线下商店门店就可以实现。

但是，这种方式企业无法知晓员工具体消费的商品数据，无法实现消费数据在线下商店门店和企业的福利平台之间的交互。

发明内容

本申请提供一种交易数据处理方法、装置、设备及存储介质，用以解决现有技术中无法实现消费数据在线下商店门店和企业的福利平台之间的交互的问题。

第一方面，本申请提供一种交易数据处理方法，应用于福利平台系统，所述福利平台系统包括提货模块，所述方法包括：接入标准企业资源计划ERP接口；接收用户端发送的交易请求，根据所述交易请求得到待支付交易额度；在所述提货模块显示用户的可用交易额度；若判定所述待支付交易额度满足所述可用交易额度，则生成交易订单信息，其中，所述交易订单信息中包括：用户信息、支付机构信息和收款方信息；对所述用户信息、支付机构信息和收款方信息进行验证，若所述用户信息为实名认证的用户信息，所述支付机构信息中的支付机构设备的签约状态为已签约状态，且所述收款方信息中收款方的信用值满足预设信用值，则根据所述交易订单信息完成在线支付，以生成所述交易请求的支付信息；通过调用所述标准ERP接口将所述支付信息发送至商户平台系统，以使所述商户平台系统根据所述支付信息得到用户的消费数据，并通过调用所述标准ERP接口将用户的消费数据发送至所述福利平台系统；其中，所述消费数据中包括：消费商品的名称、消费商品的数量、消费商品的金额、消费商品的销售门店、交易订单编号；保存所述消费数据，完成交易。

在一种可能的设计中，所述若判定所述待支付交易额度满足所述可用交易额度，则生成交易订单信息之后，还包括：将所述可用交易额度减去所述待支付交易额度，得到剩余可用交易额度；根据所述剩余可用交易额度更新所述提货模块中用户的可用交易额度。

在一种可能的设计中，所述标准ERP接口包括：支付成功回调接口和订单消费数据回传接口；相应地，所述通过调用所述标准ERP接口将所述支付信息发送至商户平台系统，以使所述商户平台系统根据所述支付信息得到用户的消费数据，并通过调用所述标准ERP接口将用户的消费数据发送至所述福利平台系统，包括：调用所述支付成功回调接口，通过所述支付成功回调接口将所述支付信息发送至商户平台系统，以使所述商户平台系统根据所述支付信息得到用户的消费数据，调用所述订单消费数据回传接口，通过所述订单消费数据回传接口将所述消费数据发送至福利平台系统。

在一种可能的设计中，所述调用所述支付成功回调接口之前，还包括：将所述支付信息通过高级加密标准算法进行加密。

在一种可能的设计中，所述对所述用户信息、支付机构信息和收款方信息进行验证，包括：验证所述用户信息是否为实名认证的用户信息；验证所述支付机构信息中的支付机构设备的签约状态是否为已签约状态；验证所述收款方信息中收款方的信用值满足预设信用值。

在一种可能的设计中，所述交易数据处理方法还包括：若监测到调用所述标准ERP接口将所述支付信息发送至商户平台系统失败，则调用所述标准ERP接口重新发送所述支付信息至商户平台系统，直至发送成功。

第二方面，本申请提供一种交易数据处理方法，应用于商户平台系统，包括：接入标准ERP接口；接收福利平台系统通过调用所述标准ERP接口发送的支付信息，其中所述支付信息是所述福利平台系统接收用户端发送的交易请求，根据所述交易请求得到待支付交易额度；在所述提货模块显示用户的可用交易额度；若判定所述待支付交易额度满足所述可用交易额度，则生成交易订单信息，其中，所述交易订单信息中包括：用户信息、支付机构信息和收款方信息；对所述用户信息、支付机构信息和收款方信息进行验证，若所述用户信息为实名认证的用户信息，所述支付机构信息中的支付机构设备的签约状态为已签约状态，且所述收款方信息中收款方的信用值满足预设信用值，则根据所述交易订单信息完成在线支付，以生成所述交易请求的支付信息得到的；根据所述支付信息得到用户的消费数据，其中，所述消费数据中包括：消费商品的名称、消费商品的数量、消费商品的金额、消费商品的销售门店、交易订单编号；通过调用所述标准ERP接口将所述消费数据发送至福利平台系统，以使所述福利平台系统保存所述消费数据，完成交易。

在一种可能的设计中，其中，所述标准ERP接口包括：支付成功回调接口和订单消费数据回传接口；相应地，所述接收福利平台系统通过调用所述标准ERP接口发送的支付信息，包括：接收福利平台系统通过调用所述支付成功回调接口发送的支付信息；相应地，所述通过调用所述标准ERP接口将所述消费数据发送至福利平台系统，包括：通过调用所述订单消费数据回传接口将所述消费数据发送至福利平台系统。

在一种可能的设计中，所述通过调用所述标准ERP接口将所述消费数据发送至福利平台系统之前，还包括：将所述消费数据通过高级加密标准算法进行加密。

在一种可能的设计中，所述交易数据处理方法还包括：若监测到通过调用所述标准ERP接口将所述消费数据发送至福利平台系统失败，则调用所述标准ERP接口重新将所述消费数据发送至福利平台系统，直至发送成功。

第三方面，本申请提供一种交易数据处理装置，应用于福利平台系统，所述福利平台系统包括提货模块，包括：第一接入模块，用于接入标准ERP接口；第一接收模块，用于接收用户端发送的交易请求，根据所述交易请求完成在线支付，以得到支付信息；第一发送模块，用于通过调用所述标准ERP接口将所述支付信息发送至商户平台系统，以使所述商户平台系统根据所述支付信息得到用户的消费数据，并通过调用所述标准ERP接口将用户的消费数据发送至所述福利平台系统；保存模块，用于保存所述消费数据，完成交易。

第四方面，本申请提供一种交易数据处理装置，应用于商户平台系统，包括：第二接入模块，用于接入标准ERP接口；第二接收模块，用于接收福利平台系统通过调用所述标准ERP接口发送的支付信息，其中，所述福利平台系统包括提货模块，所述支付信息是所述福利平台系统接收用户端发送的交易请求，并根据所述交易请求完成在线支付得到的；第二发送模块，用于根据所述支付信息得到用户的消费数据，通过调用所述标准ERP接口将所述消费数据发送至福利平台系统，以使所述福利平台系统保存所述消费数据，完成交易。

第五方面，本申请实施例提供一种电子设备，包括：至少一个处理器和存储器；所述存储器存储计算机执行指令；所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如上第一方面以及第一方面各种可能的设计所述的交易数据处理方法或第二方面以及第二方面各种可能的设计所述的交易数据处理方法。

第六方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上第一方面以及第一方面各种可能的设计所述的交易数据处理方法或第二方面以及第二方面各种可能的设计所述的交易数据处理方法。

第七方面，本申请实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时，实现如上第一方面以及第一方面各种可能的设计所述的交易数据处理方法或第二方面以及第二方面各种可能的设计所述的交易数据处理方法。

本申请提供的交易数据处理方法、装置、设备及存储介质，通过福利平台系统接入标准企业资源计划ERP接口，接收用户端发送的交易请求，根据所述交易请求得到待支付交易额度，在提货模块显示用户的可用交易额度，若判定待支付交易额度满足可用交易额度，则生成交易订单信息，其中，交易订单信息中包括：用户信息、支付机构信息和收款方信息；对用户信息、支付机构信息和收款方信息进行验证，若全部验证通过，则根据交易订单信息完成在线支付，以生成交易请求的支付信息；通过调用标准ERP接口将支付信息发送至商户平台系统，以使商户平台系统根据支付信息得到用户的消费数据，并通过调用标准ERP接口将用户的消费数据发送至福利平台系统；保存消费数据，完成交易，实现了消费数据在福利平台系统和商户平台系统之间的跨系统交互。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请实施例提供的交易数据处理方法的应用场景图；

图2为本申请实施例提供的交易数据处理方法的流程图一；

图3为本申请实施例提供的交易数据处理方法的流程图二；

图4为本申请实施例提供的交易数据处理方法的流程图三；

图5为本申请实施例提供的交易数据处理方法装置的结构示意图；

图6为本申请实施例提供的另一个交易数据处理方法装置的结构示意图；

图7为本申请实施例提供的电子设备的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

本申请的技术方案中，所涉及的金融数据或用户数据等信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。

目前有大多数企业对于下发员工福利采用线下消费的模式，对于线下消费这种模式大多数企业会选择提供线下商店的消费券的方式，员工拿着消费券到线下门店消费。使用消费券到线下门店消费的方式只需要和企业的福利平台谈妥合作事宜，将员工信息告知给线下商店门店就可以实现。还有一种方式商户提供券码，企业员工采用商户自有应用程序或者小程序扫码绑定，在应用程序或者小程序上选购商品支付，这种方式就是把提货活动、员工活动额度管理完全交给商户来统筹，企业活动方不能自由查看提货数据，需要数据可能需要联系商户，一旦员工额度需要调整，企业活动方需要联系商户进行查询修改。但是，这些方式企业无法知晓员工具体消费的商品数据，无法实现消费数据在线下商店门店和企业的福利平台之间的交互。

针对上述技术问题，本申请提出如下技术构思：在福利平台系统完成支付得到支付信息后，通过接口将支付信息发送至商户平台系统，使得商户平台系统根据支付信息得到用户的消费数据，并将消费数据通过接口回传至福利平台系统，以实现消费数据跨系统的交互。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图1为本申请实施例提供的交易数据处理方法的应用场景图。如图1所示，该应用场景包括：福利平台系统101和商户平台系统102，其中福利平台系统101和商户平台系统102均接入标准ERP接口，福利平台系统101可以通过调用标准ERP接口发送支付信息至商户平台系统102，商户平台系统102也可以通过调用标准ERP接口发送消费数据至福利平台系统101。

基于图1所示的应用场景，本申请实施例还提供一种交易数据处理方法。图2为本申请实施例提供的交易数据处理方法的流程图一。本实施例的方法的执行主体为福利平台系统，福利平台系统包括提货模块。如图2所示，该交易数据处理方法包括：

S201、接入标准企业资源计划ERP接口。

本实施例中，福利平台系统需要企业通过用户端注册福利平台系统的会员，福利平台系统提供创建活动、发放额度、查看活动使用明细等功能，企业注册成功后在福利平台系统创建活动，创建活动时企业可以选择该福利平台系统已经入驻的商户及对应的门店。

搭建福利平台系统可以采用的技术有SpringBoot框架、Shiro框架、Thymeleaf模板引擎、MyBatis框架和Layui框架。

标准企业资源计划（Enterprise Resource Planning，ERP）接口可以采用Java技术实现，每一位线下商户入驻需要对接标准ERP接口实现消费数据实时交互，福利平台系统给每一位入驻的商户分配唯一的商户编号、密钥进行标准ERP接口对接，请求参数通过高级加密标准算法进行加密。

S202、接收用户端发送的交易请求，根据交易请求得到待支付交易额度。

本实施例中，用户端发送的交易请求中包含该笔交易需要支付的金额，即待支付交易额度，因此接收用户端发送的交易请求后可以根据该交易请求得到待支付交易额度。

S203、在提货模块显示用户的可用交易额度。

本实施例中，用户端所属的用户的账户余额可以认为是用户的可交易额度，将用户的可用交易额度在提货模块进行显示，用于接下来判断待交易额度是否满足可用交易额度。

S204、若判定待支付交易额度满足可用交易额度，则生成交易订单信息，其中，交易订单信息中包括：用户信息、支付机构信息和收款方信息。

本实施例中，在若判定待支付交易额度满足可用交易额度之后，还可以包括更新提货模块中用户的可用交易额度的步骤，具体包括：

将可用交易额度减去待支付交易额度，得到剩余可用交易额度；根据剩余可用交易额度更新提货模块中用户的可用交易额度。

具体地，每当完成一次交易时，都需要更新提货模块中的可用交易额度。将可用交易额度减去待支付交易额度，得到的剩余可用交易额度即为更新后的可用交易额度。

具体地，用户端可以为用户发起交易的端口。交易请求中包括这笔交易的待支付交易额度。通过福利平台系统中的提货模块可以查询其显示的用户的可用交易额度，若待支付交易额度大于可用交易额度，则无法进行交易，若待支付交易额度小于或等于可用交易额度，则可以进行交易。

具体地，用户信息可以包括用户姓名、用户手机号、用户身份证号等信息，支付机构信息可以包括支付机构编号、支付机构准入状态等信息，收款方信息可以包括收款方账号、收款方户名等信息。

S205、对用户信息、支付机构信息和收款方信息进行验证，若用户信息为实名认证的用户信息，支付机构信息中的支付机构设备的签约状态为已签约状态，且收款方信息中收款方的信用值满足预设信用值，则根据交易订单信息完成在线支付，以生成交易请求的支付信息。

本实施例中，对用户信息、支付机构信息和收款方信息进行验证，包括：

验证用户信息是否为实名认证的用户信息；验证支付机构信息中的支付机构设备的签约状态是否为已签约状态；验证收款方信息中收款方的信用值满足预设信用值。

具体地，若用户信息为实名认证的用户信息，支付机构信息中的支付机构设备的签约状态为已签约状态，且收款方信息中收款方的信用值满足预设信用值，当这三项同时满足时说明该笔交易不存在问题，则可以根据交易订单信息完成在线支付，以生成交易请求的支付信息。

S206、通过调用标准ERP接口将支付信息发送至商户平台系统，以使商户平台系统根据支付信息得到用户的消费数据，并通过调用标准ERP接口将用户的消费数据发送至福利平台系统，其中，消费数据中包括：消费商品的名称、消费商品的数量、消费商品的金额、消费商品的销售门店、交易订单编号。

本实施例中，标准ERP接口包括：支付成功回调接口和订单消费数据回传接口；相应地，本实施例的具体步骤包括：

调用支付成功回调接口，通过支付成功回调接口将支付信息发送至商户平台系统，以使商户平台系统根据支付信息得到用户的消费数据，调用订单消费数据回传接口，通过订单消费数据回传接口将消费数据发送至福利平台系统。

具体地，支付信息可以包括：订单编号、订单人信息、订单金额、抵扣额度、活动名称、活动编号等信息。用户的消费数据可以包括具体商品名称、商品数量、商品金额、门店编号、福利平台系统订单号等数据。

本实施例中，调用支付成功回调接口之前，还包括：将支付信息通过高级加密标准算法进行加密。

具体地，高级加密标准算法（Advanced Encryption Standard，AES）是密码学中的高级加密标准，AES为分组加密法，把明文分成一组一组的，每组长度相等，每次加密一组数据，直到加密完整个明文，在AES标准规范中，分组长度只能是128位，AES是按照字节进行加密的，也就是说每个分组为16个字节（每个字节8位）。密钥的长度可以使用128位、192位或256位。

S207、保存消费数据，完成交易。

本实施例中，福利平台系统对消费数据进行保存，可以使得企业知晓员工具体消费的商品数据。

具体地，本实施例中，还包括：若监测到调用标准ERP接口将支付信息发送至商户平台系统失败，则调用标准ERP接口重新发送支付信息至商户平台系统，直至发送成功。

综上，本实施例的交易数据处理方法，通过福利平台系统接入标准企业资源计划ERP接口，接收用户端发送的交易请求，根据交易请求得到待支付交易额度，在提货模块显示用户的可用交易额度，若判定待支付交易额度满足可用交易额度，则生成交易订单信息，其中，交易订单信息中包括：用户信息、支付机构信息和收款方信息；对用户信息、支付机构信息和收款方信息进行验证，若全部验证通过，则根据交易订单信息完成在线支付，以生成交易请求的支付信息；通过调用标准ERP接口将支付信息发送至商户平台系统，以使商户平台系统根据支付信息得到用户的消费数据，并通过调用标准ERP接口将用户的消费数据发送至福利平台系统；保存消费数据，完成交易，实现了消费数据在福利平台系统和商户平台系统之间的跨系统交互。

图3为本申请实施例提供的交易数据处理方法的流程图二，本实施例的方法的执行主体为商户平台系统。如图3所示，该交易数据处理方法，包括如下步骤：

S301、接入标准ERP接口。

本实施例中，商户平台系统是指商户及对应的门店的后台系统。商户平台系统通过接入标准ERP接口与福利平台系统进行交互。

S302、接收福利平台系统通过调用标准ERP接口发送的支付信息，其中支付信息是福利平台系统接收用户端发送的交易请求，根据交易请求得到待支付交易额度；在提货模块显示用户的可用交易额度；若判定待支付交易额度满足可用交易额度，则生成交易订单信息，其中，交易订单信息中包括：用户信息、支付机构信息和收款方信息；对用户信息、支付机构信息和收款方信息进行验证，若用户信息为实名认证的用户信息，支付机构信息中的支付机构设备的签约状态为已签约状态，且收款方信息中收款方的信用值满足预设信用值，则根据交易订单信息完成在线支付，以生成交易请求的支付信息得到的。

本实施例中，标准ERP接口包括：支付成功回调接口和订单消费数据回传接口，商户平台系统接收福利平台系统通过调用支付成功回调接口发送的支付信息。

S303、根据支付信息得到用户的消费数据，其中，消费数据中包括：消费商品的名称、消费商品的数量、消费商品的金额、消费商品的销售门店、交易订单编号；通过调用标准ERP接口将消费数据发送至福利平台系统，以使福利平台系统保存消费数据，完成交易。

本实施例中，商户平台系统通过调用订单消费数据回传接口将消费数据发送至福利平台系统。

通过调用订单消费数据回传接口将消费数据发送至福利平台系统之前，还包括：将消费数据通过高级加密标准算法进行加密。

具体地，本实施例中的加密方法与步骤S203中相同，此处不再赘述。

本实施例中，还包括：若监测到通过调用标准ERP接口将消费数据发送至福利平台系统失败，则调用标准ERP接口重新将消费数据发送至福利平台系统，直至发送成功。

综上，本实施例的交易数据处理方法，商户平台系统通过接入标准ERP接口，接收福利平台系统通过调用述标准ERP接口发送的支付信息，根据支付信息得到用户的消费数据，通过调用标准ERP接口将消费数据发送至福利平台系统，以使福利平台系统保存消费数据，完成交易，实现了消费数据在商户平台系统和福利平台系统之间的跨系统交互。

图4为本申请实施例提供的交易数据处理方法的流程图三。该实施例提供另一种交易数据处理方法。如图4所示，该交易数据处理方法，包括如下步骤：

S401、福利平台系统和商户平台系统均接入标准ERP接口；其中标准ERP接口包括支付成功回调接口和订单消费数据回传接口。

S402、福利平台系统接收用户端发送的交易请求，根据交易请求得到待支付交易额度。S403、福利平台系统在提货模块显示用户的可用交易额度。

S404、福利平台系统若判定待支付交易额度满足可用交易额度，则生成交易订单信息，其中，交易订单信息中包括：用户信息、支付机构信息和收款方信息。

S405、福利平台系统对用户信息、支付机构信息和收款方信息进行验证，若用户信息为实名认证的用户信息，支付机构信息中的支付机构设备的签约状态为已签约状态，且收款方信息中收款方的信用值满足预设信用值，则根据交易订单信息完成在线支付，以生成交易请求的支付信息。

S406、福利平台系统将支付信息通过高级加密标准算法进行加密。

S407、福利平台系统通过调用支付成功回调接口将加密后的支付信息发送至商户平台系统。

S408、商户平台系统根据支付信息得到用户的消费数据，其中，消费数据中包括：消费商品的名称、消费商品的数量、消费商品的金额、消费商品的销售门店、交易订单编号；并将消费数据通过高级加密标准算法进行加密。

S409、商户平台系统调用订单消费数据回传接口将加密后的消费数据发送至福利平台系统。

S410、福利平台系统保存消费数据，完成交易。

综上，本实施例的交易数据处理方法，福利平台系统和商户平台系统通过接入标准ERP接口，福利平台系统将支付信息加密后发送至商户平台系统，商户平台系统根据加密后的支付信息得到用户的消费数据，将消费数据加密后发送至福利平台系统，福利平台系统保存消费数据，实现了用户的消费数据在福利平台系统和商户平台系统之间的跨系统交互。

图5为本申请实施例提供的交易数据处理装置的结构示意图。如图5所示，该交易数据处理装置，应用于福利平台系统，包括：第一接入模块501、第一接收模块502、显示模块503、生成模块504、验证模块505、第一发送模块506和保存模块507。

其中，第一接入模块501，用于接入标准ERP接口。

第一接收模块502，用于接收用户端发送的交易请求，根据交易请求得到待支付交易额度。

显示模块503，用于在提货模块显示用户的可用交易额度。

生成模块504，用于若判定待支付交易额度满足可用交易额度，则生成交易订单信息，其中，交易订单信息中包括：用户信息、支付机构信息和收款方信息。

验证模块505，用于对用户信息、支付机构信息和收款方信息进行验证，若用户信息为实名认证的用户信息，支付机构信息中的支付机构设备的签约状态为已签约状态，且收款方信息中收款方的信用值满足预设信用值，则根据交易订单信息完成在线支付，以生成交易请求的支付信息。

第一发送模块506，用于通过调用标准ERP接口将支付信息发送至商户平台系统，以使商户平台系统根据支付信息得到用户的消费数据，其中，消费数据中包括：消费商品的名称、消费商品的数量、消费商品的金额、消费商品的销售门店、交易订单编号；并通过调用标准ERP接口将用户的消费数据发送至福利平台系统。

保存模块507，用于保存消费数据，完成交易。

在一些实施例中，验证模块505具体用于验证用户信息是否为实名认证的用户信息；验证支付机构信息中的支付机构设备的签约状态是否为已签约状态；验证收款方信息中收款方的信用值满足预设信用值。

在一些实施例中，交易数据处理装置还包括：更新模块508；更新模块505，用于将可用交易额度减去待支付交易额度，得到剩余可用交易额度；根据剩余可用交易额度更新提货模块中用户的可用交易额度。

在一些实施例中，标准ERP接口包括：支付成功回调接口和订单消费数据回传接口，第一发送模块506，用于调用支付成功回调接口，通过支付成功回调接口将支付信息发送至商户平台系统，以使商户平台系统根据支付信息得到用户的消费数据，调用订单消费数据回传接口，通过订单消费数据回传接口将消费数据发送至福利平台系统。

在一些实施例中，交易数据处理装置还包括：第一加密模块509；第一加密模块509用于将支付信息通过高级加密标准算法进行加密。

在一些实施例中，交易数据处理装置还包括：第一监测模块510；第一监测模块510用于若监测到调用标准ERP接口将支付信息发送至商户平台系统失败，则调用标准ERP接口重新发送支付信息至商户平台系统，直至发送成功。

本申请实施例提供的交付物的处理装置，可用于执行上述实施例中交付物的处理方法的技术方案，其实现原理和技术效果类似，在此不再赘述。

图6为本申请实施例提供的另一个交易数据处理方法装置的结构示意图。如图6所示，该交易数据处理装置，应用于商户平台系统，包括：第二接入模块601、第二接收模块602和第二发送模块603。

其中，第二接入模块601，用于接入标准ERP接口。

第二接收模块602，用于接收福利平台系统通过调用标准ERP接口发送的支付信息，其中支付信息是福利平台系统接收用户端发送的交易请求，根据交易请求得到待支付交易额度；在提货模块显示用户的可用交易额度；若判定待支付交易额度满足可用交易额度，则生成交易订单信息，其中，交易订单信息中包括：用户信息、支付机构信息和收款方信息；对用户信息、支付机构信息和收款方信息进行验证，若用户信息为实名认证的用户信息，支付机构信息中的支付机构设备的签约状态为已签约状态，且收款方信息中收款方的信用值满足预设信用值，则根据交易订单信息完成在线支付，以生成交易请求的支付信息得到的。

第二发送模块603，用于根据支付信息得到用户的消费数据，其中，消费数据中包括：消费商品的名称、消费商品的数量、消费商品的金额、消费商品的销售门店、交易订单编号；通过调用标准ERP接口将消费数据发送至福利平台系统，以使福利平台系统保存消费数据，完成交易。

在一些实施例中，标准ERP接口包括：支付成功回调接口和订单消费数据回传接口，第二接收模块602，还具体用于接收福利平台系统通过调用支付成功回调接口发送的支付信息；第二发送模块603，还具体用于通过调用订单消费数据回传接口将消费数据发送至福利平台系统。

在一些实施例中，交易数据处理装置还包括：第二加密模块604；第二加密模块604用于将消费数据通过高级加密标准算法进行加密。

在一些实施例中，交易数据处理装置还包括：第二监测模块605；第二监测模块605用于若监测到通过调用标准ERP接口将消费数据发送至福利平台系统失败，则调用标准ERP接口重新将消费数据发送至福利平台系统，直至发送成功。

本申请实施例提供的交付物的处理装置，可用于执行上述实施例中交付物的处理方法的技术方案，其实现原理和技术效果类似，在此不再赘述。

需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。例如，第一拉取模块503可以为单独设立的处理元件，也可以集成在上述装置的某一个芯片中实现，此外，也可以以程序代码的形式存储于上述装置的存储器中，由上述装置的某一个处理元件调用并执行以上第一拉取模块503的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

图7为本申请实施例提供的电子设备的结构示意图。如图7所示，该电子设备可以包括：收发器701、处理器702、存储器703。

处理器702执行存储器存储的计算机执行指令，使得处理器702执行上述实施例中的方案。处理器702可以是通用处理器，包括中央处理器CPU、网络处理器（networkprocessor，NP）等；还可以是数字信号处理器DSP、专用集成电路ASIC、现场可编程门阵列FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

存储器703通过系统总线与处理器702连接并完成相互间的通信，存储器703用于存储计算机程序指令。

收发器701可以用于获取待运行任务和待运行任务的配置信息。

系统总线可以是外设部件互连标准（peripheral component interconnect，PCI）总线或扩展工业标准结构（extended industry standard architecture，EISA）总线等。系统总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。收发器用于实现数据库访问装置与其他计算机（例如客户端、读写库和只读库）之间的通信。存储器可能包含随机存取存储器（randomaccess memory，RAM），也可能还包括非易失性存储器（non-volatile memory）。

本申请实施例提供的电子设备，可以是上述实施例的终端设备。

本申请实施例还提供一种运行指令的芯片，该芯片用于执行上述实施例中交易数据处理方法的技术方案。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机执行指令，当该计算机执行指令在计算机上运行时，使得计算机执行上述实施例交易数据处理方法的技术方案。

本申请实施例还提供一种计算机程序产品，该计算机程序产品包括计算机程序，其存储在计算机可读存储介质中，至少一个处理器可以从计算机可读存储介质读取计算机程序，至少一个处理器执行计算机程序时可实现上述实施例中交易数据处理方法的技术方案。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个单元中。上述模块成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器执行本申请各个实施例方法的部分步骤。

应理解，上述处理器可以是中央处理单元（Central Processing Unit，简称CPU），还可以是其他通用处理器、数字信号处理器（Digital Signal Processor，简称DSP）、专用集成电路（Application Specific Integrated Circuit，简称ASIC）等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

总线可以是工业标准体系结构（Industry Standard Architecture，简称ISA）总线、外部设备互连（Peripheral Component Interconnect，简称PCI）总线或扩展工业标准体系结构（Extended Industry Standard Architecture，简称EISA）总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器（SRAM），电可擦除可编程只读存储器（EEPROM），可擦除可编程只读存储器（EPROM），可编程只读存储器（PROM），只读存储器（ROM），磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(Application Specific Integrated Circuits，简称ASIC)中。当然，处理器和存储介质也可以作为分立组件存在于电控单元或主控设备中。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (14)

1.一种交易数据处理方法，其特征在于，应用于福利平台系统，所述福利平台系统包括提货模块，所述方法包括：

接入标准企业资源计划ERP接口；

接收用户端发送的交易请求，根据所述交易请求得到待支付交易额度；

在所述提货模块显示用户的可用交易额度；

若判定所述待支付交易额度满足所述可用交易额度，则生成交易订单信息，其中，所述交易订单信息中包括：用户信息、支付机构信息和收款方信息；

对所述用户信息、支付机构信息和收款方信息进行验证，若所述用户信息为实名认证的用户信息，所述支付机构信息中的支付机构设备的签约状态为已签约状态，且所述收款方信息中收款方的信用值满足预设信用值，则根据所述交易订单信息完成在线支付，以生成所述交易请求的支付信息；

通过调用标准ERP接口将所述支付信息发送至商户平台系统，以使所述商户平台系统根据所述支付信息得到用户的消费数据，并通过调用所述标准ERP接口将用户的消费数据发送至所述福利平台系统；其中，所述消费数据中包括：消费商品的名称、消费商品的数量、消费商品的金额、消费商品的销售门店、交易订单编号；

保存所述消费数据，完成交易。

2.根据权利要求1所述的方法，其特征在于，所述若判定所述待支付交易额度满足所述可用交易额度，则生成交易订单信息之后，还包括：

将所述可用交易额度减去所述待支付交易额度，得到剩余可用交易额度；

根据所述剩余可用交易额度更新所述提货模块中用户的可用交易额度。

3.根据权利要求1所述的方法，其特征在于，其中，所述标准ERP接口包括：支付成功回调接口和订单消费数据回传接口；

相应地，所述通过调用所述标准ERP接口将所述支付信息发送至商户平台系统，以使所述商户平台系统根据所述支付信息得到用户的消费数据，并通过调用所述标准ERP接口将用户的消费数据发送至所述福利平台系统，包括：

调用所述支付成功回调接口，通过所述支付成功回调接口将所述支付信息发送至商户平台系统，以使所述商户平台系统根据所述支付信息得到用户的消费数据，调用所述订单消费数据回传接口，通过所述订单消费数据回传接口将所述消费数据发送至福利平台系统。

4.根据权利要求3所述的方法，其特征在于，所述调用所述支付成功回调接口之前，还包括：

将所述支付信息通过高级加密标准算法进行加密。

5.根据权利要求1所述的方法，其特征在于，所述对所述用户信息、支付机构信息和收款方信息进行验证，包括：

验证所述用户信息是否为实名认证的用户信息；

验证所述支付机构信息中的支付机构设备的签约状态是否为已签约状态；

验证所述收款方信息中收款方的信用值满足预设信用值。

6.根据权利要求1至5任一项所述的方法，其特征在于，还包括：

若监测到调用所述标准ERP接口将所述支付信息发送至商户平台系统失败，则调用所述标准ERP接口重新发送所述支付信息至商户平台系统，直至发送成功。

7.一种交易数据处理方法，其特征在于，应用于商户平台系统，包括：

接入标准ERP接口；

接收福利平台系统通过调用所述标准ERP接口发送的支付信息，其中所述福利平台系统包括提货模块，所述支付信息是所述福利平台系统接收用户端发送的交易请求，根据所述交易请求得到待支付交易额度；在所述提货模块显示用户的可用交易额度；若判定所述待支付交易额度满足所述可用交易额度，则生成交易订单信息，其中，所述交易订单信息中包括：用户信息、支付机构信息和收款方信息；对所述用户信息、支付机构信息和收款方信息进行验证，若所述用户信息为实名认证的用户信息，所述支付机构信息中的支付机构设备的签约状态为已签约状态，且所述收款方信息中收款方的信用值满足预设信用值，则根据所述交易订单信息完成在线支付，以生成所述交易请求的支付信息得到的；

根据所述支付信息得到用户的消费数据，其中，所述消费数据中包括：消费商品的名称、消费商品的数量、消费商品的金额、消费商品的销售门店、交易订单编号；通过调用所述标准ERP接口将所述消费数据发送至福利平台系统，以使所述福利平台系统保存所述消费数据，完成交易。

8.根据权利要求7所述的方法，其特征在于，其中，所述标准ERP接口包括：支付成功回调接口和订单消费数据回传接口；

相应地，所述接收福利平台系统通过调用所述标准ERP接口发送的支付信息，包括：

接收福利平台系统通过调用所述支付成功回调接口发送的支付信息；

相应地，所述通过调用所述标准ERP接口将所述消费数据发送至福利平台系统，包括：

通过调用所述订单消费数据回传接口将所述消费数据发送至福利平台系统。

9.根据权利要求7所述的方法，其特征在于，所述通过调用所述标准ERP接口将所述消费数据发送至福利平台系统之前，还包括：

将所述消费数据通过高级加密标准算法进行加密。

10.根据权利要求7至9任一项所述的方法，其特征在于，还包括：

若监测到通过调用所述标准ERP接口将所述消费数据发送至福利平台系统失败，则调用所述标准ERP接口重新将所述消费数据发送至福利平台系统，直至发送成功。

11.一种交易数据处理装置，其特征在于，应用于福利平台系统，所述福利平台系统包括提货模块，包括：

第一接入模块，用于接入标准ERP接口；

第一接收模块，用于接收用户端发送的交易请求，根据所述交易请求得到待支付交易额度；

显示模块，用于在所述提货模块显示用户的可用交易额度；

生成模块，用于若判定所述待支付交易额度满足所述可用交易额度，则生成交易订单信息，其中，所述交易订单信息中包括：用户信息、支付机构信息和收款方信息；

验证模块，用于对所述用户信息、支付机构信息和收款方信息进行验证，若所述用户信息为实名认证的用户信息，所述支付机构信息中的支付机构设备的签约状态为已签约状态，且所述收款方信息中收款方的信用值满足预设信用值，则根据所述交易订单信息完成在线支付，以生成所述交易请求的支付信息；

第一发送模块，用于通过调用所述标准ERP接口将所述支付信息发送至商户平台系统，以使所述商户平台系统根据所述支付信息得到用户的消费数据，并通过调用所述标准ERP接口将用户的消费数据发送至所述福利平台系统；其中，所述消费数据中包括：消费商品的名称、消费商品的数量、消费商品的金额、消费商品的销售门店、交易订单编号；

保存模块，用于保存所述消费数据，完成交易。

12.一种交易数据处理装置，其特征在于，应用于商户平台系统，包括：

第二接入模块，用于接入标准ERP接口；

第二接收模块，用于接收福利平台系统通过调用所述标准ERP接口发送的支付信息，其中所述福利平台系统包括提货模块，所述支付信息是所述福利平台系统接收用户端发送的交易请求，根据所述交易请求得到待支付交易额度；在所述提货模块显示用户的可用交易额度；若判定所述待支付交易额度满足所述可用交易额度，则生成交易订单信息，其中，所述交易订单信息中包括：用户信息、支付机构信息和收款方信息；对所述用户信息、支付机构信息和收款方信息进行验证，若所述用户信息为实名认证的用户信息，所述支付机构信息中的支付机构设备的签约状态为已签约状态，且所述收款方信息中收款方的信用值满足预设信用值，则根据所述交易订单信息完成在线支付，以生成所述交易请求的支付信息得到的；

第二发送模块，用于根据所述支付信息得到用户的消费数据，其中，所述消费数据中包括：消费商品的名称、消费商品的数量、消费商品的金额、消费商品的销售门店、交易订单编号；通过调用所述标准ERP接口将所述消费数据发送至福利平台系统，以使所述福利平台系统保存所述消费数据，完成交易。

13.一种电子设备，其特征在于，包括：处理器，以及与所述处理器通信连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现如权利要求1至5中任一项所述的方法，或如权利要求7至10中任一项所述的方法。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1至5中任一项所述的方法，或如权利要求7至10中任一项所述的方法。