Multi - party Payment Code Intercommunication Method and System

Abstract

A method and system for multi-party payment code interoperability, which relates to the field of digital payment and can be applied to the financial field and other fields. The method includes: receiving a payment link obtained by the client parsing a payment code, and adjusting the payment link object according to a preset payment identifier to generate an authentication link for the acquiring institution corresponding to the preset payment identifier; loading the authentication link and intercepting the user's temporary authorization link fed back by the acquiring institution, and obtaining the user identifier and the temporary authorization code fed back by the front-end according to the user's temporary authorization link; splicing to obtain an order request link according to the temporary authorization code and the user identifier, and obtaining the order information fed back by the acquiring institution according to the order request link; obtaining the key-value parameters generated by the confirmed order information, assembling a verification message according to the key-value parameters, and providing the verification message to the front-end for verification; obtaining the input payment information according to the received signature verification data, providing the payment information to the front-end for payment authentication, and displaying and outputting the received payment result.

Description

Technical Field

[0001] This application relates to the field of digital payment, and can be applied to the financial field and other fields, especially a method and system for the interoperability of multi-party payment codes. Background Art

[0002] In the prior art, the clients of each financial service institution can only meet their respective payment systems. During use, they can only complete the subsequent payment process by scanning their respective specific link codes and cannot communicate with each other. For example, if the payment code is provided by Institution A, the payee can only receive payments using the payment method provided by Institution A. Conversely, if the payee only has one payment method from Institution A, then the payer can only make payments through the payment method of Institution A. As a result, when users conduct digital payments, they need to configure different clients for different payee and payer institutions to ensure the execution of digital transactions.

[0003] In view of this, there is an urgent need in the industry for a method to overcome the barriers in the payment links of each financial institution, enabling the interoperability of payment codes such as QR codes between different merchants. On the basis of ensuring users' free choice and the coupling requirements of the payment link, the user experience is improved. Summary of the Invention

[0004] The purpose of this application is to provide a method and system for the interoperability of multi-party payment codes, enabling any client to recognize multi-party payment codes and complete corresponding transactions, and realizing the interoperability of multiple payment codes at the application level.

[0005] To achieve the above object, a method for the interoperability of multi-party payment codes provided by this application includes: receiving a payment link obtained by a client parsing a payment code, adjusting the payment link object according to a preset payment identifier to generate an authentication link for an acquirer corresponding to the preset payment identifier; loading the authentication link and intercepting a user temporary authorization link feedback by the acquirer, accessing and obtaining a user identifier and a temporary authorization code feedback by a front-end according to the user temporary authorization link; splicing an order request link according to the temporary authorization code and the user identifier, accessing and obtaining order information feedback by the acquirer according to the order request link; obtaining key-value parameters generated by the payer confirming the order information, assembling a verification message according to the key-value parameters, and providing the verification message to the front-end for verification; obtaining payment information input by the payer according to the received signature verification data, providing the payment information to the front-end for payment authentication, and displaying and outputting the received payment result.

[0006] In the above method for the interoperability of multi-party payment codes, optionally, receiving a payment link obtained by a client parsing a payment code further includes: generating an error prompt when the payment link does not match a preset whitelist.

[0007] In the above multi-party payment code interoperability method, optionally, adjusting the payment link object according to a preset payment identifier to generate an authentication link for the acquiring institution corresponding to the preset payment identifier includes: loading the payment link through an embedded browser, and adding the preset payment identifier corresponding to the acquiring institution to the user agent to generate an authentication link pointing to the acquiring institution.

[0008] In the above multi-party payment code interoperability method, optionally, the user's temporary authorization link includes the address for the acquiring institution to receive the processing result.

[0009] In the above multi-party payment code interoperability method, optionally, obtaining an order request link by splicing the temporary authorization code and the user identifier, and obtaining the order information feedback by the acquiring institution according to the order request link includes: splicing an order request link according to the temporary authorization code, the user identifier, and the processing result received by the acquiring institution; obtaining the order information feedback by the acquiring institution to the browser according to the order request link; and providing the order information to the payer for display through the H5 page of the browser.

[0010] In the above multi-party payment code interoperability method, optionally, the signature verification data includes order information, user identifier, front-end notification address, and signature data.

[0011] In the above multi-party payment code interoperability method, optionally, obtaining the key-value parameters generated by the payer's confirmation of the order information includes: intercepting the GET request generated by the payer's confirmation of the order information, and extracting the key-value parameters after the GET request.

