CN115456773A

CN115456773A - Payment control method, device, equipment and medium based on block chain

Info

Publication number: CN115456773A
Application number: CN202211038105.7A
Authority: CN
Inventors: 吴泽盛; 闫志鹏; 殷泽文; 程彦衡; 吴泳鹏
Original assignee: Shenzhen Futu Network Technology Co Ltd
Current assignee: Shenzhen Futu Network Technology Co Ltd
Priority date: 2022-08-26
Filing date: 2022-08-26
Publication date: 2022-12-09
Anticipated expiration: 2042-08-26
Also published as: CN115456773B; WO2024040819A1

Abstract

The embodiment of the application discloses a payment control method, a device, equipment and a medium based on a block chain. The method comprises the following steps: verifying a payment request for a security account initiated by a requester; if the verification is passed, performing fund deduction processing on the security account according to the payment amount, deducting the amount corresponding to the payment amount from the payment amount corresponding to the requester, and indicating the auxiliary payment platform to transfer the payment amount to the payee; and transferring funds corresponding to the payment amount to the auxiliary payment platform, and uploading data generated in the payment process to the block chain after the transaction result is verified through the intelligent contract. The steps of using funds in the security account by the user are simplified, the data throughput performance of the payment scene is improved, the payment instantaneity and the transaction efficiency are improved, and the security and the reliability of transaction payment are improved.

Description

Payment control method, device, equipment and medium based on block chain

Technical Field

The application relates to the technical field of internet, in particular to a payment control method, a payment control device, electronic equipment and a computer-readable storage medium.

Background

Securities are the collective name of multiple economic interest vouchers, and are written certificates for proving that the holders of securities have the right to obtain the corresponding interest according to the contents loaded on the securities sides. By their nature, different documents are classified into evidentiary documents, voucher documents, securities, and the like. Some securities are marketable, the presence of which has been an active financial, economic and investment source, and which typically includes stocks, bonds, funds, tickets, etc.

At present, when a user wants to use the funds on a security account, the funds on the security account must be transferred to a bank account through a bank-certificate transfer function, and then the funds on the bank account can be used for consumption.

Therefore, in the related art, the business process of using the funds on the security account is complicated, more identity verification and transaction verification are needed, the business throughput of the payment system is reduced, and the problem of lower transaction efficiency and safety of the security account is caused.

Content of application

In order to solve the technical problem, embodiments of the present application provide a payment control method, an apparatus, an electronic device, and a computer-readable storage medium, which can improve data throughput performance of a payment scenario and improve real-time performance and security of payment.

According to an aspect of an embodiment of the present application, there is provided a payment control method including: verifying a payment request for a security account initiated by a requester; the payment request comprises a payment amount and a payee; if the verification is passed, performing fund deduction processing on the security account according to the payment amount, deducting the amount corresponding to the payment amount from the payment amount corresponding to the requester, and indicating the auxiliary payment platform to transfer the payment amount to the payee; transferring funds corresponding to the payment amount to the auxiliary payment platform to generate a transaction result; and verifying the transaction result through the intelligent contract, and uploading data generated in the payment process to the block chain after the verification is passed.

According to an aspect of an embodiment of the present application, there is provided a payment control apparatus including: the payment verification module is configured to verify a payment request for the security account initiated by a requester; the payment request comprises a payment amount and a payee; the payment processing module is configured to execute fund deduction processing on the security account according to the payment amount if the verification is passed, deduct an amount corresponding to the payment amount from a payment amount corresponding to the requester, and instruct the auxiliary payment platform to transfer the payment amount to the payee; the transaction result generation module is configured to transfer funds corresponding to the payment amount to the auxiliary payment platform to generate a transaction result;

and the data uploading module is configured to verify the transaction result through the intelligent contract and upload data generated in the payment process into the block chain after the verification is passed.

According to an aspect of an embodiment of the present application, there is provided an electronic device including one or more processors; a storage device for storing one or more programs which, when executed by the electronic device, cause the electronic device to implement the payment control method as above.

According to an aspect of embodiments herein, there is provided a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements a payment control method as above.

According to an aspect of an embodiment of the present application, there is provided a computer program product comprising a computer request which, when executed by a processor, implements a payment control method as above.

In the technical scheme provided by the embodiment of the application, a payment request for a security account initiated by a requester is verified, if the verification is passed, fund deduction processing is performed on the security account according to the payment amount, the amount corresponding to the payment amount is deducted from the payment amount corresponding to the requester, an auxiliary payment platform is instructed to transfer the payment amount to a payee, the fund corresponding to the payment amount is transferred to the auxiliary payment platform, a transaction result is verified through an intelligent contract, and data generated in the payment process is uploaded to a block chain after the verification is passed. On one hand, the problem that the fund using efficiency is low due to the fact that the fund in the security account cannot be directly used and the bank-certificate transfer is low is solved, the step that the user uses the fund in the security account is simplified, the data throughput performance of a payment scene is improved, and the payment instantaneity and the transaction efficiency are improved; on the other hand, the payment and transaction process is verified through an intelligent contract technology in the block chain, and the generated data in the whole transaction process is linked up, so that the security and reliability of transaction payment are improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application. It is obvious that the drawings in the following description are only some embodiments of the application, and that for a person skilled in the art, other drawings can be derived from them without inventive effort. In the drawings:

FIG. 1 is a schematic diagram of an exemplary application environment in which aspects of embodiments of the present application may be applied;

FIG. 2 is a flow chart of a payment control method shown in an exemplary embodiment of the present application;

FIG. 3 is a block chain structure diagram shown in an exemplary embodiment of the present application;

FIG. 4 is a schematic illustration of payment verification for a payment request, shown in an exemplary embodiment of the present application;

FIG. 5 is a schematic diagram illustrating a verification process for a dynamic verification code in accordance with an exemplary embodiment of the present application;

FIG. 6 is a schematic diagram of an authentication interface shown in an exemplary embodiment of the present application;

FIG. 7 is a schematic view of a payment selection interface shown in an exemplary embodiment of the present application;

FIG. 8 is a flow chart of a payment control method shown in another exemplary embodiment of the present application;

FIG. 9 is a schematic diagram illustrating a binding selection interface in accordance with an illustrative embodiment of the present application;

fig. 10 is a schematic diagram illustrating binding of a virtual security payment card to a security account in accordance with an exemplary embodiment of the present application;

FIG. 11 is a schematic diagram of an interface for querying payment data of a virtual security payment card as shown in an exemplary embodiment of the present application;

FIG. 12 is a schematic diagram illustrating a freeze process performed on a virtual security payment card in accordance with an exemplary embodiment of the present application;

fig. 13 is a schematic view showing a process of adjusting a payment amount on a virtual security payment card according to an exemplary embodiment of the present application;

FIG. 14 is a schematic illustration of a unified modeling language for virtual security payment card management software shown in an exemplary embodiment of the present application;

FIG. 15 is a flow chart of a payment control method shown in another exemplary embodiment of the present application;

FIG. 16 is a block diagram of a payment control arrangement shown in an exemplary embodiment of the present application;

