Electronic payment method, computer system and device

Abstract

The embodiment of the invention provides an electronic payment method, a computer system and a device. Wherein the amount input page and the merchant payment result page are uniformly provided by an intermediate service party. And after the electronic wallet scans the static code of the merchant, code information obtained by scanning is sent to an amount input page. The amount input page determines order information based on the received code information and amount, and sends the order information to the intermediate service party. And the payer reuses the original process, obtains the order information from the intermediate service party, executes payment operation based on the order information, and sends a payment result notification to the intermediate service party. And the intermediate service party converts the payment result notification into a payment confirmation request for calling the acquirer, and receives a merchant payment result fed back by the acquirer. And the intermediate service party displays the merchant payment result through the merchant payment result page.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the technical field of electronic payment, and in particular, to an electronic payment method, a computer system, and a device for transactions. Background Art

[0002] Currently, users often have a need to make payments using an electronic wallet. However, there are different transaction modes in different countries. For example, there are order placement transaction modes and Push transaction modes. The processing flows between these two transaction modes are quite different and cannot be compatible, resulting in users of electronic wallets in some countries being unable to make payments smoothly when entering other countries, and the service experience is poor. Therefore, it is expected to have an improved solution that can be compatible with the above two transaction modes and enhance the service experience of users. Summary of the Invention

[0003] One or more embodiments of this specification describe an electronic payment method, a computer system, and a device that can be compatible with different transaction modes and enhance the service experience of users. The specific technical solutions are as follows.

[0004] In a first aspect, an embodiment provides an electronic payment method, which is executed by an intermediate service party and includes: receiving order information sent by an amount input page, where the order information is determined by the amount input page in response to a transaction amount input by a user based on received code information, and the code information is sent by a payer after scanning a static code of a merchant, and the amount input page is provided by the intermediate service party; sending the order information to the payer; receiving a payment result notification sent by the payer, where the payment result notification is sent by the payer after performing a payment operation based on the order information; based on the payment result notification, sending a payment confirmation request to an acquirer; receiving a merchant payment result feedback by the acquirer, where the merchant payment result is determined by the acquirer based on the payment confirmation request.

[0005] In a second aspect, an embodiment provides an electronic payment method, which is executed by an amount input page provided by an intermediate service party; the method includes: receiving code information sent by a payer; the code information is obtained by the payer after scanning a static code of a merchant; in response to a transaction amount input by a user, determining order information based on the received code information, and sending the order information to the intermediate service party.

[0006] In a third aspect, an embodiment provides an electronic payment method, including: after a payer scans a static code of a merchant, sending the scanned code information to an amount input page; the amount input page is provided by an intermediate service provider; the amount input page determines order information based on the received code information in response to a transaction amount input by a user, and sends the order information to the intermediate service provider; the payer obtains the order information from the intermediate service provider, performs a payment operation based on the order information, and sends a payment result notification to the intermediate service provider; the intermediate service provider sends a payment confirmation request to a receiving party based on the payment result notification; the receiving party determines a merchant payment result based on the payment confirmation request and feeds back the merchant payment result to the intermediate service provider.

[0007] In a fourth aspect, an embodiment provides a computer system, including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein when the processor executes the program, the following steps are implemented: receiving order information sent by an amount input page, the order information being determined by the amount input page based on received code information in response to a transaction amount input by a user, the code information being sent by the payer after scanning a static code of a merchant, and the amount input page being provided by an intermediate service provider; sending the order information to the payer; receiving a payment result notification sent by the payer, the payment result notification being sent by the payer after performing a payment operation based on the order information; sending a payment confirmation request to a receiving party based on the payment result notification; receiving a merchant payment result fed back by the receiving party, the merchant payment result being determined by the receiving party based on the payment confirmation request.

[0008] In a fifth aspect, an embodiment provides a computer system, including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein when the processor executes the program, the following steps are implemented: receiving code information sent by a payer, the code information being obtained by the payer after scanning a static code of a merchant; determining order information based on the received code information in response to a transaction amount input by a user, and sending the order information to the intermediate service provider.

[0009] In a sixth aspect, an embodiment provides an electronic payment device deployed in an intermediate service provider. The device includes: a first receiving module configured to receive order information sent by an amount input page, where the order information is determined by the amount input page based on received code information in response to a transaction amount input by a user, and the code information is sent by a payer after scanning a static code of a merchant, and the amount input page is provided by the intermediate service provider; a first sending module configured to send the order information to the payer; a second receiving module configured to receive a payment result notification sent by the payer, where the payment result notification is sent by the payer after performing a payment operation based on the order information; a second sending module configured to send a payment confirmation request to an acquirer based on the payment result notification; and a third receiving module configured to receive a merchant payment result feedback by the acquirer, where the merchant payment result is determined by the acquirer based on the payment confirmation request.

[0010] In a seventh aspect, an embodiment provides an electronic payment device deployed in an amount input page provided by an intermediate service provider. The device includes: a fourth receiving module configured to receive code information sent by a payer, where the code information is obtained by the payer after scanning a static code of a merchant; and a third sending module configured to determine order information based on the received code information in response to a transaction amount input by a user and send the order information to the intermediate service provider.

[0011] In an eighth aspect, an embodiment provides a computer-readable non-volatile storage medium, characterized in that the storage medium stores a computer program, and when the computer program is executed by a processor, the method described in any one of the first aspect to the second aspect is implemented.

[0012] In a ninth aspect, an embodiment provides a computing device including a memory and a processor. An executable code is stored in the memory, and when the processor executes the executable code, the method described in any one of the first aspect to the second aspect is implemented.

