退款信息处理方法及装置与流程

本申请涉及信息处理技术领域，特别是涉及退款信息处理方法及装置。

背景技术：

随着电子商务交易平台的不断完善，以及传统通信、移动通信等技术的快速发展，越来越多的人们通过网上购物的方式来获取自己所需的商品，商品的种类可以涉及到人们日常生活的方方面面。

在电子商务交易的过程中，一般正常的流程是：买家用户通过交易平台的网站或者移动端的应用(App)选购自己所需的商品，生成交易订单，并付款，订单进入“买家已付款”状态，此时，相关的款项一般会暂时存在交易平台的公共账户中；之后，卖家用户可以在一定时间内，针对处于已付款状态的订单进行发货，此时，订单进入“已发货”状态，并且可以为买家用户提供“确认收货”的选项，待买家用户收到货品后，可以通过该选项进行确认，交易平台再将相关的款项，从公共账户转入卖家用户的账户，至此，交易结束。

在实际应用中，可能存在以下情况：买家用户已经生成交易订单并且付款成功，但是出于种种原因，可能又不想购买该商品了。此时，交易平台也为用户提供了相应的“退款”流程，一般情况下，只要在一次交易正式结束之前，买家用户都是可以申请退款的。

但在现有技术中，在买家申请退款时，一般需要先与卖家用户进行协商，在卖家用户同意，并在交易平台中执行了相关的操作之后，例如通过电话或即时通讯等工具进行沟通，才能将相关的款项返回给买家用户，速度往往会比较慢，效率很低，并且占用网络资源。

技术实现要素：

本申请提供了退款信息处理方法及装置，可以使得退款流程更加便捷高效。

本申请提供了如下方案：

一种退款信息处理方法，包括：

对至少一个交易订单的状态进行监控；

当监控到针对目标交易订单的快速退款请求事件时，从所述事件中提取待校验的关键信息；

判断所述关键信息是否符合预置的校验规则，如果是，则确定所述目标交易订单关联的退款金额，并调用预置的同意退款接口，以便将相应的金额退还到相应的付款账户。

一种退款信息处理装置，包括：

监控单元，用于至少一个交易订单的状态进行监控；

关键信息提取单元，用于当监控到针对目标交易订单的快速退款请求事件时，从所述事件中提取待校验的关键信息；

判断单元，用于判断所述关键信息是否符合预置的校验规则，如果是，则确定所述目标交易订单关联的退款金额，并调用预置的同意退款接口，以便将相应的金额退还到相应的付款账户。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，可以为用户提供快速退款的通道，在对关键信息进行校验通过后，不需要第一用户进行操作，即可自动调用同意退款接口，将相应的金额退还到相应的付款账户，因此，使得退款流程更加便捷高效，并节约网络资源，提高用户体验。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的第一方法实施例的流程图；

图2是本申请实施例提供的第二方法实施例的流程图；

图3是本申请实施例提供的第三方法实施例的流程图；

图4是本申请实施例提供的第四方法实施例的流程图；

图5是本申请实施例提供的装置的示意图。

具体实施方式

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

在本申请实施例中，为了能够快速的响应买家用户(也即系统中业务对象的消费方用户，或称第二用户)的退款请求，可以为第二用户提供一种快速退款的通道(例如，可以在订单管理页面等处，提供相应的按钮，当然，用于进行常规退款流程的按钮也可以同时存在，用户可以根据实际的情况进行选择)。这样，当检测到用户的快速退款请求事件发生时，可以对事件中的一些关键信息进行检验，判断其是否满足快速退款的条件，如果满足，则可以由系统自动调用同意退款接口，快速为第二用户进行退款操作，这样，第二用户不需要与第一用户进行协商，也不需要等待第一用户进行操作，就可以快速收到相应的款项，使得第二用户获得更便捷的服务。下面对具体的实现方式进行详细介绍。

参见图1，本申请实施例提供了一种退款信息处理方法，该方法可以包括以下步骤：

S101：对至少一个交易订单的状态进行监控；

其中，在第二用户选购了某业务对象之后，即可生成交易订单，该步骤就是对系统中已经生成的交易订单的状态进行监控。具体实现时，在交易订单的各个阶段，系统都可以在相应的页面中为相应的第一用户或者第二用户提供相应的操作选项，例如，在订单生成后，可以为第二用户提供“付款”选项，第二用户可以通过操作该选项进入相应的付款页面；在第二用户付款完成之后，可以为第一用户提供“发货”选项，第一用户在完成发货之后，可以通过该选项来将订单修改为“已发货”状态，等等。另外，只要在第二用户完成付款后，就可以为第二用户提供“申请退款”选项。在现有技术中，第二用户在选择该选项之后，可以将相应的请求发送给第一用户，并为第一用户提供用于同意或者拒绝退款的操作选项，如果同意退款，则需要由第一用户对相应的“同意退款”选项进行操作，此时，服务器在收到该指令之后，就可以调用相关的同意退款接口，完成退款流程。

