支付处理方法及装置与流程

本公开实施例涉及移动支付技术领域，尤其涉及一种包含有富媒体信息的支付处理方法及装置。

背景技术：

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

红包支付作为移动支付的一种，伴随着某信支付以及某宝支付的普及，也使得人们越来越多地通过即时通信的社交软件进行沟通以及帐户金额的资金流动，成为了即时通信类的社交软件的重要功能之一，即通过上述方式给亲朋好友发不同金额的红包，而且这种功能已经十分普及，人们可以足不出户，就可通过在软件上实现的支付方式给万里之外的朋友送上红包。然而目前的这种移动支付方式形式单一，支付方与接收方之间难以实现互动。

技术实现要素：

本公开提供一种支付处理方法及装置，以通过采集富媒体信息的方式实现在通过移动支付时实现支付方与接收方双方的情感互动。

第一方面，本公开实施例提供一种支付处理方法，其具体的技术方案包括：

获取富媒体信息；

将所述富媒体信息添加至红包；

发送所述红包至交易接收端；

其中，所述富媒体信息用于在所述交易接收端被打开时，显示于所述交易接收端。

本公开的实施例提供的技术方案可以达到的有益效果为：在向接收端发起带有富媒体信息的支付请求时，能够将支付方采集的富媒体信息一同发送至接收方，使得支付方与接收方能够实现情感上的互动，丰富了现有的支付请求的内容，也带来了一种新的人与人之间的支付时如红包形式下的情感交互方式。

结合第一方面，在第一方面的第一种可能的实现方式中，所述获取富媒体信息，包括：

开启摄像装置以采集视频信息形成的富媒体信息；和/或

开启拾音装置以采集音频信息形成的富媒体信息；

所述富媒体信息包括动画信息、流媒体信息、视频信息、音频信息、文字信息中的任意一种或者任意组合。

本公开的实施例提供的技术方案可以达到的有益效果为：在发送支付请求时，通过对支付请求类型的检测可以提醒支付方是否有需要发送带有富媒体的支付请求，丰富了用户的选择余地，而在需要添加富媒体信息时，则在获取该需求时启动上用户终端的相应硬件支付，通过相应的硬件支持能够形成各种不同类型的富媒体信息，使得能够根据用户意愿以及用户设置采集相应的类型的富媒体信息作为支付请求的附加内容。

结合第一方面，在第一方面的第二种可能的实现方式中，所述获取富媒体 信息之后，还包括：

上传所述富媒体信息至云服务器，并接收所述云服务器中对应于所述富媒体信息的网络地址；

所述将所述富媒体信息添加至红包，包括：

向交易接收端发起支付请求时，将所述支付请求与所述网络地址发送至所述交易接收端。

本公开的实施例提供的技术方案可以达到的有益效果为：将富媒体信息与支付请求分离，使富媒体信息上传到云服务器，在发送的过程中使该富媒体信息对应在云服务器中的网络地址作为支付请求的附加内容共同发送至接收端，从而为支付方节省流量，同时也可以减少网络通道的拥堵。

结合第一方面，在第一方面的第三种可能的实现方式中，所述将所述支付请求与所述网络地址发送至所述交易接收端，包括：

将所述支付请求以及所述网络地址通过缩略图发送至所述交易接收端；

其中，所述交易接收端中显示的所述支付请求以及所述网络地址为所述缩略图；所述缩略图中包含所述交易请求以及所述网络地址和/或所述富媒体信息的超链接，通过点击该缩略图可通过超链接打开所述支付请求以及所述网络地址。

本公开的实施例提供的技术方案可以达到的有益效果为：在接收端接收的支付请求将以带有超链接的缩略图形式进行接收，使得支付请求在接收端同样能够以缩略图的方式显示，替换了传统的支付请求只能显示交易请求的方式，在接收者看到该缩略图时即认识到该支付请求对应的交易请求附带有支付方发送的富媒体信息，从而不至于让接收方忽略双方进行情感交互的重要内容，同 时亦能提升用户体验。结合第一方面，在第一方面的第四种可能的实现方式中，所述将所述富媒体信息添加至红包，包括：

检测所述支付请求的类型；

当所述支付请求的类型为可添加附加内容时，启动所述支付请求所在用户终端的硬件支持；

通过所述用户终端的硬件支持采集富媒体信息以作为所述支付请求的附加内容。

本公开的实施例提供的技术方案可以包括以下有益效果：在用户发起支付请求时，向用户提供支付请求的类型，使得用户能够自由地选择支付方式，并根据不同的支付类型选择开启相应的硬件支持，从用户层面提高了用户的体验。