[0013] In the electronic payment method provided by the embodiments of this specification, a unified amount input page is provided by an intermediate service provider. After the user scans the code, they are redirected to this amount input page, triggering the intermediate service provider to place an order. The process of the payer obtaining order information from the intermediate service provider and making a payment can reuse the original transaction processing flow. After the payer completes the payment, a payment result notification is sent to the intermediate service provider. After receiving the payment result notification, the intermediate service provider converts it into a confirmation payment request sent to the acquirer and obtains the merchant payment result feedback by the acquirer. The process of the acquirer determining the merchant payment result can reuse the original transaction processing flow. During the entire payment process of the transaction, the payer can reuse the transaction processing flow in the order placement transaction mode, and the acquirer can reuse the transaction processing flow in the Push transaction mode, thus achieving compatibility with the two transaction modes and improving the user service experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the following described drawings are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0015] Figure 1 It is a schematic diagram for comparing the implementation processes of two transaction modes;

[0016] Figure 2 It is a transaction processing flowchart in an embodiment when the acquirer is transformed to support the order placement transaction mode;

[0017] Figure 3 It is a transaction processing flowchart in an embodiment when the payer is transformed to support the Push transaction mode;

[0018] Figure 4 It is a schematic flowchart of an electronic payment method provided by the embodiment;

[0019] Figure 5 It is a schematic block diagram of an electronic payment device deployed in an intermediate service provider provided by the embodiment;

[0020] Figure 6 It is a schematic logical structure diagram of an electronic payment device deployed in an amount input page provided by the embodiment;

[0021] Figure 7 It is a schematic structural diagram of a computer system provided by the embodiment. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0022] The following describes the solution provided in this specification in conjunction with the drawings.

[0023] The electronic payment scenario involved in this specification is the scenario of scanning a static code in the forward direction. Among them, scanning in the forward direction refers to the behavior of a user scanning a code provided by the merchant side in an offline payment scenario for payment. A static code refers to a code that requires the user to enter the amount after being scanned by the user in the offline payment scenario of scanning a static code in the forward direction. The scenario of scanning a static code in the forward direction includes multiple transaction modes.

[0024] Figure 1 It is a schematic diagram for comparing the implementation processes of two transaction modes. Among them, it involves users, merchants, acquirers, payment institutions, and the amount input page. Among them, the payment institution executes the transaction processing process through a payment server and / or an electronic wallet, and the acquirer executes the transaction processing process through an acquirer server. An acquirer is an institution specialized in merchant payment collection, settlement, reconciliation, etc. A merchant can provide services or goods available for transactions.

[0025] In the order placement transaction mode, the acquirer provides the amount input page. In the entire transaction processing process, the user first enters the transaction amount in the amount input page of the acquirer, triggering the acquirer to place an order; then, the payment is completed by the cashier desk of the payment institution, and then the payment institution notifies the acquirer of the payment result.

[0026] In the Push transaction mode, the payment institution provides the amount input page. In the entire transaction processing process, the user first enters the transaction amount in the amount input page of the payment institution and completes the payment at the cashier desk; then, the payment institution pushes (Push) the payment result to the acquirer and triggers the acquirer to place an order, thereby completing the payment confirmation.

[0027] The above two transaction modes both include processes such as entering the amount, the payment institution processing the payment, the acquirer placing an order, and the confirmation between the payment institution and the acquirer.

[0028] In some transaction scenarios, the national payment network is usually also involved. The national payment network is a payment network led by a national government agency such as the central bank, which usually connects the vast majority of payment institutions and acquirers in that country. In addition, in the offline payment scenario, the national payment network generally defines a unified national code standard.

[0029] In the national payment network Inbound scenario, the national payment network acts as the acquirer side and provides services to users based on the connected acquirers behind. The behavior of a user of a payment institution making a payment when entering the country where the national payment network is located is called national payment network Inbound.

[0030] In the research on payment networks in multiple countries, the transaction mode in the scenario of scanning static codes in the Inbound project of many national payment networks is the Push transaction mode. However, some payment institutions and many e-wallets only support the order placement transaction mode. In one application scenario, the transaction mode used in the user's original country is the order placement transaction mode, but when crossing the border to a country using the Push transaction mode, the payment service cannot be used normally.

[0031] Since some countries have national payment networks while some do not, for clearer and more concise expression, the acquirer is used below to represent the following two scenarios. One is the scenario without a national payment network, in which the acquirer represents the acquiring institution; the other is the scenario with a national payment network, in which the acquirer represents the national payment network and the acquiring institution. The payer is used to represent the payment institution, and the payer includes the payment server and / or e-wallet.

[0032] To solve the problem of incompatibility between the two transaction modes, the payer can be transformed, or the acquirer can be transformed. Since the transaction processing flows of the two transaction modes are quite different, whether the payer is transformed to support the Push transaction mode or the acquirer is transformed to support the order placement transaction mode, both have relatively high transformation costs. This will be further explained below.

[0033] Figure 2 FIG. is a transaction processing flowchart when the acquirer is transformed to support the order placement transaction mode in an embodiment. It involves users, payers, intermediate service providers, acquirers, and merchants. The acquirer includes the national payment network and the acquiring institution. The transformation idea is that the original transaction processing flow of the payer remains unchanged, and the acquiring institution is transformed to support the order placement transaction mode in the scenario of scanning static codes. Taking the Inbound scenario of the national payment network as an example, the specific transformation content of its acquiring institution is as follows.

[0034] The acquiring institution needs to newly provide an amount input page and set the uniform resource locator (URL) of the amount input page into the static code value of the merchant. At the same time, the acquiring institution needs to newly integrate an order placement interface.

[0035] After the user scans the code using the e-wallet, the e-wallet obtains the URL of the acquirer's amount input page from the code value and jumps to the amount input page. After the user enters the amount on the amount input page and confirms the payment, it triggers the acquirer to place an order. After the acquirer finishes placing the order, it sends the order information containing the amount and the information of both trading parties to the intermediate service party through the national payment network, enabling the intermediate service party to place an order and generate an order code for the order information. The intermediate service party sends the decoding address carrying the order code to the merchant through the national payment network and the acquirer, and it is intercepted by the Software Development Kit (SDK) of the e-wallet. The e-wallet decodes the order code from the decoding address and obtains the order information from the intermediate service party. The e-wallet renders the cashier desk and completes the payment. After the user confirms the payment, the e-wallet sends the payment result notification to the intermediate service party. The intermediate service party forwards the payment result notification to the merchant through the national payment network and the acquirer.

