一种收款渠道的建立方法、装置以及收款方法、装置与流程

本发明属于智能收款技术领域，尤其涉及一种智能跨行收款系统及方法。

背景技术：

目前境内人民币收款时，如果收方和付方在不同的银行开户后，通过跨行收款渠道实现收款的过程中，付方开户银行为了避免自身存款的流失，关闭了某些特定的收款渠道，导致收方不能通过特定的渠道从付方账号中收款。为了解决这一技术问题，现有技术中采用的技术方案是收方与多个银行合作，采用多个银行提供的收款渠道从付方账号中收款。

但是，当采用收方与多个银行合作这一方式以实现从付方账号收款时，若付方为多个，例如有线电视公司从多个开通有线电视的家庭中收取有线电视费用时，付方为多个家庭，有线电视公司需要通过多个银行共同完成对所有家庭有线电视费用的收取，导致收方的操作复杂且占用资源多。

技术实现要素：

有鉴于此，本发明的目的在于提供一种跨行收款系统及方法，用于解决现有技术中实现跨行收款时操作复杂的问题。技术方案如下：

本发明提供一种收款渠道的建立方法，包括：

接收输入的签约信息；其中，所述签约信息至少包括付方账号；

依据每个付方账号，获取所述每个付方账号支持的收款渠道；

从获取到的所述每个付方账号支持的收款渠道中，选择与所述每个付方账号对应的签约收款渠道；

建立所述每个付方账号、所述签约收款渠道和收方账号之间的关联。

优选地，所述建立所述每个付方账号、所述签约收款渠道和收方账号之间的关联包括：

向所述签约收款渠道发送渠道签约信息；其中，所述渠道签约信息至少包括所述每个付方账号和每个付方账号对应的付方户名；

接收所述签约收款渠道对所述渠道签约信息的审批结果；

判断所述审批结果是否合格；

当合格时，建立所述每个付方账号、所述签约收款渠道和收方账号之间的关联。

优选地，所述建立所述每个付方账号、所述签约收款渠道和收方账号之间的关联，包括：

接收所述签约收款渠道发送的渠道签约信息；其中，所述渠道签约信息至少包括所述每个付方账号和每个付方账号对应的付方户名；

依据所述渠道签约信息，建立所述每个付方账号、所述签约收款渠道和收方账号之间的关联。

本发明还提供了一种收款方法，包括：

接收输入的收款信息；其中，所述收款信息至少包括收方账号、付方账号和收款金额；

依据所述收款信息，从预先建立的签约收款渠道中获取与所述收款信息对应的签约收款渠道；

利用所述签约收款渠道收款。

优选地，所述依据所述收款信息，从所述签约收款渠道中获取与所述收款信息对应的签约收款渠道，包括：

在与每个所述收方账号对应的所述签约收款渠道中，查找与所述每个付方账号一一对应的签约收款渠道。

优选地，所述利用所述签约收款渠道收款，包括：

向获取到的所述签约收款渠道发送收款交易请求；

接收所述每个付方账号通过所述签约收款渠道发送的交易回执。

优选地，所述向获取到的所述签约收款渠道发送收款交易请求之后，还包括：

对与所述收款交易请求对应的收款交易，进行清算；

其中，对所述收款交易请求对应的收款交易，进行清算包括：

接收所述签约收款渠道对应的清算通道平台发送的清算文件；

根据所述清算文件，对所述收款交易进行清算。优选地，所述向获取到的所述签约收款渠道发送收款交易请求包括：

接收收款交易请求；

判断所述收款交易请求的数量是否超过预先设置的签约收款渠道的收款交易量阈值；

判断结果为是，则缓存接收到的所述收款交易请求；

将所述收款交易请求异步发送至所述签约收款渠道。

本发明还提供了一种收款渠道的建立装置，包括：

第一接收单元，用于接收输入的签约信息；其中，所述签约信息至少包括付方账号；

