CN106056368A - 一种添加支付口令的支付处理方法 - Google Patents

Abstract

本发明提供了一种添加支付口令的支付处理方法，包括：支付终端建立添加支付信息的移动支付请求；支付信息包括支付口令和支付口令交互信息；支付终端向支付服务器发出带有支付信息的移动支付请求；支付服务器将带有支付信息的支付链接发送至接收终端；接收终端接收支付链接，接收终端将所述支付口令的交互信息发送至支付服务器；支付服务器验证接收终端反馈的交互信息与支付终端发送的移动支付请求中携带的支付口令交互信息一致时，支付请求被打开且完成。本申请使得接收终端在实现与支付口令的预设互动之后，可接收支付方发送的支付金额，实现与支付方之间的情感互动。

Description

一种添加支付口令的支付处理方法

技术领域

本发明涉及移动支付领域，特别地，涉及一种在支付时添加支付口令、实现支付双方情感交互的支付处理方法、装置及终端。

背景技术

随着移动互联网以及互联网支付的快速发展，移动支付的需求量也越来越大，移动支付衍生了多种多样的形态，例如常用的有快捷支付、帐户支付、声波支付、刷脸支付、刷卡支付以及指纹支付等，然而这些支付方式都仅仅是进行支付流程，未能有效地将支付方与接收终端有效地联系起来。

同时，移动互联网以及互联网支付的普及，也使得人们越来越多地通过即时通信的社交软件进行沟通，即时通信类的社交软件的功能之一，就是通过移动支付的方式给亲朋好友发不同金额的红包，而且这种功能已经十分普及，人们可以足不出户，就给万里之外的朋友送上红包。然而目前的这种移动支付方式形式单一，支付方与接收终端之间缺少情感上的交互。

发明内容

本发明目的在于提供一种添加支付口令的支付处理方法，以解决移动支付方式形式单一、没有趣味性和情感交互的技术问题。

为实现上述目的，本发明提供了一种添加支付口令的支付处理方法，方法包括：

支付终端建立添加支付信息的移动支付请求；支付信息包括支付口令和支付口令交互信息；

支付终端向支付服务器发出带有支付信息的移动支付请求；

支付服务器将带有支付信息的支付链接发送至接收终端；

接收终端接收所述支付链接，接收终端将所述支付口令的交互信息发送至支付服务器；

支付服务器验证接收终端反馈的支付口令的交互信息与支付终端发送的移动支付请求中携带的支付口令交互信息一致时，所述支付请求被打开且完成。

优选地，所述支付口令为特定问题，支付口令交互信息为与所述特定问题关联的设定答案；所述支付口令为图片、音频、视频、文字或者emoji绘文字，所述支付口令交互信息为文字或者emoji绘文字。

优选地，支付终端建立添加支付信息的移动支付请求还包括：

支付终端检测到支付信息的采集完成时，检测所述支付信息的格式是否符合预设格式；

当所述支付信息的格式符合预设格式时，直接采集所述支付信息；

当所述支付信息的格式不符合预设格式时，对所述支付信息进行转码以符合预设格式后，采集所述支付信息。

优选地，所述支付信息还包括支付终端数量；

当支付终端数量大于1时，支付服务器将带有支付信息的支付链接发送至若干个接收终端；

支付服务器一一验证若干个接收终端反馈的支付口令的交互信息与支付终端发送的移动支付请求中携带的支付口令交互信息是否一致；

支付服务器打开并完成支付口令交互信息一致的所述接收终端的支付请求。

优选地，所述支付链接为带有支付方授权账号的支付请求，或者为空白支付请求。

优选地，支付终端数量超出支付数时，支付服务器发送空白支付请求至超出数量的支付终端。

优选地，反馈的交互信息与支付终端发送的移动支付请求中携带的支付口令交互信息不一致时，支付服务器发送空白支付请求至对应的接收终端。

本发明具有以下有益效果：