而在本申请实施例中，除了为第二用户提供上述“申请退款”的选项，还可以为第二用户提供“快速退款”的选项，如果第二用户需要快速完成退款，则可以对该选项进行操作。该步骤S101就是要对第二用户针对这种“快速退款”选项的操作情况进行监控。

S102：当监控到针对目标交易订单的快速退款请求事件时，从所述事件中提取待校验的关键信息；

如果某第二用户针对其交易订单选择了“快速退款”选项，则进入本申请实施例的快速退款流程，在该流程中，不需要由第一用户进行退款操作，系统自动帮助第二用户完成退款。但是，为了避免第二用户滥用该功能，也降低第一用户受到损失的可能性，在自动退款前，还可以对该事件中的各项关键信息进行判断，确定其是否符合预置的快速退款规则，只有符合快速退款规则的情况下，才自动完成快速退款，否则可以仍然按照传统的流程进行退款操作。

其中，所谓的从事件中提取的关键信息，是指需要校验的信息，通过对这些关键信息进行校验，来判断是否满足快速退款的条件。具体的，需要提取哪些关键信息，可以是根据校验条件中需要校验的信息类别来确定的。例如，在校验条件中，需要对订单状态以及从付款到申请快速退款之间的时间长度进行 校验，则此时，就可以提取出当前目标交易订单的状态(包括买家已付款、已发货等等)、第二用户为当前目标交易订单进行付款的第一时间点，以及接收到当前快速付款请求的第二时间点，这样就可以计算出从第一时间点到第二时间点之间的时间长度。或者，假设在校验条件中需要对第二用户的诚信等级进行校验，则可以从当前的事件中提取出第二用户标识信息，以便到相关的数据库中查询该第二用户的诚信等级，等等。

S103：判断所述关键信息是否符合预置的校验规则，如果是，则确定所述目标交易订单关联的退款金额，并调用预置的同意退款接口，以便将相应的金额退还到相应的付款账户。

在提取出关键信息之后，就可以判断这些关键信息是否符合预置的校验规则。如果符合，就可以确定出目标交易订单关联的退款金额，并调用预置的同意退款接口，以便将相应的金额退还到相应的付款账户。其中，关于同意退款接口，在传统的方式下，是在第一用户执行了相关的同意退款操作之后，由第一用户手动触发对该接口的调用，而在本申请实施例中，可以由系统的自动触发代替第一用户的手动触发，调用的对象与传统方法可以是相同的。

其中，在对关键信息进行校验时，可以有多种方式。例如，在判断出当前交易订单处于未发货的状态时，判断从第一时间点到第二时间点的时间长度是否大于发货合约时间长度，或者，还可以判断第二用户的诚信等级信息是否满足预置条件，等等。另外，在实际应用中，还可以对多种关键信息都进行校验，只有每项关键信息均符合预置条件时，才可以进行后续的快速退款流程。例如，首先从时间长度角度进行校验，之后再从第二用户的诚信等级角度进行校验，等等。

其中，之所以从时间长度角度进行校验，是因为：

在实际应用中，造成第二用户退款的原因一般有多种，例如，可能是第二用户又看中了其他的类似产品，或者，还可能是在收到货品之后发现有质量问题，等等。另外，还有一种原因是：第二用户在付款之后，第一用户长时间未发货，第二用户不想再等待，以至于需要进行退款。针对前几种情况，传统的 退款方式是更合理的，也就是说，先由第二用户与第一用户进行协商，并且由第一用户同意后再进行退款。而针对最后一种情况，基本上是由第一用户单方面的原因导致的，因此，可以使用本申请实施例中的快速退款方式，这也可以看作是一种系统强制性的退款，也是对于第一用户不守信行为的一种惩罚。

基于以上所述，在本申请实施例中，针对第一用户长时间未发货的情况导致的退款申请，可以允许使用快速退款的方式进行退款。其中，具体实现时，在收到一个第二用户的快速退款申请后，如何判断是否由于第一用户长时间未发货导致的，是需要解决的问题。

为此，在本申请实施例中，提出了“发货合约时间”的概念，一般情况下，该时间可以是由系统默认确定的，例如可以是72小时，等等。或者，如果有些第一用户想要为第二用户提供更为优质的服务，可以另外自行设定发货合约时间，例如承诺在24小时之内进行发货，等等。