第二方面，本公开提供了一种支付处理装置，所述装置包括：

获取模块，被配置为获取富媒体信息；

添加模块，被配置为将所述富媒体信息添加至红包；

发送模块，被配置为发送所述红包至交易接收端；

其中，所述富媒体信息用于在所述交易接收端被打开时，显示于所述交易接收端。

上述的装置，所述获取模块包括：

第一获取子模块，被配置为开启摄像装置以采集视频信息形成的富媒体信息；和/或

第二获取子模块，被配置为开启拾音装置以采集音频信息形成的富媒体信息；

所述富媒体信息包括动画信息、流媒体信息、视频信息、音频信息、文字 信息中的任意一种或者任意组合。

上述的装置，所述装置还包括：

上传模块，被配置为上传所述富媒体信息至云服务器，并接收所述云服务器中对应于所述富媒体信息的网络地址；

所述添加模块包括：

共同发送子模块，被配置为向交易接收端发起支付请求时，将所述支付请求与所述网络地址发送至所述交易接收端。

上述的装置，所述共同发送子模块还包括：

缩略图子模块，被配置为将所述支付请求以及所述网络地址通过缩略图发送至所述交易接收端；

其中，所述交易接收端中显示的所述支付请求以及所述网络地址为所述缩略图；所述缩略图中包含所述交易请求以及所述网络地址和/或所述富媒体信息的超链接，通过点击该缩略图可通过超链接打开所述支付请求以及所述网络地址。

上述的装置，所述添加模块还包括：

检测子模块，被配置为检测所述支付请求的类型；

启动子模块，被配置为当所述支付请求的类型为可添加附加内容时，启动所述支付请求所在用户终端的硬件支持；

采集子模块，被配置为通过所述用户终端的硬件支持采集富媒体信息以作为所述支付请求的附加内容。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

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

图1为本公开示例性实施例中的支付处理方法的主流程图；

图2是本公开示例性实施例中的支付处理方法的发送网络地址的流程图；

图3是本公开示例性实施例中的支付处理方法的网络地址以缩略图形式发送的流程图；

图4是本公开示例性实施例中的支付处理方法的支付类型判断的流程示意图。

图5是本公开示例性实施例中的支付处理方法的对应有多个交易接收端用户时的流程示意图。

图6是根据一示例性实施例示出的一种支付处理装置的框图。

图7是根据一示例性实施例示出的一种支付处理装置的网络地址发送时的框图。

图8是根据一示例性实施例示出的带有缩略图模块的支付处理装置的框图。

图9是根据一示例性实施例示出的根据不同支付请求的类型进行发送时的装置框图。

图10是根据一示例性实施例示出的支付请求对应多个接收用户时的装置框图。

图11是根据一示例性实施例示出的一种用于支付处理的装置的框图。

图12是根据一示例性实施例示出的一种云服务器的装置的框图。

具体实施方式

下面结合附图和实施例对本公开作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本公开，而非对本公开的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本公开相关的部分而非全部结构。

在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图中将各步骤描述成顺序的处理，但是其中的许多步骤可以并行地、并发地或者同时实施。此外，各步骤的顺序可以被重新安排，当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图内的其它步骤。处理处理可以对应于方法、函数、规程、子例程、子程序等。

本公开涉及一种支付处理方法及装置，其主要运用于存在有支付请求的场景中，在支付请求的过程中实现双方的互动，其基本思想是：通过交易端向接收端发起支付请求时，开启终端的硬件支付采集支付方想要发送给接收方的富媒体信息，使支付请求同富媒体信息一起发送至接收方，中间可通过交易服务器以及云服务器的处理，使支付请求以及富媒体信息形成交易请求以及网络地址再转发至接收方，接收方在接收到所述支付请求之后，可以通过所述交易请求以及网络地址接收交易信息以及富媒体信息，很好地实现了双方之间的情感互动，为使用双方带来了一种新的移动支付方式。

本实施例可适用于带有能够进行移动支付的智能型终端中以进行支付处理的情况中，其可以由软件和/或硬件来实现，其中的硬件一般地可集成于移动终端中，如图1所示，为本公开示例性实施例提供一种支付处理方法的流程图， 所述方法可包括如下步骤：

在步骤110中，获取富媒体信息；

在本步骤中，获取富媒体信息的方式可以为：开启摄像装置以采集视频信息形成的富媒体信息；和/或开启拾音装置以采集音频信息形成的富媒体信息。