本发明公开了一种在支付时添加支付口令的支付处理方法，其中心思想是在支付请求中添加支付口令作为附加内容，如音频、视频以及Flash等，将支付口令与支付请求共同发送至支付服务器，并进一步将支付口令与支付请求发送至接收终端，使得接收终端在实现与支付口令的预设互动之后，可接收支付方发送的支付金额，实现与支付方之间的情感互动。本发明的方法及其对应装置尤可应用于目前移动支付中的各类红包玩法中，增加趣味性的同时，也给使用双方用户带来的极佳的用户体验。

例如，支付请求中添加了发送给接收终端的问题以及支付终端预设的答案，在支付服务器接收到接收终端反馈的与预设答案一致的回复后，完成支付请求，将支付终端发送的红包发给接收终端；若支付服务器接收到接收终端反馈的与预设答案不一致的回复后，不完成支付请求，将支付终端发送的红包退回给支付终端。

除了上面所描述的目的、特征和优点之外，本发明还有其它的目的、特征和优点。下面将参照图，对本发明作进一步详细的说明。

附图说明

构成本申请的一部分的附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是本发明优选实施例一的流程示意图；

图2是本发明优选实施例二的流程示意图

图3是本发明优选实施例三的流程示意图；

图4是本发明优选实施例四的流程示意图；

图5是本发明优选实施例一的结构示意图。

具体实施方式

以下结合附图对本发明的实施例进行详细说明，但是本发明可以根据权利要求限定和覆盖的多种不同方式实施。

实施例一

如图1和图5所示，是根据一示例性实施例示出的一种实现支付双方情感交互的支付处理方法的流程图，结合图示，一种实现支付双方情感交互的支付处理方法，用于进行移动支付的双方终端中，其主要包括以下步骤：

步骤S110：支付终端建立添加支付信息的移动支付请求；所述支付信息包括支付口令和支付口令交互信息。

本发明实施例可通过支付方的用户终端即支付终端上通过移动支付服务来实现，支付终端的支付方通过注册账号与支付服务商之间建立联系，如实现支付方的银行卡信息与该账号之间的绑定。

在本发明中以支付服务器统称支付服务商。在发起支付请求时，支付服务器将使用支付方的账号信息来进行支付，支付服务器与支付方之间通过网络实现通信；在用户终端设备或者其系统中经过授权以后，在该用户终端上的应用也均可发起所述添加支付信息的移动支付请求，作为示例，网络可以是但不限于移动电话网络如2G、3G以及4G或无线/有线互联网。

添加支付信息的移动支付请求，可通过附件形式对将支付信息添加于该移动支付请求，也可通过对支付请求进行拓展的形式在支付请求中添加支付信息，该支付信息既可以是支付口令，也可以是最原始的文字信息，文字信息所占字节远小于其他形式的支付口令，因此，文字信息也可作为支付口令的说明性文字出现于支付请求的支付信息中。

在支付终端中采集支付口令，可以采集用户终端中已存储的支付口令，此时在存储文件中进行选取即可，也可以通过打开用户终端设备上的硬件支持来实时制作支付口令。

所述支付口令可以为特定问题，支付口令交互信息为与所述特定问题关联的设定答案；所述支付口令为图片、音频、视频、文字或者emoji绘文字，所述支付口令交互信息为文字或者emoji绘文字。

步骤S120：支付终端向支付服务器发出带有支付信息的移动支付请求；支付服务器将带有支付信息的支付链接发送至接收终端。

所述移动支付请求是通过网络使支付终端与支付服务器之间建立内容联系，使所述移动支付请求与支付服务器之间建立起支付网络通道，本发明示例性实施例中，支付服务器针对所述移动支付请求获取或预授权支付方授权账户内的一定金额，并通过支付网络通道生成支付链接。

作为支付请求的附加内容，在支付请求到支付服务器中形成支付链接之后，所述支付信息也作为所述支付请求的附加内容，在一种可选的方式中，所述支付口令是通过网络地址的方式存在于所述支付请求中。

