CN106875182A - 一种业务处理方法及装置 - Google Patents

Abstract

本申请公开了一种业务处理方法及装置，第一服务器对应线下业务提供方；第二服务器对应线上业务提供方，所述方法包括：第二服务器接收第一服务器发送的账户信息文件，确定所述账户信息文件中包含的各用户的第一账户信息，针对确定出的每个第一账户信息，确定该用户所对应的第二账户信息，并将确定出的所述第一账户信息与第二账户信息进行关联。通过上述方式，使得账户之间的关联过程无需用户自行操作，显然，对于互联网操作不熟练的用户而言，这样的方式能够有助于这部分用户便捷地获得关联业务。

Description

一种业务处理方法及装置

技术领域

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

背景技术

随着信息技术的发展，线上业务提供方(如：网站)所提供的线上业务不断丰富，与传统的线下业务提供方(如：银行)所提供的线下业务的联系越来越紧密。

在此趋势下，线上业务提供方及线下业务提供方之间提供一些关联业务，如：使用银行卡的在线支付业务、在线转账业务等，以便于用户便捷地使用业务。

现有技术中，用户若想使用关联业务，通常需要在某一业务提供方处进行操作，具体而言，针对线上业务提供方A和线下业务提供方B，某用户分别具有相应的账户a及账户b，现用户想要使用关联业务，那么，用户就需要在业务提供方A(或B)的业务界面中自行操作，以便将账户a和账户b进行绑定关联。

但是，对于部分使用互联网不熟练的用户而言，上述过程较为繁琐，可能造成这部分用户难以使用关联业务。

发明内容

本申请实施例提供一种业务处理方法，用以解决部分用户难以使用关联业务的问题。

本申请实施例还提供一种业务处理装置，用以解决部分用户难以使用关联业务的问题。

本申请实施例提供的一种业务处理方法，第一服务器对应线下业务提供方；第二服务器对应线上业务提供方；所述方法包括：

第二服务器接收第一服务器发送的账户信息文件；

确定所述账户信息文件中包含的各用户的第一账户信息；

针对确定出的每个第一账户信息，确定该用户所对应的第二账户信息，并将确定出的所述第一账户信息与第二账户信息进行关联。

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

金融网站服务器接收银行服务器发送的账户信息文件；

确定所述账户信息文件中包含的各用户的银行账户信息；

针对确定出的每一用户的银行账户信息，确定该用户对应的网站账户信息，并将所述银行账户信息与所述网站账户信息进行关联。

本申请实施例提供的一种业务处理装置，第一服务器对应线下业务提供方；所述装置对应线上业务提供方；所述装置包括：

接收模块，接收第一服务器发送的账户信息文件；

确定模块，确定所述账户信息文件中包含的各用户的第一账户信息；

关联模块，针对确定出的每个第一账户信息，确定该用户所对应的第二账户信息，并将确定出的所述第一账户信息与第二账户信息进行关联。

本申请实施例还提供的一种业务处理装置，所述装置设置于金融网站侧；所述装置包括：

接收模块，接收银行服务器发送的账户信息文件；

确定模块，确定所述账户信息文件中包含的各用户的银行账户信息；

关联模块，针对确定出的每一用户的银行账户信息，确定该用户对应的网站账户信息，并将所述银行账户信息与所述网站账户信息进行关联。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

在线上业务提供方和线下业务提供方共同提供关联业务的场景下，部分用户可能由于不熟练互联网操作，导致其难以获得相应的关联业务，在这种情况下，属于线下业务提供方的第一服务器会将用户的使用线下业务时的第一账户信息发送给属于线上业务提供方的第二服务器，第二服务器在接收到用户的第一账户信息后，将确定出该用户的第二账户信息，并将第一账户信息和第二账户信息进行关联，正是采用这样的方式，使得账户之间的关联过程无需用户自行操作，显然，对于不熟练互联网操作的用户而言，这样的方式能够有助于这部分用户便捷地获得关联业务。

