CN110020843B - 基于托管账户的红包领取方法及装置、电子设备 - Google Patents

Abstract

公开一种基于托管账户的红包领取方法，包括：接收业务服务端发送的针对目标红包的红包领取请求；其中，所述红包领取请求包括，红包领取方登陆业务客户端时所使用的用户标识；响应于所述红包领取请求，确定所述用户标识是否绑定了所述支付服务端中的支付账户；如果所述用户标识未绑定所述支付服务端中的支付账户，将所述红包领取方领取到的红包资金转入与所述用户标识对应的资金托管账户；其中，所述资金托管账户为基于所述业务服务端上存储的所述红包领取方的用户信息，在所述支付服务端中为所述红包领取方创建的资金托管账户。

Description

基于托管账户的红包领取方法及装置、电子设备

技术领域

本说明书一个或多个实施例涉及区块链技术领域，尤其涉及一种基于托管账户的红包领取方法及装置、电子设备。

背景技术

在社交金融的场景中，存在大量的红包发放的场景；例如，可以在APP应用中搭载红包发放功能，个人可以通过APP应用进行一对一的红包发放；或者，在APP应用中的用户群组中进行一对多的红包发放。由于红包发放通常会涉及资金在不同的账户之间流转，因此通常要求APP的运营方需要具有相关的支付资质；然后，在实际应用中，对于一些不具有支付资质的运营方而言，通常可能也具有在APP中搭载红包发放功能的需求。

发明内容

本说明书提出一种基于托管账户的红包领取方法，包括：

接收业务服务端发送的针对目标红包的红包领取请求；其中，所述红包领取请求包括，红包领取方登陆业务客户端时所使用的用户标识；

响应于所述红包领取请求，确定所述用户标识是否绑定了所述支付服务端中的支付账户；

如果所述用户标识未绑定所述支付服务端中的支付账户，将所述红包领取方领取到的红包资金转入与所述用户标识对应的资金托管账户；

其中，所述资金托管账户为基于所述业务服务端上存储的所述红包领取方的用户信息，在所述支付服务端中为所述红包领取方创建的资金托管账户。

可选的，如果所述用户标识未绑定所述支付服务端中的支付账户，将所述红包领取方领取到的红包资金转入与所述用户标识对应的资金托管账户，包括：

如果所述用户标识未绑定所述支付服务端中的支付账户，进一步确定所述支付服务端中是否存在与所述用户标识对应的资金托管账户；

如果所述支付服务端中存在与所述用户标识对应的资金托管账户，将所述红包领取方领取到的红包资金转入所述资金托管账户；

如果所述支付服务端中不存在与所述用户标识对应的资金托管账户，基于所述业务服务端上存储的与所述用户标识对应的用户信息，为所述红包领取方创建资金托管账户，并将所述红包领取方领取到的红包资金转入创建的资金托管账户。

可选的，接收业务服务端发送的红包领取请求之前，还包括：

接收业务服务端发送的资金托管账户创建请求；其中，所述创建请求中包括红包领取方登陆所述业务客户端时所使用的用户标识；

基于所述业务服务端存储的与所述用户标识对应的用户信息，为所述红包领取方创建资金托管账户。

可选的，基于所述业务服务端存储的与所述用户标识对应的用户信息，为所述红包领取方创建资金托管账户，包括：

获取业务服务端存储的与所述用户标识对应的用户信息的第一数据摘要；

计算本地存储的与所述用户标识对应的用户信息的第二数据摘要；

验证所述第一数据摘要与所述第二数据摘要是否匹配；如果是，为所述红包领取方创建资金托管账户，并在本地保存所述用户标识与所述资金托管账户的对应关系。

可选的，还包括：

接收业务服务端发送的红包提现请求；其中，所述红包提现请求包括红包领取方登陆所述业务客户端时所使用的用户标识；

响应于所述红包提现请求，将与所述用户标识对应的所述资金托管账户中的红包资金，转入与所述用户标识绑定的支付账户。

可选的，还包括：

将所述红包领取方领取到的红包资金转入与所述用户标识对应的资金托管账户之后，生成对应于所述资金托管账户的红包领取记录；以及，

响应于接收到的所述业务服务端发送的针对所述资金托管账户的红包记录查看请求，将生成的对应于所述资金托管账户的红包领取记录返回给所述业务服务端，以由所述业务服务端将所述红包领取记录，进一步返回所述业务客户端。

可选的，所述支付服务端为第三方支付平台；所述业务服务端为不具备支付资质的服务提供商对应的服务平台；所述业务客户端为接入所述服务平台的客户端软件。

本说明书还提出一种基于托管账户的红包领取装置，包括：

接收模块，接收业务服务端发送的针对目标红包的红包领取请求；其中，所述红包领取请求包括，红包领取方登陆业务客户端时所使用的用户标识；

确定模块，响应于所述红包领取请求，确定所述用户标识是否绑定了所述支付服务端中的支付账户；

转入模块，如果所述用户标识未绑定所述支付服务端中的支付账户，将所述红包领取方领取到的红包资金转入与所述用户标识对应的资金托管账户；

