本公开实施例涉及互联网支付技术领域，具体而言，涉及互联网支付渠道的监控方法、互联网支付渠道的监控装置、计算机设备和计算机可读存储介质。
背景技术
目前，现有的某些互联网平台，尤其是新兴的创业平台可能没有支付牌照，因此为了便于用户支付，需要接入支付宝、微信等互联网支付渠道，所以在支付的过程中，需要用户跳转到互联网支付渠道完成支付动作，由互联网支付渠道完成资金的代扣，然后结算给互联网平台。在整个过程中，互联网支付渠道的稳定性情况就会对用户的支付体验产生很大的影响，如果互联网支付渠道与互联网平台的衔接出现了问题或者互联网支付渠道本身出现了问题，那么用户就无法通过出问题的支付渠道完成支付，此时会导致大量的用户进线跟投诉。
针对上述问题，现有的处理方式为在得知大量用户投诉或者客服接收到大量的投诉电话后，通过手动关闭支付渠道的方式来解决，等互联网支付渠道恢复稳定后，再手动恢复支付渠道，这种方式很难监控支付渠道的稳定性，只有通过用户反馈后手动下掉支付渠道的方式来解决，这会给用户带来困扰。但是，当交易完成的时候，支付是及其重要的一环。如果乘客支付失败，或者这单很久之后才会支付，导致用户体验差，特别是当遇到司机要求乘客支付成功后再下车的情况时，支付失败或延迟支付成功给双方带来的沟通和时间成本都很高。所以，如何削弱外部互联网支付渠道的服务质量对自身服务质量的影响变得重要。
技术实现要素：
本公开实施例正是基于上述问题，提出了一种新的技术方案，可以实现对互联网支付渠道的稳定性的及时监控，快速发现支付渠道的服务质量变化情况，从而及时对互联网支付渠道的支付请求流量进行平滑调整，提高支付服务效率，同时还能够使用户及时知晓无法正常支付的真正原因，并促进互联网支付渠道为应用软件等互联网平台提供更优质的支付服务，以提升用户体验。
有鉴于此，根据本公开实施例的第一方面，提出了一种互联网支付渠道的监控方法，应用软件接入所述互联网支付渠道以进行支付，所述方法包括：采集所述互联网支付渠道与所述应用软件关联的支付统计信息；根据所述支付统计信息确定所述互联网支付渠道稳定工作时的参考成功率；获取所述应用软件通过所述互联网支付渠道进行当前支付的实时成功率；根据所述实时成功率、所述参考成功率以及预设调整阈值确定是否对所述互联网支付渠道的支付请求流量进行调整。
在该技术方案中，当应用软件通过接入的互联网支付渠道(比如支付宝、微信等第三方支付渠道)进行费用结算时，为了实现对互联网支付渠道的服务稳定性的及时监控，可以通过预先采集应用软件正常使用互联网支付渠道过程中产生的支付统计信息来确定该支付渠道稳定工作时的参考成功率作为监控基准，然后实时监控应用软件通过互联网支付渠道进行支付时的实时成功率，以进一步结合预设调整阈值确定是否对互联网支付渠道的支付请求流量进行调整，即通过快速发现支付渠道的服务质量变化情况，以及时对互联网支付渠道的支付请求流量进行平滑调整，从而提高支付服务效率，提升用户体验。
其中，所述应用软件可以为网约车应用软件。
在上述技术方案中，优选地，所述根据所述实时成功率、所述参考成功率以及预设调整阈值确定是否对所述互联网支付渠道的支付请求流量进行调整的步骤，包括：将所述实时成功率、所述参考成功率代入第一计算公式确定进行当前支付时所述互联网支付渠道的稳定值；判断所述稳定值是否大于所述预设调整阈值；若是，对所述互联网支付渠道进行流量降级处理，否则保持所述互联网支付渠道的当前状态，其中，所述第一计算公式为：所述稳定值＝(所述实时成功率-所述参考成功率)/所述参考成功率。
该技术方案，在结合参考成功率、当前支付的实时成功率以及预设调整阈值对互联网支付渠道的支付请求流量进行管控调整时，具体地，首先根据实时成功率和参考成功率确定表征当前支付过程中互联网支付渠道服务质量的稳定值，进而根据稳定值和预设调整阈值的大小关系来确定何时对互联网支付渠道进行支付请求流量的降级处理，从而实现将互联网支付渠道的服务稳定性维持在容忍程度内，保证应用软件接入的互联网支付渠道的稳定性。
在上述任一技术方案中，优选地，当判定所述稳定值大于所述预设调整阈值，对所述互联网支付渠道进行流量降级处理的步骤包括：向所述应用软件的占比为所述稳定值的用户发出表明所述互联网支付渠道不稳定的提示信息。
在该技术方案中，具体地可以通过向部分应用软件的使用用户发出提示信息，告知这部分用户应用软件接入的互联网支付渠道提供的支付服务目前不稳定，使用户知晓无法正常支付的真正原因的同时，降低互联网支付渠道的用户进线，对其支付请求流量进行降级，减轻互联网支付渠道的负担，在保证用户体验的基础上，同时保证应用软件接入的互联网支付渠道的运行稳定性，提高服务质量；其中，该部分应用软件的使用用户为在其总用户中占比为计算出的稳定阈值的那部分用户，即对占比为(实时成功率-参考成功率)/参考成功率的用户提示互联网支付渠道不稳定，其余占比为(1-(实时成功率-参考成功率)/参考成功率)的用户不进行提示。
在上述任一技术方案中，优选地，所述支付统计信息包括：所述应用软件向所述互联网支付渠道发起支付请求的发起成功数量和发起失败数量，所述互联网支付渠道支付成功后的回调数量以及所述应用软件发起的关单数量。
在该技术方案中，需要预先采集统计的支付统计信息应至少包括：应用软件向互联网支付渠道发起支付请求后的发起成功数量，即订单生效后从应用软件的操作界面成功跳转到互联网支付渠道进行支付动作的次数；应用软件向互联网支付渠道发起支付请求后的发起失败数量，即订单生效后从应用软件的操作界面未成功跳转至互联网支付渠道进行支付动作的次数；以及通过互联网支付渠道支付成功后向应用软件反馈支付成功结果的回调数量和用户通过应用软件提交订单后又取消订单的关单数量。如此，通过统计与互联网支付渠道的服务质量稳定性关联较大的信息确定其稳定工作时的参考成功率，能够使结果更加准确，从而能够更好地监控互联网支付渠道的稳定性。
在上述任一技术方案中，优选地，所述根据所述支付统计信息确定所述互联网支付渠道稳定工作时的参考成功率的步骤，包括：将所述发起成功数量、所述发起失败数量和所述关单数量代入第二计算公式确定所述互联网支付渠道的平均发起成功率；将所述发起成功数量和所述回调数量代入第三计算公式确定回调成功率；将所述平均发起成功率和所述回调成功率进行比较，并将二者中较小的作为所述参考成功率，其中，所述第二计算公式为：所述平均发起成功率＝所述发起成功数量/(所述发起成功数量+所述发起失败数量-所述关单数量)，以及所述第三计算公式为：所述回调成功率＝所述回调数量/所述发起成功数量。
在该技术方案中，为了确保参考成功率的准确性和有效性，可以首先通过发起成功数量、发起失败数量和关单数量计算出互联网支付渠道的平均发起成功率，以及通过发起成功数量和回调数量计算出通过互联网支付渠道支付成功后的回调成功率，进而将平均发起成功率和回调成功率之中较小的作为参考成功率，以尽可能提高对于互联网支付渠道稳定性的容忍程度，提升互联网支付渠道的服务质量。
在上述任一技术方案中，优选地，所述获取所述应用软件通过所述互联网支付渠道进行当前支付的实时成功率的步骤，包括：获取预设时间段内所述应用软件向所述互联网支付渠道发起支付请求的当前发单量、和所述互联网支付渠道支付成功后的当前回调数量；将所述当前回调数量与所述当前发单量的比值作为所述实时成功率。
在该技术方案中，可以根据应用软件在一定时间段(即预设时间段，比如10分钟)内向互联网支付渠道请求支付的当前发单量、和该互联网支付渠道针对该发单量支付成功且反馈给应用软件的当前回调数量确定实时成功率，具体地将当前回调数量与当前发单量的比值作为实时成功率，以确保能够成功获取到该实时成功率且保证准确性。
根据本公开实施例的第二方面，提出了一种互联网支付渠道的监控装置，应用软件接入所述互联网支付渠道以进行支付，所述监控装置包括：采集模块，用于采集所述互联网支付渠道与所述应用软件关联的支付统计信息；确定模块，用于根据所述采集模块采集的所述支付统计信息确定所述互联网支付渠道稳定工作时的参考成功率；获取模块，用于获取所述应用软件通过所述互联网支付渠道进行当前支付的实时成功率；处理模块，用于根据所述实时成功率、所述参考成功率以及预设调整阈值确定是否对所述互联网支付渠道的支付请求流量进行调整。
在该技术方案中，当应用软件通过接入的互联网支付渠道(比如支付宝、微信等第三方支付渠道)进行费用结算时，为了实现对互联网支付渠道的服务稳定性的及时监控，可以通过预先采集应用软件正常使用互联网支付渠道过程中产生的支付统计信息来确定该支付渠道稳定工作时的参考成功率作为监控基准，然后实时监控应用软件通过互联网支付渠道进行支付时的实时成功率，以进一步结合预设调整阈值确定是否对互联网支付渠道的支付请求流量进行调整，即通过快速发现支付渠道的服务质量变化情况，以及时对互联网支付渠道的支付请求流量进行平滑调整，从而提高支付服务效率，提升用户体验。
其中，所述应用软件可以为网约车应用软件。
在上述技术方案中，优选地，所述处理模块包括：第一计算子模块，用于将所述实时成功率、所述参考成功率代入第一计算公式确定进行当前支付时所述互联网支付渠道的稳定值；判断子模块，用于判断所述第一计算子模块计算得到的所述稳定值是否大于所述预设调整阈值；处理子模块，用于在所述判断子模块判定为是时，对所述互联网支付渠道进行流量降级处理，否则保持所述互联网支付渠道的当前状态，其中，所述第一计算公式为：所述稳定值＝(所述实时成功率-所述参考成功率)/所述参考成功率。
该技术方案，在结合参考成功率、当前支付的实时成功率以及预设调整阈值对互联网支付渠道的支付请求流量进行管控调整时，具体地，首先根据实时成功率和参考成功率确定表征当前支付过程中互联网支付渠道服务质量的稳定值，进而根据稳定值和预设调整阈值的大小关系来确定何时对互联网支付渠道进行支付请求流量的降级处理，从而实现将互联网支付渠道的服务稳定性维持在容忍程度内，保证应用软件接入的互联网支付渠道的稳定性。
在上述任一技术方案中，优选地，当所述判断子模块判定所述稳定值大于所述预设调整阈值，所述处理子模块具体用于：向所述应用软件的占比为所述稳定值的用户发出表明所述互联网支付渠道不稳定的提示信息。
在该技术方案中，具体地可以通过向部分应用软件的使用用户发出提示信息，告知这部分用户应用软件接入的互联网支付渠道提供的支付服务目前不稳定，使用户知晓无法正常支付的真正原因的同时，降低互联网支付渠道的用户进线，对其支付请求流量进行降级，减轻互联网支付渠道的负担，在保证用户体验的基础上，同时保证应用软件接入的互联网支付渠道的运行稳定性，提高服务质量；其中，该部分应用软件的使用用户为在其总用户中占比为计算出的稳定阈值的那部分用户，即对占比为(实时成功率-参考成功率)/参考成功率的用户提示互联网支付渠道不稳定，其余占比为(1-(实时成功率-参考成功率)/参考成功率)的用户不进行提示。
在上述任一技术方案中，优选地，所述支付统计信息包括：所述应用软件向所述互联网支付渠道发起支付请求的发起成功数量和发起失败数量，所述互联网支付渠道支付成功后的回调数量以及所述应用软件发起的关单数量。
在该技术方案中，需要预先采集统计的支付统计信息应至少包括：应用软件向互联网支付渠道发起支付请求后的发起成功数量，即订单生效后从应用软件的操作界面成功跳转到互联网支付渠道进行支付动作的次数；应用软件向互联网支付渠道发起支付请求后的发起失败数量，即订单生效后从应用软件的操作界面未成功跳转至互联网支付渠道进行支付动作的次数；以及通过互联网支付渠道支付成功后向应用软件反馈支付成功结果的回调数量和用户通过应用软件提交订单后又取消订单的关单数量。如此，通过统计与互联网支付渠道的服务质量稳定性关联较大的信息确定其稳定工作时的参考成功率，能够使结果更加准确，从而能够更好地监控互联网支付渠道的稳定性。
在上述任一技术方案中，优选地，所述确定模块包括：第二计算子模块，用于将所述发起成功数量、所述发起失败数量和所述关单数量代入第二计算公式确定所述互联网支付渠道的平均发起成功率；第三计算子模块，用于将所述发起成功数量和所述回调数量代入第三计算公式确定回调成功率；比较子模块，用于将所述平均发起成功率和所述回调成功率进行比较，并将二者中较小的作为所述参考成功率，其中，所述第二计算公式为：所述平均发起成功率＝所述发起成功数量/(所述发起成功数量+所述发起失败数量-所述关单数量)，以及所述第三计算公式为：所述回调成功率＝所述回调数量/所述发起成功数量。
在该技术方案中，为了确保参考成功率的准确性和有效性，可以首先通过发起成功数量、发起失败数量和关单数量计算出互联网支付渠道的平均发起成功率，以及通过发起成功数量和回调数量计算出通过互联网支付渠道支付成功后的回调成功率，进而将平均发起成功率和回调成功率之中较小的作为参考成功率，以尽可能提高对于互联网支付渠道稳定性的容忍程度，提升互联网支付渠道的服务质量。
在上述任一技术方案中，优选地，所述获取模块包括：获取子模块，用于获取预设时间段内所述应用软件向所述互联网支付渠道发起支付请求的当前发单量、和所述互联网支付渠道支付成功后的当前回调数量；第四计算子模块，用于将所述获取子模块得到的所述当前回调数量与所述当前发单量的比值作为所述实时成功率。
在该技术方案中，可以根据应用软件在一定时间段(即预设时间段，比如10分钟)内向互联网支付渠道请求支付的当前发单量、和该互联网支付渠道针对该发单量支付成功且反馈给应用软件的当前回调数量确定实时成功率，具体地将当前回调数量与当前发单量的比值作为实时成功率，以确保能够成功获取到该实时成功率且保证准确性。
根据本公开实施例的第三方面，提出了一种计算机设备，所述计算机设备包括处理器，所述处理器用于执行存储器中存储的计算机程序时实现如上述第一方面的技术方案中任一项所述监控方法的步骤。
根据本公开实施例的第四方面，提出了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述第一方面的技术方案中任一项所述监控方法的步骤。
通过本公开实施例的上述技术方案，可以实现对互联网支付渠道的稳定性的及时监控，快速发现支付渠道的服务质量变化情况，从而及时对互联网支付渠道的支付请求流量进行平滑调整，提高支付服务效率，同时还能够使用户及时知晓无法正常支付的真正原因，并促进互联网支付渠道为应用软件等互联网平台提供更优质的支付服务，以提升用户体验。
附图说明
图1示出了本公开实施例的互联网支付渠道的监控方法的流程示意图；
图2示出了本公开实施例的根据实时成功率、参考成功率以及预设调整阈值确定是否对互联网支付渠道的支付请求流量进行调整的方法流程示意图；
图3示出了本公开实施例的根据支付统计信息确定互联网支付渠道稳定工作时的参考成功率的方法流程示意图；
图4示出了本公开实施例的互联网支付渠道的监控装置的示意框图；
图5示出了图4所示的处理模块的示意框图；
图6示出了图4所示的确定模块的示意框图；
图7示出了图4所述的获取模块的示意框图；
图8示出了本公开实施例的计算机设备的示意框图。
具体实施方式
为了可以更清楚地理解本公开实施例的上述目的、特征和优点，下面结合附图和具体实施方式对本公开实施例进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。
在下面的描述中阐述了很多具体细节以便于充分理解本公开实施例，但是，本公开实施例还可以采用其他不同于在此描述的其他方式来实施，因此，本公开实施例的保护范围并不受下面公开的具体实施例的限制。
下面结合图1至图3对本公开实施例的互联网支付渠道的监控方法进行详细说明。
如图1所示，根据本公开实施例的互联网支付渠道的监控方法，应用软件接入所述互联网支付渠道以进行支付，所述监控方法具体包括以下流程步骤：
步骤s10，采集所述互联网支付渠道与所述应用软件关联的支付统计信息。
步骤s20，根据所述支付统计信息确定所述互联网支付渠道稳定工作时的参考成功率。
步骤s30，获取所述应用软件通过所述互联网支付渠道进行当前支付的实时成功率。
步骤s40，根据所述实时成功率、所述参考成功率以及预设调整阈值确定是否对所述互联网支付渠道的支付请求流量进行调整。
在该实施例中，当应用软件通过接入的互联网支付渠道(比如支付宝、微信等第三方支付渠道)进行费用结算时，为了实现对互联网支付渠道的服务稳定性的及时监控，可以通过预先采集应用软件正常使用互联网支付渠道过程中产生的支付统计信息来确定该支付渠道稳定工作时的参考成功率作为监控基准，然后实时监控应用软件通过互联网支付渠道进行支付时的实时成功率，以进一步结合预设调整阈值确定是否对互联网支付渠道的支付请求流量进行调整，即通过快速发现支付渠道的服务质量变化情况，以及时对互联网支付渠道的支付请求流量进行平滑调整，从而提高支付服务效率，提升用户体验。
其中，所述应用软件可以为网约车应用软件。
其中，通过设定预设调整阈值来控制对于互联网支付渠道稳定性的容忍程度，预设调整阈值越小，说明越不容忍支付渠道失效，预设调整阈值越大，说明对支付渠道的容忍度越高，预设调整阈值的设定取决于具体策略，比如预设调整阈值可以取10％。
进一步地，如图2所示，上述实施例中的步骤s40可以具体执行为如下流程步骤：
步骤s402，将所述实时成功率、所述参考成功率代入第一计算公式确定进行当前支付时所述互联网支付渠道的稳定值。
步骤s404，判断所述稳定值是否大于所述预设调整阈值。
步骤s406，若是，对所述互联网支付渠道进行流量降级处理，否则保持所述互联网支付渠道的当前状态。
进一步地，所述第一计算公式为：所述稳定值＝(所述实时成功率-所述参考成功率)/所述参考成功率。
该实施例，在结合参考成功率、当前支付的实时成功率以及预设调整阈值对互联网支付渠道的支付请求流量进行管控调整时，具体地，首先根据实时成功率和参考成功率确定表征当前支付过程中互联网支付渠道服务质量的稳定值，进而根据稳定值和预设调整阈值的大小关系来确定何时对互联网支付渠道进行支付请求流量的降级处理，从而实现将互联网支付渠道的服务稳定性维持在容忍程度内，保证应用软件接入的互联网支付渠道的稳定性。
进一步地，对于上述步骤s406，当判定所述稳定值大于所述预设调整阈值，对所述互联网支付渠道进行流量降级处理时，具体地可以执行为：向所述应用软件的占比为所述稳定值的用户发出表明所述互联网支付渠道不稳定的提示信息。
在该实施例中，具体地可以通过向部分应用软件的使用用户发出提示信息，告知这部分用户应用软件接入的互联网支付渠道提供的支付服务目前不稳定，使用户知晓无法正常支付的真正原因的同时，降低互联网支付渠道的用户进线，对其支付请求流量进行降级，减轻互联网支付渠道的负担，在保证用户体验的基础上，同时保证应用软件接入的互联网支付渠道的运行稳定性，提高服务质量；其中，该部分应用软件的使用用户为在其总用户中占比为计算出的稳定阈值的那部分用户，即对占比为(实时成功率-参考成功率)/参考成功率的用户提示互联网支付渠道不稳定，其余占比为(1-(实时成功率-参考成功率)/参考成功率)的用户不进行提示，具体地，底层服务端通过检测到的数据，与前端约定错误码与提示信息，前端根据服务端的错误码显示渠道不稳定的提示信息给用户。
进一步地，在上述实施例中，当实际监控到的实时成功率与参考成功率的差距较小，即在可控制的阈值范围内时，可以完全回复互联网支付渠道。
进一步地，在上述任一实施例中，所述支付统计信息包括：所述应用软件向所述互联网支付渠道发起支付请求的发起成功数量和发起失败数量，所述互联网支付渠道支付成功后的回调数量以及所述应用软件发起的关单数量。
在该实施例中，需要预先采集统计的支付统计信息应至少包括：应用软件向互联网支付渠道发起支付请求后的发起成功数量，即订单生效后从应用软件的操作界面成功跳转到互联网支付渠道进行支付动作的次数；应用软件向互联网支付渠道发起支付请求后的发起失败数量，即订单生效后从应用软件的操作界面未成功跳转至互联网支付渠道进行支付动作的次数；以及通过互联网支付渠道支付成功后向应用软件反馈支付成功结果的回调数量和用户通过应用软件提交订单后又取消订单的关单数量。如此，通过统计与互联网支付渠道的服务质量稳定性关联较大的信息确定其稳定工作时的参考成功率，能够使结果更加准确，从而能够更好地监控互联网支付渠道的稳定性。
其中，在采集上述支付统计信息的过程中，监控的是第三支付渠道的总体情况，不以单个服务节点的数据采集和评估为参考，既可以收集采取下游上报的方式获取支付统计信息，比如通过在交易流程中嵌入上报逻辑的方式；当然也可以通过主动采集的方式获取支付统计信息，比如通过拉取数据库中交易单状态收集互联网支付渠道的服务质量。
进一步地，基于上述实施例里，图1中所示的步骤s20可以具体执行为如图3所示的流程步骤，包括：
步骤s202，将所述发起成功数量、所述发起失败数量和所述关单数量代入第二计算公式确定所述互联网支付渠道的平均发起成功率。
步骤s204，将所述发起成功数量和所述回调数量代入第三计算公式确定回调成功率。
步骤s206，将所述平均发起成功率和所述回调成功率进行比较，并将二者中较小的作为所述参考成功率。
进一步地，所述第二计算公式为：所述平均发起成功率＝所述发起成功数量/(所述发起成功数量+所述发起失败数量-所述关单数量)，以及所述第三计算公式为：所述回调成功率＝所述回调数量/所述发起成功数量。
在该实施例中，为了确保参考成功率的准确性和有效性，可以首先通过发起成功数量、发起失败数量和关单数量计算出互联网支付渠道的平均发起成功率，以及通过发起成功数量和回调数量计算出通过互联网支付渠道支付成功后的回调成功率，进而将平均发起成功率和回调成功率之中较小的作为参考成功率，以尽可能提高对于互联网支付渠道稳定性的容忍程度，提升互联网支付渠道的服务质量。
进一步地，在上述任一实施例中，所述步骤s30可以具体执行为：
获取预设时间段内所述应用软件向所述互联网支付渠道发起支付请求的当前发单量、和所述互联网支付渠道支付成功后的当前回调数量；将所述当前回调数量与所述当前发单量的比值作为所述实时成功率。
在该实施例中，可以根据应用软件在一定时间段(即预设时间段，比如10分钟)内向互联网支付渠道请求支付的当前发单量、和该互联网支付渠道针对该发单量支付成功且反馈给应用软件的当前回调数量确定实时成功率，具体地将当前回调数量与当前发单量的比值作为实时成功率，以确保能够成功获取到该实时成功率且保证准确性。
下面结合图4至图7对本公开实施例的支付渠道的监控装置进行详细说明。
如图4所示，根据本公开实施例的支付渠道的监控装置40，应用软件接入所述互联网支付渠道以进行支付，所述监控装置40包括：采集模块402、确定模块404、确定模块404和处理模块408。
其中，所述采集模块402用于采集所述互联网支付渠道与所述应用软件关联的支付统计信息；所述确定模块404用于根据所述采集模块402采集的所述支付统计信息确定所述互联网支付渠道稳定工作时的参考成功率；所述获取模块406用于根据所述采集模块402采集的所述支付统计信息确定所述互联网支付渠道稳定工作时的参考成功率；所述处理模块408用于根据所述实时成功率、所述参考成功率以及预设调整阈值确定是否对所述互联网支付渠道的支付请求流量进行调整。
在该实施例中，当应用软件通过接入的互联网支付渠道(比如支付宝、微信等第三方支付渠道)进行费用结算时，为了实现对互联网支付渠道的服务稳定性的及时监控，可以通过预先采集应用软件正常使用互联网支付渠道过程中产生的支付统计信息来确定该支付渠道稳定工作时的参考成功率作为监控基准，然后实时监控应用软件通过互联网支付渠道进行支付时的实时成功率，以进一步结合预设调整阈值确定是否对互联网支付渠道的支付请求流量进行调整，即通过快速发现支付渠道的服务质量变化情况，以及时对互联网支付渠道的支付请求流量进行平滑调整，从而提高支付服务效率，提升用户体验。
其中，所述应用软件可以为网约车应用软件。
其中，通过设定预设调整阈值来控制对于互联网支付渠道稳定性的容忍程度，预设调整阈值越小，说明越不容忍支付渠道失效，预设调整阈值越大，说明对支付渠道的容忍度越高，预设调整阈值的设定取决于具体策略，比如预设调整阈值可以取10％。
进一步地，如图5所示，上述实施例中的所述处理模块408具体包括：第一计算子模块4082、判断子模块4084和处理子模块4086。
其中，所述第一计算子模块4082用于将所述实时成功率、所述参考成功率代入第一计算公式确定进行当前支付时所述互联网支付渠道的稳定值；所述判断子模块4084用于判断所述第一计算子模块4082计算得到的所述稳定值是否大于所述预设调整阈值；所述处理子模块4086用于在所述判断子模块4084判定为是时，对所述互联网支付渠道进行流量降级处理，否则保持所述互联网支付渠道的当前状态。
进一步地，所述第一计算公式为：所述稳定值＝(所述实时成功率-所述参考成功率)/所述参考成功率。
该实施例，在结合参考成功率、当前支付的实时成功率以及预设调整阈值对互联网支付渠道的支付请求流量进行管控调整时，具体地，首先根据实时成功率和参考成功率确定表征当前支付过程中互联网支付渠道服务质量的稳定值，进而根据稳定值和预设调整阈值的大小关系来确定何时对互联网支付渠道进行支付请求流量的降级处理，从而实现将互联网支付渠道的服务稳定性维持在容忍程度内，保证应用软件接入的互联网支付渠道的稳定性。
进一步地，在上述实施例中，当所述判断子模块4084判定所述稳定阈值大于所述预设调整阈值，所述处理子模块4086具体用于：向所述应用软件的占比为所述稳定阈值的用户发出表明所述互联网支付渠道不稳定的提示信息。
在该实施例中，具体地可以通过向部分应用软件的使用用户发出提示信息，告知这部分用户应用软件接入的互联网支付渠道提供的支付服务目前不稳定，使用户知晓无法正常支付的真正原因的同时，降低互联网支付渠道的用户进线，对其支付请求流量进行降级，减轻互联网支付渠道的负担，在保证用户体验的基础上，同时保证应用软件接入的互联网支付渠道的运行稳定性，提高服务质量；其中，该部分应用软件的使用用户为在其总用户中占比为计算出的稳定阈值的那部分用户，即对占比为(实时成功率-参考成功率)/参考成功率的用户提示互联网支付渠道不稳定，其余占比为(1-(实时成功率-参考成功率)/参考成功率)的用户不进行提示，具体地，底层服务端通过检测到的数据，与前端约定错误码与提示信息，前端根据服务端的错误码显示渠道不稳定的提示信息给用户。
进一步地，在上述实施例中，当实际监控到的实时成功率与参考成功率的差距较小，即在可控制的阈值范围内时，可以完全回复互联网支付渠道。
进一步地，在上述任一实施例中，所述支付统计信息包括：所述应用软件向所述互联网支付渠道发起支付请求的发起成功数量和发起失败数量，所述互联网支付渠道支付成功后的回调数量以及所述应用软件发起的关单数量。
在该实施例中，需要预先采集统计的支付统计信息应至少包括：应用软件向互联网支付渠道发起支付请求后的发起成功数量，即订单生效后从应用软件的操作界面成功跳转到互联网支付渠道进行支付动作的次数；应用软件向互联网支付渠道发起支付请求后的发起失败数量，即订单生效后从应用软件的操作界面未成功跳转至互联网支付渠道进行支付动作的次数；以及通过互联网支付渠道支付成功后向应用软件反馈支付成功结果的回调数量和用户通过应用软件提交订单后又取消订单的关单数量。如此，通过统计与互联网支付渠道的服务质量稳定性关联较大的信息确定其稳定工作时的参考成功率，能够使结果更加准确，从而能够更好地监控互联网支付渠道的稳定性。
其中，在采集上述支付统计信息的过程中，监控的是第三支付渠道的总体情况，不以单个服务节点的数据采集和评估为参考，既可以收集采取下游上报的方式获取支付统计信息，比如通过在交易流程中嵌入上报逻辑的方式；当然也可以通过主动采集的方式获取支付统计信息，比如通过拉取数据库中交易单状态收集互联网支付渠道的服务质量。
进一步地，基于上述实施例，图4中所示的所述确定模块404可以具体包括：第二计算子模块4022、第三计算子模块4024和比较子模块4026，如图6所示。
其中，所述第二计算子模块4022用于将所述发起成功数量、所述发起失败数量和所述关单数量代入第二计算公式确定所述互联网支付渠道的平均发起成功率；所述第三计算子模块4024用于将所述发起成功数量和所述回调数量代入第三计算公式确定回调成功率；所述比较子模块4026用于将所述平均发起成功率和所述回调成功率进行比较，并将二者中较小的作为所述参考成功率。
进一步地，所述第二计算公式为：所述平均发起成功率＝所述发起成功数量/(所述发起成功数量+所述发起失败数量-所述关单数量)，以及所述第三计算公式为：所述回调成功率＝所述回调数量/所述发起成功数量。
在该实施例中，为了确保参考成功率的准确性和有效性，可以首先通过发起成功数量、发起失败数量和关单数量计算出互联网支付渠道的平均发起成功率，以及通过发起成功数量和回调数量计算出通过互联网支付渠道支付成功后的回调成功率，进而将平均发起成功率和回调成功率之中较小的作为参考成功率，以尽可能提高对于互联网支付渠道稳定性的容忍程度，提升互联网支付渠道的服务质量。
进一步地，在上述任一实施例中，图4中所示的所述获取模块406可以具体包括：获取子模块4062和第四计算子模块4064，如图7所示。
其中，所述获取子模块4062用于获取预设时间段内所述应用软件向所述互联网支付渠道发起支付请求的当前发单量、和所述互联网支付渠道支付成功后的当前回调数量；所述第四计算子模块4064用于将所述获取子模块4062得到的所述当前回调数量与所述当前发单量的比值作为所述实时成功率。
在该实施例中，可以根据应用软件在一定时间段(即预设时间段，比如10分钟)内向互联网支付渠道请求支付的当前发单量、和该互联网支付渠道针对该发单量支付成功且反馈给应用软件的当前回调数量确定实时成功率，具体地将当前回调数量与当前发单量的比值作为实时成功率，以确保能够成功获取到该实时成功率且保证准确性。
图8示出了本公开实施例的实施例的计算机设备的示意框图。
如图8所示，根据本公开实施例的实施例的计算机设备80，包括存储器802、处理器804及存储在所述存储器802上并可在所述处理器804上运行的计算机程序，其中存储器802和处理器804之间可以通过总线连接，所述处理器804用于执行存储器802中存储的计算机程序时实现如上述图1至图3的实施例中任一项所述监控方法的步骤。
本公开实施例的方法中的步骤可以根据实际需要进行顺序调整、合并和删减。
本公开实施例的支付渠道的监控装置和计算机设备中的单元可以根据实际需要进行合并、划分和删减。
根据本公开实施例，提出了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述图1至图3的实施例中任一项所述监控方法的步骤。
进一步地，本领域普通技术人员可以理解的是，上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质包括只读存储器(read-onlymemory，rom)、随机存储器(randomaccessmemory，ram)、可编程只读存储器(programmableread-onlymemory，prom)、可擦除可编程只读存储器(erasableprogrammablereadonlymemory，eprom)、一次可编程只读存储器(one-timeprogrammableread-onlymemory，otprom)、电子抹除式可复写只读存储器(electrically-erasableprogrammableread-onlymemory，eeprom)、只读光盘(compactdiscread-onlymemory，cd-rom)或其他光盘存储器、磁盘存储器、磁带存储器、或者能够用于携带或存储数据的计算机可读的任何其他介质。
进一步地，上述计算机设备可以为pc(personalcomputer，个人电脑)端。
以上结合附图详细说明了本公开实施例的技术方案，通过本公开实施例的技术方案，可以实现对互联网支付渠道的稳定性的及时监控，快速发现支付渠道的服务质量变化情况，从而及时对互联网支付渠道的支付请求流量进行平滑调整，提高支付服务效率，同时还能够使用户及时知晓无法正常支付的真正原因，并促进互联网支付渠道为应用软件等互联网平台提供更优质的支付服务，以提升用户体验。
在本公开实施例中，术语“第一”、“第二”和“第三”仅用于描述的目的，而不能理解为指示或暗示相对重要性，对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本公开实施例中的具体含义。
以上所述仅为本公开实施例的优选实施例而已，并不用于限制本公开实施例，对于本领域的技术人员来说，本公开实施例可以有各种更改和变化。凡在本公开实施例的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本公开实施例的保护范围之内。