一种支付方法及计算机存储介质

摘要

本发明实施例提供一种支付方法及计算机存储介质，其中，支付方法包含：接收用户在第一账号的内容页面中触发的订单创建指令；获取与订单创建指令对应的订单信息以及支付配置信息；根据支付配置信息，确定与第一账号关联的第二账号，其中，第一账号和第二账号为同一公众平台中的账号；将订单信息发送至第二账号，并获取第二账号根据订单信息生成的订单支付页面；接收用户在订单支付页面中触发的支付指令，执行支付指令对应的支付操作。通过本发明实施例，可降低同一公众平台中账号认证成为支付商户的手续繁琐程度，以及便于运营者对多个第一账号的交易数据统一管理。

权利要求

1.一种支付方法，其特征在于，包含：接收用户在第一账号的内容页面中触发的订单创建指令；

获取与所述订单创建指令对应的订单信息以及支付配置信息，所述支付配置信息包含所述第一账号和第二账号之间的切换逻辑信息；

根据所述支付配置信息，确定与所述第一账号关联的所述第二账号，其中，所述第一账号和所述第二账号为同一公众平台中的账号，所述第一账号至少有两个，且，所述第一账号为运营者为实现实物或者虚拟商品销售的需求，在公众平台上所申请的账号，所述第二账号为运营者为实现用户商品订单生成及对订单进行收款的需求，在公众平台上所申请的账号；

将所述订单信息发送至所述第二账号，并获取所述第二账号根据所述订单信息生成的订单支付页面；

接收所述用户在所述订单支付页面中触发的支付指令，执行所述支付指令对应的支付操作。

2.根据权利要求1所述的方法，其特征在于，在所述接收用户在第一账号的内容页面中触发的订单创建指令的步骤之前，还包含：根据首次接收的所述用户对所述第一账号的内容页面的获取指令，获取用于标识所述第一账号的第一属性信息，以及所述第一账号中用于标识所述用户的第一用户信息；

根据所述第一属性信息，将所述第一用户信息发送至所述第一账号，并接收所述第一账号返回的根据所述第一用户信息生成的所述内容页面。

3.根据权利要求2所述的方法，其特征在于，所述根据首次接收的所述用户对所述第一账号的内容页面的获取指令，获取用于标识所述第一账号的第一属性信息，以及所述第一账号中用于标识所述用户的第一用户信息的步骤包含：根据首次接收的所述用户对所述第一账号的内容页面的获取指令，获取所述第一属性信息；

判断用户终端中是否存储与所述第一属性信息对应的所述第一用户信息；

如果是，则从所述用户终端中获取所述第一用户信息；

如果否，则根据所述第一属性信息从所述公众平台的服务器获取所述第一用户信息，并将所述第一属性信息和所述第一用户信息存储至所述用户终端。

4.根据权利要求3所述的方法，其特征在于，所述根据所述第一属性信息从所述公众平台的服务器获取所述第一用户信息的步骤包含：获取所述用户对所述第一账号的第一授权信息，并将所述第一授权信息和所述第一属性信息发送至所述公众平台的服务器；

接收所述公众平台的服务器根据所述第一授权信息和所述第一属性信息所返回的所述第一用户信息。

5.根据权利要求4所述的方法，其特征在于，所述第一授权信息通过对所述第一账号进行强制授权或静默授权生成。

6.根据权利要求1所述的方法，其特征在于，所述将所述订单信息发送至所述第二账号，并获取所述第二账号根据所述订单信息生成的订单支付页面的步骤包含：获取所述第二账号中用于标识所述用户的第二用户信息，并将所述订单信息和所述第二用户信息发送至所述第二账号；

获取所述第二账号所返回的所述订单支付页面，其中，所述订单支付页面由所述第二账号根据所述订单信息和所述第二用户信息所生成。

7.根据权利要求6所述的方法，其特征在于，所述获取所述第二账号中用于标识所述用户的第二用户信息的步骤包含：

