Credit-based transaction processing method and device

Abstract

The embodiment of the invention provides a credit-based transaction processing method and device, and the method comprises the steps: obtaining an access instruction which is submitted by a payee and aims at a credit transaction service of an application program, submitting a service access request to a server, and then receiving a credit transaction page returned by the server, the method comprises the following steps: receiving a credit transaction page of a payee, submitting transaction parameters input by the payee based on the credit transaction page to a server, receiving and displaying a transaction identifier for carrying out credit transaction returned by the server, scanning the transaction identifier by a payment terminal of a payer carrying out credit transaction with the payee, and submitting a credit transaction request to the server to carry out credit transaction detection; and finally, acquiring a credit transaction result returned by the server after credit transaction determination based on the transaction parameters under the condition that the credit transaction detection is passed, thereby realizing transaction processing between the payee and the payer based on the credit transaction detection.

Description

Technical Field

[0001] This document relates to the field of data processing technology, and in particular to a credit-based transaction processing method and apparatus. Background Technology

[0002] With the continuous development of internet technology and the increasing popularity of digital payment methods, various mobile application-based payment services are emerging, covering multiple online and offline transaction scenarios, providing convenience for financial transactions between individuals. As the credit system is gradually built and data service capabilities are improved, more and more services are beginning to introduce credit assessment mechanisms to support more flexible transaction models. In this context, with the credit system gradually integrated into daily transaction services, exploring the combination of the credit system and transaction services in different transaction scenarios has become a key focus for all parties. Summary of the Invention

[0003] This specification provides one or more embodiments of a first credit-based transaction processing method applied to a payment terminal. The method includes: obtaining an access instruction for a credit transaction service submitted by the payee for an application, and submitting a service access request to a server; receiving a credit transaction page returned by the server, and submitting transaction parameters input by the payee based on the credit transaction page to the server; receiving and displaying a transaction identifier for a credit transaction returned by the server; the payment terminal of the payer conducting the credit transaction with the payee scanning the transaction identifier and submitting a credit transaction request to the server for credit transaction detection; obtaining a credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters if the credit transaction detection passes; and synchronizing the payee's pending payment bill generated after the credit transaction confirmation to the bill list within the application.

[0004] This specification provides one or more embodiments of a second credit-based transaction processing method applied to a payment terminal. The method includes: obtaining an access instruction for a credit transaction service submitted by the payer for an application, and submitting a service access request to a server; scanning a transaction identifier displayed on the payment terminal indicating a credit transaction, and submitting a credit transaction request to the server for credit transaction detection; obtaining a credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters submitted by the payee if the credit transaction detection passes; and synchronizing the payer's pending payment bill generated after the credit transaction confirmation to the bill list within the application.

[0005] This specification provides one or more embodiments of a first credit-based transaction processing apparatus, operating on a payment terminal. The apparatus includes: a request submission module configured to receive an access instruction for a credit transaction service submitted by the payee for an application, and submit a service access request to a server; a parameter submission module configured to receive a credit transaction page returned by the server and submit transaction parameters input by the payee based on the credit transaction page to the server; an identifier display module configured to receive and display a transaction identifier returned by the server indicating a credit transaction; the payment terminal of the payer conducting the credit transaction with the payee scans the transaction identifier and submits a credit transaction request to the server for credit transaction detection; and a result acquisition module configured to acquire the credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters if the credit transaction detection passes; the payee's pending payment bill generated after the credit transaction confirmation is synchronized to the bill list within the application.

[0006] This specification provides one or more embodiments of a second credit-based transaction processing apparatus, operating on a payment terminal. The apparatus includes: a request submission module configured to receive an access instruction for a credit transaction service submitted by the payer for an application, and submit a service access request to a server; an identifier scanning module configured to scan transaction identifiers displayed on the payment terminal for credit transactions, and submit a credit transaction request to the server for credit transaction detection; and a result acquisition module configured to acquire the credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters submitted by the payee, provided the credit transaction detection passes; the payer's pending payment bill generated after the credit transaction confirmation is synchronized to the bill list within the application.

[0007] This specification provides one or more embodiments of a payment terminal, including: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to: obtain an access instruction for a credit transaction service submitted by a payee for an application, and submit a service access request to a server; receive a credit transaction page returned by the server, and submit transaction parameters input by the payee based on the credit transaction page to the server; receive and display a transaction identifier for a credit transaction returned by the server; and have the payment terminal of the payer conducting the credit transaction with the payee scan the transaction identifier and submit a credit transaction request to the server for credit transaction detection; obtain a credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters if the credit transaction detection passes; and synchronize the payee's pending bill generated after the credit transaction confirmation to the bill list within the application.

[0008] This specification provides one or more embodiments of a payment terminal, including: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to: obtain an access instruction for a credit transaction service submitted by a payer for an application, and submit a service access request to a server; scan a transaction identifier displayed on the payment terminal for a credit transaction, and submit a credit transaction request to the server for credit transaction detection; obtain a credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters submitted by the payee if the credit transaction detection passes; the payer's pending payment bill generated after the credit transaction confirmation is synchronized to the bill list within the application.

[0009] This specification provides one or more embodiments of a first computer-readable storage medium for storing computer-executable instructions, which, when executed, perform the following process: obtaining an access instruction for a credit transaction service submitted by a payee for an application, and submitting a service access request to a server; receiving a credit transaction page returned by the server, and submitting transaction parameters input by the payee based on the credit transaction page to the server; receiving and displaying a transaction identifier for a credit transaction returned by the server; the payment terminal of the payer conducting the credit transaction with the payee scans the transaction identifier and submits a credit transaction request to the server for credit transaction detection; obtaining a credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters if the credit transaction detection passes; and synchronizing the payee's pending bill generated after the credit transaction confirmation to the bill list within the application.

[0010] This specification provides one or more embodiments of a second computer-readable storage medium for storing computer-executable instructions, which, when executed, perform the following process: obtaining an access instruction for a credit transaction service submitted by the payer for the application, and submitting a service access request to the server; scanning a transaction identifier displayed on the payment terminal for a credit transaction, and submitting a credit transaction request to the server for credit transaction detection; obtaining a credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters submitted by the payer if the credit transaction detection passes; and synchronizing the payer's pending payment bill generated after the credit transaction confirmation to the bill list within the application. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in one or more embodiments of this specification or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Figure 1 A schematic diagram illustrating the implementation environment of a credit-based transaction processing method provided for one or more embodiments of this specification; Figure 2 A flowchart illustrating a first credit-based transaction processing method provided for one or more embodiments of this specification; Figure 3 This document provides a timing diagram for a credit-based transaction processing method applied to offline transaction scenarios, as illustrated in one or more embodiments of this specification. Figure 4 A flowchart illustrating a second credit-based transaction processing method provided for one or more embodiments of this specification; Figure 5 A flowchart illustrating a third credit-based transaction processing method provided for one or more embodiments of this specification; Figure 6 A schematic diagram illustrating a first embodiment of a credit-based transaction processing apparatus provided for one or more embodiments of this specification; Figure 7 A schematic diagram of a second credit-based transaction processing apparatus embodiment provided for one or more embodiments of this specification; Figure 8 This specification provides a schematic diagram of the structure of a payment terminal according to one or more embodiments. Figure 9 This is a schematic diagram of the structure of a payment terminal provided for one or more embodiments of this specification. Detailed Implementation

[0012] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of the embodiments. Based on one or more embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this document.

[0013] The credit-based transaction processing method provided in one or more embodiments of this specification is applicable to the implementation environment of credit transactions. (Refer to...) Figure 1 The implementation environment includes at least: the receiving terminal 101 of the payee, the payment terminal 102 of the payer, and the server 103; The receiving terminal 101 of the payee is used to submit transaction parameters for credit transactions to the server 103, receive and display the transaction identifier for credit transactions returned by the server 103, and obtain the credit transaction result returned by the server 103 after confirming the credit transaction. This is used to cooperate with the paying terminal 102 of the payer to complete the credit transaction processing with the server 103. The receiving terminal 101 of the payee can be a mobile phone, personal computer, tablet computer, e-book reader, device for information interaction based on VR (Virtual Reality) and AR (Augmented Reality), vehicle terminal, IoT device, wearable smart device, laptop computer and desktop computer, etc. The payer's payment terminal 102 is used to scan the transaction identifier for credit transactions displayed on the payee's payment terminal 101, so as to submit a credit transaction request to the server 103 for the server 103 to perform credit transaction detection, and to obtain the credit transaction result returned after the server 103 confirms the credit transaction, thereby cooperating with the payee's payment terminal 101 and the server 103 to complete the credit transaction processing; the payer's payment terminal 102 can be a mobile phone, personal computer, tablet computer, e-book reader, device for information interaction based on VR (Virtual Reality) and AR (Augmented Reality), vehicle terminal, IoT device, wearable smart device, laptop computer and desktop computer, etc. Server 103 is used to cooperate with the receiving terminal 101 of the payee and the payment terminal 102 of the payer to process credit transactions; server 103 can be a single server, a server cluster consisting of several servers, or one or more cloud servers in a cloud computing platform.

[0014] In this implementation environment, during the transaction processing between the payee and the payer, the payee's receiving terminal 101 receives an access instruction for the credit transaction service of the application submitted by the payee and submits a service access request to the server 103. Similarly, the payer's payment terminal 102 receives an access instruction for the credit transaction service of the application submitted by the payer and submits a service access request to the server 103. Then, the receiving terminal 101 receives the credit transaction page returned by the server 103, submits the transaction parameters entered by the payee based on the credit transaction page to the server 103, and receives the credit transaction confirmation returned by the server 103. The transaction identifier is displayed on the receiving terminal 101. The payer scans the transaction identifier displayed on the receiving terminal 101 through the payment terminal 102 and submits a credit transaction request to the server 103 for credit transaction detection. If the credit transaction detection is successful, the server 103 returns the credit transaction result to the receiving terminal 101 and the payment terminal 102 respectively. Accordingly, the receiving terminal 101 obtains the credit transaction result returned by the server 103 after confirming the credit transaction based on the transaction parameters, and the payment terminal 102 obtains the credit transaction result returned by the server 103. In this way, the transaction processing between the receiving party and the payer is realized based on the credit transaction detection.

[0015] It should be noted that, considering that the credit behavior data and other related data of the payer involved in this specification may, to some extent, fall under the privacy of the payer, authorization from the payer should be obtained before collecting such data to ensure that the data collection operation complies with relevant data management regulations. For example, the payer can authorize the data when the application is launched. The specific method of data authorization can be to send a data authorization reminder to the payer, who can obtain data authorization after confirming the reminder with an instruction. Alternatively, data authorization can also be obtained by signing a data authorization agreement to obtain authorization for data collection or data transmission. This embodiment does not limit this.

[0016] One or more embodiments of the first credit-based transaction processing method provided in this specification are as follows: Reference Figure 2 The credit-based transaction processing method provided in this embodiment specifically includes steps S202 to S208.

[0017] Step S202: Obtain the access instruction for the credit transaction service of the application submitted by the payee, and submit a service access request to the server.

[0018] In this embodiment, credit transaction service refers to a transaction service that supports non-instant fund settlement for the payer based on the payer's credit data. Specifically, during the process of the payer conducting credit transaction service, the payee can agree that the payer can fulfill the payment behavior for the transaction object within a delayed time period based on the payer's credit data. Subsequently, the payer can transfer funds to the payee's collection account based on the transaction amount of the transaction object within the delayed time period, thereby completing the credit transaction.

[0019] Among them, credit transaction service can be a subroutine that provides credit transaction service; a subroutine refers to a program function module or application component that is mounted on a client or application, or a program function module or application component that is loaded and installed by a client or application, such as a subroutine that provides credit transaction service within an application.

[0020] The recipient of the payment refers to the user or entity that receives the funds during the transaction process. Specifically, the recipient can be a merchant, such as a unit or individual business operator that provides goods or services and receives credit payments in an offline transaction scenario, or an individual user, such as a user who receives funds in a mutual transfer relationship, or a party that lends funds in an offline lending scenario. The payment terminal refers to a device operated or deployed by the payment recipient for transaction processing. The payment terminal may be a fixed payment device deployed offline by the merchant that supports communication methods such as QR code scanning, near-field communication and / or Bluetooth connection, or it may be the personal mobile phone of the payment recipient, or it may be a near-field communication device or near-field communication terminal.

[0021] In practice, during the credit-based transaction processing, after the payee submits an access instruction for the credit transaction service of the application, the payee terminal obtains the access instruction and submits a service access request to the server, so that the server can send the credit transaction page for transaction processing based on the service access request.

[0022] Step S204: Receive the credit transaction page returned by the server and submit the transaction parameters entered by the payee based on the credit transaction page to the server.

[0023] As described above, after the server sends out the credit transaction page for transaction processing based on the service access request submitted by the payment terminal, the corresponding credit transaction page returned by the server is received here so that the payment recipient can input transaction parameters based on the credit transaction page.

[0024] In practice, after the server sends out the credit transaction page, the system receives and displays the returned credit transaction page. Subsequently, it obtains the transaction parameters entered by the payee based on the credit transaction page and submits them to the server, so that the server can generate a transaction identifier for the credit transaction based on the transaction parameters.

[0025] The transaction parameters refer to parameters used to characterize transaction information. Specifically, transaction parameters may include the type of credit transaction, single transaction amount threshold, cumulative transaction amount threshold, and / or delayed payment period. The single transaction amount threshold refers to the maximum amount allowed for a single credit payment by the payer during the transaction process. The cumulative transaction amount threshold refers to the maximum cumulative amount allowed for the same payer to make credit payments to the same payee within a specified time period. The delayed payment period refers to the time interval during which the payer is allowed to delay fulfilling their payment obligations, specifically the length of time from the date the transaction is concluded to the date the repayment should be completed. The delayed payment period can be configured by the payee when initiating the transaction or before, such as x hours or x days.

