CN105787733B - 一种业务信息处理方法及装置 - Google Patents

Abstract

本申请公开了一种业务信息处理方法及装置，该方法包括：接收用户账户发出的业务指令，根据该业务指令生成对应的业务信息，将所述业务信息发送至预先与该用户账户绑定的业务账户，并通过该业务账户对所述业务信息进行处理，通过所述业务账户，将处理后的所述业务信息发送至所述用户账户中。通过设置与用户账户绑定的业务账户，接收业务信息，并对该业务信息进行相应处理后发送给用户账户，那么，即使用户账户在国际业务场景下，不具备接收业务信息的功能，也可以通过业务账户接收业务信息，再发送至用户账户中。有效解决了在国际业务场景中，用户账户不能直接接收业务信息的情况，也提升了业务信息处理的效率。

Description

一种业务信息处理方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种业务信息处理方法及装置。

背景技术

随着信息技术的发展，互联网为用户提供了丰富的网络资源，用户可以通过注册用户账户的方式，便捷地获得各类业务服务。

现有技术中，通常用户获得业务服务的方式为：用户使用自身的用户账户，向相应的服务器发出业务指令，服务器在接收到用户账户发出的业务指令后，就会根据该业务指令反馈相应的业务信息至用户账户，从而，用户便获得了该业务服务。尤其对于现如今业务服务国际化的趋势，不同国家和地区的用户都可以在相同的网站中获得各类业务服务，例如：在线交易、视频订阅、信息查询等等。

但是，在国际业务环境下，由于不同国家和地区的差异，用户获得业务服务的方式、途径各不相同，同一服务器为了确保业务信息能够送达至相应的用户账户，只能按照发出业务指令的渠道反馈业务信息。如果发出业务指令的渠道不具备接收业务信息的功能，那么，将导致用户不能接收相应业务信息。

例如：在国际支付场景中，用户针对其购买的商品进行退款，该用户会通过其用户账户向服务器发出退款请求指令，服务器根据该用户的退款请求指令，将退款信息按照该用户购买商品时的付款方式(即，付款方式就是发出业务指令的渠道)，退还给用户。但是，用户进行支付时的付款方式可能是用户通过其注册的用户账户直接进行支付，而由于部分国家和地区对网络支付的要求不同，某些国家和地区禁止用户注册的用户账户等虚拟账户直接接收服务器退还的款项，只能通过银行账户接收款项，这样一来，该退款信息便不会退回至用户账户中，从而导致用户不能接收退回的款项。

发明内容

本申请实施例提供一种业务信息处理方法及装置，用以解决目前国际业务环境下，业务服务效率较低的问题。

本申请实施例提供的一种业务信息处理方法，包括：

接收用户账户发出的业务指令，根据该业务指令生成对应的业务信息；

将所述业务信息发送至预先与该用户账户绑定的业务账户，并通过该业务账户对所述业务信息进行处理；

通过所述业务账户，将处理后的所述业务信息发送至所述用户账户中。

本申请实施例提供的一种业务信息处理装置，包括：

生成模块，用于接收用户账户发出的业务指令，根据该业务指令生成对应的业务信息；

业务账户模块，用于将所述业务信息发送至预先与该用户账户绑定的业务账户，并通过该业务账户对所述业务信息进行处理；

发送模块，用于通过所述业务账户，将处理后的所述业务信息发送至所述用户账户中。

本申请实施例提供一种业务信息处理方法及装置，通过设置与用户账户绑定的业务账户，使得用户使用自身的用户账户发出相应的业务指令后，服务器可以将与该业务指令对应的业务信息发送给业务账户进行相应处理，并由该业务账户将处理完成的业务信息发送至用户账户，而不直接发给用户账户，这样一来，即使用户账户在国际业务场景下，不具备接收业务信息的功能，也可以通过业务账户接收业务信息，再发送至用户账户中。有效解决了在国际业务场景中，用户账户不能直接接收业务信息的情况，也提升了业务信息处理的效率。

附图说明

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

图1为本申请实施例提供的业务信息处理过程；

图2为本申请实施例提供的业务信息处理装置结构示意图。

具体实施方式

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

图1为本申请实施例提供的业务信息处理过程，该过程具体包括以下步骤：