根据所述支付配置信息，获取用于标识所述第二账号的第二属性信息；

判断用户终端中是否存储与所述第二属性信息对应的所述第二用户信息；

如果是，则从所述用户终端中获取所述第二用户信息；

如果否，则根据所述第二属性信息从所述公众平台的服务器获取所述第二用户信息，并将所述第二属性信息和所述第二用户信息存储至所述用户终端。

8.根据权利要求7所述的方法，其特征在于，所述根据所述第二属性信息从所述公众平台的服务器获取所述第二用户信息的步骤包含：获取所述用户对所述第二账号的第二授权信息，并将所述第二授权信息和所述第二属性信息发送至所述公众平台的服务器；

接收所述公众平台的服务器根据所述第二授权信息和所述第二属性信息所返回的所述第二用户信息。

9.根据权利要求8所述的方法，其特征在于，所述第二授权信息通过对所述第二账号进行强制授权或静默授权生成。

10.根据权利要求1所述的方法，其特征在于，在所述接收所述用户在所述订单支付页面中触发的支付指令，执行所述支付指令对应的支付操作的步骤之后，还包含：接收所述支付操作对应的支付状态通知，并根据所述支付状态通知判断是否支付成功；

如果是，则根据所述支付配置信息返回并刷新所述第一账号的内容页面。

11.一种计算机存储介质，其特征在于，所述计算机存储介质中存储有：用于接收用户在第一账号的内容页面中触发的订单创建指令，并获取与所述订单创建指令对应的订单信息以及支付配置信息的指令，所述支付配置信息包含所述第一账号和第二账号之间的切换逻辑信息；

用于根据所述支付配置信息，确定与所述第一账号关联的所述第二账号的指令，其中，所述第一账号和所述第二账号为同一公众平台中的账号，所述第一账号至少有两个，且，所述第一账号为运营者为实现实物或者虚拟商品销售的需求，在公众平台上所申请的账号，所述第二账号为运营者为实现用户商品订单生成及对订单进行收款的需求，在公众平台上所申请的账号；

用于将所述订单信息发送至所述第二账号，并获取所述第二账号根据所述订单信息生成的订单支付页面的指令；

用于接收所述用户在所述订单支付页面中触发的支付指令，执行所述支付指令对应的支付操作的指令。

说明书

一种支付方法及计算机存储介质

技术领域

[0001] 本发明实施例涉及计算机技术领域，尤其涉及一种支付方法及计算机存储介质。

背景技术

[0002] 随着计算机和互联网技术的发展，社交类应用系统可以为运营者提供公众平台，如微信公众平台、易信公众平台、来往公众平台、人人网公众平台等。运营者可在公众平台
中申请一个或者多个账号，社交类应用中的普通用户便可关注该账号，或者与该账号成为
好友关系。之后，普通用户和账号运营者可以以社交类应用为媒介，进行文本、图片、语音、
视频等信息交互。

[0003] 以微信公众平台为例，微信公众平台为公众账号运营者提供了基于微信内的网页开发工具包(微信JS‑SDK)，公众账号运营者通过微信JS‑SDK使用微信原生功能，例如微信
支付功能。对于有出售商品需求的公众账号运营者，可通过自定义菜单、关键字回复等方式
向订阅用户推送商品消息，订阅用户可在公众号中完成选购和支付的流程。

[0004] 在实现本发明过程中，发明人发现现有技术中至少存在如下问题：为实现完整的交易功能，公众账号运营者需要通过相关认证成为公众账号支付商户，然后处理交易逻辑。
如果同一运营者拥有多个需要与用户实现交易功能账号的话，针对每个公众账号分别申请
公众账号支付商户不仅手续较为繁琐，而且为每个公众账号独立处理交易逻辑的工作量巨
大，还不利于对交易数据的统一管理。

发明内容