其中，所述资金托管账户为基于所述业务服务端上存储的所述红包领取方的用户信息，在所述支付服务端中为所述红包领取方创建的资金托管账户。

可选的，所述转入模块：

如果所述用户标识未绑定所述支付服务端中的支付账户，进一步确定所述支付服务端中是否存在与所述用户标识对应的资金托管账户；

如果所述支付服务端中存在与所述用户标识对应的资金托管账户，将所述红包领取方领取到的红包资金转入所述资金托管账户；

如果所述支付服务端中不存在与所述用户标识对应的资金托管账户，基于所述业务服务端上存储的与所述用户标识对应的用户信息，为所述红包领取方创建资金托管账户，并将所述红包领取方领取到的红包资金转入创建的资金托管账户。

可选的，所述接收模块进一步：

在接收业务服务端发送的红包领取请求之前，接收业务服务端发送的资金托管账户创建请求；其中，所述创建请求中包括红包领取方登陆所述业务客户端时所使用的用户标识；

所述装置还包括；

创建模块，基于所述业务服务端存储的与所述用户标识对应的用户信息，为所述红包领取方创建资金托管账户。

可选的，所述转入模块或者所述创建模块进一步：

获取业务服务端存储的与所述用户标识对应的用户信息的第一数据摘要；计算本地存储的与所述用户标识对应的用户信息的第二数据摘要；验证所述第一数据摘要与所述第二数据摘要是否匹配；如果是，为所述红包领取方创建资金托管账户，并在本地保存所述用户标识与所述资金托管账户的对应关系。

可选的，所述接收模块进一步：

接收业务服务端发送的红包提现请求；其中，所述红包提现请求包括红包领取方登陆所述业务客户端时所使用的用户标识；

所述转入模块进一步：

响应于所述红包提现请求，将与所述用户标识对应的所述资金托管账户中的红包资金，转入与所述用户标识绑定的支付账户。

可选的，所述转入模块进一步：

将所述红包领取方领取到的红包资金转入与所述用户标识对应的资金托管账户之后，生成对应于所述资金托管账户的红包领取记录；

所述装置还包括：

返回模块，响应于接收到的所述业务服务端发送的针对所述资金托管账户的红包记录查看请求，将生成的对应于所述资金托管账户的红包领取记录返回给所述业务服务端，以由所述业务服务端将所述红包领取记录，进一步返回所述业务客户端。

可选的，所述支付服务端为第三方支付平台；所述业务服务端为不具备支付资质的服务提供商对应的服务平台；所述业务客户端为接入所述服务平台的客户端软件。

通过以上技术方案，一方面，由于支付服务端可以在确定红包领取方在登录业务客户端时所使用的用户标识未绑定支付服务端中的支付账户时，将红包领取方领取到的红包资金转入，根据业务服务端上存储的该红包领取方的用户信息，在支付服务端中为该红包领取方创建的资金托管账户中，而不再强制要求红包领取方在业务客户端上绑定支付账户；因此，可以降低红包资金的收款门槛，使得那些未在业务客户端上绑定支付账户的用户，也可以正常领取红包；

另一方面，由于红包领取方领取到的，由红包发放方通过业务客户端上绑定的支付账户发放的红包资金，最终仍然会回流至上述支付服务端上的资金托管账户；因此，可以实现支付服务端上的红包资金流的闭环，利于支付服务端的运营方更好的管理红包资金；而且，对于上述业务服务端的运营方而言，由于其可以不再需要自主的管理用户通过业务客户端领取到的红包资金；因此，也可以降低上述业务服务端的运营方的资金管理难度，节约资金管理成本。

附图说明

图1是一示例性实施例提供的一种红包领取方领取红包的示意图；

图2是一示例性实施例提供的一种基于托管账户的红包领取方法的流程图；

图3是一示例性实施例提供的一种在APP上绑定支付账户的交互图；

图4是一示例性实施例提供的一种红包领取方在APP上领取红包的交互图；

图5是一示例性实施例提供的另一种红包领取方领取红包的示意图；

图6是一示例性实施例提供的一种电子设备的结构示意图；

图7是一示例性实施例提供的一种基于托管账户的红包领取装置的框图。

具体实施方式

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

需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。

在实际应用中，如果业务客户端(比如APP)的运营方，需要在业务客户端中搭载“红包”功能，但业务客户端的运营方自身却并不具有支付资质时，通常会强制要求用户在业务客户端上绑定在支付服务端(比如第三方支付平台)中开通的支付账户，并在业务客户端上通过绑定的支付账户来发放和领取红包。

请参见图1，图1为本说明书示出的一种红包领取方领取红包的示意图。

如图1所示，对于红包发放方而言，可以在业务客户端上通过绑定的支付账户，向红包领取方发放红包。而红包领取方在业务客户端上领取红包发放方发放的红包时，如果该红包领取方并未在业务客户端上绑定在第三方支付平台中开通的支付账户，此时业务服务端通常会通过该业务客户端上的用户界面，向红包领取方输出绑定在第三方支付平台上开通的支付账户的提示消息，来强制要求该红包领取方在业务客户端上绑定支付账户；