S101，接收用户账户发出的业务指令，根据该业务指令生成对应的业务信息。

在本申请实施例中，当用户想要获得业务服务，并使用其用户账户发出业务指令时，可由相应的服务器接收所述业务指令，并根据该业务指令生成相应的业务信息。

其中，所述的用户账户，具体为用户预先在服务器中进行注册的个人账户。所述的业务指令为用户通过其用户账户向服务器发出的用以获得业务服务的指令，如：退款指令等。所述业务信息为服务器根据业务指令生成的业务服务结果信息，如：退款信息等。

具体例如：中国的用户A在某一网站中注册了用户名为userA的个人账户，该个人账户userA就是用户A的用户账户。当用户A使用其用户账户userA从该网站购买商品后，因商品的质量问题，用户A想要办理退款业务，该用户A便可通过其用户账户userA发出退款指令，网站的服务器会根据该退款指令生成相应的退款信息，此时，该退款指令就是业务指令，该退款信息就是业务信息。当然，在本申请实施例中，当用户账户接收到退款信息后，该用户账户中的款项额度将立即发生变化，也即，用户账户中的款项额度将立即增加退款信息中的款项额度，接收退款信息也就意味着退款业务已经办理成功。

这里需要说明的是，当用户使用其用户账户发出业务指令，如：退款指令时，服务器会根据该退款指令，查询该退款指令对应的业务服务操作的详细信息，包括：进行支付时的额度、支付的渠道等信息，服务器将根据查询到的这些信息生成相应的业务信息，也即，退款信息。因此，在本申请实施例中，所述业务信息包括支付渠道和/或退款额度。

S102，将所述业务信息发送至预先与该用户账户绑定的业务账户中，并通过该业务账户对所述业务信息进行处理。

延续上例进行说明，假设用户A在购买商品时，其支付渠道(此处的支付渠道是指用户A向商品卖家支付款项的渠道)为：用户A使用自身的用户账户userA中预先存储的余额直接进行支付。则服务器为用户A办理退款业务时，相应的支付渠道(此处的支付渠道是指服务器向用户A支付退款金额的渠道)为：服务器将用户A支付的款项发送至用户A自身的用户账户userA中。而在现有技术中的国际业务服务场景下，由于部分国家和地区的规定，不允许服务器直接将退款信息发送至用户账户中，那么，服务器也就不能按照支付渠道发送退款信息，也即，服务器不能将退款信息直接发送至用户账户userA中。

因此，为了解决支付渠道不能接收业务信息的问题，在本申请实施例中，通过设置相应业务账户的方式，接收服务器生成的业务信息。

本申请实施例中所述的业务账户，具体为允许接收业务信息的非个人账户，如：企业账户。当然，在本申请实施例中，所述业务账户也是预先在所述服务器中进行注册的账户。例如：上述网站可以注册所属国家为中国的业务账户China-user，该业务账户China-user预先与用户账户userA进行绑定，服务器可以将相应的退款信息发送至业务账户China-user中。

此处需要说明的是，服务器将包含有退款额度的业务信息发送至业务账户中后，该业务账户中的额度值并不会立即发生变化，这是因为：对于服务器而言，所述业务信息中包含的退款额度，仅仅是一种字符类信息，其反映了退款额度的数值。在用户进行退款操作的过程中，额度值的变化实际上就是相应的银行账户中存储额度发生了变化，也就是说，服务器在对退款操作进行处理时，需要与银行系统(如：银行服务器)进行交互，并在银行系统对退款操作所对应的额度进行记录处理后，服务器才会改变用户账户中额度的数值。

根据上述分析，对于步骤S102，当服务器将所述业务信息发送至业务账户中后，通过该业务账户对所述业务信息进行处理，具体为：该业务账户将根据所述业务信息中的退款额度，与相应的银行系统进行交互，使银行系统记录该退款额度，也即，银行系统会将该退款额度记录在用户账户所对应的银行账户(如：与用户账户绑定的银行卡)中。

例如：在上例中，业务账户China-user在接收到针对用户账户userA的退款额度后，会向该用户账户userA所对应的银行系统进行交互，使得该银行系统将该退款额度记录在userA对应的银行账户中。