[0005] 有鉴于此，本发明实施例所解决的技术问题之一在于提供一种支付方法及计算机存储介质，用以克服现有技术中的同一运营者多个公众账号实现交易功能手续繁琐、后台
处理工作量大和不便于交易数据统一管理的问题。

[0006] 根据本发明实施例的一个方面，提供了一种支付方法，包含：接收用户在第一账号的内容页面中触发的订单创建指令；获取与所述订单创建指令对应的订单信息以及支付配
置信息；根据所述支付配置信息，确定与所述第一账号关联的第二账号，其中，所述第一账
号和所述第二账号为同一公众平台中的账号；将所述订单信息发送至所述第二账号，并获
取所述第二账号根据所述订单信息生成的订单支付页面；接收所述用户在所述订单支付页
面中触发的支付指令，执行所述支付指令对应的支付操作。

[0007] 根据本发明实施例的另一个方面，还提供了一种计算机存储介质，所述计算机存储介质中存储有：

[0008] 用于接收用户在第一账号的内容页面中触发的订单创建指令，并获取与所述订单创建指令对应的订单信息以及支付配置信息的指令；

[0009] 用于根据所述支付配置信息，确定与所述第一账号关联的第二账号的指令，其中，所述第一账号和所述第二账号为同一公众平台中的账号；

[0010] 用于将所述订单信息发送至所述第二账号，并获取所述第二账号根据所述订单信息生成的订单支付页面的指令；

[0011] 用于接收所述用户在所述订单支付页面中触发的支付指令，执行所述支付指令对应的支付操作的指令。

[0012] 根据本发明实施例提供的支付方案，可以使运营者在同一公众平台中申请多个有实物或者虚拟商品出售需求的第一账号，只需申请一个认证成为支付商户的第二账号，将
用户在第一账号中希望创建的订单转至第二账号中去处理，从而降低了账号认证成为支付
商户的手续繁琐程度，以及便于运营者对多个第一账号的交易数据统一管理。

附图说明

[0013] 为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本
发明实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获
取其他的附图。

[0014] 图1示出了本发明的实施例一的支付方法的流程图；

[0015] 图2示出了本发明的实施例二的支付方法的流程图。

具体实施方式

[0016] 当然，实施本发明实施例的任一技术方案必不一定需要同时达到以上的所有优点。

[0017] 为了使本领域的人员更好地理解本发明实施例中的技术方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实
施例仅是本发明实施例一部分实施例，而不是全部的实施例。基于本发明实施例中的实施
例，本领域普通技术人员所获取的所有其他实施例，都应当属于本发明实施例保护的范围。

[0018] 下面结合本发明实施例附图进一步说明本发明实施例具体实现。

[0019] 实施例一

[0020] 图1示出了本发明的实施例一的支付方法的流程图。如图1所示，本发明的实施例一的支付方法包含以下步骤：

[0021] 步骤S101，接收用户在第一账号的内容页面中触发的订单创建指令。

[0022] 本实施例中，第一账号为运营者为实现实物或者虚拟商品销售的需求，在公众平台上所申请的账号。运营者可通过第一账号的内容页面向用户进行商品展示，展示的内容
包含但不限于商品的名称、价格、介绍、评价、销量等信息。

[0023] 当用户需要购买内容页面中展示的商品时，可以通过内容页面中提供的相应设置触发订单创建指令，以实现商品的购买操作。本实施例中，订单创建指令的触发方式不限，
例如可通过点击内容页面中的按钮进行触发，也可通过语音、面部表情或肢体动作进行触
发。

[0024] 步骤S102，获取与订单创建指令对应的订单信息以及支付配置信息。

[0025] 本实施例中，订单信息至少包含用户计划购买商品的商品标识信息，还可包含商品数量信息、商品价格信息、用户地址信息、用户联系方式信息中的至少其一。

[0026] 步骤S103，根据支付配置信息，确定与第一账号关联的第二账号，其中，第一账号和第二账号为同一公众平台中的账号。

