模板化充值方法和装置与流程

本发明涉及移动游戏支付技术领域，尤其是涉及一种模板化充值方法和装置。

背景技术：

在移动游戏领域，特别是手机网络游戏中存在允许玩家购买虚拟商品的需求(例如钻石，元宝)，一般是通过接入第三方在线支付进行交易或充值。在不同的国家和地区，流行的在线支付方式不同，例如泰国流行mol和easy2pay，美国流行paypal，俄罗斯流行payssion和yandex。由于不同的在线支付渠道的充值流程具有不同充值逻辑，需要移动游戏的服务端支持多种不同的充值流程，导致代码复杂、开发和维护的成本高。

针对上述现有技术中移动游戏客户端支持多种在线支付方式导致开发和维护成本高的问题，目前尚未提出有效解决方案。

技术实现要素：

有鉴于此，本发明的目的在于提供一种模板化充值方法和装置，规范了充值的接入流程，也简化了充值的代码。

第一方面，本发明实施例提供了一种模板化充值方法，应用于服务端，服务端预先定义有与充值方式对应的充值方式类，充值方式类包括模板化充值函数；该方法包括：接收客户端提交的充值消息；其中，充值消息包括充值方式标识；调取与充值方式标识对应的充值方式类，为调取的充值方式类创建对象；根据充值消息创建订单并将订单发送给客户端；通过对象的模板化充值函数生成充值链接并将充值链接发送给客户端，以使客户端提交订单至充值链接对应的服务器；当服务器调用服务端的回调接口时，通过对象的模板化充值函数判断订单是否交易成功；如果是，为客户端添加订单对应的虚拟充值数额。

结合第一方面，本发明实施例提供了第一方面的第一种可能的实施方式，其中，为调取的充值方式类创建对象包括：获取充值方式类的类名；根据类名为充值方式类创建对象。

结合第一方面，本发明实施例提供了第一方面的第二种可能的实施方式，其中，通过对象的模板化充值函数判断订单是否交易成功包括：通过对象的模板化充值函数获取回调接口的通用参数；根据通用参数中的订单状态参数判断订单是否交易成功。

结合第一方面，本发明实施例提供了第一方面的第三种可能的实施方式，还包括：当服务器调用服务端的回调接口时，通过对象的模板化充值函数验证调用请求是否合法；如果合法，执行通过对象的模板化充值函数判断订单是否交易成功的步骤。

结合第一方面的第三种可能的实施方式，本发明实施例提供了第一方面的第四种可能的实施方式，还包括：根据充值消息计算签名；通过对象的模板化充值函数验证调用请求是否合法包括：通过对象的模板化充值函数比较签名与根据调用请求计算的签名是否一致，验证调用请求是否合法。

结合第一方面，本发明实施例提供了第一方面的第五种可能的实施方式，还包括：当判断订单交易不成功时，发送充值失败消息至客户端。

第二方面，本发明实施例还提供一种模板化充值装置，应用于服务端，服务端预先定义有与充值方式对应的充值方式类，充值方式类包括模板化充值函数；该装置包括：接收模块，用于接收客户端提交的充值消息；其中，充值消息包括充值方式标识；对象创建模块，用于调取与充值方式标识对应的充值方式类，为调取的充值方式类创建对象；订单发送模块，用于根据充值消息创建订单并将订单发送给客户端；充值链接发送模块，用于通过对象的模板化充值函数生成充值链接并将充值链接发送给客户端，以使客户端提交订单至充值链接对应的服务器；交易成功判断模块，用于当服务器调用服务端的回调接口时，通过对象的模板化充值函数判断订单是否交易成功；充值模块，用于如果是，为客户端添加订单对应的虚拟充值数额。

结合第二方面，本发明实施例提供了第二方面的第一种可能的实施方式，其中，对象创建模块还用于：获取充值方式类的类名；根据类名为充值方式类创建对象。

结合第二方面，本发明实施例提供了第二方面的第二种可能的实施方式，其中，交易成功判断模块还用于：通过对象的模板化充值函数获取回调接口的通用参数；根据通用参数中的订单状态参数判断订单是否交易成功。

结合第二方面，本发明实施例提供了第二方面的第三种可能的实施方式，其中，还包括：合法性验证模块，用于当服务器调用服务端的回调接口时，通过对象的模板化充值函数验证调用请求是否合法；如果合法，执行通过对象的模板化充值函数判断订单是否交易成功的步骤。

本发明实施例带来了以下有益效果：本发明实施例提供的模板化充值方法和装置，为多种充值方式定义了对应的充值方式类，该充值方式类包括模板化充值函数，通过为充值方式类创建对象实现模板化流程中不同的充值的特殊的逻辑，从而达到对不同支付渠道的通用流程进行模板化的目的，既规范了充值的接入流程，也简化了接入充值的代码。