[0026] Optionally, the server processes credit transactions according to the credit transaction mode corresponding to the credit transaction type; the credit transaction mode includes credit guarantee transaction mode and / or credit compensation transaction mode.

[0027] Among them, the credit guarantee transaction model refers to a credit transaction model in which the payer is allowed to invite at least one trusted user as a guarantor when the payer's credit rating is lower than the credit rating threshold configured for the credit transaction of the payee. This allows the payer and the guarantor to participate in the credit transaction together when the guarantor agrees to provide credit guarantee. The credit compensation transaction model refers to a credit transaction model in which, when the payer's credit rating is lower than the credit rating threshold configured for the credit transaction of the payee, the payer is allowed to pay the payee an additional credit compensation amount as consideration for the payer's assumption of credit transaction risk. This allows the payer to continue participating in credit transactions after the credit compensation amount is transferred from the payer's account to the payee's account.

[0028] Step S206: Receive and display the transaction identifier for the credit transaction returned by the server.

[0029] In practice, after the server generates and distributes a transaction identifier for credit transactions based on the transaction parameters, the server receives and displays the transaction identifier for credit transactions. Subsequently, when the payer enters the application and accesses the credit transaction service, the payer can scan the transaction identifier displayed on the receiving terminal through the payment terminal and submit a credit transaction request to the server, so that the server can perform credit transaction detection based on the credit transaction request.

[0030] Optionally, the payment terminal of the payer conducting a credit transaction with the payee scans the transaction identifier and submits a credit transaction request to the server for credit transaction detection.

[0031] The transaction identifier can be a transaction credential used to represent a credit transaction request; the specific form of the transaction identifier can be a QR code or a barcode; the data encapsulated in the transaction identifier can be the payee identifier, the credit transaction amount, a timestamp, and / or the identifier's validity period; in addition, the transaction identifier can also encapsulate an access link for accessing the credit transaction service. In this case, with the access link encapsulated in the transaction identifier, in addition to the payer scanning the transaction identifier after entering the application and accessing the credit transaction service as described above, the payer can also scan the transaction identifier through a payment terminal to be redirected to the credit transaction service for subsequent transaction service processing.

[0032] In specific execution, after displaying the transaction identifier, the payment terminal can scan the transaction identifier to submit a credit transaction request to the server. Subsequently, the server can perform credit transaction detection based on the credit transaction request submitted by the payment terminal. In one optional implementation of this embodiment, credit transaction detection includes: Check whether the payer's credit rating is greater than or equal to the credit rating threshold configured in the credit transaction. If so, check whether the payer's credit transaction amount exceeds the transaction amount threshold configured for credit transactions; If not, determine whether the delayed payment period for the credit transaction exceeds the payment period threshold configured for the credit transaction; If not, the credit transaction check has passed.

[0033] Specifically, during the credit transaction detection process on the server, the system first checks whether the payer's credit rating is greater than or equal to the credit rating threshold configured for the credit transaction. If not, the credit transaction detection fails. If so, the server further checks whether the payer's credit transaction amount exceeds the transaction amount threshold configured for the credit transaction. If it does, the credit transaction detection fails. If it does not exceed the threshold, the server can determine whether the payer's delayed payment period for the credit transaction exceeds the payment period threshold configured for the credit transaction. If the delayed payment period exceeds the payment period threshold, the credit transaction detection fails; conversely, if the delayed payment period does not exceed the payment period threshold, the credit transaction detection passes.

[0034] It should be noted that in the process of detecting whether the payer's credit transaction amount exceeds the transaction amount threshold configured for credit transactions, the credit transaction amount can be a single transaction amount or a cumulative transaction amount. Based on this, the above detection of whether the payer's credit transaction amount exceeds the transaction amount threshold configured for credit transactions can be replaced by: detecting whether the payer's single transaction amount exceeds the single transaction amount threshold configured for credit transactions; or, it can also be replaced by: detecting whether the payer's cumulative transaction amount exceeds the cumulative transaction amount threshold configured for credit transactions. Furthermore, the execution order of each sub-step in the above-mentioned credit transaction detection implementation method can be adjusted according to actual execution needs, or each sub-step can be adaptively modified, changed, or deleted according to actual execution needs, or other sub-steps can be introduced into the above-mentioned credit transaction detection implementation method according to actual execution needs. For example, credit transaction detection includes: detecting whether the payer's credit rating is greater than or equal to the credit rating threshold configured in the credit transaction; if so, detecting whether the payer's single transaction amount exceeds the single transaction amount threshold configured in the credit transaction; if not, detecting whether the payer's cumulative transaction amount exceeds the cumulative transaction amount threshold configured in the credit transaction; if not, determining that the credit transaction detection has passed. Here, the process of performing credit transaction detection based on the modified, changed, deleted, or replaced sub-steps is similar to the above-mentioned credit transaction detection process, and can be found in the credit transaction detection process provided above.

[0035] In this process, the credit transaction configuration during the credit transaction detection can be configured by the payee based on a configuration page sent by the server before conducting the credit transaction. In one optional implementation provided in this embodiment, the credit transaction configuration is generated in the following way: Obtain the credit rating threshold, transaction amount threshold, and / or payment term threshold submitted by the payee and send them to the server so that the server can generate a credit transaction configuration based on the credit rating threshold, transaction amount threshold, and / or payment term threshold.

[0036] Specifically, during the process of configuring credit transaction settings by the payee, the payee can submit a credit rating threshold, a transaction amount threshold, and / or a payment term threshold. Correspondingly, the payee obtains the credit rating threshold, transaction amount threshold, and / or payment term threshold and sends them to the server. Subsequently, the server can generate a credit transaction configuration based on the credit rating threshold, transaction amount threshold, and / or payment term threshold.

[0037] In addition to the credit transaction configuration provided above, which allows the payee to configure the credit transaction before conducting the transaction, the server can also generate the credit transaction configuration based on default credit rating thresholds, transaction amount thresholds, and / or payment term thresholds. In another optional implementation provided in this embodiment, the credit transaction configuration is generated in the following manner: Obtain the preset configuration confirmation instruction submitted by the payee, so that the server can generate a credit transaction configuration based on a preset credit rating threshold, a preset transaction amount threshold, and / or a preset payment period threshold.

[0038] Specifically, the server can send a configuration page to the payee for the payee to select and input credit transaction configuration items. The payee can directly trigger the preset configuration confirmation control on the configuration page, and correspondingly, obtain the preset configuration confirmation instruction submitted by the payee, so that the server can generate a credit transaction configuration based on a preset credit rating threshold, a preset transaction amount threshold, and / or a preset payment period threshold. Here, the preset credit rating threshold can be a default credit rating threshold, the preset transaction amount threshold can be a default transaction amount threshold, and the preset payment period threshold can be a default payment period threshold.

[0039] It should be noted that the process of generating credit transaction configurations described above can specifically involve the payee configuring the credit transaction configuration before conducting the credit transaction, or the payee submitting a preset configuration confirmation instruction to generate the credit transaction configuration before conducting the credit transaction. Alternatively, it can involve configuring the credit transaction configuration based on the credit transaction page returned by the server during the credit transaction between the payee and the payer, so that the server can perform credit transaction detection based on the credit transaction configuration configured by the payee. In this case, the payee can submit a configuration instruction based on the credit transaction page, obtain and display the configuration page issued by the server, and obtain the credit rating threshold, transaction amount threshold, and / or payment term threshold submitted by the payee and send them to the server, so that the server can generate the credit transaction configuration based on the credit rating threshold, transaction amount threshold, and / or payment term threshold.

[0040] In practical applications, after the payment terminal scans the transaction identifier displayed on the receiving terminal to submit a credit transaction request, the server performs credit transaction detection based on the request. During the credit transaction detection process, there may be cases where the payer's credit rating is detected to be lower than the credit rating threshold configured for the credit transaction. In this case, in order to improve the flexibility and applicability of credit transactions and avoid transaction interruption due to a single credit rating failing to reach the credit rating threshold, this embodiment provides two credit transaction modes—a credit guarantee transaction mode and a credit compensation transaction mode—as supplementary mechanisms to the credit transaction process, while ensuring the security of the receiving party's transaction.

[0041] As mentioned above, the server processes credit transactions according to the credit transaction mode corresponding to the credit transaction type included in the transaction parameters. The credit transaction modes include credit guarantee transaction mode and credit compensation transaction mode. The two credit transaction modes are explained in detail below.

[0042] (1) Credit guarantee transaction model In practice, if the payer's credit rating is lower than the credit rating threshold configured for the credit transaction, the payee may allow the payer to invite at least one trusted user as a guarantor. In this way, with the guarantor's consent to provide credit guarantee, the payer and the guarantor can jointly participate in the credit transaction. In one optional implementation of this embodiment, the server processes credit transactions according to a credit guarantee transaction model, including: Send the credit guarantee request submitted by the payer for the credit transaction to the payment terminal; In response to the guarantee confirmation instruction submitted by the payment terminal, credit transaction detection is performed based on the credit rating of each guarantor user; If the detection passes, the credit transaction result is returned to the payment terminal after the credit transaction is confirmed based on the transaction parameters.

[0043] Specifically, during the credit transaction processing process based on the credit guarantee transaction model, if the server detects a credit guarantee request submitted by the payer from the payment terminal, it obtains the credit guarantee request and forwards it to the receiving terminal. Subsequently, if the server detects a guarantee confirmation instruction submitted by the receiving terminal, it performs a credit transaction check based on the credit rating of each guarantor in response to the guarantee confirmation instruction. If the credit transaction check based on the credit rating of each guarantor passes, the server confirms the credit transaction based on the transaction parameters and returns the credit transaction result to the receiving terminal. If the credit rating of any guarantor fails the credit transaction check, the server returns a guarantee failure notification to the payment terminal to inform the payer to change the guarantor, or returns a transaction failure notification to both the payment terminal and the receiving terminal. Optionally, the credit guarantee request submitted by the payer is generated after the payer selects at least one guarantor.

[0044] In this process, the server performs credit transaction checks on the credit ratings of each guarantor. Specifically, it checks whether the credit rating of each guarantor is greater than or equal to the credit rating threshold configured for the credit transaction. If so, it indicates that the credit ratings of each guarantor meet the credit rating threshold, and the credit transaction check is considered passed. Conversely, if not, it indicates that at least one guarantor's credit rating does not meet the credit rating threshold, and the credit transaction check is considered failed.

[0045] (2) Credit compensation transaction model In practice, if the payer's credit rating is less than the credit rating threshold configured for the credit transaction, the payer may be allowed to pay the payee an additional credit compensation amount as consideration for the payer's assumption of the credit transaction risk. This allows the payer to continue participating in the credit transaction after the credit compensation amount is transferred from the payer's account to the payee's account. In one optional implementation of this embodiment, the server processes credit transactions according to a credit compensation transaction model, including: Send a risk warning page containing risk information to the payment terminal; Obtain the credit compensation amount entered by the payee through the risk warning page, and transfer the credit compensation amount from the payer's account to the payee's account.

[0046] Optionally, risk warning information is obtained by inputting the payer's credit rating into a risk assessment model for risk assessment processing.

[0047] The risk assessment model refers to a model that assesses the risk level of a credit transaction based on the payer's credit rating. The input of the risk assessment model is the payer's credit rating, and the output is the transaction risk level. Here, the transaction risk level refers to the level used to characterize the likelihood of the payer defaulting or failing to perform on time in this credit transaction. For example, the transaction risk level can be divided into low risk level, medium risk level, and / or high risk level.

[0048] The credit compensation amount refers to the additional funds charged by the payer to allow the payer to participate in credit transactions; the credit supplement amount may be an amount set by the payee based on the payer's transaction risk level, in order to compensate the payee for potential losses that may be incurred due to accepting credit transactions from payers with high risk levels.

[0049] Specifically, during the credit transaction processing process according to the credit compensation transaction model, if the server detects a credit compensation request submitted by the payer from the payment terminal, the server can input the payer's credit rating into the risk assessment model based on the credit compensation request to obtain the transaction risk level. Based on the transaction risk level, the server generates risk warning information and sends a risk warning page containing the risk warning information to the receiving terminal. Subsequently, the server obtains the credit compensation amount entered by the receiving party through the risk warning page and transfers the credit compensation amount to the receiving party's account based on the payer's account, so that the payer can continue to participate in the credit transaction.

[0050] In addition, to improve the objectivity of the set credit compensation amount and ensure that the credit compensation amount matches the actual risk level, in addition to the credit compensation amount being entered by the payee through the risk warning page as mentioned above, the risk compensation parameters, credit transaction amount and / or transaction risk level output by the risk assessment model can also be input into the compensation amount algorithm to calculate the credit compensation amount. In one optional implementation of this embodiment, the server processes credit transactions according to a credit compensation transaction model, including: Send a risk warning page containing risk alert information and credit compensation amount to the payment terminal; Obtain the risk confirmation instruction submitted by the payee, and transfer the credit compensation amount to the payee's account based on the payer's account.

[0051] Optionally, the credit compensation amount is calculated by inputting the risk compensation parameters, the credit transaction amount, and / or the transaction risk level output by the risk assessment model into the compensation amount algorithm.