[0027] 本实施例中，支付配置信息由第一账号的运营者所设定，用于确定与第一账号关联的第二账号，使得用户在第一账号的内容页面或者第二账号的订单支付页面中触发操作
指令时，第一账号和/或第二账号可执行与所触发操作指令对应的操作。

[0028] 具体的，支付配置信息可包含第一账号和第二账号之间的切换逻辑信息，切换逻辑信息用于确定用户在第一账号指令和页面之间的对应关系。

[0029] 本实施例中，第二账号为运营者为实现用户商品订单生成及对订单进行收款的需求，在公众平台上所申请的账号。为了让用户在第二账号中可进行支付，运营者需要在工作
平台上将第二账号认证成为支付商户。

[0030] 具体的，运营者可在同一公众平台中申请至少两个第一账号，申请一个第二账号并将第二账号认证成为支付商户，通过设置支付配置信息，将至少两个第一账号与一个第
二账号进行关联。当用户希望购买第一账号中所展示的商品时，即在第一账号的内容页面
中触发的订单创建指令后，可以根据支付配置信息确定与第一账号关联的第二账号，从而
让用户从第一账号跳转至第二账号，以完成后续的订单创建及对订单的支付操作。

[0031] 步骤S104，将订单信息发送至第二账号，并获取第二账号根据订单信息生成的订单支付页面。

[0032] 本实施例中，可将订单信息发送至第二账号，并接收第二账号所返回的根据商品标识信息生成订单支付页面。订单信息为用户与第一账号生成交易订单所需的全部或者部
分信息，用户可在订单支付页面中对生成交易订单所需的信息进行调整或者补充。

[0033] 例如，可仅将商品标识信息发送至第二账号，第二账号可根据商品标识信息与商品价格信息的对照表，获得商品价格信息，并生成包含商品标识信息和价格信息的订单支
付页面，从而可接收用户在订单支付页面中对商品数量、用户地址信息、用户联系方式等信
息的调整操作。

[0034] 步骤S105，接收用户在订单支付页面中触发的支付指令，执行支付指令对应的支付操作。

[0035] 本实施例中，当用户完成交易订单所需的全部信息确认后，需要通过支付指令对订单进行支付操作，第二账号可根据支付指令调用支付平台的支付功能供用户完成支付操
作，例如当第二账号为微信公众平台的账号时，第二账号可调用微信支付的页面供用户完
成支付操作。

[0036] 由以上本发明实施例可见，本发明首先接收用户在第一账号的内容页面中触发的订单创建指令，获取与订单创建指令对应的订单信息以及支付配置信息；然后根据支付配
置信息确定与第一账号关联的第二账号，将订单信息发送至第二账号，并获取第二账号根
据订单信息生成的订单支付页面；从而接收用户在订单支付页面中触发的支付指令，执行
支付指令对应的支付操作。因此，本发明实施例可以使运营者在同一公众平台中申请多个
有实物或者虚拟商品出售需求的第一账号，只需申请一个认证成为支付商户的第二账号，
将用户在第一账号中希望创建的订单转至第二账号中去处理，从而降低了账号认证成为支
付商户的手续繁琐程度，以及便于运营者对多个第一账号的交易数据统一管理。

[0037] 实施例二

[0038] 图2示出了本发明的实施例二的支付方法的流程图。如图2所示，本发明的实施例二的支付方法包含以下步骤：

[0039] 步骤S201，根据首次接收的用户对第一账号的内容页面的获取指令，获取用于标识所述第一账号的第一属性信息，以及第一账号中用于标识用户的第一用户信息。

[0040] 本实施例中，由于第一账号可能会包含多个内容页面，用户可能会发送多个获取指令以获取不同的内容页面，为了尽快识别出用户，可在首次接收到用户对第一账号的内
容页面的获取指令后，便获取用于标识所述第一账号的第一属性信息，以及第一账号中用
于标识用户的第一用户信息。