另外，实际应用场景中，服务器针对不同国家和地区的用户账户生成的业务信息并不相同，例如：假设业务信息为退款信息，那么，由于不同国家和地区的币种的区别，服务器将根据用户账户在支付时所使用的币种，生成对应币种的退款信息。在这样的情况下，如果用户账户与其绑定的业务账户不属于同一国家和地区，其退款信息将受到汇率差的影响，导致退款信息出现一定的汇率波动误差。

因此，在本申请实施例中的一种优选方式下，当用户完成用户账户的注册时，服务器可根据确定出的用户账户以及业务账户所属的国家和地区，自动将属于同一国家和地区的用户账户与业务账户进行绑定。需要说明的是，在国际业务场景下的用户来自不同国家和地区，当用户在相应的服务器中注册用户账户时，服务器可以根据用户的互联网协议地址(Internet Protocol，IP地址)，确定出该用户账户所属的国家和地区。同样，服务器在所述业务账户进行注册时，也可根据相应的IP地址，确定所述业务账户所属的国家和地区。

当然，在实际应用中，是否自动按照用户账户以及业务账户所属的国家和地区进行绑定，可根据实际应用时的需要进行设定，这里并不构成对本申请的限定。

在本申请实施例的一种方式下，一个业务账户可与多个用户账户进行绑定，即，所属国家和地区相同的用户账户，可以与同样属于该国家和地区的业务账户进行绑定，此时，该业务账户为公共的业务账户。各用户账户的业务信息，均暂存在该公共的业务账户中。当然，在公共的业务账户中，记录有不同的用户账户对应的业务信息，并不会出现业务信息混乱的情况。

S103，通过所述业务账户，将处理后的所述业务信息发送至所述用户账户中。

业务账户中存储有不同用户账户的业务信息，经过上述的处理过程，银行系统已经将退款额度记录在用户账户所绑定的银行账户中，这样一来，通过业务账户，就可以将该业务账户中存储的业务信息，分别发送至这些业务信息对应的各用户账户中，使不同的用户账户所保存的款项额度的数值发生变化。业务账户向将业务信息发送至用户账户的过程，可看作账户与账户之间进行信息交互的过程，从而业务信息能够有效地发送至用户账户。

延续上例：服务器可以通过业务账户China-user，将退款信息发送至用户账户userA中，从而，用户账户userA便获得了来自服务器的退款，该用户账户userA中的款项额度的数值将发生变化，从而完成退款业务。

通过上述步骤，在服务器中预先注册具有接收并发送业务信息权限的业务账户，当不同用户在该服务器中注册了相应的用户账户时，将同一国家和地区的用户账户与同属于该国家和地区的业务账户进行绑定，这样一来，当服务器根据用户账户发出的业务指令，生成对应的业务信息时，可以直接发送至该业务账户，再由该业务账户将该业务信息发送至相应的用户账户中，从而，可以有效保证业务信息可以送达用户账户。

在实际应用中的国际业务服务场景下，用户在注册用户账户时，需要将相应的银行账户(如：银行卡)与该用户账户建立关联，以便在业务服务中进行支付等操作。那么，当所述业务信息中包括退款额度时，可采用上述步骤S102至S103的方式，将所述业务信息发送至与所述用户账户绑定的业务账户中，再通过该业务账户将业务信息直接发送至用户账户对应的银行账户中。

继续沿用上例：用户A使用自身的银行卡X与其用户账户userA进行关联，也即，银行卡X就是该用户账户userA的银行账户。假设用户A在购买某商品时，其支付渠道为：用户A使用该银行卡X进行支付，那么，用户A使用其用户账户userA向服务器发出退款指令后，服务器会将相应的退款信息发送至与用户账户userA绑定的业务账户China-user中，并根据支付渠道，通过该业务账户China-user，将退款信息发送至银行卡X中，完成退款业务。

但是，不同银行对于此类退款业务，设置有相应的额度限制，也即，只有退款额度达到该银行设置的规定额度时，银行才会接收该业务信息，而对于未达到规定额度的业务信息，银行通常不予受理。也就是说，若用户账户的业务信息未达到银行设置的规定额度时，就会造成业务信息不能发送至该用户的银行账户的情况。例如：假设银行卡X所属银行的最低退款额度为10元，若退款信息中包含的额度仅为8元，那么，银行将不予受理，也即，此次退款操作将失败。