[0052] In practical applications, in addition to the two credit transaction modes provided above, the two credit transaction modes can also be combined. For example, credit transaction processing can be carried out based on the credit guarantee transaction mode first. If the credit transaction detection fails under the credit guarantee transaction mode, credit transaction processing can be carried out based on the credit compensation transaction mode. In one optional implementation of this embodiment, after receiving and displaying the transaction identifier for the credit transaction returned by the server, the method further includes: If a credit guarantee request for a credit transaction is received from the server, the credit guarantee page will be displayed. Obtain the guarantee confirmation instruction submitted by the payee, so that the server can detect whether the number of guarantor users is greater than or equal to the preset number of guarantors based on the guarantee confirmation instruction; The server receives a risk warning page containing the credit compensation amount and sends a risk confirmation instruction submitted by the payee to the server, so that the server can transfer the credit compensation amount from the payer's account to the payee's account based on the risk confirmation instruction.

[0053] Optionally, the credit guarantee request is submitted by the payment terminal if the credit transaction fails the check; the risk warning page is sent after the server detects that the number of guarantor users is less than the preset number of guarantors.

[0054] Specifically, after receiving and displaying the transaction identifier for a credit transaction returned by the server, the payment terminal scans the transaction identifier displayed by the receiving terminal and submits a credit transaction request to the server. If the server's credit transaction detection result based on the credit transaction request is that the credit transaction detection fails, the server sends a transaction failure notification to the payment terminal. Subsequently, if the server obtains a credit guarantee request for a credit transaction submitted by the payment terminal, it forwards the credit guarantee request to the receiving terminal. Correspondingly, the receiving terminal obtains the credit guarantee request for a credit transaction sent by the server and displays the credit guarantee page. Subsequently, if a guarantee confirmation instruction is received from the payee based on the credit guarantee page, a guarantee confirmation instruction is sent to the server. This allows the server to check whether the number of guarantor users is greater than or equal to the preset number of guarantors. If the server detects that the number of guarantor users is less than the preset number of guarantors, it further sends a risk warning page containing the credit compensation amount to the payment terminal. Correspondingly, the server receives the risk warning page containing the credit compensation amount sent by the server and sends a risk confirmation instruction submitted by the payee to the server. This allows the server to transfer the credit compensation amount from the payer's account to the payee's account based on the risk confirmation instruction. In this context, the preset number of guarantors can be the number of guarantors preset by the payee during the configuration of the credit transaction, or it can be the number of guarantors determined based on the number of guarantors assessed by the guarantee assessment model. For example, the credit transaction amount and / or the credit rating of the payer can be input into the guarantee assessment model for number assessment processing to obtain the number of guarantors assessed, and the number of guarantors can be determined based on the number of guarantors assessed. This embodiment does not limit this.

[0055] Step S208: Obtain the credit transaction result returned by the server after determining the credit transaction based on the transaction parameters if the credit transaction detection passes.

[0056] As described above, after the server scans the transaction identifier and submits the credit transaction request based on the payment terminal of the payer, it performs a credit transaction check. If the credit transaction check passes, the server can generate a credit transaction result and send it to the receiving terminal and the payment terminal respectively. If the credit transaction check fails, the server can generate a credit transaction failure notification and send it to the receiving terminal and the payment terminal respectively.

[0057] In practice, after the server performs credit transaction detection and the credit transaction passes the detection, the server can determine the credit transaction based on the transaction parameters and return the credit transaction result to the receiving terminal. Accordingly, the credit transaction result returned by the server can be obtained.

[0058] Optionally, the payee's pending payment invoice generated after the credit transaction is confirmed is synchronized to the invoice list within the application. The pending payment invoice refers to records of receivables for which settlement has not yet been completed. Specifically, it refers to records of receivables obtained by the payee after a credit transaction has been entered into, indicating that the payee is obligated to fulfill payment within a certain delayed period. The pending payment invoice can also be replaced with a deferred payment invoice or a post-payment invoice; similarly, subsequent pending payment invoices can also be replaced with deferred payment invoices or post-payment invoices.

[0059] In practical applications, after the payee and the payer reach a credit transaction, there may be situations where the payer fails to settle the receivables in a timely manner within the agreed delayed payment period. In such cases, in order to prevent the payer from directly entering a default or overdue state, the delayed payment period can be extended with the consent of the payee. In one optional implementation of this embodiment, after the server confirms the credit transaction, it performs the following operations: If a request for an extension of the payment period for a credit transaction is detected, an extension request page is sent to the receiving terminal. Obtain the payee's confirmation instruction for the extension application, and update the delayed payment period based on the confirmation instruction.

[0060] Specifically, the server can send an extension request page to the payer after detecting that the delayed payment period has expired. If the server detects that the payer has submitted an extension request for the delayed payment period of the credit transaction, it will further send an extension request page to the receiving terminal. If the server receives an extension confirmation instruction from the receiving terminal, it indicates that the receiving terminal agrees to extend the delayed payment period, and the server updates the delayed payment period based on the extension confirmation instruction. If the server receives an extension rejection instruction from the receiving terminal, it indicates that the receiving terminal does not agree to extend the delayed payment period, and the server marks the payer's outstanding bill as an overdue bill based on the extension rejection instruction.

[0061] In addition, in practical applications, in order to improve the payer's initiative to fulfill the outstanding bills in a timely manner within the deferred payment period, the payer's credit rating can be updated based on the bill status of the outstanding bill; optionally, the server can update the credit rating after the bill status of the outstanding bill changes. In one optional implementation of this embodiment, the server's update process for credit rating includes: Generate the payer's credit behavior data based on the bill status of the updated outstanding receivables bill; Credit behavior data is input into a credit assessment model for credit assessment processing to obtain the payer's updated credit rating.

[0062] The credit assessment model refers to a model that performs credit assessment on the credit rating of the payer. The input of the credit assessment model is the credit behavior data of the payer, and the output is the credit rating of the payer. The credit behavior data refers to the data that characterizes the credit status and performance behavior of the payer in the credit transaction process. For example, the credit behavior data may include performance behavior data such as whether the payer makes timely repayments, whether there are overdue behaviors, the number of overdue days and / or the frequency of overdue payments.

[0063] Specifically, during the process of updating credit ratings, the server can simultaneously determine the updated billing status of the bills to be paid based on the updated billing status of the bills to be receivable. Based on this, the credit behavior data of the payer can be generated according to the updated billing status of the bills to be receivable. This credit behavior data is then input into a credit assessment model for credit assessment processing to obtain the payer's credit rating. Here, the credit rating output by the credit assessment model is the payer's updated credit rating. Based on this, the updated credit rating of the payer output by the credit assessment model is obtained. Alternatively, generating the payer's credit behavior data based on the updated billing status of the bills to be receivable can be replaced with generating the payer's credit behavior data based on the updated billing status of the bills to be paid.

[0064] In practical applications, to incentivize payers to repay outstanding bills in credit transactions on a timely basis, in the aforementioned credit guarantee transaction model, if the payer has overdue payments for the credit transaction, in addition to updating the payer's credit rating as described above, the credit ratings of each guarantor who provides a credit guarantee for the payer can also be updated based on the payer's credit behavior data under the overdue behavior. For example, the server's update of the credit rating includes: generating the payer's credit behavior data based on the updated bill status of the outstanding bill, inputting the credit behavior data and the guarantor's credit rating into the credit assessment model for credit assessment processing to obtain the updated credit rating of the guarantor. Furthermore, to enhance payers' willingness to repay outstanding bills and minimize their overdue days, the number of overdue days can be incorporated as reference data during the credit rating update process. For example, the server's credit rating update process includes: determining the payer's overdue days based on the updated bill status; inputting the overdue days and the payer's credit rating into a credit assessment model for credit assessment to obtain the payer's updated credit rating; this embodiment does not limit this aspect.

[0065] In summary, the credit-based transaction processing method provided in this embodiment, during the transaction processing between the payee and the payer, involves the payee's payment terminal obtaining the access instruction for the credit transaction service of the application submitted by the payee, submitting a service access request to the server, receiving the credit transaction page returned by the server, submitting the transaction parameters entered by the payee based on the credit transaction page to the server, and receiving and displaying the transaction identifier for credit transaction returned by the server. Subsequently, the payer scans the transaction identifier for credit transaction displayed by the payment terminal through the payment terminal and submits a credit transaction request to the server for credit transaction detection. If the credit transaction detection is successful, the server returns the credit transaction result to the payment terminal. Accordingly, the payer obtains the credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters. This enhances the immediacy of credit-based transaction processing between individuals between the payee and the payer while ensuring the security of credit transactions.

[0066] The following example illustrates the application of a credit-based transaction processing method provided in this embodiment in an offline transaction scenario. Figure 3 The credit-based transaction processing method provided in this embodiment will be further explained below. Figure 3 The credit-based transaction processing method applied to offline transaction scenarios includes the following steps.

[0067] Step S302: Obtain the access instruction for the credit transaction service of the application submitted by the payee, and submit a service access request to the server.

[0068] Step S306: Receive and display the credit transaction page returned by the server.

[0069] Step S310: Submit the transaction parameters entered by the payee on the credit transaction page to the server.

[0070] Step S314: Receive and display the transaction identifier for the credit transaction returned by the server.

[0071] Step S326: Receive and display the risk warning page, obtain the credit compensation amount entered by the payee based on the risk warning page, and submit it to the server.

[0072] Step S334: Obtain the credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters if the credit transaction detection passes.

[0073] Optionally, the payee's outstanding bill generated after the credit transaction is confirmed is synchronized to the bill list within the application.

[0074] It should be noted that any one or more of steps S302, S306, S310, S314, S326, and S334 can be combined with any one or more of steps S202 to S208 to form a new implementation method according to the needs of implementation and deployment; in addition, any one of steps S302, S306, S310, S314, S326, and S334 can be selected according to the actual deployment needs. One or more technical features can be combined with one or more technical features provided in steps S202 to S208 to form a new implementation method; or, any one or more technical features in steps S302, S306, S310, S314, S326 and S334 can be replaced with any one or more technical features provided in steps S202 to S208 to form a new implementation method according to the actual deployment needs, which will not be elaborated here.

[0075] Furthermore, it should be noted that steps S302, S306, S310, S314, S326, and S334 provided in this embodiment can be executed by the payment terminal. It should be noted that steps S302, S306, S310, S314, S326, and S334 executed by the payment terminal can cooperate with steps S308, S316, S322, and S336 executed by the payment terminal in the following embodiment during execution. Also, steps S302, S306, S310, S314, S326, and S334 executed by the payment terminal can cooperate with steps S304, S312, and S318 executed by the server in the following embodiment. Steps S320, S324, and S328 to S332 can also cooperate with each other during execution; therefore, when reading this embodiment, please refer to the corresponding content of steps S308, S316, S322, and S336 provided in the following embodiment of the method executed by the payment terminal, and / or refer to the corresponding content of steps S304, S312, S318 to S320, S324, and S328 to S332 provided in the following embodiment of the method executed by the server; when reading the following embodiment of the method executed by the payment terminal and / or the following embodiment of the method executed by the server, please refer to the corresponding content of steps S302, S306, S310, S314, S326, and S334 provided in this embodiment.

[0076] One or more embodiments of the second credit-based transaction processing method provided in this specification are as follows: Reference Figure 4 The credit-based transaction processing method provided in this embodiment specifically includes steps S402 to S406.

[0077] Step S402: Obtain the access instruction for the credit transaction service of the application submitted by the payer, and submit a service access request to the server.

[0078] In this embodiment, credit transaction service refers to a transaction service that supports non-instant fund settlement for the payer based on the payer's credit data. Specifically, during the process of the payer conducting credit transaction service, the payee can agree that the payer can fulfill the payment behavior for the transaction object within a delayed time period based on the payer's credit data. Subsequently, the payer can transfer funds to the payee's collection account based on the transaction amount of the transaction object within the delayed time period, thereby completing the credit transaction.

[0079] The credit transaction service may be a subroutine that provides credit transaction services; a subroutine refers to a program function module or application component mounted on a client or application, or a program function module or application component loaded and installed by a client or application, such as a subroutine within an application that provides credit transaction services.

[0080] In this embodiment, the payee refers to a user or entity that is the recipient of funds during the transaction process. Specifically, the payee can be a merchant, such as a unit or individual business operator that provides goods or services and receives credit payments in an offline transaction scenario, or the payee can be an individual user, such as a user who receives funds in a mutual transfer relationship, or the payee can be the party that lends funds in an offline lending scenario. The payment terminal refers to a device operated or deployed by the payment recipient for transaction processing; the payment terminal may be a fixed payment device deployed offline by the merchant that supports communication methods such as QR code scanning, near-field communication and / or Bluetooth connection, or it may be a near-field communication device, or it may be the personal mobile phone of the payment recipient.

[0081] In practice, during the credit-based transaction processing, after the payer submits an access instruction for the credit transaction service of the application, the payment terminal obtains the access instruction and submits a service access request to the server.

[0082] Step S404: Scan the transaction identifier displayed on the payment terminal for credit transactions and submit a credit transaction request to the server for credit transaction detection.

[0083] As described above, during the transaction processing between the payer and the payee, after the payee submits a service access request through the payment terminal, the payment terminal receives and displays the credit transaction page returned by the server, and obtains the transaction parameters entered by the payee based on the credit transaction page and submits them to the server, so that the server generates a transaction identifier for credit transaction based on the transaction parameters. After that, the payment terminal obtains and displays the transaction identifier issued by the server.

[0084] In practice, when the payment terminal displays a transaction identifier for a credit transaction, the payer can scan the transaction identifier through the payment terminal to submit a credit transaction request to the server, so that the server can perform credit transaction detection based on the credit transaction request.