比如，如图1所示，以上述业务客户端为企业即时通信APP“dingtalk”，上述第三方支付平台为“alipay”为例，红包领取方在“dingtalk”中执行红包领取操作时，如果红包领取方并未在“dingtalk”上绑定在“alipay”中开通的支付账户，则可以在“dingtalk”的用户界面中显示一条“无法领取红包，请绑定支付宝账号”的文本提示。

在这种情况下，对于红包领取方而言，可以在上述提示消息的提示下，手动执行在业务客户端上绑定支付账号的操作，在完成以上绑定操作后，才能在业务客户端领取红包发放方发放的红包，并将领取的红包资金转入绑定的支付账户中。

本说明书在以上的技术方案的基础上，提出一种基于业务服务端存储的红包领取方的用户信息，在支付服务端为该红包领取方创建资金托管账户，来管理红包领取方领取的红包资金的技术方案。

在实现时，红包发放方可以在第一客户端上，通过与红包发放方登陆第一客户端时所使用的第一用户标识(比如登陆账号)绑定的支付账户，向红包领取方发放目标红包。红包领取方在第二业务客户端上领取红包发放方发放的目标红包时，可以通过业务服务端向支付服务端发送携带红包领取方登陆第二业务客户端时所使用的第二用户标识的红包领取请求；

而支付服务端在收到该红包领取请求后，可以确定该第二用户标识是否绑定了上述支付服务端中的支付账户；如果上述第二用户标识未绑定上述支付服务端中的支付账户，此时不再需要向红包领取方输出提示，来强制要求红包领取方在第二客户端上，将上述第二用户标识与该红包领取方在支付服务端上开通的支付账户进行绑定，而是可以将红包领取方领取到的红包资金，直接转入基于业务服务端上存储的红包领取方的用户信息，在支付服务端为该红包领取方创建的资金托管账户。

在以上技术方案中，一方面，由于支付服务端可以在确定红包领取方在登录业务客户端时所使用的用户标识未绑定支付服务端中的支付账户时，将红包领取方领取到的红包资金转入，根据业务服务端上存储的该红包领取方的用户信息，在支付服务端中为该红包领取方创建的资金托管账户中，而不再强制要求红包领取方在业务客户端上绑定支付账户；因此，可以降低红包资金的收款门槛，使得那些未在业务客户端上绑定支付账户的用户，也可以正常领取红包；

另一方面，由于红包领取方领取到的，由红包发放方通过业务客户端上绑定的支付账户发放的红包资金，最终仍然会回流至上述支付服务端上的资金托管账户；因此，可以实现支付服务端上的红包资金流的闭环，利于支付服务端的运营方更好的管理红包资金；而且，对于上述业务服务端的运营方而言，由于其可以不再需要自主的管理用户通过业务客户端领取到的红包资金；因此，也可以降低上述业务服务端的运营方的资金管理难度，节约资金管理成本。

请参见图2，图2是一示例性实施例提供的一种基于托管账户的红包领取方法的流程图。该方法应用于支付服务端，包括以下步骤：

步骤202，接收业务服务端发送的针对目标红包的红包领取请求；其中，所述红包领取请求包括，红包领取方登陆业务客户端时所使用的用户标识；

步骤204，响应于所述红包领取请求，确定所述用户标识是否绑定了所述支付服务端中的支付账户；

步骤206，如果所述用户标识未绑定所述支付服务端中的支付账户，将所述红包领取方领取到的红包资金转入与所述用户标识对应的资金托管账户；其中，所述资金托管账户为基于所述业务服务端上存储的所述红包领取方的用户信息，在所述支付服务端中为所述红包领取方创建的资金托管账户。

在本说明书中，上述业务服务端，具体可以包括不具备支付资质的服务提供商对应的服务平台；上述业务客户端，具体可以包括接入上述服务平台的客户端软件；比如，APP；而上述支付服务端，具体可以包括具有支付资质的金融机构或者第三方支付平台。

其中，需要说明的是，所谓支付资质，是指在一个国家或者独立的行政区域内从事支付业务的许可。如果一个金融机构或者非金融机构，取得了从事支付业务的许可，则可以认为该金融机构或者非金融机构，取得了在一个国家或者独立的行政区域内从事支付业务的许可。而对于无法取得支付资质的机构，则无法从事与支付相关的业务运营；比如，无法在开发的APP产品中搭载诸如红包发放等与支付相关的业务功能。

以下以上述支付服务端为第三方支付平台(以下简称支付平台)，上述业务服务端为不具备支付资质的服务提供商的服务平台(以下简称服务平台)，以及上述业务客户端为上述服务提供商开发的搭载了“红包”功能的APP(以下简称APP)为例，对本说明书的技术方案进行详细说明。

上述服务提供商开发的APP中，可以预先搭载红包功能；

