Payment method, apparatus, device, storage medium and program product

Abstract

This application discloses a payment method, apparatus, device, storage medium, and program product. The method, applied to a payment terminal, includes: receiving the order amount of a first order sent by an acquiring system, wherein the order amount is obtained by the acquiring system from a graphic code transaction request, the graphic code transaction request being generated by a merchant system based on the first order and its corresponding target graphic code, the target graphic code being generated based on basic card data, and the basic card data being read by the payment terminal in response to a graphic code generation request corresponding to the first order sent by the merchant system; determining a password input scheme based on the order amount and preset password-free rules; acquiring target card data based on the password input scheme, the target card data including at least the order amount and basic card data; and sending the target card data to the acquiring system, so that the acquiring system performs payment based on the target card data and the graphic code transaction request. According to the embodiments of this application, both payment security and convenience are ensured.

Description

Technical Field

[0001] This application belongs to the field of payment technology, and in particular relates to a payment method, device, equipment, storage medium and program product. Background Technology

[0002] With the rapid development of payment technology, integrated payment terminals that combine functions such as card swiping, contactless payment, and QR code scanning are becoming increasingly popular, and plug-and-play payment solutions based on these terminals have also emerged.

[0003] The existing plug-and-play payment process is as follows: After a user makes a card swipe or contactless payment through an integrated payment terminal (hereinafter referred to as the terminal), the terminal uploads the read bank card transaction message to the acquiring institution; the acquiring institution generates a QR code corresponding to the message and returns it to the terminal; the terminal transmits the QR code to the merchant's Management Information (MIS) system; the MIS system then uses the QR code as a payment credential to complete the transaction through the QR code payment channel. This solution integrates bank card payment and QR code payment channels, reducing the cost for merchants to modify their existing MIS systems.

[0004] However, in practical applications, the above solutions, while requiring a password for every transaction to ensure security, severely sacrifice the convenience of small-amount payments, resulting in a poor user experience. Conversely, if passwords are not collected by default and only small-amount password-free transactions are supported, payment will be interrupted once the transaction amount exceeds the password-free limit, similarly reducing the user experience. Therefore, there is an urgent need for a plug-and-play payment method based on an integrated payment terminal to simultaneously ensure payment security and convenience, thereby improving the user's payment experience. Summary of the Invention

[0005] This application provides a payment method, device, electronic device, computer-readable storage medium, and computer program product that avoids the cumbersome operation of mandatory password input for small-amount payments while ensuring password verification for large-amount payments, thereby simultaneously guaranteeing payment security and convenience and improving the user's payment experience.

[0006] In a first aspect, embodiments of this application provide a payment method applied to a payment terminal, the method comprising: The system receives the order amount of the first order sent by the acquiring system. The order amount is obtained by the acquiring system from the graphic code transaction request. The graphic code transaction request is generated by the merchant system based on the first order and its corresponding target graphic code. The target graphic code is generated based on the basic card data. The basic card data is read by the payment terminal in response to the graphic code generation request sent by the merchant system corresponding to the first order. Based on the order amount and the preset password-free rules, a password input scheme is determined; Based on the password input scheme, target card data is obtained, wherein the target card data includes at least the order amount and the basic card data; The target card data is sent to the acquiring system so that the acquiring system can make payment based on the target card data and the graphic code transaction request.

[0007] Secondly, embodiments of this application provide a payment method applied to an acquiring system, the method comprising: The system receives a graphic code transaction request sent by the merchant system. The graphic code transaction request is generated based on the first order and its corresponding target graphic code. The target graphic code is generated based on basic card data. The basic card data is read by the payment terminal in response to the graphic code generation request sent by the merchant system corresponding to the first order. Parse the graphic code transaction request to obtain the order amount of the first order; The order amount is sent to the payment terminal so that the payment terminal determines a password input scheme based on the order amount and a preset password-free rule, and obtains target card data based on the password input scheme. The target card data includes at least the order amount and the basic card data. Receive the target card data sent by the payment terminal; Payment is made based on the target card data and the graphic code transaction request.

[0008] Thirdly, embodiments of this application provide a payment method applied to a merchant system, the method comprising: Generate a graphic code generation request corresponding to the first order; Send the graphic code generation request to the payment terminal; The payment terminal receives a target graphic code returned in response to the graphic code generation request, wherein the target graphic code is generated by the payment terminal based on the read basic card data. Based on the first order and the target graphic code, generate a graphic code transaction request; The acquiring system sends the graphic code transaction request to the acquiring system, so that the acquiring system can parse the graphic code transaction request to obtain the order amount, obtain the target card data based on the order amount, and make payment based on the target card data and the graphic code transaction request. The target card data includes at least the order amount and the basic card data. The target card data is obtained by the payment terminal based on a password input scheme, which is determined by the payment terminal based on the order amount and a preset password-free rule.

[0009] Fourthly, embodiments of this application provide a payment device applied to a payment terminal, the device comprising: The first receiving module is used to receive the order amount of the first order sent by the acquiring system. The order amount is obtained by the acquiring system from the graphic code transaction request. The graphic code transaction request is generated by the merchant system based on the first order and its corresponding target graphic code. The target graphic code is generated based on the basic card data. The basic card data is read by the payment terminal in response to the graphic code generation request sent by the merchant system corresponding to the first order. The determination module is used to determine the password input scheme based on the order amount and the preset password-free rules; The first acquisition module is used to acquire target card data based on the password input scheme, wherein the target card data includes at least the order amount and the basic card data; The first sending module is used to send the target card data to the acquiring system so that the acquiring system can make payment based on the target card data and the graphic code transaction request.

[0010] Fifthly, embodiments of this application provide a payment device applied to an acquiring system, the device comprising: The second receiving module is used to receive a graphic code transaction request sent by the merchant system. The graphic code transaction request is generated based on the first order and its corresponding target graphic code. The target graphic code is generated based on the basic card data. The basic card data is read by the payment terminal in response to the graphic code generation request sent by the merchant system corresponding to the first order. The parsing module is used to parse the graphic code transaction request to obtain the order amount of the first order; The second sending module is used to send the order amount to the payment terminal so that the payment terminal can determine the password input scheme based on the order amount and the preset password-free rules, and obtain the target card data based on the password input scheme. The target card data includes at least the order amount and the basic card data. The second receiving module is further configured to receive the target card data sent by the payment terminal; The payment module is used to make payments based on the target card data and the graphic code transaction request.