[0041] 本实施例中，为对在公众平台上所申请的账号进行区分，公众平台会对每个账号进行标识，例如，使用“APPID”字段对每个账号进行唯一的标识，同一公众平台中的第一账
号和第二账号有不同的APPID，第一账号的第一属性信息中会包含第一账号的APPID。

[0042] 为了识别社交类应用系统中的不同用户，公众平台会对每个用户进行标识，例如，使用“UnionID”字段在公众平台中为每个用户进行唯一的标识；同时，在公众平台上所申请
的账号也会对每个用户进行唯一的标识，例如，第一账号利用“OpenID”字段为每个用户进
行唯一的标识。

[0043] 如果运营者需要实现多个账号间的用户信息共通，可在公众平台上对多个账号进行绑定。绑定后，一个用户虽然对多个账号有多个不同的OpenID，但UnionID是相同的。例
如，将第一账号和第二账号进行绑定后，第一账号和第二账号对同一用户进行标识的
OpenID不同，但是UnionID相同。

[0044] 第一账号中用于标识用户的第一用户信息至少包含用户的OpenID和UnionID，还可包含昵称、性别、地址等其他信息。

[0045] 本实施例中，步骤S201可包含步骤S201a～S201d，其中：

[0046] 步骤S201a，根据首次接收的用户对第一账号的内容页面的获取指令，获取第一属性信息。

[0047] 步骤S201b，判断用户终端中是否存储与第一属性信息对应的第一用户信息。

[0048] 具体的，如果用户在用户终端上使用社交类应用系统的客户端访问过公众平台某一账号的相关页面，该账号可通过相应的授权机制来获取用户信息，账号获取的全部或者
部分用户信息也会被保存至用户终端。因此，为了快速获取与第一属性信息对应的第一用
户信息，提高用户体验，可首先查找用户终端中是否存储了与第一属性信息对应的第一用
户信息。

[0049] 例如，如果用户在用户终端上访问过第一账号的内容页面，并且对第一账号进行了授权，则会在用户终端的cookie中将第一属性信息中所包含的APPID，以及第一用户信息
中所包含的OpenID和UnionID进行关联保存。因此，当获取了第一属性信息中APPID后，可利
用APPID在用户终端中查找第一用户信息中所包含的OpenID和UnionID。

[0050] 步骤S201c，如果是，则从用户终端中获取第一用户信息。

[0051] 步骤S201d，如果否，则根据第一属性信息从公众平台的服务器获取第一用户信息，并将第一属性信息和第一用户信息存储至用户终端。

[0052] 具体的，公众平台的服务器可以是一台服务器，或者由若干台服务器组成的服务器集群，或者是一个云计算服务中心。

[0053] 具体的，当用户终端中未存储与第一属性信息对应的第一用户信息时，可向第一账号发送用户信息请求，由第一账号根据用户信息请求向公众平台的服务器请求获取第一
用户信息，并接收第一账号或公众平台的服务器所返回的第一用户信息，将第一属性信息
和第一用户信息存储至用户终端。

[0054] 具体的，对第一属性信息进行存储时，至少包含公众平台对第一账号的唯一标识，例如APPID；对第一用户信息进行存储时，至少包含公众平台中为用户进行唯一的标识和第
一账号为用户进行的唯一标识，例如OpenID和UnionID。

[0055] 具体的，为提高安全性，还包含将第一属性信息和/或第一用户信息进行加密后存储至用户终端。其中，对第一属性信息、第一用户信息进行加密时，可使用不同的加密方法
和加密字段标识。

[0056] 本实施例中，步骤S201d可包含步骤S1和步骤S2，其中：

[0057] 步骤S1，获取用户对第一账号的第一授权信息，并将第一授权信息和第一属性信息发送至公众平台的服务器。

[0058] 具体的，第一授权信息通过对第一账号进行强制授权或静默授权生成。其中，强制授权需要用户手动同意授权，静默授权无需用户手动同意授权。