FIG. 17 is a block diagram of a computer system suitable for use to implement the electronic device of an embodiment of the present application.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments identical to the present application. Rather, they are merely examples of the same devices and methods of some aspects of the present application, as detailed in the appended claims.

The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. the functional entities may be implemented in the form of application programs or in one or more hardware modules or integrated circuits or in different networks and/or processor means and/or microcontroller means.

The flow charts shown in the drawings are merely illustrative and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.

In the present application, the term "plurality" means two or more. "and/or" describes the association relationship of the associated object, indicating that there may be three relationships, for example, a and/or B may indicate: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.

In the related art, when a user needs to use the funds in the security account, the available funds in the security account need to be transferred to a bank account by means of a bank account transfer, and then the funds in the bank account can be used for consumption. However, the bank-certificate transfer operation is not performed immediately after the bank-certificate transfer operation is performed due to poor timeliness of the bank-certificate transfer, so that the use requirement of the user on the funds cannot be met in time, and the user cannot well grasp the fund amount transferred from the security account to the bank account, so that the use efficiency of the funds is low.

Based on this, embodiments of the present application provide a payment control method, an apparatus, an electronic device, and a computer-readable storage medium to solve the above technical problems.

The following describes a payment control method provided in an embodiment of the present application, where fig. 1 is a schematic diagram of an implementation environment related to the payment control method in the present application. As shown in fig. 1, the implementation environment includes a terminal 110 and a server 120, and the terminal 110 and the server 120 may be directly or indirectly connected through wired or wireless communication, and the application is not limited herein.

The terminal 110 may be a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, a vehicle-mounted terminal, etc., but is not limited thereto. The terminal 110 may refer to one of a plurality of terminals, and the embodiment is only illustrated by the terminal 110. Those skilled in the art will appreciate that the number of terminals described above may be greater or fewer. For example, the number of the terminals may be only one, or several tens or hundreds, or more, and in this case, the environment in which the image processing method is implemented includes other terminals. The number of terminals and the type of the device are not limited in the embodiments of the present application.

The server 120 may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing basic cloud computing services such as cloud service, a cloud database, cloud computing, a cloud function, cloud storage, network service, cloud communication, middleware service, domain name service, security service, content Delivery Network (CDN), big data, and an artificial intelligence platform. The server 120 is used to provide background services for the applications running on the terminal 110.

Optionally, the wireless or wired networks described above use standard communication techniques and/or protocols. The Network is typically the Internet, but can be any Network including, but not limited to, a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a mobile, wired or wireless Network, a private Network, or any combination of virtual private networks. In some embodiments, data exchanged over a network is represented using techniques and/or formats including Hypertext Mark-up Language (HTML), extensible Markup Language (XML), and the like. All or some of the links may also be encrypted using conventional encryption techniques such as Secure Socket Layer (SSL), transport Layer Security (TLS), virtual Private Network (VPN), internet Protocol Security (IPsec). In other embodiments, custom and/or dedicated data communication techniques may also be used in place of, or in addition to, the data communication techniques described above.

It is understood that in the embodiments of the present application, related data such as account information, user data, and transaction data are referred to, when the embodiments of the present application are applied to specific products or technologies, user permission, consent, or authorization needs to be obtained, and the collection, use, and processing of the related data comply with relevant laws and regulations and standards of relevant countries and regions.

The payment control method based on the blockchain in the embodiment of the present application may be executed by the server 120, or may be executed by the terminal 110, or may be executed by both the server 120 and the terminal 110. The terminal 110 may execute the payment control method based on the blockchain according to the embodiment of the present application, and may also execute the payment control method based on the blockchain by a client installed thereon.

Referring to fig. 2, fig. 2 is a flowchart illustrating a payment control method based on a blockchain according to an embodiment of the present application. As shown in fig. 2, the payment control method based on the blockchain at least includes steps S210 to S240, which are described in detail as follows:

step S210, verifying a payment request aiming at the security account initiated by a requester; the payment request includes a payment amount and a payee.

It should be noted that the security account refers to an account book which is set up by a security registration and settlement institution for investors and is used for accurately recording the types, names, quantities, corresponding rights and interests and change situations of the securities held by the investors, so as to be used for trading of security products.

For example, the server may be provided with a virtual security payment card, and at least one security account may be bound to the virtual security payment card to establish a payment link between the security account and the virtual security payment card, that is, the requester may use funds in the security account by calling the virtual security payment card.

The virtual security payment card is used for realizing the payment function by performing entity payment card simulation on the terminal based on card data. Wherein, this virtual securities payment card can have corresponding entity card, also can not have corresponding entity card, and this virtual securities payment card can demonstrate at the terminal, for example demonstrates through card form, two-dimensional code form etc. this application does not limit this.

Illustratively, the terminal can be provided with payment software with a payment function, the payment software is bound with a virtual security payment card, and a payment request is generated by detecting payment operation executed on the payment software by a requester aiming at the virtual security payment card. For example, the terminal is further provided with shopping software, after a requester browses and selects products in the shopping software, the shopping software displays a plurality of payment modes to a user, the requester can select one of the plurality of payment modes to pay, each payment mode corresponds to one payment software, then the selected payment software initiates a payment request for a security account bound in the virtual security payment card, wherein the total price of the products corresponding to the products selected by the requester is used as a payment amount in the payment request, and a seller of the products selected by the requester is used as a payee.

In the embodiment of the application, the payment request initiated by the requestor is verified, for example, whether the payment order information carried in the payment request is correct or not is verified, whether account information corresponding to the requestor and the security account of the initiated payment request is consistent or not is verified, and the like, which is not limited in the application.

And step S220, if the verification is passed, performing fund deduction processing on the security account according to the payment amount, deducting the amount corresponding to the payment amount from the payment amount corresponding to the requester, and indicating the auxiliary payment platform to transfer the payment amount to the payee.

The auxiliary payment platform is a platform capable of directly transferring funds, the auxiliary payment platform can be a bank account, a third-party payment platform and the like, the third-party payment platform can be payment software installed in a terminal, and the application is not limited herein. It should be understood that the amount of funds available in the auxiliary payment platform in the embodiment of the present application is by default larger than the payment amount in the payment request.

It can be understood that the server stores a payment amount corresponding to each requester, and the payment amount is used for restricting an upper limit of an amount of money that the requester can use within a preset time period and recording a fund use condition of the requester within the preset time period. For example, if the payment amount of requester A is 5000 RMB/month, then requester A can use 5000 RMB in one month at most.

For example, a payment limit may be set for the virtual security payment card of the requester, that is, payment made by each security account included in the virtual security payment card is associated with the payment limit of the virtual security payment card; or a payment limit is set for each security account contained in the virtual security payment card, namely, the payment carried out by each security account is related to the payment limit corresponding to each security account; or a total payment amount is set for the virtual security payment card, and a sub payment amount is set for each security account included in the virtual security payment card, that is, on the premise that the amount of funds paid by each security account in a preset time period does not exceed the sub payment amount, the sum of the amounts of funds paid by each security account in the preset time period does not exceed the total payment amount. The payment amount can be flexibly set according to the actual application condition, and the payment amount is not limited by the application.