其中，由于上述服务提供商，可能并不具备相关的支付资质；因此，在实现时，可以通过在开发的APP中搭载与第三方支付平台对应的支付SDK(Software Development Kit，软件开发工具包)，将上述第三方支付平台的支付功能，植入到该APP中。

从而，当用户在使用该APP发放红包时，该APP可以通过调用搭载的支付SDK，跳转到与支付SDK对应的支付APP，在该支付APP对应的支付界面中进行红包资金的支付操作，来完成红包的发放。

例如，以上述业务客户端为企业即时通信APP“dingtalk”，上述第三方支付平台为“alipay”为例，在实现时，可以通过在“dingtalk”中搭载“alipay”的支付SDK，当用户在“dingtalk”上执行红包发放的操作时，可以调用“alipay”的支付SDK，跳转到“alipay”的支付界面，进行红包资金的支付操作。

请参见图3，图3为本说明书示出一种在APP上绑定支付账户的交互图；

请参见图3，红包发放方在使用第一用户标识(比如，用户账号)登录APP后，可以在APP的用户界面中发起申请绑定支付账户的操作；例如，在实现时，可以在APP的用户界面中提供申请绑定支付账户的操作入口；比如，该操作入口可以是一个“绑定支付账户”的操作按钮；红包发放方可以通过触发该操作入口，来发起申请绑定支付账户的操作。

APP在检测到红包发放方发起的申请绑定支付账户的操作后，可以向上述服务平台发送支付账户绑定请求。上述服务平台在接收到上述支付账户绑定请求后，可以进一步调用上述支付平台上的绑定接口(API)，生成一个token凭证，并将生成的token凭证返回给APP；其中，生成的上述token凭证，具体为一个授权令牌，用于授权APP访问上述第三方支付平台中存储的上述红包发放方的用户信息。

请继续参见图3，APP在收到服务平台返回的token凭证后，可以基于该token来调用APP搭载的支付SDK，跳转到与该支付SDK对应的支付APP，由该支付APP继续与上述支付平台进行交互。

进一步的，在跳转到与该支付SDK对应的支付APP之后，该支付APP可以构建支付账户绑定请求，并将构建的支付账户绑定请求发送给上述支付平台。

需要说明的是，APP在调用搭载的支付SDK时，还可以将上述服务平台上存储的与上述第一用户标识对应的用户信息(即上述服务端平台上存储的上述红包发放方的用户信息)，作为调用参数传递给支付SDK；进而，上述支付APP构建的上述支付账户绑定请求中，也可以携带上述服务平台中存储的与上述第一用户标识对应的用户信息。

其中，在实际应用中，由于服务平台和支付平台之间，可能由于用户信息隔离导致跨平台之间无法共享用户信息；因此，APP传递给支付APP的上述红包发放方的用户信息，具体可以是针对红包发放方的用户信息进行摘要计算之后得到的一个数据摘要；比如，该数据摘要具体可以是基于hash算法对原始的用户信息进行计算后得到的hash值。

请继续参见图3，支付平台在收到支付APP发送的支付账户绑定请求后，首先验证该支付绑定请求中携带的上述服务平台中存储的与上述第一用户标识对应的用户信息，与上述支付平台中存储的与红包发放方在登录上述支付APP时所使用的第二用户标识对应的用户信息(即上述支付平台上存储的上述红包发放方的用户信息)是否匹配；

例如，以上述支付账户绑定请求携带上述服务平台中存储的与上述第一用户标识对应的用户信息的hash值为例，支付平台可以计算本地存储的与红包发放方在登录上述支付APP时所使用的第二用户标识对应的用户信息的hash值，然后进一步验证上述支付账户绑定请求中携带的hash值，与计算出的hash值是否匹配。

如果上述支付账户绑定请求中携带的用户信息，与本地存储的与上述第二用户标识对应的用户信息匹配，支付平台可以进一步向上述支付APP返回用户授权确认页面，由上述红包发放方进行授权确认。

请继续参见图3，当上述红包发放方在上述用户授权确认页面中进行了授权确认之后，上述支付APP可以基于上述红包发放方的授权确认信息来构建授权确认请求，并将该授权确认请求发送至上述支付平台。而上述支付平台在收到该授权确认请求后，可以将红包发放方在登录上述APP时所使用的第一用户标识，与该红包发放方当前登录上述支付APP时所使用的支付账户进行绑定，然后将绑定结果返回给上述支付APP向上述红包发放方进行展示。

当红包发放方通过上述绑定操作的过程，为红包发放方在登录上述APP时所使用的第一用户标识，绑定了在支付平台上开通的支付账户之后，该红包发放方可以在该APP中，通过调用该APP搭载的支付SDK，跳转到与支付SDK对应的支付APP中，在该支付APP对应的支付界面中，基于已经绑定的支付账户中进行红包资金的支付操作，来完成红包的发放。

其中，在已经绑定的支付账户中进行红包资金的支付的具体过程，在本说明书中不再进行详述。

请参见图4，图4为本说明书示出一种红包领取方在APP上领取红包的交互图；