[0059] 相比于静默授权，当第一授权信息是通过对第一账号进行强制授权生成时，公众平台的服务器根据第一授权信息和第一属性信息可返回的用户信息种类更多，并且有利于
提高用户对账号运营者的信任度，因此优选第一授权信息通过对第一账号进行强制授权生
成。

[0060] 步骤S2，接收公众平台的服务器根据第一授权信息和第一属性信息所返回的第一用户信息。

[0061] 步骤S202，根据第一属性信息，将第一用户信息发送至第一账号，并接收第一账号返回的根据第一用户信息生成的内容页面。

[0062] 具体的，将第一用户信息发送至第一账号后，第一账号不但可根据第一用户信息在生成的内容页面中标识出用户，还可为用户生成个性化的页面。例如，针对不同性别的用
户生成不同背景色的内容页面，或者推荐包含不同商品的内容页面。

[0063] 步骤S203，接收用户在第一账号的内容页面中触发的订单创建指令。

[0064] 步骤S204，获取与订单创建指令对应的订单信息以及支付配置信息。

[0065] 步骤S205，根据支付配置信息，确定与第一账号关联的第二账号，其中，第一账号和第二账号为同一公众平台中的账号。

[0066] 步骤S206，获取第二账号中用于标识用户的第二用户信息，并将订单信息和第二用户信息发送至第二账号。

[0067] 本实施例中，第二账号中用于标识用户的第二用户信息至少包含用户的OpenID和UnionID，还可包含昵称、性别、地址等其他信息。

[0068] 本实施例中，步骤S206可包含步骤S206a～S206d，其中：

[0069] 步骤S206a，根据支付配置信息，获取用于标识所述第二账号的第二属性信息。

[0070] 具体的，第二属性信息至少包含公众平台对第二账号的唯一标识，例如APPID。

[0071] 步骤S206b，判断用户终端中是否存储与第二属性信息对应的第二用户信息。

[0072] 与前述获取第一用户信息类似，为了快速获取与第二属性信息对应的第二用户信息，提高用户体验，可首先查找用户终端中是否存储了与第二属性信息对应的第二用户信
息。例如，利用APPID在用户终端中查找是否存储了第一用户信息中所包含的OpenID和
UnionID。

[0073] 步骤S206c，如果是，则从用户终端中获取第二用户信息。

[0074] 步骤S206d，如果否，则根据第二属性信息从公众平台的服务器获取第二用户信息，并将第二属性信息和第二用户信息存储至用户终端。

[0075] 具体的，当用户终端中未存储与第二属性信息对应的第二用户信息时，可向第二账号发送用户信息请求，由第二账号根据用户信息请求向公众平台的服务器请求获取第二
用户信息，并接收第二账号或公众平台的服务器所返回的第二用户信息，将第二属性信息
和第二用户信息存储至用户终端。

[0076] 具体的，对第二属性信息进行存储时，至少包含公众平台对第二账号的唯一标识，例如APPID；对第二用户信息进行存储时，至少包含公众平台中为用户进行唯一的标识和第
二账号为用户进行的唯一标识，例如OpenID和UnionID，还可包含用户地址信息、用户联系
方式等生成交易订单所需的信息。

[0077] 具体的，为提高安全性，还可包含将第二属性信息和/或第二用户信息进行加密后存储至用户终端。

[0078] 本实施例中，步骤S206d可包含步骤S3和步骤S4，其中：

[0079] 步骤S3，获取用户对第二账号的第二授权信息，并将第二授权信息和第二属性信息发送至公众平台的服务器。

[0080] 具体的，第二授权信息通过对第二账号进行强制授权或静默授权生成。由于强制授权需要用户手动同意，为简化用户操作以提高用户体验，优选第二授权信息通过对第二
账号进行静默授权生成。

[0081] 步骤S4，接收公众平台的服务器根据第二授权信息和第二属性信息所返回的第二用户信息。

[0082] 步骤S207，获取第二账号所返回的订单支付页面，其中，订单支付页面由第二账号根据订单信息和第二用户信息所生成。