[0011] Sixthly, embodiments of this application provide a payment device applied to a merchant system, the device comprising: The third generation module is used to generate a graphic code generation request corresponding to the first order; The third sending module is used to send the graphic code generation request to the payment terminal; The third receiving module is used to receive the target graphic code returned by the payment terminal in response to the graphic code generation request, wherein the target graphic code is generated by the payment terminal based on the read basic card data; The third generation module is further configured to generate a graphic code transaction request based on the first order and the target graphic code; The third sending module is further configured to send the graphic code transaction request to the acquiring system, so that the acquiring system can parse the graphic code transaction request to obtain the order amount, obtain target card data based on the order amount, and make payment based on the target card data and the graphic code transaction request. The target card data includes at least the order amount and the basic card data. The target card data is obtained by the payment terminal based on a password input scheme, which is determined by the payment terminal based on the order amount and a preset password-free rule.

[0012] In a seventh aspect, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements any one of the possible implementations of the first, second, or third aspect described above.

[0013] Eighthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions that, when executed by a processor, implement the method in any of the possible implementations of the first, second, or third aspects described above.

[0014] Ninthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform a method as described in any of the possible implementations of the first, second, or third aspects above.

[0015] In this embodiment, the acquiring system can first parse the order amount of the first order from the graphic code transaction request, and then actively send the order amount to the payment terminal. The graphic code transaction request is generated by the merchant system based on the first order and its corresponding target graphic code. The target graphic code is generated based on the basic card data, which is read by the payment terminal in response to the graphic code generation request sent by the merchant system corresponding to the first order. After obtaining the order amount, the payment terminal can intelligently determine the password input scheme (i.e., whether to enter a password) for this transaction based on preset password-free rules. By obtaining and sending target card data, including at least the order amount and basic card data, to the acquiring system based on the password input scheme, the cumbersome operation of mandatory password input for small payments is avoided, while password verification for large payments is ensured, thereby simultaneously guaranteeing payment security and convenience and improving the user's payment experience. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic flowchart of a payment method applied to a payment terminal according to an embodiment of this application; Figure 2 This is a schematic flowchart of a payment method applied to an acquiring system according to an embodiment of this application; Figure 3 This is a flowchart illustrating a payment method applied to a merchant system according to an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a payment device applied to a payment terminal according to an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a payment device applied to an acquiring system according to an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a payment device applied to a merchant system according to an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0018] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0019] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0020] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0021] Furthermore, the acquisition, storage, use, and processing of data in this application's technical solution all comply with relevant national laws and regulations.

[0022] As described in the background section, current plug-and-play payment solutions based on integrated payment terminals present a trade-off between payment security and convenience in practical applications. Specifically, while requiring a password for every transaction ensures security, it severely sacrifices the convenience of small-amount payments, resulting in a poor user experience. Conversely, if passwords are not collected by default and only small-amount password-free transactions are supported, payment is interrupted once the transaction amount exceeds the password-free limit, similarly reducing the user experience. Therefore, there is an urgent need for a plug-and-play payment method based on integrated payment terminals to simultaneously guarantee payment security and convenience, thereby improving the user's payment experience.

[0023] Therefore, in order to solve the relevant technical problems, embodiments of this application provide a payment method, apparatus, electronic device, computer-readable storage medium, and computer program product. The payment method can be applied to plug-and-play payment scenarios based on integrated payment terminals.

[0024] Furthermore, this payment method can be applied to plug-and-play payment systems based on integrated payment terminals. This payment system can include a payment terminal, a merchant system, and an acquiring system. Each of these components (payment terminal, merchant system, and acquiring system) communicates with each other. The payment terminal can be a shorthand for an integrated payment terminal that combines card swiping, contactless payment, and QR code scanning functions. The merchant system can be a merchant's Management Information (MIS) system. The acquiring system can be the acquiring institution's back-end system.

[0025] The following describes the payment method applied to a payment terminal provided in the embodiments of this application.

[0026] Figure 1 A schematic flowchart of a payment method applied to a payment terminal according to an embodiment of this application is shown. This payment method can be executed by the payment terminal. Figure 1 As shown, the payment method provided in this application embodiment includes steps S110-S140.

[0027] S110. Receive the order amount of the first order sent by the acquiring system. The order amount is obtained by the acquiring system from the graphic code transaction request. The graphic code transaction request is generated by the merchant system based on the first order and its corresponding target graphic code. The target graphic code is generated based on the basic card data. The basic card data is read by the payment terminal in response to the graphic code generation request sent by the merchant system corresponding to the first order. S120. Determine the password input scheme based on the order amount and preset password-free rules; S130. Based on the password input scheme, obtain the target card data, which includes at least the order amount and basic card data; S140. Send the target card data to the acquiring system so that the acquiring system can make payment based on the target card data and the graphic code transaction request.

[0028] In this embodiment, the acquiring system can first parse the order amount of the first order from the graphic code transaction request, and then actively send the order amount to the payment terminal. The graphic code transaction request is generated by the merchant system based on the first order and its corresponding target graphic code. The target graphic code is generated based on the basic card data, which is read by the payment terminal in response to the graphic code generation request sent by the merchant system corresponding to the first order. After obtaining the order amount, the payment terminal can intelligently determine the password input scheme (i.e., whether to enter a password) for this transaction based on preset password-free rules. By obtaining and sending target card data, including at least the order amount and basic card data, to the acquiring system based on the password input scheme, the cumbersome operation of mandatory password input for small payments is avoided, while password verification for large payments is ensured, thereby simultaneously guaranteeing payment security and convenience and improving the user's payment experience.

[0029] The specific implementation methods for each of the above steps are described below.

[0030] In some embodiments, in S110, the payment terminal can receive the order amount corresponding to the first order, sent by the acquiring system through a secure channel. The first order can be any consumption order generated by the merchant system for the user. The order amount of the first order is obtained by the acquiring system from the graphic code transaction request and serves as the data basis for the payment terminal to perform intelligent judgment on subsequent password input schemes.

[0031] The image code transaction request is generated by the merchant system based on the first order and its corresponding target image code, and sent to the acquiring system. Upon receiving the image code transaction request, the acquiring system can, on the one hand, send a transaction acceptance response to the merchant system. On the other hand, the acquiring system does not directly respond to the image code transaction request to initiate subsequent transactions. Instead, it first parses the order amount of the first order from the image code transaction request, and then proactively sends the order amount to the payment terminal through a secure channel. The secure channel is a communication link established between the payment terminal and the acquiring system, equipped with data encryption and integrity protection capabilities, used to ensure the confidentiality, integrity, and non-repudiation of sensitive transaction data such as order amounts during transmission.

[0032] Additionally, the target graphic code is a temporary graphic code generated by the payment terminal based on the base card data in response to a graphic code generation request sent by the merchant system. This target graphic code is essentially a transaction index, used to establish a link between the base card data and subsequent transaction processes, so that the acquiring system can subsequently match the target card data sent by the payment terminal with the graphic code transaction request sent by the merchant system. This target graphic code can be, for example, a QR code or a barcode.

[0033] The basic card data is read from the payment card by the payment terminal after receiving the graphic code generation request, through the user's card swiping or contactless payment operation. Basic card data may include basic identification information of the payment card, such as the card number and card expiration date. This payment card can be, for example, a bank card, transportation card, membership card, or any card conforming to the Integrated Circuit (IC) card specification.