请参见图4，红包领取方在使用第二用户标识登录APP后，可以在APP的用户界面中来查看红包发放方发放给该红包领取方的目标红包，并通过诸如点击红包等操作来领取该目标红包。

APP在检测到红包发放方发起的领取红包的操作后，可以向上述服务平台发送红包领取请求。上述服务平台在接收到上述红包领取请求后，可以基于该红包领取请求中携带的信息，进一步构建发往支付平台的红包领取请求，并将构建的红包领取请求发送至支付平台，来进一步调用上述支付平台上的红包领取接口(API)，完成红包的领取。

其中，在构建的红包领取请求中，可以包括红包领取方在登陆APP时所使用的第二用户标识。

请继续参见图4，支付平台在收到服务平台发送的上述红包领取请求后，首先可以确定该红包领取请求中的第二用户标识，是否绑定了上述红包领取方在上述支付平台中开通的支付账户；

如果上述第二用户标识已经绑定了在上述支付平台中开通的支付账户，此时可以将红包领取方领取到的红包资金，直接转入与该第二用户标识绑定的支付账户中即可。

如果上述第二用户标识未绑定在上述支付平台中开通的支付账户，此时支付平台可以不再需要向红包领取方输出提示，来强制要求红包领取方在APP上，将上述第二用户标识与该红包领取方在支付平台上开通的支付账户进行绑定，而是可以将该红包领取方领取到的红包资金，直接转入与该第二用户标识对应的资金托管账户。

在本说明书，上述资金托管账户，用于在红包领取方未在APP中绑定支付账户时，临时“托管”红包领取方领取到的红包资金。该资金托管账户，具体可以是根据上述服务平台上存储的红包领取方的用户信息，在上述支付平台中为该红包领取方创建的资金托管账户。也即，上述资金托管账户具体是指，根据红包领取方在上述服务平台中的用户信息，在上述支付平台中为该红包领取方开通的资金托管账户。

其中，需要说明的是，上述资金托管账户，具体可以在上述红包领取方在领取上述目标红包之前就预先创建，也可以在上述红包领取方在领取上述目标红包的过程中实时创建，在本说明书中不进行特别限定。

在示出的一种实施方式中，可以在上述红包领取方向上述服务平台发起APP账号注册的阶段；或者，也可以在上述红包领取方成功注册APP账号并首次登陆上述APP时，由上述服务端平台与上述支付平台进行消息交互，来为上述红包领取方创建资金托管账户。

在这种情况下，上述红包领取方在成功注册上述APP后，或者在首次登陆上述APP时，上述服务平台可以基于本地存储的上述红包领取方的用户信息来构建资金托管账户创建请求，并将该资金托管账户创建请求发送至支付平台，来进一步调用上述支付平台上的账户创建接口(API)，完成资金托管账户的创建；其中，在该资金托管账户创建请求中，可以包括该红包领取方在登录上述APP时所使用的第二用户标识。

而上述支付平台在收到该资金托管账户创建请求后，可以基于上述服务平台中存储的与该资金托管账户创建请求中携带的第二用户标识对应的用户信息，为上述红包领取方创建资金托管账户，在本地保存该资金托管账户与上述第二用户标识之间的对应关系，并将创建的资金托管账户的相关信息返回给上述服务平台，再由上述服务平台将该资金托管账户的相关信息返回给上述APP向红包领取方进行展示。

当然，除了由上述服务端平台与上述支付平台进行消息交互，来为上述红包领取方创建资金托管账户以外，在实际应用中，也可以通过在上述APP中提供用于触发开通资金托管账户的操作入口；比如，该操作入口可以是一个“开通资金托管账户”的操作按钮；红包领取方可以通过触发该操作入口，来手动开通资金托管账户，具体的开通资金托管账户的交互过程，不再赘述。

在示出的另一种实施方式中，也可以在上述红包领取方在领取上述目标红包的过程中，由上述支付平台来实时的为该红包领取方创建资金托管账户。

在这种情况下，上述服务平台可以将构建的红包领取请求发送至上述支付平台，来分别调用上述支付平台上的红包领取接口和账户创建接口(API)；当支付平台收到服务平台发送的上述红包领取请求，首先可以确定该红包领取请求中的第二用户标识，是否绑定上述红包领取方在上述支付平台中开通的支付账户；如果上述第二用户标识，未绑定上述红包领取方在上述支付平台中开通的支付账户，则可以进一步基于上述服务平台中存储的与该资金托管账户创建请求中携带的第二用户标识对应的用户信息，实时为上述红包领取方创建资金托管账户。

在示出的一种实施方式中，上述支付平台在为上述红包领取方创建资金托管账户时，首先可以获取服务平台存储的与上述第二用户标识对应的用户信息；其中，由于服务平台和支付平台之间，可能由于用户信息隔离导致跨平台之间无法共享用户信息；因此，上述支付平台获取到的，具体可以是服务平台存储的与上述第二用户标识对应的用户信息的数据摘要(比如hash值)。

例如，在实现时，服务平台可以将其本地存储的与上述第二用于标识对应的用户信息的数据摘要，携带在发给上述支付平台的资金托管账户创建请求或者红包领取请求中，主动发送给上述支付平台；