第一获取单元，用于依据每个付方账号，获取所述每个付方账号支持的收款渠道；

选择单元，用于从获取到的所述每个付方账号支持的收款渠道中，选择与所述每个付方账号对应的签约收款渠道；

建立单元，用于建立所述每个付方账号、所述签约收款渠道和收方账号之间的关联。

优选地，所述建立单元，包括：

第一发送子单元，用于向所述签约收款渠道发送渠道签约信息；其中，所述渠道签约信息至少包括所述每个付方账号和每个付方账号对应的付方户名；

第一接收子单元，用于接收所述签约收款渠道对所述渠道签约信息的审批结果；

判断子单元，用于判断所述审批结果是否合格；

第一建立子单元，用于当所述判断子单元判断所述审批结果合格时，建立所述每个付方账号、所述签约收款渠道和收方账号之间的关联。

优选地，所述建立单元，包括：

第二接收子单元，用于接收所述签约收款渠道发送的渠道签约信息；其中，所述渠道签约信息至少包括所述每个付方账号和每个付方账号对应的付方户名；

第二建立子单元，用于依据所述第二接收子单元接收的所述渠道签约信息，建立所述每个付方账号、所述签约收款渠道和收方账号之间的关联。

本发明还提供了一种收款装置，包括：

第二接收单元，用于接收输入的收款信息；其中，所述收款信息至少包括收方账号、付方账号和收款金额；

第二获取单元，用于依据所述收款信息，从预先建立的签约收款渠道中获取与所述收款信息对应的签约收款渠道；

收款单元，用于利用所述签约收款渠道收款。

优选地，所述收款单元，包括：

第二发送子单元，用于向获取到的所述签约收款渠道发送收款交易请求；

第二接收子单元，用于接收所述每个付方账号通过所述签约收款渠道发送的交易回执。

优选地，还包括：

清算单元；

所述清算单元，用于对与所述收款交易请求对应的收款交易，进行清算；

其中，所述清算单元包括：

第三接收子单元，用于接收所述签约收款渠道对应的清算通道平台发送的清算文件；

清算子单元，用于根据所述清算文件，对所述收款交易进行清算。

优选地，所述第二发送子单元，包括：

交易请求接收单元，用于接收收款交易请求；

阈值判断单元，用于判断所述收款交易请求的数量是否超过预先设置的签约收款渠道的收款交易量阈值；

存储单元，用于当所述阈值判断单元判断结果为是时，缓存接收到的所述收款交易请求；

异步发送单元，用于将所述收款交易请求异步发送至所述签约收款渠道。

与现有技术相比，本发明提供的上述技术方案具有如下优点：

从上述技术方案可知，本发明通过接收输入的签约信息，建立与签约信息对应的签约收款渠道，当收方输入多个不同的签约信息时，则针对不同的签约信息，分别建立与之对应的签约收款渠道，并建立收方账号与签约信息以及签约收款渠道之间的关联，使得收方通过一次签约即可根据自身需求通过不同的收款渠道实现收款。

相较于现有技术中，用户需要与多个银行分别签订协议，才能实现从不同的付方收款的方式，本申请中通过一次签约实现将多个收款渠道融合，并供用户使用，用户针对不同的付方，可以选择不同的收款渠道实现收款，而无需用户与多个银行合作。操作简单，且减少了用户的工作量。

附图说明

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

图1是本实施例公开的一种收款渠道的建立方法的流程图；

图2是本实施例公开的一种收款方法的流程图；

图3是本实施例公开的另一种收款方法的流程图；

图4是本实施例公开的一种收款渠道的建立装置的结构图；

图5是本实施例公开的一种收款装置的结构图；

图6是本实施例公开的另一种收款装置的结构图。

具体实施方式

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