[0034] Based on this, in order to enable the acquiring system to proactively send the order amount parsed from the graphic code transaction request to the payment terminal in a plug-and-play payment scenario, so that the payment terminal obtains the key decision basis (i.e., the order amount) for determining the password input scheme, in some embodiments, the method may further include the following before S110: In response to the merchant system's request to generate a graphic code corresponding to the first order, read the basic card data; Based on the base card data, obtain the target graphic code; Send the target graphic code to the merchant system so that the merchant system can generate a graphic code transaction request based on the first order and the target graphic code, and then send the graphic code transaction request to the acquiring system.

[0035] Here, after a merchant generates the first order through a merchant system (such as an MIS system), it can generate a graphic code generation request corresponding to the first order and send the graphic code generation request to the payment terminal (i.e., an integrated payment terminal) to request the generation of a temporary graphic code for this transaction, i.e., the target graphic code.

[0036] Upon receiving a graphic code generation request, the payment terminal responds and waits to read the underlying card data. If the user swipes or inserts a physical card on the terminal, or makes a contactless payment using their e-wallet, the terminal will read the underlying card data and enter a waiting state. In this state, the payment terminal does not require the user to enter a password but waits for the system to determine whether password verification is necessary. If no verification is required, the payment process begins directly; if verification is required, password input will be triggered subsequently.

[0037] After reading the base card data, the payment terminal can obtain the target graphic code online or offline based on the base card data. The specific methods for the payment terminal to obtain the target graphic code online or offline based on the base card data will be detailed later and will not be repeated here.

[0038] After obtaining the target graphic code, the payment terminal returns it to the merchant system. Upon receiving the graphic code, the merchant terminal binds it to the previously generated first order, generates a graphic code transaction request, and sends this request to the acquiring system. This completes the conversion of a payment card transaction into a graphic code transaction.

[0039] This embodiment converts traditional payment card transactions into graphic code transaction requests and sends them to the acquiring system, creating conditions for the acquiring system to obtain the order amount and distribute it to the payment terminal. Simultaneously, after reading the basic card data, the payment terminal enters a waiting processing state, preparing to receive the order amount and perform smart password verification. By having the acquiring system act as the information hub, proactively distributing the order amount parsed from the graphic code transaction request to the payment terminal in the waiting processing state, the payment terminal obtains the crucial decision-making basis (i.e., the order amount) for determining the password input scheme. This provides a data foundation for subsequent intelligent judgment on whether a password is required, thereby achieving a smooth, password-free experience for small transactions while ensuring the security of large transactions.

[0040] Based on this, in order to improve transaction processing efficiency and reduce dependence on the network environment, so as to quickly obtain the target graphic code even in weak network or no network environment, in some embodiments, the above-mentioned S120 may specifically include: Obtain at least one preset graphic code, which is pre-issued to the payment terminal by the acquiring system; Select a target preset graphic code from at least one preset graphic code; Generate the target graphic code based on the target preset graphic code and the basic card data.

[0041] Here, under the condition of meeting the graphic code acquisition requirements, the payment terminal can generate and send a second graphic code acquisition request to the acquiring system to request preset graphic codes in batches. The graphic code acquisition condition can be that the number of graphic codes pre-stored in the payment terminal is less than or equal to a quantity threshold. This quantity threshold can be, for example, 2. When the payment terminal detects that the number of locally pre-stored preset graphic codes is insufficient (e.g., the number of preset graphic codes is 1 or 2), it can trigger a batch request for new preset graphic codes from the acquiring system.

[0042] As an example, if the number of pre-stored graphic codes in the payment terminal is less than or equal to a certain threshold, the payment terminal can generate a second graphic code retrieval request and send it to the acquiring system. In response to this request, the acquiring system can generate multiple preset graphic codes in batches according to the graphic code generation specifications and return these preset graphic codes to the payment terminal for local storage.

[0043] When a payment terminal needs to generate a target graphic code, it can randomly or sequentially select one of one or more preset graphic codes stored locally as the target preset graphic code. Then, it establishes a relationship between the target preset graphic code and the currently read basic card data to generate the target graphic code for this transaction.

[0044] This application embodiment pre-generates and batch-distributes preset graphic codes to the local storage of the payment terminal. This allows the payment terminal to directly select a target preset graphic code from the locally stored preset graphic codes without interacting with the acquiring system in real time after receiving a graphic code generation request. The target graphic code is then associated with the current basic card data to generate the target graphic code. This significantly shortens the response time for graphic code acquisition, improves transaction processing efficiency, and reduces dependence on the network environment. The target graphic code can still be quickly obtained in weak network or no network environments.

[0045] In addition, to enhance the security and anti-counterfeiting capabilities of the target graphic code, in some embodiments, the above-mentioned S120 may specifically include: Based on the basic card data, generate the first graphic code acquisition request; Send the first graphic code acquisition request to the acquiring system; The receiving system returns the target graphic code in response to the first graphic code acquisition request.

[0046] Here, the first graphic code acquisition request can be generated by the payment terminal after reading the basic card data, and is used to request the target graphic code from the acquiring system in real time. The first graphic code acquisition request may include the basic card data read in this instance.

[0047] As an example, after reading the basic card data, the payment terminal can generate and send a first graphic code retrieval request to the acquiring system. Upon receiving the first graphic code retrieval request, the acquiring system can first parse the request to obtain the basic card data, and then generate and send the target graphic code to the payment terminal based on the basic card data according to the graphic code generation specification.

[0048] This application embodiment ensures that each target graphic code is generated in real time based on the current basic card data by requesting the target graphic code from the acquiring system in real time. This effectively avoids the security risks of preset graphic codes being reused or illegally associated, and improves the security and anti-counterfeiting capabilities of the target graphic code.

[0049] In some embodiments, in S120, the preset password-free rule can be a small-amount password-free rule pre-set in the payment terminal. The preset password-free rule can be: if the order amount is greater than a threshold amount, a password is required; if the order amount is less than or equal to the threshold amount, no password is required. The threshold amount can be a critical value used to determine whether a password is required for this transaction (i.e., whether this transaction is a large transaction). For example, the threshold amount can be 1000. Furthermore, the password input scheme can include requiring a password and not requiring a password (i.e., password-free payment).

[0050] As an example, after receiving the order amount, the payment terminal can determine whether a password is required for this transaction by combining the built-in preset password-free rules.

[0051] In some embodiments, the above-described S120 may specifically include: If the order amount meets the preset password-free rules, the password input scheme is set to require no password. If the order amount does not meet the preset password-free rules, the password input scheme will be set to require a password.

[0052] For example, if the order amount is greater than 1000, then a password is required for this transaction. If the order amount is less than or equal to 1000, then a password is not required for this transaction.