因此，当所述业务信息中包括退款额度时，在上述步骤S103中，将处理后的所述业务信息发送至所述用户账户中，具体为：判断所述业务信息是否满足预置条件，若是，则通过所述业务账户，将所述业务信息发送至用户账户对应的银行账户中，否则，则存储所述业务信息至信息集合中，知道所述信息集合中的所有业务信息的总量满足所述预设条件时，将所述业务信息发送至所述用户账户对应的银行账户中。

而在本申请实施例中，由于业务信息中包括退款额度，故判断所述业务信息是否满足预置条件，实际上就是判断所述业务信息中包含的退款额度是否高于最低退款额度(即银行设置的规定额度)。若是，就表明业务信息中的退款额度高于或等于银行设置的最低退款额度，则判定所述业务信息满足所述预置条件。否则，就表明业务信息中的退款额度低于银行设置的最低退款额度，则判定所述业务信息不满足预置条件。

对于业务信息满足预置条件的情况，就可以通过业务账户，将业务信息发送至相应的银行账户中。

但是，对于业务信息不满足预置条件的情况，用户账户对应的银行账户将不会接收该业务信息，也就不能通过业务账户将业务信息发送用户账户对应的银行账户。此时，服务器可将不满足预置条件的业务信息，存储在业务账户中的信息集合中。

具体地，考虑到用户可能多次使用其用户账户获得业务服务，服务器也就会多次将相应的业务信息发送至业务账户中，这样经过一段时间的累积后，存储在该业务账户中的业务信息总量可能就会满足预置的条件。因此，在本申请实施例中的一种方式下，存储所述业务信息至信息集合中，具体为：将所述业务信息存储至所述用户账户对应的信息集合中，直到所述信息集合中的所有业务信息的总量满足所述预设条件时，将所述业务信息发送至所述用户账户对应的银行账户中，具体为：当所述信息集合中的所有业务信息中包含的退款额度之和高于所述最低退款额度时，将所述业务信息发送至所述用户账户对应的银行账户中。

下面沿用上例进行具体说明：

用户A使用该用户账户userA在该网站中购买某商品，并使用与该用户账户userA绑定的、由银行1发行的银行卡X支付RMB 4元后，因商品的质量问题，用户A使用其用户账户userA发出退款指令。服务器接收到该退款指令后，会将生成的退款信息发送至与用户账户userA绑定的业务账户China-user中。其中，该退款信息中包含有RMB 4元的退款额度。

此时，假设银行1设置的最低退款额度为RMB 10元，显然，退款信息中的退款额度(RMB 4元)低于该银行1的最低退款额度，从而便不能通过该业务账户China-user将退款信息发送至银行卡X中。

因此，服务器会将该退款信息存储在业务账户China-user中对应于用户账户userA的信息集合中，该信息集合用于存储该用户账户userA的所有退款信息。

在一段时间后，用户A使用其用户账户userA购买商品支付的RMB 8元，并出于同样原因向服务器发出退款指令，服务器将生成的退款信息发送业务账户China-user中对应于用户账户userA的信息集合中，此时退款信息的退款额度的总量为RMB 12元，高于银行1的最低退款额度，从而服务器通过业务账户China-user将退款额度总量为RMB 12元的退款信息发送至用户A的银行卡X中，完成退款业务。

从上例可见，上述方式是对单一用户账户的业务信息进行存储累积，当单一用户账户的业务信息不满足预设条件时，可以将该用户账户的业务信息存储在业务账户中的信息集合中，累积所述业务信息，直到所述业务信息的总量满足所述预设条件，便可以将业务信息发送至该用户账户对应的银行账户中，完成退款操作。

但是，在实际应用中，某些用户使用其用户账户的频率较低，该用户可能在较长时间内不使用该用户账户进行业务服务操作，在这样的情况下，若采用上述对单一用户账户的业务信息进行存储累积的方式，由于该用户较长时间不使用该用户账户，将会导致该用户账户的业务信息将长时间存储在业务账户中，而不能发送至该用户账户对应的银行账户中，严重降低了退款业务的处理效率。