步骤S130：接收终端接收所述支付链接，接收终端将所述支付口令的交互信息发送至支付服务器。

所述支付链接中包含有支付请求的支付信息，该支付信息可以是由终端结合而生成的一种交互式信息，例如，支付用户在支付信息中提供的支付口令为一文字格式问题“我的生日是多少号”，则接收终端的用户需要根据该支付口令输入交互信息例如输入“6.1”。

在发起支付请求时，还可以采集已存储的支付口令或者通过用户终端的硬件支持实时录一段视频或语音等支付口令，然后添加到支付请求中，作为附加内容发给接收终端；接收终端在接收对应的支付请求的时候，可以看到支付方发送的支付口令，并根据支付口令中包含对应的提问或要求给予针对性的回复，实现双方的情感互动，极大地提升了用户体验。

步骤S140：支付服务器验证接收终端反馈的支付口令的交互信息与支付终端发送的移动支付请求中携带的支付口令交互信息一致时；所述支付请求被打开且完成。

支付服务器验证信息一致后，所述支付请求才能被支付服务器接收，并将支付请求内所包含的对应账户内的金额划入接收终端帐户。

例如，接收终端用户反馈了“6.1”，支付服务器验证其与支付终端发送的支付信息中的支付口令交互信息“6.1”一致，接收支付请求并开始处理。

若接收终端用户反馈了“6.1”，支付服务器验证其与支付终端发送的支付信息中的支付口令交互信息“7.1”不一致，不接收支付请求，并反馈至支付终端。

可以理解的是，支付终端和接收终端均可以安装有同一或不同即时聊天软件，而支付服务器为与即时聊天软件关联的金融账号管理服务器，移动支付请求即为发红包或转账请求。不同即时聊天软件可以通过现有的软件和/或硬件上的账号/密码实现，本发明的技术方案对于接收终端以及发送方两个方面并没有提出有任何的限制。

实施例二

本实施例中将提供一种方法，使得支付请求以及附加的支付口令在传输过程中以字节形式的地址或代码出现，从而使支付接收双方均可以更节省流量，如图2所示，本实施例具体包括以下步骤：

步骤S210:所述支付终端建立并上传带有支付信息的移动支付请求至云服务器，支付信息包括支付口令和支付口令交互信息。

支付请求与其附加的支付信息可以是一体传送、存储的，也可以是分离传送、存储的。本实施例以分离传送、存储的实现方式进行说明。

步骤S220：支付服务器将不包括有支付信息的移动支付请求转换为代码，将支付信息存储在某网络地址。

代码是与所述支付请求所对应的由字节组成的唯一字节串，通过该代码可直接查询到与其对应的支付请求，但所占字节比支付请求更少，因此传输更方便。

步骤S230：支付终端接收所述云服务器返回的所述支付信息在所述云服务器中对应的网络地址。

支付终端接收终端通过打开网络地址即可打开在云服务器中存储的支付信息，打开网络地址后，支付信息通过流式媒体的方式从云服务器中获取资源，并在接收终端上进行播放以及存储等。

步骤S240：接收终端将所述支付口令的交互信息发送至支付服务器。

步骤S250：支付服务器验证接收终端反馈的支付口令的交互信息与支付终端发送的移动支付请求中携带的支付口令交互信息一致时；将移动支付请求的代码发送至接收终端。

步骤260：接收终端通过打开代码获得与支付请求所对应的金额。

附加有支付信息的支付请求，以及通过代码和网络地址形式的支付请求在发送至接收终端时，均可以预览图的形式进行发送，预览图可以更加直接地显示所发送支付请求及支付信息的概要，其中，预览图可以是指所有支付信息的预览图，也可以是附加的支付信息所包含的每一种格式的预览图；同时，该预览图包含所述支付请求以及所述支付信息的超链接，在接收终端点击该预览图的同时，即可同时或者分别打开支付请求以及支付信息。