在检测到获取富媒体信息的指令时，可调用移动终端中的相应的硬件支持，例如摄像装置和/或拾音装置等相关硬件，生成一定格式的富媒体信息，富媒体信息的类型可包括：动画信息、流媒体信息、视频信息、音频信息、文字信息中的任意一种或者任意组合。

所述富媒体信息可以由当前终端的用户调用硬件支持自行创造，也可以由中间服务器向该用户推送由其它用户制作完成的趣味性富媒体信息并经过该用户的再创作之后形成包括有该用户音视频信息的富媒体信息。

所述支付请求可应用于移动终端或移动终端中开发的任意一款被授权的应用程序中，该移动终端可以为安装有安卓或IOS系统的手机、平板电脑、掌上型电脑等。

通过支付方(包括移动终端上下载的各客户端类型的应用程序)向交易接收端发起支付请求时，或者开启终端上移动支付服务，可通过建立支付账号与支付服务端之间的联系来实现绑定，当支付方通过一支付账号发起支付请求时，中间的交易服务器将通过该支付账号对应的数据账号来实现支付，中间的过程可通过无线通讯实现，作为示例，无线通讯可以是但不限于移动电话网络如2G、3G以及4G或无线/有线互联网，接收端同样地在接收时也通过接收交易请求而将交易请求内包含的金额存入于相应客户端绑定的数据账号。

在步骤120中、将所述富媒体信息添加至红包；

在发起支付请求时，可根据支付用户的需求，设置采集用户终端中已存储或开启相应的硬件支付来采集所需要的富媒体信息作为附加内容添加到支付请求中。

所述红包一般以支付方将包括有一定金额的支付请求发送至接收方，接收方在打开红包时可获取该支付请求中包括的金额至接收方相关账户中。

将所述富媒体信息添加至红包时，所述根据红包的类型可选择性地富媒体信息添加至红包中。

在步骤130中，发送所述红包至交易接收端。

其中，所述富媒体信息用于在所述交易接收端被打开时，显示于所述交易接收端。

支付方将包括有富媒体信息的红包发送至交易接收端时，所述接收端可在接收红包的同时查看至支付方录制的富媒体信息，其中，交易方还可设置接收方拆开红包的方式，例如，只有在完整地观看所述富媒体信息时所述红包才可被接收方打开，或者根据接收方观看所述富媒体信息的多少来分配接收方能够获取的红包内的金额的大小。

其中，所述支付请求可经过一交易服务器被发送至交易接收端，交易服务器可对支付请求的请求金额、包含的交易数等作出相应的处理，例如，当该支付请求的金额大于其绑定的数据账号内的金额时，向支付方反馈一“余额不足”的提示信息，而当该支付请求的金额小于其绑定的数据账号内的金额时，检测该支付请求所包含的交易数，使该支付请求对应地生成相应交易数的交易子请求，该部分将于下文详细描述。

在支付请求发送至所述交易接收端时，作为该支付请求的附加内容的富媒体信息也可能网络发送至所述交易接收端。

所述交易接收端接收附加有富媒体信息的交易请求(该交易请求对应于所述支付请求)，可接收交易请求内所包含的金额，该交易请求内所包含的金额存入交易接收端所包括的数据账号内，同时，所述交易接收端的用户能够观看到富媒体信息。

在本公开示例性实施例的另一可行实施方式中，所述支付方式可通过即时通讯方式打开相应的硬件支付与交易接收方实现即时通信。

本公开可以实现在支付方发起支付请求时，采集已存储的富媒体信息或者通过用户终端的硬件支持实时录一段视频或语音等富媒体信息，作为支付请求的附加内容添加到支付请求中发给接收方；接收方在接收对应的交易请求的时候，可以看到支付方发送的富媒体信息，实现双方的情感互动，极大地提升了用户体验。

在上述技术方案的基础上，如图2所示，为本公开示例性实施例中对富媒体信息进行简化的一示意图，所述所述获取富媒体信息之后，还可以包括有将富媒体信息存储至云服务器中以由中间服务器保存，以便于支付方和接收方随时查看该段富媒体信息，或者其中一方由可以为：

在步骤111中，上传所述富媒体信息至云服务器，并接收所述云服务器中对应于所述富媒体信息的网络地址；