本发明的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

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

图1为本发明实施例提供的一种模板化充值方法的流程示意图；

图2为本发明实施例提供的模板化充值方法的步骤s12的流程示意图；

图3为本发明实施例提供的模板化充值方法的交互图；

图4为本发明实施例提供的一种模板化充值装置的结构示意图；

图5为本发明实施例提供的另一种模板化充值装置的结构示意图；

图6为本发明实施例提供的另一种模板化充值装置的结构示意图；

图7为本发明实施例提供的另一种模板化充值装置的结构示意图；

图8为本发明实施例提供的一种服务器的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

目前移动游戏中存在玩家充值行为，一般是通过接入第三方在线支付进行交易或充值。由于不同的在线支付渠道的充值流程具有不同充值逻辑，需要移动游戏的服务端支持多种不同的充值流程，导致代码复杂、开发和维护的成本高。同时，不同的支付方式又存在共同点，例如easy2pay和paypal，都是由游戏生成渠道方的网址，然后把用户引导到渠道方的充值界面，玩家完成支付动作后，服务端接收渠道方的通知后给玩家发送虚拟货币。基于此，本发明实施例提供的一种模板化充值方法和装置，可以规范充值接入流程，简化充值代码。为便于对本实施例进行理解，先将本发明中服务端进行定义的类、变量和函数进行说明：

1、类和变量说明：

(1)类pay_center：执行充值操作的入口类。

(2)类pay_base：各个充值方式类的父类，用于规范不同充值方式要实现的差异化逻辑。各个充值方式对应的类如下：

easy2pay：类pay_easy2pay

mol：类pay_mol

paypal：类pay_payal

payssion：类pay_payssion

yandex：类pay_yandex

(3)对象pay_object是的某个充值方式类的对象，用于执行充值流程中充值方式的差异化逻辑。该对象在类pay_center中定义。例如使用paypal充值，pay_object为pay_payal类的对象；使用payssion充值，则为pay_payssion类的对象。

(4)变量pay_type_key是充值方式的标识符，各个充值方式对应的标识符如下：

easy2pay：easy2pay

mol：mol

paypal：payal

payssion：payssion

yandex：yandex

(5)变量request用于获取url请求中的参数，例如request->state表示获取url请求中的state参数

2、类pay_base的函数如下：

(1)hook_after_create_order：实现创建订单后的逻辑。

(2)success_pay：下单接口成功时调用。

(3)fail_pay：下单接口失败时调用。

(4)get_server_callback_param：返回服务端回调接口的通用参数，返回的参数如下：

billing_no：订单号

channel_success：订单是否成功

(5)hook_before_server_callback：判断服务端回调是否合法，一般是验证签名。

(6)server_callback_response：服务端回调接口返回数据。

3、类pay_center的关键函数如下：

(1)init_pay：初始化函数。伪代码如下：

class_name＝'pay_'.ucfirst(pay_type_key)；//得到充值方式的类名

pay_object＝newclass_name()；//根据类名，创建pay_object对象

(2)pay:下单接口，实现创建订单功能。伪代码如下：

order＝make_order()；//创建订单

if(order＝＝false)pay_object->fail_pay()；//下单失败

pay_object->hook_after_create_order()；//执行创建订单后的逻辑

pay_object->success_pay()；//下单成功

(3)server_callback：服务端回调接口，实现校验请求合法性，判断订单是否成功和发送虚拟货币功能。伪代码如下：

param＝pay_object->get_server_callback_param()；//获取参数

if(param->channel_success＝＝false)

pay_object->server_callback_response()；//如果订单是失败的，则返回

result＝pay_object->hook_before_server_callback()；//判断订单是否合法

if(result＝＝false)papy_object->server_callback_response()；//订单不合法，则返回

send_gold_to_user()；//订单成功则发送应用内商品给玩家。

papy_object->server_callback_response()；//返回结果。

首先对本发明实施例所公开的一种模板化充值方法进行详细介绍。

实施例1

本发明实施例1提供了一种模板化充值方法，应用于服务端，服务端预先定义有与充值方式对应的充值方式类，充值方式类包括模板化充值函数，参见图1所示的模板化充值方法的流程示意图，包括如下步骤：

步骤s11，接收客户端提交的充值消息。

用户有充值需求时，可以在客户端打开充值界面选择一种充值方式(在本实施例中以选择payssion为例进行说明)，并且选择金额后点击“提交订单”按钮，此时客户端向服务端提交充值消息，该充值消息中包括充值方式标识，例如payssion的充值标识为payssion。