因此，为了提高退款业务的处理效率，在本申请实施例的另一种方式下，存储所述业务信息至信息集合中，具体为：确定所述用户账户对应的银行账户所属的银行类型，将所述业务信息存储至确定的所述银行类型对应的信息集合中。当所述信息集合中的所有业务信息中包含的退款额度之和高于所述最低退款额度时，将所述业务信息发送至所述用户账户对应的银行账户中。也即，这样的方式，将同属于同一银行类型的多个银行账户的业务信息共同进行存储累积，有效增加了业务信息的存储累积效率。

这里需要说明的是，银行类型对应的信息集合中，含有多个用户账户的业务信息(有些业务信息中包含的退款额度满足预设条件，而有些则不满足预设条件)，将这些业务信息发送至各自对应的银行账户时，若针对不同业务账户的业务信息进行单独发送，由于有些业务信息不满足预设条件，银行不予受理。从而，只能将这些业务信息一并发送至某一公共的银行账户中，再在该银行内进行分发处理。因此，在本申请实施例中，业务账户针对不同的银行类型，关联设置有不同的银行账户，即公共银行账户。这样一来，当采用对多个银行账户的业务信息共同进行存储累积的方式时，就可以将满足预设条件的信息集合中的业务信息一并发送至公共银行账户中，再将该公共银行账户中的业务信息发送至不同用户账户对应的银行账户中。

下面以一应用实例对上述方式进行具体说明：

在本应用实例中，用户A的用户账户仍为userA，银行账户为银行卡X，该银行卡X所属的银行类型为银行1，并且在本例中增加了中国的用户B和用户C，其中，对于用户B而言，其用户账户为userB，银行账户为银行卡Y，该银行卡Y所属的银行类型为银行2，银行2设置的最低退款额度为RMB 8元。

对于用户C而言，其用户账户为userC，银行账户为银行卡Z，该银行卡Z所属的银行类型为银行1。

由于用户账户userB及userC所属的国家都为中国，服务器会将用户账户userB及userC与业务账户China-user进行绑定。

另外，在本应用实例中，业务账户China-user针对银行1关联设置的公共银行账户为银行卡CN1，针对银行2关联设置的公共银行账户为银行卡CN2。

具体过程为：

与上例相同，用户A使用该用户账户userA发出退款指令。服务器将生成的退款信息发送至与用户账户userA绑定的业务账户China-user中。其中，该退款信息中包含有RMB4元的退款额度。

用户B使用其用户账户userB发出退款指令，要求退还额度为RMB 6元的款项。服务器接收到该退款指令后，会将生成的退款信息发送至与用户账户userB绑定的业务账户China-user中。其中，该退款信息中包含有RMB 6元的退款额度。

用户C使用其用户账户userC发出退款指令，要求退还额度为RMB 9元的款项。服务器接收到该退款指令后，会将生成的退款信息发送至与用户账户userC绑定的业务账户China-user中。其中，该退款信息中包含有RMB 9元的退款额度。

服务器现确定用户账户userA、userB以及userC各自的退款信息均不满足银行设置的最低退款额度。因此，服务器将存储业务信息至信息集合中。

此时，服务器确定用户账户userA对应的银行卡X，以及用户账户userC对应的银行卡Z所属的银行类型均是银行1，那么，服务器会将用户账户userA和userC的退款信息存储至业务账户China-user内银行1对应的信息集合中。从而，在银行1对应的信息集合中，退款信息中包含的退款额度之和为RMB 13元，高于银行1设置的最低退款额度RMB 10元。因此，服务器可将退款信息一并发送至银行1中，也即，发送至银行卡CN1中。之后，银行1再将该银行卡CN1中的退款信息分别发送至银行卡X和银行卡Z中。

服务器确定用户账户userB对应的银行卡Y所属的银行类型是银行2，服务器会将用户账户userB的退款信息，以及银行账户所属的银行类型是银行2的其他用户账户(在本例中未具体示出)的退款信息，均存储至业务账户China-user内银行2对应的信息集合中。并当银行2对应的信息集合中，退款信息中包含的退款额度之和高于银行2设置的最低退款额度RMB 8元后，将该信息集合中的退款信息一并发送至银行卡CN2中，再由银行2将该银行卡CN2中的退款信息分发至不同的银行账户中。从而完成退款业务。