支付方将采集得到的富媒体信息(或从终端的存储介质中选取)在向接收端发送时，或在支付请求达到交易服务器进行处理时，将所述支付请求的附加内容－富媒体信息抽离，使富媒体信息单独上传至云服务器进行存储，该富媒 体信息全部上传完毕之后，由所述云服务器生成一对应于该富媒体信息的网络地址(url，Uniform Resoure Locator，统一资源定位器)。

所述将所述富媒体信息添加至红包，包括：

在步骤112中，向交易接收端发起支付请求时，将所述支付请求与所述网络地址一起提交至交易接收端。

云服务器返回该网络地址url至支付方或者所述支付请求所对应的交易服务器中，使该网络地址url作为所述支付请求的附加内容，或将url的代码写入支付请求中，以由支付端将二者一直发送至交易接收端。

在本公开示例性实施例的另一种实施场景中，还可能存在有支付方同时发起多个支付请求的情况，在支付方发起多个支付请求时，可分别建立支付请求与其附加的富媒体信息之间的对应关系，根据该对应关系使所述云服务器返回的网络地址能够正确返回到对应的原支付请求中。

通过将富媒体信息上传至云服务器并使支付方接收其网络地址的益处在于，该网络地址可多次使用，在支付方更换其所在的网络环境时，也可通过该种方式发送出包含有富媒体信息等内容的支付请求，极大地减少了支付方的流量占用，并使得支付请求在发送时所占用的字节数据大幅降低，接收端在接收到该种类型的支付请求时，对于其中的富媒体信息，可根据所处的网络环境选择性地通过向云服务器请求的方式通过流媒体形式在接收端的移动终端中进行播放，对双方而言都避免了额外的流量浪费。

图3为本公开示意性实施例示出的接收端以缩略图的形式接收支付请求后的效果示意图；如图3所示，将所述支付请求与所述网络地址一起提交至交易接收端，包括：

在步骤310中，上传所述富媒体信息至云服务器，并接收所述云服务器中对应于所述富媒体信息的网络地址；

在步骤320中，向交易接收端发起支付请求；

在步骤330中，将所述支付请求以及所述网络地址通过缩略图发送至所述交易接收端；

可选择在支付方的终端中生成所述缩略图，或者在中间的交易服务器中生成所述缩略图。

所述缩略图中包含所述交易请求以及所述网络地址和/或所述富媒体信息的超链接，通过点击该缩略图可通过超链接打开所述支付请求以及所述网络地址。

所述支付请求以及网络地址均以代码形式出现，并且分别对应地在云服务器以及交易服务器中包含有一存储位置，可通过网络方式对该支付请求以及网络地址进行请求。

所述缩略图在接收端中接收时显示，该缩略图带有超链接形式，所述接收端在接收该缩略图时，在该缩略图正文可附配文字对该缩略图进行说明，以说明该缩略图的作用以及目的，所述缩略图到达所述交易接收端时，在所述交易接收端中显示的所述支付请求以及所述网络地址为所述缩略图，而不再显示所述支付请求或富媒体信息的网络地址。

在接收端的使用者点击该缩略图，可使得同时打开所述交易服务器的交易请求和/或云服务器的网络地址，从而实现接收支付方的支付请求以及富媒体信息的目的。

如图4所示，在添加富媒体信息的过程中还可对支付请求的类型进行选取， 以避免支付方或者接收方无法播放所述富媒体信息的情形发生，在采集富媒体信息作为附加内容添加至所述支付请求中时，可对支付请求的类型进行检测，其可包括：

在步骤410中，检测所述支付请求的类型，以判断该支付请求是否能添加附加内容；

所述支付请求按照能否添加附加内容，可分为能够添加附加内容的支付请求以及不能添加附加内容的支付请求。

在本步骤中，对所述支付请求的类型的检测，可理解为对用户意图的一种判断，例如用户无意发送富媒体信息时，则会选取简单的支付请求(即不能添加附加内容的支付请求)直接发送至接收方，在默认方式下，本终端中会采用向用户提供能够添加附加内容的支付请求。

另一种方式中，也可在向用户提供能够添加附加内容的支付请求的情况下，由用户自行选择关闭该支付请求的附加内容选项，或者直接将其附加内容选项设置为空白，则所述支付请求会转变为不能添加附加内容的支付请求并发送至接收方。

在步骤420中，当所述支付请求的类型为可添加附加内容时，启动所述支付请求所在用户终端的硬件支持；

根据步骤410的检测结果，在检测结果为所述支付请求可添加附加内容时，与终端中的系统联系以启动其中的几项硬件支持，或者根据用户的设置自动开启其中的一项或者几项硬件支持，例如，在终端中提供的麦克风、摄像头等硬件支持。