After the payment request is verified, the server deducts funds corresponding to the payment amount from the security account into a total fund account preset by the server, and then sends a payment instruction to the auxiliary payment platform, so that the auxiliary payment platform transfers the payment amount to the payee, the payee can receive the payment amount in time, the payment completion efficiency is improved, and the amount corresponding to the payment amount is deducted from the payment amount corresponding to the requester, so that the fund use condition of the requester is recorded.

Step S230, transferring the fund corresponding to the payment amount to the auxiliary payment platform to generate a transaction result.

Because the payment limit records the fund use condition of the requester in the preset time period, the fund transfer amount of the auxiliary payment platform can be obtained by inquiring the change of the payment limit of the requester in the preset time period, and then the server transfers the fund corresponding to the fund transfer amount to the auxiliary payment platform.

The fund transfer processing can be carried out to the auxiliary payment platform at intervals of a preset time period according to the change of the payment amount, so that the interaction times of the server and the auxiliary payment platform are reduced, and the computing resources are saved; or, once the payment task corresponding to one payment request is completed, the fund transfer processing is performed on the auxiliary payment platform, so that the auxiliary payment platform can receive the payment amount of the payment after the payment is made, and the real-time property of fund circulation is ensured, which is not limited in the application.

In some embodiments, transferring funds corresponding to the payment amount to the secondary payment platform includes: acquiring a line change value of a payment line corresponding to the auxiliary payment platform in a preset time period; and transferring funds corresponding to the amount change value to the auxiliary payment platform.

For example, the server may perform reconciliation with the auxiliary payment platform once every 24 hours, and the reconciliation process may be: the server detects the amount change value of the payment amount corresponding to the requester in 24 hours, then receives the total amount of the payment amount transferred to all the payee sides by the requester in 24 hours, which is sent by the auxiliary payment platform, and then judges whether the amount change value of the payment amount is consistent with the total amount of the payment amount or not, if so, funds corresponding to the amount change value are transferred to the auxiliary payment platform.

In some embodiments, the blockchain-based payment control method may be applied to a node of a blockchain network, where the node of the blockchain network may be any node accessing the blockchain network, and the node may be any form of computing device, such as a server, a terminal, and the like. The intelligent contract is then employed in the blockchain network to constrain the funds transfer process between the server and the secondary payment platform.

It should be noted that smart contracts are computer protocols intended to propagate, validate or execute contracts in an informational manner, with the purpose of providing a secure method over traditional contracts and reducing other transaction costs associated with contracts, which allows for trusted transactions to be conducted without third parties, which transactions are traceable and irreversible.

For example, a node of the blockchain network may receive a payment request for a security account submitted by a terminal and then perform a fund deduction process on the security account to transfer funds in the security account into a total funds account in the node of the blockchain network. And then, calling an intelligent contract to determine funds corresponding to the payment amount of the payment request in the total fund account, modifying the state of the funds into a locked state, and indicating the auxiliary payment platform to transfer the payment amount of corresponding amount to the payee, so as to ensure that the payee can receive the payment amount in time and improve the efficiency of completing the payment. The locking of the fund corresponding to the payment amount in the total fund account means that the fund cannot be operated by other nodes except the node executing the intelligent contract.

And after the auxiliary payment platform is detected to finish payment, receiving a transaction result fed back by the auxiliary payment platform, verifying the transaction result, and if the transaction result is payment success, calling an intelligent contract to transfer funds corresponding to the payment amount in the total fund account to the auxiliary payment platform.

And S240, verifying the transaction result through the intelligent contract, and uploading data generated in the payment process to the block chain after the verification is passed.

Because the intelligent contract in the block chain has the characteristics of automatic performance, transparent execution rule and logic, and public result and incapability of being tampered, after the auxiliary payment platform implements the payment task, the intelligent contract verifies the transaction result, the accuracy and fairness of the verification result are ensured, and the complexity of executing the payment task in the security account is simplified. And uploading data generated in the payment process into the blockchain after the verification is passed, wherein the data generated in the payment process includes but is not limited to: a payment request for a security account and a verification of the payment request; and the transaction data generated by the fund deduction process, such as a line corresponding to the payment amount, a payment mode and the like.

The block chain is a chain data structure formed by combining data blocks in a sequential connection mode according to a time sequence, and a distributed account book which can not be tampered and forged of data is guaranteed in a cryptographic mode. Multiple independent distributed nodes (i.e., nodes of the blockchain network) maintain the same records. The blockchain technology realizes decentralization and becomes a foundation for credible digital asset storage, transfer and transaction.

Taking the block chain structure diagram shown in fig. 3 as an example, whenever new data needs to be written into the block chain, the data is collected into one block and added to the end of the existing block chain, and the newly added block of each node is ensured to be identical through a consensus algorithm. A plurality of transaction records are recorded in each block, and the transaction records also comprise the hash value of the previous block, and all blocks store the value of the previous block in this way and are connected in sequence to form a block chain. The hash value of the previous block is stored in the block head of the next block in the block chain, and when the transaction data in the current block changes, the hash value of the block is changed, so that the transaction data uploaded to the block chain network is difficult to tamper, the payment transaction is carried out on the block chain, the public transparency of the payment process is realized, and the payment reliability is improved.

In some embodiments, the funds available in the security account to which the payment request corresponds may be a specific amount in the balance of funds; or the amount may be a specific amount obtained by fund exchange of virtual resources in the security account, for example, there are funds and stocks purchased in the security account, and the amount of funds corresponding to virtual resources which can be currently traded in the security account may be used as funds which can be transferred. The virtual resources which can be traded currently in the security account refer to the virtual resources which can be sold currently. The virtual resources are also used as funds for transaction, so that the fund sources are enriched, and the use experience of the user is improved.

According to the method and the device, after the payment request is verified to be passed, fund deduction processing can be executed on the security account, the auxiliary payment platform is instructed to carry out payment padding on the payment amount, so that the corresponding payment amount is transferred to a payee, and then the payment service can be guaranteed to be completed in time, then the auxiliary payment platform is transferred to the specific amount padded before the auxiliary payment platform, so that the payment process is completed, the problems that the fund in the security account cannot be directly used and the fund use efficiency is low due to the fact that the bank-certificate transfer accounts are carried out are solved, the steps that a user uses the fund in the security account are simplified, the data throughput performance of a payment scene is improved, and the payment instantaneity is improved.

Referring to fig. 4, fig. 4 is a schematic diagram for verifying a payment request for a security account initiated by a requester according to an embodiment.