用户在建行申请开通一个账户，以从任意一个或多个付方账号处实现收款时，建行根据客户的需求，结合收取费用等内容，为客户提供合适的收款渠道，例如，用户为有线电视公司，其需要从每个开通了有线电视服务的家庭中分别收取费用，则用户所要求实现的是大批量的交易，结合收款渠道不同的收费标准，为有限电视公司提供金联收款这一收款渠道。

但是，由于每个家庭即付方所持有的账户的开户行可能不同，例如付方可以持有农村商业银行或信用社账户，这类小型银行并不在金联渠道支持的范围内。此时，当多个已经开通了有线电视服务的家庭，持有不同他行的银行卡，且他行并不支持金联收款这一收款渠道时，导致有线电视公司不能成功的从持有他行银行卡的家庭中收款有线电视服务费用。

现有技术中，为了实现用户能够从每个已经开通了有线电视服务的家庭中收取费用，采用的方式是：针对持有他行银行卡的家庭，有线电视公司分别与他行签约，以实现从每个家庭中收取费用。这一方式导致用户的操作复杂且占用资源多。

针对此问题，本申请提供了一种收款渠道的建立方法，通过接收输入的签约信息，建立与签约信息对应的收款渠道，当收方输入多个不同的签约信息时，则针对不同的签约信息，分别建立与之对应的收款渠道，使得收方通过一次签约即可根据自身需求通过不同的收款渠道实现收款。

相较于现有技术中，用户需要与多个银行分别签订协议，才能实现从不同的付方收款的方式，本申请中通过一次签约实现将多个收款渠道融合，并供用户使用，用户针对不同的付方，可以选择不同的收款渠道实现收款，而无需用户与多个银行合作。操作简单，且减少了用户的工作量。

请参阅图1，其示出了本申请实施例提供的一种收款渠道的建立方法的流程图，所述建立方法包括：

S101、接收输入的签约信息；

其中，所述签约信息至少包括付方账号；

优选地，所述付方账号可以是付方的银行卡号。

S102、依据每个付方账号，获取所述每个付方账号支持的收款渠道；

不同的银行，其开通的银行卡支持的收款渠道是不同的，针对每个付方账号对应的开户行，分别获取每个付方账号支持的收款渠道。每个付方账号支持的收款渠道可以为一个，也可以为多个。

S103、从获取到的所述每个付方账号支持的收款渠道中，选择与所述每个付方账号对应的签约收款渠道；

当付方账号支持的收款渠道为一个时，则选择这一个收款渠道为与此付方账号对应的签约收款渠道；

当付方账号支持的收款渠道为多个时，则从这多个收款渠道中选择一个收款渠道为与此付方账号对应的签约收款渠道。

S104、建立所述每个付方账号、所述签约收款渠道和收方账号之间的关联。

优选地，建立所述每个付方账号、所述签约收款渠道和收方账号之间的关联包括：

S1041、向所述签约收款渠道发送渠道签约信息；其中，所述渠道签约信息至少包括所述每个付方账号和每个付方账号对应的付方户名；

针对每个付方账号，将至少包括付方账号、付方账号对应的付方户名的渠道签约信息，发送到所述签约收款渠道；

由于不同的收款渠道，在签订收款协议时，所需要提供的具体渠道签约信息是不同的，因此针对签约收款渠道，向所述签约收款渠道发送包括其所需要的渠道签约信息的内容。

例如，签约收款渠道为小额借记时，渠道签约信息包括付方账号、付方户名、付方联行号和授权支付协议号；

签约收款渠道为银联收款时，渠道签约信息除包括付方账号、付方户名、付方联行号、商户编号、POS编号和证件类型等商户注册信息；其中，所述商户注册信息可以从商户登记系统获取；

签约收款渠道为金联收款时，渠道签约信息除包括付方账号、付方户名、付方联行号和营业执照、组织机构代码证等企业入网信息。

S1042、接收所述签约收款渠道对所述渠道签约信息的审批结果；

S1043、判断所述审批结果是否合格；

当合格时，执行S1044；