在步骤430中，通过所述用户终端的硬件支持采集富媒体信息以作为所述 支付请求的附加内容。

启动硬件支持后，则可通过支付方的移动终端上的硬件完成对富媒体信息的采集，该过程可包括：通过摄像头录制一预设时间的视频文件，通过麦克风录制一预设时间的音频文件，等等。

本步骤中也包括在检测为所述支付请求的类型为可添加附加内容时，选择终端中存储的富媒体文件来作为附加内容，例如，通过一定的路径选择存储的flash(动画)、流媒体、视频、音频中等。

另一种可行方式是，可由另外一云服务器向支付方提供各类模板，使用户按照该类型的模板录制富媒体信息，从而支付方发送的富媒体信息的格式能够与所述另外一云服务器相一致，由于所述格式可以被统一成任意一方的移动终端支持的标准格式，如mp4格式，使得在接收方接收时能够直接显示，无须富媒体信息的格式转换。

当所述支付请求不能添加附加内容时，可进行步骤440以更改该支付请求的类型。

如图5所示，为本公开的当一个支付请求对应有多个交易接收方时的方法流程图，结合图示，所述发起向交易接收端进行支付的支付请求时包括：

在步骤510中，获取所述支付请求所对应的交易数M；

在一“群红包”玩法的实施方式中，发送群红包的支付方可设置该支付请求所对应的红包个数，即设置好所述支付请求所对应的交易数。

在检测到所述交易数时，所述支付请求在发送至交易服务器时被拆分成对应交易数的子支付请求。

在步骤520中，检测所述支付请求所对应的交易额；

每一支付请求，可由支付方对其设定要交易的金额，即交易额，该交易额可从与支付方有关的账户中直接扣除。

在步骤530中，生成对应交易数的交易子请求；

所述支付请求在达到交易服务器时，根据对应交易数的子支付请求分别在交易服务器中通过原子减操作生成对应的交易子请求。

在步骤540中接收到一交易子请求的接收方，可获取该交易子请求对应的金额，以及交易子请求附加内容富媒体信息。

各交易子请求内所包含的交易金额可以相等，也可以不相等，该部分可由支付方进行设置。

在步骤550中，获取接收端的个数N；

当一个支付请求对应地有多个接收端时，每一接收端对应地具有一接收交易子请求，检测所述接收交易子请求的总数是否超过所述支付请求所对应的交易数；

在步骤560中，判断接收交易子请求N是否超出交易数M；

在步骤570中，当检测到的接收端个数M超过所述支付请求的交易数N时，生成有效接收交易子请求；

按照时间顺序原则，将在达到所述支付请求的交易数内的接收交易子请求列为有效接收交易子请求。

有效接收交易子请求的个数对应地等于所述支付请求的交易数。

所有的有效接收交易子请求的金额之和，为所述支付请求所包括的总金额。

生成的有效接收交易子请求同样还包括有对所述支付请求的附加内容的富媒体信息。

在步骤580中、生成无效接收交易子请求；

当所述接收交易子请求的总数N超过所述支付请求所对应的交易数M时，按照时间顺序排列在所述支付请求的交易数内的接收交易子请求，为无效接收交易子请求。

对应于无效接收交易子请求，同样地生成一无效子交易额，该无效子交易额同样地包括有所述支付请求的富媒体信息(或其网络地址)，以实现支付方和接收方的情感交互。

通过本公开的方法，使得同一个支付方用户作为一个支付方可以发起一个对应有多个接收方的红包，并且结合将该支付方用户上传云服务器中的富媒体信息的网络地址也可以随红包发送至多个接收方，使得该用户能够同时与多个交易接收端的用户实现互动，极大了提升了用户体验。

图6为根据一示例性实施例示出的一种支付处理装置的框图，其应用于用于交易发起端，如图6所示，所述装置包括获取模块610、添加模块620以及发送模块630，其中的两两模块之间可实现通讯连接，且均可与移动终端中的中心控制模块通讯连接。

其中的获取模块610，被配置为获取富媒体信息；

其中的添加模块620，被配置为将所述富媒体信息添加至红包；

其中的发送模块630，被配置为发送所述红包至交易接收端；

其中，所述富媒体信息用于在所述交易接收端被打开时，显示于所述交易接收端。

本公开示例性实施例通过获取模块610获取富媒体信息并将获取得到的富媒体信息通过添加模块620添加到红包中，使得用户可以通过发送模块630发 送带有富媒体信息的红包至接收端用户中，实现了支付方与接收方之间的互动。