[0053] Furthermore, different payment cards may have different transaction restrictions. Therefore, to ensure that the PIN input scheme complies with both terminal rules and card transaction restrictions, and to further improve the transaction success rate, in some embodiments, the above-mentioned S120 may specifically include: Analyze the basic card data to obtain the card transaction attributes; The password input scheme is determined based on the order amount, preset password-free rules, and card transaction attributes.

[0054] Here, card transaction attributes are feature information stored in the payment card chip that identifies the card's own functions and transaction restrictions. Different payment cards have different card transaction attributes due to factors such as issuing bank policies, card types, and risk levels. These attributes may include whether the card supports small-amount contactless transactions, single contactless transaction limits, cumulative contactless transaction limits, and cumulative contactless transaction counts. These attributes are set by the issuing bank when issuing the card and stored in the IC card chip, which the payment terminal can retrieve when reading the base card data.

[0055] As an example, after receiving the order amount from the acquiring institution, the payment terminal can first parse the card transaction attributes from the read basic card data and determine the password input scheme based on these attributes. Specifically, the payment terminal can determine whether the parsed card transaction attributes indicate that the current payment card supports password-free transactions: if the card transaction attributes indicate that the payment card does not support password-free transactions, then regardless of the order amount, the payment terminal directly determines that a password is required and displays the password keypad for the user to enter the password; if the card transaction attributes indicate that the payment card supports password-free transactions, the payment terminal further combines the order amount, the locally built-in small-amount password-free rules, and other restrictions in the card transaction attributes for a comprehensive judgment.

[0056] If the card transaction attributes do not include other restrictions, the payment terminal can compare the order amount with the amount threshold. If the order amount is less than or equal to the amount threshold, the password input scheme is determined to be password-free. If the order amount is greater than the amount threshold, the password input scheme is determined to be password-required.

[0057] If the card transaction attributes include the card's cumulative limit or cumulative number of PIN-free transactions, and the current card has reached that cumulative limit or number of transactions, then regardless of the order amount, the payment terminal will directly determine that a PIN is required and display a PIN pad for the user to enter the PIN.

[0058] If the card transaction attributes include a single-transaction contactless limit, then that limit will be used instead of comparing it to the terminal's transaction threshold. In some scenarios, terminal-side rules (i.e., prioritizing comparison between the order amount and the threshold) can be taken into account, with the single-transaction contactless limit being used only when it is lower. Payment terminals can choose different decision-making logic based on different configuration strategies.

[0059] Through the embodiments of this application, after receiving the actual order amount issued by the acquiring institution, the payment terminal can intelligently determine whether a password should be entered for this transaction based on the order amount and the card transaction attributes parsed from the basic card data, combined with the built-in small-amount password-free rules. This avoids the risk of transaction failure caused by ignoring the card's own limitations (such as not supporting password-free transactions), and ensures that the password input scheme complies with both the terminal rules and the card transaction restrictions, further improving the transaction success rate.

[0060] In some embodiments, in S130, the target card data is complete IC card transaction data generated by the payment terminal according to the PIN input scheme after determining the scheme, and used to send it to the acquiring system to complete the transaction. This target card data includes at least the order amount of this transaction and the basic card data read from the IC card. If the PIN input scheme requires a PIN, it also includes the transaction PIN entered by the user. Additionally, the target card data includes other transaction dynamic data used for this transaction. Transaction dynamic data may include, for example, a transaction counter, a card random number, and application ciphertext.

[0061] Therefore, in order to ensure the security of large transactions while providing a smooth, password-free experience for small transactions, in some embodiments, the above-mentioned S130 may specifically include: When the password input scheme is set to require no password, target card data is generated based on the basic card data and the order amount. When the password input scheme requires a password, the password input interface is displayed; Receives the transaction password entered by the user on the password input interface; Target card data is generated based on the transaction password, basic card data, and order amount.

[0062] Here, if the password input scheme is passwordless, the payment terminal will directly assemble the basic card data read from the payment card and the order amount issued by the acquiring system, and generate complete IC card transaction data containing the above data and other necessary transaction elements in accordance with the IC card transaction specifications, thus obtaining the target card data.

[0063] If the password input scheme requires a password, the payment terminal can first pop up the password keypad to obtain the transaction password entered by the user; then, it will assemble the basic card data read from the IC card, the order amount issued by the acquiring system, and the transaction password entered by the user, and generate complete IC card transaction data containing the above data and other necessary transaction elements in accordance with the IC card transaction specifications, thus obtaining the target card data.

[0064] This application embodiment dynamically generates complete target card data containing different data elements by using a password input scheme determined by intelligent judgment. This ensures that the transaction password is accurately collected and packaged in scenarios where a password is required, while avoiding unnecessary password interaction in password-free scenarios. Thus, it ensures the security of large transactions while providing a smooth password-free experience for small transactions.

[0065] In some embodiments, in S140, after obtaining the target card data, the payment terminal can send the target card data to the acquiring system. The acquiring system can associate the target card data with the graphic code transaction request previously sent by the merchant system to form complete transaction information, and initiate transaction authorization according to the standard payment card transaction process, routing the transaction to the issuing bank for authorization, thereby completing the payment settlement.

[0066] After a transaction is completed, the acquiring system can receive the first transaction result from the issuing bank and provide differentiated result notifications based on the recipient. Specifically, for the payment terminal, the acquiring system can directly forward the first transaction result to meet the payment terminal's requirement for recognizing the original state of the card transaction; for the merchant system, the first transaction result can be encapsulated according to the graphic code payment standard to generate a second transaction result, clearly identifying the true type of the transaction as a card transaction in the encapsulated result. This dual-channel, dual-format result notification method ensures a closed-loop transaction on the terminal side and achieves seamless compatibility on the merchant system side.

[0067] Furthermore, if the payment terminal or merchant system does not receive the transaction result within a preset time, it can proactively send a transaction status query request to the acquiring system. This request can include a target graphic code. Upon receiving the query request, the acquiring system can retrieve local transaction records based on the target graphic code and return the current transaction status to the payment terminal or merchant system that initiated the query. This query mechanism ensures the traceability and eventual consistency of transaction status in abnormal situations.

[0068] The following describes the payment method applied to the acquiring system provided in the embodiments of this application.

[0069] Figure 2 A schematic flowchart of a payment method applied to an acquiring system according to an embodiment of this application is shown. This payment method can be executed by the acquiring system. Figure 2 As shown, the payment method provided in this application embodiment includes steps S210-S250.

[0070] S210. Receive a graphic code transaction request sent by the merchant system. The graphic code transaction request is generated based on the first order and its corresponding target graphic code. The target graphic code is generated based on the basic card data. The basic card data is read by the payment terminal in response to the graphic code generation request sent by the merchant system corresponding to the first order. S220. Parse the graphic code transaction request to obtain the order amount of the first order; S230. Send the order amount to the payment terminal so that the payment terminal can determine the password input scheme based on the order amount and the preset password-free rules, and obtain the target card data based on the password input scheme. The target card data includes at least the order amount and the basic card data. S240, Receive target card data sent by the payment terminal; S250: Make payment based on target card data and graphic code transaction request.