[0085] Transaction parameters refer to parameters used to characterize transaction information. Specifically, transaction parameters may include the type of credit transaction, single transaction amount threshold, cumulative transaction amount threshold, and / or deferred payment period. The single transaction amount threshold refers to the upper limit of the amount that the payer is allowed to make a single credit payment during the transaction process. The cumulative transaction amount threshold refers to the upper limit of the cumulative amount that the same payer is allowed to make credit payments to the same payee within a specified time period. The deferred payment period refers to the time interval during which the payer is allowed to delay fulfilling its payment obligations, specifically the length of time from the date the transaction is concluded to the date the repayment should be completed. The deferred payment period can be configured by the payee when initiating the transaction or before initiating the transaction, such as x hours or x days.

[0086] Optionally, the server processes credit transactions according to the credit transaction mode corresponding to the credit transaction type; the credit transaction mode includes credit guarantee transaction mode and / or credit compensation transaction mode.

[0087] Among them, the credit guarantee transaction model refers to a credit transaction model in which the payer is allowed to invite at least one trusted user as a guarantor when the payer's credit rating is lower than the credit rating threshold configured for the credit transaction of the payee. This allows the payer and the guarantor to participate in the credit transaction together when the guarantor agrees to provide credit guarantee. The credit compensation transaction model refers to a credit transaction model in which, when the payer's credit rating is lower than the credit rating threshold configured for the credit transaction of the payee, the payer is allowed to pay the payee an additional credit compensation amount as consideration for the payer's assumption of credit transaction risk. This allows the payer to continue participating in credit transactions after the credit compensation amount is transferred from the payer's account to the payee's account.

[0088] The transaction identifier can be a transaction credential used to represent a credit transaction request; the specific form of the transaction identifier can be a QR code or a barcode; the data encapsulated in the transaction identifier can be the payee identifier, the credit transaction amount, a timestamp, and / or the identifier's validity period; In addition, the transaction identifier may also contain an access link for accessing the credit transaction service. In this case, in addition to scanning the transaction identifier after the payer enters the application and accesses the credit transaction service as described above, the payer can also scan the transaction identifier through the payment terminal and be redirected to the credit transaction service for subsequent transaction processing. In this case, the above steps S402 to S404 can be replaced by scanning the transaction identifier for credit transaction displayed on the payment terminal and submitting a credit transaction request to the server for credit transaction detection.

[0089] In practice, after displaying the transaction identifier, the payment terminal can scan the transaction identifier to submit a credit transaction request to the server. Correspondingly, the server can perform credit transaction detection based on the credit transaction request submitted by the payment terminal. In one optional implementation of this embodiment, credit transaction detection includes: Check whether the payer's credit rating is greater than or equal to the credit rating threshold configured in the credit transaction. If so, check whether the payer's credit transaction amount exceeds the transaction amount threshold configured for credit transactions; If not, determine whether the delayed payment period for the credit transaction exceeds the payment period threshold configured for the credit transaction; If not, the credit transaction check has passed.

[0090] Specifically, during the credit transaction detection process on the server, the system first checks whether the payer's credit rating is greater than or equal to the credit rating threshold configured for the credit transaction. If not, the credit transaction detection fails. If so, the server further checks whether the payer's credit transaction amount exceeds the transaction amount threshold configured for the credit transaction. If it does, the credit transaction detection fails. If it does not exceed the threshold, the server can determine whether the payer's delayed payment period for the credit transaction exceeds the payment period threshold configured for the credit transaction. If the delayed payment period exceeds the payment period threshold, the credit transaction detection fails; conversely, if the delayed payment period does not exceed the payment period threshold, the credit transaction detection passes.

[0091] It should be noted that in the process of detecting whether the payer's credit transaction amount exceeds the transaction amount threshold configured for credit transactions, the credit transaction amount can be a single transaction amount or a cumulative transaction amount. Based on this, the above detection of whether the payer's credit transaction amount exceeds the transaction amount threshold configured for credit transactions can be replaced by: detecting whether the payer's single transaction amount exceeds the single transaction amount threshold configured for credit transactions; or, it can also be replaced by: detecting whether the payer's cumulative transaction amount exceeds the cumulative transaction amount threshold configured for credit transactions. Furthermore, the execution order of each sub-step in the above-mentioned credit transaction detection implementation method can be adjusted according to actual execution needs, or each sub-step can be adaptively modified, changed, or deleted according to actual execution needs, or other sub-steps can be introduced into the above-mentioned credit transaction detection implementation method according to actual execution needs. For example, credit transaction detection includes: detecting whether the payer's credit rating is greater than or equal to the credit rating threshold configured in the credit transaction; if so, detecting whether the payer's single transaction amount exceeds the single transaction amount threshold configured in the credit transaction; if not, detecting whether the payer's cumulative transaction amount exceeds the cumulative transaction amount threshold configured in the credit transaction; if not, determining that the credit transaction detection has passed. Here, the process of performing credit transaction detection based on the modified, changed, deleted, or replaced sub-steps is similar to the above-mentioned credit transaction detection process, and can be found in the credit transaction detection process provided above.

[0092] In this process, the credit transaction configuration during the credit transaction detection can be configured by the payee based on a configuration page sent by the server before conducting the credit transaction. In one optional implementation provided in this embodiment, the credit transaction configuration is generated in the following way: Obtain the credit rating threshold, transaction amount threshold, and / or payment term threshold submitted by the payee and send them to the server so that the server can generate a credit transaction configuration based on the credit rating threshold, transaction amount threshold, and / or payment term threshold.

[0093] Specifically, during the process of configuring credit transaction settings by the payee, the payee can submit a credit rating threshold, a transaction amount threshold, and / or a payment term threshold. Correspondingly, the payee obtains the credit rating threshold, transaction amount threshold, and / or payment term threshold and sends them to the server. Subsequently, the server can generate a credit transaction configuration based on the credit rating threshold, transaction amount threshold, and / or payment term threshold.

[0094] In addition to the credit transaction configuration provided above, which allows the payee to configure the credit transaction before conducting the transaction, the server can also generate the credit transaction configuration based on default credit rating thresholds, transaction amount thresholds, and / or payment term thresholds. In another optional implementation provided in this embodiment, the credit transaction configuration is generated in the following manner: Obtain the preset configuration confirmation instruction submitted by the payee, so that the server can generate a credit transaction configuration based on a preset credit rating threshold, a preset transaction amount threshold, and / or a preset payment period threshold.

[0095] Specifically, the server can send a configuration page to the payee for the payee to select and input credit transaction configuration items. The payee can directly trigger the preset configuration confirmation control on the configuration page, and correspondingly, obtain the preset configuration confirmation instruction submitted by the payee, so that the server can generate a credit transaction configuration based on a preset credit rating threshold, a preset transaction amount threshold, and / or a preset payment period threshold. Here, the preset credit rating threshold can be a default credit rating threshold, the preset transaction amount threshold can be a default transaction amount threshold, and the preset payment period threshold can be a default payment period threshold.

[0096] In practical applications, after the payment terminal scans the transaction identifier displayed on the receiving terminal to submit a credit transaction request, the server performs credit transaction detection based on the request. During the credit transaction detection process, there may be cases where the payer's credit rating is detected to be lower than the credit rating threshold configured for the credit transaction. In this case, in order to improve the flexibility and applicability of credit transactions and avoid transaction interruption due to a single credit rating failing to reach the credit rating threshold, this embodiment provides two credit transaction modes—a credit transaction mode and a credit compensation transaction mode—as supplementary mechanisms to the credit transaction process, while ensuring the security of the receiving party's transaction.

[0097] As mentioned above, the server processes credit transactions according to the credit transaction mode corresponding to the credit transaction type included in the transaction parameters. The credit transaction modes include credit guarantee transaction mode and credit compensation transaction mode. The two credit transaction modes are explained in detail below.

[0098] (1) Credit guarantee transaction model In practice, if the payer's credit rating is lower than the credit rating threshold configured for the credit transaction, the payee may allow the payer to invite at least one trusted user as a guarantor. In this way, with the guarantor's consent to provide credit guarantee, the payer and the guarantor can jointly participate in the credit transaction. In one optional implementation of this embodiment, the server processes credit transactions according to a credit guarantee transaction model, including: Send the credit guarantee request submitted by the payer for the credit transaction to the payment terminal; In response to the guarantee confirmation instruction submitted by the payment terminal, credit transaction detection is performed based on the credit rating of each guarantor user; If the detection passes, the credit transaction result is returned to the payment terminal after the credit transaction is confirmed based on the transaction parameters.

[0099] Specifically, during the credit transaction processing process based on the credit guarantee transaction model, if the server detects a credit guarantee request submitted by the payer from the payment terminal, it obtains the credit guarantee request and forwards it to the receiving terminal. Subsequently, if the server detects a guarantee confirmation instruction submitted by the receiving terminal, it performs a credit transaction check based on the credit rating of each guarantor in response to the guarantee confirmation instruction. If the credit transaction check based on the credit rating of each guarantor passes, the server confirms the credit transaction based on the transaction parameters and returns the credit transaction result to the receiving terminal. If the credit rating of any guarantor fails the credit transaction check, the server returns a guarantee failure notification to the payment terminal to inform the payer to change the guarantor, or returns a transaction failure notification to both the payment terminal and the receiving terminal. Optionally, the credit guarantee request submitted by the payer is generated after the payer selects at least one guarantor.

[0100] In this process, the server performs credit transaction checks on the credit ratings of each guarantor. Specifically, it checks whether the credit rating of each guarantor is greater than or equal to the credit rating threshold configured for the credit transaction. If so, it indicates that the credit ratings of each guarantor meet the credit rating threshold, and the credit transaction check is considered passed. Conversely, if not, it indicates that at least one guarantor's credit rating does not meet the credit rating threshold, and the credit transaction check is considered failed.

[0101] (2) Credit compensation transaction model In practice, if the payer's credit rating is less than the credit rating threshold configured for the credit transaction, the payer may be allowed to pay the payee an additional credit compensation amount as consideration for the payer's assumption of the credit transaction risk. This allows the payer to continue participating in the credit transaction after the credit compensation amount is transferred from the payer's account to the payee's account. In one optional implementation of this embodiment, the server processes credit transactions according to a credit compensation transaction model, including: Send a risk warning page containing risk information to the payment terminal; Obtain the credit compensation amount entered by the payee through the risk warning page, and transfer the credit compensation amount from the payer's account to the payee's account.

[0102] Optionally, risk warning information is obtained by inputting the payer's credit rating into a risk assessment model for risk assessment processing.

[0103] The risk assessment model refers to a model that assesses the risk level of a credit transaction based on the payer's credit rating. The input of the risk assessment model is the payer's credit rating, and the output is the transaction risk level. Here, the transaction risk level refers to the level used to characterize the likelihood of the payer defaulting or failing to perform on time in this credit transaction. For example, the transaction risk level can be divided into low risk level, medium risk level, and / or high risk level.

[0104] The credit compensation amount refers to the additional funds charged by the payer to allow the payer to participate in credit transactions; the credit supplement amount may be an amount set by the payee based on the payer's transaction risk level, in order to compensate the payee for potential losses that may be incurred due to accepting credit transactions from payers with high risk levels.

[0105] Specifically, during the credit transaction processing process according to the credit compensation transaction model, if the server detects a credit compensation request submitted by the payer from the payment terminal, the server can input the payer's credit rating into the risk assessment model based on the credit compensation request to obtain the transaction risk level. Based on the transaction risk level, the server generates risk warning information and sends a risk warning page containing the risk warning information to the receiving terminal. Subsequently, the server obtains the credit compensation amount entered by the receiving party through the risk warning page and transfers the credit compensation amount to the receiving party's account based on the payer's account, so that the payer can continue to participate in the credit transaction.

[0106] In addition, in practical applications, in order to improve the objectivity of the set credit compensation amount and ensure that the credit compensation amount matches the actual risk level, in addition to the credit compensation amount being entered by the payee through the risk warning page as mentioned above, the risk compensation parameters, credit transaction amount and / or transaction risk level output by the risk assessment model can also be entered into the compensation amount algorithm to calculate the credit compensation amount. In one optional implementation of this embodiment, the server processes credit transactions according to a credit compensation transaction model, including: Send a risk warning page containing risk alert information and credit compensation amount to the payment terminal; Obtain the risk confirmation instruction submitted by the payee, and transfer the credit compensation amount to the payee's account based on the payer's account.

[0107] Optionally, the credit compensation amount is calculated by inputting the risk compensation parameters, the credit transaction amount, and / or the transaction risk level output by the risk assessment model into the compensation amount algorithm.

[0108] It should be noted that the implementation methods of credit transaction processing by the server under the two credit transaction modes provided above can be combined in any form according to actual execution needs, or can be combined in any form after adaptive modification or change according to actual execution needs. For example, the server's credit transaction processing includes: sending a credit guarantee request submitted by the payer to the receiving terminal; responding to the guarantee confirmation instruction submitted by the receiving terminal and performing credit transaction detection based on the credit rating of each guarantor; if the detection fails, sending a risk warning page containing risk warning information to the receiving terminal; obtaining the credit compensation amount entered by the payee through the risk warning page, and transferring the credit compensation amount from the payer's account to the payee's account based on the payer's account; For example, the server processes credit transactions, including: sending a credit guarantee request submitted by the payer to the receiving terminal; responding to the guarantee confirmation instruction submitted by the receiving terminal, detecting whether the number of guarantors for the guarantor is greater than or equal to the guarantor number threshold; if not, sending a risk warning page containing risk warning information and credit compensation amount to the receiving terminal; obtaining the risk confirmation instruction submitted by the receiving party, and transferring the credit compensation amount to the receiving party's account based on the payer's account; the credit compensation amount is calculated by inputting risk compensation parameters, credit transaction amount, and / or the transaction risk level output by the risk assessment model into the compensation amount algorithm.

[0109] Step S406: Obtain the credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters submitted by the payee, provided that the credit transaction detection has passed.

