Payment event processing method and device, equipment and storage medium
By obtaining the payment information of the payment event and determining the target recognition based on the call information and payment amount, we can determine whether the payment event is abnormal, and solve the problem of user input errors when electronically paying mobile phone bills, realizing the timely detection and handling of abnormal payment events, improving the user experience.
Patent Information
- Application Number
- CN202411844410.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-13
- Publication Date
- 2025-03-14
AI Technical Summary
When users pay their mobile phone bills electronically, manually entering the payment phone number is prone to input errors, which leads to users being unable to discover payment errors in time, causing losses and reducing user experience.
By obtaining the payment information of the payment event, including the payment number, payment number and payment amount, based on the call information between the first user to which the payment number belongs and the second user to which the payment number belongs, the target recognition degree between the first user and the second user to which the payment number belongs, determines whether the payment event is abnormal, and issues a warning in a timely manner.
It effectively avoids the occurrence of payment errors, improves the user experience, promptly detects and handles abnormal payment events, and reduces users' economic losses.
Smart Images
Figure CN119629279A_ABST
Abstract
Description
Technical Field
[0001] The present application belongs to the field of information processing technology, and in particular, relates to a payment event processing method, device, equipment, storage medium and computer program product. Background Art
[0002] With the development of science and technology, electronic payment methods have gradually become an indispensable part of people's daily lives, greatly facilitating people's lives. In actual application scenarios where users pay for mobile phone bills electronically, users are often required to manually enter the phone number for payment, which may result in incorrect number input. Most users are unable to detect payment errors in time, making it difficult to recover the fees in time, resulting in losses and reducing user experience.
[0003] Therefore, there is an urgent need for a method for handling electronic payment events to promptly detect abnormal payment events, avoid losses to users caused by payment errors, and improve user experience. Summary of the invention
[0004] The embodiments of the present application provide a payment event processing method, apparatus, device, storage medium and computer program product, which can promptly detect abnormal payment events and avoid the occurrence of payment errors.
[0005] In a first aspect, an embodiment of the present application provides a payment event processing method, the method comprising:
[0006] Obtain payment information of payment events, including payment number, payment number and payment amount;
[0007] Based on the call information and payment amount between the first user to which the payment number belongs and the second user to which the payment number belongs, determining the target acquaintance between the first user and the second user; the target acquaintance is used to characterize the probability that the first user and the second user have an acquaintance relationship;
[0008] The target familiarity is compared with the preset threshold to make an abnormal judgment on the payment event and obtain the target judgment result.
[0009] In a second aspect, an embodiment of the present application provides a payment event processing device, the device comprising:
[0010] The acquisition module is used to obtain the payment information of the payment event, and the payment information includes the payment number, payment number and payment amount;
[0011] A determination module, used to determine the target familiarity between the first user and the second user based on the call information and payment amount between the first user to which the payment number belongs and the second user to which the payment number belongs; the target familiarity is used to represent the probability that the first user and the second user have an acquaintance relationship;
[0012] The judgment module is used to compare the target familiarity with a preset threshold to make an abnormal judgment on the payment event and obtain a target judgment result.
[0013] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the payment event processing method of the first aspect is implemented.
[0014] In a fourth aspect, an embodiment of the present application provides a computer storage medium having computer program instructions stored thereon, and when the computer program instructions are executed by a processor, the payment event processing method of the first aspect is implemented.
[0015] In a fifth aspect, an embodiment of the present application provides a computer program product. When the instructions in the computer program product are executed by a processor of an electronic device, the electronic device executes the payment event processing method as in the first aspect.
[0016] The payment event processing method, apparatus, device, storage medium and computer program product of the embodiments of the present application obtain payment information of the payment event, including the payment number, the payment number and the payment amount, and determine the target acquaintance between the first user and the second user based on the call information between the first user to which the payment number belongs and the second user to which the payment number belongs, as well as the payment amount. That is, the degree of acquaintance between the first user and the second user is determined through information on the call contact that has occurred between the first user and the second user, and then whether the payment event is abnormal is judged based on the degree of acquaintance between the first user and the second user, that is, the target acquaintance. If the degree of acquaintance between the first user and the second user is low, it can be considered that the payment event may be abnormal, so that an early warning is issued in time to avoid the occurrence of abnormal payment events such as incorrect entry of the payment number, thereby improving the user experience. BRIEF DESCRIPTION OF THE DRAWINGS
[0017] In order to more clearly illustrate the technical solution of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.
[0018] Figure 1 It is a structural diagram of a payment event processing system provided by an embodiment of the present application;
[0019] Figure 2 It is a flowchart of a payment event processing method provided by an embodiment of the present application;
[0020] Figure 3is a flowchart of a payment event processing method provided by another embodiment of the present application;
[0021] Figure 4 It is a structural diagram of a payment event processing device provided by an embodiment of the present application;
[0022] Figure 5 It is a schematic diagram of the structure of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION
[0023] The features and exemplary embodiments of various aspects of the present application will be described in detail below. In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, rather than to limit the present application. For those skilled in the art, the present application can be implemented without the need for some of these specific details. The following description of the embodiments is only to provide a better understanding of the present application by illustrating the examples of the present application.
[0024] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or equipment including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or equipment. In the absence of further restrictions, the elements defined by the statement "include..." do not exclude the existence of other identical elements in the process, method, article or equipment including the elements.
[0025] With the development of science and technology, electronic payment methods have gradually become an indispensable part of people's daily lives, greatly facilitating people's lives. In actual application scenarios where users pay for mobile phone bills electronically, users are often required to manually enter the phone number for payment, which may result in incorrect number input. Most users are unable to detect payment errors in time, making it difficult to recover the fees in time, resulting in losses and reducing user experience.
[0026] Therefore, there is an urgent need for a method for handling electronic payment events to promptly detect abnormal payment events, avoid losses to users caused by payment errors, and improve user experience.
[0027] In order to solve the problems of the prior art, the embodiments of the present application provide a payment event processing method, device, equipment, storage medium and computer program product. By obtaining payment information of a payment event, including a payment number, a payment number and a payment amount, the target acquaintance between the first user to which the payment number belongs and the second user to which the payment number belongs and the payment amount are determined, that is, the degree of acquaintance between the first user and the second user is determined through the information of the call contact that has occurred between the first user and the second user, and then whether the payment event is abnormal is judged according to the degree of acquaintance between the first user and the second user, that is, the target acquaintance. If the degree of acquaintance between the first user and the second user is low, it can be considered that the payment event may be abnormal, so that an early warning is issued in time to avoid the occurrence of abnormal payment events such as wrong payment number input, thereby improving user experience.
[0028] The following first introduces the payment event processing system provided in the embodiment of the present application.
[0029] Figure 1 FIG. 1 is a flow chart of a payment event processing system provided by an embodiment of the present application. Figure 1 As shown, the payment event processing system 100 may include a data collection module 101 , a data warehouse module 102 , an exception judgment module 103 and an exception processing module 104 .
[0030] The data collection module 101 is used for data collection and query of the first user and the second user. The data collection module 101 works at the beginning of the payment stage. If the first user authorizes the module or the first user has uploaded personal address book information, the data collection module 101 can query the unique identity corresponding to the current first user's billing number, and query the unique identity of the second user corresponding to the address book number. If the payment number and payment number of the first user and the second user have a circle of contacts record on the operator side, the acquaintance relationship between the first user and the second user is marked, and the acquired data is entered into the data warehouse module 102.
[0031] The data warehouse module 102 is used to record the acquaintance relationship between the first user of the payment number and the second user to whom the payment number belongs. The data warehouse module 102 serves as the data recording center of the payment event processing system 100 and stores basic data of the first user and the second user, including the payment number of the first user, all other numbers under the name of the first user, the payment number of the second user and all other numbers under the name of the second user, and the degree of acquaintance between the first user and the second user.
[0032] The abnormality judgment module 103 is used to receive data sent by the data collection module 101 and the data warehouse module 102, calculate the acquaintance between the first user to which the payment number belongs and the second user to which the payment number belongs, and judge whether the payment event is abnormal based on the acquaintance between the first user and the second user.
[0033] The exception handling module 104 is used to receive the judgment result sent by the exception judgment module 103, and to perform an early warning operation on the payment event with an abnormal judgment result. In the case of an abnormal payment event, the exception handling module 104 will firstly pop up a confirmation window when the first user confirms the payment, reminding the first user to check whether the payment number is confirmed. If the user enters a confirmation operation indicating that the payment number is correct, a buffer time will be set after the payment is completed, and a prompt message will be sent to the first user and the second user. If the payment needs to be credited immediately, the first user can perform a confirmation operation to execute the payment immediately; if the payment number is wrong, the confirmation operation indicating that the payment number is wrong can be entered to cancel the payment behavior, and the system will automatically process the refund. If no operation is performed within the buffer time, the fee will be credited after the buffer time, and if no complaint information from the first user is received within the preset time after the fee is credited, the second user will be marked as a trusted user and stored in the data warehouse module 102, and no early warning will be issued later.
[0034] The following is an introduction to the payment event processing method provided in the embodiment of the present application.
[0035] Figure 2 FIG. 1 is a flow chart showing a method for processing a payment event provided by an embodiment of the present application. Figure 2 As shown, the method may include the following steps: S201 to S203.
[0036] S201: Obtain payment information of a payment event, where the payment information may include a payment number, a payment number, and a payment amount.
[0037] A payment event indicates a behavior event in which a user A uses his payment account to pay a certain amount of phone charges for the number of another user B. In a payment event, the payment number can represent the payment account of user A, the payment number can represent the number of user B, and the payment amount represents the amount of phone charges paid by user A for user B.
[0038] In some embodiments, obtaining payment information of a payment event may be accomplished through the data collection module 101 .
[0039] S202: Determine a target familiarity between the first user and the second user based on call information and payment amount between the first user to whom the payment number belongs and the second user to whom the payment number belongs.
[0040] The first user represents user A, and the second user represents user B. The call information represents the information of the call contact between the first user and the second user. The target acquaintance degree can be used to represent the probability that the first user and the second user have an acquaintance relationship.
[0041] Based on the call information and payment amount between the first user and the second user, that is, through the information of the call contact between the first user and the second user, the degree of acquaintance between the first user and the second user is determined, and then based on the degree of acquaintance between the two users, it is judged whether the payment event is abnormal. In the case that the degree of acquaintance between the two users is low, it can be considered that the payment event may be abnormal, so as to issue an early warning in time to avoid the occurrence of abnormal payment events such as entering the wrong payment number, thereby improving the user experience.
[0042] In some embodiments, the call information may include the number of first numbers that the first user has contacted with the premium number, the number of contacts between each first number and the premium number within a first preset time period, and the average call duration between each first number and the premium number within the first preset time period.
[0043] The first number indicates a number that has had a call with the second user among all the numbers under the first user name. The first preset time can be set manually, for example, the first preset time can be one month.
[0044] In some embodiments, based on the call information and payment amount between the first user to which the payment number belongs and the second user to which the payment number belongs, determining the target familiarity between the first user and the second user can be accomplished by the abnormality judgment module 103 .
[0045] S203: Compare the target familiarity with a preset threshold to make an abnormal judgment on the payment event and obtain a target judgment result.
[0046] The information of the call contacts between the first user and the second user can characterize the degree of acquaintance between the first user and the second user to a certain extent. When the degree of acquaintance between the first user and the second user is high, it can be considered that it is reasonable for the first user to pay for the second user; and when the degree of acquaintance between the first user and the second user is low, it can be considered that it may be unreasonable for the first user to pay for the second user. In this way, by making an abnormal judgment on the payment event based on the target acquaintance, an accurate target judgment result can be obtained.
[0047] In some embodiments, the payment event is judged abnormal based on the target familiarity by comparing the target familiarity with a preset threshold, and when the target familiarity is less than the preset threshold, the target judgment result is determined to be an abnormal payment event. The preset threshold can be set manually.
[0048] In some embodiments, the payment event is judged to be abnormal according to the target familiarity to obtain the target judgment result, which can be completed by the abnormal judgment module 103.
[0049] The embodiment of the present application obtains payment information of a payment event, including a payment number, a payment number and a payment amount, and determines a target acquaintance between the first user and the second user based on call information between the first user to whom the payment number belongs and the second user to whom the payment number belongs, as well as the payment amount. That is, the degree of acquaintance between the first user and the second user is determined through information on call contact that has occurred between the first user and the second user. Then, whether the payment event is abnormal is judged based on the degree of acquaintance between the first user and the second user, that is, the target acquaintance. If the degree of acquaintance between the first user and the second user is low, it can be considered that the payment event may be abnormal, so that an early warning is issued in time to avoid the occurrence of abnormal payment events such as incorrect entry of a payment number, thereby improving user experience.
[0050] In some embodiments, step S202: determining the target familiarity between the first user and the second user based on the call information and payment amount between the first user to which the payment number belongs and the second user to which the payment number belongs may include:
[0051] Determining a first acquaintance corresponding to the call information from a correlation between the call information and the acquaintance;
[0052] Determine a second degree of familiarity corresponding to the payment amount from the correlation between the payment amount and the degree of familiarity;
[0053] A target acquaintance between the first user and the second user is determined according to the first acquaintance and the second acquaintance.
[0054] The correlation between the call information and the acquaintance degree may be a positive correlation. Specifically, when the call information shows that the first user and the second user have frequent contacts, it can be considered that the first user and the second user have a high acquaintance degree; when the call information shows that the first user and the second user have few contacts, it can be considered that the first user and the second user have a low acquaintance degree.
[0055] The correlation between the payment amount and the acquaintance can be a negative correlation. Specifically, when the payment amount is larger, it can be considered that the risk of the first user paying for the second user is higher, and the acquaintance between the first user and the second user needs to be more vigilant; when the payment amount is smaller, it can be considered that the risk of the first user paying for the second user is lower, and the impact of the payment amount on the acquaintance between the first user and the second user is smaller.
[0056] The target familiarity between the first user and the second user is jointly determined based on the call information and the payment amount, and factors affecting the target familiarity between the first user and the second user are comprehensively considered, so that a more accurate target familiarity can be obtained.
[0057] In some embodiments, step S202: determining the target familiarity between the first user and the second user based on the call information and payment amount between the first user to which the payment number belongs and the second user to which the payment number belongs may include:
[0058] Obtaining a third degree of familiarity between the first user and the second user according to the number of first numbers that the first user has contacted with the paid number, the number of contacts, and the average call duration;
[0059] The target acquaintance between the first user and the second user is determined according to the third acquaintance and the payment amount.
[0060] The number of first numbers that the first user has contacted with the paid number, the number of contacts and the average call duration can more truly reflect the frequency of calls between the first user and the second user. The third acquaintance between the first user and the second user is obtained based on the number of first numbers that the first user has contacted with the paid number, the number of contacts and the average call duration. The target acquaintance between the first user and the second user is then determined in combination with the payment amount, so that a more accurate target acquaintance can be obtained.
[0061] In some embodiments, obtaining the third degree of familiarity between the first user and the second user based on the number of first numbers that the first user has contacted with the premium number, the number of contacts, and the average call duration may include:
[0062] The product of the number of first numbers that the first user has contacted with the paid number, the number of contacts and the average call duration is calculated to obtain a third degree of acquaintance between the first user and the second user.
[0063] In some embodiments, determining the target familiarity between the first user and the second user based on the third familiarity and the payment amount may include:
[0064] The quotient of the third acquaintance and the payment amount is calculated to obtain the target acquaintance between the first user and the second user.
[0065] As an example, based on the call information and payment amount between the first user to whom the payment number belongs and the second user to whom the payment number belongs, the target familiarity between the first user and the second user is determined, which can be shown as follows:
[0066] n= (N*P*L) / M (1)
[0067] Among them, n is the target acquaintance, M is the payment amount, P is the number of first numbers that the first user has contacted with the payment number, N is the number of contacts between the first number and the payment number within the first preset time period, and L is the average call duration between the first number and the payment number within the first preset time period.
[0068] In some embodiments, in order to remind the first user whether the payment number is correct and to promptly issue an early warning for abnormal payment events, such as Figure 3 As shown, based on any of the above embodiments, the payment event processing method may further include the following steps: S301 to S302.
[0069] S301: When the target judgment result is that the payment event is abnormal, display a first prompt message, and the first prompt message is used to remind the first user whether the payment number is correct.
[0070] S302: When a confirmation operation indicating that the payment number is correct is received, the payment amount corresponding to the payment event is credited to the account after a preset buffered credit time.
[0071] The abnormal payment event indicates that the acquaintance between the first user and the second user does not meet the preset conditions, and the payment number entered by the first user may be wrong. By displaying the first prompt information, the first user can be reminded in time to check the payment number to avoid fee losses caused by incorrect payment number entry.
[0072] When the first user clicks to confirm that the payment number is correct and continues to complete the payment, a buffer time for the payment can be set after the first user completes the payment. If no operation is performed within the preset buffer time, the fees corresponding to the payment amount will be credited after the buffer time ends.
[0073] As an example, displaying the first prompt information may be displaying the first prompt information in a pop-up window on the payment interface of the first user.
[0074] In some embodiments, the above steps S301 to S302 may be completed by the exception handling module 104 .
[0075] In some embodiments, in order to speed up the payment progress, before the preset buffering time ends, a confirmation operation indicating that the first user will immediately execute the payment can be received, so that the fee corresponding to the payment amount is immediately credited. Among them, the buffering time can be set manually, which will not be repeated here.
[0076] In some embodiments, in order to facilitate the first user and the second user to verify the payment event, after the fees corresponding to the payment amount are received, a second prompt message can also be sent to the first user and the second user. The second prompt message is used to notify the first user and the second user of the payment number and payment number corresponding to the payment event.
[0077] In some embodiments, in step S302: when a confirmation operation indicating that the payment number is correct is received, after the payment amount corresponding to the payment event is credited after a preset buffered credit time, the payment event processing method may further include:
[0078] Query whether complaint information from the first user is received within a second preset time period;
[0079] When no complaint information from the first user is received within the second preset time period, the second user to whom the payment number belongs is marked as a trusted user.
[0080] The complaint information may indicate feedback information of a poor first user experience caused by an abnormal payment event.
[0081] If no complaint information is received from the first user within the second preset time period, it indicates that the payment event is normal and the payment number is correct. In this case, the second user to whom the payment number belongs can be marked as a trusted user. When the first user enters the payment number next time, the payment event abnormality judgment will no longer be made for the payment number of the second user, thereby improving payment efficiency while ensuring that no abnormalities occur in the payment event.
[0082] As an example, marking the second user to which the payment number belongs as a trusted user may be performed by adding the identity identifier corresponding to the second user to which the payment number belongs to a whitelist.
[0083] In some embodiments, based on any of the above embodiments, the payment event processing method may further include:
[0084] When a confirmation operation indicating that the payment number is wrong is received, the fee corresponding to the payment amount is refunded to the payment number.
[0085] When the first user finds that the payment number is wrong, he can input a confirmation operation indicating that the payment number is wrong. The payment event processing system will refund the fee corresponding to the payment amount to the payment number, which can timely avoid the first user's fee loss.
[0086] Figure 4 4 is a schematic diagram of the structure of a payment event processing device 400 provided in an embodiment of the present application. Figure 4 As shown, the device may include an acquisition module 410 , a determination module 420 , and a judgment module 430 .
[0087] The acquisition module 410 is used to acquire payment information of the payment event, where the payment information includes a payment number, a payment number and a payment amount;
[0088] The determination module 420 is used to determine the target familiarity between the first user and the second user based on the call information and payment amount between the first user to which the payment number belongs and the second user to which the payment number belongs; the target familiarity is used to represent the probability that the first user and the second user have an acquaintance relationship;
[0089] The judgment module 430 is used to compare the target familiarity with a preset threshold value to make an abnormal judgment on the payment event and obtain a target judgment result.
[0090] The embodiment of the present application obtains payment information of a payment event, including a payment number, a payment number and a payment amount, and determines a target acquaintance between the first user and the second user based on call information between the first user to whom the payment number belongs and the second user to whom the payment number belongs, as well as the payment amount. That is, the degree of acquaintance between the first user and the second user is determined through information on call contact that has occurred between the first user and the second user. Then, whether the payment event is abnormal is judged based on the degree of acquaintance between the first user and the second user, that is, the target acquaintance. If the degree of acquaintance between the first user and the second user is low, it can be considered that the payment event may be abnormal, so that an early warning is issued in time to avoid the occurrence of abnormal payment events such as incorrect entry of a payment number, thereby improving user experience.
[0091] In some embodiments, the determination module 420 is further configured to determine a first acquaintance corresponding to the call information from the correlation between the call information and the acquaintance;
[0092] The determination module 420 is further used to determine a second familiarity corresponding to the payment amount from the correlation between the payment amount and the familiarity;
[0093] The determination module 420 is further configured to determine a target familiarity between the first user and the second user according to the first familiarity and the second familiarity.
[0094] In some embodiments, the call information includes the number of first numbers that the first user has contacted with the premium number, the number of contacts between each first number and the premium number within a first preset time period, and the average call duration between each first number and the premium number within the first preset time period.
[0095] In some embodiments, the determination module 420 is further configured to obtain a third degree of familiarity between the first user and the second user based on the number of first numbers that the first user has contacted with the premium number, the number of contacts, and the average call duration;
[0096] The determination module 420 is further configured to determine a target familiarity between the first user and the second user according to the third familiarity and the payment amount.
[0097] In some embodiments, the payment event processing device 400 further includes a calculation module;
[0098] The calculation module is used to calculate the product of the number of first numbers that the first user has contacted with the paid number, the number of contacts and the average call duration, and obtain the third acquaintance between the first user and the second user.
[0099] In some embodiments, the calculation module is further used to calculate a quotient of the third acquaintance and the payment amount to obtain a target acquaintance between the first user and the second user.
[0100] In some embodiments, the payment event processing device 400 further includes a display module and a payment module;
[0101] A display module, used for displaying a first preset prompt message when the target judgment result is that the payment event is abnormal, and the first prompt message is used to remind the first user whether the payment number is correct;
[0102] The payment module is used to, upon receiving a confirmation operation indicating that the payment number is correct, deposit the payment amount corresponding to the payment event after a preset buffer arrival time.
[0103] In some embodiments, the payment event processing device 400 further includes a query module and a marking module;
[0104] A query module, configured to, upon receiving a confirmation operation indicating that the payment number is correct, query whether complaint information of the first user is received within a second preset time period after the payment amount corresponding to the payment event is credited after a preset buffered credit time;
[0105] The marking module is used to mark the second user to which the payment number belongs as a trusted user when no complaint information from the first user is received within a second preset time period.
[0106] In some embodiments, the payment module is further used to refund the fee corresponding to the payment amount to the payment number upon receiving a confirmation operation indicating that the payment number is wrong.
[0107] Figure 4 The various modules in the device shown can be implemented Figure 2 Each step in the above steps can achieve the corresponding technical effect, which will not be repeated here for the sake of brevity.
[0108] Figure 5 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application is shown.
[0109] The electronic device may include a processor 501 and a memory 502 storing computer program instructions.
[0110] Specifically, the processor 501 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.
[0111] The memory 502 may include a large capacity memory for data or instructions. By way of example and not limitation, the memory 502 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive or a combination of two or more of these. In appropriate cases, the memory 502 may include a removable or non-removable (or fixed) medium. In appropriate cases, the memory 502 may be inside or outside the integrated gateway disaster recovery device. In a specific embodiment, the memory 502 is a non-volatile solid-state memory.
[0112] In certain embodiments, the memory may include a read-only memory (ROM), a random access memory (RAM), a magnetic disk storage medium device, an optical storage medium device, a flash memory device, an electrical, optical or other physical / tangible memory storage device. Thus, typically, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., a memory device) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of the present application.
[0113] The processor 501 implements any one of the payment event processing methods in the above embodiments by reading and executing the computer program instructions stored in the memory 502 .
[0114] In one example, the electronic device may further include a communication interface 503 and a bus 510. Figure 5 As shown, the processor 501, the memory 502, and the communication interface 503 are connected via a bus 510 and communicate with each other.
[0115] The communication interface 503 is mainly used to implement communication between various modules, devices, units and / or equipment in the embodiments of the present application.
[0116] Bus 510 includes hardware, software or both, and the parts of electronic equipment are coupled to each other. For example, but not limitation, bus may include accelerated graphics port (AGP) or other graphics bus, enhanced industrial standard architecture (EISA) bus, front side bus (FSB), hypertransport (HT) interconnection, industrial standard architecture (ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations. In appropriate cases, bus 510 may include one or more buses. Although the present application embodiment describes and shows a specific bus, the application considers any suitable bus or interconnection.
[0117] In addition, in combination with the payment event processing method in the above embodiment, the embodiment of the present application can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when the computer program instructions are executed by the processor, any one of the payment event processing methods in the above embodiment is implemented.
[0118] An embodiment of the present application also provides a computer program product, including a computer program, which, when executed, implements any one of the payment event processing methods in the above embodiments.
[0119] It should be clear that the present application is not limited to the specific configuration and processing described above and shown in the figures. For the sake of simplicity, a detailed description of the known method is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present application is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present application.
[0120] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware or a combination thereof. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (ASIC), appropriate firmware, a plug-in, a function card, etc. When implemented in software, the elements of the present application are programs or code segments that are used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link by a data signal carried in a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, etc. The code segment can be downloaded via a computer network such as the Internet, an intranet, etc.
[0121] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or devices. However, this application is not limited to the order of the above steps, that is, the steps can be performed in the order mentioned in the embodiment, or in a different order from the embodiment, or several steps can be performed simultaneously.
[0122] The above reference is to the flowchart and / or block diagram of the method, device, equipment, storage medium and computer program product according to the embodiment of the present application. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine so that these instructions executed by the processor of the computer or other programmable data processing device enable the implementation of the function / action specified in one or more boxes of the flowchart and / or block diagram. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor or a field programmable logic circuit. It can also be understood that each box in the block diagram and / or flowchart and the combination of boxes in the block diagram and / or flowchart can also be implemented by dedicated hardware that performs a specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions.
[0123] The above is only a specific implementation of the present application. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here. It should be understood that the protection scope of the present application is not limited to this. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in the present application, and these modifications or replacements should be included in the protection scope of the present application.
Claims
1. A payment event processing method, characterized in that: include: Obtain payment information of a payment event, wherein the payment information includes a payment number, a payment number, and a payment amount; Determining a target familiarity between the first user and the second user based on call information between the first user to which the payment number belongs and the second user to which the payment number belongs and the payment amount; The target acquaintance degree is used to represent the probability that the first user and the second user have an acquaintance relationship; The target familiarity is compared with a preset threshold value to make an abnormal judgment on the payment event and obtain a target judgment result.
2. The method according to claim 1, characterized in that: The determining the target familiarity between the first user and the second user based on the call information between the first user to which the payment number belongs and the second user to which the payment number belongs and the payment amount includes: Determining a first acquaintance corresponding to the call information from a correlation between the call information and the acquaintance; Determining a second degree of familiarity corresponding to the payment amount from the correlation between the payment amount and the degree of familiarity; A target acquaintance between the first user and the second user is determined according to the first acquaintance and the second acquaintance.
3. The method according to claim 1, characterized in that The call information includes the number of first numbers that the first user has contacted with the payment number, the number of contacts between each first number and the payment number within a first preset time period, and the average call duration between each first number and the payment number within the first preset time period.
4. The method according to claim 3, characterized in that The determining the target familiarity between the first user and the second user based on the call information between the first user to which the payment number belongs and the second user to which the payment number belongs and the payment amount includes: Obtaining a third degree of acquaintance between the first user and the second user according to the number of first numbers that the first user has contacted with the paid number, the number of contacts, and the average call duration; A target acquaintance between the first user and the second user is determined according to the third acquaintance and the payment amount.
5. The method according to claim 4, characterized in that The obtaining of the third acquaintance between the first user and the second user according to the number of first numbers that the first user has contacted with the paid number, the number of contacts and the average call duration includes: The product of the number of first numbers that the first user has contacted with the paid number, the number of contacts and the average call duration is calculated to obtain a third degree of acquaintance between the first user and the second user.
6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: When the target judgment result is that the payment event is abnormal, displaying a first prompt message, wherein the first prompt message is used to remind the first user whether the payment number is correct; When a confirmation operation indicating that the payment number is correct is received, the payment amount corresponding to the payment event is credited to the account after a preset buffered credit time.
7. The method according to claim 6, characterized in that In the case where a confirmation operation indicating that the payment number is correct is received, after the payment amount corresponding to the payment event is credited after a preset buffered credit time, the method further includes: Query whether complaint information of the first user is received within a second preset time period; In the case that no complaint information from the first user is received within the second preset time period, the second user to which the payment number belongs is marked as a trusted user.
8. A payment event processing device, characterized in that: The device comprises: An acquisition module, used to acquire payment information of a payment event, wherein the payment information includes a payment number, a payment number and a payment amount; a determination module, configured to determine a target acquaintance between the first user to which the payment number belongs and the second user to which the payment number belongs, based on call information between the first user to which the payment number belongs and the second user to which the payment number belongs and the payment amount; the target acquaintance is used to represent a probability that the first user and the second user have an acquaintance relationship; The judgment module is used to compare the target familiarity with a preset threshold value to make an abnormal judgment on the payment event and obtain a target judgment result.
9. An electronic device, characterized in that: The device comprises: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, the payment event processing method as described in any one of claims 1-7 is implemented.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed by the processor, the payment event processing method according to any one of claims 1 to 7 is implemented.