在本公开示例性实施例的另一种实施场景中，所述获取模块610包括：

第一获取子模块，被配置为开启摄像装置以采集视频信息形成的富媒体信息；和/或

第二获取子模块，被配置为开启拾音装置以采集音频信息形成的富媒体信息；

所述富媒体信息包括动画信息、流媒体信息、视频信息、音频信息、文字信息中的任意一种或者任意组合。

在本公开示例性实施例的另一种实施场景中，如图7所示，本公开的装置还包括：

上传模块710，被配置为上传所述富媒体信息至云服务器，并接收所述云服务器中对应于所述富媒体信息的网络地址；

所述添加模块包括：

共同发送子模块720，被配置为向交易接收端发起支付请求时，将所述支付请求与所述网络地址发送至所述交易接收端。

图8是根据一示例性实施例示出的所述发送模块630的一种框图，如图7所示，所述发送模块630包括缩略图模块631，其被配置用于将所述支付请求以及所述网络地址通过缩略图发送至所述交易接收端；

其中，所述交易接收端中显示的所述支付请求以及所述网络地址为所述缩略图；所述缩略图中包含所述交易请求以及所述网络地址和/或所述富媒体信息的超链接，通过点击该缩略图可通过超链接打开所述支付请求以及所述网络地址。

图9是根据一示例性实施例示出的所述采集模块620的一种框图，如图7所示，所述添加模块620包括：

检测子模块910，被配置为检测所述支付请求的类型；

启动子模块920，被配置为当所述支付请求的类型为可添加附加内容时，启动所述支付请求所在用户终端的硬件支持；

采集子模块930，被配置为通过所述用户终端的硬件支持采集富媒体信息以作为所述支付请求的附加内容。

更改子模块940，被配置为当所述支付请求的类型为非可添加附加内容时，对所述支付请求的类型进行更改，以使当前用户可以发送附加有富媒体信息的红包类型的支付请求；然后通过返回子模块950返回步骤920。

图10是根据一示例性实施例示出的所述发送模块630的一种框图，如图10所示，所述发送模块630还包括：

第二检测模块1032，用于获取所述支付请求所对应的交易数以及交易额，以在交易服务器中通过原子减操作生成对应所述交易数的交易子请求，各交易子请求为有效支付请求，各所述交易子请求所对应的子交易额之和为所述支付请求所对应的交易额。

图10是根据一示例性实施例示出的所述发送模块630的一种框图，如图10所示，所述发送模块630还包括：

第三检测模块1033，被配置用于检测所述交易子请求的总数是否超过所述支付请求所对应的交易数；

无效子模块1034，被配置用于对于所述交易子请求的总数超过所述支付请求所对应的交易数的交易子请求，生成一无效子交易额；

有效子模块1035，被配置用于对于所述交易子请求的总数未超过所述支付请求所对应的交易数的交易子请求，生成一有效子交易额。

上述实施例中提供的支付处理装置可执行本公开中任意实施例中所提供的支付处理方法，具备执行该方法相应的功能模块和有益效果，未在上述实施例中详细描述的技术细节，可参见本公开任意实施例中所提供的支付处理方法。

将意识到的是，本公开也扩展到适合于将本公开付诸实践的计算机程序，特别是载体上或者载体中的计算机程序。程序可以以源代码、目标代码、代码中间源和诸如部分编译的形式的目标代码的形式，或者以任何其它适合在按照本公开的方法的实现中使用的形式。也将注意的是，这样的程序可能具有许多不同的构架设计。例如，实现按照本公开的方法或者系统的功能性的程序代码可能被再分为一个或者多个子例程。

用于在这些子例程中间分布功能性的许多不同方式将对技术人员而言是明显的。子例程可以一起存储在一个可执行文件中，从而形成自含式的程序。这样的可执行文件可以包括计算机可执行指令，例如处理器指令和/或解释器指令(例如，Java解释器指令)。可替换地，子例程的一个或者多个或者所有子例程都可以存储在至少一个外部库文件中，并且与主程序静态地或者动态地(例如在运行时间)链接。主程序含有对子例程中的至少一个的至少一个调用。子例程也可以包括对彼此的函数调用。涉及计算机程序产品的实施例包括对应于所阐明方法中至少一种方法的处理步骤的每一步骤的计算机可执行指令。这些指令可以被再分成子例程和/或被存储在一个或者多个可能静态或者动态链接的文件中。