[0071] Other steps of the method in this application embodiment can be found above. Figure 1 The relevant descriptions of the embodiments shown will not be repeated here.

[0072] In this embodiment, the graphic code transaction request is generated based on the first order and its corresponding target graphic code. The target graphic code is generated based on the basic card data, which is read by the payment terminal in response to the graphic code generation request sent by the merchant system corresponding to the first order. Based on this, the acquiring system receives the graphic code transaction request sent by the merchant system, parses the order amount of the first order from it, and sends it to the payment terminal. This allows the payment terminal to intelligently determine the password input scheme (i.e., whether to enter a password) for this transaction based on preset password-free rules. By obtaining and sending target card data, including at least the order amount and basic card data, to the acquiring system based on the password input scheme, the cumbersome operation of mandatory password input for small payments is avoided, while password verification for large payments is ensured. This simultaneously guarantees payment security and convenience, improving the user's payment experience.

[0073] Based on this, in order to improve transaction processing efficiency and reduce dependence on the network environment, so as to quickly obtain the target graphic code even in weak or no network environments, the method also includes: Receive the second graphic code acquisition request sent by the payment terminal; In response to the second graphic code acquisition request, multiple preset graphic codes are generated; Multiple preset graphic codes are sent to the payment terminal. These preset graphic codes are used to associate with the basic card data to generate the target graphic code.

[0074] Here, under the condition of meeting the graphic code acquisition requirements, the payment terminal can generate and send a second graphic code acquisition request to the acquiring system to request preset graphic codes in batches. The graphic code acquisition condition can be that the number of graphic codes pre-stored in the payment terminal is less than or equal to a quantity threshold. This quantity threshold can be, for example, 2. When the payment terminal detects that the number of locally pre-stored preset graphic codes is insufficient (e.g., the number of preset graphic codes is 1 or 2), it can trigger a batch request for new preset graphic codes from the acquiring system.

[0075] As an example, if the number of pre-stored graphic codes in the payment terminal is less than or equal to a certain threshold, the payment terminal can generate a second graphic code retrieval request and send it to the acquiring system. In response to this request, the acquiring system can generate multiple preset graphic codes in batches according to the graphic code generation specifications and return these preset graphic codes to the payment terminal for local storage.

[0076] When a payment terminal needs to generate a target graphic code, it can randomly or sequentially select one of one or more preset graphic codes stored locally as the target preset graphic code. Then, it establishes a relationship between the target preset graphic code and the currently read basic card data to generate the target graphic code for this transaction.

[0077] This application embodiment pre-generates and batch-distributes preset graphic codes to the local storage of the payment terminal. This allows the payment terminal to directly select a target preset graphic code from the locally stored preset graphic codes without interacting with the acquiring system in real time after receiving a graphic code generation request. The target graphic code is then associated with the current basic card data to generate the target graphic code. This significantly shortens the response time for graphic code acquisition, improves transaction processing efficiency, and reduces dependence on the network environment. The target graphic code can still be quickly obtained in weak network or no network environments.

[0078] In addition, to enhance the security and anti-counterfeiting capabilities of the target graphic code, in some embodiments, the method may further include: Receive a first graphic code acquisition request sent by the payment terminal, the first graphic code acquisition request including basic card data; In response to the first graphic code acquisition request, a target graphic code is generated based on the base card data; Send the target graphic code to the payment terminal.

[0079] The first graphic code acquisition request can be generated by the payment terminal after reading the basic card data. It is used to request the target graphic code from the acquiring system in real time. The first graphic code acquisition request may include the basic card data read in this instance.

[0080] As an example, after reading the basic card data, the payment terminal can generate and send a first graphic code retrieval request to the acquiring system. Upon receiving the first graphic code retrieval request, the acquiring system can first parse the request to obtain the basic card data, and then generate and send the target graphic code to the payment terminal based on the basic card data according to the graphic code generation specification.

[0081] This application embodiment ensures that each target graphic code is generated in real time based on the current basic card data by requesting the target graphic code from the acquiring system in real time. This effectively avoids the security risks of preset graphic codes being reused or illegally associated, and improves the security and anti-counterfeiting capabilities of the target graphic code.

[0082] Furthermore, to improve the accuracy and sophistication of merchant-side accounting management, in some embodiments, after S250 above, the method may further include: Obtain the first transaction result; Based on the graphic code payment standard, the first transaction result is encapsulated to obtain the second transaction result, in which the transaction type is card transaction; Send the second transaction result to the merchant system.

[0083] Here, the first transaction result can be the transaction result returned by the issuing bank. After receiving the first transaction result from the issuing bank, the acquiring system can provide differentiated result notifications based on the recipient. Specifically, for the payment terminal, the acquiring system can directly forward the first transaction result to meet the payment terminal's requirement for recognizing the original state of the card transaction; for the merchant system, the first transaction result can be encapsulated according to the graphic code payment specification to generate a second transaction result, clearly identifying the true type of the transaction as a card transaction in the encapsulated result. Through this dual-channel, dual-format result notification method, both the transaction loop on the terminal side and seamless compatibility on the merchant system side are ensured.

[0084] In addition, for the merchant system, since the second transaction result obtained based on the graphic code payment specification clearly identifies the actual type of the transaction as a card transaction, merchants can accurately distinguish the actual payment method of the transaction during subsequent reconciliation and inventory, avoiding misclassifying card transactions as graphic code transactions, thus improving the accuracy and precision of accounting management.

[0085] The following describes the payment method for merchant systems provided in the embodiments of this application.

[0086] Figure 3 A schematic flowchart of a payment method applied to a merchant system according to an embodiment of this application is shown. This payment method can be executed by the merchant system. Figure 3 As shown, the payment method provided in this application embodiment includes steps S310-S350.

[0087] S310, Generate a graphic code generation request corresponding to the first order; S320, sends a graphic code generation request to the payment terminal; S330, Receive the target graphic code returned by the payment terminal in response to the graphic code generation request. The target graphic code is generated by the payment terminal based on the read basic card data. S340, based on the first order and the target graphic code, generates a graphic code transaction request; S350, a graphic code transaction request is sent to the acquiring system so that the acquiring system can parse the graphic code transaction request to obtain the order amount, obtain the target card data based on the order amount, and make payment based on the target card data and the graphic code transaction request. The target card data includes at least the order amount and the basic card data. The target card data is obtained by the payment terminal based on the password input scheme. The password input scheme is determined by the payment terminal based on the order amount and the preset password-free rules.

[0088] Other steps of the method in this application embodiment can be found above. Figure 1 The relevant descriptions of the embodiments shown will not be repeated here.