As shown in fig. 4, a requester sends a request for using a virtual security payment card to a server through a terminal, and the server sends a request for obtaining a transaction password of the virtual security payment card to the terminal according to the request for using the virtual security payment card, so that the terminal displays a transaction password input box to the requester according to the request for obtaining the transaction password. And then the server acquires the transaction password input by the request direction transaction password input box fed back by the terminal, and verifies whether the transaction password fed back by the terminal is correct or not according to the transaction password stored in association with the virtual security payment card in advance. And if the transaction password is correct, sending a dynamic verification code acquisition request of the virtual security payment card to the terminal, and if the dynamic verification code is correct, verifying the identity of the payment request as a pass, and calling the virtual security payment card.

The verification process of the dynamic verification code may be as shown in fig. 5:

step S510, the requester triggers a dynamic verification code confirmation button, and the dynamic verification code confirmation button is displayed to the requester by the terminal according to the dynamic verification code acquisition request;

step S520, the terminal sends a dynamic verification code acquisition instruction to the server and enables the terminal to display a dynamic verification code input box;

step S530, the server transmits a dynamic verification code acquisition instruction to a Short Message Service (SMS) platform;

step S540, the SMS platform sends the dynamic verification code to a preset terminal according to the dynamic verification code obtaining instruction, where the preset terminal is a terminal where a Subscriber Identity Module (SIM) corresponding to the virtual security payment card is located, and the preset terminal and the aforementioned terminal sending the dynamic verification code obtaining instruction may be the same terminal or different terminals;

step S550, the terminal sends the dynamic verification code input by the dynamic verification code input box of the request direction to the server;

step S560, the server forwards the received dynamic verification code to the SMS platform;

step S570, the SMS platform checks whether the received dynamic verification code is consistent with the dynamic verification code sent to the preset terminal;

in step S580, the SMS platform feeds back a verification result to the server, and if the dynamic verification code received by the SMS platform is verified to be consistent with the dynamic verification code sent to the preset terminal, the SMS platform feeds back a verification result to the server, and if the dynamic verification code received by the SMS platform is verified to be inconsistent with the dynamic verification code sent to the preset terminal, the SMS platform feeds back a verification result to the server.

The identity of the requester corresponding to the payment request is verified by combining the transaction password and the dynamic verification code, so that the accuracy of identity verification is improved through multiple verification modes, and the payment safety is ensured.

In some embodiments, as shown in fig. 6, when selecting to use the virtual security payment card for payment, the terminal accesses an authentication interface corresponding to the virtual security payment card, and the authentication interface may be provided with a plurality of authentication mode selection buttons, for example, the authentication mode selection buttons include "face authentication", "fingerprint authentication", and "voice authentication". Then, acquiring corresponding identity authentication information according to the authentication mode selected by the requester, and if the authentication mode selected by the requester is 'face authentication', acquiring the face information of the requester through an image acquisition device on the terminal; when the verification mode selected by the requester is fingerprint verification, fingerprint information of the requester is acquired through a fingerprint acquisition device on the terminal; when the verification mode selected by the requester is 'voice verification', the voice information of the requester is acquired through the voice acquiring device on the terminal. By setting a plurality of authentication modes and performing identity authentication according to the authentication mode selected by the requester, the diversity and selectivity of the identity authentication performed by the requester are improved, and the use experience of the requester is further improved.

And then, the terminal generates a payment request according to the obtained identity authentication information and the order information associated with the payment request, and sends the payment request to the server. The server stores the identity information of each requesting party, after receiving the payment request uploaded by the terminal, the server performs identity verification on the identity verification information in the payment request according to the stored identity information, and performs order verification on the order information in the payment request. The order verification of the order information in the payment request can be used for detecting whether the order information is correct, for example, detecting whether signature information of the order information is correct, so as to effectively distinguish forged order information and ensure the security of payment.

If the identity authentication and the order authentication are both passed, the authentication result of the payment authentication of the payment request is passed; and if any one of the identity authentication and the order authentication is not passed, the authentication result of the payment authentication of the payment request is not passed.

The security account corresponding to the payment request may be a security account directly specified by the requesting party, or may be obtained by screening a plurality of security accounts corresponding to the requesting party by the server following the payment request.

For example, if the payment verification is passed, the available amount of each security account included in the virtual security payment card is obtained. Then, the security account with the available credit larger than or equal to the payment amount is used as the security account to be paid. It can be understood that, one virtual security payment card may be bound with a plurality of security accounts, and the security account with the available amount greater than or equal to the payment amount is used as the security account to be paid, so as to ensure that the subsequent payment operation can be correctly performed on the security account to be paid.

The available amount refers to the amount of funds the requester can use.

Alternatively, the available amount of the security account may be based on the total amount of funds in the security account. For example, the total amount of funds of the security account may be a specific amount in the fund balance of the security account, or may be a sum of the specific amount in the fund balance and a specific amount obtained by performing fund exchange on virtual resources in the security account, which is not limited in this application.

Illustratively, the fund remaining available amount of each security account is obtained according to the payment amount, and then the minimum value of the fund remaining available amount of each security account and the fund total amount of each security account is used as the corresponding available amount of each security account. For example, the security accounts include a security account a and a security account B, the total fund amount of the security account a is 100 yuan, the total fund amount of the security account B is 700 yuan, the payment amount set for the virtual security payment card is 1000 yuan per day, and the virtual security payment card has paid 600 yuan according to the historical payment record of the virtual security payment card in the current day, so that the fund remaining available amount of each security account is 400 yuan, the available amount of the security account a is 100 yuan, and the available amount of the security account B is 400 yuan.

Optionally, when there are a plurality of security accounts with the available amount greater than or equal to the payment amount, the priorities of the security accounts may be obtained, and the security account with the highest priority may be used as the security account to be paid. The priority may be preset for each security account, or may be dynamically set according to information such as usage frequency and reliability of each security account, which is not limited in the present application.

Optionally, as shown in fig. 7, when there are a plurality of security accounts with an available credit greater than or equal to the payment amount, a payment selection instruction of the security account to be paid may be sent to the terminal, and the terminal displays a payment selection interface of the security account to be paid to the requester according to the selection instruction of the security account to be paid, for example, the security account displayed through the payment selection interface includes a security account a and a security account B, and each security account corresponds to a different selection button. The terminal receives the selection operation executed by the requester on the payment selection interface of the security account to be paid, and feeds back the security account to be paid to the server according to the selection operation.

The embodiment of the application ensures the safety of the payment process by carrying out payment verification on the payment request, and screens the security account in advance according to the available amount of the security account contained in the virtual security payment card to ensure that the obtained security account to be paid meets the payment requirement, so as to avoid the payment failure caused by insufficient available amount in the security account and avoid program waste.

In some embodiments, when there is no security account with an available amount greater than or equal to the payment amount among the security accounts included in the virtual security payment card, a plurality of available amounts of each security account included in the virtual security payment card may be added, and if the added available amount is greater than or equal to the payment amount, the added security accounts are all used as the security accounts to be paid, so as to improve the success rate of payment and improve the use experience of the requester.

Referring to fig. 8, fig. 8 is a flowchart illustrating a block chain based payment control method according to another exemplary embodiment. As shown in fig. 8, in an exemplary embodiment, before verifying the payment request for the security account initiated by the requester at step S210, the following steps may be further included:

step S810, determining a security account that can be used for payment according to a binding request for the security account initiated by a requester.

A security account that may be used for payment means that there are funds in the security account that may make payments.

One virtual security payment card can be bound with a plurality of security accounts, and one security account can also be bound with a plurality of virtual security payment cards, which is not limited in the application.

It should be noted that corresponding user information exists in both the virtual security payment card and the security account, and the user information between the virtual security payment card and the security account may be the same or different. The user information between the virtual security payment card and the security account needs to be the same in consideration of the security of the virtual security payment card and the security account and in order to facilitate subsequent management; considering the flexibility of binding between the virtual security payment card and the security account, the user information between the virtual security payment card and the security account can be different; or selecting a corresponding binding strategy according to the corresponding credibility of the virtual security payment card and the security account, so that the binding method between the virtual security payment card and the security account is more suitable for the actual situation. The binding method between the virtual security payment card and the security account can be flexibly selected according to the actual situation, and the method is not limited in the application.

In some embodiments, determining a security account that may be used for payment in accordance with a binding request for the security account initiated by a requestor includes: inquiring the security account state of the security account corresponding to the requester; calculating the credibility of the security account with the security account state being the normal state according to the historical trading information of the security account with the security account state being the normal state; and taking the security account with the credibility meeting the preset condition as the security account which can be used for payment.

Alternatively, the security account corresponding to the requestor may be a security account with which the requestor has an association. For example, the server obtains identity information corresponding to a virtual security payment card operated by a requester, including: user name, identification image, etc. The user name refers to the name of the user, and the identity identification can be the identity card number of the user, the passport number of the user, or other identification uniquely identifying the identity of the user. The identity image refers to the avatar information corresponding to the identity identifier, for example, if the identity identifier is an identity card number, the identity information is avatar information on the identity card, and if the identity identifier is a passport number, the corresponding avatar information is avatar information on the passport. The virtual security payment card may have its own virtual card identifier, which may be composed of the identity information of the card holding user, so as to associate the identity information of the card holding user with the virtual card, for example, querying all security accounts through the identity information of the card holding user, and regarding the security account matched with the identity information of the card holding user as the security account corresponding to the requesting party.

Optionally, the security account corresponding to the requesting party may be security accounts in all security software in the terminal corresponding to the requesting party. For example, the stock account login records of all stock software in the terminal corresponding to the requester are inquired, and all stock accounts related in the login records are used as the stock accounts corresponding to the virtual stock payment card.

The security account status of the security account may include a normal status, a frozen status, and the like. The security account with the security account status of normal status refers to an account which can be normally used, such as the fund balance in the security account can be normally used, and security transactions can be normally performed; the security account with the frozen security account status refers to an account that can be used abnormally, such as no account login or no security transaction can be performed normally.

The reliability may be calculated according to the historical transaction information of the requester, for example, whether the transaction information marked as a violation exists in the historical transaction information is queried, the reliability of the requester is lower if the number of the transaction information marked as a violation is larger, and the reliability of the requester is higher if the number of the transaction information marked as a violation is smaller.

The credibility of the security account with the security account status being in the normal status is calculated according to the historical trading information of the security account with the security account status being in the normal status, for example, whether the trading information marked as violation exists in the historical trading information is inquired, if the quantity of the trading information marked as violation is larger, the credibility of the security account is lower, and if the quantity of the trading information marked as violation is smaller, the credibility of the security account is higher. And then, taking the security account with the reliability meeting the preset condition as the security account which can be used for payment, thereby improving the binding efficiency of the subsequent security accounts.

Specifically, when the credibility of the security account is determined, historical trading information of the security account is obtained, illegal trading information in the historical trading information is extracted, the illegal times Num _ vio and the corresponding total amount of illegal orders Tra _ vio are obtained through counting, meanwhile, the normal trading times Num _ nor and the corresponding total amount of normal trades Tra _ nor in the historical trading information are counted, and a trading difference parameter Par _ var is calculated as follows:

then, based on the trading balance parameter Par _ var, the number of violations Num _ vio and the social activity parameter Par _ act of the account of the security account, the reliability is calculated as follows:

where α represents a confidence factor. In the mode, the reliability can be obtained by calculating the illegal transaction information, the illegal transaction information and the like in the security account, so that the security and the reputation of the security account can be measured by the reliability, corresponding processing can be carried out based on the reliability of the security account, and the security and the reliability of the transaction are improved.

The security accounts with the credibility meeting the preset condition can be security accounts with the credibility larger than or equal to a credibility threshold; or the security accounts may be sorted according to the credibility of the security accounts and then sequenced by a preset number of security accounts.

After the reliability is obtained through calculation, in this embodiment, tag processing may be performed on the transaction data and the data generated in the payment process based on the reliability, and uplink may be performed as a parameter for evaluating the credibility of the information, so as to improve reliability and objectivity of uplink data.

Step S820, sending the security account available for payment to the requester, so as to receive the security account selection information fed back by the requester for the security account available for payment, and obtain the security account to be bound.

For example, referring to fig. 9, fig. 9 is a schematic diagram of an interface for selecting a security account that can be used for payment, as shown in fig. 9, a server sends the security account that can be used for payment to a terminal, and the terminal displays a binding selection interface of the security account to a requester according to the received security account that can be used for payment, for example, the security accounts displayed through the binding selection interface include a security account a, a security account B, and a security account C, and each security account corresponds to a different selection button. And then the requester executes a security account selection operation for the binding selection interface, and after the terminal detects that the requester triggers a 'confirm' button, the security account to be bound is fed back to the server according to the security account A and the security account B currently selected by the requester, and then the server obtains that the security accounts to be bound are the security account A and the security account B, so that the requester can bind a plurality of security accounts through one security account binding operation, the security account binding process is simplified, and the user experience is improved.

In some embodiments, sending the security account available for payment to the requester to receive security account selection information fed back by the requester for the security account available for payment, and obtaining the security account to be bound includes: sending a security account verification request to the requestor in response to the security account selection information; receiving security account verification information fed back by a requester according to the security account verification request; carrying out security account verification on the selected security account according to the security account verification information; and if the security account passes the verification, the selected security account is used as the security account to be bound.

It is understood that, in order to secure each security account, a security account verification step is provided for each security account to treat the selected security accounts, which pass the security account verification, as the security accounts to be bound.

For example, after the requesting party triggers the selection control of the security account, a security account verification interface of the security account is displayed to perform corresponding security account verification on the security account, and only after the security account verification passes, the security account is selected successfully, otherwise, the security account selection fails.

Step S830, a payment link with the security account to be bound is established.

For example, a payment link between the virtual security payment card and the security account to be bound may be established, and the payment link between the virtual security payment card and the security account to be bound means that the bound security account may be invoked through the virtual security payment card. By binding the security account to the virtual security payment card, the virtual security payment card can be directly called to use funds in the security account, and the use efficiency of the funds in the security account is improved.