或者，支付平台也可以基于收到的资金托管账户创建请求或者红包领取请求中的上述第二用户标识，进一步向上述服务平台查询与该第二用户标识对应的用户信息的数据摘要；

然后，支付平台可以进一步计算本地存储的与上述第二用户标识对应的用户信息的数据摘要，然后将计算出的数据摘要，与获取到的服务平台存储的与上述第二用户标识对应的用户信息的数据摘要进行匹配；

如果二者匹配，支付平台可以进一步为该红包领取方创建资金托管账户，在本地保存该资金托管账户与上述第二用户标识之间的对象关系，然后可以立即将红包领取方领取的红包资金转入实时创建的该资金托管账户。

在本说明书中，当支付平台将红包领取方领取的红包资金转入上述红包领取方的资金托管账户之后，还可以向上述服务平台返回一个红包资金已经转入资金托管账户的提示消息，再由上述服务平台将该提示消息返回给上述APP向红包领取方进行展示。

请参见图5，图5为本说明书示出的另一种红包领取方领取红包的示意图。

如图5所示，以上述APP为企业即时通信“dingtalk”，上述第三方支付平台为“alipay”为例，红包领取方在“dingtalk”中执行红包领取操作时，如果红包领取方并未在“dingtalk”上绑定在“alipay”中开通的支付账户，则可以直接将红包领取方领取的红包资金转入为该红包领取方创建的资金托管账户，并通过上述服务平台向“dingtalk”返回一条“领取成功，资金已转入托管账户”的文本提示。

在本说明书中，当将红包领取方领取到的红包资金转入与上述第二用户标识对应的资金托管账户之后，支付平台还可以在本地生成对应于该资金托管账户的红包领取记录。

而对于红包领取方而言，可以通过APP上提供的与红包领取记录对应的查看入口，来查看红包领取记录。APP在检测到红包领取方发起的针对红包领取记录的查看请求后，可以向上述服务平台发送红包记录查看请求。上述服务平台在接收到上述红包记录查看请求后，可以基于该红包记录查看请求中携带的信息，进一步构建发往支付平台的红包记录查看请求，并将构建的红包记录查看请求发送至支付平台，来进一步调用上述支付平台上的账单查询接口(API)，完成红包领取记录的查看。

而支付平台在收到服务平台发送的红包领取记录后，可以响应该红包领取记录，将生成的对应于上述资金托管账户的红包领取记录返回给服务平台，再由该服务平台将该红包领取记录进一步返回给APP，向红包领取方进行展示。

在本说明书中，对于转入上述资金托管账户的红包资金，还可以由上述红包领取方来发起提现操作，将其转入到上述红包领取方在上述APP上绑定了在上述支付平台开通的支付账户之中。

例如，在实现时，可以在APP的用户界面中提供用于提现的操作入口；比如，该操作入口可以是一个“提现到支付账户”的操作按钮；红包领取方可以通过触发该操作入口，将已经领取至资金托管账户中的红包资金，提现至绑定的支付账户中。

其中，上述红包领取方在APP上绑定在上述支付平台开通的支付账户的具体过程，与以上描述的红包发放方在APP上绑定在上述支付平台开通的支付账户的具体过程相同，在本说明书中不再进行赘述。

APP在检测到红包领取方发起的提现操作后，可以向上述服务平台发送红包提现请求。上述服务平台在接收到上述红包提现请求后，可以基于该红包提现请求中携带的信息，进一步构建发往支付平台的红包提现请求，并将构建的红包提现请求发送至支付平台，来进一步调用上述支付平台上的红包提现接口(API)，完成红包的提现。

而支付平台在收到服务平台发送的红包提现请求后，可以响应该红包提现请求，将与上述第二用户标识对应的上述资金托管账户中的红包资金，转入与上述第二用户标识绑定的支付账户。

通过以上技术方案可见，一方面，由于支付平台可以在确定红包领取方在登录APP时所使用的用户标识未绑定支付平台中的支付账户时，将红包领取方领取到的红包资金转入，根据服务平台上存储的该红包领取方的用户信息，在支付平台中为该红包领取方创建的资金托管账户中，而不再强制要求红包领取方在APP上绑定支付账户；因此，可以降低红包资金的收款门槛，使得那些未在APP上绑定支付账户的用户，也可以正常领取红包；

另一方面，由于红包领取方领取到的，由红包发放方通过APP上绑定的支付账户发放的红包资金，最终仍然会回流至上述支付平台上的资金托管账户；因此，可以实现支付平台上的红包资金流的闭环，利于支付平台的运营方更好的管理红包资金；而且，对于上述服务平台的运营方而言，由于其可以不再需要自主的管理用户通过APP领取到的红包资金；因此，也可以降低上述APP的运营方的资金管理难度，节约资金管理成本。

与上述方法实施例相对应，本申请还提供了装置的实施例。