[0012] The present application also provides a multi-party payment code interoperability system, which includes a client, a payment component, an acquirer, and a front-end; the client parses the payment link obtained from the payment code and provides the payment link to the payment component; the payment component adjusts the payment link object according to a preset payment identifier to generate an authentication link for the acquirer corresponding to the preset payment identifier and loads the authentication link; the acquirer processes the authentication link and feeds back a user temporary authorization link; the payment component intercepts the user temporary authorization link and accesses the front-end according to the user temporary authorization link; the payment front-end obtains the currently logged-in user identifier according to the loading request of the payment component, generates a user temporary authorization code according to the user identifier, and feeds back the user identifier and the user temporary authorization code to the payment component; the payment component splices the temporary authorization code and the user identifier to obtain an order request link, and accesses the acquirer according to the order request link; the acquirer generates order information according to the order request and feeds it back to the payment; the payment component provides the order information to the client for display, extracts key-value parameters through the GET request generated by the payer's confirmation of the order information, assembles a verification message according to the key-value parameters, and provides the verification message to the front-end for verification; the front-end verifies the verification message and feeds back the signature verification data to the payment component, and the payment component obtains the payment information input by the payer according to the signature verification data and provides the payment information to the front-end; after the front-end authenticates the payment information, it feeds back a payment result to the payment component.

[0013] The present application also provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the above method is implemented.

[0014] The present application also provides a computer-readable storage medium, which stores a computer program for executing the above method.

[0015] The beneficial technical effects of the present application are as follows: it can be conveniently introduced into each payee client, not limited to specific clients; in addition, the present invention realizes the interconnection and interoperability of multi-party payment codes, breaking the technical and payment service barriers between payment codes; it combines them well and is convenient for users to use. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application, but do not limit the present application. In the drawings:

[0017] Figure 1 is a schematic flowchart of a multi-party payment code interoperability method provided by an embodiment of the present application;

[0018] Figure 2 Schematic diagram of the order information generation process provided by an embodiment of the present application;

[0019] Figure 3 Schematic diagram of the H5 page display provided by an embodiment of the present application;

[0020] Figure 4 Schematic diagram of the payment interface display provided by an embodiment of the present application;

[0021] Figure 5 Schematic diagram of the order data return display provided by an embodiment of the present application;

[0022] Figure 6 Schematic diagram of the signature verification platform display provided by an embodiment of the present application;

[0023] Figure 7 Schematic diagram of the payment success interface display provided by an embodiment of the present application;

[0024] Figure 8 Schematic diagram of the structure of the multi - party payment code interoperability system provided by an embodiment of the present application;

[0025] Figure 9 Schematic diagram of the timing process of the multi - party payment code interoperability system provided by an embodiment of the present application;

[0026] Figure 10 Schematic diagram of the structure of the electronic device provided by an embodiment of the present application. Detailed implementation manners

[0027] The following will combine the accompanying drawings and embodiments to detail the implementation manners of the present application, so as to fully understand how the present application uses technical means to solve technical problems and the implementation process of achieving technical effects and implement accordingly. It should be noted that as long as there is no conflict, each embodiment in the present application and each feature in each embodiment can be combined with each other, and the formed technical solutions are all within the protection scope of the present application.

[0028] In addition, the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer - executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0029] Please refer to Figure 1 As shown, a multi - party payment code interoperability method provided by the present application specifically includes:

[0030] S101 receives the payment link obtained by the client parsing the payment code, and adjusts the payment link object according to a preset payment identifier to generate an authentication link for the acquiring institution corresponding to the preset payment identifier;

[0031] S102 loads the authentication link and intercepts the user's temporary authorization link fed back by the acquiring institution, and accesses the user identifier and the temporary authorization code fed back by the front-end according to the user's temporary authorization link;

[0032] S103 splices the order request link according to the temporary authorization code and the user identifier, and accesses the order information fed back by the acquiring institution according to the order request link;

[0033] S104 obtains the key-value parameters generated by the payer's confirmation of the order information, assembles the verification message according to the key-value parameters, and provides the verification message to the front-end for verification;

[0034] S105 obtains the payment information input by the payer according to the received signature verification data, provides the payment information to the front-end for payment authentication, and displays and outputs the received payment result.

[0035] Among them, the signature verification data includes order information, user identifier, front-end notification address, and signature data. Through the above process, this application uses a payment component as a medium between the payee client and the acquiring institution to receive and display order information; then receives payment information and displays the C-terminal payment information signature verification platform to guide the user to perform payment verification, sends the message to the payment background, and displays the payment result, etc. It is user-friendly, easy to operate, and has strong coupling with each client.