实施例三

进一步地，在本发明实施例的另一实施场景中，可以通过包数据的方式对支付请求进行压缩发送，进一步改善支付请求流畅性，减少网络拥堵，防止支付请求延迟的情形发生，如图3所示，该方法具体包括：

步骤S310:所述支付终端建立带有支付信息的移动支付请求，压缩带有支付信息的移动支付请求形成一包数据；支付信息包括支付口令和支付口令交互信息。

通过无失真数据压缩技术，减少所述移动支付请求及其支付口令的电子数据中间的冗余，精简其数据编码，使其形成一个包数据。

步骤S320:支付终端将该包数据发送至云服务器。

包数据在传输过程中不易形成碎片，更利于数据的完整性传输。

步骤S330:支付服务器对包数据进行解析，以生成带有支付信息的支付请求。

无失真数据压缩的过程是可逆过程，因此，支付服务器接收到包数据之后，根据可逆向性解析该包数据，即可得出其中的移动支付请求并生成支付请求，该支付请求可替换所述包数据中的移动支付请求，使得该支付请求以及其中的支付信息一直以包数据的形式发送至接收终端。根据前述，亦可建立起该支付服务器与云服务器之间的联系，在支付服务器中解析得出的支付口令发送至云服务器进行存储并给出网络地址，使该网络地址替换包数据中的支付口令，进而通过包数据的形式发送至接收终端，接收终端在接收该包数据时即进行解压显示。

在另一种可能的实施方式中，在移动支付请求及其支付信息发送至支付服务器之前，还可先对该支付请求及其附加内容进行加密，该加密的过程也可以由支付服务器对支付请求的加密过程进行加密。

实施例四

本发明示例的另一实施场景中，在发送移动支付请求之前，还可对支付请求的类型进行检测，通过对移动支付请求的判断，进而选择不同的支付网络通道，如图4所示，该方法包括：

步骤S410：支付终端检测所述支付信息的类型；

步骤S420：当所述支付信息的类型为可添加附加内容时，支付终端启动终端中可调用的硬件支持。

当所述支付信息的类型为不可添加的附加内容时，则直接通过简易网络通道发送该移动支付请求，无须开启用户终端的硬件支持等步骤。

在此步骤中，发送支付请求的过程为常规过程，无须采集与发送支付信息。

另一种可能的实施方式是，当判断所述支付请求是否为包括有富媒体文件信息的支付请求时，首先对该支付请求的大小进行初步判断，例如，根据常规情形下(某一支付请求文件包括有一个支付请求以及少量的文字信息时)设定一个阈值(例如，该阈值＝5Kbyte，即5K字节)，移动支付请求的文件大小低于该阈值时，则可对该支付请求初步判断为未添加支付信息作为附加内容的简易支付，此时，适用于常规的支付请求发送网路，而当支付请求的文件高于该阈值时，则可对该支付请求初步判断为添加支付信息作为附加内容的支付方式。

步骤S430：支付终端通过所述用户终端的硬件支持采集支付口令以作为所述移动支付请求的附加内容；

支付终端在采集的支付口令中添加交互式的用于支付请求的支付口令。

支付终端在检测到该类型的支付请求时，根据用户设置，开启终端的硬件支持，如开启摄像头录制视频、开启麦克风以录制音频、开启软件以制作交互式信息等，在该过程中，可将所述支付口令添加到支付信息中。

第一次在本地添加支付信息文件之后，在支付请求所在的用户终端中会生成一存储文件夹，以保存从本地数据信息中添加到支付请求内容中支付信息相关的本地存储以及缓存，以及保存在支付请求发送时生成的缓存配置信息，以方便后期查询与翻阅。

该存储文件夹在达到预定大小时，会开启该存储文件夹的定期删除功能，删除其中的保存时间最长的一批文件。

实施例五