[0036] The acquirer needs to newly integrate the payment result notification interface to advance the payment transaction status after receiving the payment result notification from the payer. In this transformation, the acquirer's transaction processing flow is quite different from the original Push transaction mode, involving the upgrade and transformation of interfaces such as the front-end amount input page, back-end order placement, and payment result notification, with a relatively large overall integration and R & D cost. Also, since the URL of the amount input page needs to be set in the merchant's static code value, the static code materials on the acquirer side need to be re-laid, resulting in a relatively large operation cost.

[0037] Figure 3 It is a transaction processing flow chart when the payer is transformed to support the Push transaction mode in an embodiment. It involves the user, payer, intermediate service party, acquirer, and merchant. The acquirer includes the national payment network and the acquirer institution. The transformation idea is that the transaction processing flow on the acquirer side remains unchanged, and the payer is transformed to support the Push transaction mode for the positive-scan static code scenario. The specific transformation content of the payer is as follows.

[0038] The payer provides a front-end amount input page. When the user scans the code using the e-wallet, the e-wallet obtains the code value and jumps to the amount input page provided by the payer, and then performs code verification. The payer sends the code verification request to the intermediate service provider, and the intermediate service provider forwards it to the acquirer through the national payment network. The acquirer forwards the code verification result to the payer through the national payment network and the intermediate service provider. When the code verification result indicates passing, the amount input page allows the user to input the amount. The user inputs the amount and confirms the payment. The payer places an order, that is, determines the order information including the amount and the information of both trading parties, and renders the cashier desk. At the same time, the intermediate service provider also performs the order placement operation and generates an order code. The user confirms the payment at the cashier desk. After the payment is completed, the payer sends a payment confirmation request to the intermediate service provider. The intermediate service provider sends the payment confirmation request to the acquirer through the national payment network. The acquirer places an order and confirms the merchant payment result, and sends the merchant payment result to the payer through the national payment network and the intermediate service provider. At the same time, the acquirer notifies the merchant of the merchant payment result. When the acquirer confirms the payment failure, the payer cancels the payment and notifies the user of the cancellation result.

[0039] When the user clicks to complete the payment on the payer's payment result page, the payer will jump to the merchant payment result page provided by the payer. At the same time, the payer will send a query request for querying the merchant payment result to the intermediate service provider. The intermediate service provider sends the query request to the acquirer through the national payment network. The acquirer feeds back the query result to the payer through the national payment network and the intermediate service provider. The payer displays the query result on the merchant payment result page.

[0040] The above transformation involves the payer providing the front-end amount input page and the merchant payment result page, as well as the upgrade transformation of the back-end payment confirmation, payment confirmation query and other interfaces, and the overall integrated R & D cost is also relatively large.

[0041] It should be noted that Figure 2 and Figure 3 In the embodiment, the scenario where the acquirer includes the national payment network and the acquirer is taken as an example for illustration. In the actual application scenario, some countries do not have the national payment network participating in the transaction processing process. Therefore, it is also possible to remove Figure 2 and Figure 3 the national payment network in the embodiment, that is, the intermediate service provider directly communicates and interacts with the acquirer.

[0042] To solve the problem that two transaction modes cannot be compatible and to achieve zero upgrade and transformation costs for both the payer and the payee, this specification provides an electronic payment method in an embodiment that can solve the above technical problems. This method involves the intermediate service provider providing a unified amount input page. After the payer scans the merchant's static code, the payer sends the scanned code information to the amount input page. In response to the transaction amount input by the user, the amount input page determines the order information based on the code information and sends it to the intermediate service provider. The payer obtains the order information through interaction with the intermediate service provider and performs a payment operation based on the order information, thereby sending a payment result notification to the intermediate service provider. The intermediate service provider converts the payer's payment result notification into a confirmation payment request sent to the payee and simultaneously receives the merchant payment result feedback. This payment method does not require upgrading and transformation of the payer and the payee, and at the same time can accommodate the differences in the transaction processing flows between the order placement transaction mode of the payer and the Push transaction mode of the payee, greatly reducing the access cost of the payee in the Push transaction mode. The above technical solution is described in detail below.

[0043] Figure 4 A flowchart of an electronic payment method provided for the embodiment. The execution process involves users, payers, amount input pages, merchant payment result pages, intermediate service providers, payees, and merchants. Among them, the amount input page and the merchant payment result page are provided by the intermediate service provider.

[0044] The payer generally includes a payment server and an e-wallet. The e-wallet executes the transaction processing flow through interaction with the payment server. In this embodiment, the operations performed by the payer can also be understood as being executed through the e-wallet. One e-wallet can correspond to one electronic payment channel. In some examples, different banks have their own electronic payment applications, so a single e-wallet can include the payment channels of a single bank. In some examples, the e-wallet can also be a payment channel provided by a third party, such as Alipay, etc.

[0045] The amount input page, as an independent intermediate page, can be implemented through a browser or an application. The amount input page is between the payer and the intermediate service provider and is used for users to input the transaction amount and can execute predetermined processing logics, such as receiving code information, determining order information, and sending order information, etc.

[0046] The intermediate service provider acts as an intermediate or agency between the payer and the payee and is used for placing orders, providing order information, sending payment confirmation requests to the payee, and receiving the merchant payment results of the payee, etc.

[0047] The acquirer can refer to only the acquiring institution or a combination of the national payment network and the acquiring institution. For the convenience of description, in the following description, the case where the acquirer only refers to the acquiring institution is taken as an example for illustration.