[0036] In an embodiment of this application, the payment link obtained by the client parsing the payment code further includes: when the payment link does not match the preset white list, a error prompt is generated. Specifically, in actual work, the payer client APP can scan the collection code of Institution A / Institution B, parse the link URL, and check whether the domain name is in the domain name white list synchronized by the acquiring institution. Only when it is valid can the process continue, otherwise an error is reported; then when it is confirmed to be valid, the URL, that is, the payment link, can be provided to the payment component to complete the subsequent process.

[0037] In an embodiment of the present application, adjusting the payment link object according to a preset payment identifier to generate an authentication link for an acquirer corresponding to the preset payment identifier may include: loading the payment link through an embedded browser, and adding a preset payment identifier corresponding to the acquirer in the user agent to generate an authentication link pointing to the acquirer. Specifically, in actual work, the payment component loads the payment link URL through the embedded browser WebView. At this time, it is necessary to add an identifier supporting UnionPay QR code payment in the user agent UserAgent, and the format is "UnionPay<version number><APP identifier>". The purpose of loading this URL is to obtain the user authorization code.

[0038] Thus, when the payment component loads this URL, it will be redirected to a URL in a specific format returned by the acquirer, and this URL is for obtaining user information. In addition, this URL in the specific format, that is, the user temporary authorization link, also includes the address for the acquirer to receive the processing result, that is, redirectUrl.

[0039] Please refer to Figure 2 As shown, in an embodiment of the present application, obtaining an order request link by splicing the temporary authorization code and the user identifier, and obtaining order information feedback by the acquirer according to the order request link includes:

[0040] S201 Splice an order request link according to the temporary authorization code, the user identifier, and the processing result received by the acquirer;

[0041] S202 Obtain order information feedback by the acquirer to the browser according to the order request link;

[0042] S203 Provide the order information to the payer for display through the H5 page of the browser.

[0043] Specifically, in combination with the foregoing embodiment, the front-end of the payer receives a request loaded by the payment component, obtains the user identifier of the currently logged-in user, and after certain processing, returns the user temporary authorization code userAuthCode to the payment component; the payment component decodes the redirectUrl through URLDecode, and splices the above-mentioned temporary authorization code userAuthCode and the user identifier reqCode after the decoded url. The payment component loads the spliced URL, that is, the order request link, through WebView; after loading, the acquirer returns order information to WebView, which includes a request message for "front-end payment"; at this time, the payment component displays this H5 page, as Figure 3 shown.

[0044] In an embodiment of the present application, the key-value parameters generated by obtaining the payer's confirmation of the order information include: intercepting the GET request generated by the payer's confirmation of the order information, and extracting the key-value parameters after the GET request. Specifically, in actual work, the payer user confirms the H5 page information of the order and clicks the "Pay" button on the page (as Figure 4 shown). After that, the H5 page of the order information will initiate a GET request to the payer APP. The component intercepts the GET request, extracts the key / value parameter part after the request, and combines it with other necessary data to form a message and forwards it to the payer's background system for verification, waiting for the payment order data to be returned, as Figure 5 shown; subsequently, the payer's front-end verifies the transaction through the UnionPay public key, and returns payment information such as order information (order type, payment amount), user identification, front-end notification address, signature data, etc. and the marketing information result to the payment component; the payment component displays the C-terminal signature verification platform, as Figure 6 shown, and guides the user to enter the payment password on the signature verification platform to complete the identity authentication, and submits the payment confirmation information to the payer's front-end; the payer's front-end completes the password verification, instructs registration, calls the payment interface to complete the payment, and instructs to update and push the payment voucher, and returns the result information to the payment component. The payment component receives the payment result and displays the payment success page for the user, as Figure 7 shown. In this embodiment, the success page also provides a button. When the user clicks the button, if the data in the GET request contains the front-end notification address, the payment component will access the front-end notification address again through the WebView at this time to display the order result page. If the front-end notification address is not included, the payment component will not perform any processing.