The process of establishing a payment link for a security account is described with reference to fig. 10 as an example, and as shown in fig. 10, the server determines whether there is a security account available for payment according to a security account binding request. If there are security accounts available for payment, it is detected whether there are security accounts of a specified currency. And if the security account with the specified currency exists, receiving security account selection information which can be used for payment and is fed back by the requester for the security account with the specified currency, and obtaining the security account to be bound. And then, sending a transaction password verification request aiming at the security account to be bound to the terminal so as to verify the transaction password fed back by the requester through the terminal. If the transaction password is successfully verified, establishing a payment link between the virtual security payment card and the security account to be bound; and if the transaction password is not successfully verified, prompting the requesting party to perform verification again through the terminal. And then, establishing a payment link between the virtual security payment card and the security account to be bound, and completing the security account binding step.

In some embodiments, establishing a payment link with the security account to be bound further comprises: acquiring user information of a requester; obtaining the credibility of the requester according to the user information; generating a payment amount corresponding to the requester according to the credibility of the requester; and establishing a payment link with the security account to be bound according to the payment amount corresponding to the requester.

For example, user information corresponding to a virtual security payment card operated by a requester can be acquired, so that the reliability of the requester is obtained according to the acquired user information, a payment amount corresponding to the requester is generated according to the reliability of the requester, and a payment link between the virtual security payment card and a security account to be bound is established. It can be understood that the higher the credibility of the requester is, the higher the payment amount corresponding to the requester is; the lower the credibility of the requester, the lower the payment amount corresponding to the requester.

Optionally, the number of fund usage times of the requester in a preset time period, the authentication level in the payment process, and the like of the requester can be determined according to the credibility of the requester. For example, if the credibility of the requesting user is higher, the number of fund usage times in a preset time period is more, and the authentication level in the payment process is lower; if the credibility of the requesting user is lower, the fund use times in the preset time period are less, and the authentication grade in the payment process is higher. The authentication level in the payment process refers to the level of an authentication mode adopted in the payment process, and if the authentication level in the payment process is judged to be low according to the credibility of the requesting user, the corresponding authentication mode can be transaction password authentication; when the authentication level in the payment process is judged to be a middle level according to the credibility of the requesting user, the corresponding authentication mode can be face identification authentication; when the authentication level in the payment process is judged to be high according to the credibility of the requesting user, the corresponding authentication mode can be face identification authentication and dynamic authentication code authentication. The corresponding parameters of the payment link are automatically generated through the credibility of the requesting user, so that the established payment link between the requesting user and the security account is more suitable for the actual situation of the requesting party, and the use experience of the user is improved on the premise of improving the payment safety.

In some embodiments, the process of opening a virtual security payment card is described: responding to a virtual security payment card opening request initiated by a requester, and acquiring user information of a requesting user corresponding to the virtual security payment card opening request; carrying out user identity authentication on the user information, and generating payment configuration parameters according to the credit degree corresponding to the user information; and if the user identity authentication is passed, generating a virtual security payment card according to the user information.

The terminal can display a user information filling interface, and collect user information of a requesting user according to the user information filling interface; the virtual security payment card management software may be a virtual security payment card management software, and the user information of the requesting party may be user information obtained according to an account identifier currently logged in by the virtual security payment card management software.

After the user information of the requesting party is obtained, user identity authentication is performed on the user information, for example, at least one of face information, fingerprint information, voice information, verification code information and the like of the current user is obtained through a terminal, so as to check whether the obtained information is consistent with the user information, and if so, the user identity authentication is passed. And after the user identity authentication is passed, generating a virtual security payment card according to the user information.

In some embodiments, the method further comprises: receiving a payment data query request aiming at the security account, which is initiated by a requester and carries the data type of the payment data to be queried; matching a corresponding data display strategy according to the data type, and inquiring a payment data record corresponding to the data type; and sending the data display strategy and the payment data record to the requester so that the terminal corresponding to the requester displays the payment data record according to the data display strategy.

Different display strategies are set for the payment data to be inquired of different data types to distinguish the payment data to be inquired, so that the payment data to be inquired can be displayed more clearly on the terminal side, and reading is facilitated.

The payment data query request may be a request for a designated security account, or may be a request for all security accounts in the virtual security payment card, which is not limited in the present application.

The explanation will be given by taking the example that the payment data inquiry request is a request for all the security accounts in the virtual security payment card.

As shown in fig. 11, the data type of the payment data to be queried includes bill particulars and cashback particulars, and when the data type of the payment data to be queried carried in the payment data query request is bill particulars, the matched data display policy is a first data display policy; and when the data type of the payment data to be inquired carried in the payment data inquiry request is the cashback detail, the matched data display strategy is the second data display strategy.

Wherein the bill particulars are used for displaying all capital expenditure records and capital return records associated with the virtual security payment card, and the cashback particulars are used for displaying all cashback records generated by consumption associated with the virtual security payment card.

Optionally, the bill particulars or the cashback particulars may be filtered according to the date and the type, for example, the type of the bill particulars includes consumption and refund, and the type of the cashback particulars includes account already arrived, expired, pending and returned. Further, when the terminal detects that the detail is clicked, the terminal can jump to a detail interface corresponding to the clicked detail to display the detail content of the detail.

Because the display interface of the bill particulars and the display interface of the cash back particulars are different, different subclasses can be set for the display interface of the bill particulars and the display interface of the cash back particulars to package codes corresponding to the difference of the interfaces. Then, a list of particulars, a request for a detail filter item, a title of the list, a title of the details, and the like are generated from the enumerated values of the bill particulars and the counter particulars, respectively. Data consistency is achieved by defining an ordered set by enumerating values to predefine identifiers that list all values.

In some embodiments, the freezing or thawing process and the credit adjustment process may also be performed on the virtual security payment card.

Referring to fig. 12, fig. 12 is a schematic diagram illustrating a process of freezing a virtual security payment card, as shown in fig. 12, a freezing request for the virtual security payment card initiated by a requester is received, whether the virtual security payment card is in a frozen state is detected according to the freezing request, and if the virtual security payment card is not in the frozen state, an account is frozen; and sending a transaction password verification request to the terminal to obtain a transaction password input by the requesting party to the terminal, further verifying whether the transaction password is correct, detecting whether the freezing state of the account is successful after the verification is successful, popping up a freezing success prompt if the verification is successful, and returning to the reprocessing if the verification is unsuccessful. It can be understood that the process of performing the unfreezing process on the virtual security payment card is similar to the process of performing the freezing process on the virtual security payment card, and is not repeated here.

Referring to fig. 13, fig. 13 is a schematic diagram illustrating a process of adjusting a payment amount of a virtual security payment card, as shown in fig. 13, receiving a request for adjusting the payment amount of the virtual security payment card initiated by a requesting party, detecting whether the virtual security payment card is in a frozen state according to the request for adjusting the payment amount, if not, obtaining a modified amount input by the requesting party to a terminal, further checking whether the modified amount exceeds a modification threshold, if not, prompting whether to store the modified amount, and if receiving an instruction of canceling the storage of the requesting party, prompting the requesting party whether to re-input the modified amount; if receiving the instruction of the confirmation storage of the requesting party, sending a transaction password verification request to the terminal to obtain the transaction password input by the requesting party to the terminal, further verifying whether the transaction password is correct, and if so, modifying the payment amount according to the value of the modified amount.

