一种账户间应用数据交互控制方法及装置与流程

本申请涉及互联网应用技术领域，尤其涉及一种账户间应用数据交互控制方法及装置。

背景技术：

电子账户，也称网络账户，是电子商务、电子金融等领域中不可缺少的要素，通过使用电子账户，用户可以方便地通过计算机和互联网完成转账、付款等业务。随着各种传统业务的网络化发展，电子账户的应用范围也越来越广。

借贷功能是在转账功能的基础上发展出来的一种新的电子账户应用方式，一次完成的借贷操作中，至少包括“借”、“还”两次转账操作，而与普通的转账操作相比，在借贷操作中，系统会对双方的借贷行为进行记录，并且在必要时介入处理，例如定期提醒借方还贷、到期强制借方还贷等等。

但是，现有技术存在的问题是，借方用户仅能针对之前的借款行为进行还款操作，如果借方用户直接向贷方用户发起普通转账，虽然在其实际行为上已经完成了还贷，但是从系统的角度，是无法将普通转账操作识别为还贷操作的，因此后续系统仍然会执行提醒借方还贷、甚至强制借方还贷等操作，这样不仅给用户带来麻烦，而且会造成系统及网络资源的不必要浪费。另外，在有些情况下，即便借方用户了解上述操作规则，也仍然存在操作繁琐的问题。

技术实现要素：

针对上述技术问题，本申请提供一种账户间应用数据交互控制方法及装置，技术方案如下：

根据本申请的第1方面，提供一种账户间应用数据交互控制方法，，该方法包括：

接收第一用户发出的向第二用户的资产数据转移请求；

获取第一用户和第二用户之间的信息交互记录；

根据所获取的信息交互记录，判断是否存在未完成偿还的资产数据借贷记录，在所述借贷记录中，第一用户为借方用户、第二用户为贷方用户；

在判断结果为是的情况下，利用本次待转移的资产数据对所述借贷记录进行偿还处理。

根据本申请的第2方面，提供一种用户借条信息偿还处理方法，该方法包括：

接收第一用户发出的向第二用户的转账请求；

获取第一用户和第二用户之间的信息交互记录；

根据所获取的信息交互记录，判断是否存在未完成偿还的第一用户向第二用户发起的借条信息；

在判断结果为是的情况下，利用本次转账额度对所述借条信息进行偿还处理。

根据本申请的第3方面，提供一种账户间应用数据交互控制装置，该装置包括：

请求接收模块，用于接收第一用户发出的向第二用户的资产数据转移请求；

交互记录获取模块，用于获取第一用户和第二用户之间的信息交互记录；

判断模块，用于根据所获取的信息交互记录，判断是否存在未完成偿还的资产数据借贷记录，在所述借贷记录中，第一用户为借方用户、第二用户为贷方用户；

偿还处理模块，用于在判断结果为是的情况下，利用本次待转移的资产数据对所述借贷记录进行偿还处理。

根据本申请的第4方面，提供一种用户借条信息偿还处理装置，该装置包括：

请求接收模块，用于接收第一用户发出的向第二用户的转账请求；

交互记录获取模块，用于获取第一用户和第二用户之间的信息交互记录；

判断模块，用于根据所获取的信息交互记录，判断是否存在未完成偿还的第一用户向第二用户发起的借条信息；

偿还处理模块，用于在判断结果为是的情况下，利用本次转账额度对所述借条信息进行偿还处理。

应用本申请所提供的技术方案，当用户A向系统请求向用户B进行资产转移操作时，系统会先判断用户A对用户B是否有尚未还清的资产额度，如果是则优先利用本次转移的额度对欠额进行偿还，从而避免在欠额实际已还清的情况下，系统仍然进行提示或强制还贷给用户带来的麻烦，也有效避免了系统及网络资源的不必要浪费。对于借方用户而言，不需要刻意去选择使用普通转账操作还是还贷操作，最终都能够达成还贷的目的，在操作上更为简便。

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

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1是本申请的账户间应用数据交互控制方法的流程示意图；

图2是本申请的一种应用场景示意图；

图3是本申请的账户间应用数据交互控制装置的结构示意图。

具体实施方式

为了使本领域技术人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行详细地描述，显然，所 描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请保护的范围。