步骤s12，调取与充值方式标识对应的充值方式类，为调取的充值方式类创建对象。

服务端可以获取充值消息中包括的充值方式标识，并根据该充值方式标识调取对应的充值方式类，payssion对应的充值方式类为pay_payssion类。为类pay_payssion创建对象pay_object，用于执行充值流程中充值方式的差异化逻辑。该对象在类pay_center中定义，对于payssion充值，pay_object为pay_payssion类的对象。

步骤s13，根据充值消息创建订单并将订单发送给客户端。

服务端根据充值消息生成订单，该订单中可以包括金额、充值数额或者虚拟商品的数量和种类等信息。服务端将订单发送给客户端，由客户端提交给上述充值方式的服务器。

步骤s14，通过对象的模板化充值函数生成充值链接并将充值链接发送给客户端，以使客户端提交订单至充值链接对应的服务器。

服务端通过对象的模板化充值函数生成充值链接url，并将该链接发送至客户端，在客户端通过webview接入充值链接，进入对应的充值方式的支付界面，用户在该支付界面完成支付操作。以充值方式是payssion为例，生成充值链接的过程如下：

pay_object->hook_after_create_order：

url＝https://www.payssion.com/api/v1/payment/create？api_key＝api_key&amount＝amount&currency＝currency&order_id＝order_id&api_sig＝api_sig；

//拼接充值链接，等号右边的参数名会替换为实际的参数值，各参数意义如下：api_key是payssion分配给游戏的标识符，amount是金额，currency是币种，order_id是订单号，api_sig是签名。其中充值方式分配的api_key是唯一的。签名api_sig的计算方式如下：

api_sig＝md5(api_key+amount+currency+order_id+secret_key)

其中md5即message-digestalgorithm5(信息-摘要算法5)，用于确保信息传输完整一致，是计算机广泛使用的杂凑算法之一(又译摘要算法、哈希算法)。显然也可以使用其他算法进行保密签名的生成。

步骤s15，当服务器调用服务端的回调接口时，通过对象的模板化充值函数判断订单是否交易成功。如果是，执行步骤s16；如果否，执行步骤s17。

充值方式(渠道方)的服务器会调用游戏服务端的回调接口，回调接口执行pay_center的init函数和server_callback函数，具体如下：

(1)通过对象的模板化充值函数获取回调接口的通用参数。

pay_object->get_server_callback_param：

returnarray(billing_no＝>request->track_id,channel_success＝>(request->state＝＝'completed'))；

其中，billing_no为订单号，channel_success为交易状态，当request->state为'completed'时才表示交易成功，否则表示交易失败。

(2)根据通用参数中的订单状态参数判断订单是否交易成功。

服务端根据上述通用参数中的channel_success判断订单是否交易成功，当request->state为'completed'时表示交易成功。

步骤s16，为客户端添加订单对应的虚拟充值数额。

在服务端确定渠道方交易成功后，为客户端添加对应的虚拟充值数额，该虚拟充值数额包括虚拟货币数额、虚拟商品数额等形式。

步骤s17，发送充值失败消息至客户端。

当判断订单交易不成功时，服务端发送充值失败消息至客户端，提醒用户充值操作未成功。

本发明实施例提供的模板化充值方法，为多种充值方式定义了对应的充值方式类，该充值方式类包括模板化充值函数，通过为充值方式类创建对象实现模板化流程中不同的充值的特殊的逻辑，从而达到对不同支付渠道的通用流程进行模板化的目的，既规范了充值的接入流程，也简化了接入充值的代码。

作为步骤s12的一种实施方式，根据当前应用的版本信息确定是否存在配置数据，请参阅图2，步骤s12可以包括：

步骤s21，获取充值方式类的类名。

步骤s22，根据类名为充值方式类创建对象。

上述步骤通过初始化函数实现，具体如下：

init_pay：

class_name＝'pay_'.ucfirst(pay_type_key)；//得到充值方式的类名。

pay_object＝newclass_name()；//根据类名，创建pay_object对象。

基于安全性考虑，在渠道方的服务器调用服务端的回调接口时，需要通过对象的模板化充值函数验证调用请求是否合法；如果合法，执行通过对象的模板化充值函数判断订单是否交易成功的步骤。

具体地，通过对象的模板化充值函数验证调用请求是否合法包括：

通过对象的模板化充值函数比较签名与根据调用请求计算的签名是否一致，验证调用请求是否合法。其中比较url请求中的参数计算得到的签名与根据充值时计算的签名，如果不一致，说明这个url请求是不可信任的，返回失败。具体如下：

pay_object->hook_before_server_callback：

cal_sig＝md5(request->api_key+request->amount+request->currency+request->order_id+request->state+secret_key)；