与上述方法实施例相对应，本说明书还提供了一种基于托管账户的红包领取装置的实施例。本说明书的基于托管账户的红包领取装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图6所示，为本说明书的基于托管账户的红包领取装置所在电子设备的一种硬件结构图，除了图6所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的电子设备通常根据该电子设备的实际功能，还可以包括其他硬件，对此不再赘述。

图7是本说明书一示例性实施例示出的一种基于托管账户的红包领取装置的框图。

请参考图7，所述基于托管账户的红包领取装置70可以应用在前述图6所示的电子设备中，包括：

接收模块701，接收业务服务端发送的针对目标红包的红包领取请求；其中，所述红包领取请求包括，红包领取方登陆业务客户端时所使用的用户标识；

确定模块702，响应于所述红包领取请求，确定所述用户标识是否绑定了所述支付服务端中的支付账户；

转入模块703，如果所述用户标识未绑定所述支付服务端中的支付账户，将所述红包领取方领取到的红包资金转入与所述用户标识对应的资金托管账户；

其中，所述资金托管账户为基于所述业务服务端上存储的所述红包领取方的用户信息，在所述支付服务端中为所述红包领取方创建的资金托管账户。

在本实施例中，所述转入模块703：

如果所述用户标识未绑定所述支付服务端中的支付账户，进一步确定所述支付服务端中是否存在与所述用户标识对应的资金托管账户；

如果所述支付服务端中存在与所述用户标识对应的资金托管账户，将所述红包领取方领取到的红包资金转入所述资金托管账户；

如果所述支付服务端中不存在与所述用户标识对应的资金托管账户，基于所述业务服务端上存储的与所述用户标识对应的用户信息，为所述红包领取方创建资金托管账户，并将所述红包领取方领取到的红包资金转入创建的资金托管账户。

在本实施例中，所述接收模块701进一步：

在接收业务服务端发送的红包领取请求之前，接收业务服务端发送的资金托管账户创建请求；其中，所述创建请求中包括红包领取方登陆所述业务客户端时所使用的用户标识；

所述装置70还包括：

创建模块704(图7中未示出)，基于所述业务服务端存储的与所述用户标识对应的用户信息，为所述红包领取方创建资金托管账户。

在本实施例中，所述转入模块703或者所述创建模块704进一步：

获取业务服务端存储的与所述用户标识对应的用户信息的第一数据摘要；计算本地存储的与所述用户标识对应的用户信息的第二数据摘要；验证所述第一数据摘要与所述第二数据摘要是否匹配；如果是，为所述红包领取方创建资金托管账户，并在本地保存所述用户标识与所述资金托管账户的对应关系。

在本实施例中，所述接收模块701进一步：

接收业务服务端发送的红包提现请求；其中，所述红包提现请求包括红包领取方登陆所述业务客户端时所使用的用户标识；

所述转入模块703进一步：

响应于所述红包提现请求，将与所述用户标识对应的所述资金托管账户中的红包资金，转入与所述用户标识绑定的支付账户。

在本实施例中，所述转入模块703进一步：

将所述红包领取方领取到的红包资金转入与所述用户标识对应的资金托管账户之后，生成对应于所述资金托管账户的红包领取记录；

所述装置70还包括：

返回模块705(图7中未示出)，响应于接收到的所述业务服务端发送的针对所述资金托管账户的红包记录查看请求，将生成的对应于所述资金托管账户的红包领取记录返回给所述业务服务端，以由所述业务服务端将所述红包领取记录，进一步返回所述业务客户端。

在本实施例中，所述支付服务端为第三方支付平台；所述业务服务端为不具备支付资质的服务提供商对应的服务平台；所述业务客户端为接入所述服务平台的客户端软件。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (16)

1.一种基于托管账户的红包领取方法，包括：

接收业务服务端发送的针对目标红包的红包领取请求；其中，所述红包领取请求包括，红包领取方登陆业务客户端时所使用的用户标识；

响应于所述红包领取请求，确定所述用户标识是否绑定了支付服务端中的支付账户；

如果所述用户标识未绑定所述支付服务端中的支付账户，则为所述红包领取方创建资金托管账户，并将所述红包领取方领取到的红包资金转入与所述用户标识对应的资金托管账户；

其中，所述资金托管账户为基于所述业务服务端上存储的所述红包领取方的用户信息，在所述支付服务端中为所述红包领取方创建的资金托管账户。

2.根据权利要求1所述的方法，如果所述用户标识未绑定所述支付服务端中的支付账户，则为所述红包领取方创建资金托管账户，并将所述红包领取方领取到的红包资金转入与所述用户标识对应的资金托管账户，包括：

如果所述用户标识未绑定所述支付服务端中的支付账户，进一步确定所述支付服务端中是否存在与所述用户标识对应的资金托管账户；

如果所述支付服务端中不存在与所述用户标识对应的资金托管账户，基于所述业务服务端存储的与所述用户标识对应的用户信息，为所述红包领取方创建资金托管账户，并将所述红包领取方领取到的红包资金转入创建的资金托管账户。

3.根据权利要求1所述的方法，接收业务服务端发送的红包领取请求之前，还包括：