附图说明

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

图1a为本申请实施例提供的业务处理架构示意图；

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

图2a为本申请实施例提供的在实际的金融场景下的业务处理架构示意图；

图2b为本申请实施例提供的在实际的金融场景下的业务处理方法的实际执行过程；

图2c为本申请实施例提供的账户信息文件中记录的第一账户信息的示意图；

图3a为本申请实施例提供的在实际金融场景下的一种集群式的业务处理架构示意图；

图3b为在图3a的基础上对银行账户信息进行划分的示意图；

图4为本申请实施例提供的业务处理装置结构示意图；

图5为本申请实施例提供的在实际金融场景下的业务处理装置结构示意图。

具体实施方式

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

正如前述，在实际应用场景下，用户在使用线下业务提供商及线上业务提供商所提供的关联业务时，对于部分互联网操作不熟练的用户而言，难以进行相应的线上操作，从而难以获得关联业务。

基于此，就需要一种能够在用户不熟练互联网操作的情况下，也能较为顺利获得关联业务的方式，因此，在本申请实施例中，提供一种业务处理方法。

需要说明的是，本申请实施例中的业务处理方法基于如图1a所示的架构。对于图1a所示的架构而言，在实际应用中，线上业务提供方和线下业务提供方在各自服务器的支持下向用户提供相应业务，为便于描述，将属于线下业务提供方的服务器称为：第一服务器；将属于线上业务提供方的服务器称为：第二服务器。其中，线下业务提供方可包括：银行、超市、餐厅等能够提供线下业务的提供方，其提供的线下业务可以是诸如：银行业务、超市的购物卡业务等等。线上业务提供方可包括：网站等能够提供在线业务的提供方，其提供的在线业务可以是诸如：在线支付业务、在线订阅业务等等。

那么，上述的第一服务器就可包括：银行服务器、购物卡数据服务器等，相应地，上述的第二服务器就可包括：网站服务器等。

基于如图1a所示的架构，本申请实施例提供的业务处理过程如图1b所示，该过程具体包括以下步骤：

S101：第二务器接收第一服务器发送的账户信息文件。

第二服务器属于线上业务提供方，可以理解，第二服务器所提供的业务均属于在线业务，用户可通过相应的互联网操作(如：访问第二服务器对应的网站、使用相应的应用程序等)获得由第二服务器所提供的在线业务，但正如前述，实际应用中的部分用户可能对使用互联网的线上操作并不熟练，因而难以使用第二服务器所提供的在线业务，而考虑到实际应用中用户可以便捷地在线下业务提供方处获得相应的线下业务，如：用户在银行(即，线下业务提供方)办理银行业务(该银行业务即为线下业务)，那么，在该场景下，当用户办理线下业务提供方所提供的线下业务时，线下业务提供方便可获得用户的信息，如：用户的身份信息、联系方式等，也就是说，对于线下业务提供方的第一服务器而言，可以基于用户的信息生成与该用户相对应的账户信息(如：银行后台的服务器可以根据办理银行业务的用户的信息，生成相应的银行账户信息)。

基于此，第一服务器中将会针对不同的用户均生成相应的账户信息，并采用账户信息文件的方式存储。当然，在本申请实施例中，上述的账户信息文件中可以仅包含一个用户的账户信息，也可以包含大量用户的账户信息，这里并不构成对本申请的限定。

S102：确定所述账户信息文件中包含的各用户的第一账户信息。

正如前述，账户信息文件中包含用户在线下业务提供方的账户信息，也即，第一账户信息。其中，第一账户信息内包含用户信息，以及属于线下业务提供方的账号信息(如：用户的银行卡账号、购物卡账号等)。

作为本申请实施例中的一种方式，账户信息文件可以是以文本格式记录账户信息的文件，如：csv文件，换言之，在账户信息文件中，每一用户的第一账户信息以一条数据的方式记录在该账户文件内，那么，第二服务器便可以针对账户信息文件中各条数据进行读取，从而确定出各用户的第一账户信息。当然，上述示例仅是对一种账户信息文件的方式进行说明，这里并不构成对本申请的限定。