In some embodiments, referring to fig. 14, fig. 14 is a schematic diagram of a Unified Modeling Language (UML) of virtual security payment card management software provided to a terminal, and the following description of the classes is made in conjunction with fig. 14:

the payment card data center is used for maintaining a payment card model and related information, maintaining related cache operation and externally providing a read-write entrance of local virtual security payment card information.

The "payment card model" is used to provide a parameter structure of a virtual security payment card.

The "home page" mainly provides account information, functional entries and the like of the virtual security payment card and the virtual security payment card management software.

The "account information view" is the main view of the home page, providing access to the cashback list, "normal view" of the virtual security payment cards that complete the existing security account bindings and are not frozen, and "exception view" of the virtual security payment cards that do not complete the account security account bindings or have been frozen.

The virtual security payment card in the normal view needs to carry out dynamic verification code verification through dynamic verification code types, and card number, security code, validity period and other information of the virtual security payment card are obtained through a card information popup window.

The abnormal view provides access to a security account binding class and a virtual security payment card management class respectively so as to perform operations of security account binding, virtual security payment card unfreezing, payment amount adjustment and the like.

The 'functional area view' is used for providing access to a 'bill list' and a 'card management class', and the 'detail information' is used for inquiring the detail information of a single bill or cashback in the 'bill list' and the 'cashback list'.

The transaction detail base class is abstracted aiming at the bill list and the cash back list to package all the same interface display logics, and different interface logics are stripped, so that the code quantity of interface development is reduced, and subsequent maintenance and management of relevant codes displayed on the interface are facilitated.

In some embodiments, please refer to fig. 15, fig. 15 is a flowchart illustrating a block chain based payment control method according to an embodiment of the present application, and referring to fig. 15, the block chain based payment control method at least includes steps S1510 to S1580, which are described in detail as follows:

step S1510, the terminal sends a payment request for the security account to the third party payment platform, where the payment request includes the payment amount, the payee, and the identifier of the virtual security payment card.

Step S1520, the third party payment platform forwards the payment request to the auxiliary payment platform.

Step S1530, the auxiliary payment platform sends a verification request to the server according to the payment request;

step S1540, the server verifies the payment request according to the verification request, if the verification result of the server for verifying the payment request is passed, capital deduction processing is executed on the security account according to the payment amount, the amount corresponding to the payment amount is deducted from the payment amount corresponding to the requester, and a payment instruction is sent to the auxiliary payment platform;

step S1550, the auxiliary payment platform transfers payment amount to the payee according to the payment instruction, and feeds back a transaction result to the third-party payment platform and the server;

step S1560, the server transfers the funds corresponding to the payment amount to the auxiliary payment platform.

Fig. 16 is a block diagram illustrating a payment control apparatus according to an embodiment of the present application, and as shown in fig. 16, the apparatus includes:

a payment verification module 1610 configured to verify a payment request for a security account initiated by a requestor; the payment request comprises payment amount and a payee;

the payment processing module 1620 is configured to execute fund deduction processing on the security account according to the payment amount if the verification is passed, deduct an amount corresponding to the payment amount from a payment amount corresponding to the requester, and instruct the auxiliary payment platform to transfer the payment amount to the payee;

the fund transfer module 1630 is configured to transfer funds corresponding to the payment amount to the auxiliary payment platform to generate a transaction result;

the data uploading module 1640 is configured to verify the transaction result through the smart contract, and upload data generated in the payment process into the blockchain after the verification is passed.

In one embodiment of the present application, the funds-transfer module 1630 may include:

the limit change value determining unit is configured to acquire a limit change value of a payment limit corresponding to the auxiliary payment platform in a preset time period;

and the transfer unit is configured to transfer the funds corresponding to the amount change value to the auxiliary payment platform.

In an embodiment of the present application, the payment control apparatus further includes a security account determination unit, a security account selection unit, and a payment link establishment unit, and before determining a security account to be paid included in the virtual security payment card according to a payment request initiated by a requester for the virtual security payment card, the apparatus further includes:

the security account determining unit is configured to determine a security account which can be used for payment according to a binding request for the security account initiated by a requesting party;

the security account selection unit is configured to send a security account which can be used for payment to a requesting party so as to receive security account selection information fed back by the requesting party aiming at the security account which can be used for payment, and obtain a security account to be bound;

and the payment link establishing unit is configured to establish a payment link with the security account to be bound.

In one embodiment of the present application, the security account determination unit may include:

the security account state query unit is configured to query the security account state of the security account corresponding to the requester;

the security account credibility calculating unit is configured to calculate the credibility of the security account with the security account state being the normal state according to the historical trading information of the security account with the security account state being the normal state;

and the payable determining unit is configured to take the security account with the credibility meeting the preset condition as the security account which can be used for payment.

In one embodiment of the present application, the security account selection unit may include:

a security account verification request unit configured to send a security account verification request to a requester in response to security account selection information;

the security account verification information receiving unit is configured to receive security account verification information fed back by a requesting party according to a security account verification request;

the verification unit is configured to verify the selected security accounts according to the security account verification information;

and the to-be-bound confirming unit is configured to take the selected security account as the to-be-bound security account if the security account passes the verification.

In one embodiment of the present application, the payment link establishment unit includes:

a user information acquisition unit configured to acquire user information of the requester;

the requester credibility determining unit is configured to obtain the credibility of the requester according to the user information;

the payment amount confirmation unit is configured to generate a payment amount corresponding to the requester according to the credibility of the requester;

and the payment link establishing unit is configured to establish a payment link with the security account to be bound according to the payment amount corresponding to the requester.

In one embodiment of the present application, the payment control apparatus may further include:

the payment data query request receiving unit is configured to receive a payment data query request aiming at the security account, which is initiated by a requester, wherein the payment data query request carries the data type of the payment data to be queried;

the data display strategy and payment data record determining unit is configured to match the corresponding data display strategy according to the data type and inquire the payment data record corresponding to the data type;

and the query feedback unit is configured to send the data display strategy and the payment data record to the requester so that the terminal corresponding to the requester displays the payment data record according to the data display strategy.

In the exemplary payment control device, funds required for payment in a security account to be paid are locked through an intelligent contract, a payee is subjected to fund transfer through an auxiliary payment platform to ensure that a payment service can be completed in time, and then after the intelligent contract determines that the auxiliary payment platform completes payment, the funds locked in the security account to be paid are subjected to transfer operation to transfer the funds corresponding to payment amount in the security account to be paid to the auxiliary payment platform, so that the problems that the funds in the security account cannot be directly used and the use efficiency of the funds is low in the transfer of the bank notes are solved, the steps of using the funds in the security account by a user are simplified, the use efficiency of the funds in the security account is improved, and the use safety of the funds in the security account is improved.