针对现有技术所存在的问题，本申请提供一种账户间应用数据交互控制方法，参见图1所示，该方法可以包括：

S101，接收第一用户发出的向第二用户的资产数据转移请求；

S102，获取第一用户和第二用户之间的信息交互记录；

S103，根据所获取的信息交互记录，判断是否存在未完成偿还的第二用户向第一用户的资产数据借贷记录；

S104，在判断结果为是的情况下，利用本次待转移的资产数据对所述借贷记录进行偿还处理。

在本申请所提供的方案中，“资产”可以是常规意义上的货币、财物，也可以是例如积分、点券等虚拟财产，“第一用户”和“第二用户”为参与资产数据交互的双方用户。当第一用户向第二用户发起普通的资产转移操作时，系统会先判断第一用户对第二用户是否有尚未还清的资产额度，如果是则优先利用本次转移的额度对欠额进行偿还，否则可以按照普通的资产转移方式处理本次资产转移操作。

在实际应用中，利用本次转移额度对欠额进行偿还可以采用不同的方式实现，一种较为简单的处理方式是：

判断本次待转移的资产数值是否等于所述借贷记录的未偿还资产数值；在判断结果为是的情况下，利用本次待转移的资产数据对所述借贷记录进行偿还处理。

这种方式实际上是做了以下假设：当用户A对用户B存在资产欠额数值X(如果借贷产生利息，则X可等于本息的总和，后文不再重复说明)时，如果A向B发起资产转移，一般会选择与X数值相同的转移额度Y。基于这种假设，系统会仅在转移额度Y＝X时，对借贷记录进行偿还处理。

如果系统支持同时存在多笔借贷操作，则用户A对用户B存在资产欠额数 值x可能是由多笔借贷记录的欠额共同组成，即X＝x1+x2+…+xn，这种情况下，当用户A向用户B发起额度为Y的转移操作时，系统会首先判断Y是否等于X，如果Y＝X则直接对多笔借贷记录进行合并偿还处理；如果Y≠X则进一步判断Y是否等于x1+x2…xn中的任意一个，如果是则对匹配到的数值所对应的单笔借贷记录进行偿还处理。

以上两种方式，实际上是假设借方对贷方进行资产转移操作时，会直接使用对全部借贷操作的总欠额或某一笔借贷操作的欠额进行转移，这种假设很符合用户的普遍实际操作需求，相应的系统处理实现逻辑也相对简单。当然，如果进一步考虑到实际可能存在的转移额度Y与欠额数值X不相等的情况，也可以进一步增加其他的处理逻辑，例如：

在本次待转移的资产数值大于未偿还资产数值的情况下，可以先对借贷记录进行偿还处理、并针对偿还处理后剩余的待转移资产数值进行资产数据转移处理。也就是说，当Y＞X时，将Y的总值拆分为两部分：X和Y-X，系统首先利用转移额度的第一部分(数值为X)对借贷记录进行偿还处理，然后针对转移额度的第二部分(数值为Y-X)生成一次相应额度的普通资产转移操作。

在本次待转移的资产数值小于未偿还资产数值的情况下，可以先借贷记录进行偿还处理、并针对偿还处理后未还清的资产数值生成新的未完成偿还的借贷记录。也就是说，当X＞Y时，将X的总值拆分为两部分：Y和X-Y，系统首先利用Y对欠额的第一部分(数值为Y)进行偿还处理，核销原借贷记录后，针对欠额的第二部分(数值为X-Y)生成一笔相应额度的借贷记录。

以上两种方式，对系统的自动偿还处理逻辑进行了补全，可以理解的是，这两种方式也分别能够支持多笔借贷操作的自动偿还处理，本申请实施例中不再详细描述。另外，在实际应用中，可以根据需求在系统中配置以上一种或多种自动偿还处理逻辑，本申请对此并不需要进行限定。

下面结合一种具体的应用场景，对本申请方案进行说明。如图2所示，在支付应用环境下的即时通信中，支持用户间直接转账、发起借条等账务操作，用户A向用户B先后发起了两笔借条，额度分别为17500元和7500元(为描述 方便，后文将分别以简称为“借条1”和“借条2”)。后续当用户A向用户B发起普通转账时，系统根据接收到的转账请求，首先根据当前的会话ID确认会话双方用户之间存在未偿还的借条信息，因此触发自动偿还操作，以下是几种自动偿还处理的情形举例：