S103：针对确定的每个第一账户信息，确定该用户所对应的第二账户信息，并将确定出的所述第一账户信息与第二账户信息进行关联。

实际应用中，用户获得线上或线下业务提供方所提供的业务时，通常基于相应的账户，如：用户使用银行提供的银行业务时，将基于该用户在该银行的银行账户；又如：用户使用网站提供的新闻推送业务时，将基于该用户在该网站的账户。

换言之，对于本申请实施例中的关联业务而言，用户若要获得关联业务，则用户在线上业务提供方的账户信息将与用户在线下业务提供方的账户信息进行关联。

因此，在本步骤中，第二服务器会将用户的第一账户信息与第二账户信息进行关联。其中，第二账户信息就是用户在线上业务提供方上注册的账户信息。

这里需要说明的是，作为本申请实施例中的一种方式：如果用户已拥有第二账户信息，则表示第二服务器中注册有该用户的第二账户信息，进一步地，第二服务器可直接确定出该第二账户信息。

作为本申请实施例中的另一种方式：部分用户对线上操作并不熟练，难以注册线上业务提供方的账户，换言之，对于这部分用户而言，并不具有第二账户信息，在此情况下，第二服务器获得了用户的第一账户信息之后，便可以根据第一账户信息中携带的用户信息，自动为用户创建属于线上业务提供方的账户信息(即，第二账户信息)。

这样一来，第二服务器便可以将用户的第一账户信息和第二账户信息进行关联，从而使得用户能够获得由线上业务提供方和线下业务提供方共同提供的关联业务。例如：对于商品网站而言，该商品网站的服务器可以接收由银行发送的账户信息文件，并确定出账户信息文件中包含的用户银行卡账户信息，进而，商品网站的服务器可以将用户银行卡账户与该用户在该商品网站的账户进行关联，那么，后续用户便可以使用银行卡在该商品网站中进行支付。当然，该示例是对本申请实施例中的业务处理方法的说明，并不构成对本申请的限定。

通过上述步骤，在线上业务提供方和线下业务提供方共同提供关联业务的场景下，部分用户可能由于不熟练互联网操作，导致其难以获得相应的关联业务，在这种情况下，属于线下业务提供方的第一服务器会将用户的使用线下业务时的第一账户信息发送给属于线上业务提供方的第二服务器，第二服务器在接收到用户的第一账户信息后，将确定出该用户的第二账户信息，并将第一账户信息和第二账户信息进行关联，正是采用这样的方式，使得账户之间的关联过程无需用户自行操作，显然，对于互联网操作不熟练的用户而言，这样的方式能够有助于这部分用户便捷地获得关联业务。

在实际应用中，第二服务器将会接收来自于不同线下业务提供方的第一服务器所发送的第一账户信息，由第一服务器向第二服务器发送的账户信息数量巨大，那么，其中的账户信息就可能存在遗漏或出错的可能，这将会影响后续第二服务器关联账户的过程，为了保证后续关联过程中的准确性，因此，当第二服务器接收到了第一服务器发送的账户信息文件、并对该账户信息文件进行处理之前，往往还需要针对账户信息文件中的信息进行校验，具体而言，对于本申请实施例中的上述方法，在将所述第一账户信息与第二账户信息进行关联之前，所述方法还包括：对所述第一账户信息进行校验，并确定所述第一账户信息通过校验。

其中，由于第一账户信息中包含用户自身的用户信息(如：前述的个人身份信息、地址信息等)及线下业务的账号信息(如：前述的银行卡号、会员卡号等)，那么，对第一账户信息进行校验，就可包括：对第一账户信息中用户信息的校验及对线下业务的账号信息的校验。

对于用户信息而言，可校验用户信息的有效性，如：校验用户的身份证号是否有效、校验用户联系方式是否有效等等。