S1044、建立所述每个付方账号、所述签约收款渠道和收方账号之间的关联。

上述建立每个付方账号、所述签约收款渠道和收方账号之间的关联的方式，适用于金联、银联等收款渠道，需要收方发起签约请求。

优选地，建立所述每个付方账号、所述签约收款渠道和收方账号之间的关联包括：

接收所述签约收款渠道发送的渠道签约信息；其中，所述渠道签约信息至少包括所述每个付方账号和每个付方账号对应的付方户名；

依据所述渠道签约信息，建立所述每个付方账号、所述签约收款渠道和收方账号之间的关联。

上述建立每个付方账号、所述签约收款渠道和收方账号之间的关联的方式，适用于小额借记等收款渠道，需要付方发起签约请求。

针对每个付方账号，确定了与所述每个付方账号对应的签约收款渠道后，将所述每个付方账号、所述签约收款渠道，与收方账号相关联。其中，所述收方账号可以为一个，也可以为多个。

一个收方账号对应的签约收款渠道有多个，但这一收方账号对应的每个付方账号，仅对应一个签约收款渠道。当收方账号以及付方账号都确定后，能够找到唯一一个签约收款渠道。

通过建立付方账号、签约收款渠道和收方账号之间的关联，收方账号从付方账号处通过一个签约收款渠道实现收款。

本实施例中，通过接收输入的签约信息，建立与签约信息对应的签约收款渠道，当收方输入多个不同的签约信息时，则针对不同的签约信息，分别建立与之对应的签约收款渠道，并建立收方账号与签约信息以及签约收款渠道之间的关联，使得收方通过一次签约即可根据自身需求通过不同的收款渠道实现收款。

相较于现有技术中，用户需要与多个银行分别签订协议，才能实现从不同的付方收款的方式，本申请中通过一次签约实现将多个收款渠道融合，并供用户使用，用户针对不同的付方，可以选择不同的收款渠道实现收款，而无需用户与多个银行合作。操作简单，且减少了用户的工作量。

基于上述实施例公开的收款渠道的建立方法建立的收款渠道，本实施例还公开了一种收款方法。参阅图2，其示出了本申请实施例提供的一种收款方法的流程图，所述收款方法包括：

S201、接收输入的收款信息；其中，所述收款信息至少包括收方账号、付方账号和收款金额；

在进行收款时，需要连接银行系统，其中，连接方式可以是通过登录网上银行的方式，通过输入用户名以及密码登录网上银行；连接方式还可以是直连的方式，用户通过登录自己的系统，输入对接接口规范后，实现自己的系统与建行系统的连接。

连接银行系统后，银行系统接收用户输入的收款信息，其中，所述收款信息至少包括收方账号、付方账号和收款金额。

优选地，所述收方账号可以在登录到网上银行后，直接根据登录网上银行时输入的用户名获取，也可以在登录企业系统后，根据登录企业系统时输入的信息获取到；

当收方账号有多个时，即一个用户对应多个收方账号时，可以在收款时从多个收方账号中选择一个收方账号。

S202、依据所述收款信息，从预先建立的签约收款渠道中获取与所述收款信息对应的签约收款渠道；

接收到收款信息后，在预先建立的每个付方账号、签约收款渠道和收方账号之间的关联中，获取与收款信息中包括的收方账号对应的所述签约收款渠道，再根据收款信息中包括的付方账号，查找与所述每个付方账号一一对应的签约收款渠道。

S203、利用所述签约收款渠道收款。

优选地，所述利用所述签约收款渠道收款，包括：

S2031、向获取到的所述签约收款渠道发送收款交易请求；

向所述签约收款渠道发送收款交易请求，所述签约收款渠道依据所述渠道签约信息，向付方开户银行发送收款交易请求。

S2032、接收所述每个付方账号通过所述签约收款渠道发送的交易回执。