[0048] As mentioned above, a merchant is a service platform that provides tradable service items including goods. Typically, a merchant can be an e-commerce platform, a paid content platform, or a physical store selling goods. In the scenario of scanning a static code face-up, the merchant mainly refers to an offline physical store with a static code pasted on it.

[0049] With the help of the amount input page and the intermediate service provider, the payer and the acquirer can respectively follow the original transaction execution process without the need for upgrading and transformation, thus realizing the compatibility of the two transaction modes. The following is a detailed description of this embodiment.

[0050] In step S410, after the payer scans the static code of the merchant, the scanned code information is sent to the amount input page.

[0051] In an offline payment scenario, the user can use an e-wallet to scan the static code provided by the merchant to initiate a payment for the transaction. After scanning the static code, the e-wallet can obtain the code information of the static code. The code information can include information such as the merchant name and merchant identifier.

[0052] In response to the operation of the e-wallet scanning the static code of the merchant, the e-wallet can jump to the amount input page and render the amount input page for the user to enter the transaction amount. The e-wallet can be pre-integrated with an SDK configured by the intermediate service provider, and the address of the amount input page can be pre-configured in the SDK. In this way, when the user uses the e-wallet to scan the static code, in response to this operation, the SDK jumps to the amount input page.

[0053] The SDK, i.e., the software development kit, is a toolkit used to be integrated into the e-wallet to assist in electronic payment. Integrating the SDK into the e-wallet can achieve the jump to the amount input page without the need for upgrading and transformation of the e-wallet.

[0054] In step S420, in response to the transaction amount input by the user, the amount input page determines the order information based on the received code information and sends the order information to the intermediate service provider. The intermediate service provider receives the order information sent by the amount input page and stores the order information, thus realizing the order placement operation; then, when the intermediate service provider receives the order information sent by the amount input page, it can generate the decoding address of the order information, and the decoding address contains the order code corresponding to the order information. The order code is used to identify the order information.

[0055] When the amount input page obtains the transaction amount and the code information, the order information such as the transaction amount and the information of both parties to the transaction is determined. When the amount input page determines the order information, the order placement process is realized.

[0056] To reduce the probability that the payer pays successfully while the payee confirms payment failure and ensure the user payment experience, during the process of rendering the amount input page, the acquirer can be called for code verification. That is, before step S420, the code verification process of step S412 can also be included. The specific implementation process is as follows.

[0057] In response to the code information received from the e-wallet, the amount input page sends a code verification request carrying the code information to the intermediate service provider.

[0058] The intermediate service provider receives the code verification request sent by the amount input page and sends the code verification request to the acquirer.

[0059] The acquirer receives the code verification request sent by the intermediate service provider, verifies the code information based on the code verification request, and feeds back the code verification result to the amount input page through the intermediate service provider. The acquirer can obtain the code information from the code verification request and verify the code information based on the merchant information stored by itself. For example, it can verify whether the static code format is incorrect, whether the corresponding merchant has problems, etc. The process by which the acquirer determines the code verification result based on the code information can reuse the original processing flow. The acquirer sends the code verification result to the intermediate service provider, and the intermediate service provider sends the code verification result to the amount input page.

[0060] The amount input page receives the code verification result sent by the intermediate service provider and allows the input of the transaction amount when the code verification result indicates that the verification is passed. When the code verification result indicates that the verification fails, the input of the transaction amount is not allowed.

[0061] In the user's perception, after the user scans the code through the e-wallet, the user is redirected to the amount input page, which displays the merchant name and an input box for the transaction amount to be entered. When the user enters the amount in the input box and confirms the payment, the amount input page is triggered to place an order, that is, the order information is determined.

[0062] In step S430, the payer obtains the order information from the intermediate service provider.

[0063] Specifically, after placing an order and generating an order code, the intermediate service provider can send the decoding address containing the order code to the amount input page. The e-wallet can intercept the decoding address sent to the amount input page through the integrated SDK. Intercepting the decoding address through the integrated SDK is not the only interception method, and the e-wallet can also intercept the decoding address through other means.

[0064] The e-wallet can obtain order information from the intermediate service provider based on the decoded address. Specifically, the e-wallet can decode the order code from the decoded address and obtain the order information from the intermediate service provider based on the order code. The decoding process of the payer can reuse the original processing flow.

[0065] In step S440, the payer performs a payment operation based on the order information and sends a payment result notification to the intermediate service provider. The payment result notification is used to indicate that the payer has confirmed the completion of the payment. After the payer obtains the merchant name and transaction amount in the order information, the payer can perform the payment operation. This payment operation is for the order corresponding to the order information.

[0066] Specifically, the e-wallet can render the cashier desk. The user can select a payment method, etc. in the cashier desk and click to confirm the payment. The e-wallet completes the payment after the user confirms the payment. The steps for the payer to perform the payment operation based on the order information can reuse the original transaction processing flow.

[0067] In step S450, the intermediate service provider receives the payment result notification sent by the payer and sends a payment confirmation request to the acquirer based on the payment result notification. The intermediate service provider converts the payment result notification sent by the payer into a payment confirmation request for calling the acquirer.

[0068] The payment confirmation request carries information about both parties to the transaction, the transaction amount, etc. This payment confirmation request is used to request the acquirer to confirm whether the payment can be successfully made.

[0069] In step S460, the acquirer receives the payment confirmation request sent by the intermediate service provider, determines the merchant payment result based on the payment confirmation request, and feeds back the merchant payment result to the intermediate service provider.

[0070] The acquirer can perform an order placement operation based on the information about both parties to the transaction and the transaction amount carried in the payment confirmation request and confirm the merchant payment result. This merchant payment result includes confirming successful payment and confirming failed payment. Specifically, the acquirer can check whether the transaction amount exceeds the limit, whether the merchant's account is abnormal, etc., and determine whether the payment on the merchant side is successful based on these situations. The process for the acquirer to confirm the merchant payment result can reuse the original transaction processing flow.