另一个涉及计算机程序产品的实施例包括对应于所阐明的系统和/或产 品中至少一个的装置中每个装置的计算机可执行指令。这些指令可以被再分成子例程和/或被存储在一个或者多个可能静态或者动态链接的文件中。

计算机程序的载体可以是能够运载程序的任何实体或者设备。例如，载体可以包含存储介质，诸如(ROM例如CD ROM或者半导体ROM)或者磁记录介质(例如软盘或者硬盘)。进一步地，载体可以是可传输的载体，诸如电学或者光学信号，其可以经由电缆或者光缆，或者通过无线电或者其它手段传递。当程序具体化为这样的信号时，载体可以由这样的线缆或者其它设备或者装置组成。可替换地，载体可以是其中嵌入有程序的集成电路，所述集成电路适合于执行相关方法，或者供相关方法的执行所用。

应该留意的是，上文提到的实施例是举例说明本公开，而不是限制本公开，并且本领域的技术人员将能够设计许多可替换的实施例，而不会偏离所附权利要求的范围。在权利要求中，任何放置在圆括号之间的参考符号不应被解读为是对权利要求的限制。动词“包括”和其词形变化的使用不排除除了在权利要求中记载的那些之外的元素或者步骤的存在。在元素之前的冠词“一”或者“一个”不排除复数个这样的元素的存在。本公开可以通过包括几个明显不同的元件的硬件，以及通过适当编程的计算机而实现。在列举几种装置的设备权利要求中，这些装置中的几种可以通过硬件的同一项来体现。在相互不同的从属权利要求中陈述某些措施的单纯事实并不表明这些措施的组合不能被用来获益。

如果期望的话，这里所讨论的不同功能可以以不同顺序执行和/或彼此同时执行。此外，如果期望的话，以上所描述的一个或多个功能可以是可选的或者可以进行组合。

如果期望的话，上文所讨论的各步骤并不限于各实施例中的执行顺序，不 同步骤可以以不同顺序执行和/或彼此同时执行。此外，在其他实施例中，以上所描述的一个或多个步骤可以是可选的或者可以进行组合。

虽然本公开的各个方面在独立权利要求中给出，但是本公开的其它方面包括来自所描述实施方式的特征和/或具有独立权利要求的特征的从属权利要求的组合，而并非仅是权利要求中所明确给出的组合。

这里所要注意的是，虽然以上描述了本公开的示例实施方式，但是这些描述并不应当以限制的含义进行理解。相反，可以进行若干种变化和修改而并不背离如所附权利要求中所限定的本公开的范围。

本领域普通技术人员应该明白，本公开实施例的装置中的各模块可以用通用的计算装置来实现，各模块可以集中在单个计算装置或者计算装置组成的网络组中，本公开实施例中的装置对应于前述实施例中的方法，其可以通过可执行的程序代码实现，也可以通过集成电路组合的方式来实现，因此本公开并不局限于特定的硬件或者软件及其结合。

本领域普通技术人员应该明白，本公开实施例的装置中的各模块可以用通用的移动终端来实现，各模块可以集中在单个移动终端或者移动终端组成的设备组合中，本公开实施例中的装置对应于前述实施例中的方法，其可以通过编辑可执行的程序代码实现，也可以通过集成电路组合的方式来实现，因此本公开并不局限于特定的硬件或者软件及其结合。

图11是根据一示例性实施例示出的一种用于支付处理的装置800的框图。例如，装置800可以是移动电话，计算机，数字广播终端，消息收发装置，游戏控制台，平板装置，医疗装置，健身装置，个人数字助理等。

参照图11，装置800可以包括以下一个或多个组件：处理组件802，存储 器804，电源组件806，多媒体组件808，音频组件810，输入/输出(I/O)接口812，传感器组件814，以及通信组件816。

处理组件802通常控制装置800的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件802可以包括一个或多个处理器820来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件802可以包括一个或多个模块，便于处理组件802和其他组件之间的交互。例如，处理组件802可以包括多媒体模块，以方便多媒体组件808和处理组件802之间的交互。

存储器804被配置为存储各种类型的数据以支持在装置800的操作。这些数据的示例包括用于在装置800上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器804可以由任何类型的易失性或非易失性存储装置或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件806为装置800的各种组件提供电源。电源组件806可以包括电源管理系统，一个或多个电源，及其他与为装置800生成、管理和分配电源相关联的组件。