对于线下业务的账号信息而言，不同的线下业务提供方所创建的账号不同，以邮箱账号为例：不同网站的邮箱账号与其网站域名相关，那么，可以认为，不同网站的邮箱账号中，具有能够标示各网站的字符(或字符序列)，如：邮箱账号中“@MM.com”的字符序列，用于标示该邮箱属于网站MM.com；而邮箱账号中“@NN.com”的字符序列，用于标示该邮箱属于网站NN.com。

结合上述示例，不同的线下业务提供商所对应的账号信息，具有各自的账户标识，这些账户标识是相应的线下业务提供商所预设的，可用于表明该账号信息所属的业务提供方。

基于此，在本申请实施例中，对所述第一账户信息进行校验，具体包括：根据所述线下业务提供方预设的账户标识，对所述第一账户信息所对应的账户标识进行校验。

更为具体地，确定所述第一账户信息通过校验，具体包括：确定所述预设的账户标识与所述第一账户信息对应的账户标识一致。

在上述的校验过程通过后，第二服务器便将执行第一账户信息的关联过程，如前所述，关联过程实质上是线上业务提供方及线下业务提供方账户之间的关联绑定，所以，本申请实施例中，第二服务器将确定出用户在线上业务提供方的账户(即，第二账户信息)，在将所述第一账户信息与所述用户对应的第二账户信息进行关联之前，所述方法还包括：确定所述第一账户信息中的用户信息，根据所述用户信息，在所述第二服务器中，确定该用户信息对应的第二账户信息。

当然，上述过程是针对于用户已具有线上业务提供方账户信息(即，第二账户信息)的情况，而在实际应用中，对于互联网操作不熟练的用户而言，可能并未具有第二账户信息，那么，在这种情况下，所述方法还包括：若未查找到该用户信息对应的第二账户信息，则根据所述用户信息，创建第二账户信息。

换言之，如果第二服务器并未查找到用户的第二账户信息，就表明该用户并未在线上业务提供方处注册过账户，从而第二服务器将为用户建立相应的账户，也即，第二服务器将根据用户信息，创建属于该用户的第二账户。

需要说明的是，实际应用场景下，第二服务器创建用户的第二账户信息时，可基于相应的规则，例如：根据用户姓名的全拼+具有唯一性的字符序列，生成该用户的账户名；根据预先设定的N位字符作为该账户的密码。当然，这里只是第二服务器创建用户的第二账户信息的一种方式，并不作为对本申请的限定。

经过前述内容，第二服务器便可以将用户的第一账户信息和第二账户信息进行关联，在关联成功后，用户便可以顺利地使用线上业务提供方与线下业务提供方之间的关联业务。而且，本申请实施例中的上述方法还适用于大量线下业务提供方的账户与线上业务提供方账户之间进行关联的场景。

具体而言，线上业务提供方可面向不同的线下业务提供方，实现关联操作，在大量账户信息的情况下，第二服务器可采用集群的方式，也即，第二服务器可包括集群式的多台业务服务器。

在此基础上，确定所述账户信息文件中包含的各第一账户信息，具体包括：确定所述账户信息文件中包含的各第一账户信息的数量，当所述数据超过预设阈值时，将所述账户信息文件中划分为多个子文件，将划分得到的多个子文件分发给各业务服务器，使得各业务服务器分别确定各子文件中包含的各第一账户信息。

需要说明的是，账户信息文件中所包含的第一账户信息的数量越大，则表明该第二服务器所要处理的数据就越多，故上述的预设阈值通常与第二服务器的工作负荷相关，可以理解，在第二服务器的工作负荷较高的情况下，其预设阈值通常较低，反之，则预设阈值可以较高。在实际应用中，预设阈值的大小可由服务器根据自身的负荷情况进行调节，这里并不构成对本申请的限定。

此外，将账户信息文件所划分得到的子文件的数量，可以与集群中第二服务器的数量相同，也可以根据实际情况，划分成不同数量的子文件(将在下述的实际应用场景实施例中具体说明)。