[0089] This embodiment of the application responds to a graphic code generation request sent by the merchant system corresponding to the first order via a payment terminal. It reads the basic card data, acquires and sends the target graphic code to the merchant system based on the basic card data. This allows the merchant system to generate a graphic code transaction request based on the first order and the target graphic code and send it to the acquiring system. The acquiring system can then parse this request and send the order amount to the payment terminal. After obtaining the order amount, the payment terminal can intelligently determine the password input scheme (i.e., whether a password needs to be entered) for this transaction based on preset password-free rules. By acquiring and sending target card data, including at least the order amount and basic card data, to the acquiring system based on the password input scheme, the cumbersome operation of mandatory password input for small payments is avoided, while password verification for large payments is ensured. This simultaneously guarantees payment security and convenience, improving the user's payment experience.

[0090] Furthermore, to improve the accuracy and sophistication of merchant-side accounting management, in some embodiments, after S350 above, the method may further include: The system receives the second transaction result sent by the acquiring system. The second transaction result is encapsulated based on the graphic code payment specification, and the transaction type in the second transaction result is card transaction.

[0091] Because the second transaction result obtained based on the graphic code payment specification clearly identifies the actual type of the transaction as a card transaction, merchants can accurately distinguish the actual payment method of the transaction during subsequent reconciliation and inventory checks, avoiding misclassifying card transactions as graphic code transactions, thus improving the accuracy and sophistication of accounting management.

[0092] Based on the payment method applied to a payment terminal provided in the above embodiments, this application also provides specific implementations of a payment device applied to a payment terminal. Please refer to the following embodiments.

[0093] like Figure 4 As shown, a payment device 400 provided in one embodiment of this application includes the following modules: The first receiving module 410 is used to receive the order amount of the first order sent by the acquiring system. The order amount is obtained by the acquiring system from the graphic code transaction request. The graphic code transaction request is generated by the merchant system based on the first order and its corresponding target graphic code. The target graphic code is generated based on the basic card data. The basic card data is read by the payment terminal in response to the graphic code generation request sent by the merchant system corresponding to the first order. The determination module 420 is used to determine the password input scheme based on the order amount and preset password-free rules; The first acquisition module 430 is used to acquire target card data based on the password input scheme. The target card data includes at least the order amount and basic card data. The first sending module 440 is used to send target card data to the acquiring system so that the acquiring system can make payment based on the target card data and the graphic code transaction request.

[0094] The payment device 400 described above is explained in detail below: In some embodiments, the payment device 400 may further include: The reading module is used to read the basic card data in response to the graphic code generation request sent by the merchant system corresponding to the first order before receiving the order amount of the first order sent by the acquiring system. The first acquisition module 430 is also used to acquire the target graphic code based on the base card data; The first sending module 440 is also used to send the target graphic code to the merchant system, so that the merchant system can generate a graphic code transaction request based on the first order and the target graphic code, and send the graphic code transaction request to the acquiring system. In some embodiments, the first acquisition module 430 is specifically used for: Based on the basic card data, generate the first graphic code acquisition request; Send the first graphic code acquisition request to the acquiring system; The receiving system returns the target graphic code in response to the first graphic code acquisition request.

[0095] In some embodiments, the first acquisition module 430 is specifically used for: Obtain at least one preset graphic code, which is pre-issued to the payment terminal by the acquiring system; Select a target preset graphic code from at least one preset graphic code; Generate the target graphic code based on the target preset graphic code and the basic card data.

[0096] In some embodiments, the determining module 420 is specifically used for: Analyze the basic card data to obtain the card transaction attributes; The password input scheme is determined based on the order amount, preset password-free rules, and card transaction attributes.

[0097] In some embodiments, the determining module 420 is specifically used for: If the order amount meets the preset password-free rules, the password input scheme is set to require no password. If the order amount does not meet the preset password-free rules, the password input scheme will be set to require a password.

[0098] In some embodiments, the first acquisition module 430 is specifically used for: When the password input scheme is set to require no password, target card data is generated based on the basic card data and the order amount. When the password input scheme requires a password, the password input interface is displayed; Receives the transaction password entered by the user on the password input interface; Target card data is generated based on the transaction password, basic card data, and order amount.

[0099] In this embodiment, the acquiring system can first parse the order amount of the first order from the graphic code transaction request, and then actively send the order amount to the payment terminal. The graphic code transaction request is generated by the merchant system based on the first order and its corresponding target graphic code. The target graphic code is generated based on the basic card data, which is read by the payment terminal in response to the graphic code generation request sent by the merchant system corresponding to the first order. After obtaining the order amount, the payment terminal can intelligently determine the password input scheme (i.e., whether to enter a password) for this transaction based on preset password-free rules. By obtaining and sending target card data, including at least the order amount and basic card data, to the acquiring system based on the password input scheme, the cumbersome operation of mandatory password input for small payments is avoided, while password verification for large payments is ensured, thereby simultaneously guaranteeing payment security and convenience and improving the user's payment experience.

[0100] Based on the payment method for an acquiring system provided in the above embodiments, this application also provides specific implementations of a payment device for an acquiring system. Please refer to the following embodiments.

[0101] like Figure 5As shown, a payment device 500 provided in one embodiment of this application includes the following modules: The second receiving module 510 is used to receive the graphic code transaction request sent by the merchant system. The graphic code transaction request is generated based on the first order and its corresponding target graphic code. The target graphic code is generated based on the basic card data. The basic card data is read by the payment terminal in response to the graphic code generation request sent by the merchant system corresponding to the first order. The parsing module 520 is used to parse the graphic code transaction request and obtain the order amount of the first order; The second sending module 530 is used to send the order amount to the payment terminal so that the payment terminal can determine the password input scheme based on the order amount and the preset password-free rules, and obtain the target card data based on the password input scheme. The target card data includes at least the order amount and the basic card data. The second receiving module 510 is also used to receive target card data sent by the payment terminal; Payment module 540 is used to make payments based on target card data and graphic code transaction requests.

[0102] The payment device 500 described above is explained in detail below: In some embodiments, the second receiving module 510 is further configured to receive a first graphic code acquisition request sent by the payment terminal, the first graphic code acquisition request including basic card data.

[0103] Payment device 500 may also include: The second generation module is used to generate a target graphic code based on the base card data in response to the first graphic code acquisition request. The second sending module 530 is also used to send the target graphic code to the payment terminal.

[0104] In some embodiments, the second receiving module 510 is further configured to receive a second graphic code acquisition request sent by the payment terminal; The second generation module is also used to generate multiple preset graphic codes in response to the second graphic code acquisition request; The second sending module 530 is also used to send multiple preset graphic codes to the payment terminal. The preset graphic codes are used to associate with the basic card data to generate the target graphic code.