假设用户A请求向用户B请求转账25000元，由于转账额度刚好等于两笔未偿还借条的总额，因此系统将对借条1与借条2进行合并偿还处理，处理之后，所有借条全部还清。

假设用户A请求向用户B请求转账17500元，由于转账额度与借条1匹配，因此系统将对借条1进行偿还处理。处理之后，最终剩余借条2未完成偿还。

假设用户A请求向用户B请求转账5000元，由于转账额度分别小于借条1和借条2，因此系统可以选择对任一笔借条进行偿还处理。这里选择对额度比较接近的借条2进行偿还处理，处理后借条2被核销，生成一笔新的额度为7500-5000＝2500元的借条，这里将其称为借条3，最终剩余未偿还的借条为借条1和借条3。

假设用户A请求向用户B请求转账30000元，由于转账额度大于两笔未偿还借条的总额，因此系统将对借条1与借条2进行合并偿还处理，并对扣除总偿还金额25000后剩余的5000元进行普通转账处理。

假设用户A请求向用户B请求转账20000元，由于转账额度小于两笔未偿还借条的总额，但是又分别大于两笔借条的额度，因此系统选择对任一笔借条进行偿还处理。这里选择优先对额度比较大的借条1进行偿还处理，处理后借条1被核销，并且剩余5000元；进一步地，利用剩余的5000元对借条2进行偿还处理，处理后借条2被核销，生成一笔新的额度为7500-5000＝2500元的借条，这里将其称为借条4，最终剩余未偿还的借条为借条4。

相应于上述方法实施例，本申请还提供一种账户间应用数据交互控制装置，参见图3所示，该装置可以包括：

请求接收模块110，用于接收第一用户发出的向第二用户的资产数据转移请求；

交互记录获取模块120，用于获取第一用户和第二用户之间的信息交互记录；

判断模块130，用于根据所获取的信息交互记录，判断是否存在未完成偿还的资产数据借贷记录，在借贷记录中，第一用户为借方用户、第二用户为贷方用户；

偿还处理模块140，用于在判断结果为是的情况下，利用本次待转移的资产数据对借贷记录进行偿还处理。

在本申请的一种具体实施方式中，偿还处理模块140可以具体用于：

判断本次待转移的资产数值是否等于借贷记录的未偿还资产数值；

在判断结果为是的情况下，利用本次待转移的资产数据对借贷记录进行偿还处理。

在本申请的一种具体实施方式中，偿还处理模块140可以具体用于：

在存在两笔以上未完成偿还的借贷记录的情况下，判断本次待转移的资产数值是否等于所有未完成偿还的借贷记录的未偿还资产数值总和；

如果是，则利用本次待转移的资产数据对所有未完成偿还的借贷记录进行合并偿还处理；

如果否，则进一步判断本次待转移的资产数值是否等于其中一笔未完成偿还的借贷记录的未偿还资产数值，如果是则本次待转移的资产数据对该笔未完成偿还的借贷记录进行偿还处理。

在本申请的一种具体实施方式中，偿还处理模块140可以具体用于：

在本次待转移的资产数值大于未偿还资产数值的情况下，对借贷记录进行偿还处理、并针对扣除偿还数值后剩余的待转移资产数值进行资产数据转移处理。

在本申请的一种具体实施方式中，偿还处理模块140可以具体用于：

在本次待转移的资产数值小于未偿还资产数值的情况下，对借贷记录进行偿还处理、并针对偿还处理后未还清的资产数值生成新的未完成偿还的借贷记录。

本申请还提供一种用户借条信息偿还处理装置，该装置可以包括：

请求接收模块，用于接收第一用户发出的向第二用户的转账请求；

交互记录获取模块，用于获取第一用户和第二用户之间的信息交互记录；

判断模块，用于根据所获取的信息交互记录，判断是否存在未完成偿还的第一用户向第二用户发起的借条信息；

偿还处理模块，用于在判断结果为是的情况下，利用本次转账额度对借条信息进行偿还处理。

可以理解的是，用户借条信息偿还处理装置与前面实施例中的种账户间应用数据交互控制装置的结构示意图一致，这里不再重复示出

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本申请方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

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