[0071] In this embodiment, the payer pays first, and after successful payment, it is pushed to the acquirer for payment confirmation. The acquirer feeds back the merchant payment result.

[0072] When the merchant payment result indicates a failed payment, this embodiment can also include step S470, that is, the intermediate service provider can send a payment cancellation instruction to the payer. The payer cancels the above payment when receiving the payment cancellation instruction.

[0073] After the payer cancels the above payment, the payer may send the cancellation result to the intermediate service provider. The payer may notify the user of the cancellation result. For example, the user may be notified that the payment has been cancelled and the amount will be refunded to the original payment path within a certain period of time, etc.

[0074] The intermediate service provider also provides a merchant payment result page for presenting the merchant payment result to the user. After the user completes the payment at the cashier, the payer may present the payment result page to the user. When the user clicks to complete the payment on the payment result page, that is, when the payer receives the operation of the user triggering the completion of payment on the payment result page, the page may jump to the merchant payment result page. Based on this, in one embodiment, the payment method may further include step S480, that is, the payer jumps to the merchant payment result page in response to the operation of the user inputting to confirm the completion of payment. In response to this jump, the merchant payment result page sends a query request to the intermediate service provider, and the query request is used to query the merchant payment result of the acquirer. Specifically, the e-wallet in the payer may jump to the merchant payment result page through the integrated SDK. The SDK is configured by the intermediate service provider, and the address of the merchant payment result page may be pre-configured in the SDK.

[0075] When the merchant payment result page receives the merchant payment result fed back by the intermediate service provider, it presents the merchant payment result. The presented merchant payment result may include results such as the merchant confirming the payment, the merchant payment being successful, or the merchant payment failing, etc.

[0076] When the intermediate service provider receives the above query request and has not yet received the merchant payment result fed back by the acquirer side in step S460, the intermediate service provider may query the merchant payment result from the acquirer and send the merchant payment result to the merchant payment result page. The intermediate service provider may send a query request to the acquirer, and when the acquirer receives the query request, it feeds back the merchant payment result to the intermediate service provider. When the acquirer receives the query request, it may reuse the original process to handle the query request.

[0077] If, when the intermediate service provider receives the above query request, it has already received the merchant payment result fed back by the acquirer in step S460, then the intermediate service provider may directly feed back the merchant payment result to the merchant payment result page.

[0078] In the perception of the user, after the user completes the payment at the cashier, the payer presents the payment result page to the user. After the user clicks to complete the payment on the payment result page, the page jumps to the merchant payment result page, presenting the payment result on the merchant side to the user. In this way, the user can know their own payment situation from the payment result page and know the merchant's collection situation from the merchant payment result page.

[0079] In this embodiment, since the payment result page of the payer only shows the payment result of the payer and does not perceive the merchant payment situation of the acquirer, and in the Push transaction mode, the acquirer generally does not provide a page for displaying the merchant payment result. Therefore, the intermediate service provider provides a unified merchant payment result page to display the result of whether the merchant's payment is successful, thus ensuring the user payment experience.

[0080] The above content takes the case where the acquirer only refers to the acquiring institution as an example to elaborate on the payment process in detail. When the implementation scenario includes a national payment network, Figure 4 The execution process of the acquirer in the embodiment can be specifically executed in the following manner.

[0081] In step S412, when the intermediate service provider receives the code verification request sent by the amount input page, it can forward the code verification request to the acquiring institution through the national payment network. Specifically, the intermediate service provider can send the code verification request to the national payment network, and the national payment network then sends the code verification request to the acquiring institution. The acquiring institution receives the code verification request forwarded by the national payment network, verifies the code information based on the code verification request, and feeds back the code verification result to the amount input page through the national payment network and the intermediate service provider.

[0082] In step S450, when the intermediate service provider receives the payment result notification sent by the payer, it can send a payment confirmation request to the acquiring institution through the national payment network based on the payment result notification.

[0083] In step S460, the acquiring institution receives the payment confirmation request forwarded through the national payment network, determines the merchant payment result based on the payment confirmation request, and feeds back the merchant payment result to the intermediate service provider through the national payment network. Among them, the acquiring institution sends the merchant payment result to the national payment network, and the national payment network then forwards the merchant payment result to the intermediate service provider.

[0084] When the intermediate service provider receives the query request but has not received the merchant payment result fed back by the acquiring institution in step S460, the intermediate service provider can query the merchant payment result from the acquiring institution through the national payment network and send the merchant payment result to the merchant payment result page.

[0085] The above embodiments are obtained by improving on the Figure 4 basis, and their description focuses on the Figure 4 differences from the Figure 4 embodiments. The same or corresponding parts can be referred to the

[0086] In summary, the embodiments of this specification provide a compatibility method for the acquirer Push transaction mode in the scenario of offline payment by scanning a static code in the positive direction, which can ensure that both the payment side and the acquirer side are unaware, and on the premise of ensuring the user payment experience, it is compatible with the transaction processing flow differences between the existing payment-side order placement transaction mode and the acquirer-side Push transaction mode, greatly reducing the access costs of the Push transaction mode for the national payment network and acquirers.

[0087] When the user's e-wallet scans the static code and recognizes that it is a static code issued by an acquirer in a certain country and the Push transaction mode is used in that country, the electronic payment method provided by the embodiments of this specification will be launched. Thus, the user can perform offline electronic payment well in that country without problems such as incompatibility and inability to use, thereby improving the user service experience.

[0088] In this specification, the intermediate service provider can be implemented by any device, equipment, platform, device cluster, etc. with computing and processing capabilities.