从上例可见，上述方式是对银行账户所属银行类型相同的多个用户账户的业务信息进行共同存储累积，即使某一用户账户的业务信息不满足预设条件，也可以通过共同存储累积的方式，使信息集合中存储的业务信息的总量在短时间内满足预设条件，有效增加了业务信息的存储累积效率。

当然，在实际应用场景下，通过业务账户，将退款信息发送至银行账户时，会产生相应的手续费，那么，对于同一用户账户而言，该用户账户有多个退款信息的情况下，则会产生多笔手续费。因此，可以采用本申请实施例中的方式，对同一用户账户的多个退款信息进行存储累积，当多个退款信息中包含的退款额度之和高于预设值时，将多个退款信息一并发送。从而有效降低退款时产生的手续费。

以上为本申请实施例提供的业务信息处理方法，基于同样的思路，本申请实施例还提供一种业务信息处理装置，如图2所示。

在图2中，所述业务信息处理装置包括：生成模块201、业务账户模块202以及发送模块203，其中，

所述生成模块201，用于接收用户账户发出的业务指令，根据该业务指令生成对应的业务信息。

所述业务账户模块202，用于将所述业务信息发送至预先与该用户账户绑定的业务账户，并通过该业务账户对所述业务信息进行处理。

所述发送模块203，用于通过所述业务账户，将处理后的所述业务信息发送至所述用户账户中。

在本申请实施例中，所述业务指令为退款指令，所述业务信息为退款信息，所述业务信息包括支付渠道和/或退款额度。

当所述业务信息中包括退款额度时，所述发送模块203，具体用于判断所述业务信息是否满足预设条件，若是，则通过所述业务账户，将所述业务信息发送至用户账户对应的银行账户中；否则，则存储所述业务信息至信息集合中，直到所述信息集合中的所有业务信息的总量满足所述预设条件时，将所述业务信息发送至所述用户账户对应的银行账户中。

所述发送模块203，具体用于判断所述业务信息中包含的退款额度是否高于最低退款额度，若是，则判定所述业务信息满足所述预设条件；否则，则判定所述业务信息不满足所述预设条件。

所述发送模块203，具体用于确定所述用户账户对应的银行账户所属的银行类型，将所述业务信息存储至确定的所述银行类型对应的信息集合中，当所述信息集合中的所有业务信息中包含的退款额度之和高于所述最低退款额度时，将所述业务信息发送至所述用户账户对应的银行账户中。

所述发送模块203，具体用于将所述业务信息存储至所述用户账户对应的信息集合中，当所述信息集合中的所有业务信息中包含的退款额度之和高于所述最低退款额度时，将所述业务信息发送至所述用户账户对应的银行账户中。

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

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

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

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

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

Claims (12)

1.一种业务信息处理方法，其特征在于，包括：

服务器接收用户账户发出的业务指令，根据该业务指令生成对应的业务信息；所述用户账户为用户预先在所述服务器中进行注册的个人账户；

所述服务器将所述业务信息发送至预先与该用户账户绑定的业务账户，并通过该业务账户对所述业务信息进行处理；所述业务账户为预先在所述服务器中进行注册的账户，所述业务账户为允许接收所述业务信息的非个人账户；所述服务器根据所述用户账户以及所述业务账户所属的国家和地区，将属于同一国家和地区的所述用户账户与所述业务账户进行绑定；

通过所述业务账户，将处理后的所述业务信息发送至所述用户账户中，

其中，所述业务指令为退款指令，所述业务信息为退款信息，所述业务信息包括退款额度；

其中，所述根据该业务指令生成对应的业务信息，具体包括：根据用户账户在支付时所使用的币种，生成对应币种的退款信息；

其中，所述通过该业务账户对所述业务信息进行处理，具体包括：所述业务账户根据所述业务信息中的退款额度，与银行系统进行交互，使所述银行系统记录所述退款额度。

2.如权利要求1所述的方法，其特征在于，所述业务信息还包括支付渠道。

3.如权利要求2所述的方法，其特征在于，当所述业务信息中包括退款额度时，将处理后的所述业务信息发送至所述用户账户中，具体包括：

判断所述业务信息是否满足预设条件；