接收业务服务端发送的资金托管账户创建请求；其中，所述创建请求中包括红包领取方登陆所述业务客户端时所使用的用户标识；

基于所述业务服务端存储的与所述用户标识对应的用户信息，为所述红包领取方创建资金托管账户。

4.根据权利要求2或3所述的方法，基于所述业务服务端存储的与所述用户标识对应的用户信息，为所述红包领取方创建资金托管账户，包括：

获取业务服务端存储的与所述用户标识对应的用户信息的第一数据摘要；

计算本地存储的与所述用户标识对应的用户信息的第二数据摘要；

验证所述第一数据摘要与所述第二数据摘要是否匹配；如果是，为所述红包领取方创建资金托管账户，并在本地保存所述用户标识与所述资金托管账户的对应关系。

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

接收业务服务端发送的红包提现请求；其中，所述红包提现请求包括红包领取方登陆所述业务客户端时所使用的用户标识；

响应于所述红包提现请求，将与所述用户标识对应的所述资金托管账户中的红包资金，转入与所述用户标识绑定的支付账户。

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

将所述红包领取方领取到的红包资金转入与所述用户标识对应的资金托管账户之后，生成对应于所述资金托管账户的红包领取记录；以及，

响应于接收到的所述业务服务端发送的针对所述资金托管账户的红包记录查看请求，将生成的对应于所述资金托管账户的红包领取记录返回给所述业务服务端，以由所述业务服务端将所述红包领取记录，进一步返回给所述业务客户端。

7.根据权利要求1所述的方法，所述支付服务端为第三方支付平台；所述业务服务端为不具备支付资质的服务提供商对应的服务平台；所述业务客户端为接入所述服务平台的客户端软件。

8.一种基于托管账户的红包领取装置，包括：

接收模块，接收业务服务端发送的针对目标红包的红包领取请求；其中，所述红包领取请求包括，红包领取方登陆业务客户端时所使用的用户标识；

确定模块，响应于所述红包领取请求，确定所述用户标识是否绑定了支付服务端中的支付账户；

转入模块，如果所述用户标识未绑定所述支付服务端中的支付账户，则为所述红包领取方创建资金托管账户，并将所述红包领取方领取到的红包资金转入与所述用户标识对应的资金托管账户；

其中，所述资金托管账户为基于所述业务服务端上存储的所述红包领取方的用户信息，在所述支付服务端中为所述红包领取方创建的资金托管账户。

9.根据权利要求8所述的装置，所述转入模块：

如果所述用户标识未绑定所述支付服务端中的支付账户，进一步确定所述支付服务端中是否存在与所述用户标识对应的资金托管账户；

如果所述支付服务端中不存在与所述用户标识对应的资金托管账户，基于所述业务服务端上存储的与所述用户标识对应的用户信息，为所述红包领取方创建资金托管账户，并将所述红包领取方领取到的红包资金转入创建的资金托管账户。

10.根据权利要求8所述的装置，所述接收模块进一步：

在接收业务服务端发送的红包领取请求之前，接收业务服务端发送的资金托管账户创建请求；其中，所述创建请求中包括红包领取方登陆所述业务客户端时所使用的用户标识；

所述装置还包括：

创建模块，基于所述业务服务端存储的与所述用户标识对应的用户信息，为所述红包领取方创建资金托管账户。

11.根据权利要求10所述的装置，所述转入模块或者所述创建模块进一步：

获取业务服务端存储的与所述用户标识对应的用户信息的第一数据摘要；计算本地存储的与所述用户标识对应的用户信息的第二数据摘要；验证所述第一数据摘要与所述第二数据摘要是否匹配；如果是，为所述红包领取方创建资金托管账户，并在本地保存所述用户标识与所述资金托管账户的对应关系。

12.根据权利要求8所述的装置，所述接收模块进一步：

接收业务服务端发送的红包提现请求；其中，所述红包提现请求包括红包领取方登陆所述业务客户端时所使用的用户标识；

所述转入模块进一步：

响应于所述红包提现请求，将与所述用户标识对应的所述资金托管账户中的红包资金，转入与所述用户标识绑定的支付账户。

13.根据权利要求8所述的装置，所述转入模块进一步：

将所述红包领取方领取到的红包资金转入与所述用户标识对应的资金托管账户之后，生成对应于所述资金托管账户的红包领取记录；

所述装置还包括：

返回模块，响应于接收到的所述业务服务端发送的针对所述资金托管账户的红包记录查看请求，将生成的对应于所述资金托管账户的红包领取记录返回给所述业务服务端，以由所述业务服务端将所述红包领取记录，进一步返回给所述业务客户端。

14.根据权利要求8所述的装置，所述支付服务端为第三方支付平台；所述业务服务端为不具备支付资质的服务提供商对应的服务平台；所述业务客户端为接入所述服务平台的客户端软件。

15.一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器通过运行所述可执行指令以实现如权利要求1-7中任一项所述的方法。

16.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，该指令被处理器执行时实现如权利要求1-7中任一项所述方法的步骤。