[0089] The above content describes specific embodiments of this specification, and other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be executed in a different order than in the embodiments, and the desired results can still be achieved. Additionally, the processes depicted in the drawings do not necessarily have to be executed in the specific order or continuous order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0090] Figure 5 A schematic block diagram of an electronic payment device deployed in an intermediate service provider provided for the embodiment. This device embodiment corresponds to Figure 4 the method executed by the intermediate service provider. The device 500 includes: a first receiving module 510 configured to receive order information sent by the amount input page, where the order information is determined by the amount input page in response to the transaction amount input by the user based on the received code information, and the code information is sent by the payer after scanning the merchant's static code, and the amount input page is provided by the intermediate service provider; a first sending module 520 configured to send the order information to the payer; a second receiving module 530 configured to receive the payment result notification sent by the payer, where the payment result notification is sent by the payer after performing a payment operation based on the order information; a second sending module 540 configured to send a payment confirmation request to the acquirer based on the payment result notification; and a third receiving module 550 configured to receive the merchant payment result fed back by the acquirer, where the merchant payment result is determined by the acquirer based on the payment confirmation request.

[0091] Figure 6 Schematic diagram of the logical structure of an electronic payment device deployed on an amount input page provided for an embodiment. This device embodiment corresponds to Figure 4 the method executed on the amount input page. The amount input page is provided by an intermediate service provider. The device 600 includes: a fourth receiving module 610 configured to receive code information sent by a payer; the code information is obtained after the payer scans a static code of a merchant; a third sending module 620 configured to, in response to a transaction amount input by a user, determine order information based on the received code information, and send the order information to the intermediate service provider.

[0092] Each of the above device embodiments corresponds to a method embodiment. For specific descriptions, reference can be made to the description in the method embodiment section, which will not be elaborated here. The device embodiment is obtained based on the corresponding method embodiment and has the same technical effects as the corresponding method embodiment. For specific descriptions, reference can be made to the corresponding method embodiment.

[0093] This specification also provides a computer-readable non-volatile storage medium, in which a computer program is stored. When executed by a processor, the computer program can be used to execute one or more steps of one or more methods described or shown herein, or provide the functions described or shown herein. Herein, the computer-readable non-volatile storage medium or media may include one or more based on semiconductors or other integrated circuits (ICs) (e.g., field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs)), hard disk drives (HDDs), hybrid hard disks (HHDs), optical discs, optical disc drives (ODDs), magneto-optical discs, magneto-optical drives, floppy disks, floppy disk drives (FDDs), magnetic tapes, solid-state drives (SSDs), RAM drives, secure digital cards or drives, any other suitable computer-readable non-volatile storage medium, or any suitable combination of these in appropriate cases. The computer-readable non-volatile storage medium can be volatile, non-volatile, or a combination of volatile and non-volatile.

[0094] The embodiments of this specification also provide two sets of computer systems, which can be implemented based on the same hardware system, and the difference lies in the different codes executed. Figure 7FIG. 1000 shows an example computer system 1000. In certain embodiments, one or more computer systems 1000 perform one or more steps of one or more methods described or shown herein. In certain embodiments, one or more computer systems 1000 provide the functionality described or shown herein. In certain embodiments, software running on one or more computer systems 1000 performs one or more steps of one or more methods described or shown herein, or provides the functionality described or shown herein. Certain embodiments include one or more portions of one or more computer systems 1000. Here, references to computer systems may include computing devices, and vice versa, where appropriate. Additionally, references to computer systems may include one or more computer systems, where appropriate.

[0095] This application contemplates any suitable number of computer systems 1000. This application contemplates computer systems 1000 in any suitable physical form. By way of example, and not limitation, computer system 1000 may be an embedded computer system, a system-on-chip (SOC), a single-board computer system (SBC) (e.g., a computer-on-module (COM) or system-on-module (SOM)), a desktop computer system, a notebook or laptop computer system, an interactive kiosk, a mainframe, a grid of computer systems, a mobile phone, a personal digital assistant (PDA), a server, a tablet computer system, or any suitable combination thereof. Where appropriate, computer system 1000 may include one or more computer systems 1000; be single or distributed; span multiple locations; span multiple machines; span multiple data centers; or reside in the cloud, which may include one or more cloud components in one or more networks. Where appropriate, one or more computer systems 1000 may perform one or more steps of one or more methods described or shown herein without substantial spatial or temporal limitation. For example, and not by way of limitation, one or more computer systems 1000 may perform one or more steps of one or more methods described or shown herein in real time or in batch mode. Where appropriate, one or more computer systems 1000 may perform one or more steps of one or more methods described or shown herein at different times or at different locations.

[0096] In certain embodiments, computer system 1000 includes a processor 1002, a memory 1004, a storage 1006, an input / output (I / O) interface 1008, a communication interface 1010, and a bus 1012. Although this application describes and shows a particular computer system having a particular number of particular components in a particular arrangement, this application contemplates any suitable computer system having any suitable number of any suitable components in any suitable arrangement.

[0097] In a particular embodiment, the processor 1002 includes hardware for executing instructions, such as those that make up a computer program. By way of example and not limitation, to execute instructions, the processor 1002 may retrieve (or fetch) the instructions from an internal register, internal cache, memory 1004, or storage 1006; decode and execute them; and then write one or more results to an internal register, internal cache, memory 1004, or storage 1006. In a particular embodiment, the processor 1002 may include one or more internal caches for data, instructions, or addresses. This application contemplates that, where appropriate, the processor 1002 may include any suitable number of any suitable internal caches. By way of example and not limitation, the processor 1002 may include one or more instruction caches, one or more data caches, and one or more translation lookaside buffers (TLBs). The instructions in the instruction cache may be copies of the instructions in memory 1004 or storage 1006, and the instruction cache may speed up retrieval of those instructions by the processor 1002. The data in the data cache may be copies of the data in memory 1004 or storage 1006 for operations by instructions executed at the processor 1002; results of instructions previously executed at the processor 1002 for access or writing to memory 1004 or storage 1006 by subsequent instructions executed at the processor 1002; or other suitable data. The data cache may speed up read or write operations by the processor 1002. The TLB may speed up virtual address translation by the processor 1002. In a particular embodiment, the processor 1002 may include one or more internal registers for data, instructions, or addresses. This application contemplates that, where appropriate, the processor 1002 may include any suitable number of any suitable internal registers. Where appropriate, the processor 1002 may include one or more arithmetic logic units (ALUs); be a multi-core processor; or include more than one processor 1002. Although this application describes and illustrates particular processors, this application contemplates any suitable processor.