本实施例中，在收方从多个付方账号中收款时，根据预先建立的与收方账号、付方账号对应的签约收款渠道，实现从每个付方账号中收款。即用户只需要在建行开通一个对公活期账户，在于建行签约的过程中，针对不同的付方账号建立不同的收款渠道，通过将多个收款渠道融合，以实现采用一个或多个收款渠道分别从每个付方账号中收款。解决了在面对持有不同他行的付方时，用户需要分别与多个银行分别签订协议，才能实现从不同的付方收款，导致的操作复杂的问题。

参阅图3，其示出了本申请实施例提供的另一种收款方法的流程图，所述收款方法包括：

S301、接收输入的收款信息；其中，所述收款信息至少包括收方账号、付方账号和收款金额；

S302、依据所述收款信息，从预先建立的签约收款渠道中获取与所述收款信息对应的签约收款渠道；

本实施例中的步骤S301、S302与图2所示的实施例中的步骤S201、S202相同，此处不再赘述。

S303、向获取到的所述签约收款渠道发送收款交易请求；

优选地，所述向获取到的所述签约收款渠道发送收款交易请求，包括：

S3031、接收收款交易请求；

接收用户通过企业系统发送的收款交易请求，此交易请求可以通过特定的按钮触发；

S3032、判断所述收款交易请求的数量是否超过预先设置的签约收款渠道的收款交易量阈值；

判断结果为是，则执行S3033；

判断结果为否，则执行S3035；

针对每个签约收款渠道，可以预先设置收款交易量阈值；

此主要针对的用户是企业，企业在短时间内集中发送大量收款交易请求。

在接收到收款交易请求后，根据所述获取到的所述签约收款渠道对应的预先设置的收款交易量阈值，判断所述收款交易请求的数量是否超过所述签约收款渠道的收款交易量阈值；

S3033、缓存接收到的所述收款交易请求；

当判断接收到的所述收款交易请求的数量超过了所述签约收款渠道的收款交易量阈值，则将接收到的所述收款交易请求存储；

S3034、将所述收款交易请求异步发送至所述签约收款渠道；

采用异步的方式将存储的所述收款交易请求发送至所述签约收款渠道。

可选地，可以针对用户预先设置收款交易量阈值，即当接收到的收款交易请求是某个特定用户发送的，则根据这一特定用户预先设置的收款交易量阈值，判断所述收款交易请求的数量是否超过了阈值，若超过了则存储后，采用异步的方式向所述签约收款渠道发送。

针对用户设置阈值主要是考虑到有些用户，每次发送的交易请求量都很大，这时可以为此用户设置阈值，避免同时发送大量交易请求时，导致系统拥堵，交易请求失败的问题产生。

对用户设置阈值与对签约收款渠道设置阈值是不同的，其中，对签约收款渠道设置阈值，仅针对在这一签约收款渠道下发送的交易请求进行控制；而对用户设置阈值，则只要是这一用户发起的交易，无论采用何种收款渠道，则都对交易请求进行控制。

S3035、将所述收款交易请求同时发送至所述签约收款渠道；

S304、接收所述每个付方账号通过所述签约收款渠道发送的交易回执；

S305、对与所述收款交易请求对应的收款交易，进行清算；

优选地，对于所述收款交易请求对应的收款交易进行清算，包括：

S3051、接收所述签约收款渠道对应的清算通道平台发送的清算文件；

由于不同的签约收款渠道，对应的清算通道平台是不同的，接收不同所述清算通道平台发送的清算文件。

S3052、根据所述清算文件，对所述收款交易进行清算。

其中，步骤S304与步骤S305的执行顺序并不受本实施例的限定。在实际应用中，对发起的收款交易进行清算是定时执行的。

本实施例公开的一种收款方法，还可以包括对与所述收款交易请求对应的收款交易，进行对账；

其中，对与所述收款交易请求对应的收款交易，进行对账包括：

向与获取到的所述签约收款渠道对应的对账系统发送对账请求；

