一种监控支付流程的方法及装置与流程

1.本技术涉及计算机技术领域，尤其涉及一种监控支付流程的方法及装置。


背景技术：

2.ios系统采用苹果提供的iap （in-app purchase）是应用程序app内购买虚拟商品的方式进行支付，支付流程比较复杂，并且偶现一些未知问题。这些问题可能会导致支付流程失败，从而导致用户出现用户支付成功但没有下发权益。因此需要对支付流程进行监控并且记录，避免出现问题无法针对性解决。
3.目前市面上主要是采用对网络接口进行监控的方式，但现有技术的方案只是对网络接口进行监控，无法实现支付流程全链路的监控。因此，如何监控支付流程成为急需解决的问题。


技术实现要素：

4.有鉴于此，本技术的主要目的在于提供一种监控支付流程的方法及装置，实现支付过程全链路的监控。
5.本技术第一方面提供了一种生成身份标识的方法，该方法包括：将支付过程中的n个节点定义到支付枚举中，支付枚举包括：需要进行支付监控的支付过程范围，n大于或等于1；校验用户发起支付的当前节点是否位于支付过程范围；若当前节点位于支付过程范围，则确定当前节点为正确节点；创建包含正确节点的第一队列。
6.在本技术第一方面的一些实现方式中，该方法还可以包括：在支付过程范围中，将进行到节点所产生的支付信息添加至第二队列中，其中，支付信息包括订单号、交易标识id、交易时间；当出现异常节点，将异常节点对应的错误码以及错误信息添加至第二队列中。
7.判断错误码以及错误信息是否需要上报至后台服务器；若错误码以及错误信息需要上报至后台服务器，则对位于第二队列中的当前节点、错误码以及错误信息进行拼接，生成上报信息并将上报信息上报至后台服务器。
8.在本技术第一方面的一些实现方式中，判断错误码以及错误信息是否需要上报至后台服务器，包括：判断当前节点是否位于第一队列中；若当前节点未位于第一队列中，则错误码以及错误信息需要上报至后台服务器。
9.在本技术第一方面的一些实现方式中，该方法还包括：根据错误类型对上报信息进行归类，错误类型与错误码以及错误信息具有映射关系。
10.本技术第二方面提供了一种监控支付流程的装置，该装置包括：
枚举模块，用于将支付过程中的n个节点定义到支付枚举中，支付枚举包括：需要进行支付监控的支付过程范围，n大于或等于1；检验模块，用于校验用户发起支付的当前节点是否位于支付过程范围；若当前节点位于支付过程范围，则确定当前节点为正确节点；创建模块，用于创建包含正确节点的第一队列。
11.在本技术第二方面的一些实现方式中，该装置还包括：添加模块，用于在支付过程范围中，将进行到当前节点所产生的支付信息添加至第二队列中，支付信息包括订单号、交易标识id、交易时间；在一些实现方式中，添加模块还用于当出现异常节点，将异常节点对应的错误码以及错误信息添加至第二队列中；判断模块，用于判断错误码以及错误信息是否需要上报至后台服务器；若错误码以及错误信息需要上报至后台服务器，则对位于第二队列中的当前节点、错误码以及错误信息进行拼接，生成上报信息并将上报信息上报至后台服务器；在一些实现方式中，判断模块还用于判断当前节点是否位于第一队列中；若当前节点未位于第一队列中，则错误码以及错误信息需要上报至后台服务器；分析模块，用于根据错误类型对上报信息进行归类，错误类型与错误码以及错误信息具有映射关系。
12.本技术第三方面提供了一种计算机设备，其特征在于，该设备包括存储器和处理器，处理器用于执行存储器中存储的程序，运行如前述第一方面中任一项的方法。
13.相对于现有技术，本技术所提供的技术方案具有如下有益效果：本技术通过对支付过程中涉及的各个节点进行枚举并记录各个节点的数据，从而实现支付全链路的监控。
14.除上述优点之外，本技术为了提高数据的实时性，将需要上报的数据在本地进行了分析并处理，总的数据量相对较小，因此可以上报到统计后台服务器。并且其中的上报过程采用实时上报的方式，无需进行回捞和用户手动上报的操作，上报后即可统计在后台服务器查询到的上报信息，以保证上报信息的实时性。
附图说明
15.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
16.图1为本技术实施例提供的一种监控支付流程的方法的流程示意图；图2为本技术实施例提供的另一种监控支付流程的方法的流程示意图；图3为本技术实施例提供的另一种监控支付流程的方法的流程示意图；图4为本技术实施例提供的另一种监控支付流程的方法的流程示意图；图5为本技术实施例提供的一种监控支付流程的装置的结构示意图；图6为本技术实施例提供的一种计算机设备的结构示意图。
具体实施方式
17.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
18.本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等（如果存在）是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
19.本技术实施例应用于ios系统，在本技术提供的实施例中，ios用户的终端设备可以是各种形式，例如，手机(mobile phone)、平板电脑(pad)、带无线收发功能的电脑、虚拟现实(virtual reality，vr)终端设备、增强现实(augmented reality，ar)终端设备、工业控制(industrial control)中的无线终端、车载终端设备、无人驾驶(self driving)中的无线终端、远程医疗(remote medical)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端、可穿戴终端设备等等。
20.以ios用户为例，由于苹果支付服务器在境外，偶尔会出现由于互联网长城gfw导致的请求超时；或者也会出现系统iap支付回调异常，先回调一次显示失败，再回调一次显示成功，然而正常情况下回调的结果只有一个，成功或失败。
21.在此情况下，可能会导致一些用户的支付流程失败，甚至出现丢单。例如用户在购买虚拟商品时已经支付成功但系统并没有下发权益。
22.现有技术中使用对网络接口进行监控的方式，这种方案只是对网络接口进行监控，对客户端支付行为并不能记录，并且也不能获悉iap支付的错误。因此，现有技术方案监控范围比较局限，只能统计接口数据的请求和返回，但对于客户端本地行为，以及业务逻辑的执行并不知道。因此，本技术实施例提供的方案中，提出一种监控支付流程的方法，将支付过程中的各个节点定义到支付枚举中，当支付流程中的各个节点的支付发生问题后都可以进行监控，进一步加强了监控流程的完整性，实现支付过程的全链路监控。并且本技术对系统iap支付回调、接口请求过程、界面交互、前后台切换、支付成功以及失败，支付所涉及的全部流程进行记录，不仅接口可监控，用户端的支付行为也可监控，相较之下监控链路更为完整。
23.请参阅图1，本技术该实施例提供了一种监控支付流程的方法包括以下步骤：s101：将支付过程中的n个节点定义到支付枚举中，支付枚举包括：需要进行支付监控的支付过程范围，n大于或等于1；支付枚举也可以简称为枚举。枚举可以用来定义带名字的常量，一个枚举也可以相当于一个事件（event）。n表示支付节点的个数，而支付过程中会产生至少一个的节点，首先需要用户有支付发起动作才会进行后续节点的进行，因此n大于或等于1，例如支付过程
中所产生的节点，其中，一种节点可以为用户发起支付等等。具体的，枚举的数据结构可以有先后顺序。例如也可以通过支付监控类svpurchase monitor实现，并将其定义为单例。需要说明的是，单例指的是一种软件开发模式，表示在程序运行过程中，只有一个实例存在。
24.以支付监控类svpurchase monitor实现为例，可以定义事件枚举svpurchase event，类型是整型。其中，整型指的是一种数据类型，也可以理解为除小数和负数之外的数字。将支付中的所有节点，都定义为对应的枚举值，总共近七十个枚举值，每个枚举值都是一个事件（event）。
25.s102：校验用户发起支付的当前节点是否位于支付过程范围；支付过程范围指的是整个支付业务链路。例如，在整个支付业务链路中，每一个节点都是一个事件。当用户执行支付操作时，以一个成功的支付流程为例，整个业务链路大概可以划分为点击支付按钮、点击支付按钮、对支付环境进行检查、创建商品订单、调用支付处理器api、创建skproduct 、等待用户确认、用户确认支付、系统回调成功、获取收据、验证收据、刷新用户权益。而在这个流程之外，则会被判定异常的场景。例如创建订单失败、创建skproduct失败等。
26.具体地，skproduct指的是ios系统用来调起支付的对象。收据指的是苹果服务器返回给客户端的一个字符串，其中收据的作用可以是用于和ios系统的服务器验证交易的合法性。
27.需要说明的是，支付过程范围可以是指校验的当前节点是否在队列中，例如记录到回调失败的发生，这个时间并不在上述定义的节点中，则不位于支付过程范围。
28.s103：若该当前节点位于支付过程范围，则确定该当前节点为正确节点；正确节点指的是在支付过程范围内的节点，例如用户确认支付、创建商品订单等等，也可以理解为支付过程正常进行。
29.s104：创建包含正确节点的第一队列。
30.由于支付过程中的节点很多，因此对正确节点以及异常节点进行区分，便于后续的调用。
31.需要说明的是，第一队列指的是正常流程的队列。创建正常流程为第一队列，可以用于监控支付流程是否出现异常。
32.图1所示的流程，引入了支付枚举并将正常的支付流程创建为第一队列，将支付过程中的各个节点定义到支付枚举中，当支付流程中的各个节点的支付发生问题后都可以进行监控，进一步加强了监控流程的完整性。
33.请参阅图2，本技术还提供了另外一种监控支付流程的方法，由于现有技术未将节点的信息进行记录，因此无法将节点与订单进行关联，无法获知用户购买的商品的具体信息，以及系统支付api返回的收据内容，从而导致若出现支付失败的情况需要对出现问题的数据进行回捞，由此本技术该实施例可以在图1的基础上进一步增加判断过程，具体包括如下步骤：s201：在支付过程范围中，将进行到当前节点所产生的支付信息添加至第二队列中；具体地，支付信息可以包括订单号、交易标识id、交易时间；第二队列指的是支付过程中产生的流程表，也可以用于记录支付过程中异常节点所产生的错误码以及错误信
息。
34.s202：若当前节点未位于支付过程范围，则确定当前节点为异常节点；异常节点可以是例如创建订单失败、创建skproduct失败等事件。当用户执行支付操作时，以一个成功的支付流程为例，整个业务链路大概可以划分为点击支付按钮、点击支付按钮、对支付环境进行检查、创建商品订单、调用支付处理器api、创建skproduct 、等待用户确认、用户确认支付、系统回调成功、获取收据、验证收据、刷新用户权益。而在这个流程之外，则会被判定异常的场景中产生的节点相当于异常的节点。
35.s203：将异常节点对应的错误码以及错误信息添加至第二队列中。
36.需要说明的是，错误码和错误信息需要记录是为了后续进行数据统计。记录错误码的意义在于，通过错误码进行数据统计和归类。例如40163表示错误类型a，93007表示错误类型b，每种错误发生的次数等信息需要基于错误码进行归类。
37.而记录错误信息的意义在于，当进行分析时，错误信息都是文本的方式呈现的，例如“用户的token失效，需要重新登录后购买”，错误信息的展示较为直观。
38.在一些实现方式中，s201可以周期性执行。
39.其中s201和s202的执行顺序可以先后进行，也可以同时进行。
40.在图2所示的本技术实施例中，为了避免还需要回捞操作，提出了将数据实时上报到公司的统计后台服务器，减少数据量，只上报关键信息，以此实现数据后台服务器可以承载上报。相较于现有技术而言本技术该实施例采用的是实时上报的，减少了需要回捞的操作。其中回捞指的是服务端给特定设备通过长连接下发一个指令，接收到指令后通过另一个网络请求将数据发送到服务端。
41.如图3所示，本技术实施例还提供了另一种监控支付流程的方法，由于平时经常对支付进行测试，为了避免测试环境对线上数据的影响，测试环境是不对监控数据进行上报的，而是简单的输出到日志中，则会导致后续需要分析数据还要进行数据重调的步骤。因此可以在图2所进行的流程之后增加判断过程，判断是否需要上报，将需要上报的数据在本地进行了分析并处理，上报后即可在统计后台服务器查询到上报信息，该实施例具体包括：s203：将异常节点对应的错误码以及错误信息添加至第二队列中。
42.当进入到异常的节点时，支付监控可以进行一些判定行为，该判断行为可以是例如判断是否需要上报到后台服务器。如果需要上报，会对记录的节点进行拼接，并且带着上述信息一并上报到统计后台服务器，从而知道当前用户的支付流程以及具体情况。
43.具体地，拼接可以是拼接业务链路，拼接的目的是还原用户当时支付的流程，包括接口请求过程、iap支付回调、前后台切换、弹窗交互等场景。其中，业务链路由一个业务链路由一个purchase route字符串来承载，purchase route的链路拼接的规则是通过事件从事件名表中获取事件映射，将这个描述拼接在purchase route中，并且每次上报都会重复这个流程。purchase route的拼接有先后顺序，根据事件上报的顺序，将事件对应的描述从前到后添加到purchase route中，从而构成一个事件链路。
44.s301：判断错误码以及错误信息是否需要上报至后台服务器；例如可以判断节点是否位于第一队列中；若节点未位于第一队列中，则错误码以及错误信息需要上报至后台服务器。
45.具体地是否进行上报，主要通过check event方法来实现，方法内部会进行一些逻
辑判断。如果需要上报，会调用report record方法进行上报。check event方法的核心逻辑如下。也可以判断传入的事件（event）是否在event list中，也就是正常流程的队列，相当于第一队列中。如果不在则调用report record方法。但不清除record list数组，因为失败后还会有重试逻辑，重试后成功后才算是一个完整链路。其中，record list指的是支付流程表，相当于第二队列。
46.具体地，判断传入的事件（event）是否点击开始支付按钮，点击支付按钮表示一个新的支付链路的开始。如果是的话，先调用report record方法上报，并清除record list队列中的记录，随后再记录新的事件（event）。
47.也可以判断传入的事件（event）是否在event list中出现多次，如果在正确的流程中出现多次，也可能属于异常情况。例如收到多次系统回调，这样可能是系统的错误，需要上报到后台服务器。
48.需要说明的是，report record方法负责上报监控数据到后台服务器，主要是业务链路字符串的拼接，以及其他上报参数的处理。
49.s302：若错误码以及错误信息需要上报至后台服务器，则对位于第二队列中的的当前节点、错误码以及错误信息进行拼接，生成上报信息并将上报信息上报至后台服务器。
50.需要说明的是，拼接指的是拼接业务链路，例如事件链路拼接后的purchase route字符串格式如下：(点击支付按钮)
ꢀ‑
》 (对支付环境进行check)
ꢀ‑
》 (创建商品订单)
ꢀ‑
》 (调用支付api)
ꢀ‑
》 (创建skproduct)
ꢀ‑
》 (支付中，用户确认支付)
ꢀ‑
》 (系统回调成功)
ꢀ‑
》 (获取收据)
ꢀ‑
》 (验证收据)
ꢀ‑
》 (刷新用户权益)。
51.其中，skproduct指的是ios系统用来调起支付的对象，收据指的是苹果服务器返回给客户端的一个字符串。
52.s303：对上报信息进行统计分析。
53.具体地，统计分析可以采用根据错误类型对上报信息进行归类，错误类型与错误码以及错误信息具有映射关系。
54.在图3所示的本技术实施例中，为了防止不对监控数据进行上报的，而是简单的输出到日志中。提出了将数据进行上报，以此方式，提高了后续获取数据的便利性。
55.参见图4，在该具体应用场景中，使用代码来实现支付流程的监控，通过一个支付监控类svpurchase monitor实现，并将其定义为单例，对整个支付流程进行监控。该实际应用场景中具体通过如下步骤实现监控支付流程：s401：定义事件枚举svpurchase event，类型是整型。
56.将支付中涉及到的节点定义为对应的枚举值，总共近七十个枚举值，每个枚举值都是一个事件（event）。
57.s402：在业务代码中涉及支付的位置，添加svpmonitor record方法调用。
58.将当前位置对应的事件（event）传入，当触发这个调用时，事件（event）就会被记录到record list队列中。
59.s403：在svpurchase monitor中定义event list队列，通过数组实现，在启动时会进行实例化。
60.event list队列可以理解为前述中的第一队列，其中event list队列中定义正常
流程中包含的事件（event），并且事件（event）之间有先后顺序。这里的事件（event）指的是每个枚举值。
61.s404：在svpurchase monitor中定义event desmap表，通过字典实现，在启动时会进行注册。包含所有事件（event），用事件枚举作为key，事件描述作为value。
62.需要说明的是，event desmap指的是事件描述表，其意义在于，例如定义的枚举为svp event create product success，以此种方式进行定义不利于后续的分析，并且如果用枚举拼接起来构成支付行为链路并上报，不易于分析人员的理解。因此，通过event desmap对event和事件描述进行映射，例如svp event create product success的事件描述是“创建skproduct成功”，这样事件链路拼接之后便于后续对异常情况进行分析。
63.s405：在svpurchase monitor中定义event name map表，通过字典实现，在启动时会进行注册。包含所有事件（event），用事件枚举作为key，事件名作为value。
64.需要说明的是，event name map指的是事件名表，其意义在于枚举的数据结构是有先后顺序的，例如同一个位置但有不同的事件（event）定义，但上报的整型都是一致的，则会导致版本1和版本2的同一个位置，枚举定义不同，影响数据分析准确性。而通过event name map对event和事件名进行一个映射，上报的时候直接上报事件名，以svp event purchase failure为例，上报的就是“svp event purchase failure”字符串，这样就不受限于枚举定义的顺序了。
65.s406：定义record list队列，通过数组实现，用来存放支付过程中的event。
66.record list队列指的是前述第二队列，存放的是支付过程中产生的事件。在启动时会创建，创建是为空数组，用来存放支付过程中记录的事件（event）。
67.在图4所示的本技术实施例中，将正确的支付业务链路，通过event list限定在合理范围内的相关设计，其中event list指的是正常流程的队列。并且通过svpurchase event将网络请求、界面交互、支付api、异常场景的各个场景进行定义，并且通过svp monitor record方法在event对应的地方进行代码调用，配合event desmap事件描述映射，通过purchase route字符串对事件链路进行拼接的设计，以此方式，实现对这些场景进行监控的全覆盖，相较于现有技术的技术方案而言便于后续的分析。
68.如图5所示，本技术实施例还提供了一种监控支付流程的装置，该装置具体包括：枚举模块501，用于将支付过程中的n个节点定义到支付枚举中，支付枚举包括：需要进行支付监控的支付过程范围，n大于或等于1；校验模块502，用于校验用户发起支付的当前节点是否位于支付过程范围；若当前节点位于支付过程范围，则确定当前节点为正确节点；创建模块503，用于创建包含正确节点的第一队列。
69.在本技术的另一些实施例中，该装置还可以包括：添加模块，用于在支付过程范围中，将进行到当前节点所产生的支付信息添加至第二队列中，支付信息包括订单号、交易标识id、交易时间；在一些具体实现方式中，该添加模块还可以用于当出现异常节点，将异常节点对应的错误码以及错误信息添加至第二队列中。
70.判断模块，用于判断错误码以及错误信息是否需要上报至后台服务器；若错误码以及错误信息需要上报至后台服务器，则对位于第二队列中的当前节点、错误码以及错误
信息进行拼接，生成上报信息并将上报信息上报至后台服务器；在一些具体实现方式中，该判断模块还可以用于判断当前节点是否位于第一队列中；若节点未位于第一队列中，则错误码以及错误信息需要上报至后台；分析模块，用于根据错误类型对上报信息进行归类，错误类型与错误码以及错误信息具有映射关系。
71.可以理解的是，本实施例示意的结构并不构成对该装置的具体限定。在另一些实施例中，该装置可以包括比图示更多或更少的部件，或者组合另一些部件，或者拆分另一些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
72.如图6所示，本技术实施例还提供了一种计算机设备，包括：存储器601、处理器602；其中，存储器601用于存储程序；处理器602用于执行存储器中的程序，以实现上述如图1至图4中描述的一种监控支付流程的方法。
73.最后，还需要说明的是，在本技术实施例中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
74.对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。