[0110] As described above, after the server scans the transaction identifier and submits the credit transaction request based on the payment terminal of the payer, it performs a credit transaction check. If the credit transaction check passes, the server can generate a credit transaction result and send it to the payment terminal and the receiving terminal respectively. If the credit transaction check fails, the server can generate a credit transaction failure notification and send it to the payment terminal and the receiving terminal respectively.

[0111] In practice, after the server performs credit transaction detection and the credit transaction passes the detection, the server can determine the credit transaction based on the transaction parameters and return the credit transaction result to the payment terminal. Accordingly, the credit transaction result returned by the server can be obtained.

[0112] Optionally, the payer's pending payment invoice generated after the credit transaction is confirmed is synchronized to the invoice list within the application. The pending payment invoice refers to a record of receivables for which settlement has not yet been completed. Specifically, it refers to a record of receivables for which the payer agrees with the payee to fulfill payment obligations within a certain delayed period after a credit transaction has been entered into. The pending payment invoice can also be replaced with a deferred payment invoice or a post-payment invoice; similarly, subsequent pending payment invoices can also be replaced with deferred payment invoices or post-payment invoices.

[0113] In practical applications, after the payee and the payer reach a credit transaction, there may be situations where the payer fails to settle the receivables in a timely manner within the agreed delayed payment period. In such cases, in order to prevent the payer from directly entering a default or overdue state, the delayed payment period can be extended with the consent of the payee. In one optional implementation of this embodiment, after the server confirms the credit transaction, it performs the following operations: If a request for an extension of the payment period for a credit transaction is detected, an extension request page is sent to the receiving terminal. Obtain the payee's confirmation instruction for the extension application, and update the delayed payment period based on the confirmation instruction.

[0114] Specifically, the server can send an extension request page to the payer after detecting that the delayed payment period has expired. If the server detects that the payer has submitted an extension request for the delayed payment period of the credit transaction, it will further send an extension request page to the receiving terminal. If the server receives an extension confirmation instruction from the receiving terminal, it indicates that the receiving terminal agrees to extend the delayed payment period, and the server updates the delayed payment period based on the extension confirmation instruction. If the server receives an extension rejection instruction from the receiving terminal, it indicates that the receiving terminal does not agree to extend the delayed payment period, and the server marks the payer's outstanding bill as an overdue bill based on the extension rejection instruction.

[0115] In addition, in practical applications, in order to improve the payer's initiative to fulfill the outstanding bills in a timely manner within the delayed payment period, the payer's credit rating can be updated based on the bill status of the outstanding bill; optionally, the server can update the credit rating after the bill status of the outstanding bill changes. In one optional implementation of this embodiment, the server's update process for credit rating includes: Generate the payer's credit behavior data based on the bill status of the updated pending bill; Credit behavior data is input into a credit assessment model for credit assessment processing to obtain the payer's updated credit rating.

[0116] The credit assessment model refers to a model that performs credit assessment on the credit rating of the payer. The input of the credit assessment model is the credit behavior data of the payer, and the output is the credit rating of the payer. The credit behavior data refers to the data that characterizes the credit status and performance behavior of the payer in the credit transaction process. For example, the credit behavior data may include performance behavior data such as whether the payer makes timely repayments, whether there are overdue behaviors, the number of overdue days and / or the frequency of overdue payments.

[0117] Specifically, during the process of updating the credit rating, the server generates the payer's credit behavior data based on the updated bill status of the pending bill, and inputs the credit behavior data into the credit assessment model for credit assessment processing to obtain the payer's credit rating. Here, the credit rating output by the credit assessment model is the payer's updated credit rating. Based on this, the updated credit rating of the payer output by the credit assessment model is obtained.

[0118] In practical applications, to incentivize payers to make timely repayments on outstanding bills for credit transactions, in the aforementioned credit guarantee transaction model, if the payer has overdue payments for the credit transaction, in addition to updating the payer's credit rating as described above, the credit ratings of each guarantor who provides a credit guarantee for the payer can also be updated based on the payer's credit behavior data under the overdue behavior. For example, the server's update of the credit rating includes: generating the payer's credit behavior data based on the updated bill status of the outstanding bill, inputting the credit behavior data and the guarantor's credit rating into the credit assessment model for credit assessment processing to obtain the updated credit rating of the guarantor. Furthermore, to enhance payers' willingness to repay outstanding bills and minimize their overdue days, the number of overdue days can be incorporated as reference data during the credit rating update process. For example, the server's credit rating update process includes: determining the payer's overdue days based on the updated bill status; inputting the overdue days and the payer's credit rating into a credit assessment model for credit assessment to obtain the payer's updated credit rating; this embodiment does not limit this aspect.

[0119] In summary, the credit-based transaction processing method provided in this embodiment, during the transaction processing between the payee and the payer, involves the payer's payment terminal obtaining an access instruction for the credit transaction service submitted by the payer for the application, and submitting a service access request to the server. Subsequently, when the payee's terminal displays a transaction identifier for a credit transaction, the method scans the displayed transaction identifier and submits a credit transaction request to the server for credit transaction detection. If the credit transaction detection passes, the server returns the credit transaction result to the payer's terminal. Correspondingly, the method obtains the credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters. This enhances the immediacy of credit-based transaction processing between individuals between the payee and the payer while ensuring the security of the credit transaction.

[0120] The following example illustrates the application of a credit-based transaction processing method provided in this embodiment in an offline transaction scenario. Figure 3 The credit-based transaction processing method provided in this embodiment will be further explained below. Figure 3 The credit-based transaction processing method applied to offline transaction scenarios includes the following steps.

[0121] Step S308: Obtain the access instruction for the credit transaction service of the application submitted by the payer, and submit a service access request to the server.

[0122] Step S316: Scan the transaction identifier displayed on the payment terminal for credit transactions and submit a credit transaction request to the server.

[0123] Step S322: Obtain the failure notification from the server indicating that the credit transaction detection failed, and submit a credit compensation instruction based on the credit compensation page within the credit transaction service.

[0124] Step S336: Obtain the credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters submitted by the payee, provided that the credit transaction detection has passed.

[0125] Optionally, the payer's outstanding bill generated after the credit transaction is confirmed is synchronized to the invoice list within the application.

[0126] It should be noted that any one or more of steps S308, S316, S322, and S336 can be combined with any one or more of steps S402 to S406 to form a new implementation method according to the needs of implementation and deployment. In addition, any one or more technical features in steps S308, S316, S322, and S336 can be selected and combined with any one or more technical features provided in steps S402 to S406 to form a new implementation method according to the actual deployment needs. Alternatively, any one or more technical features in steps S308, S316, S322, and S336 can also be replaced with any one or more technical features provided in steps S402 to S406 to form a new implementation method according to the actual deployment needs. These will not be elaborated on here.

[0127] Furthermore, it should be noted that steps S308, S316, S322, and S336 provided in this embodiment can be executed by the payment terminal. It should be noted that steps S308, S316, S322, and S336 executed by the payment terminal can cooperate with steps S304, S312, S318 to S320, S324, and S328 to S332 executed by the server in the following embodiments. Also, steps S308, S316, S322, and S336 executed by the payment terminal can cooperate with steps S302, S306, S310, S314, and S328 executed by the receiving terminal in the above embodiments. Steps S326 and S334 can also cooperate with each other during execution; therefore, when reading this embodiment, please refer to the corresponding content of steps S304, S312, S318 to S320, S324 and S328 to S332 provided in the method embodiment executed by the server below, and / or refer to the corresponding content of steps S302, S306, S310, S314, S326 and S334 provided in the method embodiment executed by the payment terminal above; when reading the embodiment executed by the server below and / or the embodiment executed by the payment terminal above, please refer to the corresponding content of steps S308, S316, S322 and S336 provided in this embodiment.

[0128] One or more embodiments of the third credit-based transaction processing method provided in this specification are as follows: Reference Figure 5The credit-based transaction processing method provided in this embodiment specifically includes steps S502 to S508.

[0129] Step S502: Obtain the service access request for the credit transaction service of the application submitted by the payment terminal, and return the credit transaction page to the payment terminal.

[0130] In this embodiment, credit transaction service refers to a transaction service that supports non-instant fund settlement for the payer based on the payer's credit data. Specifically, during the process of the payer conducting credit transaction service, the payee can agree that the payer can fulfill the payment behavior for the transaction object within a delayed time period based on the payer's credit data. Subsequently, the payer can transfer funds to the payee's collection account based on the transaction amount of the transaction object within the delayed time period, thereby completing the credit transaction.

[0131] The credit transaction service may be a subroutine that provides credit transaction services; a subroutine refers to a program function module or application component mounted on a client or application, or a program function module or application component loaded and installed by a client or application, such as a subroutine within an application that provides credit transaction services.

[0132] In this embodiment, the payee refers to a user or entity that is the recipient of funds during the transaction process. Specifically, the payee can be a merchant, such as a unit or individual business operator that provides goods or services and receives credit payments in an offline transaction scenario, or the payee can be an individual user, such as a user who receives funds in a mutual transfer relationship, or the payee can be the party that lends funds in an offline lending scenario. The payment terminal refers to a device operated or deployed by the payment recipient for transaction processing; the payment terminal may be a fixed payment device deployed offline by the merchant that supports communication methods such as QR code scanning, near-field communication and / or Bluetooth connection, or it may be a near-field communication device, or it may be the personal mobile phone of the payment recipient.

[0133] In specific implementation, during the credit-based transaction processing, after the payee submits an access instruction for the credit transaction service of the application, the payment terminal obtains the access instruction and submits a service access request to the server. Here, the server obtains the service access request for the credit transaction service of the application submitted by the payment terminal and returns the credit transaction page to the payment terminal. Similarly, after the payer submits an access instruction for the credit transaction service of the application, the payment terminal can also obtain the access instruction and submit a service access request to the server. Accordingly, the server obtains the service access request submitted by the payment terminal and sends the credit transaction page to the payment terminal.

[0134] Step S504: Obtain the transaction parameters submitted by the payment terminal and entered by the payee based on the credit transaction page, generate a transaction identifier based on the transaction parameters, and return it to the payment terminal.

[0135] In practice, after the credit transaction page is sent to the payment terminal, the payment terminal receives and displays the credit transaction page returned by the server. Subsequently, the payment terminal obtains and submits the transaction parameters entered by the payee based on the credit transaction page. Correspondingly, the payment terminal obtains the transaction parameters entered by the payee based on the credit transaction page, generates a transaction identifier based on the transaction parameters, and returns it to the payment terminal.

[0136] The transaction parameters refer to parameters used to characterize transaction information. Specifically, transaction parameters may include the type of credit transaction, single transaction amount threshold, cumulative transaction amount threshold, and / or delayed payment period. The single transaction amount threshold refers to the maximum amount allowed for a single credit payment by the payer during the transaction process. The cumulative transaction amount threshold refers to the maximum cumulative amount allowed for the same payer to make credit payments to the same payee within a specified time period. The delayed payment period refers to the time interval during which the payer is allowed to delay fulfilling their payment obligations, specifically the length of time from the date the transaction is concluded to the date the repayment should be completed. The delayed payment period can be configured by the payee when initiating the transaction or before, such as x hours or x days.

[0137] Optionally, credit transactions may be processed according to the credit transaction model corresponding to the type of credit transaction; credit transaction models include credit guarantee transaction model and / or credit compensation transaction model.

[0138] Among them, the credit guarantee transaction model refers to a credit transaction model in which the payer is allowed to invite at least one trusted user as a guarantor when the payer's credit rating is lower than the credit rating threshold configured for the credit transaction of the payee. This allows the payer and the guarantor to participate in the credit transaction together when the guarantor agrees to provide credit guarantee. The credit compensation transaction model refers to a credit transaction model in which, when the payer's credit rating is lower than the credit rating threshold configured for the credit transaction of the payee, the payer is allowed to pay the payee an additional credit compensation amount as consideration for the payer's assumption of credit transaction risk. This allows the payer to continue participating in credit transactions after the credit compensation amount is transferred from the payer's account to the payee's account.

[0139] Step S506: Receive the credit transaction request submitted by the payment terminal by scanning the transaction identifier, and perform credit transaction detection based on the credit transaction request.

[0140] As described above, after a transaction identifier is sent to the payment terminal, and the payment terminal displays the transaction identifier for a credit transaction, the payer can scan the transaction identifier to submit a credit transaction request. Correspondingly, the payment terminal receives the credit transaction request submitted by scanning the transaction identifier and performs credit transaction detection based on the credit transaction request.

[0141] The transaction identifier can be a transaction credential used to represent a credit transaction request; the specific form of the transaction identifier can be a QR code or a barcode; the data encapsulated in the transaction identifier can be the payee identifier, the credit transaction amount, a timestamp, and / or the identifier's validity period; in addition, the transaction identifier can also encapsulate an access link for accessing the credit transaction service. In this case, with the access link encapsulated in the transaction identifier, in addition to the payer scanning the transaction identifier after entering the application and accessing the credit transaction service as described above, the payer can also scan the transaction identifier through a payment terminal to be redirected to the credit transaction service for subsequent transaction service processing.

[0142] In specific execution, after displaying the transaction identifier, the payment terminal can scan the transaction identifier to submit a credit transaction request to the server. Correspondingly, credit transaction detection can be performed based on the credit transaction request submitted by the payment terminal. In one optional implementation of this embodiment, credit transaction detection includes: Check whether the payer's credit rating is greater than or equal to the credit rating threshold configured in the credit transaction. If so, check whether the payer's credit transaction amount exceeds the transaction amount threshold configured for credit transactions; If not, determine whether the delayed payment period for the credit transaction exceeds the payment period threshold configured for the credit transaction; If not, the credit transaction check has passed.