[0045] Please refer to Figure 8 and Figure 9As shown in the figure, the present application also provides a multi-party payment code interoperability system, which includes a client, a payment component, an acquirer, and a front-end. The client parses the payment link obtained from the payment code and provides the payment link to the payment component. The payment component adjusts the payment link object according to a preset payment identifier, generates an authentication link for the acquirer corresponding to the preset payment identifier, and loads the authentication link. The acquirer processes the authentication link and feeds back a user temporary authorization link. The payment component intercepts the user temporary authorization link and accesses the front-end according to the user temporary authorization link. The payment front-end obtains the currently logged-in user identifier according to the loading request of the payment component, generates a user temporary authorization code according to the user identifier, and feeds back the user identifier and the user temporary authorization code to the payment component. The payment component splices the temporary authorization code and the user identifier to obtain an order request link, and accesses the acquirer according to the order request link. The acquirer generates order information according to the order request and feeds it back to the payment. The payment component provides the order information to the client for display, extracts key-value parameters through the GET request generated by the payer's confirmation of the order information, assembles a verification message according to the key-value parameters, and provides the verification message to the front-end for verification. The front-end verifies the verification message and feeds back the signature verification data to the payment component. The payment component obtains the payment information input by the payer according to the signature verification data, and provides the payment information to the front-end. After the front-end authenticates the payment information, it feeds back the payment result to the payment component.

[0046] The beneficial technical effects of the present application are as follows: It can be conveniently introduced into each payee client, not limited to specific clients. In addition, the present invention realizes the interconnection and interoperability of multi-party payment codes, breaks the technical and payment service barriers between payment codes, and combines them well for the convenience of users.

[0047] The present application also provides an electronic device, which includes a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the above method is implemented.

[0048] The present application also provides a computer-readable storage medium, which stores a computer program for executing the above method.

[0049] As Figure 10 shown, the electronic device 600 may further include: a communication module 110, an input unit 120, an audio processing unit 130, a display 160, and a power supply 170. It should be noted that the electronic device 600 does not necessarily have to include Figure 10 all the components shown in Figure 10For components not shown herein, reference may be made to the prior art.

[0050] As Figure 10 shown, the central processing unit 100, sometimes also referred to as a controller or operation control, may include a microprocessor or other processor device and / or logic device. The central processing unit 100 receives inputs and controls the operation of the various components of the electronic device 600.

[0051] Among them, the memory 140 can be, for example, one or more of a buffer, a flash memory, a hard drive, a removable medium, a volatile memory, a non-volatile memory, or other suitable devices. It can store the above-mentioned information related to failures, and can also store programs for executing relevant information. And the central processing unit 100 can execute the programs stored in the memory 140 to implement information storage or processing, etc.

[0052] The input unit 120 provides inputs to the central processing unit 100. The input unit 120 is, for example, a key or a touch input device. The power supply 170 is used to supply power to the electronic device 600. The display 160 is used to display display objects such as images and texts. The display can be, for example, an LCD display, but is not limited thereto.

[0053] The memory 140 can be a solid-state memory. For example, a read-only memory (ROM), a random access memory (RAM), a SIM card, etc. It can also be such a memory that stores information even when powered off, can be selectively erased and has more data. Examples of such a memory are sometimes referred to as EPROMs, etc. The memory 140 can also be some other type of device. The memory 140 includes a buffer memory 141 (sometimes referred to as a buffer). The memory 140 can include an application / function storage unit 142, which is used to store application programs and function programs or the processes for operating the electronic device 600 through the central processing unit 100.

[0054] The memory 140 can also include a data storage unit 143, which is used to store data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit 144 of the memory 140 can include various drivers of the electronic device for communication functions and / or for performing other functions of the electronic device (such as a messaging application, an address book application, etc.).

[0055] The communication module 110 is the transmitter / receiver 110 that transmits and receives signals via the antenna 111. The communication module (transmitter / receiver) 110 is coupled to the central processing unit 100 to provide input signals and receive output signals, which can be the same as in the case of a conventional mobile communication terminal.

[0056] Based on different communication technologies, in the same electronic device, multiple communication modules 110 may be provided, such as a cellular network module, a Bluetooth module, and / or a wireless local area network module, etc. The communication module (transmitter / receiver) 110 is also coupled to a speaker 131 and a microphone 132 via an audio processor 130 to provide an audio output via the speaker 131 and receive an audio input from the microphone 132, so as to implement normal telecommunication functions. The audio processor 130 may include any suitable buffers, decoders, amplifiers, etc. Additionally, the audio processor 130 is also coupled to a central processor 100, enabling recording on the local device through the microphone 132 and playing back the sound stored on the local device through the speaker 131.

[0057] Those skilled in the art should understand that the embodiments of the present application may be provided as a method, a system, or a computer program product. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0058] The present application is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, as well as the combination of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate a device for implementing the functions specified in Figure 1 one or more of the flows Figure 1 or multiple flows and / or blocks