这样，在具体提取待校验的关键信息时，就可以提取出目标交易订单的当前状态，并确定出为目标交易订单付款的第一时间点，以及接收到退款请求的第二时间点；这样，具体在进行校验时，就可以对订单状态以及时间长度信息进行校验。

参见图2，在这种方式下，本申请实施例的退款信息处理方法可以包括以下步骤：

S201：对至少一个交易订单的状态进行监控；

S202：当监控到针对目标交易订单的快速退款请求事件时，从所述事件中提取待校验的关键信息；所述关键信息包括：所述目标交易订单的当前状态，为所述目标交易订单付款的第一时间点，以及接收到退款请求的第二时间点；

S203：判断目标交易订单是否处于未发货状态；如果是，则进入步骤S204，否则提示第二用户按照传统的退款流程进行处理；

S204：判断从第一时间点到第二时间点的时间长度是否大于发货合约时间长度；如果是，则确定时间信息符合校验规则，进入步骤S205，否则提示第 二用户按照传统的退款流程进行处理；

其中，如果第一用户设定了自己的发货合约时间，则会在服务器中保存相关的信息，并且可以优先使用第一用户设定的发货合约时间进行判断。此时，还可以首先从目标交易订单中提取目标第一用户标识信息，然后根据目标第一用户标识信息，确定该目标第一用户设定的发货合约时间长度。如果目标第一用户未设定发货合约时间，则将系统默认的时间长度确定为所述发货合约时间长度。

S205：确定所述目标交易订单关联的退款金额，并调用预置的同意退款接口，以便将相应的金额退还到相应的付款账户。

当然，由于本申请实施例中进行退款信息处理的主体是交易平台服务器，相对于第一用户以及第二用户而言，都是一种第三方的系统，而第一用户一般又会与其他的物流服务提供方合作，完成货品的发货以及配送等流程，因此，交易平台服务器一般无法直接获知货品在物流状态，而是要由第一用户或者相关的物流服务提供方，在发货后手动修改对应交易订单的状态，系统才能够根据这种状态信息，知晓第一用户是否已经发货。因此，在上述判断的过程中，有可能出现的一种情况是：系统判断出目标交易订单处于未发货状态，并且申请退款的时间距离付款的时间确实已经超出了发货合约时间，于是就直接为第二用户进行了退款处理。但是实际上第一用户可能已经针对相关的货品发货了，只是尚未及时在系统中更新交易订单的状态。这样情况可能会给第一用户造成经济损失，针对这种情况，在实际应用中，可以为第一用户提供申诉途径，使得第一用户能够通过申诉来避免自己受到损失，如果申诉成功，相关的款项可以由系统承担。关于具体申诉过程的具体实现，由于与本申请实施例的技术方案无关，因此，不再详述。

上述校验方式，对订单状态以及距离付款的时间进行了校验，除此之外，在实际应用中，还可以对第二用户的诚信等级进行校验。这是因为：系统中可能存在一些诚信等级比较低第二用户，对于这种第二用户而言，可能会利用本申请实施例中的快速退款通道达到其他目的，破坏系统的秩序，影响到正常用户对系统的使用。例如，如前文所述，在实现快速退款的过程中，实际上系统 是承担了一些风险的，比如前述第一用户已经发货，但只是未更新交易订单状态的情况下，系统需要对第一用户进行赔付。部分第二用户可能会将其看作是系统的漏洞，恶意使用该功能，从而达到既收到了退款，又收到了货品的目的。

为此，在本申请实施例中，还可以对用户的诚信等级进行校验，如果诚信等级很低的第二用户，即使在退款时间上满足前述规则，也拒绝为其提供快速退款服务。换言之，本申请实施例提供的快速退款通道可以是专门为诚信等级比较高的第二用户提供的，这样的第二用户属于系统中的优质用户，系统对其有较高的信任度，也愿意承担相应的风险。这样有利于维护系统的秩序，另外，也可以激励第二用户提高自己的诚信等级，以获得相应的高端服务。

另外，对于诚信等级满足条件的不同的第二用户而言，其诚信等级可能仍然有高低之分，为此，在具体实现时，还可以预先为各种不同的诚信等级设定不同的授信额度，这样，在进行执行快速退款校验时，还可以判断需要退款的金额是否大于当前第二用户诚信等级对应的授信额度，只有在结果为肯定的状态下，才为其进行快速退款。这样，可以进一步降低系统的风险。

也就是说，在前述步骤S202中，从事件中提取的关键信息还可以包括交易中的目标第二用户标识，这样，具体在判断所述关键信息是否符合预置的校验规则时，还可以从预置的数据库中提取目标第二用户的诚信等级信息，判断该诚信等级信息是否满足预置条件。例如，参见图3，在步骤S205之前，还可以包括：

S206：从预置的数据库中提取目标第二用户的诚信等级信息；