由于不同的签约收款渠道，对应的对账系统是不同的，例如所述签约收款渠道为小额借记时，对应的对账系统是支付结算系统；所述签约收款渠道为银联收款时，对应的对账系统是银联系统；所述签约收款渠道为金联收款时，对应的对账系统是支付结算系统和金联万家系统。因此需要根据所述签约收款渠道，确定与所述签约收款渠道对应的对账系统，并向所述对账系统发送对账请求。

接收所述对账系统返回的对账结果。

用户可以通过统一的查询界面查询对账结果，进而获知收款交易的交易结果。由于不同的签约收款渠道对应的对账系统是不同的，因此，对账系统返回的对账结果的显示形式或内容是不同的。

在实际应用中，可以预先设置周期，按照周期完成对账操作。

本实施例中，在收方从多个付方账号中收款时，根据预先建立的与收方账号、付方账号对应的签约收款渠道，实现从每个付方账号中收款。即用户只需要在建行开通一个对公活期账户，在于建行签约的过程中，针对不同的付方账号建立不同的收款渠道，通过将多个收款渠道融合，以实现采用一个或多个收款渠道分别从每个付方账号中收款。解决了在面对持有不同他行的付方时，用户需要分别与多个银行分别签订协议，才能实现从不同的付方收款，导致的操作复杂的问题。

同时，本实施例中，在发送收款交易请求时，针对签约收款渠道设置的阈值，对同时发送的交易量进行控制，可以避免同时发送大量交易请求导致系统拥堵，交易请求失败的问题产生。且对收款交易提供了清算和对账操作，方便用户获知当前收款交易的交易结果，提高了用户体验。

对应图1所示的一种收款渠道的建立方法，本实施例公开了一种收款渠道的建立装置，参阅图4，其示出了本实施例公开的一种收款渠道的建立装置的结构图，所述建立装置包括：

第一接收单元11、第一获取单元12、选择单元13和建立单元14；

所述第一接收单元11，用于接收输入的签约信息；其中，所述签约信息至少包括付方账号；

所述第一获取单元12，用于依据每个付方账号，获取所述每个付方账号支持的收款渠道；

所述选择单元13，用于从获取到的所述每个付方账号支持的收款渠道中，选择与所述每个付方账号对应的签约收款渠道；

所述建立单元14，用于建立所述每个付方账号、所述签约收款渠道和收方账号之间的关联。

优选地，所述建立单元14，包括：

第一发送子单元21、第一接收子单元22、判断子单元23和第一建立子单元24；

所述第一发送子单元21，用于向所述签约收款渠道发送渠道签约信息；其中，所述渠道签约信息至少包括所述每个付方账号和每个付方账号对应的付方户名；

所述第一接收子单元22，用于接收所述签约收款渠道对所述渠道签约信息的审批结果；

所述判断子单元23，用于判断所述审批结果是否合格；

所述第一建立子单元24，用于当所述判断子单元判断所述审批结果合格时，建立所述每个付方账号、所述签约收款渠道和收方账号之间的关联。

优选地，所述建立单元14，包括：

第二接收子单元和第二建立子单元；

所述第二接收子单元，用于接收所述签约收款渠道发送的渠道签约信息；其中，所述渠道签约信息至少包括所述每个付方账号和每个付方账号对应的付方户名；

所述第二建立子单元，用于依据所述第二接收子单元接收的所述渠道签约信息，建立所述每个付方账号、所述签约收款渠道和收方账号之间的关联。

在建立收方账号、付方账号与签约收款渠道之间的关联时，根本不同的签约收款渠道，选择不同的建立单元14，实现建立三者之间的关联。

本实施例中，通过第一接收单元接收输入的签约信息，建立单元建立与签约信息对应的签约收款渠道，当收方输入多个不同的签约信息时，则针对不同的签约信息，分别建立与之对应的签约收款渠道，并建立收方账号与签约信息以及签约收款渠道之间的关联，使得收方通过一次签约即可根据自身需求通过不同的收款渠道实现收款。