[0059] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including an instruction device that implements the functions specified in Figure 1 one or more of the flows Figure 1 or multiple flows and / or blocks

[0060] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus, so that a series of operation steps are performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions for implementing the process Figure 1 in one process or multiple processes and / or blocks Figure 1 steps for the functions specified in one block or multiple blocks.

[0061] The specific embodiments described above further elaborate on the objectives, technical solutions, and beneficial effects of the present application. It should be understood that the above are only specific embodiments of the present application and are not intended to limit the protection scope of the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included within the protection scope of the present application.

Claims

1. A method for multi-party payment code interoperability, characterized in that The method includes: Receiving a payment link obtained by the client parsing a payment code, and adjusting the payment link object according to a preset payment identifier to generate an authentication link for the acquiring institution corresponding to the preset payment identifier; Loading the authentication link and intercepting the user temporary authorization link fed back by the acquiring institution, and accessing the front-end feedback user identifier and temporary authorization code according to the user temporary authorization link; Splicing an order request link according to the temporary authorization code and the user identifier, and accessing the order information fed back by the acquiring institution according to the order request link; Obtaining the key-value parameters generated by the payer's confirmation of the order information, assembling a verification message according to the key-value parameters, and providing the verification message to the front-end for verification; Obtaining the payment information input by the payer according to the received signature verification data, providing the payment information to the front-end for payment authentication, and displaying and outputting the received payment result; Splicing an order request link according to the temporary authorization code and the user identifier, and the order information fed back by the acquiring institution obtained by accessing according to the order request link includes: Splicing an order request link according to the temporary authorization code, the user identifier, and the receiving and processing result of the acquiring institution; Accessing the order information fed back by the acquiring institution to the browser according to the order request link; Providing the order information to the payer for display through the H5 page of the browser.

2. The multi-party payment code interoperability method according to claim 1, characterized in that Receiving the payment link obtained by the client parsing the payment code further includes: Generating an error prompt when the payment link does not match the preset whitelist.

3. The multi-party payment code interoperability method according to claim 1, wherein, Adjusting the payment link object according to the preset payment identifier to generate an authentication link for the acquiring institution corresponding to the preset payment identifier includes: Loading the payment link through an embedded browser, and adding the preset payment identifier corresponding to the acquiring institution to the user agent to generate an authentication link pointing to the acquiring institution.

4. The multi-party payment code interoperability method according to claim 1, wherein The user temporary authorization link includes the address of the receiving and processing result of the acquiring institution.

5. The multi-party payment code interoperability method according to claim 1, wherein The signature verification data includes order information, user identifier, front-end notification address, and signature data.

6. The method for multi-party payment code interoperability according to claim 1, wherein Obtaining the key-value parameters generated by the payer's confirmation of the order information includes: Intercepting the GET request generated by the payer's confirmation of the order information, and extracting the key-value parameters after the GET request.

7. A multi-party payment code interoperability system, characterized in that, The system includes a client, a payment component, an acquiring institution, and a front-end; The client parses the payment code to obtain a payment link, and provides the payment link to the payment component; the payment component adjusts the payment link object according to a preset payment identifier to generate an authentication link for the acquiring institution corresponding to the preset payment identifier and loads the authentication link; The acquiring institution processes the authentication link and feeds back a user temporary authorization link; The payment component intercepts the user temporary authorization link and accesses the front-end according to the user temporary authorization link; The payment front-end obtains the currently logged-in user identifier according to the loading request of the payment component, generates a user temporary authorization code according to the user identifier, and feeds back the user identifier and the user temporary authorization code to the payment component; The payment component obtains an order request link by splicing the temporary authorization code and the user identification, and accesses the acquiring institution according to the order request link; The acquiring institution generates order information according to the order request and feeds it back to the payment; The payment component provides the order information to the client for display, extracts key-value parameters through a GET request generated by the payer's confirmation of the order information, assembles a verification message according to the key-value parameters, and provides the verification message to the front-end for verification; The front-end verifies the verification message and feeds back the signature verification data to the payment component. The payment component obtains the payment information input by the payer according to the signature verification data and provides the payment information to the front-end; after the front-end authenticates the payment information, it feeds back the payment result to the payment component; The payment component is specifically configured to obtain an order request link by splicing the temporary authorization code, the user identification, and the receiving and processing result of the acquiring institution; Obtain the order information fed back by the acquiring institution to the browser according to the order request link; Provide the order information to the payer for display through the H5 page of the browser.

8. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program for the computer to execute the method according to any one of claims 1 to 6.

Images