S207：判断所述诚信等级是否高于预置的阈值，如果是，进入步骤S208；

S208：根据预置的诚信等级与授信额度之间的对应关系，确定所述目标第二用户的诚信等级信息对应的目标授信额度；

S209：判断所述目标交易订单中的退款金额是否小于所述目标授信额度，如果是，则确定所述诚信等级信息是否满足预置条件，进入步骤S205。

需要说明的是，图3中的步骤S201、S203、S204以及S205均与图2中 对应的步骤相同，这里不再赘述。

通过上述关于第二用户诚信等级的校验，可以降低系统风险。而在具体实现时，为了进一步降低系统风险，还可以对同一第二用户在最近一段时间内请求进行快速退款的次数进行限制，避免同一第二用户在短时间内频繁地进行快速退款。具体的，参见图4，在步骤S205之前，还可以包括以下步骤：

S210：从所述交易订单中提取交易中的目标第一用户以及目标第二用户标识；

S211：判断在最近预置时间段内，所述第二用户针对所述与所述目标第一用户的交易订单发起所述快速退款请求的次数是否小于预置的阈值，如果是，则进入步骤S205。

需要说明的是，图3中的步骤S201至S209均与图3中对应的步骤相同，这里不再赘述。

总之，在本申请实施例中，可以为用户提供快速退款的通道，在对关键信息进行校验通过后，不需要第一用户进行操作，即可自动调用同意退款接口，将相应的金额退还到相应的付款账户，因此，使得退款流程更加便捷高效。

与本申请实施例提供的退款信息处理方法相对应，本申请实施例还提供了一种退款信息处理装置，参见图5，该装置具体可以包括：

监控单元501，用于对至少一个交易订单的状态进行监控；

关键信息提取单元502，用于当监控到针对目标交易订单的快速退款请求事件时，从所述事件中提取待校验的关键信息；

判断单元503，用于判断所述关键信息是否符合预置的校验规则，如果是，则确定所述目标交易订单关联的退款金额，并调用预置的同意退款接口，以便将相应的金额退还到相应的付款账户。

其中，所述从所述事件中提取的待校验的关键信息包括：所述目标交易订单的当前状态，为所述目标交易订单付款的第一时间点，以及接收到退款请求的第二时间点；

所述判断单元503具体可以包括：

第一判断子单元，用于判断所述目标交易订单是否处于未发货状态；

第二判断子单元，用于如果所述第一判断子单元的判断结果为是，则判断从第一时间点到第二时间点的时间长度是否大于发货合约时间长度；

第一确定子单元，用于如果所述第二判断子单元的判断结果为是，则确定时间信息符合校验规则。

其中，所述发货合约时间长度为交易中的第一用户预先设定，所述第一用户为业务对象所有方用户；所述装置还包括：

用户标识信息提取单元，用于从所述目标交易订单中提取目标第一用户标识信息；

第一时间长度信息确定单元，用于根据所述目标第一用户标识信息，确定该目标第一用户设定的发货合约时间长度。

或者，所述装置还可以包括：

第二时间长度信息确定单元，用于如果所述目标第一用户未设定发货合约时间，则将系统默认的时间长度确定为所述发货合约时间长度。

另外，所述从所述事件中提取的待校验的关键信息还可以包括：交易中的目标第二用户标识，所述第二用户为业务对象的消费方用户；

所述判断单元503还可以包括：

诚信等级信息提取子单元，用于从预置的数据库中提取所述目标第二用户的诚信等级信息；

第三判断子单元，用于判断所述诚信等级信息是否满足预置条件。

其中，所述第三判断子单元具体用于：

判断所述诚信等级是否高于预置的阈值；

如果是，则根据预置的诚信等级与授信额度之间的对应关系，确定所述目 标第二用户的诚信等级信息对应的目标授信额度；

判断所述目标交易订单中的退款金额是否小于所述目标授信额度；

如果是，则确定所述诚信等级信息是否满足预置条件。

此外，该装置还可以包括：

用户信息提取单元，用于在所述调用预置的同意退款接口之前，从所述交易订单中提取交易中的目标第一用户以及目标第二用户标识；

退款次数判断单元，用于判断在最近预置时间段内，所述第二用户针对所述与所述目标第一用户的交易订单发起所述快速退款请求的次数；

触发单元，用于如果所述次数小于预置的阈值，则触发执行所述调用预置的同意退款接口的步骤。

在本申请实施例中，可以为用户提供快速退款的通道，在对关键信息进行校验通过后，不需要第一用户进行操作，即可自动调用同意退款接口，将相应的金额退还到相应的付款账户，因此，使得退款流程更加便捷高效。

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

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

以上对本申请所提供的退款信息处理方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。