本发明示例的另一实施场景中，通过所述用户终端的硬件支持采集支付口令以作为所述移动支付请求的附加内容时，为保证形成的富媒体文件能被支付接收双方的用户终端所读取，可通过建立一种标准的通用格式的方式来实现，该过程包括：

步骤S510：支付终端检测到支付口令的采集完成时，检测所述支付口令的格式是否符合预设格式；

通过用户终端完成支付信息的采集时会形成相对应的富媒体文件，一种可能的方式是，通过检测富媒体文件的文件扩展名来识别富媒体文件的格式，对于不同类别的富媒体文件，可分别设置不同的预设格式来分别进行识别，对于相同类别的富媒体文件，则设置通用统一的预设格式。

步骤S520：判断是否符合预设格式；

根据富媒体文件的类别，对各类型的富媒体文件进行一一判断。

步骤S530：当所述支付口令的格式符合预设格式时，直接采集所述支付口令作为所述移动支付请求的附加内容。

支付口令有多种类型，不同类型的支付口令分别具有一对应的预设格式，该种类型的支付口令符合其预设格式时，对其直接进行采集。

支付口令可以包括但不限于：

趣味图片信息，从发送方的终端中选取可用的图片格式添加到该支付请求所包含的内容中；

Flash信息，从发送方的终端中选取，或者即时调用终端的硬件支持配合软件支持制作成能够添加到该支付请求内容中的Flash信息；

视频信息，从发送方的终端中选取，或者即时调用终端的硬件支持配合软件支持制作成可用的视频信息添加到该支付请求内容中的视频信息；

音频信息，从发送方的终端中选取，或者即时调用终端中的麦克风等硬件配合软件支持成可用的音频信息添加到该支付请求内容中的音频信息。

步骤S540：当所述支付口令的格式不符合预设格式时，对所述支付口令进行转码以符合预设格式。

转码过程可在用户终端所在设备进行，也可在发送至支付服务器或者云服务器时进行，在接收终端接收到支付口令时，即是经过转码后的符合预设格式的支付口令，以减少或防止支付口令在接收终端不能读取的情形发生。

接收终端的业务软件版本过低，无法显示支付请求及其附加内容支付口令时，可在该接收终端上只显示支付请求的代码以及支付口令的网络地址，并通过保存入口保存起来，以便于在其它接收终端或者电子计算机设备上通过代码及网络地址获取支付请求的金额以及支付口令。

实施例六

本发明示例的实施场景中，以移动支付请求对应地拆分成2个及以上的支付请求时的方法流程，与其对应地为目前的群红包玩法，该方法包括以下步骤：

步骤S610：支付服务器检测所述移动支付请求所对应的支付数，以在支付服务器中通过原子减操作生成对应所述支付数的第一支付请求；

本发明实施例中，可通过支付请求文件的内容中所包括的文件类型来判断所述支付请求是否为包括有支付信息的支付请求，对支付请求的内容类型进行检测，当检测到其内容类型≥N(N为≥2的正整数)时，即可判断该支付请求为包含有支付信息的支付请求，从而使该支付请求进入到下一步骤。

对于附加内容中仅包含一种富媒体类型的情形，则可通过判断支付请求文件大小的方式进行判断，通过设定常规阈值，以该常规阈值为界限，大于该常规阈值的支付请求文件为包含有支付信息的支付请求。

步骤S620：支付服务器针对每一所述第一支付请求生成一有效支付请求，并发送每一所述有效支付请求以及所述支付信息至接收终端；

一般情况下所述第一支付请求的个数对应于所述移动支付请求的支付数，支付数为≥1的正整数，当支付数为1时，则所述移动支付请求对应于一个第一支付请求，第一支付请求生成的支付请求即为所述移动支付请求的金额；

当支付数＞1时，例如支付数为N，则所述移动支付请求对应于N个第一支付请求，N个第一支付请求对应的各支付请求的金额之和即为所述移动支付请求的金额。