[0143] Specifically, during the credit transaction detection process, the first step is to check whether the payer's credit rating is greater than or equal to the credit rating threshold configured for the credit transaction. If not, the credit transaction detection is deemed unsuccessful. If so, the next step is to check whether the payer's credit transaction amount exceeds the transaction amount threshold configured for the credit transaction. If it does, the credit transaction detection is deemed unsuccessful. If it does not exceed the threshold, it can be determined whether the payer's delayed payment period for the credit transaction exceeds the payment period threshold configured for the credit transaction. If the delayed payment period exceeds the payment period threshold, the credit transaction detection is deemed unsuccessful; conversely, if the delayed payment period does not exceed the payment period threshold, the credit transaction detection is deemed successful.

[0144] It should be noted that in the process of detecting whether the payer's credit transaction amount exceeds the transaction amount threshold configured for credit transactions, the credit transaction amount can be a single transaction amount or a cumulative transaction amount. Based on this, the above detection of whether the payer's credit transaction amount exceeds the transaction amount threshold configured for credit transactions can be replaced by: detecting whether the payer's single transaction amount exceeds the single transaction amount threshold configured for credit transactions; or, it can also be replaced by: detecting whether the payer's cumulative transaction amount exceeds the cumulative transaction amount threshold configured for credit transactions. Furthermore, the execution order of each sub-step in the above-mentioned credit transaction detection implementation method can be adjusted according to actual execution needs, or each sub-step can be adaptively modified, changed, or deleted according to actual execution needs, or other sub-steps can be introduced into the above-mentioned credit transaction detection implementation method according to actual execution needs. For example, credit transaction detection includes: detecting whether the payer's credit rating is greater than or equal to the credit rating threshold configured in the credit transaction; if so, detecting whether the payer's single transaction amount exceeds the single transaction amount threshold configured in the credit transaction; if not, detecting whether the payer's cumulative transaction amount exceeds the cumulative transaction amount threshold configured in the credit transaction; if not, determining that the credit transaction detection has passed. Here, the process of performing credit transaction detection based on the modified, changed, deleted, or replaced sub-steps is similar to the above-mentioned credit transaction detection process, and can be found in the credit transaction detection process provided above.

[0145] In this process, the credit transaction configuration during the credit transaction detection can be configured by the payee based on a configuration page sent by the server before conducting the credit transaction. In one optional implementation provided in this embodiment, the credit transaction configuration is generated in the following way: Obtain the credit rating threshold, transaction amount threshold, and / or payment term threshold submitted by the payee and send them to the server so that the server can generate a credit transaction configuration based on the credit rating threshold, transaction amount threshold, and / or payment term threshold.

[0146] Specifically, during the process of configuring credit transaction settings by the payee, the payee can submit a credit rating threshold, a transaction amount threshold, and / or a payment term threshold. The payee terminal obtains the credit rating threshold, transaction amount threshold, and / or payment term threshold and sends them to the server. Accordingly, a credit transaction configuration can be generated based on the credit rating threshold, transaction amount threshold, and / or payment term threshold submitted by the payee terminal.

[0147] In addition to the above-mentioned configuration of credit transaction settings by the payee before conducting the credit transaction, credit transaction settings can also be generated based on default credit rating thresholds, transaction amount thresholds, and / or payment term thresholds. In another optional implementation provided in this embodiment, the credit transaction settings are generated in the following manner: Obtain the preset configuration confirmation instruction submitted by the payee, so that the server can generate a credit transaction configuration based on a preset credit rating threshold, a preset transaction amount threshold, and / or a preset payment period threshold.

[0148] Specifically, a configuration page can be sent to the payee for them to select and input credit transaction configuration items. The payee can directly trigger the preset configuration confirmation control on the configuration page. The payment terminal receives and submits the preset configuration confirmation instruction submitted by the payee. Correspondingly, in response to the preset configuration confirmation instruction, a credit transaction configuration is generated based on a preset credit rating threshold, a preset transaction amount threshold, and / or a preset payment period threshold. Here, the preset credit rating threshold can be a default credit rating threshold, the preset transaction amount threshold can be a default transaction amount threshold, and the preset payment period threshold can be a default payment period threshold.

[0149] In practical applications, after the payment terminal scans the transaction identifier displayed on the receiving terminal to submit a credit transaction request, credit transaction detection is performed based on the credit transaction request. During the credit transaction detection process, there may be cases where the payer's credit rating is detected to be lower than the credit rating threshold configured for the credit transaction. In this case, in order to improve the flexibility and applicability of credit transactions and avoid transaction interruption due to a single credit rating not reaching the credit rating threshold, this embodiment provides two credit transaction modes as supplementary mechanisms to the credit transaction process, ensuring the security of the receiving party's transaction while allowing the payer with a low credit rating to still have the opportunity to continue the credit transaction.

[0150] As mentioned above, credit transactions can be processed according to the credit transaction type and corresponding credit transaction mode included in the transaction parameters. The credit transaction mode includes credit guarantee transaction mode and credit compensation transaction mode. The two credit transaction modes are explained in detail below.

[0151] (1) Credit guarantee transaction model In practice, if the payer's credit rating is lower than the credit rating threshold configured for the credit transaction, the payee may allow the payer to invite at least one trusted user as a guarantor. In this way, with the guarantor's consent to provide credit guarantee, the payer and the guarantor can jointly participate in the credit transaction. In one optional implementation of this embodiment, credit transaction processing is performed according to a credit guarantee transaction model, including: Send the credit guarantee request submitted by the payer for the credit transaction to the payment terminal; In response to the guarantee confirmation instruction submitted by the payment terminal, credit transaction detection is performed based on the credit rating of each guarantor user; If the detection passes, the credit transaction result is returned to the payment terminal after the credit transaction is confirmed based on the transaction parameters.

[0152] Specifically, during the credit transaction processing based on the credit guarantee transaction model, if a credit guarantee request submitted by the payer is detected from the payment terminal, the credit guarantee request is obtained and forwarded to the receiving terminal. Subsequently, if a guarantee confirmation instruction is detected from the receiving terminal, a credit transaction check is performed based on the credit rating of each guarantor in response to the guarantee confirmation instruction. If the credit transaction check based on the credit rating of each guarantor passes, the credit transaction is confirmed based on the transaction parameters, and the credit transaction result is returned to the receiving terminal. If the credit rating of any guarantor fails the credit transaction check, a guarantee failure notification is returned to the payment terminal to inform the payer to change the guarantor, or a transaction failure notification is returned to both the payment terminal and the receiving terminal. Optionally, the credit guarantee request submitted by the payer is generated after the payer selects at least one guarantor.

[0153] Specifically, the credit transaction detection for each guarantor's credit rating can be performed to check whether each guarantor's credit rating is greater than or equal to the credit rating threshold configured for the credit transaction. If so, it indicates that the credit rating of each guarantor meets the credit rating threshold, and the credit transaction detection is confirmed to have passed. Conversely, if not, it indicates that at least one guarantor's credit rating does not meet the credit rating threshold, and the credit transaction detection is confirmed to have failed.

[0154] (2) Credit compensation transaction model In practice, if the payer's credit rating is less than the credit rating threshold configured for the credit transaction, the payer may be allowed to pay the payee an additional credit compensation amount as consideration for the payer's assumption of the credit transaction risk. This allows the payer to continue participating in the credit transaction after the credit compensation amount is transferred from the payer's account to the payee's account. In one optional implementation of this embodiment, credit transaction processing is performed according to a credit compensation transaction model, including: Send a risk warning page containing risk information to the payment terminal; Obtain the credit compensation amount entered by the payee through the risk warning page, and transfer the credit compensation amount from the payer's account to the payee's account.

[0155] Optionally, risk warning information is obtained by inputting the payer's credit rating into a risk assessment model for risk assessment processing.

[0156] The risk assessment model refers to a model that assesses the risk level of a credit transaction based on the payer's credit rating. The input of the risk assessment model is the payer's credit rating, and the output is the transaction risk level. Here, the transaction risk level refers to the level used to characterize the likelihood of the payer defaulting or failing to perform on time in this credit transaction. For example, the transaction risk level can be divided into low risk level, medium risk level, and / or high risk level.

[0157] The credit compensation amount refers to the additional funds charged by the payer to allow the payer to participate in credit transactions; the credit supplement amount may be an amount set by the payee based on the payer's transaction risk level, in order to compensate the payee for potential losses that may be incurred due to accepting credit transactions from payers with high risk levels.

[0158] Specifically, during the credit transaction processing according to the credit compensation transaction model, if a credit compensation request submitted by the payer for a credit transaction is detected by the payment terminal, the payer's credit rating can be input into the risk assessment model based on the credit compensation request to obtain the transaction risk level. Based on the transaction risk level, risk warning information is generated and sent to the receiving terminal. Subsequently, the credit compensation amount entered by the receiving party through the risk warning page is obtained, and the credit compensation amount is transferred from the payer's account to the receiving party's account to enable the payer to continue participating in the credit transaction.

[0159] In addition, to improve the objectivity of the set credit compensation amount and ensure that the credit compensation amount matches the actual risk level, in addition to the credit compensation amount being entered by the payee through the risk warning page as mentioned above, the risk compensation parameters, credit transaction amount and / or transaction risk level output by the risk assessment model can also be input into the compensation amount algorithm to calculate the credit compensation amount. In one optional implementation of this embodiment, credit transaction processing is performed according to a credit compensation transaction model, including: Send a risk warning page containing risk alert information and credit compensation amount to the payment terminal; Obtain the risk confirmation instruction submitted by the payee, and transfer the credit compensation amount to the payee's account based on the payer's account.

[0160] Optionally, the credit compensation amount is calculated by inputting the risk compensation parameters, the credit transaction amount, and / or the transaction risk level output by the risk assessment model into the compensation amount algorithm.

[0161] It should be noted that the implementation methods of credit transaction processing under the two credit transaction models provided above can be combined in any form according to actual execution needs, or can be combined in any form after adaptive modification or change according to actual execution needs. For example, credit transaction processing includes: sending a credit guarantee request submitted by the payer to the payment terminal; responding to the guarantee confirmation instruction submitted by the payment terminal and performing credit transaction detection based on the credit rating of each guarantor; if the detection fails, sending a risk warning page containing risk warning information to the payment terminal; obtaining the credit compensation amount entered by the payee through the risk warning page, and transferring the credit compensation amount from the payer's account to the payee's account based on the payer's account; For example, processing credit transactions includes: sending a credit guarantee request submitted by the payer to the payment terminal; responding to the guarantee confirmation instruction submitted by the payment terminal, detecting whether the number of guarantors for the guarantor is greater than or equal to the guarantor number threshold; if not, sending a risk warning page containing risk warning information and credit compensation amount to the payment terminal; obtaining the risk confirmation instruction submitted by the payee, and transferring the credit compensation amount to the payee's account based on the payer's account; the credit compensation amount is calculated by inputting risk compensation parameters, credit transaction amount and / or the transaction risk level output by the risk assessment model into the compensation amount algorithm.

[0162] Step S508: If the credit transaction detection passes, return the credit transaction result generated after determining the credit transaction based on the transaction parameters to the receiving terminal and the payment terminal.

[0163] As described above, after the credit transaction request submitted by the payer's payment terminal after scanning the transaction identifier is tested, if the credit transaction test passes, a credit transaction result can be generated and sent to the receiving terminal and the payment terminal respectively; if the credit transaction test fails, a credit transaction failure notification can be generated and sent to the receiving terminal and the payment terminal respectively.

[0164] In practice, after credit transaction detection is performed and the credit transaction passes the detection, the credit transaction can be determined based on the transaction parameters and the credit transaction result can be returned to the receiving terminal and the payment terminal respectively. After that, the receiving terminal and the payment terminal can obtain the credit transaction result returned by the server.

[0165] Optionally, the payee's pending payment invoice generated after the credit transaction is confirmed is synchronized to the invoice list within the application. The pending payment invoice refers to records of receivables for which settlement has not yet been completed. Specifically, it refers to records of receivables obtained by the payee after a credit transaction has been entered into, indicating that the payee is obligated to fulfill payment within a certain delayed period. The pending payment invoice can also be replaced with a deferred payment invoice or a post-payment invoice; similarly, subsequent pending payment invoices can also be replaced with deferred payment invoices or post-payment invoices.

[0166] In practical applications, after the payee and the payer reach a credit transaction, there may be situations where the payer fails to settle the receivables in a timely manner within the agreed delayed payment period. In such cases, in order to prevent the payer from directly entering a default or overdue state, the delayed payment period can be extended with the consent of the payee. In one optional implementation of this embodiment, after the credit transaction is confirmed, the following operations are performed: If a request for an extension of the payment period for a credit transaction is detected, an extension request page is sent to the receiving terminal. Obtain the payee's confirmation instruction for the extension application, and update the delayed payment period based on the confirmation instruction.

[0167] Specifically, after detecting the expiration of the delayed payment period, an extension application page can be sent to the payer. If an extension application for the delayed payment period of a credit transaction is detected, an extension application page can be further sent to the receiving terminal. If the receiving terminal receives an extension confirmation instruction from the payee regarding the extension application, it indicates that the payee agrees to extend the delayed payment period; accordingly, the delayed payment period is updated based on the extension confirmation instruction submitted by the receiving terminal. If an extension rejection instruction is received from the payee regarding the extension application, it indicates that the payee does not agree to extend the delayed payment period; accordingly, the payer's outstanding bill is marked as an overdue bill based on the extension rejection instruction submitted by the receiving terminal.

[0168] In addition, in practical applications, in order to improve the payer's initiative to fulfill the outstanding bills in a timely manner within the deferred payment period, the payer's credit rating can be updated based on the bill status of the outstanding bill; optionally, the credit rating can be updated after the bill status of the outstanding bill changes. In one optional implementation of this embodiment, the credit rating update process includes: Generate the payer's credit behavior data based on the bill status of the updated outstanding receivables bill; Credit behavior data is input into a credit assessment model for credit assessment processing to obtain the payer's updated credit rating.