另外，上述的业务处理方法可应用在用户使用银行卡购买在线金融产品的场景。在该场景下，银行作为线下业务提供方，用户可在银行办理相应的银行业务(即，线下业务)，金融网站作为线上业务提供方，其提供的在线金融产品属于线上业务。银行与金融网站之间提供一种关联业务，使得用户使用自身的银行卡，便可购买在线网站中的金融产品，但在使用该关联业务时，需要用户将自身的银行卡与金融网站的账户进行关联。

该场景下，对于互联网操作不熟练的用户而言，难以在金融网站上执行上述的关联操作，因此，本申请实施例中，基于前述内容，在该场景下提供了一种业务处理方法，其业务处理的架构如图2a所示，银行服务器与金融网站服务器连接，该方法流程如图2b所示，具体包括以下步骤：

S201：金融网站服务器接收银行服务器发送的账户信息文件。

这里的账户信息文件中包含了用户的银行账户信息。该银行账户信息中进一步可包含：银行卡号、用户的身份信息、联系方式等信息。并且，可以认为，在用户想要使用关联业务的情况下，可向银行发出申请，银行后台的银行服务器就会将该用户的银行账户信息写入至账户信息文件中，以便发送给金融网站，开通关联业务。

通常，银行服务器向金融网站服务器发送账户信息文件的时间为每日结算后，也即，银行服务器会将当日进行关联申请的用户的银行账户信息进行统计，生成账户信息文件，这里并不构成对本申请的限定。

S202：确定所述账户信息文件中包含的各用户的银行账户信息。

如图2c所示，为账户信息文件中所包含的银行账户信息的示意图，从图2c中可见，不同用户的银行账户信息以文本格式的方式记录在账户信息文件中，每一用户的银行账户信息包括：用户信息(如图2c中的用户姓名、身份证号、手机号等)，及相应的账号信息(如图2c中的银行卡号等)，并且，每一用户的银行账户信息以一条数据的方式记录在该账户信息文件中。

所以，金融网站服务器便可以在账户信息文件中读取每一条数据，以确定各用户的银行账户信息。

S203：针对确定出的每一用户的银行账户信息，确定该用户对应的网站账户信息，并将所述银行账户信息与所述网站账户信息进行关联。

金融网站服务器将用户的银行账户信息与该用户的网站账户信息进行关联后，用户便可以顺利地使用关联业务。

通过上述步骤，在实际应用场景下，若用户想要使用银行和金融网站之间的关联业务，只需向银行发出申请，那么，银行服务器就会将用户的银行账户信息发送给金融网站服务器，金融网站服务器将自动关联用户的银行账户和用户的网站账户，在该过程中，用户无需自行操作设置，这样的方式有助于不熟练互联网操作的用户获得关联业务。

需要说明的是，针对于如图2b所示的方法，可应用在大量用户账户信息的场景下。具体而言，金融网站服务器可以面向不同的银行，接收来自于不同银行发送的账户信息文件，实际应用中，银行发送的账户信息文件中可能包含几万～百万数量的银行账户信息，金融网站服务器将针对这些银行账户信息均进行关联处理，为了保证处理效率，通常金融网站服务器采用集群的方式，其架构如图3a所示。基于图3a所示的架构，当集群中的某一金融网站服务器接收到银行发送的账户信息文件后，会将账户信息文件中的所有银行账户信息进行划分，形成多个子文件(子文件的数量通常与集群中所包含的所有金融网站服务器的数量一致，这里不作具体限定)，分别发送给集群中的各金融网站服务器，进行关联处理。

这样的方式属于分布式的处理方式，能够更加高效地对用户的账户进行关联，同时也起到了负载均衡的作用。

结合如图3a所示的架构，具体而言，假设某银行发送的账户信息文件中包含100条数据(即，100个用户的银行账户信息)，如图3b所示。由于集群中有4台服务器，所以，接收到该账户信息文件的服务器会将这100条数据划分成为4个子文件，从图3b中可见，每个子文件内包含25条数据，以便将4个子文件分别发送给4台服务器进行处理。