相较于现有技术中，用户需要与多个银行分别签订协议，才能实现从不同的付方收款的方式，本申请中通过一次签约实现将多个收款渠道融合，并供用户使用，用户针对不同的付方，可以选择不同的收款渠道实现收款，而无需用户与多个银行合作。操作简单，且减少了用户的工作量。

对应图2所示的一种收款方法，本实施例公开了一种收款装置，参阅图5，其示出了本实施例公开的一种收款装置的结构图，所述收款装置包括：

第二接收单元31、第二获取单元32和收款单元33；

所述第二接收单元31，用于接收输入的收款信息；其中，所述收款信息至少包括收方账号、付方账号和收款金额；

所述第二获取单元32，用于依据所述收款信息，从预先建立的签约收款渠道中获取与所述收款信息对应的签约收款渠道；

所述收款单元33，用于利用所述签约收款渠道收款。

优选地，所述收款单元33包括：

第二发送子单元41，用于向获取到的所述签约收款渠道发送收款交易请求；

第二接收子单元42，用于接收所述每个付方账号通过所述签约收款渠道发送的交易回执。

本实施例中，在收方从多个付方账号中收款时，根据预先建立的与收方账号、付方账号对应的签约收款渠道，实现从每个付方账号中收款。即用户只需要在建行开通一个对公活期账户，在于建行签约的过程中，针对不同的付方账号建立不同的收款渠道，通过将多个收款渠道融合，以实现采用一个或多个收款渠道分别从每个付方账号中收款。解决了在面对持有不同他行的付方时，用户需要分别与多个银行分别签订协议，才能实现从不同的付方收款，导致的操作复杂的问题。

对应图3所示的一种收款方法，本实施例公开了一种收款装置，参阅图6，其示出了本实施例公开的一种收款装置的结构图，所述收款装置包括：

第二接收单元31、第二获取单元32、第二发送子单元41、第二接收子单元42和清算单元51；

所述清算单元51，用于对与所述收款交易请求对应的收款交易，进行清算；

其中，所述清算单元51包括：

第三接收子单元，用于接收所述签约收款渠道对应的清算通道平台发送的清算文件；

清算子单元，用于根据所述清算文件，对所述收款交易进行清算。

优选地，所述第二发送子单元41包括：

交易请求接收单元61、阈值判断单元62、存储单元63和异步发送单元64；

所述交易请求接收单元61，用于接收收款交易请求；

所述阈值判断单元62，用于判断所述收款交易请求的数量是否超过预先设置的签约收款渠道的收款交易量阈值；

所述存储单元63，用于当所述阈值判断单元判断结果为是时，缓存接收到的所述收款交易请求；

所述异步发送单元64，用于将所述收款交易请求异步发送至所述签约收款渠道。

本实施例中，在收方从多个付方账号中收款时，根据预先建立的与收方账号、付方账号对应的签约收款渠道，实现从每个付方账号中收款。即用户只需要在建行开通一个对公活期账户，在于建行签约的过程中，针对不同的付方账号建立不同的收款渠道，通过将多个收款渠道融合，以实现采用一个或多个收款渠道分别从每个付方账号中收款。解决了在面对持有不同他行的付方时，用户需要分别与多个银行分别签订协议，才能实现从不同的付方收款，导致的操作复杂的问题。

同时，本实施例中，在发送收款交易请求时，针对签约收款渠道设置的阈值，对同时发送的交易量进行控制，可以避免同时发送大量交易请求导致系统拥堵，交易请求失败的问题产生。且对收款交易提供了清算和对账操作，方便用户获知当前收款交易的交易结果，提高了用户体验。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于方法类实施例而言，由于其与设备实施例基本相似，所以描述的比较简单，相关之处参见设备实施例的部分说明即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。