[0169] The credit assessment model refers to a model that performs credit assessment on the credit rating of the payer. The input of the credit assessment model is the credit behavior data of the payer, and the output is the credit rating of the payer. The credit behavior data refers to the data that characterizes the credit status and performance behavior of the payer in the credit transaction process. For example, the credit behavior data may include performance behavior data such as whether the payer makes timely repayments, whether there are overdue behaviors, the number of overdue days and / or the frequency of overdue payments.

[0170] Specifically, during the credit rating update process, the updated bill status of the pending payment bill can be determined simultaneously based on the updated bill status of the pending receivable bill. Based on this, the payer's credit behavior data can be generated according to the updated bill status of the pending receivable bill. The credit behavior data is then input into the credit assessment model for credit assessment processing to obtain the payer's credit rating. Here, the credit rating output by the credit assessment model is the payer's updated credit rating. Based on this, the updated credit rating of the payer output by the credit assessment model is obtained.

[0171] In summary, the credit-based transaction processing method provided in this embodiment, during the transaction processing between the payee and the payer, involves the payee's payment terminal obtaining the access instruction for the credit transaction service of the application submitted by the payee, submitting a service access request to the server, receiving the credit transaction page returned by the server, submitting the transaction parameters entered by the payee based on the credit transaction page to the server, and receiving and displaying the transaction identifier for credit transaction returned by the server. Subsequently, the payer scans the transaction identifier for credit transaction displayed by the payment terminal through the payment terminal and submits a credit transaction request to the server for credit transaction detection. If the credit transaction detection is successful, the server returns the credit transaction result to the payment terminal. Accordingly, the payer obtains the credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters. This enhances the immediacy of credit-based transaction processing between individuals between the payee and the payer while ensuring the security of credit transactions.

[0172] The following example illustrates the application of a credit-based transaction processing method provided in this embodiment in an offline transaction scenario. Figure 3 The credit-based transaction processing method provided in this embodiment will be further explained below. Figure 3 The credit-based transaction processing method applied to offline transaction scenarios includes the following steps.

[0173] Step S304: Receive the service access request submitted by the payment terminal and return the credit transaction page to the payment terminal.

[0174] Step S312: Obtain the transaction parameters submitted by the payment terminal, generate a transaction identifier based on the transaction parameters, and return the transaction identifier to the payment terminal.

[0175] Step S318: Obtain the credit transaction request submitted by the payment terminal and perform credit transaction detection based on the credit transaction request; if the credit transaction detection fails, proceed to step S320 below.

[0176] Step S320: Send a failure notification to the payment terminal indicating that the credit transaction detection failed.

[0177] Step S324: Based on the credit compensation instruction submitted by the payment terminal, send a risk warning page containing risk warning information to the receiving terminal.

[0178] Optionally, risk warning information is obtained by inputting the payer's credit rating into a risk assessment model for risk assessment processing.

[0179] Step S328: Obtain the credit compensation amount and transfer the credit compensation amount from the payer's account to the payee's account.

[0180] Step S330: Generate the credit transaction result after the credit transaction is determined based on the transaction parameters.

[0181] Step S332: Return the credit transaction results to the receiving terminal and the payment terminal respectively.

[0182] It should be noted that any one or more steps in S304, S312, S318 to S320, S324, and S328 to S332 can be combined with any one or more steps in S502 to S508 to form a new implementation method according to the needs of implementation and deployment. Furthermore, steps in S304, S312, S318 to S320, S324, and S328 to S332 can be modified as needed for actual deployment. Choose any one or more technical features and combine them with any one or more technical features provided in steps S502 to S508 above to form a new implementation method; or, any one or more technical features in steps S304, S312, S318 to S320, S324 and S328 to S332 can also be replaced with any one or more technical features provided in steps S502 to S508 above to form a new implementation method according to the actual deployment needs, which will not be elaborated here.

[0183] The first embodiment of the credit-based transaction processing device provided in this specification is as follows: In the above embodiments, a first credit-based transaction processing method is provided, and correspondingly, a first credit-based transaction processing apparatus is also provided, which will be described below with reference to the accompanying drawings.

[0184] Reference Figure 6 This illustration shows a schematic diagram of an embodiment of a credit-based transaction processing device provided in this embodiment.

[0185] Since the apparatus embodiments correspond to the method embodiments, the descriptions are relatively simple. For relevant parts, please refer to the corresponding descriptions of the method embodiments provided above. The apparatus embodiments described below are merely illustrative.

[0186] This embodiment provides a credit-based transaction processing device that operates on a payment terminal. The device includes: The request submission module 602 is configured to obtain the credit transaction service access instruction submitted by the payee for the application and submit the service access request to the server. The parameter submission module 604 is configured to receive the credit transaction page returned by the server and submit the transaction parameters input by the payee based on the credit transaction page to the server. The identifier display module 606 is configured to receive and display the transaction identifier of the credit transaction returned by the server; the payment terminal of the payer who is conducting a credit transaction with the payee scans the transaction identifier and submits a credit transaction request to the server for credit transaction detection. The result acquisition module 608 is configured to acquire the credit transaction result returned by the server after the credit transaction detection is passed and the credit transaction is confirmed based on the transaction parameters; the pending bill of the payee generated after the credit transaction is confirmed is synchronized to the bill list in the application.

[0187] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0188] The second embodiment of the credit-based transaction processing device provided in this specification is as follows: In the above embodiments, a second credit-based transaction processing method is provided, and correspondingly, a second credit-based transaction processing apparatus is also provided, which will be described below with reference to the accompanying drawings.

[0189] Reference Figure 7 This illustration shows a schematic diagram of an embodiment of a credit-based transaction processing device provided in this embodiment.

[0190] Since the apparatus embodiments correspond to the method embodiments, the descriptions are relatively simple. For relevant parts, please refer to the corresponding descriptions of the method embodiments provided above. The apparatus embodiments described below are merely illustrative.

[0191] This embodiment provides a credit-based transaction processing device that operates on a payment terminal. The device includes: The request submission module 702 is configured to obtain the credit transaction service access instruction submitted by the payer for the application and submit the service access request to the server. The identifier scanning module 704 is configured to scan the transaction identifier displayed on the payment terminal for credit transactions and submit a credit transaction request to the server for credit transaction detection. The result acquisition module 706 is configured to acquire the credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters submitted by the payee, provided that the credit transaction detection is passed; the payer's pending payment bill generated after the credit transaction is confirmed is synchronized to the bill list in the application.

[0192] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0193] This manual provides the following embodiment of a payment terminal: Corresponding to the first credit-based transaction processing method described above, and based on the same technical concept, one or more embodiments of this specification also provide a payment terminal for executing the first credit-based transaction processing method provided above. Figure 8 This is a schematic diagram of the structure of a payment terminal provided for one or more embodiments of this specification.

[0194] This embodiment provides a payment terminal, including: like Figure 8 As shown, device 800 mainly consists of a communication interface 802, a user interface 804, a processor 806, and a data storage 808. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 810. The communication interface 802 enables device 800 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 802 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 802 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 802 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 802 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces. The user interface 804 includes receiving user input and providing output to the user. Therefore, user interface 804 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 804 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 804 may include software, circuitry, or other forms of logic capable of transmitting and receiving data to and from external user input / output devices. Additionally or alternatively, device 800 may support remote access from other devices via communication interface 802 or another physical interface (not shown). User interface 804 may be configured to receive user input, the position and movement of which may be indicated by indicators or cursors described herein. User interface 804 may also be configured as a display device for rendering or displaying text fragments.

[0195] Processor 806 may include one or more general-purpose processors and / or special-purpose processors. Data storage 808 may include one or more volatile and / or non-volatile storage components, and may be integrated wholly or partially with processor 806. Data storage 808 may include removable and non-removable components.

[0196] Processor 806 is capable of executing program instructions 818 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 808 to perform the various functions described herein. Data storage 808 may comprise a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 800, enable device 800 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Execution of program instructions 818 by processor 806 may result in processor 806 using data 812. For example, program instructions 818 may include an operating system 822 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 800 and one or more application programs 820 (e.g., a browser, social application, or game application). Similarly, data 812 may include operating system data 816 and application data 814. Operating system data 816 is primarily accessible to operating system 822, while application data 814 is primarily accessible to one or more application programs 820. Application data 814 may reside in a file system visible or hidden from the user of device 800. Application 820 can communicate with operating system 822 through one or more application programming interfaces (APIs). These APIs facilitate application 820 in reading and / or writing application data 814, transmitting or receiving information via communication interface 802, and receiving or displaying information on user interface 804. In some terms, application 820 may be simply referred to as "app". Furthermore, application 820 can be downloaded to device 800 through one or more online application stores or app markets. However, applications can also be installed on device 800 in other ways, such as through a web browser or a physical interface on device 800 (e.g., a USB port).

[0197] In one specific embodiment, the payment terminal includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the payment terminal, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following: Obtain the credit transaction service access instruction submitted by the payee for the application, and submit the service access request to the server; Receive the credit transaction page returned by the server, and submit the transaction parameters entered by the payee based on the credit transaction page to the server; The system receives and displays the transaction identifier returned by the server indicating a credit transaction; the payment terminal of the payer, which is conducting a credit transaction with the payee, scans the transaction identifier and submits a credit transaction request to the server for credit transaction detection. The system retrieves the credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters, provided that the credit transaction detection has passed. The outstanding bill for the payee generated after the credit transaction is confirmed is synchronized to the bill list within the application.

[0198] This specification provides the following embodiment of a payment terminal: Corresponding to the second credit-based transaction processing method described above, and based on the same technical concept, one or more embodiments of this specification also provide a payment terminal for executing the second credit-based transaction processing method described above. Figure 9 This is a schematic diagram of the structure of a payment terminal provided for one or more embodiments of this specification.

[0199] This embodiment provides a payment terminal, including: like Figure 9As shown, device 900 mainly consists of a communication interface 902, a user interface 904, a processor 906, and a data storage 908. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 910. Communication interface 902 enables device 900 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, communication interface 902 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, communication interface 902 can be a wired interface such as Ethernet, Token Ring, or USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or wide area wireless interface (e.g., WiMAX or LTE). Of course, communication interface 902 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. Communication interface 902 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide area wireless interfaces. User interface 904 includes receiving user input and providing output to the user. Therefore, user interface 904 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 904 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 904 may include software, circuitry, or other forms of logic capable of transmitting data to and receiving data from external user input / output devices. Additionally or alternatively, device 900 may support remote access from other devices via communication interface 902 or another physical interface (not shown). User interface 904 may be configured to receive user input, the position and movement of which may be indicated by indicators or cursors described herein. User interface 904 may also be configured as a display device for rendering or displaying text fragments.

[0200] Processor 906 may include one or more general-purpose processors and / or special-purpose processors. Data storage 908 may include one or more volatile and / or non-volatile storage components, and may be integrated wholly or partially with processor 906. Data storage 908 may include removable and non-removable components.

[0201] Processor 906 is capable of executing program instructions 918 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 908 to perform the various functions described herein. Data storage 908 may contain a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 900, enable device 900 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Execution of program instructions 918 by processor 906 may result in processor 906 using data 912. For example, program instructions 918 may include an operating system 922 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 900 and one or more application programs 920 (e.g., a browser, social application, or game application). Similarly, data 912 may include operating system data 916 and application data 914. Operating system data 916 is primarily accessible to operating system 922, while application data 914 is primarily accessible to one or more application programs 920. Application data 914 may reside in a file system visible or hidden from the user of device 900. Application 920 can communicate with operating system 922 through one or more application programming interfaces (APIs). These APIs facilitate application 920 reading and / or writing application data 914, transmitting or receiving information via communication interface 902, and receiving or displaying information on user interface 904. In some terms, application 920 may be simply referred to as "app". Furthermore, application 920 can be downloaded to device 900 through one or more online application stores or app markets. However, applications can also be installed on device 900 in other ways, such as through a web browser or a physical interface on device 900 (e.g., a USB port).

[0202] In one specific embodiment, the payment terminal includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the payment terminal, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following: Obtain the credit transaction service access instruction submitted by the payer for the application, and submit the service access request to the server; Scan the transaction identifier displayed on the payment terminal to initiate a credit transaction, and submit a credit transaction request to the server for credit transaction detection; The system retrieves the credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters submitted by the payee, provided that the credit transaction detection has passed; the payee's pending payment bill generated after the credit transaction is confirmed is synchronized to the bill list within the application.

[0203] The first embodiment of the computer-readable storage medium provided in this specification is as follows: Corresponding to the first credit-based transaction processing method described above, and based on the same technical concept, one or more embodiments of this specification also provide a first computer-readable storage medium.

[0204] This embodiment provides a computer-readable storage medium for storing computer-executable instructions, which, when executed, implement the following process: Obtain the credit transaction service access instruction submitted by the payee for the application, and submit the service access request to the server; Receive the credit transaction page returned by the server, and submit the transaction parameters entered by the payee based on the credit transaction page to the server; The system receives and displays the transaction identifier returned by the server indicating a credit transaction; the payment terminal of the payer, which is conducting a credit transaction with the payee, scans the transaction identifier and submits a credit transaction request to the server for credit transaction detection. The system retrieves the credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters, provided that the credit transaction detection has passed. The outstanding bill for the payee generated after the credit transaction is confirmed is synchronized to the bill list within the application.