[0098] In a particular embodiment, the memory 1004 includes a main memory for storing instructions to be executed by the processor 1002 or data to be operated on by the processor 1002. By way of example and not limitation, the computer system 1000 can load instructions into the memory 1004 from the memory 1006 or other sources (e.g., another computer system 1000). Then, the processor 1002 can load the instructions from the memory 1004 into internal registers or an internal cache. To execute the instructions, the processor 1002 can retrieve the instructions from the internal registers or internal cache and decode them. During or after executing the instructions, the processor 1002 can write one or more results (which may be intermediate or final results) to the internal registers or internal cache. Then, the processor 1002 can write one or more of these results to the memory 1004. In a particular embodiment, the processor 1002 executes instructions only in one or more internal registers or internal cache or the memory 1004 (and not in the memory 1006 or elsewhere), and operates on data only in one or more internal registers or internal cache or the memory 1004 (and not in the memory 1006 or elsewhere). One or more memory buses (each of which can include an address bus and a data bus) can couple the processor 1002 to the memory 1004. The bus 1012 can include one or more memory buses as described below. In a particular embodiment, one or more memory management units (MMUs) are located between the processor 1002 and the memory 1004 and facilitate access to the memory 1004 requested by the processor 1002. In a particular embodiment, the memory 1004 includes random access memory (RAM). In an appropriate case, this RAM can be volatile memory. In an appropriate case, this RAM can be dynamic RAM (DRAM) or static RAM (SRAM). Additionally, in an appropriate case, this RAM can be single-port or multi-port RAM. This application contemplates any suitable RAM. In an appropriate case, the memory 1004 can include one or more memories 1004. Although this application describes and illustrates particular memories, this disclosure contemplates any suitable memory.

[0099] In a particular embodiment, the memory 1006 includes mass storage for data or instructions. By way of example and not limitation, the memory 1006 may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disk, a magneto-optical disk, a tape, or a universal serial bus (USB) drive or a combination of more than two of these. Where appropriate, the memory 1006 may include removable or non-removable (or fixed) media. Where appropriate, the memory 1006 may be internal or external to the computer system 1000. In a particular embodiment, the memory 1006 is non-volatile solid state memory. In a particular embodiment, the memory 1006 includes read-only memory (ROM). Where appropriate, this ROM may be mask-programmed ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM), or flash memory or a combination of more than two of these. This application contemplates that the memory 1006 may take any suitable physical form. Where appropriate, the memory 1006 may include one or more storage control units to facilitate communication between the processor 1002 and the memory 1006. Where appropriate, the memory 1006 may include more than one memory 1006. Although this application describes and illustrates particular storage, this application contemplates any suitable storage.

[0100] In a particular embodiment, the I / O interface 1008 includes hardware, software, or both to provide one or more interfaces between the computer system 1000 and one or more I / O devices. Where appropriate, the computer system 1000 may include one or more of these I / O devices. One or more of these I / O devices may enable communication between a person and the computer system 1000. By way of example and not limitation, the I / O devices may include a keyboard, a keypad, a microphone, a display, a mouse, a printer, a scanner, a speaker, a still camera, a stylus, a tablet computer, a touch screen, a trackball, a video camera, other suitable I / O devices, or a combination of more than two of these. The I / O devices may include one or more sensors. This application contemplates any suitable I / O devices and any suitable I / O interface 1008 for them. Where appropriate, the I / O interface 1008 may include one or more device or software drivers to enable the processor 1002 to drive one or more of these I / O devices. Where appropriate, the I / O interface 1008 may include more than one I / O interface 1008. Although this application describes and illustrates a particular I / O interface, this disclosure contemplates any suitable I / O interface.

[0101] In a particular embodiment, communication interface 1010 includes hardware, software, or both (e.g., packet-based communication) that provides one or more communication interfaces between computer system 1000 and one or more other computer systems 1000 or one or more networks. By way of example and not limitation, communication interface 1010 can include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wired network, or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network (e.g., a Wi-Fi network). This application contemplates any suitable network and any suitable communication interface 1010 for it. By way of example and not limitation, computer system 1000 can communicate with an ad hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or one or more portions of the Internet or a combination of two or more of these. One or more portions of these networks can be wired or wireless. For example, computer system 1000 can communicate with a wireless personal area network (WPAN) (e.g., a Bluetooth WPAN), a Wi-Fi network, a Wi-Max network, a cellular telephone network (e.g., a Global System for Mobile Communications (GSM) network), or other suitable wireless networks or a combination of two or more of these. In appropriate instances, computer system 1000 can include any suitable communication interface 1010 for any of these networks. In appropriate instances, communication interface 1010 can include one or more communication interfaces 1010. Although this application describes and shows particular communication interfaces, this application contemplates any suitable communication interface.

[0102] In a particular embodiment, bus 1012 includes hardware, software, or both that interconnects components of computer system 1000 with each other. By way of example and not limitation, bus 1012 can include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a HYPERTRANSPORT (HT) interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBAND interconnect, a Low Pin Count (LPC) bus, a memory bus, a MicroChannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCIe) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable bus or a combination of two or more of these. In appropriate instances, bus 1012 can include one or more buses 1012. Although this application describes and shows particular buses, this application contemplates any suitable bus or interconnect.

[0103] In this specification, the "first" in certain terms, and the corresponding "second" (if any), are for convenience of distinction and description only and have no limiting significance.