[0083] 本实施例中，将订单信息和第二用户信息发送至第二账号后，第二账号可根据订单信息和第二用户信息生成订单支付页面，用户可在订单支付页面中对生成交易订单所需
的信息进行调整或者补充。例如，订单支付页面中的商品标识信息和商品数量信息可根据
订单信息所确定，订单支付页面中的用户地址信息、用户联系方式信息可根据第二属性信
息所确定。

[0084] 步骤S208，接收用户在订单支付页面中触发的支付指令，执行支付指令对应的支付操作。

[0085] 步骤S209，接收支付操作对应的支付状态通知，并根据支付状态通知判断是否支付成功。如果是，则根据支付配置信息返回并刷新第一账号的内容页面。

[0086] 本实施例中，如用户通过支付平台进行支付的话，支付平台会返回支付操作对应的支付状态通知，支付状态通知至少包含支付是否成功。由于用户是对第一账号所提供的
内容较为关注，才会进行商品的购买及支付，因此为提高用户体验，若支付成功的话，可根
据支付配置信息返回并刷新第一账号的内容页面，供用户继续浏览第一账号的内容页面。

[0087] 本实施例中，若支付成功的话，第二账号会保存交易订单所包含的信息、支付操作的相关信息、第一用户信息和第二用户信息。由于第一用户信息和第二用户信息中包含的
UnionID相同，因此如果存在多个第一账号的话，运营者也可对同一用户通过不同第一账号
的内容页面提交并完成的订单情况进行汇总管理。

[0088] 由以上本发明实施例可见，本发明通过获取第一账号中用于标识用户的第一用户信息，可为不同用户生成个性化的内容页面；通过获取第二账号中用于标识用户的第二用
户信息，可根据订单信息和第二用户信息帮助用户快速填写订单相关信息；通过将存储在
用户终端中的第一属性信息、第一用户信息、第二属性信息、第二用户信息中的至少其一进
行加密，提高了用户信息的安全性；由于第一用户信息和第二用户信息中对同一用户存在
相同的标识，便于运营者通过第二账号对多个第一账号发起的订单交易进行汇总和管理。

[0089] 实施例三

[0090] 本发明实施例还提供了一种计算机存储介质，所述计算机存储介质中存储有：

[0091] 用于接收用户在第一账号的内容页面中触发的订单创建指令，并获取与所述订单创建指令对应的订单信息以及支付配置信息的指令；

[0092] 用于根据所述支付配置信息，确定与所述第一账号关联的第二账号的指令，其中，所述第一账号和所述第二账号为同一公众平台中的账号；

[0093] 用于将所述订单信息发送至所述第二账号，并获取所述第二账号根据所述订单信息生成的订单支付页面的指令；

[0094] 用于接收所述用户在所述订单支付页面中触发的支付指令，执行所述支付指令对应的支付操作的指令。

[0095] 可选地，还包含：用于根据首次接收的所述用户对所述第一账号的内容页面的获取指令，获取用于标识所述第一账号的第一属性信息，以及所述第一账号中用于标识所述
用户的第一用户信息的指令；

[0096] 用于根据所述第一属性信息，将所述第一用户信息发送至所述第一账号，并接收所述第一账号返回的根据所述第一用户信息生成的所述内容页面的指令。

[0097] 可选地，所述用于根据首次接收的所述用户对所述第一账号的内容页面的获取指令，获取用于标识所述第一账号的第一属性信息，以及所述第一账号中用于标识所述用户
的第一用户信息的指令包含：

[0098] 用于根据首次接收的所述用户对所述第一账号的内容页面的获取指令，获取所述第一属性信息的指令；

[0099] 用于判断用户终端中是否存储与所述第一属性信息对应的所述第一用户信息的指令；

[0100] 用于如果是，则从所述用户终端中获取所述第一用户信息的指令；

[0101] 用于如果否，则根据所述第一属性信息从所述公众平台的服务器获取所述第一用户信息，并将所述第一属性信息和所述第一用户信息存储至所述用户终端的指令。