It should be noted that the block chain based payment control apparatus provided in the foregoing embodiment and the block chain based payment control method provided in the foregoing embodiment belong to the same concept, and specific ways of performing operations by each module and unit have been described in detail in the method embodiment, and are not described herein again. In practical applications, the above function distribution may be completed by different function modules according to needs, that is, the internal structure of the device is divided into different function modules to complete all or part of the above described functions, which is not limited herein.

FIG. 17 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present application.

It should be noted that the computer system 1700 of the electronic device shown in fig. 17 is only an example, and should not bring any limitation to the functions and the scope of the application of the embodiments.

As shown in fig. 17, electronic device 1700 is in the form of a general purpose computing device. Components of electronic device 1700 may include, but are not limited to: the at least one processing unit 1710, the at least one memory unit 1720, a bus 1730 connecting various system components including the memory unit 1720 and the processing unit 1710, and a display unit 1740.

Where the storage unit stores program code, the program code may be executed by the processing unit 1710 to cause the processing unit 1710 to perform steps according to various exemplary embodiments of the present disclosure described in the "exemplary methods" section above in this specification.

The storage unit 1720 may include readable media in the form of volatile memory units, such as a random access memory unit (RAM) 1721 and/or a cache memory unit 1722, and may further include a read only memory unit (ROM) 1723.

Storage unit 1720 may also include a program/utility 1724 having a set (at least one) of program modules 1725, such program modules 1725 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.

Bus 1730 may be any of several types of bus structures including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

The electronic device 1700 can also communicate with one or more external devices 1770 (e.g., keyboard, pointing device, bluetooth device, etc.), with one or more devices that enable a user to interact with the electronic device 1700, and/or with any devices (e.g., router, modem, etc.) that enable the electronic device 1700 to communicate with one or more other computing devices. Such communication can occur via an input/output (I/O) interface 1750. Also, the electronic device 1700 can communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network such as the internet) via the network adapter 1760. As shown, the network adapter 1760 communicates with the other modules of the electronic device 1700 over the bus 1730. It should be appreciated that although not shown, other hardware and/or application modules may be used in conjunction with electronic device 1700, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.

In particular, according to embodiments of the present application, the processes described above with reference to the flow diagrams may be implemented as computer applications. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising a computer program for performing the method illustrated by the flow chart. The computer programs, when executed by the processing unit 1710, perform the various functions defined in the system of the present application.

It should be noted that the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium or any combination of the two. The computer readable storage medium may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a Read-Only Memory (ROM), an Erasable Programmable Read-Only Memory (EPROM), a flash Memory, an optical fiber, a portable Compact Disc Read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with a requesting execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with a computer program embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with a request execution system, apparatus, or device. The computer program embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. Each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units described in the embodiments of the present application may be implemented by an application program or by hardware, and the described units may also be disposed in a processor. Wherein the names of the elements do not in some way constitute a limitation on the elements themselves.

Another aspect of the present application also provides a computer-readable storage medium on which a computer program is stored, which computer program, when executed by a processor, implements the above blockchain-based payment control method. The computer-readable storage medium may be included in the electronic device described in the above embodiment, or may exist alone without being assembled into the electronic device.

Another aspect of the application also provides a computer program product or computer program comprising computer requests stored in a computer readable storage medium. The processor of the computer device reads the computer request from the computer-readable storage medium, and the processor executes the computer request, so that the computer device executes the block chain-based payment control method provided in the above embodiments.

The above description is only a preferred exemplary embodiment of the present application, and is not intended to limit the embodiments of the present application, and those skilled in the art can easily make various changes and modifications according to the main concept and spirit of the present application, so that the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A payment control method based on a block chain is characterized by comprising the following steps:

verifying a payment request for a security account initiated by a requester; the payment request comprises a payment amount and a payee;

if the verification is passed, performing fund deduction processing on the security account according to the payment amount, deducting the amount corresponding to the payment amount from the payment amount corresponding to the requester, and indicating the auxiliary payment platform to transfer the payment amount to the payee;

transferring funds corresponding to the payment amount to the auxiliary payment platform to generate a transaction result;

and verifying the transaction result through the intelligent contract, and uploading data generated in the payment process to the block chain after the verification is passed.

2. The method of claim 1, wherein transferring funds corresponding to the payment amount to the secondary payment platform comprises:

acquiring the amount change value of the payment amount corresponding to the auxiliary payment platform within a preset time period;

and transferring funds corresponding to the amount change value to the auxiliary payment platform.

3. The method of claim 1, further comprising, prior to the verifying the requestor-initiated payment request for the security account:

determining a security account which can be used for payment according to a binding request aiming at the security account initiated by a requester;

sending the security account available for payment to the requester so as to receive security account selection information fed back by the requester for the security account available for payment, and obtaining a security account to be bound;

establishing a payment link with the to-be-bound security account.

4. The method according to claim 3, wherein determining the security account that can be used for payment based on a binding request for the security account initiated by a requestor comprises:

inquiring the security account state of the security account corresponding to the request party;

calculating the credibility of the security account with the security account state being the normal state according to the historical trading information of the security account with the security account state being the normal state;

and taking the security account with the credibility meeting the preset conditions as the security account which can be used for payment.

5. The method according to claim 3, wherein the sending the security account available for payment to the requester for receiving security account selection information fed back by the requester for the security account available for payment, resulting in a security account to be bound, comprises:

sending a security account verification request to the requestor in response to the security account selection information;

receiving security account verification information fed back by the requester according to the security account verification request;

performing security account verification on the selected security account according to the security account verification information;

and if the security account passes the verification, taking the selected security account as the security account to be bound.

6. The method according to claim 3, wherein the establishing a payment link with the security account to be bound comprises:

acquiring user information of the requester;

obtaining the credibility of the requester according to the user information;

generating a payment amount corresponding to the requester according to the credibility of the requester;

and establishing a payment link with the to-be-bound security account according to the payment amount corresponding to the requester.

7. The method of any of claims 1 to 6, further comprising:

receiving a payment data query request aiming at the security account, which is initiated by the requester, wherein the payment data query request carries the data type of the payment data to be queried;

matching a corresponding data display strategy according to the data type, and inquiring a payment data record corresponding to the data type;

and sending the data display strategy and the payment data record to the requester so that a terminal corresponding to the requester displays the payment data record according to the data display strategy.

8. A payment control apparatus, the apparatus comprising:

the payment verification module is configured to verify a payment request for the security account initiated by a requester; the payment request comprises a payment amount and a payee;

the payment processing module is configured to execute fund deduction processing on the security account according to the payment amount if the verification is passed, deduct an amount corresponding to the payment amount from a payment amount corresponding to the requester, and instruct the auxiliary payment platform to transfer the payment amount to the payee;

the transaction result generation module is configured to transfer funds corresponding to the payment amount to the auxiliary payment platform to generate a transaction result;

9. An electronic device, comprising:

one or more processors;

storage means for storing one or more programs that, when executed by the electronic device, cause the electronic device to implement the payment control method of any one of claims 1 to 7.

10. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out a payment control method as claimed in any one of claims 1 to 7.