Payment method and device, electronic equipment and computer readable storage medium
By sending payment requests to the payment server and generating retry requests, the payment efficiency problem caused by payment exceptions is solved, efficient updates and retry of the payment process are achieved, and duplicate deductions are avoided.
Patent Information
- Application Number
- CN202410071380.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-01-17
- Publication Date
- 2025-07-18
AI Technical Summary
The existing payment method directly returns an error in the case of payment abnormality, causing the transaction object to repeatedly enter payment data, resulting in inefficient payment.
Send a payment request to the payment server, receive configuration information, generate payment data, and generate a retry request based on the reception status and retry configuration information to update the payment result.
Update payment results through payment retry requests, avoid repeated input of payment data, and improve the efficiency of the payment process.
Smart Images

Figure CN120338775A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of data interaction, and particularly to a payment method, apparatus, electronic device, and computer-readable storage medium. Background Art
[0002] In recent years, with the rapid development of Internet technology, payment methods relying on the Internet have become increasingly convenient. During the payment process, it is possible to encounter payment anomalies, and there can be various reasons for payment anomalies, such as network anomalies, request timeouts, interface errors, or system failures, etc. In the case of payment anomalies, current payment methods often directly return payment error messages.
[0003] During the research and practice of current technologies, the inventors of the present application found that directly returning payment error messages may cause the trading object to think that the payment has failed during the payment process, and then they will re-enter payment data for payment, resulting in situations such as duplicate deductions, and thus leading to low payment efficiency during the payment process. Summary of the Invention
[0004] Embodiments of the present application provide a payment method, apparatus, electronic device, and computer-readable storage medium, which can improve the payment efficiency during the payment process.
[0005] A payment method includes:
[0006] Sending a payment request to a payment server and receiving payment configuration information returned by the payment server based on the payment request, where the payment configuration information includes payment retry configuration information;
[0007] Generating payment data according to the payment configuration information and sending the payment data to the payment server so that the payment server returns the payment result of the payment data;
[0008] Determining the receiving status of the payment result and generating a payment retry request according to the receiving status and the payment retry configuration information, where the receiving status indicates the receiving situation of the payment result;
[0009] Sending the payment retry request to the payment server so that the payment server updates the payment result based on the payment retry request;
[0010] When receiving the updated payment result returned by the payment server, presenting the updated payment result.
[0011] Optionally, embodiments of the present application may also provide another payment method, including:
[0012] Receive a payment request sent by a target terminal, and generate payment configuration information corresponding to the target terminal based on the payment request;
[0013] Send the payment configuration information to the target terminal, and receive payment data returned by the target terminal based on the payment configuration information;
[0014] Determine the payment result of the payment data, and send the payment result to the target terminal;
[0015] When receiving a payment retry request returned by the target terminal, update the payment result;
[0016] Send the updated payment result to the target terminal so that the target terminal can display the updated payment result.
[0017] Correspondingly, an embodiment of the present application provides a payment device, including:
[0018] A first sending unit, configured to send a payment request to a payment server, and receive payment configuration information returned by the payment server based on the payment request, where the payment configuration information includes payment retry configuration information;
[0019] A generating unit, configured to generate payment data according to the payment configuration information, and send the payment data to the payment server so that the payment server returns the payment result of the payment data;
[0020] A first determining unit, configured to determine the receiving status of the payment result, and generate a payment retry request according to the receiving status and the payment retry configuration information, where the receiving status indicates the receiving situation of the payment result;
[0021] A second sending unit, configured to send the payment retry request to the payment server so that the payment server updates the payment result based on the payment retry request;
[0022] A display unit, configured to display the updated payment result when receiving the updated payment result returned by the payment server.
[0023] Optionally, an embodiment of the present application may further provide another payment device, including:
[0024] A first receiving unit, configured to receive a payment request sent by a target terminal, and generate payment configuration information corresponding to the target terminal based on the payment request;
[0025] A second receiving unit, configured to send the payment configuration information to the target terminal, and receive payment data returned by the target terminal based on the payment configuration information;
[0026] A second determination unit, configured to determine a payment result of the payment data and send the payment result to the target terminal;
[0027] An update unit, configured to update the payment result when receiving a payment retry request returned by the target terminal;
[0028] A third sending unit, configured to send the updated payment result to the target terminal so that the target terminal displays the updated payment result.
[0029] In some embodiments, the first determination unit may specifically be configured to generate a payment retry request according to the type of the payment result and payment retry configuration information when the reception status indicates that the payment result is received; and generate a payment retry request based on the payment retry configuration information when the reception status indicates that the payment result is not received.
[0030] In some embodiments, the first determination unit may specifically be configured to generate a payment retry request according to the payment retry configuration information when the payment result is not clear; and display the payment result based on the payment configuration information when the payment result is payment success or payment failure.
[0031] In some embodiments, the second sending unit may specifically be configured to generate target payment data based on the payment configuration information when receiving payment retry prompt information returned by the payment server; update the payment data based on the target payment data to obtain updated payment data; and send the updated payment data to the payment server so that the payment server updates the payment result based on the updated payment data.
[0032] In some embodiments, the second sending unit may specifically be configured to identify a payment retry count and an error message text from the payment retry configuration information when not receiving the updated payment result returned by the payment server; return to execute the step of generating a payment retry request according to the reception status and payment retry configuration information until the updated payment result is received or the payment retry count is reached; display the updated payment result when the updated payment result is received; and display the error message text when the updated payment result is not received.
[0033] In some embodiments, the generating unit may be specifically configured to display a data payment page, where the data payment page includes a payment data input control and a list of payment methods determined based on payment configuration information; in response to a selection operation on the list of payment methods, determine a target payment method, and receive initial payment data corresponding to the target payment method through the payment data input control; generate payment data corresponding to the payment request based on the target payment method and the initial payment data.
[0034] In some embodiments, the updating unit may be specifically configured to obtain the current payment record of the target terminal, and query the target payment record corresponding to the payment data in the current payment record; when the target payment record exists, determine the current payment result corresponding to the payment data based on the target payment record, and use the current payment result as the updated payment result; when the target payment record does not exist, generate a payment retry prompt message, and send the payment retry prompt message to the target terminal to obtain the updated payment result.
[0035] In addition, an embodiment of the present application further provides an electronic device, including a processor and a memory, where the memory stores an application program, and the processor is configured to run the application program in the memory to execute the payment method provided by the embodiment of the present application.
[0036] In addition, an embodiment of the present application further provides a computer-readable storage medium, where the computer-readable storage medium stores multiple instructions, and the instructions are suitable for being loaded by a processor to execute the steps in any of the payment methods provided by the embodiment of the present application.
[0037] In addition, an embodiment of the present application further provides a computer program product, including a computer program or instruction, and when the computer program or instruction is executed by a processor, the steps in the payment method provided by the embodiment of the present application are implemented.
[0038] After the embodiment of the present application sends a payment request to the payment server and receives the payment configuration information returned by the payment server based on the payment request, according to the payment configuration information, payment data is generated and sent to the payment server, so that the payment server returns the payment result of the payment data. Then, the receiving status of the payment result is determined, and according to the receiving status and the payment retry configuration information in the payment configuration information, a payment retry request is generated and sent to the payment server, so that the payment server updates the payment result based on the payment retry request. When receiving the updated payment result returned by the payment server, the updated payment result is displayed. Since this solution can generate a payment retry request according to the receiving status of the payment result and the payment retry configuration information in the case where payment anomalies may occur, the payment server updates the payment result through the payment retry request, so that the correct payment result can be obtained, avoiding the situation of re-entering payment data for re-payment and repeated deductions. Therefore, the payment efficiency in the payment process can be improved. BRIEF DESCRIPTION OF THE DRAWINGS
[0039] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those skilled in the art, without creative efforts, other drawings can be obtained based on these drawings.
[0040] Figure 1 It is a system schematic diagram of the payment system provided by the embodiment of the present application;
[0041] Figure 2 It is a scenario schematic diagram of the payment method provided by the embodiment of the present application;
[0042] Figure 3 It is a flow schematic diagram of the payment method provided by the embodiment of the present application;
[0043] Figure 4 It is a schematic diagram of the payment scenario provided by the embodiment of the present application;
[0044] Figure 5 It is another flow schematic diagram of the payment method provided by the embodiment of the present application;
[0045] Figure 6 It is another flow schematic diagram of the payment method provided by the embodiment of the present application;
[0046] Figure 7 It is a schematic diagram of the target terminal initiating payment in the social payment scenario provided by the embodiment of the present application;
[0047] Figure 8It is a schematic diagram of the processing flow when the target terminal does not receive the payment result in the social payment scenario provided by the embodiments of the present application;
[0048] Figure 9 It is a schematic diagram of the processing flow when the target terminal receives the payment result in the social payment scenario provided by the embodiments of the present application;
[0049] Figure 10 It is a schematic diagram of the overall process of the payment process provided by the embodiments of the present application;
[0050] Figure 11 It is a schematic diagram of the structure of the first payment device provided by the embodiments of the present application;
[0051] Figure 12 It is a schematic diagram of the structure of the second payment device provided by the embodiments of the present application;
[0052] Figure 13 It is a schematic diagram of the structure of the electronic device provided by the embodiments of the present application. Detailed implementation manners
[0053] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative efforts belong to the scope of protection of the present invention.
[0054] Embodiments of the present invention provide a payment method, apparatus, electronic device, and computer-readable storage medium. Among them, the payment apparatus may be integrated in the electronic device, and the electronic device may be a server or a terminal device, etc. Specifically, embodiments of the present invention provide a payment apparatus applicable to a first electronic device (which may be referred to as the first payment apparatus for distinction) and a payment apparatus applicable to a second electronic device (which may be referred to as the second payment apparatus for distinction). Among them, the first electronic device may be a terminal device, etc. The terminal includes, but is not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle-mounted terminals, aircraft, etc., but is not limited thereto. The second electronic device may be a network-side device such as a server. The server may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, network acceleration services (Content Delivery Network, CDN), and big data and artificial intelligence platforms. The terminal and the server may be directly or indirectly connected through wired or wireless communication methods, and this application does not limit this. Embodiments of the present invention can be applied to various scenarios, including but not limited to cloud technology, cloud security, artificial intelligence, intelligent transportation, assisted driving, etc.
[0055] Embodiments of the present invention take the first electronic device as the target terminal and the second electronic device as the payment server as an example to introduce the payment method.
[0056] For example, referring to Figure 1 , embodiments of the present invention provide a payment system including a target terminal 10 and a payment server 20; the target terminal 10 is connected to the payment server 20 through a network. For example, it can be connected through a wired or wireless network connection, etc. Among them, the payment apparatus may be integrated in the target terminal. For example, it is integrated in the target terminal in the form of a client.
[0057] Among them, the target terminal 10 can be used to send a payment request to the payment server 20, receive payment configuration information returned by the payment server 20 based on the payment request, generate payment data according to the payment configuration information, and send the payment data to the payment server 20, so that the payment server 20 returns the payment result of the payment data. Then, determine the reception status of the payment result, and generate a payment retry request according to the reception status and the payment retry configuration information in the payment configuration information, and send the payment retry request to the payment server 20, so that the payment server 20 updates the payment result based on the payment retry request. When receiving the updated payment result returned by the payment server 20, display the updated payment result, thereby improving the payment efficiency of the payment process. Specifically, it can be as Figure 2 shown.
[0058] Among them, the payment server 20 can be used to receive a payment request sent by the target terminal 10, generate payment configuration information corresponding to the target terminal 10 based on the payment request, send the payment configuration information to the target terminal 10, receive payment data returned by the target terminal 10 based on the payment configuration information, determine the payment result of the payment data, and send the payment result to the target terminal 10. When receiving a payment retry request returned by the target terminal 10, update the payment result and send the updated payment result to the target terminal, so that the target terminal can display the updated payment result, thereby improving the payment efficiency during the payment process.
[0059] Among them, the payment method provided in the embodiments of the present application involves artificial intelligence technology. The so-called artificial intelligence (AI) is to use a digital computer or a machine controlled by a digital computer to simulate, extend, and expand human intelligence, a theory, method, technology, and application system that perceives the environment, acquires knowledge, and uses knowledge to obtain the best results. In other words, artificial intelligence is a comprehensive technology in computer science that attempts to understand the essence of intelligence and produce a new intelligent machine that can react in a way similar to human intelligence. Artificial intelligence also studies the design principles and implementation methods of various intelligent machines, enabling the machines to have the functions of perception, reasoning, and decision-making.
[0060] Artificial intelligence technology is a comprehensive discipline that involves a wide range of fields, including both hardware-level technologies and software-level technologies. The basic technologies of artificial intelligence generally include, for example, sensors, dedicated artificial intelligence chips, cloud computing, distributed storage, big data processing technology, pre-trained model technology, operation / interaction systems, mechatronics, etc. Among them, the pre-trained model, also known as the large model or the foundation model, can be widely applied to downstream tasks in various directions of artificial intelligence after fine-tuning. The software technologies of artificial intelligence mainly include several major directions such as computer vision technology, speech processing technology, natural language processing technology, and machine learning / deep learning.
[0061] With the research and progress of artificial intelligence technology, artificial intelligence technology has been studied and applied in multiple fields. For example, common ones include smart home, smart wearable devices, virtual assistants, smart speakers, smart marketing, driverless, autonomous driving, drones, digital twins, virtual humans, robots, artificial intelligence-generated content (AIGC), conversational interaction, smart healthcare, smart customer service, game AI, etc. It is believed that with the development of technology, artificial intelligence technology will be applied in more fields and play an increasingly important role.
[0062] It can be understood that in the specific implementation of the present application, relevant data such as payment configuration information or payment data of the object is involved. When the following embodiments of the present application are applied to specific products or technologies, permission or consent needs to be obtained, and the collection, use, and processing of relevant data need to comply with relevant laws, regulations, and standards of relevant countries and regions.
[0063] The following will be described in detail respectively. It should be noted that the description order of the following embodiments does not limit the preferred order of the embodiments.
[0064] In this embodiment, the description will be made from the perspective of the first payment device. The first payment device can be specifically integrated in the first electronic device, and the first electronic device can be a device such as a terminal; among them, the terminal can include devices such as a tablet computer, a notebook computer, a personal computer (PC, Personal Computer), a wearable device, a virtual reality device, or other intelligent devices that can perform payments.
[0065] A payment method includes:
[0066] Sending a payment request to a payment server and receiving payment configuration information returned by the payment server based on the payment request. The payment configuration information includes payment retry configuration information. According to the payment configuration information, generating payment data and sending the payment data to the payment server so that the payment server returns the payment result of the payment data, determining the receiving status of the payment result, and generating a payment retry request according to the receiving status and the payment retry configuration information. The receiving status represents the receiving situation of the payment result, and sending the payment retry request to the payment server so that the payment server updates the payment result based on the payment retry request. When receiving the updated payment result returned by the payment server, presenting the updated payment result.
[0067] As Figure 3 shown, the specific process of this payment method is as follows:
[0068] 101. Sending a payment request to a payment server and receiving the payment configuration information returned by the payment server.
[0069] Among them, the payment request can be understood as a request for placing a payment order. That is, through this payment request, the payment method and the checkout can be pulled up. Therefore, the payment request can also be understood as a payment order request.
[0070] Among them, the payment configuration information can be understood as the configuration information for configuring payment methods, payment retry policies, etc. The payment configuration information may include payment retry configuration information. The so-called payment retry configuration information can be understood as the configuration information of the payment retry policy. For example, it may include the conditions for triggering payment retry, the number of times of initiating payment retry, the interval time between payment retries, and the error message text returned after payment retry, etc. It should be noted that the payment retry here is not the end-side initiating a new or repeated payment, but triggering the payment server side to check the payment order. When the payment order check result shows that there is no payment record, the end-side will be triggered to initiate a new or repeated payment. The new or repeated payment here refers to the process of using the previous payment data to complete the payment link again, and information such as the payment password or secret key needs to be entered again.
[0071] Among them, there can be multiple ways to send a payment request to the payment server. Specifically, it can be as follows:
[0072] For example, display a content interaction page. The content interaction page includes a payment control. In response to a trigger operation on the payment control, generate a payment request and send the payment request to the payment server. Or, when detecting payment information to be paid, generate a payment request and send the payment request to the payment server. Or, receive a payment request sent by an object terminal and send the payment request to the payment server, and so on.
[0073] Among them, "in response to" is used to indicate the conditions or states on which the executed operations depend. When the dependent conditions or states are met, one or more of the executed operations can be real-time or have a set delay; without special instructions, there is no restriction on the execution order of the multiple executed operations.
[0074] Send a payment request to the payment server so that the payment server returns payment configuration information based on the payment request. After sending the payment request to the payment server, it is possible to receive the payment configuration information returned by the payment server based on the payment request. There can be multiple ways to receive the payment configuration information returned by the payment server based on the payment request. For example, it is possible to receive the payment order voucher returned by the payment server based on the payment request, generate a payment start request based on the payment order voucher, and send the payment start request to the payment server, and receive the payment configuration information returned by the payment server based on the payment start request.
[0075] Among them, the payment voucher can be understood as the voucher for placing a payment order. The payment start request can be understood as a request for obtaining a payment method to pull up the cashier desk and triggering the server to return payment configuration information.
[0076] 102. Generate payment data according to the payment configuration information and send the payment data to the payment server so that the payment server can return the payment result of the payment data.
[0077] Among them, the payment data can be understood as the payment method selected during payment, the payment password received or collected under this payment method, the payment amount, or the collection object identifier, etc., which are used for payment deduction data. There can be various types of payment passwords. For example, it can include passwords containing various types of characters set by the trading object, and can also include passwords corresponding to various biometric data such as palm prints, fingerprints, and facial data.
[0078] Among them, the payment result can be understood as the result after payment through this payment data. There can be various types of payment results. For example, it can include payment success, payment failure, and unclear payment results, etc. Payment success can be understood as successful deduction during the payment process. Payment failure can be understood as the failure to complete payment deduction due to some clear reasons, and these clear reasons can include insufficient balance, incorrect password, or other clear reasons. Unclear payment results can be understood as unable to determine whether the deduction has been made. It may have been paid successfully or the payment may have failed. Unclear payment results can include unclear payment failure results. There can be various reasons for unclear payment results. For example, it can include request timeout or network exception, etc.
[0079] Among them, there can be various ways to generate payment data according to the payment configuration information. Specifically, it can be as follows:
[0080] For example, a payment page can be displayed. The payment page can include a payment data input control and a list of payment methods determined based on the payment configuration information. In response to the selection operation for the list of payment methods, the target payment method is determined, and the initial payment data corresponding to the target payment method is received through the payment data input control. Based on the target payment method and the initial payment data, the payment data corresponding to the payment request is generated.
[0081] Among them, the list of payment methods can include at least one payment method. The so-called payment method can be understood as the deduction account indicating payment. For example, payment through account balance, payment through bank card, payment through credit card, or payment through associated object, etc.
[0082] After generating the payment data according to the payment configuration information, the payment data can be sent to the payment server so that the payment server can return the payment result of the payment data. There can be various ways for the payment server to return the payment result of the payment data. For example, the payment server can perform payment verification on the payment data to obtain the payment result of the payment data, and then the payment result of the payment data can be returned.
[0083] 103. Determine the receiving status of the payment result, and generate a payment retry request based on the receiving status and the payment retry configuration information.
[0084] Among them, the receiving status represents the receiving request for the payment result, that is, it indicates whether the payment result of the payment data has been received. Therefore, the receiving status can include received the payment result and not received the payment result.
[0085] Among them, the payment retry request can be understood as a request to trigger the payment server to perform a payment retry for the payment data.
[0086] Among them, there can be various ways to determine the receiving status of the payment result. Specifically, it can be as follows:
[0087] For example, detect the data returned by the payment server. When the payment result is detected, determine that the receiving status of the payment result is received. When the payment result is not detected, determine that the receiving status of the payment result is not received. Or, detect the data interface of the payment server. When the payment result is detected, determine that the receiving status of the payment result is received. When the payment result is not detected, determine that the receiving status of the payment result is not received, and so on.
[0088] After determining the receiving status of the payment result, a payment retry request can be generated based on the receiving status and the payment retry configuration information. There can be various ways to generate a payment retry request. For example, when the receiving status indicates that the payment result has been received, generate a payment retry request according to the type of the payment result and the payment retry configuration information. When the receiving status indicates that the payment result has not been received, generate a payment retry request based on the payment retry configuration information.
[0089] Among them, when the receiving status indicates the payment result, there can be various ways to generate a payment retry request according to the type of the payment result and the payment retry configuration information. For example, when the payment result is not clear, generate a payment retry request according to the payment retry configuration information. When the payment result is payment success or payment failure, display the payment result based on the payment configuration information.
[0090] Among them, when the payment result is not clear, at this time, it can be determined that there is a payment exception. In order to avoid duplicate payment and deduction, it is necessary to generate a payment retry request according to the payment retry configuration information to trigger the server to perform a payment retry.
[0091] Among them, when the receiving status indicates that the payment result has not been received, at this time, it can be determined that there is a payment exception. In order to avoid duplicate payment and deduction, it is necessary to generate a payment retry request according to the payment retry configuration information to trigger the server to perform a payment retry.
[0092] 104. Send a payment retry request to the payment server so that the payment server can update the payment result based on the payment retry request.
[0093] For example, the payment retry request can be directly sent to the payment server so that the payment server can update the payment result based on the payment retry request. Or, the payment retry request can also be sent to the payment server through a third-party server so that the payment server can update the payment result based on the payment retry request.
[0094] Optionally, in some embodiments, when receiving the payment retry prompt message returned by the payment server, it can indicate that the payment server has not queried the payment record of the payment data. At this time, re-payment and deduction are required so that the payment server can update the payment result. For example, when receiving the payment retry prompt message returned by the payment server, based on the payment configuration information, generate target payment data. Based on the target payment data, update the payment data to obtain the updated payment data, and send the updated payment data to the payment server so that the payment server can update the payment result based on the updated payment data.
[0095] Among them, the payment retry prompt message can be understood as the payment server's prompt that there is no corresponding payment record for the payment data of the trading object. At this time, re-payment and deduction are required. Re-payment and deduction require re-generating payment data. Therefore, when receiving the payment retry prompt message returned by the payment server, target payment data can be generated based on the payment configuration information. There are various ways to generate the target payment data based on the payment configuration information. For example, payment secret key and other information can be obtained from the payment data, and based on the payment secret key and the payment configuration information, generate the target payment data. It should be noted here that during the payment retry process, the trading object does not need to enter payment secret key and other information again, and can directly obtain it from the data entered last time, and generate the target payment data based on the payment configuration information and the obtained payment secret key.
[0096] After generating the target payment data, the previous payment data can be updated based on the target payment data, so as to obtain the updated payment data. There are various ways to update the payment data. For example, replace the payment data with the target payment data to obtain the updated payment data. Or, the target payment data can also be compared with the payment data. When the target payment data is the same as the payment data, the payment data or the target payment data can be used as the updated payment data. When the target payment data is different from the payment data, the target payment data is used as the updated payment data, and so on.
[0097] After updating the payment data based on the target payment data, the updated payment data can be sent to the payment server so that the payment server can update the payment result based on the updated payment data.
[0098] 105. When the updated payment result returned by the payment server is received, display the updated payment result.
[0099] For example, when the updated payment result returned by the payment server is received, the updated payment result can be directly displayed, or when the updated payment result returned by the payment server is received, the updated payment result can also be displayed based on the payment configuration information, and so on.
[0100] Among them, there can be various ways to display the updated payment result based on the payment configuration information. For example, the result type of the payment result can be determined, the payment result information corresponding to the result type can be identified in the payment configuration information, and the payment result information can be displayed.
[0101] Optionally, in some embodiments, when the updated payment result returned by the payment server is not received, the payment retry times and the error message text can be identified in the payment retry configuration information, and the step of generating a payment retry request according to the reception status and the payment retry configuration information can be returned until the updated payment result is received or the payment retry times are reached. When the updated payment result is received, display the updated payment result. When the updated payment result is not received, display the error message text.
[0102] Among them, there can be various payment scenarios for this solution. For example, it can include commercial payment scenarios and social payment scenarios. For instance, it can include sending red envelopes, transferring money, and making payments (face-to-face payment), etc. Specifically, it can be as Figure 4 shown.
[0103] As described above, after the embodiment of the present application sends a payment request to the payment server and receives the payment configuration information returned by the payment server based on the payment request, it generates payment data according to the payment configuration information and sends the payment data to the payment server so that the payment server returns the payment result of the payment data. Then, it determines the receiving status of the payment result, generates a payment retry request according to the receiving status and the payment retry configuration information in the payment configuration information, and sends the payment retry request to the payment server so that the payment server updates the payment result based on the payment retry request. When receiving the updated payment result returned by the payment server, it displays the updated payment result. Since this solution can generate a payment retry request according to the receiving status of the payment result and the payment retry configuration information in the case where payment anomalies may occur, the payment server updates the payment result through the payment retry request, so that the correct payment result can be obtained, avoiding the situation of re-entering payment data for re-payment and duplicate deductions. Therefore, the payment efficiency in the payment process can be improved.
[0104] According to the method described in the above embodiment, the following will give a further detailed description by way of examples.
[0105] This embodiment will be described from the perspective of a second payment device, which can be specifically integrated in a second electronic device. The second electronic device can be a server, which can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, network acceleration services (Content Delivery Network, CDN), and big data and artificial intelligence platforms.
[0106] A payment method includes:
[0107] Receiving a payment request sent by a target terminal, generating payment configuration information corresponding to the target terminal based on the payment request, sending the payment configuration information to the target terminal, receiving payment data returned by the target terminal based on the payment configuration information, determining the payment result of the payment data, and sending the payment result to the target terminal. When receiving a payment retry request returned by the target terminal, updating the payment result and sending the updated payment result to the target terminal so that the target terminal displays the updated payment result.
[0108] As Figure 5 shown, a payment method has the following specific process:
[0109] 201. Receive a payment request sent by a target terminal and generate payment configuration information corresponding to the target terminal based on the payment request.
[0110] Among them, there are various ways to receive the payment request sent by the target terminal. Specifically, they can be as follows:
[0111] For example, it can directly receive the payment request sent by the target terminal, or it can also receive the payment request sent by the target terminal through a third-party server, and so on.
[0112] After receiving the payment request sent by the target terminal, the payment configuration information corresponding to the target terminal can be generated based on the payment request. There are various ways to generate the payment configuration information corresponding to the target terminal based on the payment request. For example, the payment request can be sent to the payment data processing server, the payment voucher of the payment request returned by the payment data processing server is received, the payment voucher is sent to the target terminal so that the target terminal can generate a payment start request based on the payment voucher, the payment start request returned by the target terminal is received, and the payment start request is sent to the payment data processing server. The payment information of at least one payment method corresponding to the payment request returned by the payment data processing server is received, and the payment retry configuration information is generated based on the payment start request. The payment retry configuration information and the payment information are used as the payment configuration information.
[0113] 202. Send the payment configuration information to the target terminal and receive the payment data returned by the target terminal based on the payment configuration information.
[0114] Among them, there are various ways to send the payment configuration information to the target terminal. Specifically, they can be as follows:
[0115] For example, it can directly send the payment configuration information to the target terminal, or it can also send the payment configuration information to the target terminal through a third-party server, and so on.
[0116] After sending the payment configuration information to the target terminal, the target terminal returns the payment data based on the payment configuration data. The way for the target terminal to return the payment data based on the payment configuration data can refer to the above description and will not be elaborated here one by one.
[0117] After sending the payment configuration information to the target terminal, the payment data returned by the target terminal based on the payment configuration information can be received. There are various ways to receive the payment data. For example, it can directly receive the payment data returned by the target terminal, or it can also receive the encrypted payment data of the target terminal for the payment data, and then decrypt the encrypted payment data to obtain the payment data, and so on.
[0118] Optionally, in some embodiments, after receiving the payment data returned by the target terminal based on the payment configuration information, the payment data may further be marked to obtain the current payment information of the payment data, and the historical payment record of the target terminal may be obtained. The historical payment record may be updated based on the current payment information to obtain the current payment record of the target terminal.
[0119] Among them, the historical payment record may be understood as the payment record of the target terminal before receiving the payment data.
[0120] 203. Determine the payment result of the payment data and send the payment result to the target terminal.
[0121] Among them, there are various ways to determine the payment result of the payment data. Specifically, it may be as follows:
[0122] For example, the transaction secret key and the payment amount may be queried from the payment data, and the preset transaction secret key and the current remaining amount of the transaction object may be obtained. When the transaction secret key is the same as the preset transaction secret key and the payment amount is less than or equal to the current remaining amount, it is determined that the payment result is a successful payment. When the transaction secret key is different from the preset transaction secret key, or the payment amount is greater than the current remaining amount, it is determined that the payment result is a failed payment. When the transaction secret key or the payment amount is not queried from the payment data, it is determined that the payment result is a failed payment or the payment result is not clear. Or, the payment data may also be sent to the payment data processing server. When the original payment result returned by the payment data processing server is received, the original payment result is used as the payment result. When the original payment result returned by the payment data processing server is not received, it may be determined that the payment result is not clear, and so on.
[0123] Among them, the payment data processing server may be understood as the server of the trading platform with specific payment data processing authority. For example, it may include the server of the payment and settlement platform. There are various types of payment and settlement platforms. For example, it may include banks or Internet financial platforms, and so on.
[0124] After determining the payment result of the payment data, the payment result may be sent to the target terminal. There are various ways to send the payment result to the target terminal. For example, the payment result may be sent through the data interface of the target terminal, or the payment result may also be sent through a third-party data platform, and so on.
[0125] Among them, it should be noted that in the process of sending the payment result to the target terminal, the target terminal may not receive the payment result.
[0126] 204. When receiving the payment retry request returned by the target terminal, update the payment result.
[0127] For example, when receiving a payment retry request returned by a target terminal, obtain the current payment record of the target terminal, and query the target payment record corresponding to the payment data in the current payment record. When there is a target payment record, based on the target payment record, determine the current payment result corresponding to the payment data, and use the current payment result as the updated payment result. When there is no target payment record, generate a payment retry prompt message and send the payment retry prompt message to the target terminal to obtain the updated payment result.
[0128] Among them, when there is a target payment record, there are multiple ways to determine the current payment result corresponding to the payment data based on the target payment record. For example, it is possible to obtain the set of payment results corresponding to the current payment record and filter out the current payment result corresponding to the target payment record in the set of payment results to obtain the current payment result corresponding to the payment data. Or, it is possible to identify the current payment result of the payment data in the target payment record. Or, it is also possible to send the target payment record to the payment data processing server and receive the current payment result of the payment data returned by the payment data processing server based on the target payment record, and so on.
[0129] Among them, when there is no target payment record, a payment retry prompt message can be generated and sent to the target terminal to obtain the updated payment result. There are multiple ways to send the payment retry prompt message to the target terminal to obtain the updated payment result. For example, it is possible to send the payment retry prompt message to the target terminal so that the target terminal updates the payment data based on the payment retry prompt message, receive the updated payment data returned by the target terminal, and determine the payment result of the updated payment data to obtain the updated payment result.
[0130] Among them, the method of determining the payment result of the updated payment data can be similar to the method of determining the payment result of the payment data. For details, see the above description and will not be elaborated here one by one.
[0131] 205. Send the updated payment result to the target terminal so that the target terminal can display the updated payment result.
[0132] For example, it is possible to directly send the updated payment result to the target terminal so that the target terminal can display the updated payment result. Or, it is possible to send the updated payment result to the target terminal so that the target terminal can display the updated payment result based on the payment configuration information. Or, it is also possible to send the updated payment result to the target terminal through a third-party server so that the target terminal can display the updated payment result based on the payment configuration information, and so on.
[0133] Among them, the method for the target terminal to display the updated payment result can be referred to the above description and will not be elaborated here one by one.
[0134] As can be seen from the above, in the embodiment of the present application, after receiving a payment request sent by a target terminal, generating payment configuration information corresponding to the target terminal based on the payment request, sending the payment configuration information to the target terminal, and receiving payment data returned by the target terminal based on the payment configuration information, determining the payment result of the payment data, and sending the payment result to the target terminal, when receiving a payment retry request returned by the target terminal, updating the payment result, and sending the updated payment result to the target terminal so that the target terminal can display the updated payment result; since the payment configuration information can be sent to the target terminal in this solution, the target terminal can send a payment retry request in case of possible payment anomalies, and update the payment result through the payment retry request, so that the correct payment result can be obtained, avoiding the situation of re-entering payment data for re-payment and duplicate deductions. Therefore, the payment efficiency in the payment process can be improved.
[0135] The method described in the above embodiment will be further described in detail with examples below.
[0136] In this embodiment, it will be described by taking the example that the first payment device is integrated in the target terminal, the second payment device is integrated in the server, and the server is a payment server.
[0137] As Figure 6 shown, the specific process of this payment method can be as follows:
[0138] 301. The target terminal sends a payment request to the payment server.
[0139] For example, the target terminal displays a content interaction page, which includes a payment control. In response to a trigger operation on the payment control, a payment request is generated and sent to the payment server. Or, when the target terminal detects payment information to be paid, a payment request is generated and sent to the payment server. Or, the target terminal receives a payment request sent by an object terminal and sends the payment request to the payment server, and so on.
[0140] 302. The payment server generates payment configuration information corresponding to the target terminal based on the payment request.
[0141] For example, the payment server sends a payment request to the payment data processing server, receives the payment voucher for the payment request returned by the payment data processing server, sends the payment voucher to the target terminal so that the target terminal generates a payment start request based on the payment voucher, receives the payment start request returned by the target terminal, and sends the payment start request to the payment data processing server. The payment server receives the payment information of at least one payment method corresponding to the payment request returned by the payment data processing server, generates payment retry configuration information based on the payment start request, and uses the payment retry configuration information and the payment information as payment configuration information.
[0142] 303. The payment server sends the payment configuration information to the target terminal.
[0143] For example, the payment server can directly send the payment configuration information to the target terminal, or can also send the payment configuration information to the target terminal through a third-party server, etc.
[0144] 304. The target terminal generates payment data according to the payment configuration information and sends the payment data to the payment server.
[0145] For example, the target terminal displays a payment page. The payment page can include a payment data input control and a list of payment methods determined based on the payment configuration information. In response to a selection operation on the list of payment methods, the target payment method is determined, and the initial payment data corresponding to the target payment method is received through the payment data input control. Based on the target payment method and the initial payment data, the payment data corresponding to the payment request is generated. The payment data is sent to the payment server.
[0146] 305. The payment server determines the payment result of the payment data and sends the payment result to the target terminal.
[0147] For example, the payment server can query the transaction secret key and the payment amount in the payment data, obtain the preset transaction secret key and the current remaining amount of the transaction object. When the transaction secret key is the same as the preset transaction secret key and the payment amount is less than or equal to the current remaining amount, the payment result is determined to be payment successful. When the transaction secret key is different from the preset transaction secret key, or the payment amount is greater than the current remaining amount, the payment result is determined to be payment failed. When the transaction secret key or the payment amount cannot be queried in the payment data, the payment result is determined to be payment failed or the payment result is not clear. Or, the payment data can also be sent to the payment data processing server. When the original payment result returned by the payment data processing server is received, the original payment result is used as the payment result. When the original payment result returned by the payment data processing server is not received, the payment result can be determined to be not clear, etc.
[0148] The payment server may send the payment result through the data interface of the target terminal, or may also send the payment result through a third-party data platform, etc.
[0149] Optionally, in some embodiments, after receiving the payment data returned by the target terminal based on the payment configuration information, the payment server may also mark the payment data to obtain the current payment information of the payment data, and obtain the historical payment record of the target terminal, and update the historical payment record based on the current payment information to obtain the current payment record of the target terminal.
[0150] 306. The target terminal determines the reception status of the payment result, and generates a payment retry request according to the reception status and the payment retry configuration information.
[0151] For example, the target terminal detects the data returned by the payment server. When the payment result is detected, it determines that the reception status of the payment result is received. When the payment result is not detected, it determines that the reception status of the payment result is not received. Or, it detects the data interface of the payment server. When the payment result is detected, it determines that the reception status of the payment result is received. When the payment result is not detected, it determines that the reception status of the payment result is not received, etc.
[0152] When the reception status indicates that the payment result is received and the payment result is not clear, the target terminal generates a payment retry request according to the payment retry configuration information. When the reception status indicates that the payment result is received and the payment result is payment success or payment failure, the payment result is displayed based on the payment configuration information.
[0153] When the reception status indicates that the payment result is not received, the target terminal generates a payment retry request according to the payment retry configuration information to trigger the server to retry the payment.
[0154] 307. The target terminal sends the payment retry request to the payment server.
[0155] For example, the target terminal may directly send the payment retry request to the payment server so that the payment server can update the payment result based on the payment retry request, or may also send the payment retry request to the payment server through a third-party server so that the payment server can update the payment result based on the payment retry request.
[0156] Optionally, in some embodiments, after the target terminal sends a payment retry request to the payment server, when receiving the payment retry prompt message returned by the payment server, based on the payment configuration information, generate target payment data, and based on the target payment data, update the payment data to obtain updated payment data, and send the updated payment data to the payment server so that the payment server can update the payment result based on the updated payment data.
[0157] 308. When the payment server receives the payment retry request returned by the target terminal, it updates the payment result.
[0158] For example, when the payment server receives the payment retry request returned by the target terminal, it obtains the current payment record of the target terminal and queries the target payment record corresponding to the payment data in the current payment record.
[0159] When there is a target payment record, the payment server obtains the set of payment results corresponding to the current payment record, and filters out the current payment result corresponding to the target payment record in the set of payment results to obtain the current payment result corresponding to the payment data. Or, the current payment result of the payment data can be identified in the target payment record. Or, the target payment record can be sent to the payment data processing server, and the current payment result of the payment data returned by the payment data processing server based on the target payment record can be received, and so on.
[0160] When there is no target payment record, the payment server can generate a payment retry prompt message and send the payment retry prompt message to the target terminal so that the target terminal can update the payment data based on the payment retry prompt message, receive the updated payment data returned by the target terminal, and determine the payment result of the updated payment data to obtain the updated payment result.
[0161] 309. The payment server sends the updated payment result to the target terminal.
[0162] For example, the payment server can directly send the updated payment result to the target terminal so that the target terminal can display the updated payment result. Or, the updated payment result can be sent to the target terminal so that the target terminal can display the updated payment result based on the payment configuration information. Or, the updated payment result can be sent to the target terminal through a third-party server so that the target terminal can display the updated payment result based on the payment configuration information, and so on.
[0163] 310. When the target terminal receives the updated payment result returned by the payment server, it displays the updated payment result.
[0164] For example, when receiving the updated payment result returned by the payment server, the target terminal can directly display the updated payment result. Or, when receiving the updated payment result returned by the payment server, the target terminal can also display the updated payment result based on the payment configuration information, and so on.
[0165] Optionally, in some embodiments, when the target terminal does not receive the updated payment result returned by the payment server, it can identify the payment retry times and error message text in the payment retry configuration information, and return to execute the step of generating a payment retry request according to the reception status and the payment retry configuration information until it receives the updated payment result or reaches the payment retry times. When receiving the updated payment result, it displays the updated payment result. When not receiving the updated payment result, it displays the error message text.
[0166] Among them, taking the payment scenario of this solution as a social payment scenario as an example, the payment server can include the servers corresponding to the social business system and the social payment system respectively, and the payment data processing server can be the payment settlement server corresponding to the social payment system. In the social payment scenario, the schematic diagram of the target terminal initiating the payment process can be as Figure 7 shown. The trading object initiates a payment request by inputting an amount through the target terminal. The payment server places an order for payment through the social business system and the social payment system, and then returns the payment order voucher for placing the payment order to the target terminal. The target terminal requests to obtain the payment method through the payment order voucher to pull up the cashier desk. The payment server obtains at least one payment method from the payment settlement server, generates the payment retry configuration information, and returns the payment information including the payment method and the payment retry configuration information to the target terminal as the payment configuration information. The trading user selects a payment method and inputs the payment password through the target terminal to obtain the payment data. The target terminal sends the payment data to the payment server for payment deduction. The payment server records the payment deduction request initiated by the target terminal. The payment server conducts payment deduction through the payment settlement server and returns the payment result to the target terminal. The target terminal can then process the information of the payment result.
[0167] Among them, there may be a situation where the target terminal does not receive the payment result, and there may also be a situation where the target terminal has received the payment result. When the target terminal does not receive the payment result, the process of processing the payment result can be as Figure 8As shown, the target terminal has not received the payment result. For the target terminal, the payment result at this time can be understood as unclear. A payment retry request is generated and sent to the payment server. The payment server determines whether there is a first payment record (target payment record). If there is a payment record, the payment inquiry can be made through the payment settlement server. If there is no payment record, the target terminal needs to be triggered to select the payment method again and enter the payment password to make a payment deduction again. The payment server updates the payment result according to the payment inquiry result and the result of the payment deduction again, and returns the updated payment result to the target terminal, and the target terminal can display the updated payment result.
[0168] After the target terminal has received the payment result, the process of processing the payment result can be as Figure 9 As shown, after the target terminal receives the payment result, it needs to determine the type of the payment result. When the payment result is payment success, the target terminal can directly display the payment success information. When the payment result is payment failure and the result is clear, the target terminal can directly display the payment failure information. When the payment result is unclear payment result or unclear payment failure result, the target terminal can generate a payment retry request and send the payment retry request to the payment server. The payment server determines whether there is a first payment record (target payment record). If there is a payment record, the payment inquiry can be made through the payment settlement server. If there is no payment record, the target terminal needs to be triggered to select the payment method again and enter the payment password to make a payment deduction again. The payment server updates the payment result according to the payment inquiry result and the result of the payment deduction again, and returns the updated payment result to the target terminal, and the target terminal can display the updated payment result.
[0169] Among them, in the overall payment process of this solution, in order to ensure the fluency and security of the payment process, a payment retry separation solution can be adopted. The overall process can be as Figure 10As shown, the trading partner initiates a payment, pulls up the payment desk, and initiates a payment request. After successfully pulling up the payment desk, payment configuration information can be returned. Once the payment desk fails to be pulled up, the entire payment process stops. Making a payment order through the payment request, i.e., payment deduction, determines whether the first payment is successful. When a payment result indicating successful payment is received, the payment process ends. If it is not determined that the payment is successful, it is possible to detect whether there is a network exception. If there is a network exception or a payment result is received, it is possible to determine whether to return the error text corresponding to the network exception. When there is error text, it is determined that the payment fails, and at this time the payment process ends. When there is no error text, the payment retry interface can be called to retry the payment. When there is no network exception and a payment result is received, it is possible to determine whether the payment failure in the payment result is a definite result. When the payment failure is a definite result, it is possible to determine that the payment fails and stop the payment process. When the payment failure is an indefinite result, i.e., the payment result is not clear, the payment retry interface can also be called to retry the payment. When retrying the payment, it is necessary to check the payment order through the payment server. When the payment order check determines that the payment is successful, the payment process can be stopped. When the payment order check is not successful, it is necessary to continue to determine whether there is a network exception. If there is a network exception, return to the step of calling the payment retry interface to retry the payment. If there is no network exception, it is necessary to determine whether to continue to retry the payment according to the payment retry configuration information. If necessary, continue to retry the payment until it is determined that the payment result is successful. If not, the payment process can be stopped.
[0170] Among them, this solution analyzes the problem points where payment exceptions may occur and optimizes the situation where the payment result is not clear in the case of unclear error reports. Taking the application scenario of this solution as a social payment scenario as an example, through the optimization process in the payment process of this solution, within a preset time range, the ratio between the total number of payment orders and the number of successfully paid orders can be as Figure 11 shown. It can be found that through the optimization of this solution, when it is determined that there is an exception in the payment, the exception is processed, and the payment is made successful as much as possible, ensuring the payment experience of the trading partner, greatly improving the payment availability rate, thereby improving the payment efficiency in the payment process, and also ensuring the payment security in the payment process.
[0171] As can be seen from the above, after the target terminal in this embodiment sends a payment request to the payment server and receives the payment configuration information returned by the payment server based on the payment request, it generates payment data according to the payment configuration information and sends the payment data to the payment server, so that the payment server returns the payment result of the payment data. Then, it determines the receiving status of the payment result, and generates a payment retry request according to the receiving status and the payment retry configuration information in the payment configuration information, and sends the payment retry request to the payment server, so that the payment server updates the payment result based on the payment retry request. When receiving the updated payment result returned by the payment server, it displays the updated payment result. Since this solution can generate a payment retry request according to the receiving status of the payment result and the payment retry configuration information in the case where payment anomalies may occur, the payment server updates the payment result through the payment retry request, so that the correct payment result can be obtained, avoiding the situation of re-entering payment data for re-payment and repeated deductions. Therefore, the payment efficiency in the payment process can be improved.
[0172] To better implement the above method, an embodiment of the present invention further provides a payment device (i.e., the first multi-person voice call device). The second payment device can be integrated in a terminal, and the terminal can include a tablet computer, a notebook computer, and / or a personal computer, etc.
[0173] For example, as Figure 11 shown, the first payment device may include a first sending unit 401, a generating unit 402, a first determining unit 403, a second sending unit 404, and a displaying unit 405, as follows:
[0174] (1) The first sending unit 401;
[0175] The first sending unit 401 is configured to send a payment request to the payment server and receive the payment configuration information returned by the payment server based on the payment request. The payment configuration information includes payment retry configuration information.
[0176] For example, the first sending unit 401 may specifically be configured to display a content interaction page, where the content interaction page includes a payment control, and in response to a trigger operation on the payment control, generate a payment request and send the payment request to the payment server.
[0177] (2) The generating unit 402;
[0178] The generating unit 402 is configured to generate payment data according to the payment configuration information and send the payment data to the payment server, so that the payment server returns the payment result of the payment data.
[0179] For example, the generation unit 402 can be specifically used to display a payment page, which may include a payment data input control and a list of payment methods determined based on payment configuration information. In response to a selection operation on the list of payment methods, a target payment method is determined, and initial payment data corresponding to the target payment method is received through the payment data input control. Based on the target payment method and the initial payment data, payment data corresponding to the payment request is generated, and the payment data is sent to the payment server so that the payment server returns the payment result of the payment data.
[0180] (3) The first determination unit 403;
[0181] The first determination unit 403 is used to determine the reception status of the payment result and generate a payment retry request according to the reception status and the payment retry configuration information, where the reception status indicates the reception situation of the payment result.
[0182] For example, the first determination unit 403 can be specifically used to detect the data returned by the payment server. When the payment result is detected, the reception status of the payment result is determined to be received. When the payment result is not detected, the reception status of the payment result is determined to be not received. When the reception status indicates that the payment result is received, a payment retry request is generated according to the type of the payment result and the payment retry configuration information. When the reception status indicates that the payment result is not received, a payment retry request is generated based on the payment retry configuration information.
[0183] (4) The second sending unit 404;
[0184] The second sending unit 404 is used to send the payment retry request to the payment server so that the payment server updates the payment result based on the payment retry request.
[0185] For example, the second sending unit 404 can be specifically used to directly send the payment retry request to the payment server so that the payment server updates the payment result based on the payment retry request, or the payment retry request can also be sent to the payment server through a third-party server so that the payment server updates the payment result based on the payment retry request.
[0186] (5) The display unit 405;
[0187] The display unit 405 is used to display the updated payment result when receiving the updated payment result returned by the payment server.
[0188] For example, the display unit 405 can be specifically used to directly display the updated payment result when receiving the updated payment result returned by the payment server, or when receiving the updated payment result returned by the payment server, the updated payment result can also be displayed based on the payment configuration information, and so on.
[0189] In specific implementation, each of the above units can be implemented as an independent entity, or can be arbitrarily combined and implemented as the same or several entities. For the specific implementation of each of the above units, reference can be made to the foregoing method embodiments and will not be elaborated herein.
[0190] As can be seen from the above, in this embodiment, after the first sending unit 401 sends a payment request to the payment server and receives the payment configuration information returned by the payment server based on the payment request, the generating unit 402 generates payment data according to the payment configuration information and sends the payment data to the payment server so that the payment server returns the payment result of the payment data. Then, the first determining unit 403 determines the receiving status of the payment result, and generates a payment retry request according to the receiving status and the payment retry configuration information in the payment configuration information. The second sending unit 404 sends the payment retry request to the payment server so that the payment server updates the payment result based on the payment retry request. When the display unit 405 receives the updated payment result returned by the payment server, it displays the updated payment result. Since this solution can generate a payment retry request according to the receiving status of the payment result and the payment retry configuration information in the case where payment anomalies may occur, the payment server updates the payment result through the payment retry request, so that the correct payment result can be obtained, avoiding the situation of re-entering payment data for re-payment and repeated deductions. Therefore, the payment efficiency in the payment process can be improved.
[0191] To better implement the above method, an embodiment of the present invention further provides a payment device (i.e., the second payment device). The first payment device can be integrated in a server, and the server can be a single server or a server cluster composed of multiple servers.
[0192] For example, as Figure 12 shown, the second payment device may include a first receiving unit 501, a second receiving unit 502, a second determining unit 503, an updating unit 504, and a third sending unit 505, as follows:
[0193] (1) The first receiving unit 501;
[0194] The first receiving unit 501 is configured to receive a payment request sent by a target terminal and generate payment configuration information corresponding to the target terminal based on the payment request.
[0195] For example, the first receiving unit 501 may be specifically configured to receive a payment request sent by a target terminal, send the payment request to a payment data processing server, receive a payment voucher for the payment request returned by the payment data processing server, send the payment voucher to the target terminal so that the target terminal generates a payment start request based on the payment voucher, receive the payment start request returned by the target terminal, and send the payment start request to the payment data processing server, receive payment information of at least one payment method corresponding to the payment request returned by the payment data processing server, generate payment retry configuration information based on the payment start request, and use the payment retry configuration information and the payment information as payment configuration information.
[0196] (2) The second receiving unit 502;
[0197] The second receiving unit 502 is configured to send the payment configuration information to the target terminal and receive payment data returned by the target terminal based on the payment configuration information.
[0198] For example, the second receiving unit 502 may be specifically configured to send payment configuration information to the target terminal. The target terminal then generates payment data based on the payment configuration data, and the second receiving unit 502 receives the payment data returned by the target terminal.
[0199] (3) The second determining unit 503;
[0200] The second determining unit 503 is configured to determine the payment result of the payment data and send the payment result to the target terminal.
[0201] For example, the second determining unit 503 may be specifically configured to send the payment data to the payment data processing server. When receiving the original payment result returned by the payment data processing server, the original payment result is used as the payment result. When not receiving the original payment result returned by the payment data processing server, it can be determined that the payment result is not clear, and the payment result is sent to the target terminal.
[0202] (4) The updating unit 504;
[0203] The updating unit 504 is configured to update the payment result when receiving a payment retry request returned by the target terminal.
[0204] For example, the update unit 504 can be specifically used to obtain the current payment record of the target terminal when receiving a payment retry request returned by the target terminal, query the target payment record corresponding to the payment data in the current payment record, when there is a target payment record, determine the current payment result corresponding to the payment data based on the target payment record, and use the current payment result as the updated payment result. When there is no target payment record, generate a payment retry prompt message and send the payment retry prompt message to the target terminal to obtain the updated payment result.
[0205] (5) The third sending unit 505;
[0206] The third sending unit 505 is used to send the updated payment result to the target terminal so that the target terminal can display the updated payment result.
[0207] For example, the third sending unit 505 can be specifically used to send the updated payment result to the target terminal so that the target terminal can display the updated payment result, or send the updated payment result to the target terminal so that the target terminal can display the updated payment result based on the payment configuration information, or send the updated payment result to the target terminal through a third-party server so that the target terminal can display the updated payment result based on the payment configuration information.
[0208] In specific implementation, each of the above units can be implemented as an independent entity, or can be combined arbitrarily to be implemented as the same or several entities. For the specific implementation of each of the above units, reference can be made to the foregoing method embodiments, which will not be elaborated herein.
[0209] As can be seen from the above, in this embodiment, after the first receiving unit 501 receives the payment request sent by the target terminal and generates the payment configuration information corresponding to the target terminal based on the payment request, the second receiving unit 502 sends the payment configuration information to the target terminal and receives the payment data returned by the target terminal based on the payment configuration information. The second determination unit 503 determines the payment result of the payment data and sends the payment result to the target terminal. The update unit 504 updates the payment result when receiving the payment retry request returned by the target terminal. The third sending unit 505 sends the updated payment result to the target terminal so that the target terminal can display the updated payment result. Since the payment configuration information can be sent to the target terminal in this solution, the target terminal can send a payment retry request in the case of possible payment anomalies, and update the payment result through the payment retry request, so that the correct payment result can be obtained, avoiding the situation of re-entering payment data for re-payment and repeated deductions. Therefore, the payment efficiency in the payment process can be improved.
[0210] The embodiment of the present application also provides an electronic device, such as Figure 13As shown, it shows a schematic structural diagram of an electronic device involved in an embodiment of the present application. Specifically:
[0211] The electronic device may include a processor 601 with one or more processing cores, a memory 602 with one or more computer-readable storage media, a power supply 603, an input unit 604, and other components. Those skilled in the art can understand that Figure 13 the structural diagram of the electronic device shown in does not constitute a limitation on the electronic device. It may include more or fewer components than shown, or combine certain components, or have different component arrangements. Among them:
[0212] The processor 601 is the control center of the electronic device, connecting various parts of the entire electronic device through various interfaces and lines. By running or executing software programs and / or modules stored in the memory 602, and by calling data stored in the memory 602, it executes various functions of the electronic device and processes data. Optionally, the processor 601 may include one or more processing cores; preferably, the processor 601 may integrate an application processor and a modem processor. Among them, the application processor mainly processes the operating system, user interface, application programs, etc., and the modem processor mainly processes wireless communication. It can be understood that the above-mentioned modem processor may not be integrated into the processor 601.
[0213] The memory 602 can be used to store software programs and modules. The processor 601 executes various functional applications and data processing by running the software programs and modules stored in the memory 602. The memory 602 may mainly include a program storage area and a data storage area. Among them, the program storage area can store the operating system, application programs required for at least one function (such as the sound playback function, image playback function, etc.); the data storage area can store data created according to the use of the electronic device. In addition, the memory 602 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices. Correspondingly, the memory 602 may also include a memory controller to provide the processor 601 with access to the memory 602.
[0214] The electronic device also includes a power supply 603 that powers each component. Preferably, the power supply 603 can be logically connected to the processor 601 through a power management system, so as to realize functions such as management of charging, discharging, and power consumption management through the power management system. The power supply 603 may also include any components such as one or more DC or AC power supplies, a recharge system, a power failure detection circuit, a power converter or inverter, and a power status indicator.
[0215] The electronic device may further include an input unit 604, which may be configured to receive input digital or character information, and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function controls.
[0216] Although not shown, the electronic device may further include a display unit and the like, which will not be elaborated here. Specifically, in this embodiment, the processor 601 in the electronic device will load the executable files corresponding to the processes of one or more application programs into the memory 602 according to the following instructions, and the processor 601 will run the application programs stored in the memory 602 to implement various functions as follows:
[0217] Send a payment request to the payment server, and receive payment configuration information returned by the payment server based on the payment request. The payment configuration information includes payment retry configuration information. According to the payment configuration information, generate payment data, and send the payment data to the payment server so that the payment server returns the payment result of the payment data. Determine the receiving status of the payment result, and generate a payment retry request according to the receiving status and the payment retry configuration information. The receiving status indicates the receiving situation of the payment result. Send the payment retry request to the payment server so that the payment server updates the payment result based on the payment retry request. When receiving the updated payment result returned by the payment server, display the updated payment result.
[0218] Or
[0219] Receive a payment request sent by a target terminal, and generate payment configuration information corresponding to the target terminal based on the payment request. Send the payment configuration information to the target terminal, and receive payment data returned by the target terminal based on the payment configuration information. Determine the payment result of the payment data, and send the payment result to the target terminal. When receiving a payment retry request returned by the target terminal, update the payment result, and send the updated payment result to the target terminal so that the target terminal displays the updated payment result.
[0220] For the specific implementation of each of the above operations, reference may be made to the previous embodiments, which will not be elaborated here.
[0221] As can be seen from the above, after the embodiment of the present application sends a payment request to the payment server and receives the payment configuration information returned by the payment server based on the payment request, payment data is generated according to the payment configuration information, and the payment data is sent to the payment server so that the payment server returns the payment result of the payment data. Then, the receiving status of the payment result is determined, and according to the receiving status and the payment retry configuration information in the payment configuration information, a payment retry request is generated and sent to the payment server so that the payment server updates the payment result based on the payment retry request. When the updated payment result returned by the payment server is received, the updated payment result is displayed. Since this solution can generate a payment retry request according to the receiving status of the payment result and the payment retry configuration information in the case where payment anomalies may occur, the payment server updates the payment result through the payment retry request, so that the correct payment result can be obtained, avoiding the situation of re-entering payment data for re-payment and repeated deductions. Therefore, the payment efficiency in the payment process can be improved.
[0222] Those of ordinary skill in the art can understand that all or part of the steps in the above various methods can be completed by instructions or by controlling related hardware through instructions. The instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.
[0223] Therefore, the embodiment of the present application provides a computer-readable storage medium, in which multiple instructions are stored, and the instructions can be loaded by a processor to execute the steps in any one of the payment methods provided by the embodiment of the present application. For example, the instructions can execute the following steps:
[0224] Send a payment request to the payment server, and receive the payment configuration information returned by the payment server based on the payment request. The payment configuration information includes payment retry configuration information. Generate payment data according to the payment configuration information, and send the payment data to the payment server so that the payment server returns the payment result of the payment data. Determine the receiving status of the payment result, and generate a payment retry request according to the receiving status and the payment retry configuration information. The receiving status indicates the receiving situation of the payment result. Send the payment retry request to the payment server so that the payment server updates the payment result based on the payment retry request. When the updated payment result returned by the payment server is received, display the updated payment result.
[0225] Or
[0226] Receive a payment request sent by a target terminal, generate payment configuration information corresponding to the target terminal based on the payment request, send the payment configuration information to the target terminal, receive payment data returned by the target terminal based on the payment configuration information, determine the payment result of the payment data, and send the payment result to the target terminal. When receiving a payment retry request returned by the target terminal, update the payment result and send the updated payment result to the target terminal so that the target terminal can display the updated payment result.
[0227] For the specific implementation of each of the above operations, reference may be made to the previous embodiments and will not be elaborated herein.
[0228] Among them, the computer-readable storage medium may include: read-only memory (ROM, Read Only Memory), random access memory (RAM, Random Access Memory), magnetic disk or optical disc, etc.
[0229] Since the instructions stored in the computer-readable storage medium can execute the steps in any of the payment methods provided in the embodiments of the present application, the beneficial effects achievable by any of the payment methods provided in the embodiments of the present application can be realized. For details, reference may be made to the previous embodiments and will not be elaborated herein.
[0230] Among them, according to one aspect of the present application, a computer program product or a computer program is provided. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the electronic device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the electronic device executes the methods provided in various optional implementation manners of the above payment aspect.
[0231] The above has introduced in detail a payment method, device, electronic device, and computer-readable storage medium provided by the embodiments of the present application. Specific examples are used in this article to elaborate on the principles and implementation manners of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention; at the same time, for those skilled in the art, according to the idea of the present invention, there will be changes in the specific implementation manners and application scopes. In summary, the content of this specification should not be construed as a limitation to the present invention.
Claims
1. A payment method, characterized in that, Including: Sending a payment request to a payment server and receiving payment configuration information returned by the payment server based on the payment request, where the payment configuration information includes payment retry configuration information; Generating payment data according to the payment configuration information and sending the payment data to the payment server so that the payment server returns a payment result of the payment data; Determining a receiving status of the payment result and generating a payment retry request according to the receiving status and the payment retry configuration information, where the receiving status indicates a receiving situation of the payment result; Sending the payment retry request to the payment server so that the payment server updates the payment result based on the payment retry request; When receiving an updated payment result returned by the payment server, presenting the updated payment result.
2. The payment method according to claim 1, wherein The generating a payment retry request according to the receiving status and the payment retry configuration information includes: When the receiving status indicates that the payment result is received, generating a payment retry request according to a type of the payment result and the payment retry configuration information; When the receiving status indicates that the payment result is not received, generating a payment retry request based on the payment retry configuration information.
3. The payment method according to claim 2, wherein The generating a payment retry request according to the type of the payment result and the payment retry configuration information includes: When the payment result is not clear, generating a payment retry request according to the payment retry configuration information; When the payment result is payment success or payment failure, presenting the payment result based on the payment configuration information.
4. The payment method according to claim 1, wherein After sending the payment retry request to the payment server, further including: When receiving payment retry prompt information returned by the payment server, generating target payment data based on the payment configuration information; Updating the payment data based on the target payment data to obtain updated payment data; Sending the updated payment data to the payment server so that the payment server updates the payment result based on the updated payment data.
5. The payment method according to claim 1, wherein After sending the payment retry request to the payment server, further including: When not receiving the updated payment result returned by the payment server, identifying a payment retry count and an error message in the payment retry configuration information; Returning to execute the step of generating a payment retry request according to the receiving status and the payment retry configuration information until receiving the updated payment result or reaching the payment retry count; When receiving the updated payment result, presenting the updated payment result; When not receiving the updated payment result, presenting the error message.
6. The payment method according to claim 1, characterized in that The generating payment data according to the payment configuration information includes: Displaying a data payment page, where the data payment page includes a payment data input control and a list of payment methods determined based on the payment configuration information; In response to a selection operation on the list of payment methods, determining a target payment method and receiving initial payment data corresponding to the target payment method through the payment data input control; Generate the payment data corresponding to the payment request based on the target payment method and the initial payment data.
7. A payment method, characterized in that, Including: Receive a payment request sent by a target terminal, and generate payment configuration information corresponding to the target terminal based on the payment request; Send the payment configuration information to the target terminal, and receive the payment data returned by the target terminal based on the payment configuration information; Determine the payment result of the payment data, and send the payment result to the target terminal; When receiving a payment retry request returned by the target terminal, update the payment result; Send the updated payment result to the target terminal so that the target terminal can display the updated payment result.
8. The payment method according to claim 7, wherein The updating of the payment result includes: Obtain the current payment record of the target terminal, and query the target payment record corresponding to the payment data in the current payment record; When the target payment record exists, determine the current payment result corresponding to the payment data based on the target payment record, and use the current payment result as the updated payment result; When the target payment record does not exist, generate a payment retry prompt message, and send the payment retry prompt message to the target terminal to obtain the updated payment result.
9. A payment device, characterized in that, Including: A first sending unit, configured to send a payment request to a payment server, and receive the payment configuration information returned by the payment server based on the payment request, where the payment configuration information includes payment retry configuration information; A generating unit, configured to generate payment data according to the payment configuration information, and send the payment data to the payment server so that the payment server returns the payment result of the payment data; A first determining unit, configured to determine the receiving status of the payment result, and generate a payment retry request according to the receiving status and the payment retry configuration information, where the receiving status indicates the receiving situation of the payment result; A second sending unit, configured to send the payment retry request to the payment server so that the payment server updates the payment result based on the payment retry request; A displaying unit, configured to display the updated payment result when receiving the updated payment result returned by the payment server.
10. A payment device, characterized in that, Including: A first receiving unit, configured to receive a payment request sent by a target terminal, and generate payment configuration information corresponding to the target terminal based on the payment request; A second receiving unit, configured to send the payment configuration information to the target terminal, and receive the payment data returned by the target terminal based on the payment configuration information; A second determining unit, configured to determine the payment result of the payment data, and send the payment result to the target terminal; An updating unit, configured to update the payment result when receiving a payment retry request returned by the target terminal; A third sending unit, configured to send the updated payment result to the target terminal so that the target terminal can display the updated payment result.
11. An electronic device, characterized in that, It includes a processor and a memory. The memory stores an application program, and the processor is used to run the application program in the memory to execute the steps in the payment method according to any one of claims 1 to 8.
12. A computer program product, comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, the steps in the payment method according to any one of claims 1 to 8 are implemented.
13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions, and the instructions are suitable for being loaded by the processor to execute the steps in the payment method according to any one of claims 1 to 8.
Citation Information
Cited By
Payment system, method and device based on large model, medium and equipment
CN122089301A