支付数为N，而支付服务器检测到在预定时间(所述移动支付请求的有效期间)内最多有M个接收终端，即最多生成M个第一支付请求，且M＜N，即所述移动支付请求最多对应于M个第一支付请求，则该M个支付请求所对应的金额总和≤所述移动支付请求对应的金额，此时，对于在所述移动支付请求对应的金额内的未分派的金额，通过支付服务器返回到所述移动支付请求绑定的账户内。

N个第一支付请求中的每一支付请求中的金额可以是固定的，也可以由支付服务器随机分配。

在移动支付请求的支付数N≥2的正整数个时，(在一种可能的实施场景中，可以为“抢红包”玩法)，可在支付服务器中可实施原子减操作，原子减操作实施完毕时，超出该原子减操作之外的支付请求未失效。

步骤S630：支付服务器一一验证若干个接收终端反馈的支付口令的交互信息与支付终端发送的移动支付请求中携带的支付口令交互信息是否一致；支付服务器打开并完成支付口令交互信息一致的所述接收终端的支付请求。

步骤S640：在支付服务器中通过原子减操作生成超出所述支付数的第二支付请求，发送由支付服务器生成的空白支付请求，以及所述支付口令至反馈的交互信息与支付终端发送的移动支付请求中携带的支付口令交互信息不一致的接收终端。

该支付请求为空白支付请求，该空白支付请求同样地添加有支付口令或其网络地址，即支付口令则仍随着该空白支付请求发送至接收终端，接收终端虽然未得到有效的支付金额，仍可以观看到发送终端发送出来的带有祝福性的音频视频Flash等支付口令。

即当M＞N，支付服务器发送生成的空白支付请求至M-N个接收终端。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (7)

1.一种添加支付口令的支付处理方法，其特征在于，所述方法包括步骤：

支付终端建立添加支付信息的移动支付请求；所述支付信息包括支付口令和支付口令交互信息；

支付终端向支付服务器发出带有支付信息的移动支付请求；

支付服务器将带有支付信息的支付链接发送至接收终端；

接收终端接收所述支付链接，接收终端将所述支付口令的交互信息发送至支付服务器；

支付服务器验证接收终端反馈的支付口令的交互信息与支付终端发送的移动支付请求中携带的支付口令交互信息一致时，所述支付请求被打开且完成。

2.根据权利要求1所述的支付处理方法，其特征在于，所述支付口令为特定问题，支付口令交互信息为与所述特定问题关联的设定答案；所述支付口令为图片、音频、视频、文字或者emoji绘文字，所述支付口令交互信息为文字或者emoji绘文字。

3.根据权利要求2所述的支付处理方法，其特征在于，支付终端建立添加支付信息的移动支付请求还包括：

支付终端检测到支付信息的采集完成时，检测所述支付信息的格式是否符合预设格式；

当所述支付信息的格式符合预设格式时，直接采集所述支付信息；

当所述支付信息的格式不符合预设格式时，对所述支付信息进行转码以符合预设格式后，采集所述支付信息。

4.根据权利要求3所述的支付处理方法，其特征在于，所述支付信息还包括支付终端数量；

当支付终端数量大于1时，支付服务器将带有支付信息的支付链接发送至若干个接收终端；

支付服务器一一验证若干个接收终端反馈的支付口令的交互信息与支付终端发送的移动支付请求中携带的支付口令交互信息是否一致；

支付服务器打开并完成支付口令交互信息一致的所述接收终端的支付请求。

5.根据权利要求1所述的支付处理方法，其特征在于，所述支付链接为带有支付方授权账号的支付请求，或者为空白支付请求。

6.根据权利要求5所述的支付处理方法，其特征在于，支付终端数量超出支付数时，支付服务器发送空白支付请求至超出数量的支付终端。

7.根据权利要求5所述的支付处理方法，其特征在于，反馈的交互信息与支付终端发送的移动支付请求中携带的支付口令交互信息不一致时，支付服务器发送空白支付请求至对应的接收终端。