当然，在此过程中，金融网站服务器可能会接收到来自于不同银行的账户信息文件，为了区分不同银行的不同账户信息文件，金融网站服务器会针对每一个账户信息文件生成唯一的标识号码，用于标识该账户信息文件。

在此基础上，由于子文件1～4是由同一账户信息文件所划分的，为了标示出4个子文件，可针对子文件生成子标识号码。

具体而言，结合图3b进行说明，针对图3b中的账户信息文件，可生成对应的、具有唯一性的标识号码，假设标识号码为：10001。针对账户信息文件所划分形成的4个子文件，生成各自的子标识号码，作为一种可选方式，可使用数据库的sequence序列，为子文件生成子标识号码，sequence序列保证了每个子标识号码的唯一性。假设，子文件1的子标识号码为1000188，子文件2的子标识号码为1000189，以此类推。

当然，上述示例仅是对标识号码的示例性说明，并不构成对本申请的限定，在实际应用中，标识号码和子标识号码可以是多位，具体将根据实际应用的需要进行设定。

各金融网站服务器在执行账户的关联之前，还会针对各银行账户进行校验，如：校验用户信息的有效性。此外，对于银行账户而言，不同银行的银行卡号具有各自的银行卡标识码(Bank Identification Number，BIN)，所以，金融网站服务器将会校验每一银行账户信息中的BIN。具体而言，对所述银行账户信息进行校验，具体包括：根据银行预设的银行卡标识号BIN，对所述银行账户信息所对应的BIN进行校验。

确定所述银行账户信息通过校验，具体包括：确定所述预设的BIN与所述银行账户信息对应的BIN一致。

例如：某银行A的BIN为：6556，那么，对于该银行发送的账户信息文件，金融网站服务器将对每一条数据中的银行卡号的BIN进行校验，各银行卡号的BIN为6556，则校验通过，否则校验不通过。

只有通过校验的银行账户信息，金融网站服务器采用执行后续的关联处理。在本申请实施例中，金融网站服务器将根据银行账户中的用户信息，确定该用户信息对应的网站账户信息，如果发现用户还未注册，则金融网站服务器将自行根据用户信息，创建相应的网站账户信息。此后，金融网站服务器将银行账户信息与网站账户信息进行关联处理。

当然，在关联过程中一旦有异常情况，则标注为异常，并在后续过程中执行重试。在重试了设定的次数后，如果仍然没能成功关联，则将该条数据的状态标定为关联失败，反之，则成功执行关联，关联状态为成功。

在进行关联后，金融网站服务器会向银行反馈回盘文件。回盘文件中记录了每一条银行账户信息的关联状态，在生成回盘文件的过程中，金融网站服务器将对各银行的账户信息文件的数量、每一账户信息文件中银行账户信息的数量及回盘文件中记录的银行账户信息的数量进行核对，以保证回盘文件的准确性。

需要说明的是，回盘文件中记录的银行账户信息的数量将大于或等于账户信息文件中银行账户信息的数量。这是因为：在实际应用中，用户可以在金融网站上取消自身银行账户信息与网站账户信息之间的关联，也就是说，金融网站服务器可能会接收到用户的解绑请求，并进行解绑，这样的状态信息也将记录在回盘文件中，所以，回盘文件中记录的银行账户信息的数量将大于或等于账户信息文件中银行账户信息的数量。

当银行接收到了回盘文件后，便会根据回盘文件中账户信息的关联状态信息进行同步。作为本申请实施例中的一种可选方式，银行处理回盘成功后，当日会向用户发出关联状态的通知消息。

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

在图4中，第一服务器对应线下业务提供方；所述装置对应线上业务提供方；所述装置包括：

接收模块401，接收第一服务器发送的账户信息文件；

确定模块402，确定所述账户信息文件中包含的各用户的第一账户信息；