[0105] In some embodiments, the payment device 500 may further include: The second acquisition module is used to acquire the first transaction result after payment is made based on the target card data and the graphic code transaction request; The encapsulation module is used to encapsulate the first transaction result based on the graphic code payment specification to obtain the second transaction result, where the transaction type in the second transaction result is card transaction; The second sending module 530 is also used to send the second transaction result to the merchant system.

[0106] In this embodiment, the graphic code transaction request is generated based on the first order and its corresponding target graphic code. The target graphic code is generated based on the basic card data, which is read by the payment terminal in response to the graphic code generation request sent by the merchant system corresponding to the first order. Based on this, the acquiring system receives the graphic code transaction request sent by the merchant system, parses the order amount of the first order from it, and sends it to the payment terminal. This allows the payment terminal to intelligently determine the password input scheme (i.e., whether to enter a password) for this transaction based on preset password-free rules. By obtaining and sending target card data, including at least the order amount and basic card data, to the acquiring system based on the password input scheme, the cumbersome operation of mandatory password input for small payments is avoided, while password verification for large payments is ensured. This simultaneously guarantees payment security and convenience, improving the user's payment experience.

[0107] Based on the payment method for merchant systems provided in the above embodiments, this application also provides specific implementations of payment devices for merchant systems. Please refer to the following embodiments.

[0108] like Figure 6 As shown, a payment device 600 provided in one embodiment of this application includes the following modules: The third generation module 610 is used to generate a graphic code generation request corresponding to the first order; The third sending module 620 is used to send a graphic code generation request to the payment terminal; The third receiving module 630 is used to receive the target graphic code returned by the payment terminal in response to the graphic code generation request. The target graphic code is generated by the payment terminal based on the read basic card data. The third generation module 610 is also used to generate a graphic code transaction request based on the first order and the target graphic code; The third sending module 620 is also used to send a graphic code transaction request to the acquiring system, so that the acquiring system can parse the graphic code transaction request, obtain the order amount, obtain the target card data based on the order amount, and make payment based on the target card data and the graphic code transaction request. The target card data includes at least the order amount and the basic card data. The target card data is obtained by the payment terminal based on the password input scheme, which is determined by the payment terminal based on the order amount and the preset password-free rules.

[0109] The payment device 600 described above is explained in detail below: In some embodiments, the third receiving module 630 is further configured to receive a second transaction result sent by the acquiring system after sending a graphic code transaction request to the acquiring system. The second transaction result is encapsulated based on the graphic code payment specification, and the transaction type in the second transaction result is a card transaction.

[0110] This embodiment of the application responds to a graphic code generation request sent by the merchant system corresponding to the first order via a payment terminal. It reads the basic card data, acquires and sends the target graphic code to the merchant system based on the basic card data. This allows the merchant system to generate a graphic code transaction request based on the first order and the target graphic code and send it to the acquiring system. The acquiring system can then parse this request and send the order amount to the payment terminal. After obtaining the order amount, the payment terminal can intelligently determine the password input scheme (i.e., whether a password needs to be entered) for this transaction based on preset password-free rules. By acquiring and sending target card data, including at least the order amount and basic card data, to the acquiring system based on the password input scheme, the cumbersome operation of mandatory password input for small payments is avoided, while password verification for large payments is ensured. This simultaneously guarantees payment security and convenience, improving the user's payment experience.

[0111] Based on the payment method provided in the above embodiments, this application also provides specific implementation methods for electronic devices. Figure 7 A schematic diagram of the structure of an electronic device provided in one embodiment of this application is shown.

[0112] like Figure 7 As shown, the electronic device 700 may include a processor 710 and a memory 720 storing computer program instructions.

[0113] Specifically, the processor 710 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0114] Memory 720 may include mass storage for data or instructions. For example, and not limitingly, memory 720 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where suitable, memory 720 may include removable or non-removable (or fixed) media. Where suitable, memory 720 may be internal or external to electronic device 700. In a particular embodiment, memory 720 is a non-volatile solid-state memory.

[0115] In specific embodiments, the memory 720 may be implemented as a read-only memory (ROM), random access memory (RAM), static storage device, dynamic storage device, etc. The memory 720 may store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 720 and executed by the processor 710. The processor 710 implements any of the payment methods in the above embodiments by reading and executing the computer program instructions stored in the memory 720.

[0116] The processor 710 implements any of the payment methods described in the above embodiments by reading and executing computer program instructions stored in the memory 720.

[0117] In one example, the electronic device 700 may further include a communication interface 730 and a bus 740. For example, Figure 7 As shown, the processor 710, memory 720, and communication interface 730 are connected via bus 740 and communicate with each other.

[0118] The communication interface 730 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0119] Bus 740 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-E) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 740 may include one or more buses. Although specific buses are described and illustrated in the embodiments of this application, this application considers any suitable bus or interconnection.

[0120] For example, the electronic device 700 can be a mobile phone, tablet computer, laptop computer, handheld computer, in-vehicle electronic device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc.

[0121] The electronic device can execute the payment method in the embodiments of this application, thereby achieving a combination Figures 1 to 3 The payment method described, and the beneficial effects of the corresponding method embodiments, will not be elaborated further here.

[0122] Furthermore, in conjunction with the payment methods in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the payment methods in the above embodiments. Examples of such computer-readable storage media include non-transitory computer-readable storage media, such as read-only memory (ROM).

[0123] The computer program instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the payment method shown in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0124] In conjunction with the payment methods described in the above embodiments, this application can provide a computer program product to implement them. When the instructions in this computer program product are executed by the processor of an electronic device, they implement any of the payment methods described in the above embodiments.

[0125] The computer program products of the above embodiments are used to implement the payment method shown in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0126] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0127] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0128] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0129] The aspects of this application have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0130] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A payment method, characterized in that, Applied to a payment terminal, the method includes: The system receives the order amount of the first order sent by the acquiring system. The order amount is obtained by the acquiring system from the graphic code transaction request. The graphic code transaction request is generated by the merchant system based on the first order and its corresponding target graphic code. The target graphic code is generated based on the basic card data. The basic card data is read by the payment terminal in response to the graphic code generation request sent by the merchant system corresponding to the first order. Based on the order amount and the preset password-free rules, a password input scheme is determined; Based on the password input scheme, target card data is obtained, wherein the target card data includes at least the order amount and the basic card data; The target card data is sent to the acquiring system so that the acquiring system can make payment based on the target card data and the graphic code transaction request.

2. The method according to claim 1, characterized in that, Before receiving the order amount of the first order sent by the acquiring system, the method further includes: In response to the request sent by the merchant system to generate a graphic code corresponding to the first order, the basic card data is read; Based on the basic card data, obtain the target graphic code; The target graphic code is sent to the merchant system, so that the merchant system generates a graphic code transaction request based on the first order and the target graphic code, and sends the graphic code transaction request to the acquiring system.

