WO2021056571A1 - 支付处理方法、装置、电子设备以及存储介质 - Google Patents
支付处理方法、装置、电子设备以及存储介质 Download PDFInfo
- Publication number
- WO2021056571A1 WO2021056571A1 PCT/CN2019/109215 CN2019109215W WO2021056571A1 WO 2021056571 A1 WO2021056571 A1 WO 2021056571A1 CN 2019109215 W CN2019109215 W CN 2019109215W WO 2021056571 A1 WO2021056571 A1 WO 2021056571A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- application
- payment
- electronic device
- target application
- attribute information
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
Definitions
- This application relates to the field of payment technology, and more specifically, to a payment processing method, device, electronic device, and storage medium.
- this application proposes a payment processing method, device, electronic equipment, and storage medium to solve the above-mentioned problems.
- an embodiment of the present application provides a payment processing method, which is applied to an electronic device, and the method includes: when the electronic device enters a payment mode in the process of running a target application, acquiring the called payment application Attribute information; determine whether the payment application is legal based on the attribute information; when the payment application is illegal, generate a pending event; send the pending event to the server, and use the pending event To instruct the server to process the target application.
- an embodiment of the present application provides a payment processing method applied to a server.
- the method includes: the server receives a pending event sent by an electronic device, and the pending event is a target operation of the electronic device.
- the application enters the payment mode in the process of the application, it is generated when the called payment application is illegal; the target application is processed in response to the pending event.
- an embodiment of the present application provides a payment processing method, which is applied to a payment processing system, the payment processing system includes a connected electronic device and a server, and the method includes: the electronic device is running a target application When entering the payment mode in the process, obtain the attribute information of the called payment application; the electronic device judges whether the payment application is legal based on the attribute information; when the payment application is illegal, the electronic device A pending event is generated; the electronic device sends the pending event to a server; the server responds to the pending event to process the target application.
- an embodiment of the present application provides a payment processing device applied to an electronic device.
- the device includes: an attribute information acquisition module, which is used when the electronic device enters the payment mode during the process of running the target application program, Obtain the attribute information of the called payment application; the attribute information judgment module is used for judging whether the payment application is legal based on the attribute information; the pending event generation module is used for when the payment application is illegal, A pending event is generated; a pending event sending module is used to send the pending event to a server, and the pending event is used to instruct the server to process the target application.
- an embodiment of the present application provides a payment processing device applied to a server, and the device includes: a pending event receiving module for the server to receive a pending event sent by an electronic device, the pending event When the electronic device enters the payment mode in the process of running the target application, it is generated when the called payment application is illegal; the pending event response module is used to respond to the pending event on the target application deal with.
- an embodiment of the present application provides an electronic device, including a memory and a processor, the memory is coupled to the processor, and the memory stores instructions that are executed when the instructions are executed by the processor.
- the processor executes the above method.
- an embodiment of the present application provides a computer-readable storage medium, the computer-readable storage medium stores program code, and the program code can be invoked by a processor to execute the foregoing method.
- the payment processing method, device, electronic device, and storage medium provided by the embodiments of the present application.
- the electronic device enters the payment mode while running the target application, it obtains the attribute information of the called payment application, and determines the payment based on the attribute information.
- a pending event is generated and sent to the server.
- the pending event is used to instruct the server to process the target application, so as to pass the process of running the target application Enter the payment mode and process the target application when it detects that the called payment application is illegal, so as to accurately and timely detect illegal payment behaviors, and fully protect the legitimate interests of users and the platform.
- FIG. 1 shows a schematic diagram of an application scenario of a payment processing method provided by an embodiment of the present application
- Figure 2 shows a sequence diagram of a payment processing method provided by an embodiment of the present application
- FIG. 3 shows a schematic flowchart of a payment processing method provided by another embodiment of the present application.
- FIG. 4 shows a schematic flowchart of a payment processing method provided by another embodiment of the present application.
- FIG. 5 shows a schematic flowchart of step S310 of the payment processing method shown in FIG. 4 of the present application
- FIG. 6 shows a schematic flowchart of step S312 of the payment processing method shown in FIG. 5 of the present application
- FIG. 7 shows a schematic flowchart of an embodiment of step S340 of the payment processing method shown in FIG. 4 of the present application.
- FIG. 8 shows a schematic flowchart of another embodiment of step S340 of the payment processing method shown in FIG. 4 of the present application.
- FIG. 9 shows a schematic flowchart of a payment processing method provided by another embodiment of the present application.
- FIG. 10 shows a schematic flowchart of a payment processing method provided by yet another embodiment of the present application.
- Fig. 11 shows a block diagram of a payment processing device provided by an embodiment of the present application.
- FIG. 12 shows a block diagram of a payment processing device according to another embodiment of the present application.
- FIG. 13 shows a block diagram of an electronic device used to execute the payment processing method according to the embodiment of the present application
- FIG. 14 shows a storage unit for storing or carrying program code for implementing the payment processing method according to the embodiment of the present application according to an embodiment of the present application.
- Mobile payment also known as mobile payment (Mobile Payment)
- Mobile Payment is a method that allows users to use electronic devices (such as mobile phones, tablet computers, etc.) to pay for the goods or services they consume. It is a brand-new business that combines electronic money, identity verification, mobile communications and electronic equipment, allowing users to enjoy a variety of services anytime, anywhere.
- manufacturers corresponding to electronic devices have begun to develop payment applications that support electronic devices for mobile payments, and set that the jointly operated application installed on the electronic device needs to call the electronic device when calling payment applications The corresponding payment application developed by the manufacturer. However, when some jointly operated applications call payment applications, they will call more third-party payment applications (payment applications developed by the corresponding manufacturers of non-electronic devices), that is, the application performs "cut payment". Thus seriously harming the interests of the electronic equipment platform.
- the inventor has discovered through long-term research and proposed the payment processing method, device, electronic device, and storage medium provided by the embodiments of the present application.
- the target application is processed to accurately and timely detect illegal payment behaviors, and fully protect the legitimate interests of users and the platform.
- the specific payment processing method is described in detail in the subsequent embodiments.
- FIG. 1 shows a schematic diagram of a payment processing system 10 provided in the implementation of this application.
- the payment processing system 10 includes an electronic device 100 and a server 200, where the electronic device 100 and the server 200 are communicatively connected to implement data interaction between the electronic device 100 and the server 200.
- the electronic device 100 can send pending events to the server 200 and the like.
- the electronic device 100 and the server 200 may be respectively connected to a base station, so as to realize data interaction between the electronic device 100 and the server 200 through the base station.
- the electronic device 100 may include a smart phone, a tablet computer, a wearable electronic device, and the like.
- the server 200 may include a traditional server, a cloud server, etc., which is not limited herein.
- the payment processing system 10 also includes other more electronic devices, for example, it may also include a first test device 300, a second test device 400, and a third test device 500.
- the server 200 communicates with the first test device 300, the second test device 400, and the third test device 500 respectively to realize data interaction with the first test device 300, the second test device 400, and the third test device 500.
- a server 200 can send data information in the event to be processed to the first test device 300, the second test device 400, the third test device 500, etc., which is not limited herein.
- FIG. 2 shows a sequence diagram of a payment processing method provided by an embodiment of the present application.
- the flow shown in Figure 2 will be described in detail below.
- the payment processing method is applied to a payment processing system.
- the payment processing system includes an electronic device and a server.
- the electronic device is connected to the server.
- the payment processing method may specifically include The following steps:
- Step S110 When the electronic device enters the payment mode in the process of running the target application, obtain the attribute information of the called payment application.
- the electronic device can run applications in the foreground, run applications in the background, or switch between the foreground and the background to run applications, which is not limited here.
- an application running in the foreground refers to an application that can usually interact with the user and can run in the foreground, and it will be suspended when it is not visible (such as a game);
- an application running in the background refers to Interaction with the user is very limited. Except for the configuration period, other times of its lifetime are hidden (for example: SMS automatic reply program and alarm clock program); applications that switch between the foreground and the background of the electronic device mean that they can be in the foreground and Freely switch applications between the background. Understandably, when the application program is not killed (kill), it means that the application program is running on the electronic device.
- the target application is an application running in the foreground of the electronic device.
- a payment behavior may be involved, and the target application program will call the payment application program to enter the payment mode in response to the payment behavior.
- the target application is a game application
- the user may trigger scenarios that require payment such as "equipment purchase” and "skin purchase” when the electronic device is running the game application, and the target application can respond The user's trigger calls the payment application to enter the payment mode.
- the target application is a shopping application
- the user may trigger scenarios that require payment such as "purchase” and "payment”
- the target application can respond to the user Trigger calling the payment application to enter the payment mode.
- the target application can also enter the payment mode in other scenarios, which will not be repeated here.
- the electronic device when the electronic device enters the payment mode during the process of running the target application, the electronic device can obtain the payment application called by the target application, and obtain the attribute information of the payment application.
- the attribute information of the target application includes but is not limited to: the package name of the target application, the software development kit SDK plug-in of the target application, the online time of the target application, the number of customers of the target application, and the conversion of the target application Rates, etc., are not limited here.
- the electronic device can obtain the attribute information of the payment application from the local or the server. Taking the electronic device from the local as an example, the local of the electronic device can record the attribute information of all installed applications. Therefore, the electronic When determining the called payment application, the device can read the attribute information of the payment application locally.
- Step S120 The electronic device judges whether the payment application is legal based on the attribute information.
- the electronic device may preset a legal condition of the attribute information, where the legal condition is used to characterize that the payment application is an official payment application. Therefore, after obtaining the attribute information of the called payment application, the attribute information of the payment application can be compared with the legal conditions to determine whether the attribute information of the payment application meets the legal conditions.
- the attribute information of the payment application satisfies the legal conditions
- the target application does not have "cut payment” and the target can be determined
- the payment application called by the application is legal; when the attribute information of the payment application does not meet the legal conditions, it means that the payment application is not an official payment application set by the electronic device, but a third-party payment application, and the target application occurs " Cut payment", it can be determined that the payment application called by the target application is illegal.
- Step S130 When the payment application is illegal, the electronic device generates a pending event.
- the electronic device may generate a pending event for the target application, where the pending event may include an event to be punished, an event to be verified, etc. , In order to process the target application, which is not limited here.
- the electronic device can continue to perform the payment operation to reduce the impact on the user's payment and improve the user experience.
- the electronic device can continue to perform the payment operation and output prompt information, which is used to remind the user of possible problems with the target application, so that the user can help eliminate the entire The environment of the industry.
- the electronic device can terminate the payment operation and output a prompt message to directly avoid damage to the platform's interests.
- the electronic device may also include other more methods for payment operations, which will not be repeated here.
- Step S140 The electronic device sends the to-be-processed event to the server.
- the electronic device may send the event to be processed to the server via a data network or a wireless network, which is not limited here.
- Step S150 The server processes the target application in response to the event to be processed.
- the server after the server receives the pending event sent by the electronic device, it can respond to the pending event to process the target application, for example, penalize the target application, and impose punishment on the developer behind the target application. Penalties, etc.
- the server after the server receives the pending event sent by the electronic device, it can reproduce the payment process of the target application and obtain evidence, so as to reproduce the target application's data through the data when the "cut payment" actually occurs. Illegal behavior in order to process the target application.
- An embodiment of the present application provides a payment processing method.
- the electronic device enters the payment mode while running the target application, it obtains the attribute information of the called payment application, and determines whether the payment application is legal based on the attribute information.
- a pending event is generated, and the pending event is sent to the server.
- the server responds to the pending event to process the target application, so that the electronic device enters the payment mode during the process of running the target application and detects
- the called payment application is illegal, the target application is processed through the server to detect illegal payment behaviors accurately and timely, and fully protect the legitimate interests of users and the platform.
- FIG. 3 shows a schematic flowchart of a payment processing method provided by another embodiment of the present application.
- the method is applied to the payment processing device 600 shown in FIG. 11 and the electronic device 100 (as shown in FIG. 1) equipped with the payment processing device 600.
- the following will elaborate on the process shown in FIG. 3, and the payment processing method may specifically include the following steps:
- Step S210 When the electronic device enters the payment mode in the process of running the target application, obtain the attribute information of the called payment application.
- Step S220 Determine whether the payment application is legal based on the attribute information.
- Step S230 When the payment application is illegal, a pending event is generated.
- Step S240 Send the pending event to the server, where the pending event is used to instruct the server to process the target application.
- step S210 to step S240 please refer to step S110 to step S150, which will not be repeated here.
- the electronic device when the electronic device enters the payment mode while running the target application, it obtains the attribute information of the called payment application, and determines whether the payment application is legal based on the attribute information.
- a pending event is generated, and the pending event is sent to the server.
- the pending event is used to instruct the server to process the target application, thereby entering the payment mode while running the target application, and
- the target application is processed, so as to accurately and timely detect illegal payment behaviors, and fully protect the legitimate interests of users and the platform.
- FIG. 4 shows a schematic flowchart of a payment processing method provided by another embodiment of the present application. This method is applied to electronic equipment. The following will elaborate on the process shown in FIG. 4 in detail.
- the payment processing method may specifically include the following steps:
- Step S310 When the electronic device runs the application, it determines whether the application satisfies a specified condition.
- the electronic device presets and stores a designated condition, and the designated condition is used as a basis for judging the application program running by the electronic device, and the designated condition is used to characterize that the target application condition is met. Therefore, in this embodiment, when the electronic device is running the application, the application running on the electronic device can be compared with the specified condition to determine whether the application meets the specified condition, where the judgment result indicates that the application satisfies the specified condition. When the conditions are met, the application can be determined as the target application, and when the judgment result indicates that the application does not meet the specified conditions, the application can be determined as a non-target application.
- FIG. 5 shows a schematic flowchart of step S310 of the payment processing method shown in FIG. 4 in an embodiment of the present application.
- the process shown in FIG. 5 will be described in detail below, and the method may specifically include the following steps:
- Step S311 When the electronic device runs the application, it determines whether the application is a jointly operated application.
- the specified condition may include a jointly operated application, that is, when the application belongs to a jointly operated application, it can be determined that the application meets the specified condition, and when the application is not a jointly operated application, It can be determined that the application does not meet the specified conditions.
- the jointly operated application program refers to the application program jointly cooperated by the electronic equipment manufacturer and the application program developer.
- the application running on the electronic device can be compared with all jointly operated applications to determine whether the application belongs to a jointly operated application.
- the characterization application belongs to a joint operation application it can be determined that the application meets the specified conditions and the application is determined as the target application.
- the judgment result indicates that the application does not belong to the joint operation application it can be determined that the application does not meet the specified requirements.
- the application is determined as a non-target application.
- the electronic device can create a list of jointly operated applications in advance.
- the list is used to add and record all the jointly operated applications. Therefore, after the electronic device obtains the running applications, it can find out whether it is in the list.
- the method of recording the application program consistent with the running application program is used to determine whether the running application program belongs to the jointly operated application program.
- the electronic device can add a mark to each jointly operated application. Therefore, after the electronic device obtains the running application, it can determine the running application by judging whether the running application includes the mark. Whether the program is a jointly operated application.
- the electronic device may also include more ways to determine whether the running application is a jointly operated application, which will not be repeated here.
- Step S312 When the application belongs to a jointly operated application, determine the application as the target application.
- FIG. 6 shows a schematic flowchart of step S312 of the payment processing method shown in FIG. 5 in an embodiment of the present application.
- the process shown in FIG. 5 will be described in detail below, and the method may specifically include the following steps:
- Step S3121 When the application belongs to the jointly operated application, determine whether the application is a game application.
- the application when it is determined that the application is a jointly operated application, it can be determined whether the application is a game application, and when the determination result indicates that the application is a game application, the application can be The program is determined to be a target application, and when the judgment result indicates that the application is not a game application, the application can be determined as a non-target application.
- the type of the application can be obtained, and the type of the application can be compared with the type of the game application to determine whether the application is a game application. It can be understood that when the application When the type of the application is consistent with the type of the game application, it can be determined that the application is a game application. When the type of the application is inconsistent with the type of the game application, it can be determined that the application is a non-game application.
- Step S3122 When the application is a game application, determine the application as the target application.
- Step S320 When the application program satisfies the specified condition, the application program is determined as the target application program.
- Step S330 When the electronic device enters the payment mode in the process of running the target application, obtain the attribute information of the called payment application.
- step S330 For the specific description of step S330, please refer to step S110, which will not be repeated here.
- Step S340 Determine whether the payment application is an official payment application based on the attribute information, and the official payment application is a payment application corresponding to the manufacturer to which the electronic device belongs.
- the legal condition of the payment application is an official payment application, where the official payment application is a payment application corresponding to the manufacturer to which the electronic device belongs. Therefore, in this embodiment, after the attribute information of the payment application is obtained, it can be determined based on the attribute information whether the payment application is an official payment application, and when the payment application is an official payment application, it can be determined that the payment application is an official payment application. There is no "cut payment" in the target application, and the payment application is legal. When the payment application is not an official payment application, it can be determined that the target application has "cut payment” and the payment application is illegal.
- FIG. 7 shows a schematic flowchart of an embodiment of step S340 of the payment processing method shown in FIG. 4 in an embodiment of the present application.
- the process shown in FIG. 7 will be described in detail below.
- the electronic device pre-stores official attribute information corresponding to the official payment application, and the payment processing method may specifically include the following steps:
- Step S341A Obtain the official attribute information, and determine whether the attribute information is consistent with the official attribute information.
- the electronic device pre-stores official attribute information corresponding to the official payment application. Therefore, in this embodiment, after obtaining the attribute information of the payment application and the official attribute information, the attribute information of the payment application can be compared with the official attribute information to determine whether the attribute information of the payment application is the same as the official attribute information. Consistent. When the attribute information of the payment application is consistent with the official attribute information, it can be determined that the payment application is an official payment application. When the attribute information of the payment application is inconsistent with the official attribute information, it can be determined that the payment application is not an official payment application. program.
- Step S342A When the attribute information is inconsistent with the official attribute information, it is determined that the payment application is not the official payment application.
- FIG. 8 shows a schematic flowchart of another embodiment of step S340 of the payment processing method shown in FIG. 4 in an embodiment of the present application.
- the process shown in FIG. 8 will be described in detail below.
- the attribute information includes a software development kit SDK plug-in, and the payment processing method may specifically include the following steps:
- Step S341B Determine whether the SDK plug-in is an official SDK plug-in, and the official SDK plug-in is an SDK plug-in corresponding to the manufacturer to which the electronic device belongs.
- the attribute information includes an SDK plug-in
- the electronic device may pre-store an official SDK plug-in
- the official SDK plug-in is an SDK plug-in corresponding to the manufacturer to which the electronic device belongs. Therefore, in this embodiment, after obtaining the SDK plug-in of the payment application and the official SDK plug-in, the SDK plug-in of the payment application can be compared with the official SDK plug-in to determine whether the SDK plug-in of the payment application is the same as the official SDK plug-in. Consistent. When the SDK plug-in of the payment application is consistent with the official SDK plug-in, it can be determined that the payment application is an official payment application. When the SDK plug-in of the payment application is inconsistent with the official SDK plug-in, it can be determined that the payment application is not an official payment application. program.
- Step S342B When the SDK plug-in is not the official SDK plug-in, it is determined that the payment application is not the official payment application.
- Step S350 When the payment application is not the official payment application, it is determined that the payment application is illegal.
- Step S360 When the payment application is illegal, a pending event is generated.
- Step S370 Send the to-be-processed event to a server, where the to-be-processed event is used to instruct the server to process the target application.
- step S360 to step S370 please refer to step S130 to step S150, which will not be repeated here.
- an electronic device when an electronic device runs an application, it determines whether the application meets a specified condition, and when the application meets the specified condition, the application is determined as the target application.
- the electronic device enters the payment mode in the process of running the target application, it obtains the attribute information of the called payment application, and determines whether the payment application is an official payment application based on the attribute information, and the official payment application belongs to the electronic device
- the payment application is determined to be illegal.
- a pending event is generated and the pending event is sent to the server.
- the pending event The event is used to instruct the server to process the target application.
- the present embodiment also judges the application program running on the electronic device to determine the target application program through specified conditions, so as to improve the accuracy of the target application program processing.
- this embodiment also determines whether the payment application is legal by determining whether the payment application is an official payment application, so as to improve the accuracy of the judgment of the payment application.
- FIG. 9 shows a schematic flowchart of a payment processing method provided by another embodiment of the present application.
- the method is applied to the payment processing device 700 shown in FIG. 12 and the server 200 (as shown in FIG. 1) configured with the payment processing device 700.
- the process shown in Fig. 9 will be described in detail below, and the payment processing method may specifically include the following steps:
- Step S410 The server receives a pending event sent by the electronic device, and the pending event is generated when the called payment application is illegal when the electronic device enters the payment mode while the target application is running.
- Step S420 Process the target application in response to the to-be-processed event.
- step S410-step S420 please refer to step S110-step S150, which will not be repeated here.
- a server receives a pending event sent by an electronic device.
- the pending event is an illegal payment application when the electronic device enters the payment mode during the process of running the target application.
- the target application is processed in response to the pending event, so that the payment mode is entered during the process of running the target application, and the target application is processed when it is detected that the called payment application is illegal, so as to be accurate and
- the timely detection of illegal payment behaviors fully protects the legitimate interests of users and the platform.
- FIG. 10 shows a schematic flowchart of a payment processing method provided by yet another embodiment of the present application. This method is applied to a server. The following will describe the process shown in FIG. 10 in detail.
- the to-be-processed event includes the basic information of the target application, the first identification information of the electronic device, and the information of the electronic device.
- the second identification information, the payment processing method may specifically include the following steps:
- Step S510 The server receives a pending event sent by the electronic device, and the pending event is generated when the called payment application is illegal when the electronic device enters the payment mode while the target application is running.
- step S510 please refer to step S110 to step S140, which will not be repeated here.
- Step S520 Send the basic information to the first test device, where the basic information is used to instruct the first test device to install the target application based on the basic information in order to pay for the target application Perform recurrence, and obtain evidence when the payment process of the target application program successfully reproduces.
- the event to be processed includes basic information of the target application. Accordingly, the server can respond to the event to be processed and process the target application based on the basic information.
- the basic information of the target application can include at least the package name of the target application, and the server can find the corresponding target application based on the package name of the target application to process the target application.
- the server after the server obtains the basic information of the target application, it can send the basic information of the target application to the first test device of the communication connection, and accordingly, the first test device can install based on the received basic information.
- the target application program reproduces the payment process of the target application program, and collects evidence when the payment process of the target application program is successfully reproduced, so as to provide evidence of penalizing the target application program.
- the first test device can install the target application based on the received package name to reproduce the payment process of the target application, and reproduce the payment process of the target application Obtain evidence when successful.
- the first test device can obtain evidence through screen recording, which is not limited here.
- Step S530 When the payment process of the target application fails to reproduce, determine the second test device corresponding to the first identification information.
- the developer of the target application may not set "cut payment” for all electronic devices, but for some models of electronic devices. Therefore, Only the basic information of the target application is used to reproduce the payment process of the target application, which may not be able to reproduce the "cut payment” behavior, that is, the payment process of the target application fails to reproduce.
- the event to be processed further includes the first identification information of the electronic device. Therefore, when the payment process of the target application fails to reproduce, it means that the payment process of the target application cannot be reproduced only through basic information, and the corresponding second test device can be determined based on the first identification information to pass the first identification information. Second, the test equipment solves the problem that the "cut payment" of the target application may only target some models of electronic equipment. Specifically, the first identification information may include at least the model.
- an electronic device consistent with the model of the electronic device can be determined based on the model as the second test device, and By using an electronic device with the same model as the electronic device where the "cut payment" occurs as the second test device to reproduce the payment process, it solves the problem that the "cut payment" of the target application may only target some types of electronic equipment.
- Step S540 Send the basic information to the second test device, where the basic information is used to instruct the second test device to install the target application based on the basic information, so as to update the target application
- the payment process is reproduced, and evidence is obtained when the payment process of the target application program is successfully reproduced.
- the server may send the basic information of the target application to the second test device connected to the communication, and accordingly ,
- the second test device can install the target application based on the received basic information to reproduce the payment process of the target application, and obtain evidence when the payment process of the target application is successfully reproduced, so as to provide the target application Evidence that the procedure is penalized.
- the second test device can install the target application based on the received package name to reproduce the payment process of the target application, and reproduce the payment process of the target application Obtain evidence when successful.
- the second test device can obtain evidence through screen recording, which is not limited here.
- Step S550 When the payment process of the target application fails to reproduce, determine the third test device corresponding to the first identification information and the second identification information.
- the developer of the target application may not set “cut payment” for all electronic devices, but for some models of electronic devices.
- the set “cut payment” may not be for all areas, but for more remote areas. Therefore, only using the basic information of the target application and the first identification information of the electronic device to reproduce the payment process of the target application may not be able to reproduce the "cut payment" behavior, that is, the payment process of the target application fails to reproduce .
- the event to be processed further includes the second identification information of the electronic device. Therefore, when the payment process of the target application fails to reproduce, it can be determined based on the first identification information and the second identification information when it is characterized that the payment process of the target application cannot be reproduced only through the basic information and the first identification information.
- the first identification information may include at least the model
- the second identification information may include at least the network protocol IP address. Therefore, when the payment process of the target application fails to reproduce, the identification information may be determined based on the model and IP address.
- the electronic device with the same model and located in the same city is used as the third test device, and the electronic device with the same model and the same city as the electronic device where the "cut payment" occurs is used as the third test device to reproduce the payment process
- the way to solve the problem that the "cut payment" of the target application may only target some models of electronic devices and target relatively remote areas.
- Step S560 Send the basic information to the third test device, where the basic information is used to instruct the third test device to install the target application based on the basic information, so as to control the target application
- the payment process is reproduced, and evidence is obtained when the payment process of the target application program is successfully reproduced.
- the server may send the basic information of the target application to the third communication connection.
- the test device correspondingly, the third test device can install the target application based on the received basic information to reproduce the payment process of the target application, and collect evidence when the payment process of the target application is successfully reproduced, To provide evidence of penalizing the target application.
- the third test device can install the target application based on the received package name to reproduce the payment process of the target application, and reproduce the payment process of the target application Obtain evidence when successful.
- the third test device can obtain evidence through screen recording, which is not limited here.
- the third test device can also be used to reproduce the payment process of the target application at the same time as the electronic device's "cut payment", so as to improve the success rate of the recurrence. No longer.
- the server receives a pending event sent by an electronic device, and the pending event is when the electronic device enters the payment mode while the target application is running, the called payment application does not Generated when it is legal, and send basic information to the first test device.
- the basic information is used to instruct the first test device to install the target application based on the basic information to reproduce the payment process of the target application. Evidence will be collected when the payment process is reproduced successfully.
- the second test device corresponding to the first identification information is determined, and basic information is sent to the second test device.
- the basic information is used to instruct the second test device to install the target based on the basic information
- the application program reproduces the payment process of the target application program, and collects evidence when the payment process of the target application program successfully reproduces.
- the third test device corresponding to the first identification information and the second identification information is determined, and the basic information is sent to the third test device, and the basic information is used to indicate the third test device Install the target application based on the basic information to reproduce the payment process of the target application, and collect evidence when the payment process of the target application is successfully reproduced.
- the payment process fails to be reproduced through basic information, the payment process is reproduced according to the model, IP address, etc. of the electronic device, so as to improve the recurrence of the payment process.
- the success rate to facilitate evidence collection.
- FIG. 11 shows a block diagram of a payment processing device 600 provided by an embodiment of the present application.
- the payment processing apparatus 600 is applied to the above-mentioned electronic equipment. The following will describe the block diagram shown in FIG. 11.
- the payment processing apparatus 600 includes: an attribute information acquisition module 610, an attribute information judgment module 620, a pending event generation module 630, and The pending event sending module 640, where:
- the attribute information obtaining module 610 is configured to obtain the attribute information of the called payment application when the electronic device enters the payment mode during the process of running the target application.
- the attribute information judgment module 620 is configured to judge whether the payment application is legal based on the attribute information. Further, the attribute information judging module 620 includes: an attribute information judging sub-module and a first determining sub-module, wherein:
- the attribute information judging sub-module is configured to judge whether the payment application is an official payment application based on the attribute information, and the official payment application is a payment application corresponding to the manufacturer to which the electronic device belongs. Further, the electronic device pre-stores official attribute information corresponding to the official payment application, and the attribute information judging submodule includes: an attribute information judging unit and a first determining unit, wherein:
- the attribute information judging unit is used to obtain the official attribute information and judge whether the attribute information is consistent with the official attribute information.
- the first determining unit is configured to determine that the payment application is not the official payment application when the attribute information is inconsistent with the official attribute information.
- the attribute information includes a software development kit SDK plug-in
- the attribute information judging sub-module includes: an SDK plug-in judging unit and a second determining unit, wherein:
- the SDK plug-in judging unit is used to judge whether the SDK plug-in is an official SDK plug-in, and the official SDK plug-in is an SDK plug-in corresponding to the manufacturer to which the electronic device belongs.
- the second determining unit is configured to determine that the payment application is not the official payment application when the SDK plug-in is not the official SDK plug-in.
- the first determining submodule is configured to determine that the payment application is illegal when the payment application is not the official payment application.
- the pending event generation module 630 is configured to generate pending events when the payment application is illegal.
- the pending event sending module 640 is configured to send the pending event to a server, and the pending event is used to instruct the server to process the target application.
- the payment processing device 600 further includes: an application program determination sub-module and an application program determination sub-module, wherein:
- the application judging submodule is used for judging whether the application satisfies a specified condition when the electronic device is running the application. Further, the application judging submodule includes: an application judging unit and an application determining unit, wherein:
- the application judging unit is used for judging whether the application is a jointly operated application when the electronic device is running the application.
- the application determining unit is configured to determine the application as the target application when the application belongs to a jointly operated application. Further, the application determining unit includes: an application determining sub-module and an application determining sub-unit, wherein:
- the application judging subunit is used for judging whether the application is a game application when the application belongs to the jointly operated application.
- the application determining submodule is configured to determine the application as the target application when the application is a game application.
- the application determining submodule is configured to determine the application as a target application when the application satisfies the specified condition.
- FIG. 12 shows a module block diagram of a payment processing apparatus 700 according to another embodiment of the present application.
- the payment processing apparatus 700 is applied to the above-mentioned electronic equipment. The following will describe the block diagram shown in FIG. 12.
- the payment processing apparatus 700 includes: a pending event receiving module 710 and a pending event response module 720, wherein:
- the pending event receiving module 710 is used for the server to receive the pending event sent by the electronic device, and the pending event is the payment application called when the electronic device enters the payment mode in the process of running the target application Generated when illegal.
- the to-be-processed event response module 720 is configured to process the target application in response to the to-be-processed event. Further, the to-be-processed event includes basic information of the target application, and the to-be-processed event response module 720 includes: a to-be-processed event response sub-module, wherein:
- the to-be-processed event response sub-module is used to respond to the to-be-processed event and process the target application based on the basic information. Further, the response submodule for the pending event includes: a basic information sending unit, wherein:
- the first basic information sending unit is configured to send the basic information to a first test device, where the basic information is used to instruct the first test device to install the target application based on the basic information, so as to The payment process of the target application is reproduced, and evidence is obtained when the payment process of the target application is successfully reproduced.
- the to-be-processed event further includes first identification information of the electronic device
- the to-be-processed event response sub-module includes: a second test device determining unit and a second basic information sending unit, wherein:
- the second test device determining unit is configured to determine the second test device corresponding to the first identification information when the payment process of the target application fails to recur. Further, the first identification information includes a model, and the second test equipment determining unit includes:
- the second test device determining subunit is configured to determine an electronic device consistent with the model of the electronic device as the second test device based on the model when the payment process of the target application fails to reproduce.
- the second basic information sending unit is configured to send the basic information to the second test device, and the basic information is used to instruct the second test device to install the target application based on the basic information to correct The payment process of the target application is reproduced, and evidence is obtained when the payment process of the target application is successfully reproduced.
- the to-be-processed event further includes second identification information of the electronic device
- the to-be-processed event response sub-module includes: a third test device determining unit and a third basic information sending unit, wherein:
- the third test device determining unit is configured to determine the third test device corresponding to the first identification information and the second identification information when the payment process of the target application fails to recur. Further, the first identification information includes a model, the second identification information includes a network protocol IP address, and the third test device determining unit includes: a third test device determining subunit, wherein:
- the third test device determining subunit is used to determine an electronic device that is consistent with the electronic device model and is located in the same city based on the model and the IP address when the payment process of the target application fails to reproduce As the third test equipment.
- the third basic information sending unit is configured to send the basic information to the third test device, and the basic information is used to instruct the third test device to install the target application based on the basic information to correct The payment process of the target application is reproduced, and evidence is obtained when the payment process of the target application is successfully reproduced.
- the coupling between the modules may be electrical, mechanical or other forms of coupling.
- each functional module in each embodiment of the present application may be integrated into one processing module, or each module may exist alone physically, or two or more modules may be integrated into one module.
- the above-mentioned integrated modules can be implemented in the form of hardware or software function modules.
- FIG. 13 shows a structural block diagram of an electronic device 800 provided by an embodiment of the present application.
- the electronic device 800 may include the electronic device 100 or the server 200, which is not limited here.
- the electronic device 800 may be an electronic device capable of running application programs, such as a smart phone, a tablet computer, or an e-book.
- the electronic device 800 in this application may include one or more of the following components: a processor 810, a memory 820, and one or more application programs, where one or more application programs may be stored in the memory 520 and configured to be composed of one Or multiple processors 510 execute, and one or more programs are configured to execute the method described in the foregoing method embodiment.
- the processor 810 may include one or more processing cores.
- the processor 810 uses various interfaces and lines to connect various parts of the entire electronic device 800, and executes by running or executing instructions, programs, code sets, or instruction sets stored in the memory 820, and calling data stored in the memory 820.
- the processor 810 may adopt at least one of digital signal processing (Digital Signal Processing, DSP), Field-Programmable Gate Array (Field-Programmable Gate Array, FPGA), and Programmable Logic Array (Programmable Logic Array, PLA).
- DSP Digital Signal Processing
- FPGA Field-Programmable Gate Array
- PLA Programmable Logic Array
- the processor 810 may be integrated with one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), a modem, and the like.
- the CPU mainly processes the operating system, user interface, and application programs;
- the GPU is used to render and draw the content to be displayed;
- the modem is used to process wireless communication. It is understandable that the above-mentioned modem may not be integrated into the processor 810, but may be implemented by a communication chip alone.
- the memory 820 may include random access memory (RAM) or read-only memory (Read-Only Memory).
- the memory 820 may be used to store instructions, programs, codes, code sets or instruction sets.
- the memory 820 may include a program storage area and a data storage area, where the program storage area may store instructions for implementing the operating system and instructions for implementing at least one function (such as touch function, sound playback function, image playback function, etc.) , Instructions used to implement the following various method embodiments, etc.
- the storage data area can also store data (such as phone book, audio and video data, chat record data) created by the electronic device 800 during use.
- FIG. 14 shows a structural block diagram of a computer-readable storage medium provided by an embodiment of the present application.
- the computer readable medium 900 stores program code, and the program code can be invoked by a processor to execute the method described in the foregoing method embodiment.
- the computer-readable storage medium 900 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read Only Memory), EPROM, hard disk, or ROM.
- the computer-readable storage medium 900 includes a non-transitory computer-readable storage medium.
- the computer-readable storage medium 900 has a storage space for the program code 910 for executing any method steps in the above-mentioned methods. These program codes can be read from or written into one or more computer program products.
- the program code 910 may be compressed in an appropriate form, for example.
- the payment processing method, device, electronic device, and storage medium provided by the embodiments of the present application.
- the electronic device enters the payment mode in the process of running the target application, it obtains the attribute information of the called payment application based on This attribute information determines whether the payment application is legal or not.
- a pending event is generated, and the pending event is sent to the server.
- the pending event is used to instruct the server to process the target application.
- the target application enters the payment mode during the process, and the target application is processed when it is detected that the called payment application is illegal, so as to accurately and timely detect illegal payment behaviors, and fully protect the legitimate interests of users and the platform.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Stored Programmes (AREA)
Abstract
一种支付处理方法、装置、电子设备以及存储介质,涉及支付技术领域。该方法应用于电子设备,所述方法包括:电子设备在运行目标应用程序的过程中进入支付模式时,获取所调用的支付应用程序的属性信息,基于该属性信息判断支付应用程序是否合法,当支付应用程序不合法时,生成待处理事件,将待处理事件发送至服务器,该待处理事件用于指示服务器对目标应用程序进行处理。该支付处理方法、装置、电子设备以及存储介质通过在运行目标应用程序的过程中进入支付模式,且检测到所调用的支付应用程序不合法时对目标应用程序进行处理,以准确且及时的发现非法支付行为,充分保障用户和平台的合法利益。
Description
本申请涉及支付技术领域,更具体地,涉及一种支付处理方法、装置、电子设备以及存储介质。
随着科学技术的发展,电子设备的使用越来越广泛,功能越来越多,已经成为人们日常生活中的必备之一。目前,电子设备可以用于进行移动支付。
发明内容
鉴于上述问题,本申请提出了一种支付处理方法、装置、电子设备以及存储介质,以解决上述问题。
第一方面,本申请实施例提供了一种支付处理方法,应用于电子设备,所述方法包括:所述电子设备在运行目标应用程序的过程中进入支付模式时,获取所调用的支付应用程序的属性信息;基于所述属性信息判断所述支付应用程序是否合法;当所述支付应用程序不合法时,生成待处理事件;将所述待处理事件发送至服务器,所述待处理器事件用于指示所述服务器对所述目标应用程序进行处理。
第二方面,本申请实施例提供了一种支付处理方法,应用于服务器,所述方法包括:所述服务器接收电子设备发送的待处理事件,所述待处理事件为所述电子设备在运行目标应用程序的过程中进入支付模式时,所调用的支付应用程序不合法时生成;响应所述待处理事件对所述目标应用程序进行处理。
第三方面,本申请实施例提供了一种支付处理方法,应用于支付处理系统,所述支付处理系统包括连接的电子设备和服务器,所述方法包括:所述电子设备在运行目标应用程序的过程中进入支付模式时,获取所调用的支付应用程序的属性信息;所述电子设备基于所述属性信息判断所述支付应用程序是否合法;当所述支付应用程序不合法时,所述电子设备生成待处理事件;所述电子设备将所述待处理事件发送至服务器;所述服务器响应所述待处理器事件对所述目标应用程序进行处理。
第四方面,本申请实施例提供了一种支付处理装置,应用于电子设备,所述装置包括:属性信息获取模块,用于所述电子设备在运行目标应用程序的过程中进入支付模式时,获取所调用的支付应用程序的属性信息;属性信息判断模块,用于基于所述属性信息判断所述支付应用程序是否合法;待处理事件生成模块,用于当所述支付应用程序不合法时,生成待处理事件;待处理事件发送模块,用于将所述待处理事件发送至服务器,所述待处理器事件用于指示所述服务器对所述目标应用程序进行处理。
第五方面,本申请实施例提供了一种支付处理装置,应用于服务器,所述装置包括:待处理事件接收模块,用于所述服务器接收电子设备发送的待处理事件,所述待处理事件为所述电子设备在运行目标应用程序的过程中进入支付模式时,所调用的支付应用程序不合法时生成;待处理事件响应模块,用于响应所述待处理事件对所述目标应用程序进行处理。
第六方面,本申请实施例提供了一种电子设备,包括存储器和处理器,所述存储器耦接到所述处理器,所述存储器存储指令,当所述指令由所述处理器执行时所述处理器执行上述方法。
第七方面,本申请实施例提供了一种计算机可读取存储介质,所述计算机可读取存储介质中存储有程序代码,所述程序代码可被处理器调用执行上述方法。
本申请实施例提供的支付处理方法、装置、电子设备以及存储介质,电子设备在运行目标应用程序的过程中进入支付模式时,获取所调用的支付应用程序的属性信息,基于该属性信息判断支付应用程序是否合法,当支付应用程序不合法时,生成待处理事件,将待处理事件发送至服务器,该待处理事件用于指示服务器对目标应用程序进行处理,从而通过在运行目标应用程序的过程中进入 支付模式,且检测到所调用的支付应用程序不合法时对目标应用程序进行处理,以准确且及时的发现非法支付行为,充分保障用户和平台的合法利益。
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其它的附图。
图1示出了本申请实施例提供支付处理方法的应用场景的示意图;
图2示出了本申请一个实施例提供的支付处理方法的时序图;
图3示出了本申请又一个实施例提供的支付处理方法的流程示意图;
图4示出了本申请再一个实施例提供的支付处理方法的流程示意图;
图5示出了本申请的图4所示的支付处理方法的步骤S310的流程示意图;
图6示出了本申请的图5所示的支付处理方法的步骤S312的流程示意图;
图7示出了本申请的图4所示的支付处理方法的步骤S340的一个实施例的流程示意图;
图8示出了本申请的图4所示的支付处理方法的步骤S340的又一个实施例的流程示意图;
图9示出了本申请另一个实施例提供的支付处理方法的流程示意图;
图10示出了本申请又再一个实施例提供的支付处理方法的流程示意图;
图11示出了本申请一个实施例提供的支付处理装置的模块框图;
图12示出了本申请又一个实施例提供的支付处理装置的模块框图;
图13示出了本申请实施例用于执行根据本申请实施例的支付处理方法的电子设备的框图;
图14示出了本申请实施例的用于保存或者携带实现根据本申请实施例的支付处理方法的程序代码的存储单元。
为了使本技术领域的人员更好地理解本申请方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述。
移动支付也称为手机支付(Mobile Payment),是允许用户使用电子设备(例如手机、平板电脑等)对所消费的商品或服务进行账务支付的一种方式。其是一种结合了电子化货币、身份验证、移动通信与电子设备的崭新业务,可以使用户随时随地地享受多种服务。目前,电子设备对应的厂商开始研发用于支持电子设备进行移动支付的支付应用程序,并设定安装于该电子设备上的联合运营的应用程序在调用支付类应用程序时,需要调用该电子设备对应的厂商研发的支付应用程序。但是,部分联合运营的应用程序在调用支付类应用程序时,会调用比较多的第三方支付应用程序(非电子设备的对应的厂商研发的支付应用程序),即应用程序进行“切支付”,从而严重损害了电子设备平台的利益。
针对上述问题,发明人经过长期的研究发现,并提出了本申请实施例提供的支付处理方法、装置、电子设备以及存储介质,通过在运行目标应用程序的过程中进入支付模式,且检测到所调用的支付应用程序不合法时对目标应用程序进行处理,以准确且及时的发现非法支付行为,充分保障用户和平台的合法利益。其中,具体的支付处理方法在后续的实施例中进行详细的说明。
下面将针对本申请实施例提供的支付处理方法的应用场景进行描述。
请参阅图1,图1示出了本申请实施提供的支付处理系统10的示意图。支付处理系统10包括电子设备100和服务器200,其中,电子设备100和服务器200通信连接,以实现电子设备100和服务器200的数据交互,例如,电子设备100可以发送待处理事件至服务器200等。作为一种方式,电子设备100和服务器200可以分别与基站连接,以通过基站实现电子设备100和服务器200之间的 数据交互。其中,电子设备100可以包括智能手机、平板电脑、穿戴式电子设备等。服务器200可以包括传统服务器、云服务器等,在此不做限定。
进一步地,该支付处理系统10还包括其他更多的电子设备,例如,还可以包括第一测试设备300、第二测试设备400以及第三测试设备500。服务器200分别第一测试设备300、第二测试设备400以及第三测试设备500通信连接,以实现与第一测试设备300、第二测试设备400以及第三测试设备500的数据交互,例如,服务器200可以发送待处理事件中的数据信息给第一测试设备300、第二测试设备400或者第三测试设备500等,在此不做限定。
请参阅图2,图2示出了本申请一个实施例提供的支付处理方法的时序图。下面将针对图2所示的流程进行详细的阐述,所述支付处理方法应用于支付处理系统,该支付处理系统包括电子设备和服务器,该电子设备和服务器连接,所述支付处理方法具体可以包括以下步骤:
步骤S110:所述电子设备在运行目标应用程序的过程中进入支付模式时,获取所调用的支付应用程序的属性信息。
在本实施例中,电子设备可以在前台运行应用程序、在后台运行应用程序或在前台和后台切换运行应用程序,在此不做限定。具体的,在前台运行的应用程序是指通常可以和用户进行交互,能运行在前台的应用程序,当它不可见时就会被挂起(比如:游戏);在后台运行的应用程序是指和用户交互非常有限,除了配置期间,其生存期的其他时间都是隐藏的(比如:SMS自动回复程序和闹钟程序);在电子设备的前台和后台切换运行的应用程序是指可以在前台以及后台之间随意切换的应用程序。可以理解的,当应用程序没有被杀掉(kill)时,表征该应用程序在电子设备上运行。可选地,在本实施例中,目标应用程序为在电子设备的前台运行的应用程序。
在一些实施方式中,电子设备在运行目标应用程序的过程中,可能会涉及到支付行为,则目标应用程序会响应支付行为调用支付应用程序进入支付模式。例如,若该目标应用程序为游戏类应用程序,则电子设备在运行游戏类应用程序的过程中,用户可能触发“装备购买”、“皮肤购买”等需要支付的场景,则目标应用程序可以响应用户的触发调用支付应用程序进入支付模式。又例如,若该目标应用程序为购物类应用程序,则电子设备在运行购物类应用程序的过程中,用户可能触发“购买”、“付款”等需要支付的场景,则目标应用程序可以响应用户触发调用支付应用程序进入支付模式。当然,在本实施例中,目标应用程序还可以在其他场景下进入支付模式,在此不再赘述。
在本实施例中,电子设备在运行目标应用程序的过程中进入支付模式时,电子设备可以获取该目标应用程序所调用的支付应用程序,并获取该支付应用程序的属性信息。其中,目标应用程序的属性信息包括但不限于:目标应用程序的包名、目标应用程序的软件开发工具包SDK插件、目标应用程序的上线时间、目标应用程序的客户量、目标应用程序的转化率等,在此不做限定。在一些实施方式中,电子设备可以从本地或者服务器获取支付应用程序的属性信息,以电子设备从本地获取为例,电子设备的本地可以记录有所安装的所有应用程序的属性信息,因此,电子设备在确定所调用的支付应用程序时,可以从本地读取该支付应用程序的属性信息。
步骤S120:所述电子设备基于所述属性信息判断所述支付应用程序是否合法。
在一些实施方式中,电子设备可以预先设置属性信息的合法条件,其中,该合法条件用于表征支付应用程序为官方支付应用程序。因此,在获得所调用的支付应用程序的属性信息后,可以将支付应用程序的属性信息和合法条件进行比较,以判断支付应用程序的属性信息是否满足合法条件。
其中,当支付应用程序的属性信息满足合法条件时,表征支付应用程序为电子设备设定的官方支付应用程序,而非第三方支付应用程序,目标应用程序没有发生“切支付”,可以确定目标应用程序调用的支付应用程序合法;当支付应用程序的属性信息不满足合法条件时,表征支付应用程序不是电子设备设定的官方支付应用程序,而是第三方支付应用程序,目标应用程序发生“切支付”,可以确定目标应用程序调 用的支付应用程序不合法。
步骤S130:当所述支付应用程序不合法时,所述电子设备生成待处理事件。
在一些实施方式中,当判断结果表征支付应用程序不合法时,表征该目标应用程序发生“切支付”,因此,为了充分保障用户和厂商平台的利益,有效打击“切支付”的应用程序和背后的开发商,肃清整个行业的环境,可以对发生“切支付”的目标应用程序进行处理。在本实施例中,当目标应用程序包所调用的支付应用程序不合法时,电子设备可以生成针对目标应用程序的待处理事件,其中,该待处理事件可以包括待处罚事件、待验证事件等,以对目标应用程序进行处理,在此不做限定。
作为一种方式,当判断结果表征支付应用程序不合法时,电子设备可以继续执行支付操作,以减小对用户支付的影响,提升用户体验。作为另一种方式,当判断结果表征支付应用程序不合法时,电子设备可以继续执行支付操作并输出提示信息,该指示信息用于提示用户该目标应用程序可能存在的问题,以便用户帮助肃清整个行业的环境。作为再一种方式,当判断结果表征支付应用程序不合法时,电子设备可以终止支付操作并输出提示信息,以直接避免平台的利益受损。当然,在本实施例中,当支付应用程序不合法时,电子设备还可以包括其他更多针对支付操作的方式,在此不再赘述。
步骤S140:所述电子设备将所述待处理事件发送至服务器。
在一些实施方式中,电子设备在生成待处理事件后,可以通过数据网络或无线网络将待处理事件发送至服务器,在此不做限定。
步骤S150:所述服务器响应所述待处理器事件对所述目标应用程序进行处理。
在一些实施方式中,服务器在接收到电子设备发送的待处理事件后,可以响应该待处理事件对目标应用程序进行处理,例如,对目标应用程序进行处罚、对目标应用程序背后的开发商进行处罚等。在本实施例中,服务器在接收到电子设备发送的待处理事件后,可以对目标应用程序的支付过程进行复现并取证,以通过真实发生“切支付”时的数据复现目标应用程序的不合法行为,以便对目标应用程序进行处理。
本申请一个实施例提供支付处理方法,电子设备在运行目标应用程序的过程中进入支付模式时,获取所调用的支付应用程序的属性信息,基于该属性信息判断支付应用程序是否合法,当支付应用程序不合法时,生成待处理事件,将待处理事件发送至服务器,服务器响应该待处理事件对目标应用程序进行处理,从而通过电子设备在运行目标应用程序的过程中进入支付模式,且检测到所调用的支付应用程序不合法时,通过服务器对目标应用程序进行处理,以准确且及时的发现非法支付行为,充分保障用户和平台的合法利益。
请参阅图3,图3示出了本申请又一个实施例提供的支付处理方法的流程示意图。在具体的实施例中,该方法应用于如图11所示的支付处理装置600以及配置有所述支付处理装置600的电子设备100(如图1所示)。下面将针对图3所示的流程进行详细的阐述,所述支付处理方法具体可以包括以下步骤:
步骤S210:所述电子设备在运行目标应用程序的过程中进入支付模式时,获取所调用的支付应用程序的属性信息。
步骤S220:基于所述属性信息判断所述支付应用程序是否合法。
步骤S230:当所述支付应用程序不合法时,生成待处理事件。
步骤S240:将所述待处理事件发送至服务器,所述待处理器事件用于指示所述服务器对所述目标应用程序进行处理。
其中,步骤S210-步骤S240的具体描述请参阅步骤S110-步骤S150,在此不再赘述。
本申请又一个实施例提供的支付处理方法,电子设备在运行目标应用程序的过程中进入支付模式时,获取所调用的支付应用程序的属性信息,基于该属性信息判断支付应用程序是否合法,当支付应用程序不合法时,生成待处理事件,将待处理事件发送至服务器,该待处理事件用于指示服务 器对目标应用程序进行处理,从而通过在运行目标应用程序的过程中进入支付模式,且检测到所调用的支付应用程序不合法时对目标应用程序进行处理,以准确且及时的发现非法支付行为,充分保障用户和平台的合法利益。
请参阅图4,图4示出了本申请再一个实施例提供的支付处理方法的流程示意图。该方法应用于电子设备,下面将针对图4所示的流程进行详细的阐述,所述支付处理方法具体可以包括以下步骤:
步骤S310:所述电子设备在运行应用程序时,判断所述应用程序是否满足指定条件。
在一些实施方式中,电子设备预先设置并存储有指定条件,该指定条件用于作为电子设备运行的应用程序的判断依据,且指定条件用于表征满足目标应用程序条件。因此,在本实施例中,电子设备在运行应用程序时,可以将电子设备运行的应用程序和指定条件进行比较,以判断该应用程序是否满足指定条件,其中,当判断结果表征应用程序满足指定条件时,可以将应用程序确定为目标应用程序,当判断结果表征应用程序不满足指定条件时,可以将应用程序确定为非目标应用程序。
请参阅图5,图5示出了本申请实施例的图4所示的支付处理方法的步骤S310的流程示意图。下面将针对图5所示的流程进行详细的阐述,所述方法具体可以包括以下步骤:
步骤S311:电子设备在运行所述应用程序时,判断所述应用程序是否属于联合运营的应用程序。
在一些实施方式中,该指定条件可以包括联合运营的应用程序,即当应用程序属于联合运营的应用程序时,可以确定该应用程序满足指定条件,当应用程序不属于联合运营的应用程序时,可以确定该应用程序不满足指定条件。其中,联合运营的应用程序是指电子设备厂商和应用程序开发商共同合作的应用程序。
在本实施例中,电子设备在运行应用程序时,可以将电子设备运行的应用程序和所有联合运营的应用程序进行比较,以判断该应用程序是否属于联合运营的应用程序,其中,当判断结果表征应用程序属于联合运营的应用程序时,可以确定应用程序满足指定条件,将应用程序确定为目标应用程序,当判断结果表征应用程序不属于联合运营的应用程序时,可以确定应用程序不满足指定条件,将应用程序确定为非目标应用程序。
作为一种方式,电子设备可以预先创建联合运营的应用程序的清单,该清单用于添加记录所有联合运营的应用程序,因此,电子设备在获取运行的应用程序后,可以通过在清单中查找是否记录有与运行的应用程序一致的应用程序的方式,来判断运行的应用程序是否属于联合运营的应用程序。作为另一种方式,电子设备可以在每个联合运营的应用程序添加标记,因此,电子设备在获取运行的应用程序后,可以通过判断运行的应用程序是否包括标记的方式,来判断运行的应用程序是否属于联合运营的应用程序。当然,在本实施例中,电子设备还可以包括其他更多判断运行的应用程序是否为联合运营的应用程序的方式,在此不再赘述。
步骤S312:当所述应用程序属于联合运营的应用程序时,将所述应用程序确定为所述目标应用程序。
请参阅图6,图6示出了本申请实施例的图5所示的支付处理方法的步骤S312的流程示意图。下面将针对图5所示的流程进行详细的阐述,所述方法具体可以包括以下步骤:
步骤S3121:当所述应用程序属于所述联合运营的应用程序时,判断所述应用程序是否为游戏类应用程序。
在一些实施方式中,当确定应用程序属于联合运营的应用程序时,可以判断该应用程序是否为游戏类应用程序,其中,当判断结果表征该应用程序为游戏类应用程序时,可以将该应用程序确定为目标应用程序,当判断结果表征该应用程序不是游戏类应用程序时,可以将该应用程序确定为非目标应用程序。在本实施例中,可以获取应用程序的类型,并将该应用程序的类型和游戏类应用程序的类型进行比较,以判断该应用程序是否为游戏类应用程序,可以理解的是,当应用程序的类型与游戏类应用程序的类型一致时,可以确定该应用程序为游戏类应用程序,当应用程序的类型与游戏类应用程序的类型不一致时,可以确定 该应用程序为非游戏类应用程序。
步骤S3122:当所述应用程序为游戏类应用程序时,将所述应用程序确定为所述目标应用程序。
步骤S320:当所述应用程序满足所述指定条件时,将所述应用程序确定为目标应用程序。
步骤S330:所述电子设备在运行目标应用程序的过程中进入支付模式时,获取所调用的支付应用程序的属性信息。
其中,步骤S330的具体描述请参阅步骤S110,在此不再赘述。
步骤S340:基于所述属性信息判断所述支付应用程序是否为官方支付应用程序,所述官方支付应用程序为所述电子设备所属的厂商对应的支付应用程序。
在一些实施方式中,支付应用程序的合法条件为官方支付应用程序,其中,官方支付应用程序为电子设备所属的厂商对应的支付应用程序。因此,在本实施例中,在获取支付应用程序的属性信息后,可以基于该属性信息判断支付应用程序是否为官方支付应用程序,其中,当支付应用程序为官方支付应用程序时,可以确定该目标应用程序没有发生“切支付”,该支付应用程序合法,当支付应用程序不是官方支付应用程序时,可以确定该目标应用程序发生“切支付”,该支付应用程序不合法。
请参阅图7,图7示出了本申请实施例的图4所示的支付处理方法的步骤S340的一个实施例的流程示意图。下面将针对图7所示的流程进行详细的阐述,所述电子设备预先存储所述官方支付应用程序对应的官方属性信息,所述支付处理方法具体可以包括以下步骤:
步骤S341A:获取所述官方属性信息,并判断所述属性信息是否与所述官方属性信息一致。
在一些实施方式中,电子设备预先存储有官方支付应用程序对应的官方属性信息。因此,在本实施例中,在获取支付应用程序的属性信息和官方属性信息之后,可以将支付应用程序的属性信息和官方属性信息进行比较,以判断支付应用程序的属性信息是否与官方属性信息一致,当支付应用程序的属性信息与官方属性信息一致时,可以确定支付应用程序是官方支付应用程序,当支付应用程序的属性信息与官方属性信息不一致时,可以确定支付应用程序不是官方支付应用程序。
步骤S342A:当所述属性信息与所述官方属性信息不一致时,确定所述支付应用程序不是所述官方支付应用程序。
请参阅图8,图8示出了本申请实施例的图4所示的支付处理方法的步骤S340的又一个实施例的流程示意图。下面将针对图8所示的流程进行详细的阐述,所述属性信息包括软件开发工具包SDK插件,所述支付处理方法具体可以包括以下步骤:
步骤S341B:判断所述SDK插件是否为官方SDK插件,所述官方SDK插件为所述电子设备所属的厂商对应的SDK插件。
在一些实施方式中,属性信息包括SDK插件,电子设备可以预先存储有官方SDK插件,该官方SDK插件为电子设备所属的厂商对应的SDK插件。因此,在本实施例中,在获取支付应用程序的SDK插件和官方SDK插件之后,可以将支付应用程序的SDK插件和官方SDK插件进行比较,以判断支付应用程序的SDK插件是否与官方SDK插件一致,当支付应用程序的SDK插件与官方SDK插件一致时,可以确定支付应用程序是官方支付应用程序,当支付应用程序的SDK插件与官方SDK插件不一致时,可以确定支付应用程序不是官方支付应用程序。
步骤S342B:当所述SDK插件不是所述官方SDK插件时,确定所述支付应用程序不是所述官方支付应用程序。
步骤S350:当所述支付应用程序不是所述官方支付应用程序时,确定所述支付应用程序不合法。
步骤S360:当所述支付应用程序不合法时,生成待处理事件。
步骤S370:将所述待处理事件发送至服务器,所述待处理器事件用于指示所述服务器对所述目标应用程序进行处理。
其中,步骤S360-步骤S370的具体描述请参阅步骤S130-步骤S150,在此不再赘述。
本申请再一个实施例提供的支付处理方法,电子设备在运行应用程序时,判断该应用程序是否满足指定条件,当应用程序满足指定条件时,将应用程序确定为目标应用程序。电子设备在运行目标应用程序的过程中进入支付模式时,获取所调用的支付应用程序的属性信息,基于该属性信息判断支付应用程序是否为官方支付应用程序,该官方支付应用程序为电子设备所属的厂商对应的支付应用程序,当支付应用程序不是官方支付应用程序时,确定支付应用程序不合法,当支付应用程序不合法时,生成待处理事件,将待处理事件发送至服务器,该待处理事件用于指示服务器对目标应用程序进行处理。相较于图3所示的支付处理方法,本实施例还通过指定条件对电子设备运行的应用程序进行判断以确定目标应用程序,以提升目标应用程序处理的准确性。另外,本实施例还通过判断支付应用程序是否为官方支付应用程序的方式判断支付应用程序是否合法,以提升支付应用程序判断的准确性。
请参阅图9,图9示出了本申请另一个实施例提供的支付处理方法的流程示意图。在具体的实施例中,该方法应用于如图12所示的支付处理装置700以及配置有所述支付处理装置700的服务器200(如图1所示)。下面将针对图9所示的流程进行详细的阐述,所述支付处理方法具体可以包括以下步骤:
步骤S410:所述服务器接收电子设备发送的待处理事件,所述待处理事件为所述电子设备在运行目标应用程序的过程中进入支付模式时,所调用的支付应用程序不合法时生成。
步骤S420:响应所述待处理事件对所述目标应用程序进行处理。
其中,步骤S410-步骤S420的具体描述请参阅步骤S110-步骤S150,在此不再赘述。
本申请另一个实施例提供的支付处理方法,服务器接收电子设备发送的待处理事件,该待处理事件为电子设备在运行目标应用程序的过程中进入支付模式时,所调用的支付应用程序不合法时生成,响应待处理事件对目标应用程序进行处理,从而通过在运行目标应用程序的过程中进入支付模式,且检测到所调用的支付应用程序不合法时对目标应用程序进行处理,以准确且及时的发现非法支付行为,充分保障用户和平台的合法利益。
请参阅图10,图10示出了本申请又再一个实施例提供的支付处理方法的流程示意图。该方法应用于服务器,下面将针对图10所示的流程进行详细的阐述,所述待处理事件包括所述目标应用程序的基础信息、所述电子设备的第一标识信息以及所述电子设备的第二标识信息,所述支付处理方法具体可以包括以下步骤:
步骤S510:所述服务器接收电子设备发送的待处理事件,所述待处理事件为所述电子设备在运行目标应用程序的过程中进入支付模式时,所调用的支付应用程序不合法时生成。
其中,步骤S510的具体描述请参阅步骤S110-步骤S140,在此不再赘述。
步骤S520:将所述基本信息发送至第一测试设备,所述基本信息用于指示所述第一测试设备基于所述基本信息安装所述目标应用程序,以对所述目标应用程序的支付过程进行复现,并在所述目标应用程序的支付过程复现成功时进行取证。
在一些实施方式中,待处理事件包括目标应用程序的基本信息,相应地,服务器可以响应该待处理事件,基于所述基本信息对所述目标应用程序进行处理。其中,该目标应用程序的基本信息至少可以包括该目标应用程序的包名,则服务器可以基于目标应用程序的包名查找到对应的目标应用程序,以对目标应用程序进行处理。
在一些实施方式中,服务器在获取目标应用程序的基本信息后,可以将目标应用程序的基本信息发送至通信连接的第一测试设备,相应地,第一测试设备可以基于接收到的基本信息安装目标应用程序,以对该目标应用程序的支付过程进行复现,并在目标应用程序的支付过程复现成功时进行取证,以提供对目标 应用程序进行处罚的证据。例如,当该基本信息为包名时,第一测试设备可以基于接收到的包名安装目标应用程序,以对该目标应用程序的支付过程进行复现,并在目标应用程序的支付过程复现成功时进行取证。在本实施例中,第一测试设备可以通过录屏取证,在此不做限定。
步骤S530:当所述目标应用程序的支付过程复现失败时,确定与所述第一标识信息对应的第二测试设备。
在一些实施方式中,目标应用程序的开发者为了降低被发现“切支付”行为可能性,其设定的“切支付”可能并非针对所有电子设备,而是针对部分型号的电子设备,因此,仅通过目标应用程序的基本信息对目标应用程序的支付过程进行复现,可能无法复现“切支付”行为,即导致目标应用程序的支付过程复现失败。
在本实施例中,待处理事件还包括电子设备的第一标识信息。因此,当目标应用程序的支付过程复现失败时,表征仅通过基本信息无法实现对目标应用程序的支付过程的复现时,可以基于该第一标识信息确定对应的第二测试设备,以通过第二测试设备解决目标应用程序的“切支付”可能仅针对部分型号的电子设备的问题。具体地,该第一标识信息至少可以包括机型,因此,当目标应用程序的支付过程复现失败时,可以基于机型确定与电子设备的机型一致的电子设备作为第二测试设备,以通过与发生“切支付”的电子设备机型一致的电子设备作为第二测试设备对支付过程进行复现的方式,解决目标应用程序的“切支付”可能仅针对部分型号的电子设备的问题。
步骤S540:将所述基本信息发送至所述第二测试设备,所述基本信息用于指示所述第二测试设备基于所述基本信息安装所述目标应用程序,以对所述目标应用程序的支付过程进行复现,并在所述目标应用程序的支付过程复现成功时进行取证。
在一些实施方式中,服务器在获取目标应用程序的基本信息以及确定与第一标识信息对应的第二测试设备后,可以将目标应用程序的基本信息发送至通信连接的第二测试设备,相应地,第二测试设备可以基于接收到的基本信息安装目标应用程序,以对该目标应用程序的支付过程进行复现,并在目标应用程序的支付过程复现成功时进行取证,以提供对目标应用程序进行处罚的证据。例如,当该基本信息为包名时,第二测试设备可以基于接收到的包名安装目标应用程序,以对该目标应用程序的支付过程进行复现,并在目标应用程序的支付过程复现成功时进行取证。在本实施例中,第二测试设备可以通过录屏取证,在此不做限定。
步骤S550:当所述目标应用程序的支付过程复现失败时,确定与所述第一标识信息和第二标识信息对应的第三测试设备。
在一些实施方式中,目标应用程序的开发者为了降低被发现“切支付”行为可能性,其设定的“切支付”可能并非针对所有电子设备,而是针对部分型号的电子设备,并且其设定的“切支付”可能并非针对所有的区域,而是针对比较偏远的区域。因此,仅通过目标应用程序的基本信息和电子设备的第一标识信息对目标应用程序的支付过程进行复现,可能无法复现“切支付”行为,即导致目标应用程序的支付过程复现失败。
在本实施例中,待处理事件还包括电子设备的第二标识信息。因此,当目标应用程序的支付过程复现失败时,表征仅通过基本信息和第一标识信息无法实现对目标应用程序的支付过程的复现时,可以基于该第一标识信息和第二标识信息确定对应的第三测试设备,以通过第三测试设备解决目标应用程序的“切支付”可能仅针对部分型号的电子设备且针对比较偏远的区域的问题。具体地,该第一标识信息至少可以包括机型,该第二标识信息至少可以包括网络协议IP地址,因此,当目标应用程序的支付过程复现失败时,可以基于机型和IP地址确定与电子设备的机型一致且处于同一城市的电子设备作为第三测试设备,以通过与发生“切支付”的电子设备机型一致且城市相同的电子设备作为第三测试设备对支付过程进行复现的方式,解决目标应用程序的“切支付”可能仅针对部分型号的电子设备且针对比较偏远的区域的问题。
步骤S560:将所述基本信息发送至所述第三测试设备,所述基本信息用于指示所述第三测试设备基于所述基本信息安装所述目标应用程序,以对所述目标应用程序的支付过程进行复现,并在所述目标应用程序的支付过程复现成功时进行取证。
在一些实施方式中,服务器在获取目标应用程序的基本信息以及确定与第一标识信息和第二标识信息对应的第三测试设备后,可以将目标应用程序的基本信息发送至通信连接的第三测试设备,相应地,第三测试设备可以基于接收到的基本信息安装目标应用程序,以对该目标应用程序的支付过程进行复现,并在目标应用程序的支付过程复现成功时进行取证,以提供对目标应用程序进行处罚的证据。例如,当该基本信息为包名时,第三测试设备可以基于接收到的包名安装目标应用程序,以对该目标应用程序的支付过程进行复现,并在目标应用程序的支付过程复现成功时进行取证。在本实施例中,第三测试设备可以通过录屏取证,在此不做限定。
当然,在本实施例中,还可以通过第三测试设备在与电子设备发生“切支付”的时间相同的时间进行目标应用程序的支付过程的复现,以提高复现的成功率,在此不再赘述。
本申请又再一个实施例提供的支付处理方法,服务器接收电子设备发送的待处理事件,该待处理事件为电子设备在运行目标应用程序的过程中进入支付模式时,所调用的支付应用程序不合法时生成,将基本信息发送至第一测试设备,该基本信息用于指示第一测试设备基于基本信息安装目标应用程序,以对目标应用程序的支付过程进行复现,并在目标应用程序的支付过程复现成功时进行取证。当目标应用程序的支付过程复现失败时,确定与第一标识信息对应的第二测试设备,将基本信息发送至第二测试设备,该基本信息用于指示第二测试设备基于基本信息安装目标应用程序,以对目标应用程序的支付过程进行复现,并在目标应用程序的支付过程复现成功时进行取证。当目标应用程序的支付过程复现失败时,确定与第一标识信息和第二标识信息对应的第三测试设备,将基本信息发送至第三测试设备,该基本信息用于指示第三测试设备基于基本信息安装目标应用程序,以对目标应用程序的支付过程进行复现,并在目标应用程序的支付过程复现成功时进行取证。相较于图9所示的支付处理方法,本实施例在通过基本信息复现支付过程失败时,还根据电子设备的机型、IP地址等进行支付过程的复现,以提升支付过程复现的成功率,以便于取证。
请参阅图11,图11示出了本申请一个实施例提供的支付处理装置600的模块框图。该支付处理装置600应用于上述电子设备,下面将针对图11所示的框图进行阐述,所述支付处理装置600包括:属性信息获取模块610、属性信息判断模块620、待处理事件生成模块630以及待处理事件发送模块640,其中:
属性信息获取模块610,用于所述电子设备在运行目标应用程序的过程中进入支付模式时,获取所调用的支付应用程序的属性信息。
属性信息判断模块620,用于基于所述属性信息判断所述支付应用程序是否合法。进一步地,所述属性信息判断模块620包括:属性信息判断子模块和第一确定子模块,其中:
属性信息判断子模块,用于基于所述属性信息判断所述支付应用程序是否为官方支付应用程序,所述官方支付应用程序为所述电子设备所属的厂商对应的支付应用程序。进一步地,所述电子设备预先存储所述官方支付应用程序对应的官方属性信息,所述属性信息判断子模块包括:属性信息判断单元和第一确定单元,其中:
属性信息判断单元,用于获取所述官方属性信息,并判断所述属性信息是否与所述官方属性信息一致。
第一确定单元,用于当所述属性信息与所述官方属性信息不一致时,确定所述支付应用程序不是所述官方支付应用程序。
进一步地,所述属性信息包括软件开发工具包SDK插件,所述属性信息判断子模块包括:SDK插件判断单元和第二确定单元,其中:
SDK插件判断单元,用于判断所述SDK插件是否为官方SDK插件,所述官方SDK插件为所述电子设备所属的厂商对应的SDK插件。
第二确定单元,用于当所述SDK插件不是所述官方SDK插件时,确定所述支付应用程序不是所述官方支付应用程序。
第一确定子模块,用于当所述支付应用程序不是所述官方支付应用程序时,确定所述支付应用程序不合法。
待处理事件生成模块630,用于当所述支付应用程序不合法时,生成待处理事件。
待处理事件发送模块640,用于将所述待处理事件发送至服务器,所述待处理器事件用于指示所述服务器对所述目标应用程序进行处理。
进一步地,所述支付处理装置600还包括:应用程序判断子模块和应用程序确定子模块,其中:
应用程序判断子模块,用于所述电子设备在运行应用程序时,判断所述应用程序是否满足指定条件。进一步地,所述应用程序判断子模块包括:应用程序判断单元和应用程序确定单元,其中:
应用程序判断单元,用于电子设备在运行所述应用程序时,判断所述应用程序是否属于联合运营的应用程序。
应用程序确定单元,用于当所述应用程序属于联合运营的应用程序时,将所述应用程序确定为所述目标应用程序。进一步地,所述应用程序确定单元包括:应用程序判断子模块和应用程序确定子单元,其中:
应用程序判断子单元,用于当所述应用程序属于所述联合运营的应用程序时,判断所述应用程序是否为游戏类应用程序。
应用程序确定子模块,用于当所述应用程序为游戏类应用程序时,将所述应用程序确定为所述目标应用程序。
应用程序确定子模块,用于当所述应用程序满足所述指定条件时,将所述应用程序确定为目标应用程序。
请参阅图12,图12示出了本申请又一个实施例提供的支付处理装置700的模块框图。该支付处理装置700应用于上述电子设备,下面将针对图12所示的框图进行阐述,所述支付处理装置700包括:待处理事件接收模块710和待处理事件响应模块720,其中:
待处理事件接收模块710,用于所述服务器接收电子设备发送的待处理事件,所述待处理事件为所述电子设备在运行目标应用程序的过程中进入支付模式时,所调用的支付应用程序不合法时生成。
待处理事件响应模块720,用于响应所述待处理事件对所述目标应用程序进行处理。进一步地,所述待处理事件包括所述目标应用程序的基本信息,所述待处理事件响应模块720包括:待处理事件响应子模块,其中:
待处理事件响应子模块,用于响应所述待处理事件,基于所述基本信息对所述目标应用程序进行处理。进一步地,所述待处理事件响应子模块包括:基本信息发送单元,其中:
第一基本信息发送单元,用于将所述基本信息发送至第一测试设备,所述基本信息用于指示所述第一测试设备基于所述基本信息安装所述目标应用程序,以对所述目标应用程序的支付过程进行复现,并在所述目标应用程序的支付过程复现成功时进行取证。
进一步地,所述待处理事件还包括所述电子设备的第一标识信息,所述待处理事件响应子模块包括:第二测试设备确定单元和第二基本信息发送单元,其中:
第二测试设备确定单元,用于当所述目标应用程序的支付过程复现失败时,确定与所述第一标识信息对应的第二测试设备。进一步地,所述第一标识信息包括机型,所述第二测试设备确定单元包括:
第二测试设备确定子单元,用于当所述目标应用程序的支付过程复现失败时,基于所述机型确定与所述电子设备的机型一致的电子设备作为所述第二测试设备。
第二基本信息发送单元,用于将所述基本信息发送至所述第二测试设备,所述基本信息用于指示所述第二测试设备基于所述基本信息安装所述目标应用程序,以对所述目标应用程序的支付过程进行复现,并在所述目标应用程序的支付过程复现成功时进行取证。
进一步地,所述待处理事件还包括所述电子设备的第二标识信息,所述待处理事件响应子模块包括:第三测试设备确定单元和第三基本信息发送单元,其中:
第三测试设备确定单元,用于当所述目标应用程序的支付过程复现失败时,确定与所述第一标识信息和第二标识信息对应的第三测试设备。进一步地,所述第一标识信息包括机型,所述第二标识信息包括网络协议IP地址,所述第三测试设备确定单元包括:第三测试设备确定子单元,其中:
第三测试设备确定子单元,用于当所述目标应用程序的支付过程复现失败时,基于所述机型和所述IP地址确定与所述电子设备机型一致且处于同一城市的电子设备作为所述第三测试设备。
第三基本信息发送单元,用于将所述基本信息发送至所述第三测试设备,所述基本信息用于指示所述第三测试设备基于所述基本信息安装所述目标应用程序,以对所述目标应用程序的支付过程进行复现,并在所述目标应用程序的支付过程复现成功时进行取证。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述装置和模块的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,模块相互之间的耦合可以是电性,机械或其它形式的耦合。
另外,在本申请各个实施例中的各功能模块可以集成在一个处理模块中,也可以是各个模块单独物理存在,也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。
请参阅图13,其示出了本申请实施例提供的一种电子设备800的结构框图。其中,该电子设备800可以包括电子设备100,也可以包括服务器200,在此不做限定。该电子设备800可以是智能手机、平板电脑、电子书等能够运行应用程序的电子设备。本申请中的电子设备800可以包括一个或多个如下部件:处理器810、存储器820以及一个或多个应用程序,其中一个或多个应用程序可以被存储在存储器520中并被配置为由一个或多个处理器510执行,一个或多个程序配置用于执行如前述方法实施例所描述的方法。
其中,处理器810可以包括一个或者多个处理核。处理器810利用各种接口和线路连接整个电子设备800内的各个部分,通过运行或执行存储在存储器820内的指令、程序、代码集或指令集,以及调用存储在存储器820内的数据,执行电子设备800的各种功能和处理数据。可选地,处理器810可以采用数字信号处理(Digital Signal Processing,DSP)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)、可编程逻辑阵列(Programmable Logic Array,PLA)中的至少一种硬件形式来实现。处理器810可集成中央处理器(Central Processing Unit,CPU)、图形处理器(Graphics Processing Unit,GPU)和调制解调器等中的一种或几种的组合。其中,CPU主要处理操作系统、用户界面和应用程序等;GPU用于负责待显示内容的渲染和绘制;调制解调器用于处理无线通信。可以理解的是,上述调制解调器也可以不集成到处理器810中,单独通过一块通信芯片进行实现。
存储器820可以包括随机存储器(Random Access Memory,RAM),也可以包括只读存储器(Read-Only Memory)。存储器820可用于存储指令、程序、代码、代码集或指令集。存储器820可包括存储程序区和存储数据区,其中,存储程序区可存储用于实现操作系统的指令、用于实现至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等。存储数据区还可以存储电子设备800在使用中所创建的数据(比如电话本、音视频数据、聊天记录数据)等。
请参阅图14,其示出了本申请实施例提供的一种计算机可读存储介质的结构框图。该计算机 可读介质900中存储有程序代码,所述程序代码可被处理器调用执行上述方法实施例中所描述的方法。
计算机可读存储介质900可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM、硬盘或者ROM之类的电子存储器。可选地,计算机可读存储介质900包括非易失性计算机可读介质(non-transitory computer-readable storage medium)。计算机可读存储介质900具有执行上述方法中的任何方法步骤的程序代码910的存储空间。这些程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。程序代码910可以例如以适当形式进行压缩。
综上所述,本申请实施例提供的支付处理方法、装置、电子设备以及存储介质,电子设备在运行目标应用程序的过程中进入支付模式时,获取所调用的支付应用程序的属性信息,基于该属性信息判断支付应用程序是否合法,当支付应用程序不合法时,生成待处理事件,将待处理事件发送至服务器,该待处理事件用于指示服务器对目标应用程序进行处理,从而通过在运行目标应用程序的过程中进入支付模式,且检测到所调用的支付应用程序不合法时对目标应用程序进行处理,以准确且及时的发现非法支付行为,充分保障用户和平台的合法利益。
最后应说明的是:以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不驱使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。
Claims (20)
- 一种支付处理方法,其特征在于,应用于电子设备,所述方法包括:所述电子设备在运行目标应用程序的过程中进入支付模式时,获取所调用的支付应用程序的属性信息;基于所述属性信息判断所述支付应用程序是否合法;当所述支付应用程序不合法时,生成待处理事件;将所述待处理事件发送至服务器,所述待处理器事件用于指示所述服务器对所述目标应用程序进行处理。
- 根据权利要求1所述的方法,其特征在于,所述基于所述属性信息判断所述支付应用程序是否合法,包括:基于所述属性信息判断所述支付应用程序是否为官方支付应用程序,所述官方支付应用程序为所述电子设备所属的厂商对应的支付应用程序;当所述支付应用程序不是所述官方支付应用程序时,确定所述支付应用程序不合法。
- 根据权利要求2所述的方法,其特征在于,所述电子设备预先存储所述官方支付应用程序对应的官方属性信息,所述基于所述属性信息判断所述支付应用程序是否为官方支付应用程序,包括:获取所述官方属性信息,并判断所述属性信息是否与所述官方属性信息一致;当所述属性信息与所述官方属性信息不一致时,确定所述支付应用程序不是所述官方支付应用程序。
- 根据权利要求2或3所述的方法,其特征在于,所述属性信息包括软件开发工具包SDK插件,所述基于所述属性信息判断所述支付应用程序是否为官方支付应用程序,包括:判断所述SDK插件是否为官方SDK插件,所述官方SDK插件为所述电子设备所属的厂商对应的SDK插件;当所述SDK插件不是所述官方SDK插件时,确定所述支付应用程序不是所述官方支付应用程序。
- 根据权利要求1-4任一项所述的方法,其特征在于,所述电子设备在运行目标应用程序的过程中进入支付模式时,获取所调用的支付应用程序的属性信息之前,还包括:所述电子设备在运行应用程序时,判断所述应用程序是否满足指定条件;当所述应用程序满足所述指定条件时,将所述应用程序确定为目标应用程序。
- 根据权利要求5所述的方法,其特征在于,所述电子设备在运行应用程序时,判断所述应用程序是否满足指定条件,包括:电子设备在运行所述应用程序时,判断所述应用程序是否属于联合运营的应用程序;当所述应用程序属于联合运营的应用程序时,将所述应用程序确定为所述目标应用程序。
- 根据权利要求6所述的方法,其特征在于,所述当所述应用程序属于联合运营的应用程序时,将所述应用程序确定为所述目标应用程序,包括:当所述应用程序属于所述联合运营的应用程序时,判断所述应用程序是否为游戏类应用程序;当所述应用程序为游戏类应用程序时,将所述应用程序确定为所述目标应用程序。
- 一种支付处理方法,其特征在于,应用于服务器,所述方法包括:所述服务器接收电子设备发送的待处理事件,所述待处理事件为所述电子设备在运行目标应用程序的过程中进入支付模式时,所调用的支付应用程序不合法时生成;响应所述待处理事件对所述目标应用程序进行处理。
- 根据权利要求8所述的方法,其特征在于,所述待处理事件包括所述目标应用程序的基本信息,所述响应所述待处理事件对所述目标应用程序进行处理,包括:响应所述待处理事件,基于所述基本信息对所述目标应用程序进行处理。
- 根据权利要求9所述的方法,其特征在于,所述响应所述待处理事件,基于所述基本信息对所述目标应用程序进行处理,包括:将所述基本信息发送至第一测试设备,所述基本信息用于指示所述第一测试设备基于所述基本信息安装所述目标应用程序,以对所述目标应用程序的支付过程进行复现,并在所述目标应用程序的支付过程复现成功时进行取证。
- 根据权利要求9或10所述的方法,其特征在于,所述基本信息至少包括包名。
- 根据权利要求10所述的方法,其特征在于,所述待处理事件还包括所述电子设备的第一标识信息,所述方法还包括:当所述目标应用程序的支付过程复现失败时,确定与所述第一标识信息对应的第二测试设备;将所述基本信息发送至所述第二测试设备,所述基本信息用于指示所述第二测试设备基于所述基本信息安装所述目标应用程序,以对所述目标应用程序的支付过程进行复现,并在所述目标应用程序的支付过程复现成功时进行取证。
- 根据权利要求12所述的方法,其特征在于,所述第一标识信息包括机型,所述当所述目标应用程序的支付过程复现失败时,确定与所述第一标识信息对应的第二测试设备,包括:当所述目标应用程序的支付过程复现失败时,基于所述机型确定与所述电子设备的机型一致的电子设备作为所述第二测试设备。
- 根据权利要求12或13所述的方法,其特征在于,所述待处理事件还包括所述电子设备的第二标识信息,所述方法还包括:当所述目标应用程序的支付过程复现失败时,确定与所述第一标识信息和第二标识信息对应的第三测试设备;将所述基本信息发送至所述第三测试设备,所述基本信息用于指示所述第三测试设备基于所述基本信息安装所述目标应用程序,以对所述目标应用程序的支付过程进行复现,并在所述目标应用程序的支付过程复现成功时进行取证。
- 根据权利要求14所述的方法,其特征在于,所述第一标识信息包括机型,所述第二标识信息包括网络协议IP地址,所述当所述目标应用程序的支付过程复现失败时,确定与所述第一标识信息和第二标识信息对应的第三测试设备,包括:当所述目标应用程序的支付过程复现失败时,基于所述机型和所述IP地址确定与所述电子设备机型一致且处于同一城市的电子设备作为所述第三测试设备。
- 一种支付处理方法,其特征在于,应用于支付处理系统,所述支付处理系统包括连接的电子设备和服务器,所述方法包括:所述电子设备在运行目标应用程序的过程中进入支付模式时,获取所调用的支付应用程序的属性信息;所述电子设备基于所述属性信息判断所述支付应用程序是否合法;当所述支付应用程序不合法时,所述电子设备生成待处理事件;所述电子设备将所述待处理事件发送至服务器;所述服务器响应所述待处理器事件对所述目标应用程序进行处理。
- 一种支付处理装置,其特征在于,应用于电子设备,所述装置包括:属性信息获取模块,用于所述电子设备在运行目标应用程序的过程中进入支付模式时,获取所调用的支付应用程序的属性信息;属性信息判断模块,用于基于所述属性信息判断所述支付应用程序是否合法;待处理事件生成模块,用于当所述支付应用程序不合法时,生成待处理事件;待处理事件发送模块,用于将所述待处理事件发送至服务器,所述待处理器事件用于指示所述服务器对所述目标应用程序进行处理。
- 一种支付处理装置,其特征在于,应用于服务器,所述装置包括:待处理事件接收模块,用于所述服务器接收电子设备发送的待处理事件,所述待处理事件为所述电子设备在运行目标应用程序的过程中进入支付模式时,所调用的支付应用程序不合法时生成;待处理事件响应模块,用于响应所述待处理事件对所述目标应用程序进行处理。
- 一种电子设备,其特征在于,包括存储器和处理器,所述存储器耦接到所述处理器,所述存储器存储指令,当所述指令由所述处理器执行时所述处理器执行如权利要求1-7任一项或如权利要求8-15任一项所述的方法。
- 一种计算机可读取存储介质,其特征在于,所述计算机可读取存储介质中存储有程序代码,所述程序代码可被处理器调用执行如权利要求1-7任一项或如权利要求8-15任一项所述的方法。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201980099276.0A CN114222988A (zh) | 2019-09-29 | 2019-09-29 | 支付处理方法、装置、电子设备以及存储介质 |
PCT/CN2019/109215 WO2021056571A1 (zh) | 2019-09-29 | 2019-09-29 | 支付处理方法、装置、电子设备以及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2019/109215 WO2021056571A1 (zh) | 2019-09-29 | 2019-09-29 | 支付处理方法、装置、电子设备以及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2021056571A1 true WO2021056571A1 (zh) | 2021-04-01 |
Family
ID=75165430
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2019/109215 WO2021056571A1 (zh) | 2019-09-29 | 2019-09-29 | 支付处理方法、装置、电子设备以及存储介质 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN114222988A (zh) |
WO (1) | WO2021056571A1 (zh) |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102081722A (zh) * | 2011-01-04 | 2011-06-01 | 奇智软件(北京)有限公司 | 一种保护指定应用程序的方法及装置 |
CN104021339A (zh) * | 2014-06-10 | 2014-09-03 | 北京奇虎科技有限公司 | 移动终端的安全支付方法及装置 |
US20150348015A1 (en) * | 2012-12-19 | 2015-12-03 | Deutsche Telekom Ag | Method and system for terminal device-based communication between third-party applications and an electronic wallet |
CN105303100A (zh) * | 2015-09-30 | 2016-02-03 | 北京奇虎科技有限公司 | 应用程序启动的验证方法及装置 |
-
2019
- 2019-09-29 WO PCT/CN2019/109215 patent/WO2021056571A1/zh active Application Filing
- 2019-09-29 CN CN201980099276.0A patent/CN114222988A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102081722A (zh) * | 2011-01-04 | 2011-06-01 | 奇智软件(北京)有限公司 | 一种保护指定应用程序的方法及装置 |
US20150348015A1 (en) * | 2012-12-19 | 2015-12-03 | Deutsche Telekom Ag | Method and system for terminal device-based communication between third-party applications and an electronic wallet |
CN104021339A (zh) * | 2014-06-10 | 2014-09-03 | 北京奇虎科技有限公司 | 移动终端的安全支付方法及装置 |
CN105303100A (zh) * | 2015-09-30 | 2016-02-03 | 北京奇虎科技有限公司 | 应用程序启动的验证方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
CN114222988A (zh) | 2022-03-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10445482B2 (en) | Identity authentication method, identity authentication device, and terminal | |
US10726068B2 (en) | App processing method and apparatus | |
CN107643977B (zh) | 防沉迷的方法及相关产品 | |
CN106649010B (zh) | 一种终端设备测试方法及终端设备 | |
CN107436748B (zh) | 处理第三方应用消息的方法、装置、终端设备及可读介质 | |
CN106375774B (zh) | 一种直播间显示内容控制的方法、装置和系统 | |
CN108243282A (zh) | 消息显示方法、装置、移动终端及存储介质 | |
CN109040419B (zh) | 录屏方法、装置、移动终端及存储介质 | |
CN104581221A (zh) | 视频直播的方法和装置 | |
CN107506646B (zh) | 恶意应用的检测方法、装置及计算机可读存储介质 | |
WO2019007371A1 (zh) | 一种防止信息被盗的方法、存储设备及移动终端 | |
CN108710458A (zh) | 一种分屏控制方法和终端设备 | |
WO2017114029A1 (zh) | 一种信息展示方法、装置及电子设备 | |
TW201518977A (zh) | 應用安全驗證方法、應用伺服器、應用用戶端及系統 | |
TWI514258B (zh) | 語音管理方法及系統,及其電腦程式產品 | |
CN109582565A (zh) | 防止应用崩溃的方法、终端及计算机存储介质 | |
CN108984231A (zh) | 一种应用程序账号的登录方法及移动终端 | |
JP2021072625A (ja) | 新しい人を紹介するビデオ通話の通話時間による課金を公平に行う方法およびシステム | |
CN108346031B (zh) | 一种数据交互方法及系统 | |
CN104750418B (zh) | 触摸操作区域长按操作的识别方法及装置 | |
WO2021184966A1 (zh) | 证件照检测方法、装置、电子设备以及存储介质 | |
WO2021056571A1 (zh) | 支付处理方法、装置、电子设备以及存储介质 | |
CN109978541A (zh) | 移动支付方法、终端以及计算机可读存储介质 | |
CN109246259A (zh) | 一种终端交互方法、终端及计算机可读存储介质 | |
CN105577621B (zh) | 一种业务操作验证方法、装置以及系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 19946836 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 19946836 Country of ref document: EP Kind code of ref document: A1 |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 19946836 Country of ref document: EP Kind code of ref document: A1 |