关联模块403，针对确定出的每个第一账户信息，确定该用户所对应的第二账户信息，并将确定出的所述第一账户信息与第二账户信息进行关联。

上述装置中还包括：校验模块404，对所述第一账户信息进行校验，并确定所述第一账户信息通过校验。

进一步地，校验模块404，根据所述线下业务提供方预设的账户标识，对所述第一账户信息所对应的账户标识进行校验，确定所述预设的账户标识与所述第一账户信息对应的账户标识一致。

确定模块402，在关联模块403执行关联操作之前，确定所述第一账户信息中的用户信息，根据所述用户信息，在所述第二服务器中，确定该用户信息对应的第二账户信息。

在此基础上，确定模块402若未查找到该用户信息对应的第二账户信息，则根据所述用户信息，创建第二账户信息。

当然，在实际应用中的某些场景下，第一服务器会采用集群式的分布架构，那么，对于每一台第一服务器上的业务处理装置而言，确定模块402将确定所述账户信息文件中包含的各第一账户信息的数量，并当所述数据超过预设阈值时，将所述账户信息文件中划分为多个子文件，将划分得到的多个子文件分发给各业务服务器，使得各业务服务器分别确定各子文件中包含的各第一账户信息。

基于用户通过线下方式获得关联业务的实际应用场景，本申请实施例还提供一种业务处理装置，如图5所示。所述装置设置于金融网站服务器侧，该金融网站服务器与银行服务器进行交互，该装置包括：

接收模块501，接收银行服务器发送的账户信息文件；

确定模块502，确定所述账户信息文件中包含的各用户的银行账户信息；

关联模块503，针对确定出的每一用户的银行账户信息，确定该用户对应的网站账户信息，并将所述银行账户信息与所述网站账户信息进行关联。

如图5所示的装置中还包括：校验模块504，对所述银行账户信息进行校验，并确定所述银行账户信息通过校验。

进一步地，校验模块504，根据银行预设的银行卡标识号BIN，对所述银行账户信息所对应的BIN进行校验，并确定所述预设的BIN与所述银行账户信息对应的BIN一致。

在关联模块503执行关联操作前，确定模块502确定所述银行账户信息中的用户信息，根据所述用户信息，在所述金融网站服务器中，确定该用户信息对应的网站账户信息。

在此基础上，确定模块502若未查找到该用户信息对应的网站账户信息，则根据所述用户信息，创建与该用户信息对应的网站账户信息。

相类似地，在实际应用中的某些场景下，金融网站服务器也会采用集群式的分布架构，在此情况下，对于每一台金融网站服务器上的业务处理装置而言，确定模块502确定所述账户信息文件中包含的各银行账户信息的数量，当所述数量超过预设阈值时，将所述账户信息文件中划分为多个子文件，将划分得到的多个子文件分发给各金融业务服务器，使得各金融业务服务器分别确定各子文件中包含的各银行账户信息。

另外，上述的装置中还包括：回盘模块505，生成根据关联后的账户信息，生成回盘文件，并反馈至银行服务器，使得所述银行服务器根据所述回盘文件对账户的关联状态进行记录。

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

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

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

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

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

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

Claims (15)

1.一种业务处理方法，其特征在于，第一服务器对应线下业务提供方；第二服务器对应线上业务提供方；所述方法包括：

第二服务器接收第一服务器发送的账户信息文件；

确定所述账户信息文件中包含的各用户的第一账户信息；

针对确定出的每个第一账户信息，确定该用户所对应的第二账户信息，并将确定出的所述第一账户信息与第二账户信息进行关联。

2.如权利要求1所述的方法，其特征在于，在将确定出的所述第一账户信息与第二账户信息进行关联之前，所述方法还包括：

对所述第一账户信息进行校验，并确定所述第一账户信息通过校验。

3.如权利要求2所述的方法，其特征在于，对所述第一账户信息进行校验，具体包括：

根据所述线下业务提供方预设的账户标识，对所述第一账户信息所对应的账户标识进行校验；