若是，则通过所述业务账户，将所述业务信息发送至用户账户对应的银行账户中；

否则，则存储所述业务信息至信息集合中，直到所述信息集合中的所有业务信息的总量满足所述预设条件时，将所述业务信息发送至所述用户账户对应的银行账户中。

4.如权利要求3所述的方法，其特征在于，判断所述业务信息是否满足预设条件，具体包括：

判断所述业务信息中包含的退款额度是否高于最低退款额度；

若是，则判定所述业务信息满足所述预设条件；

否则，则判定所述业务信息不满足所述预设条件。

5.如权利要求4所述的方法，其特征在于，存储所述业务信息至信息集合中，具体包括：

确定所述用户账户对应的银行账户所属的银行类型；

将所述业务信息存储至确定的所述银行类型对应的信息集合中；

直到所述信息集合中的所有业务信息的总量满足所述预设条件时，将所述业务信息发送至所述用户账户对应的银行账户中，具体包括：

当所述信息集合中的所有业务信息中包含的退款额度之和高于所述最低退款额度时，将所述业务信息发送至所述用户账户对应的银行账户中。

6.如权利要求4所述的方法，其特征在于，存储所述业务信息至信息集合中，具体包括：

将所述业务信息存储至所述用户账户对应的信息集合中；

直到所述信息集合中的所有业务信息的总量满足所述预设条件时，将所述业务信息发送至所述用户账户对应的银行账户中，具体包括：

当所述信息集合中的所有业务信息中包含的退款额度之和高于所述最低退款额度时，将所述业务信息发送至所述用户账户对应的银行账户中。

7.一种业务信息处理装置，其特征在于，包括：

生成模块，用于服务器接收用户账户发出的业务指令，根据该业务指令生成对应的业务信息；所述用户账户为用户预先在服务器中进行注册的个人账户；其中，所述业务指令为退款指令，所述业务信息为退款信息，所述业务信息包括退款额度；其中，所述根据该业务指令生成对应的业务信息，具体包括：根据用户账户在支付时所使用的币种，生成对应币种的退款信息；

业务账户模块，用于所述服务器将所述业务信息发送至预先与该用户账户绑定的业务账户，并通过该业务账户对所述业务信息进行处理；所述业务账户为预先在所述服务器中进行注册的账户，所述业务账户为允许接收所述业务信息的非个人账户；所述服务器根据所述用户账户以及所述业务账户所属的国家和地区，将属于同一国家和地区的所述用户账户与所述业务账户进行绑定；其中，所述通过该业务账户对所述业务信息进行处理，具体包括：所述业务账户根据所述业务信息中的退款额度，与银行系统进行交互，使所述银行系统记录所述退款额度；

发送模块，用于通过所述业务账户，将处理后的所述业务信息发送至所述用户账户中。

8.如权利要求7所述的装置，其特征在于，所述业务信息还包括支付渠道。

9.如权利要求8所述的装置，其特征在于，当所述业务信息中包括退款额度时，所述发送模块，具体用于判断所述业务信息是否满足预设条件，若是，则通过所述业务账户，将所述业务信息发送至用户账户对应的银行账户中；否则，则存储所述业务信息至信息集合中，直到所述信息集合中的所有业务信息的总量满足所述预设条件时，将所述业务信息发送至所述用户账户对应的银行账户中。

10.如权利要求9所述的装置，其特征在于，所述发送模块，具体用于判断所述业务信息中包含的退款额度是否高于最低退款额度，若是，则判定所述业务信息满足所述预设条件；否则，则判定所述业务信息不满足所述预设条件。

11.如权利要求10所述的装置，其特征在于，所述发送模块，具体用于确定所述用户账户对应的银行账户所属的银行类型，将所述业务信息存储至确定的所述银行类型对应的信息集合中，当所述信息集合中的所有业务信息中包含的退款额度之和高于所述最低退款额度时，将所述业务信息发送至所述用户账户对应的银行账户中。

12.如权利要求10所述的装置，其特征在于，所述发送模块，具体用于将所述业务信息存储至所述用户账户对应的信息集合中，当所述信息集合中的所有业务信息中包含的退款额度之和高于所述最低退款额度时，将所述业务信息发送至所述用户账户对应的银行账户中。

Images