[0102] 可选地，所述用于根据所述第一属性信息从所述公众平台的服务器获取所述第一用户信息的指令包含：

[0103] 用于获取所述用户对所述第一账号的第一授权信息，并将所述第一授权信息和所述第一属性信息发送至所述公众平台的服务器的指令；

[0104] 用于接收所述公众平台的服务器根据所述第一授权信息和所述第一属性信息所返回的所述第一用户信息的指令。

[0105] 可选地，所述第一授权信息通过对所述第一账号进行强制授权或静默授权生成。

[0106] 可选地，所述用于将所述订单信息发送至所述第二账号，并获取所述第二账号根据所述订单信息生成的订单支付页面的指令包含：

[0107] 用于获取所述第二账号中用于标识所述用户的第二用户信息，并将所述订单信息和所述第二用户信息发送至所述第二账号的指令；

[0108] 用于获取所述第二账号所返回的所述订单支付页面的指令，其中，所述订单支付页面由所述第二账号根据所述订单信息和所述第二用户信息所生成。

[0109] 可选地，所述用于获取所述第二账号中用于标识所述用户的第二用户信息，并将所述订单信息和所述第二用户信息发送至所述第二账号的指令包含：

[0110] 用于根据所述支付配置信息，获取用于标识所述第二账号的第二属性信息的指令；

[0111] 用于判断用户终端中是否存储与所述第二属性信息对应的所述第二用户信息的指令；

[0112] 用于如果是，则从所述用户终端中获取所述第二用户信息的指令；

[0113] 用于如果否，则根据所述第二属性信息从所述公众平台的服务器获取所述第二用户信息，并将所述第二属性信息和所述第二用户信息存储至所述用户终端的指令。

[0114] 可选地，所述用于根据所述第二属性信息从所述公众平台的服务器获取所述第二用户信息，并将所述第二属性信息和所述第二用户信息存储至所述用户终端的指令包含：

[0115] 用于获取所述用户对所述第二账号的第二授权信息，并将所述第二授权信息和所述第二属性信息发送至所述公众平台的服务器的指令；

[0116] 用于接收所述公众平台的服务器根据所述第二授权信息和所述第二属性信息所返回的所述第二用户信息的指令。

[0117] 可选地，所述第二授权信息通过对所述第二账号进行强制授权或静默授权生成。

[0118] 可选地，还包含：用于接收所述支付操作对应的支付状态通知，并根据所述支付状态通知判断是否支付成功的指令；

[0119] 用于如果是，则根据所述支付配置信息返回并刷新所述第一账号的内容页面的指令。

[0120] 通过本实施例的计算机存储介质，可以实现前述多个方法实施例中相应的数据获取方法，并具有相应方法实施例的有益效果，在此不再赘述。

[0121] 需要指出，根据实施的需要，可将本发明实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步
骤，以实现本发明实施例的目的。

[0122] 上述根据本发明实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网
络下载的原始存储在远程记录介质或非暂时机器可读介质中并将被存储在本地记录介质
中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编
程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解，计算机、处理
器、微处理器控制器或可编程硬件包含可存储或接收软件或计算机代码的存储组件(例如，
RAM、ROM、闪存等)，当所述软件或计算机代码被计算机、处理器或硬件访问且执行时，实现
在此描述的支付方法。此外，当通用计算机访问用于实现在此示出的支付方法的代码时，代
码的执行将通用计算机转换为用于执行在此示出的支付方法的专用计算机。

[0123] 本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟
以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员
可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出
本发明实施例的范围。

[0124] 以上实施方式仅用于说明本发明实施例，而并非对本发明实施例的限制，有关技术领域的普通技术人员，在不脱离本发明实施例的精神和范围的情况下，还可以做出各种
变化和变型，因此所有等同的技术方案也属于本发明实施例的范畴，本发明实施例的专利
保护范围应由权利要求限定。