确定所述第一账户信息通过校验，具体包括：

确定所述预设的账户标识与所述第一账户信息对应的账户标识一致。

4.如权利要求1所述的方法，其特征在于，在将所述第一账户信息与所述用户对应的第二账户信息进行关联之前，所述方法还包括：

确定所述第一账户信息中的用户信息；

根据所述用户信息，在所述第二服务器中，确定该用户信息对应的第二账户信息。

5.如权利要求4所述的方法，其特征在于，所述方法还包括：

若未查找到该用户信息对应的第二账户信息，则根据所述用户信息，创建第二账户信息。

6.如权利要求1所述的方法，其特征在于，所述第二服务器包括集群式的多台业务服务器；

确定所述账户信息文件中包含的各第一账户信息，具体包括：

确定所述账户信息文件中包含的各第一账户信息的数量；

当所述数据超过预设阈值时，将所述账户信息文件中划分为多个子文件；

将划分得到的多个子文件分发给各业务服务器，使得各业务服务器分别确定各子文件中包含的各第一账户信息。

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

金融网站服务器接收银行服务器发送的账户信息文件；

确定所述账户信息文件中包含的各用户的银行账户信息；

针对确定出的每一用户的银行账户信息，确定该用户对应的网站账户信息，并将所述银行账户信息与所述网站账户信息进行关联。

8.如权利要求7所述的方法，其特征在于，在将所述银行账户信息与所述网站账户信息进行关联之前，所述方法还包括：

对所述银行账户信息进行校验，并确定所述银行账户信息通过校验。

9.如权利要求8所述的方法，其特征在于，对所述银行账户信息进行校验，具体包括：

根据银行预设的银行卡标识号BIN，对所述银行账户信息所对应的BIN进行校验；

确定所述银行账户信息通过校验，具体包括：

确定所述预设的BIN与所述银行账户信息对应的BIN一致。

10.如权利要求7所述的方法，其特征在于，在将所述银行账户信息与所述网站账户信息进行关联之前，所述方法还包括：

确定所述银行账户信息中的用户信息；

根据所述用户信息，在所述金融网站服务器中，确定该用户信息对应的网站账户信息。

11.如权利要求10所述的方法，其特征在于，所述方法还包括：

若未查找到该用户信息对应的网站账户信息，则根据所述用户信息，创建与该用户信息对应的网站账户信息。

12.如权利要求7所述的方法，其特征在于，所述金融网站服务器包括集群式的多台金融业务服务器；

确定所述账户信息文件中包含的各用户的银行账户信息，具体包括：

确定所述账户信息文件中包含的各银行账户信息的数量；

当所述数量超过预设阈值时，将所述账户信息文件中划分为多个子文件；

将划分得到的多个子文件分发给各金融业务服务器，使得各金融业务服务器分别确定各子文件中包含的各银行账户信息。

13.如权利要求7所述的方法，其特征在于，所述方法还包括：

金融网站服务器生成根据关联后的账户信息，生成回盘文件，并反馈至银行服务器，使得所述银行服务器根据所述回盘文件对账户的关联状态进行记录。

14.一种业务处理装置，其特征在于，第一服务器对应线下业务提供方；所述装置对应线上业务提供方；所述装置包括：

接收模块，接收第一服务器发送的账户信息文件；

确定模块，确定所述账户信息文件中包含的各用户的第一账户信息；

关联模块，针对确定出的每个第一账户信息，确定该用户所对应的第二账户信息，并将确定出的所述第一账户信息与第二账户信息进行关联。

15.一种业务处理装置，其特征在于，所述装置设置于金融网站侧；所述装置包括：

接收模块，接收银行服务器发送的账户信息文件；

确定模块，确定所述账户信息文件中包含的各用户的银行账户信息；

关联模块，针对确定出的每一用户的银行账户信息，确定该用户对应的网站账户信息，并将所述银行账户信息与所述网站账户信息进行关联。