[0205] It should be noted that the embodiments of the first computer-readable storage medium in this specification and the embodiments of the first credit-based transaction processing method in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0206] The second embodiment of the computer-readable storage medium provided in this specification is as follows: Corresponding to the second credit-based transaction processing method described above, and based on the same technical concept, one or more embodiments of this specification also provide a second computer-readable storage medium.

[0207] This embodiment provides a computer-readable storage medium for storing computer-executable instructions, which, when executed, implement the following process: Obtain the credit transaction service access instruction submitted by the payer for the application, and submit the service access request to the server; Scan the transaction identifier displayed on the payment terminal to initiate a credit transaction, and submit a credit transaction request to the server for credit transaction detection; The system retrieves the credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters submitted by the payee, provided that the credit transaction detection has passed; the payee's pending payment bill generated after the credit transaction is confirmed is synchronized to the bill list within the application.

[0208] It should be noted that the embodiments of the second type of computer-readable storage medium in this specification and the embodiments of the second type of credit-based transaction processing method in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0209] The first example of a computer program product provided in this specification is as follows: Corresponding to the first credit-based transaction processing method described above, and based on the same technical concept, one or more embodiments of this specification also provide a first computer program product.

[0210] A computer program product includes a computer program / instructions that, when executed by a processor, perform the following steps: Obtain the credit transaction service access instruction submitted by the payee for the application, and submit the service access request to the server; Receive the credit transaction page returned by the server, and submit the transaction parameters entered by the payee based on the credit transaction page to the server; The system receives and displays the transaction identifier returned by the server indicating a credit transaction; the payment terminal of the payer, which is conducting a credit transaction with the payee, scans the transaction identifier and submits a credit transaction request to the server for credit transaction detection. The system retrieves the credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters, provided that the credit transaction detection has passed. The outstanding bill for the payee generated after the credit transaction is confirmed is synchronized to the bill list within the application.

[0211] It should be noted that the embodiments of the first type of computer program product in this specification and the embodiments of the first credit-based transaction processing method in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0212] The second example of a computer program product provided in this specification is as follows: Corresponding to the second credit-based transaction processing method described above, and based on the same technical concept, one or more embodiments of this specification also provide a second computer program product.

[0213] A computer program product includes a computer program / instructions that, when executed by a processor, perform the following steps: Obtain the credit transaction service access instruction submitted by the payer for the application, and submit the service access request to the server; Scan the transaction identifier displayed on the payment terminal to initiate a credit transaction, and submit a credit transaction request to the server for credit transaction detection; The system retrieves the credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters submitted by the payee, provided that the credit transaction detection has passed; the payee's pending payment bill generated after the credit transaction is confirmed is synchronized to the bill list within the application.

[0214] It should be noted that the embodiments of the second type of computer program product in this specification and the embodiments of the second type of credit-based transaction processing method in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0215] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments. For example, the device embodiment, equipment embodiment and computer-readable storage medium embodiment are all similar to the method embodiment, so the description is relatively simple. When reading the relevant content of the device embodiment, equipment embodiment and computer-readable storage medium embodiment, please refer to the description of the method embodiment.

[0216] While one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is merely one possible execution order among many steps, and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims. This specification uses specific terms to describe embodiments of this specification. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic related to at least one embodiment of this specification. Therefore, it should be emphasized and noted that "an embodiment," "one embodiment," or "an alternative embodiment" mentioned twice or more in different locations in this specification do not necessarily refer to the same embodiment. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0217] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0218] In the 1930s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many improvements to the methodology today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that an improvement to the methodology cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0219] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 525D, Atmel AT91SAM, Microchip PIC18F25K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0220] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0221] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, when implementing the embodiments of this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0222] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0223] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of 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, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0224] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0225] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0226] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0227] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0228] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer-readable storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0229] It should also be noted that 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 limitation, an element defined by the phrase "comprising at least one…" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0230] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0231] The above description is merely an embodiment of this document and is not intended to limit the scope of this document. Various modifications and variations can be made to this document by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this document should be included within the scope of the claims of this document.

Claims

1. A credit-based transaction processing method applied to a payment terminal, the method comprising: Obtain the credit transaction service access instruction submitted by the payee for the application, and submit the service access request to the server; Receive the credit transaction page returned by the server, and submit the transaction parameters entered by the payee based on the credit transaction page to the server; Receive and display the transaction identifier for the credit transaction returned by the server; The payment terminal of the payer, which is conducting a credit transaction with the payee, scans the transaction identifier and submits a credit transaction request to the server for credit transaction detection. Obtain the credit transaction result returned by the server after determining the credit transaction based on the transaction parameters if the credit transaction detection passes; Once the credit transaction is confirmed, the outstanding bill for the payee is synchronized to the bill list within the application.

2. The credit-based transaction processing method according to claim 1, wherein the transaction parameters include the credit transaction type for which the credit transaction is being conducted; The server processes credit transactions according to the credit transaction mode corresponding to the credit transaction type. The credit transaction models include credit guarantee transaction models and / or credit compensation transaction models.

3. The credit-based transaction processing method according to claim 2, wherein the server performs credit transaction processing according to the credit compensation transaction mode, comprising: Send a risk warning page containing risk warning information to the payment terminal; The risk warning information is obtained by inputting the payer's credit rating into a risk assessment model for risk assessment processing; Obtain the credit compensation amount entered by the payee through the risk warning page, and transfer the credit compensation amount from the payer's account to the payee's account.

4. The credit-based transaction processing method according to claim 2, wherein the server performs credit transaction processing according to the credit guarantee transaction mode, including: Send the credit guarantee request submitted by the payer for the credit transaction to the receiving terminal; The credit guarantee request is generated after the payer selects at least one guarantor. In response to the guarantee confirmation instruction submitted by the payment terminal, the credit transaction detection is performed based on the credit rating of each guarantor user; If the detection passes, the credit transaction result is returned to the payment terminal after the credit transaction is confirmed based on the transaction parameters.

5. The credit-based transaction processing method according to claim 1, after the step of receiving and displaying the transaction identifier for the credit transaction returned by the server, further includes: If a credit guarantee request for the credit transaction is received from the server, the credit guarantee page will be displayed. The credit guarantee request is submitted by the payment terminal if the credit transaction detection fails. The server obtains the guarantee confirmation instruction submitted by the payee, so that the server can detect whether the number of guarantor users is greater than or equal to the preset number of guarantors based on the guarantee confirmation instruction. The server receives a risk warning page containing the credit compensation amount and sends a risk confirmation instruction submitted by the payee to the server, so that the server transfers the credit compensation amount from the payer's account to the payee's account based on the risk confirmation instruction; the risk warning page is sent after the server detects that the number of guarantor users is less than the preset number of guarantors.

6. In the credit-based transaction processing method according to claim 1, after the server determines the credit transaction, it performs the following operations: If the payer submits an extension request for the delayed payment period of the credit transaction, an extension request page is sent to the receiving terminal; Obtain the payment recipient's confirmation instruction for the extension application, and update the delayed payment period based on the confirmation instruction.

7. The credit-based transaction processing method according to claim 1, wherein the credit transaction detection includes: Detect whether the credit rating of the payer is greater than or equal to the credit rating threshold configured in the credit transaction; If so, check whether the credit transaction amount of the payer exceeds the transaction amount threshold configured for the credit transaction; If not, determine whether the delayed payment period for the credit transaction by the payer exceeds the payment period threshold configured for the credit transaction; If not, the credit transaction check has passed.

8. The credit-based transaction processing method according to claim 7, wherein the credit transaction configuration is generated in the following manner: The system obtains the credit rating threshold, transaction amount threshold, and / or payment term threshold submitted by the payee and sends them to the server, so that the server generates the credit transaction configuration based on the credit rating threshold, transaction amount threshold, and / or payment term threshold; or... The server obtains a preset configuration confirmation instruction submitted by the payee, so that the server generates the credit transaction configuration based on a preset credit rating threshold, a preset transaction amount threshold, and / or a preset payment period threshold.

9. The credit-based transaction processing method according to claim 1, wherein the server updates the credit rating of the payer after the bill status of the pending bill changes; in, The server's update process for the payer's credit rating includes: The credit behavior data of the payer is generated based on the updated bill status of the outstanding bill; The credit behavior data is input into the credit assessment model for credit assessment processing to obtain the payer's updated credit rating.

10. A credit-based transaction processing method applied to a payment terminal, the method comprising: Obtain the credit transaction service access instruction submitted by the payer for the application, and submit the service access request to the server; Scan the transaction identifier displayed on the payment terminal to initiate a credit transaction, and submit a credit transaction request to the server for credit transaction detection; Obtain the credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters submitted by the payee, provided that the credit transaction detection is passed; Once the credit transaction is confirmed, the payer's pending payment bill is synchronized to the bill list within the application.

11. The credit-based transaction processing method according to claim 10, if the credit transaction detection fails, the following operation is performed: Receive and display the transaction failure notification sent by the server; the payment failure notification includes information about the reason for the failure. in, The credit transaction detection includes: Detect whether the credit rating of the payer is greater than or equal to the credit rating threshold configured in the credit transaction; If so, check whether the credit transaction amount of the payer exceeds the transaction amount threshold configured for the credit transaction; If not, determine whether the delayed payment period for the credit transaction by the payer is greater than the payment period threshold configured for the credit transaction; If the value is greater than 1, the credit transaction detection has failed.

12. The credit-based transaction processing method according to claim 10, further comprising, after the step of obtaining the credit transaction result returned by the server after determining the credit transaction based on the transaction parameters submitted by the payee when the credit transaction detection passes: Obtain the extension application page returned by the server, which allows for the application to extend the delayed payment period; The application extension page is sent after the server detects that the delayed payment period has expired; The server obtains the payment extension request submitted by the payer for the credit transaction and submits it to the server; the server updates the payment extension period based on the payment recipient's confirmation instruction for the extension request.

13. The credit-based transaction processing method according to claim 10, wherein the transaction parameters include the credit transaction type for which the credit transaction is being conducted; The server processes credit transactions according to the credit transaction mode corresponding to the credit transaction type. The credit transaction models include credit guarantee transaction models and / or credit compensation transaction models.

14. The credit-based transaction processing method according to claim 13, wherein the server performs credit transaction processing according to the credit guarantee transaction mode, comprising: Send the credit guarantee request submitted by the payer for the credit transaction to the receiving terminal; The credit guarantee request is generated after the payer selects at least one guarantor. In response to the guarantee confirmation instruction submitted by the payment terminal, the credit transaction detection is performed based on the credit rating of each guarantor user; If the detection passes, the credit transaction result is returned to the payment terminal after the credit transaction is confirmed based on the transaction parameters.

15. The credit-based transaction processing method according to claim 13, wherein the server performs credit transaction processing according to the credit compensation transaction mode, comprising: Send a risk warning page containing risk warning information to the payment terminal; The risk warning information is obtained by inputting the payer's credit rating into a risk assessment model for risk assessment processing; Obtain the credit compensation amount entered by the payee through the risk warning page, and transfer the credit compensation amount from the payer's account to the payee's account.

16. A credit-based transaction processing device, operating at a payment terminal, the device comprising: The request submission module is configured to obtain the credit transaction service access instruction submitted by the payee for the application and submit the service access request to the server. The parameter submission module is configured to receive the credit transaction page returned by the server and submit the transaction parameters input by the payee based on the credit transaction page to the server. The identifier display module is configured to receive and display the transaction identifier for the credit transaction returned by the server. The payment terminal of the payer, which is conducting a credit transaction with the payee, scans the transaction identifier and submits a credit transaction request to the server for credit transaction detection. The result acquisition module is configured to acquire the credit transaction result returned by the server after determining the credit transaction based on the transaction parameters if the credit transaction detection passes. Once the credit transaction is confirmed, the outstanding bill for the payee is synchronized to the bill list within the application.

17. A credit-based transaction processing device, operating at a payment terminal, the device comprising: The request submission module is configured to obtain the credit transaction service access instruction submitted by the payer for the application and submit the service access request to the server. The identifier scanning module is configured to scan the transaction identifier displayed on the payment terminal for credit transactions and submit a credit transaction request to the server for credit transaction detection. The result acquisition module is configured to acquire the credit transaction result returned by the server after determining the credit transaction based on the transaction parameters submitted by the payee, provided that the credit transaction detection has passed. Once the credit transaction is confirmed, the payer's pending payment bill is synchronized to the bill list within the application.

18. A payment terminal, comprising: processor; And, a memory configured to store computer-executable instructions, which, when executed, cause the processor to: Obtain the credit transaction service access instruction submitted by the payee for the application, and submit the service access request to the server; Receive the credit transaction page returned by the server, and submit the transaction parameters entered by the payee based on the credit transaction page to the server; Receive and display the transaction identifier for the credit transaction returned by the server; The payment terminal of the payer, which is conducting a credit transaction with the payee, scans the transaction identifier and submits a credit transaction request to the server for credit transaction detection. Obtain the credit transaction result returned by the server after determining the credit transaction based on the transaction parameters if the credit transaction detection passes; Once the credit transaction is confirmed, the outstanding bill for the payee is synchronized to the bill list within the application.

19. A payment terminal, comprising: processor; And, a memory configured to store computer-executable instructions, which, when executed, cause the processor to: Obtain the credit transaction service access instruction submitted by the payer for the application, and submit the service access request to the server; Scan the transaction identifier displayed on the payment terminal to initiate a credit transaction, and submit a credit transaction request to the server for credit transaction detection; Obtain the credit transaction result returned by the server after confirming the credit transaction based on the transaction parameters submitted by the payee, provided that the credit transaction detection is passed; Once the credit transaction is confirmed, the payer's pending payment bill is synchronized to the bill list within the application.

20. A computer-readable storage medium for storing computer-executable instructions that, when executed, implement the steps of the method of claim 1 or claim 10.

Images