多媒体组件808包括在所述装置800和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手 势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件808包括一个前置摄像头和/或后置摄像头。当装置800处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件810被配置为输出和/或输入音频信号。例如，音频组件810包括一个麦克风(MIC)，当装置800处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器804或经由通信组件816发送。在一些实施例中，音频组件810还包括一个扬声器，用于输出音频信号。

I/O接口812为处理组件802和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件814包括一个或多个传感器，用于为装置800提供各个方面的状态评估。例如，传感器组件814可以检测到装置800的打开/关闭状态，组件的相对定位，例如所述组件为装置800的显示器和小键盘，传感器组件814还可以检测装置800或装置800一个组件的位置改变，用户与装置800接触的存在或不存在，装置800方位或加速/减速和装置800的温度变化。传感器组件814可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件814还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件814还可以包括加速度 传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件816被配置为便于装置800和其他装置之间有线或无线方式的通信。装置800可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件816经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件816还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，装置800可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理装置(DSPD)、可编程逻辑组件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子组件实现，用于执行上述方法。

图12是根据一示例性实施例示出的一种用于实现富媒体信息上传云服务器的装置1900的框图。例如，装置1900可以被提供为一服务器。参照图12，装置1900包括处理组件1922，其进一步包括一个或多个处理器，以及由存储器1932所代表的存储器资源，用于存储可由处理组件1922的执行的指令，例如应用程序。存储器1932中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件1922被配置为执行指令，以执行上述支付处理方法，包括：获取富媒体信息；

将所述富媒体信息添加至红包；

发送所述红包至交易接收端；

其中，所述富媒体信息用于在所述交易接收端被打开时，显示于所述交易 接收端。

装置1900还可以包括一个电源组件1926被配置为执行装置1900的电源管理，一个有线或无线网络接口1950被配置为将装置1900连接到网络，和一个输入/输出(I/O)接口1958。装置1900可以操作基于存储在存储器1932的操作系统，例如WindowsServerTM，MacOSXTM，UnixTM,LinuxTM，FreeBSDTM或类似。

在本公开示例性实施例的另一种实施场景中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器804，上述指令可以由装置800的处理组件802执行以完成上述方法，例如，所述非临时性计算机可读存储介质可以是ROM(Read-Only Memory，只读内存)、随机存取存储器(Random-Access Memory，RAM)、CD-ROM(Compact Disc Read-Only Memory，只读光盘)、磁带、软盘、和光数据存储设备等。

本公开还提供了一种非临时性计算机可读存储介质，当所述存储介质中的指令由移动终端的处理器执行时，使得移动终端能够执行版本更新信息的处理方法，所述方法包括：

获取富媒体信息；

将所述富媒体信息添加至红包；

发送所述红包至交易接收端；

其中，所述富媒体信息用于在所述交易接收端被打开时，显示于所述交易接收端。

所述存储介质中的指令还可以包括：开启摄像装置以采集视频信息形成的富媒体信息；和/或

开启拾音装置以采集音频信息形成的富媒体信息；

所述富媒体信息包括动画信息、流媒体信息、视频信息、音频信息、文字信息中的任意一种或者任意组合。

所述存储介质中的指令还可以包括：所述获取富媒体信息之后，还包括：

上传所述富媒体信息至云服务器，并接收所述云服务器中对应于所述富媒体信息的网络地址；

所述将所述富媒体信息添加至红包，包括：

向交易接收端发起支付请求时，将所述支付请求与所述网络地址发送至所述交易接收端。

所述存储介质中的指令还可以包括：所述将所述支付请求与所述网络地址发送至所述交易接收端，包括：

将所述支付请求以及所述网络地址通过缩略图发送至所述交易接收端；

其中，所述交易接收端中显示的所述支付请求以及所述网络地址为所述缩略图；所述缩略图中包含所述交易请求以及所述网络地址和/或所述富媒体信息的超链接，通过点击该缩略图可通过超链接打开所述支付请求以及所述网络地址。

所述存储介质中的指令还可以包括：所述将所述富媒体信息添加至红包，包括：

检测所述支付请求的类型；

当所述支付请求的类型为可添加附加内容时，启动所述支付请求所在用户终端的硬件支持；

通过所述用户终端的硬件支持采集富媒体信息以作为所述支付请求的附加 内容

注意，上述仅为本公开的示例性实施例及所运用技术原理。本领域技术人员会理解，本公开不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本公开的保护范围。因此，虽然通过以上实施例对本公开进行了较为详细的说明，但是本公开不仅仅限于以上实施例，在不脱离本公开构思的情况下，还可以包括更多其他等效实施例，而本公开的范围由所附的权利要求范围决定。