3. The method according to claim 2, characterized in that, The step of obtaining the target graphic code based on the basic card data includes: Based on the basic card data, a first graphic code acquisition request is generated; Send the first graphic code acquisition request to the acquiring system; The acquiring system receives the target graphic code returned in response to the first graphic code acquisition request.

4. The method according to claim 2, characterized in that, The step of obtaining the target graphic code based on the basic card data includes: Obtain at least one preset graphic code, which is pre-issued to the payment terminal by the acquiring system; Select a target preset graphic code from the at least one preset graphic code; The target graphic code is generated based on the target preset graphic code and the basic card data.

5. The method according to claim 1, characterized in that, The step of determining the password input scheme based on the order amount and preset password-free rules includes: The card transaction attributes are obtained by parsing the basic card data; Based on the order amount, the preset password-free rules, and the card transaction attributes, a password input scheme is determined.

6. The method according to claim 1 or 5, characterized in that, The step of determining the password input scheme based on the order amount and preset password-free rules includes: If the order amount meets the preset password-free rule, the password input scheme is determined to be password-free. If the order amount does not meet the preset password-free rule, the password input scheme is determined to require a password.

7. The method according to claim 1, characterized in that, The step of obtaining target card data based on the password input scheme includes: When the password input scheme is one where no password is required, the target card data is generated based on the basic card data and the order amount; When the password input scheme requires a password, a password input interface is displayed; Receive the transaction password entered by the user on the password input interface; The target card data is generated based on the transaction password, the basic card data, and the order amount.

8. A payment method, characterized in that, Applied to an acquiring system, the method includes: The system receives a graphic code transaction request sent by the merchant system. The graphic code transaction request is generated based on the first order and its corresponding target graphic code. The target graphic code is generated based on basic card data. The basic card data is read by the payment terminal in response to the graphic code generation request sent by the merchant system corresponding to the first order. Parse the graphic code transaction request to obtain the order amount of the first order; The order amount is sent to the payment terminal so that the payment terminal determines a password input scheme based on the order amount and a preset password-free rule, and obtains target card data based on the password input scheme. The target card data includes at least the order amount and the basic card data. Receive the target card data sent by the payment terminal; Payment is made based on the target card data and the graphic code transaction request.

9. The method according to claim 8, characterized in that, The method further includes: Receive a first graphic code acquisition request sent by the payment terminal, wherein the first graphic code acquisition request includes the basic card data; In response to the first graphic code acquisition request, a target graphic code is generated based on the base card data; The target graphic code is sent to the payment terminal.

10. The method according to claim 8, characterized in that, The method further includes: Receive the second graphic code acquisition request sent by the payment terminal; In response to the second graphic code acquisition request, multiple preset graphic codes are generated; The payment terminal is sent with the plurality of preset graphic codes, which are used to associate with the basic card data to generate the target graphic code.

11. The method according to any one of claims 8-10, characterized in that, After making payment based on the target card data and the graphic code transaction request, the method further includes: Obtain the first transaction result; Based on the graphic code payment standard, the first transaction result is encapsulated to obtain the second transaction result, where the transaction type in the second transaction result is card transaction; The second transaction result is sent to the merchant system.

12. A payment method, characterized in that, Applied to a merchant system, the method includes: Generate a graphic code generation request corresponding to the first order; Send the graphic code generation request to the payment terminal; The payment terminal receives a target graphic code returned in response to the graphic code generation request, wherein the target graphic code is generated by the payment terminal based on the read basic card data. Based on the first order and the target graphic code, generate a graphic code transaction request; The acquiring system sends the graphic code transaction request to the acquiring system, so that the acquiring system can parse the graphic code transaction request to obtain the order amount, obtain the target card data based on the order amount, and make payment based on the target card data and the graphic code transaction request. The target card data includes at least the order amount and the basic card data. The target card data is obtained by the payment terminal based on a password input scheme, which is determined by the payment terminal based on the order amount and a preset password-free rule.

13. The method according to claim 12, characterized in that, After sending the graphic code transaction request to the acquiring system, the method further includes: The system receives a second transaction result sent by the acquiring system. The second transaction result is encapsulated based on the graphic code payment specification, and the transaction type in the second transaction result is a card transaction.

14. A payment device, characterized in that, The device, used in payment terminals, includes: The first receiving module is used to receive the order amount of the first order sent by the acquiring system. The order amount is obtained by the acquiring system from the graphic code transaction request. The graphic code transaction request is generated by the merchant system based on the first order and its corresponding target graphic code. The target graphic code is generated based on the basic card data. The basic card data is read by the payment terminal in response to the graphic code generation request sent by the merchant system corresponding to the first order. The determination module is used to determine the password input scheme based on the order amount and the preset password-free rules; The first acquisition module is used to acquire target card data based on the password input scheme, wherein the target card data includes at least the order amount and the basic card data; The first sending module is used to send the target card data to the acquiring system so that the acquiring system can make payment based on the target card data and the graphic code transaction request.

15. A payment device, characterized in that, The device, used in an acquiring system, includes: The second receiving module is used to receive a graphic code transaction request sent by the merchant system. The graphic code transaction request is generated based on the first order and its corresponding target graphic code. The target graphic code is generated based on the basic card data. The basic card data is read by the payment terminal in response to the graphic code generation request sent by the merchant system corresponding to the first order. The parsing module is used to parse the graphic code transaction request to obtain the order amount of the first order; The second sending module is used to send the order amount to the payment terminal so that the payment terminal can determine the password input scheme based on the order amount and the preset password-free rules, and obtain the target card data based on the password input scheme. The target card data includes at least the order amount and the basic card data. The second receiving module is further configured to receive the target card data sent by the payment terminal; The payment module is used to make payments based on the target card data and the graphic code transaction request.

16. A payment device, characterized in that, The device, used in a merchant system, includes: The third generation module is used to generate a graphic code generation request corresponding to the first order; The third sending module is used to send the graphic code generation request to the payment terminal; The third receiving module is used to receive the target graphic code returned by the payment terminal in response to the graphic code generation request, wherein the target graphic code is generated by the payment terminal based on the read basic card data; The third generation module is further configured to generate a graphic code transaction request based on the first order and the target graphic code; The third sending module is further configured to send the graphic code transaction request to the acquiring system, so that the acquiring system can parse the graphic code transaction request to obtain the order amount, obtain target card data based on the order amount, and make payment based on the target card data and the graphic code transaction request. The target card data includes at least the order amount and the basic card data. The target card data is obtained by the payment terminal based on a password input scheme, which is determined by the payment terminal based on the order amount and a preset password-free rule.

17. An electronic device, characterized in that, The electronic device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the payment method as described in any one of claims 1-7, 8-11, or 12-13.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the payment method as described in any one of claims 1-7, 8-11, or 12-13.

19. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device causes the electronic device to perform the payment method as described in any one of claims 1-7, 8-11, or 12-13.

Images