if(cal_sig！＝request->notify_sig)returnfalse；

returntrue

参见图3所示的模板化充值方法的交互图，其中包括游戏客户端、游戏服务器和充值服务器，包括如下步骤：

1.用户提交充值金额和充值方式。

用户在游戏客户端的商场界面或者充值界面进行虚拟商品或者货币的购买或者充值。

2.生成订单和充值链接。

游戏服务器根据客户端发送的充值消息创建订单并拼接充值链接。

3.发送订单和充值链接。

游戏服务器向客户端发送订单和充值链接。

4.向充值服务器提交订单。

客户端通过充值链接显示充值方式的充值界面，完成充值操作。

5.调用游戏服务器的回调接口。

充值服务器调用游戏服务器的回调接口，回调接口执行pay_center的init函数和server_callback函数，如果订单是成功的则会发送应用内商品给用户的客户端。

6.发送虚拟商品或货币。

本发明实施例提供的模板化充值方法，为多种充值方式定义了对应的充值方式类，该充值方式类包括模板化充值函数，通过为充值方式类创建对象实现模板化流程中不同的充值的特殊的逻辑，从而达到对不同支付渠道的通用流程进行模板化的目的，同时对充值服务器回调进行合法验证，提高了充值的安全性。

实施例2

本发明实施例2提供了一种模板化充值装置，应用于服务端，服务端预先定义有与充值方式对应的充值方式类，充值方式类包括模板化充值函数，参见图4所示的结构示意图，包括以下模块：

接收模块410，用于接收客户端提交的充值消息；其中，充值消息包括充值方式标识；

对象创建模块420，用于调取与充值方式标识对应的充值方式类，为调取的充值方式类创建对象；

订单发送模块430，用于根据充值消息创建订单并将订单发送给客户端；

充值链接发送模块440，用于通过对象的模板化充值函数生成充值链接并将充值链接发送给客户端，以使客户端提交订单至充值链接对应的服务器；

交易成功判断模块450，用于当服务器调用服务端的回调接口时，通过对象的模板化充值函数判断订单是否交易成功；

充值模块460，用于如果是，为客户端添加订单对应的虚拟充值数额。

具体地，对象创建模块420还用于：获取充值方式类的类名；根据类名为充值方式类创建对象。

具体地，交易成功判断模块450还用于：通过对象的模板化充值函数获取回调接口的通用参数；根据通用参数中的订单状态参数判断订单是否交易成功。

进一步，参见图5所示的结构示意图，上述装置还包括：

合法性验证模块510，用于当服务器调用服务端的回调接口时，通过对象的模板化充值函数验证调用请求是否合法；如果合法，执行通过对象的模板化充值函数判断订单是否交易成功的步骤。

进一步，参见图6所示的结构示意图，上述装置还包括：

签名计算模块610，用于根据充值消息计算签名；

合法性验证模块还用于：通过对象的模板化充值函数比较签名与根据调用请求计算的签名是否一致，验证调用请求是否合法。

进一步，参见图7所示的结构示意图，上述装置还包括：

失败消息发送模块710，用于当判断订单交易不成功时，发送充值失败消息至客户端。

本发明实施例所提供的装置，其实现原理及产生的技术效果和前述方法实施例相同，为简要描述，装置实施例部分未提及之处，可参考前述方法实施例中相应内容，在此不再赘述。

参见图8，本发明实施例还提供一种服务器100，包括：处理器80，存储器81，总线82和通信接口83，处理器80、通信接口83和存储器81通过总线82连接；处理器80用于执行存储器81中存储的可执行模块，例如计算机程序。

其中，存储器81可能包含高速随机存取存储器(ram，randomaccessmemory)，也可能还包括非不稳定的存储器(non-volatilememory)，例如至少一个磁盘存储器。通过至少一个通信接口83(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。

总线82可以是isa总线、pci总线或eisa总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

其中，存储器81用于存储程序，处理器80在接收到执行指令后，执行程序，前述本发明实施例任一实施例揭示的流过程定义的装置所执行的方法可以应用于处理器80中，或者由处理器80实现。

处理器80可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器80中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器80可以是通用处理器，包括中央处理器(centralprocessingunit，简称cpu)、网络处理器(networkprocessor，简称np)等；还可以是数字信号处理器(digitalsignalprocessing，简称dsp)、专用集成电路(applicationspecificintegratedcircuit，简称asic)、现成可编程门阵列(field-programmablegatearray，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器81，处理器80读取存储器81中的信息，结合其硬件完成上述方法的步骤。

本发明实施例所提供的进行模板化充值方法的计算机程序产品，包括存储了处理器可执行的非易失的程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。

上述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。