[0104] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the embodiments of the storage medium and the computing device, since they are basically similar to the method embodiments, the description is relatively simple, and reference can be made to the corresponding parts of the method embodiments for the relevant content.

[0105] Those skilled in the art should be able to realize that in one or more of the above examples, the functions described in the embodiments of the present invention can be implemented by hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium.

[0106] The specific embodiments described above further elaborate on the objectives, technical solutions, and beneficial effects of the embodiments of the present invention. It should be understood that the above description is only the specific embodiments of the embodiments of the present invention and is not used to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of the present invention should be included in the protection scope of the present invention.

Claims

1. An electronic payment method, comprising: After scanning the merchant's static code, the payer sends the scanned code information to the amount input page; the amount input page is provided by the intermediary service provider; The amount input page determines order information based on the received code information in response to the transaction amount input by the user, and sends the order information to the intermediate service provider; The payer obtains the order information from the intermediate service provider, performs a payment operation based on the order information, and sends a payment result notification to the intermediate service provider; The intermediary service provider sends a payment confirmation request to the acquirer based on the payment result notification; The acquirer determines the merchant payment result based on the payment confirmation request, and feeds back the merchant payment result to the intermediate service provider.

2. An electronic payment method, performed by an intermediary service provider, comprising: receiving order information sent by an amount input page, wherein the order information is determined by the amount input page in response to the transaction amount input by the user and based on the received code information, wherein the code information is sent by the payer after scanning the static code of the merchant, and the amount input page is provided by the intermediate service provider; Sending the order information to the payer; receiving a payment result notification sent by the payee, wherein the payment result notification is sent by the payee after performing a payment operation based on the order information; Based on the payment result notification, sending a payment confirmation request to the acquirer; The merchant payment result fed back by the acquirer is received, where the merchant payment result is determined by the acquirer based on the payment confirmation request.

3. The method according to claim 2, before receiving the order information sent by the amount input page, the method further comprises: Receiving a code verification request carrying the code information sent by the amount input page; forwarding the code verification request to the acquirer; receiving a code verification result sent by the acquirer, wherein the code verification result is obtained by the acquirer verifying the code information based on the code verification request; The code verification result is sent to the amount input page, so that the amount input page allows the transaction amount to be entered when the code verification result indicates that the verification is passed.

4. The method according to claim 2, further comprising: When the order information sent by the amount input page is received, a decoding address corresponding to the order information is determined, and the decoding address is sent to the amount input page, so that the payer intercepts the decoding address.

5. The method according to claim 2, further comprising: When the merchant payment result indicates that the payment fails, a payment cancellation instruction is sent to the payee, so that the payee cancels the payment upon receiving the payment cancellation instruction.

6. The method according to claim 2, further comprising: Receiving a query request sent by a merchant payment result page; wherein the merchant payment result page is provided by the intermediary service provider, and the query request is used to query the merchant payment result; the query request is sent by the merchant payment result page in response to a jump operation of the payee to the merchant payment result page, and the jump operation is performed by the payee when receiving a confirmation payment operation of the user; When the merchant payment result has been received, the merchant payment result is sent to the merchant payment result page.

7. The method according to claim 6, further comprising: When the merchant payment result is not received, the merchant payment result is queried from the acquirer, and the queried merchant payment result is sent to the merchant payment result page.

8. An electronic payment method, performed through an amount input page, the amount input page being provided by an intermediary service provider; the method comprising: Receive the code information sent by the payer; The code information is obtained by the payer after scanning the merchant's static code; In response to the transaction amount input by the user, order information is determined based on the received code information, and the order information is sent to the intermediate service provider.

9. The method according to claim 8, further comprising: In response to the code information received from the payer, sending a code verification request carrying the code information to the intermediate service provider; Receiving the code verification result forwarded by the intermediate service provider; The code verification result is obtained by the acquirer verifying the code information based on the code verification request; When the code verification result indicates that the verification is passed, the transaction amount can be entered.

10. An electronic payment system, comprising an amount input page and an intermediate service provider; After scanning the merchant's static code, the payer sends the scanned code information to the amount input page; the amount input page is provided by the intermediate service provider; The amount input page is used to determine order information based on the received code information in response to the transaction amount input by the user, and send the order information to the intermediate service provider; The payer obtains the order information from the intermediate service provider, performs a payment operation based on the order information, and sends a payment result notification to the intermediate service provider; The intermediary service provider is used to send a payment confirmation request to the acquirer based on the payment result notification; The acquirer determines the merchant payment result based on the payment confirmation request, and feeds back the merchant payment result to the intermediate service provider.

11. An electronic payment device, deployed in an intermediate service provider, comprising: A first receiving module is configured to receive order information sent by an amount input page, wherein the order information is determined by the amount input page in response to a transaction amount input by a user based on received code information, wherein the code information is sent by the payer after scanning a static code of a merchant, and the amount input page is provided by the intermediate service provider; A first sending module, configured to send the order information to the payer; A second receiving module is configured to receive a payment result notification sent by the payee, wherein the payment result notification is sent by the payee after performing a payment operation based on the order information; A second sending module, configured to send a payment confirmation request to the acquirer based on the payment result notification; The third receiving module is configured to receive the merchant payment result fed back by the acquirer, where the merchant payment result is determined by the acquirer based on the payment confirmation request.

12. An electronic payment device, deployed in an amount input page, the amount input page being provided by an intermediary service provider; the device comprising: A fourth receiving module, configured to receive code information sent by the payer; The code information is obtained by the payer after scanning the merchant's static code; The third sending module is configured to determine order information based on the received code information in response to the transaction amount input by the user, and send the order information to the intermediate service provider.

13. A computer-readable non-volatile storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 9 is implemented.

14. A computing device, comprising a memory and a processor, wherein the memory stores executable codes, and when the processor executes the executable codes, the method according to any one of claims 1 to 9 is implemented.

Images