WO2020073491A1 - 基于区块链的供应链支付方法、收款方法、装置、设备及介质 - Google Patents

基于区块链的供应链支付方法、收款方法、装置、设备及介质 Download PDF

Info

Publication number
WO2020073491A1
WO2020073491A1 PCT/CN2018/122730 CN2018122730W WO2020073491A1 WO 2020073491 A1 WO2020073491 A1 WO 2020073491A1 CN 2018122730 W CN2018122730 W CN 2018122730W WO 2020073491 A1 WO2020073491 A1 WO 2020073491A1
Authority
WO
WIPO (PCT)
Prior art keywords
supplier
payment
information
amount
electronic
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2018/122730
Other languages
English (en)
French (fr)
Inventor
庄海龑
王秀骏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
OneConnect Smart Technology Co Ltd
Original Assignee
OneConnect Smart Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by OneConnect Smart Technology Co Ltd filed Critical OneConnect Smart Technology Co Ltd
Publication of WO2020073491A1 publication Critical patent/WO2020073491A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/018—Certifying business or products

Definitions

  • This application relates to the field of financial technology, and in particular to a blockchain-based supply chain payment method, payment collection method, device, equipment, and medium.
  • each first-tier supplier can use electronic payment vouchers Obtain the payment from the core company, but before receiving the payment, the first-level supplier needs to pay the payment in advance to its subordinate supplier, that is, the second-level supplier, and the second-tier supplier also needs to pay its own subordinate supplier, that is Pay in advance to third-tier suppliers, that is, the current electronic payment vouchers issued through core companies cannot be circulated among suppliers at all levels, which makes electronic payments between financial supply chains particularly complicated and inefficient. The security is not high. At the same time, when some suppliers are short of funds, the supply chain will break, which is not conducive to the stable development of the supply chain.
  • Embodiments of the present application provide a blockchain-based supply chain payment method, collection method, device, computer equipment, and storage medium to solve the current electronic payment between financial supply chains with high complexity, low efficiency, and insecure security High question.
  • a supply chain payment method based on blockchain including:
  • the superior supplier information, the inferior supplier information and the actual payment amount M included in the payment request are obtained;
  • the electronic payment voucher of the superior supplier is split to obtain the first electronic payment with a disposable amount of NM Voucher and second electronic payment voucher with disposable amount M;
  • the payment is confirmed to be successful, and the first electronic payment voucher is used as the electronic payment of the superordinate supplier after the transaction certificate.
  • a supply chain payment method based on blockchain including:
  • the identity authentication information of the subordinate supplier is sent to the superior supplier to enable the superior
  • the supplier authenticates the subordinate supplier according to the identity authentication information
  • a supply chain payment device based on blockchain including:
  • the payment request obtaining module is used to obtain the information of the upper-level supplier, the information of the lower-level supplier and the actual payment amount M contained in the payment request if the payment request sent by the upper-level supplier is received;
  • Authenticity verification module which is used to verify the authenticity of the information of the superior supplier and the information of the lower supplier to obtain the verification result
  • a control amount acquisition module configured to obtain a controllable amount N in the electronic payment voucher of the upper level supplier if the verification result is that the upper level supplier information and the lower level supplier information are both true;
  • the payment voucher splitting module is used to split the electronic payment voucher of the superior supplier when the disposable amount N in the electronic payment voucher of the superior supplier exceeds the actual payment amount M to obtain disposable The first electronic payment voucher with an amount of NM and the second electronic payment voucher with a disposable amount of M;
  • a payment voucher transfer module used to transfer the second electronic payment voucher to the subordinate supplier by means of blockchain
  • the payment detection module is used to detect whether the subordinate supplier has confirmed that the payment is successful, and perform identity authentication on the subordinate supplier;
  • the payment confirmation module is used to confirm that the payment is successful if the lower-level supplier has confirmed that the payment is successful and the lower-level supplier has passed the identity authentication, and use the first electronic payment voucher as the post-transaction The electronic payment certificate of the superior supplier.
  • a supply chain payment device based on blockchain including:
  • the control amount judgment module is used to determine whether the controllable amount in the second electronic payment certificate is equal to the actual payment amount if it is detected that the subordinate supplier successfully receives the second electronic payment certificate sent by the upper supplier;
  • the authentication information sending module is used to confirm that the payment is successful if the disposable amount in the second electronic payment voucher is equal to the actual payment amount, and send the identity verification of the subordinate supplier to the superior supplier Information, so that the superior supplier authenticates the subordinate supplier according to the identity authentication information;
  • the payment voucher merging module is used to merge the second payment voucher with the electronic payment voucher of the lower-level supplier after receiving the identity authentication success information sent by the upper-level supplier, and merge the combined electronic payment The voucher serves as the electronic payment voucher after the transaction of the subordinate supplier.
  • a computer device includes a memory, a processor, and computer-readable instructions stored in the memory and executable on the processor, and the processor implements the computer-readable instructions to implement the foregoing blockchain-based The steps of the supply chain payment method or the steps of the aforementioned blockchain-based supply chain payment method.
  • One or more non-volatile readable storage media the non-volatile readable storage media storing computer-readable instructions, the computer-readable instructions are executed by one or more processors to implement the above block-based The steps of the supply chain payment method of the chain or the steps of the above-mentioned blockchain-based supply chain payment method.
  • FIG. 1 is a schematic diagram of an application environment of a supply chain payment method and a payment collection method based on a blockchain provided by an embodiment of the present application;
  • FIG. 2 is an implementation flowchart of a supply chain payment method based on a blockchain provided by an embodiment of the present application
  • FIG. 3 is a flowchart of an implementation of step S12 in a blockchain-based supply chain payment method provided by an embodiment of the present application;
  • step S15 is an implementation flowchart of step S15 in the blockchain-based supply chain payment method provided by an embodiment of the present application
  • FIG. 5 is a flowchart of implementing currency conversion in a blockchain-based supply chain payment method provided by an embodiment of the present application
  • FIG. 6 is a flowchart of an implementation of a supply chain payment method based on a blockchain provided by an embodiment of the present application
  • FIG. 7 is a schematic diagram of a blockchain-based supply chain payment device provided by an embodiment of the present application.
  • FIG. 8 is a schematic diagram of a blockchain-based supply chain payment collection device provided by an embodiment of the present application.
  • FIG. 9 is a schematic diagram of a computer device provided by an embodiment of the present application.
  • FIG. 1 illustrates an application environment of a blockchain-based supply chain payment method and a payment method provided by an embodiment of the present application.
  • the blockchain-based supply chain payment method and collection method are used in the scenario of electronic payment by suppliers at all levels in the financial supply chain.
  • the electronic payment scenario includes a server, an upper-level supplier client, and a lower-level supplier client, where the upper-level supplier sends a payment request to the server through the upper-level supplier client, and passes the upper-level supplier when identity verification is required
  • the client provides verification information to the server, and the subordinate supplier receives the electronic payment voucher sent by the server through the subordinate supplier client, and provides authentication information through the subordinate supplier client when identity verification is required.
  • the upper-level supplier client and the lower-level supplier client can be, but are not limited to, smart devices such as portable computers, personal computers, mobile phones, and tablet computers.
  • the server can be implemented by an independent server or a server cluster composed of multiple servers.
  • FIG. 2 illustrates a blockchain-based supply chain payment method provided by an embodiment of the present application. The method is applied to the server in FIG. 1 as an example for description. The details are as follows:
  • the enterprise pays the goods to the first-tier supplier
  • the first-tier supplier pays the goods to the second-tier supplier.
  • the upper-tier supplier is the payer of the goods
  • the lower-tier supplier The merchant is the payee of the payment.
  • the server obtains the upper-level supplier information, the lower-level supplier information and the actual payment amount M contained in the payment request for subsequent follow-up Verify the authenticity of the transaction.
  • the electronic payment voucher refers to a certain format, a certain amount, at the time of seeing the ticket or on the designated due date, at the designated place, the invoice or the other person as the payer, to the payee or hold Electronic written vouchers for unconditional payments.
  • the Supply Chain (Supply Chain Finance, SCF) refers to banks providing financing and other settlement and wealth management services to customers, and at the same time providing these customers' suppliers with the convenience of timely receipt of loans, or providing prepayment agents to their distributors.
  • Payment and inventory financing services that is, a financing model in which banks link core enterprises and upstream and downstream enterprises to provide flexible use of financial products and services. It is a professional field of commercial bank credit business, but also enterprises, especially small and medium-sized enterprises. A financing channel.
  • network transmission protocols include, but are not limited to: Internet Control Message Protocol (Internet Control Message Protocol, ICMP), Address Resolution Protocol (ARP Address Resolution Protocol, ARP) and File Transfer Protocol (File Transfer Protocol, FTP), etc.
  • S12 Verify the authenticity of the information of the superior supplier and the information of the lower supplier, and obtain the verification result.
  • the verification result is that the information of the upper-level supplier and the lower-level supplier are both true, that is, when the payment is confirmed to be legal, the disposable amount N contained in the electronic payment certificate of the upper-level supplier is obtained.
  • the disposable amount N refers to the maximum amount of transactions included in the electronic payment voucher is N, for example, the disposable amount of an electronic payment voucher is 20,000 yuan, which means that when using the electronic payment voucher for electronic payment, available The upper limit of the amount paid is 20,000 yuan.
  • the electronic payment voucher of the upper-level supplier can be obtained on the terminal corresponding to the upper-level supplier of the blockchain, or it can be obtained from a preset database, or it can be stored according to the actual situation.
  • the setting of the path is determined, and no specific restrictions are made here.
  • the electronic payment voucher of the superior supplier is obtained from a preset database, after each confirmation of successful payment, the electronic payment voucher of the superior supplier in the preset database is updated.
  • the electronic payment voucher of the superior supplier is split to obtain the first electronic payment voucher and The second electronic payment voucher with the control amount of M, and the split time is generated on the split first electronic payment voucher and the second payment voucher.
  • the electronic payment voucher may be copied to obtain two identical electronic payment vouchers, and the two electronic payment vouchers are disposable The amount is adjusted so that the sum of the disposable amounts of the two electronic payment vouchers is equal to the disposable amount N of the electronic payment voucher of the superior supplier.
  • the disposable amount of NM is obtained.
  • splitting of the electronic payment voucher of the superior supplier into two electronic payment vouchers mentioned in this embodiment is only a preferred way to split the electronic payment vouchers in this application. In the process, it can also be split into more than two electronic payment vouchers, which can be determined according to the actual situation, without specific restrictions here.
  • the amount N in the electronic payment certificate of the superior supplier is equal to the actual payment amount M, there is no need to split the electronic payment certificate of the superior supplier, that is, the electronic payment certificate of the superior supplier is directly used as the second electronic payment certificate.
  • the payment request is rejected , And send prompt information to the superior supplier client.
  • the second electronic payment voucher is transferred to the lower-level supplier through the blockchain, so that the electronic payment voucher that cannot be directly circulated can be paid from the upper-level supplier to the lower-level supplier, which improves the electronic payment of the financial supply chain.
  • the use of blockchain in this way also improves the security of electronic payments.
  • the blockchain is a chained data structure that combines data blocks in a chronological order in a sequential manner, and is a tamper-proof and unforgeable distributed ledger guaranteed by cryptography.
  • the lower-level supplier After transferring the second electronic payment voucher to the lower-level supplier, it is necessary to detect whether the lower-level supplier confirms that the payment is successful, if the lower-level supplier does not confirm, or the lower-level supplier confirms that the payment fails, or detects within a preset time range If the subordinate supplier does not confirm whether the payment is successful, it indicates that there is a security risk and the actual payment cannot be made.
  • detecting whether the lower-level supplier confirms that the payment is successful may specifically be detected based on whether receipt information indicating that the payment is successful is sent from the lower-level supplier, and the lower-level supplier is judged if the receipt information is received Confirm the payment is successful; in the case of payment through the blockchain, you can also check whether the subordinate supplier confirms the successful payment by querying the blockchain for the confirmation information uploaded by the subordinate supplier for the payment.
  • the superior supplier and the subordinate supplier can also conduct voice or video communication, and the subordinate supplier can inform the superior supplier of the successful payment through voice or video, and the superior supplier in the superior
  • the confirmation operation is performed in the supplier client, and the higher-level supplier client can determine whether the lower-level supplier confirms the successful payment according to whether the above confirmation operation is detected, and feeds back the confirmation result to the server.
  • the subordinate supplier After the subordinate supplier confirms that the payment has been successfully tested, the subordinate supplier needs to be authenticated to further ensure that the subordinate supplier is the party expected to pay, and to ensure the legality and correctness of the subordinate supplier actually paid.
  • the identity authentication of the subordinate supplier may include, but is not limited to: the authentication of the legality and correctness of the identity of the subordinate supplier, when specifically implemented After confirming the successful payment, the subordinate supplier can send the identity authentication information of the subordinate supplier to the superior supplier. The superior supplier authenticates the legality and correctness of the subordinate supplier according to the identity authentication information. After passing, the actual payment will be made.
  • performing identity authentication on the subordinate supplier may include: performing identity authentication on the subordinate supplier through voice communication interaction, live video interaction, or multimedia information interaction.
  • the upper-level supplier and the lower-level supplier conduct voice or video communication, and the upper-level supplier can realize the identity authentication of the lower-level supplier based on voice communication interaction or live video interaction; in addition, the lower-level supplier can also record multimedia information such as short video And send to the superior supplier, the superior supplier authenticates the subordinate supplier according to the multimedia information. It is easy to understand that, when conducting voice or video communication, the identity authentication of the subordinate supplier to the superior supplier and the identity authentication of the superior supplier to the subordinate supplier can be realized at the same time.
  • the upper-level supplier and the lower-level supplier can also customize the identity authentication method for the lower-level supplier.
  • the upper-level supplier can specify any of the above-mentioned identity authentication methods.
  • the lower-level supplier performs identity authentication; correspondingly, the lower-level supplier can also specify any of the above identity authentication methods to authenticate the upper-level supplier.
  • the lower-level supplier when it is detected that the lower-level supplier has confirmed the successful payment and the lower-level supplier has passed the identity authentication, it can confirm the successful payment.
  • the first electronic payment certificate is used as the electronic payment certificate of the higher-level supplier after the transaction .
  • the superior supplier information, the subordinate supplier information and the actual payment amount M included in the payment request are obtained, and the superior supplier information and the subordinate supplier information After verifying the authenticity and confirming that the verification result is that the information of the superior supplier and the information of the lower supplier are true, obtain the amount N in the electronic payment certificate of the superior supplier, and then the amount N in the electronic payment certificate and the actual payment amount M For comparison, when the amount N in the electronic payment voucher of the superior supplier exceeds the actual payment amount M, the electronic payment voucher of the superior supplier is split to obtain the first electronic payment voucher with an amount of NM and the Second electronic payment voucher, and then use the blockchain method to transfer the second electronic payment voucher to the lower-level supplier, and start the detection of whether the lower-level supplier has confirmed the successful payment and the identity verification of the lower-level supplier.
  • the first electronic payment voucher is used as the electronic payment voucher of the superior supplier after the transaction, so that the electronic payment voucher issued by the core enterprise can be freely traded between suppliers at all levels, optimizing the electronic payment between the financial supply chain. Convenience, improve the efficiency of electronic payment in the financial supply chain.
  • the use of blockchain technology for electronic payment makes electronic payment traceable and tamper-resistant, and also improves the security of electronic payment.
  • this core The form of circulation of electronic payment vouchers issued by enterprises with strong credit also avoids the abnormality or breakage of the financial supply chain caused by the previous poor capital turnover of the supplier, and ensures the stability of the financial supply chain.
  • the following uses a specific embodiment to verify the authenticity of the upper-level supplier information and the lower-level supplier information mentioned in step S12, and obtains the verification result. Detailed description.
  • FIG. 3 shows a specific implementation process of step S12 provided by an embodiment of the present application, and details are as follows:
  • S121 query whether there is a target enterprise account from a preset database, and if there is a target enterprise account, query whether the authorized user account is associated with the target enterprise account, where the preset database pre-stores the target enterprise account and the authorized user account , The association information between the target enterprise account and the authorized user account, and the authorization period corresponding to the authorized user account and the corresponding authorized user information.
  • both the upper-level supplier information and the lower-level supplier information include the target enterprise account, authorized user account, and login time.
  • the target enterprise account, authorized user account, and target enterprise are pre-stored in the database preset on the server side
  • the authorized user account and login time are queried with the information in the preset database to see if there is information consistent with the information in the database to determine the authenticity of the information in the payment request.
  • the target enterprise account is an enterprise account in which the enterprise account registration is completed in advance.
  • the authorized user account is the user account corresponding to the authorized authorized user.
  • the login time is the current system time when the verification is triggered by the higher-level supplier client.
  • the current time of the system can be obtained by using the built-in time acquisition function of the enterprise client (such as the currentTimeMillis method in the System class in JAVA), and Determine the current time of the system as the login time.
  • the server pre-associates and stores at least one authorized user account corresponding to the target enterprise account, and the authorization period and authorized user information corresponding to each authorized user account, so as to perform verification based on the authorized user information.
  • the authorized user information includes but is not limited to mobile phone numbers and registered biometrics.
  • the authorization period corresponding to the authorized user account is obtained from a preset database, and it is determined whether the login time is within the authorization period.
  • the authorization period may be the cut-off time when the authorized user account has validity.
  • the authorization period of an authorized user account is "24:00:00 on October 12, 2018", which means that the authorized user account is in 2018. It is valid until 24:00:00 on October 12.
  • the login time in the identity verification request if the login time is within the authorization period, it means that the authorized user account is within the validity period and can be used for login, transaction or Other contracting behaviors; otherwise, if the login time is not within the authorization period, it means that the authorized user account is not within the validity period, and no login, transaction or other contracting behaviors are allowed to ensure the transaction security of the enterprise corresponding to the target enterprise account.
  • the server will query the database based on the authorized user account only when the login time is within the authorized period, to obtain the authorized user information corresponding to the authorized user account, so as to perform identity verification based on the authorized user information to ensure that the target enterprise account corresponds to the
  • the transaction security of the enterprise can avoid the useless overhead caused by other verification actions that the login time is not within the authorized period, and improve the processing efficiency.
  • S124 Send the identity verification code to the mobile terminal corresponding to the mobile number, and receive the login verification code returned by the mobile terminal. If the identity verification code is consistent with the login verification code, it is confirmed that the verification code verification is successful.
  • the identity verification code is a verification code randomly generated by the platform server using a dynamic code generation tool for identity verification.
  • the identity verification code is stored in the server in association with the authorized user account, and a validity period is set, for example, 60 seconds.
  • the login verification code is the verification code used for identity verification uploaded through the enterprise client during the user login phase. After obtaining the login verification code, the server uses a string matching algorithm to compare whether the login verification code and the identity verification code are consistent. If the two are consistent, the verification code verification is successful; otherwise, the verification code verification is unsuccessful.
  • S125 Obtain the biometrics to be verified uploaded by the on-board supplier and the lower-level supplier through the client, and calculate the similarity value between the biometrics to be verified and the registered biometrics. If the similarity value is not less than the preset threshold, confirm biometric verification success.
  • the upper-level supplier client and the lower-level supplier client start the built-in or external recording device to collect the sound to be verified
  • a similarity algorithm is used to compare the registered voiceprint feature and the voiceprint feature to be verified to obtain the similarity. If the similarity reaches a preset threshold, if yes, the biometric verification is successful, otherwise, the biometric verification is unsuccessful.
  • the similarity algorithm is used to compare the registered facial features and the facial features to be verified to obtain the similarity. If the similarity reaches a preset threshold, if yes, the biometric verification is successful, otherwise, the biometric verification is unsuccessful.
  • the information to be read can also be sent to the upper supplier client and the lower supplier client, or security issues , So that the user can read the information to be read, or answer security questions to collect the voice data to be verified, and in addition to extracting the voiceprint features to be verified, it is also necessary to identify whether the text data to be verified recognized by the voice data to be verified.
  • the information to be read matches to avoid illegal users using pre-recorded recording data for voice verification.
  • the registered biometric feature in the authorized user information stored on the server side is a registered facial feature
  • the biometric verification process in addition to using the similarity algorithm to compare the registered facial feature and the facial feature to be verified, to obtain the similarity and Compared with the preset threshold, to determine whether the biometric verification is successful, you also need to send action instructions to the upper supplier client and the lower supplier client, such as blinking and shaking your head, so that the shooting device collects short videos based on the action instruction
  • action instructions to the upper supplier client and the lower supplier client, such as blinking and shaking your head
  • step S124 and step S125 do not necessarily have an order of execution, which may be a parallel execution relationship, which is not limited here.
  • verifying the target enterprise account, the authorized user account, and the association information between the target enterprise account and the authorized user account contained in the upper supplier information and the lower supplier information from the preset database After confirming that the obtained target enterprise account, authorized user account, and associated information are consistent with the information stored in the database, verify code verification and biometric verification are performed. If both verification code verification and biometric verification are successful, the verification result is confirmed to be a superior supplier. The information and the information of the lower-level suppliers are true. Through verification from multiple angles, the authenticity of the information of the upper-level suppliers and the information of the lower-level suppliers is ensured, and the security of electronic payment is improved.
  • FIG. 4 shows a specific implementation process of step S15 provided by an embodiment of the present application. Details are as follows:
  • electronic account book information is generated, and the electronic account book information includes a payer, a payee, and a transaction amount, the payer is a superior supplier, and the payee is a lower supplier, transaction The amount is the second payment voucher.
  • S152 Use the preset private key to electronically sign the electronic account book information to obtain the signature information, and encapsulate the electronic account book information and the signature information into a block body.
  • the electronic account information is electronically signed by a preset private key to obtain signature information, and then the electronic account information and signature information are encapsulated into a block body.
  • the electronic signature can be implemented by using the SM2 algorithm.
  • the preset private key is generated by the upper-level supplier and the lower-level supplier through the point-to-point communication agreement of the blockchain, so that the signature information containing the private key can be decrypted by the lower-level supplier through the corresponding public key.
  • S153 Encapsulate the summary information of the previous block of the blockchain into a block header, make the block body and block header form a new block, and link the new block with the existing block in the blockchain Into a new blockchain.
  • the summary information of the previous block on the blockchain is encapsulated into a block header, and the block body obtained in step S152 and the block body are combined into a new block, and the new block is used Link with the original block of the blockchain to get a new blockchain.
  • the summary information of the previous block includes but is not limited to the address and transaction timestamp of the previous block, and the summary information of the previous block can be specifically implemented through the SM3 algorithm.
  • S154 Send the new block to each terminal of the new blockchain, so that when the terminal corresponding to the lower-level supplier receives the new block, the preset public key is used to block the new block.
  • the signature information in the body is verified, and after the verification is successful, the electronic account book information in the block body is obtained and updated.
  • the new block is broadcast, so that when the terminal corresponding to the subordinate supplier receives the new block, the preset public key is used to verify the signature information in the block body of the new block , And after successful verification, obtain the electronic account book information in the block body for verification during the payment process.
  • update the electronic account book information may include the transaction time and transaction amount 3. Records of transaction information such as suppliers participating in the transaction.
  • electronic account book information is generated, and then the electronic account book information is electronically signed using a preset private key to obtain signature information, and the electronic account book information and the signature information are encapsulated
  • encapsulate the summary information of the previous block of the blockchain into a block header make the block body and block header form a new block, and combine the new block with the existing block in the blockchain Link to form a new blockchain, and then send the new block to each terminal of the new blockchain, so that the terminal corresponding to the subordinate supplier adopts the preset public when receiving the new block
  • the key verifies the signature information in the block body of the new block, and after the verification is successful, obtains and updates the electronic account book information in the block body.
  • the second electronic payment voucher is sent To lower-level suppliers, electronic payment vouchers that could not be directly circulated can be used for electronic payment quickly, which improves the efficiency of electronic payment.
  • electronic payment vouchers that could not be directly circulated can be used for electronic payment quickly, which improves the efficiency of electronic payment.
  • immutability, safety and reliability of the blockchain Features ensure the security of electronic payments made by electronic payment vouchers.
  • the blockchain-based supply chain payment method further includes:
  • the exchange rate between the currency type of the actual payment amount and the default currency of the electronic payment voucher can be obtained by visiting the website to query the latest conversion rate, or the conversion rate can be obtained from a preset database, or Choose other methods according to the actual situation, no specific restrictions here.
  • the actual payment amount is 2000 USD
  • the currency type of the payment amount is USD
  • the default currency type of the electronic payment voucher is RMB.
  • the conversion rate between USD and RMB needs to be obtained.
  • the conversion rate obtained from the preset database to convert US dollars to Renminbi is 6.9265.
  • a default currency gold coin with the same value as the actual payment amount is generated, and the default currency amount is used as the converted actual payment amount M.
  • step S181 based on the actual payment amount of 2000 USD and the conversion rate of 6.9274 for the conversion of USD to RMB, the equivalent of the actual payment amount of 2000 USD is 13853 yuan, and 13853 yuan is the actual payment amount M.
  • FIG. 6 illustrates a blockchain-based supply chain payment method provided by an embodiment of the present application. The method is applied to the server in FIG. 1 as an example for description. The details are as follows:
  • the lower-level supplier after receiving the second electronic payment voucher sent by the upper-level supplier, the lower-level supplier will send a message to the server to successfully receive the second electronic payment voucher sent by the upper-level supplier, and obtain the second electronic payment from the message The disposable amount in the voucher, and determine whether the disposable amount in the second electronic payment voucher is equal to the actual payment amount.
  • the subordinate supplier needs to send a confirmation message to the server after receiving the second electronic payment voucher.
  • the server determines whether the disposable amount contained in the second electronic payment certificate received by the lower-level supplier is legal.
  • the disposable amount in the second electronic payment voucher is equal to the actual payment amount, it is determined that the received second electronic payment voucher is true and reliable and has not been tampered with.
  • the identity of the subordinate supplier is sent to the superior supplier Authentication information, so that the higher-level supplier performs identity authentication on the lower-level supplier according to the identity authentication information.
  • the specific authentication process refer to the description of step S60. To avoid repetition, no further description is provided here.
  • the transaction After receiving the identity authentication success message sent by the superior supplier, the transaction can be confirmed as successful. At this time, the electronic payment voucher of the lower supplier is combined with the second payment voucher, and the combined electronic payment voucher is used as the subordinate supply. The electronic payment voucher after the merchant transaction completes the payment process.
  • the disposable amount in the second electronic payment voucher is equal to the actual payment amount.
  • the second electronic payment voucher When the disposable amount in is equal to the actual payment amount, confirm the successful collection and send the lower supplier's identity authentication information to the higher supplier, so that the higher supplier will authenticate the lower supplier according to the identity authentication information.
  • the second payment voucher is merged with the electronic payment certificate of the lower supplier, and the combined electronic payment certificate is used as the electronic payment certificate after the transaction of the lower supplier, so that the payment is received
  • the payment amount and the payee are true and legal, which improves the security of the electronic payment.
  • FIG. 7 shows a functional block diagram of a blockchain-based supply chain payment device corresponding to the blockchain-based supply chain payment method of the above embodiment.
  • the blockchain-based supply chain payment device includes a payment request acquisition module 11, an authenticity verification module 12, a control amount acquisition module 13, a payment voucher splitting module 14, a payment voucher transfer module 15, and payment detection Module 16 and payment confirmation module 17.
  • the detailed description of each functional module is as follows:
  • the payment request obtaining module 11 is used to obtain the information of the upper-level supplier, the information of the lower-level supplier and the actual payment amount M contained in the payment request if the payment request sent by the upper-level supplier is received;
  • Authenticity verification module 12 is used to verify the authenticity of the information of the superior supplier and the information of the lower supplier to obtain the verification result;
  • the control amount acquisition module 13 is used to obtain the controllable amount N in the electronic payment certificate of the upper level supplier if the verification result is that the upper level supplier information and the lower level supplier information are both true;
  • the payment voucher splitting module 14 is used to split the electronic payment voucher of the superior supplier when the disposable amount N in the electronic payment voucher of the superior supplier exceeds the actual payment amount M to obtain the first An electronic payment voucher and a second electronic payment voucher with a disposable amount of M;
  • the payment voucher transfer module 15 is used to transfer the second electronic payment voucher to the subordinate supplier by means of blockchain;
  • the payment detection module 16 is used to detect whether the lower-level supplier has confirmed the successful payment and to authenticate the lower-level supplier;
  • the payment confirmation module 17 is used to confirm that the payment is successful if the lower-level supplier has confirmed that the payment is successful and the lower-level supplier has passed the identity authentication, and use the first electronic payment certificate as the electronic payment certificate of the higher-level supplier after the transaction .
  • the authenticity verification module 12 includes:
  • a relevance query unit is used to query whether a target business account exists from a preset database, and if a target business account exists, query whether an authorized user account is associated with the target business account, wherein the preset database pre-stores the target business Account information, authorized user account, the associated information between the target enterprise account and the authorized user account, and the authorization period corresponding to the authorized user account and the corresponding authorized user information;
  • the authorization period obtaining unit is used to obtain the authorization period corresponding to the authorized user account from the preset database if the authorized user account is associated with the target enterprise account;
  • the authorized user information query unit is used to query the authorized user information corresponding to the authorized user account if the login time is within the authorized period, where the authorized user information includes the mobile phone number and registered biometrics;
  • the verification code verification unit is used to send an identity verification code to the mobile terminal corresponding to the mobile number and receive the login verification code returned by the mobile terminal. If the identity verification code is consistent with the login verification code, the verification code verification is successful;
  • the biometric verification unit is used to obtain the biometrics to be verified uploaded by the on-board supplier and the subordinate suppliers through the client, and calculate the similarity value of the biometrics to be verified and the registered biometrics, if the similarity value is not less than the preset threshold, Then confirm that the biometric verification is successful;
  • the verification result confirmation unit is used to confirm that if the verification code verification and the biometric verification are successful, the verification result is that the superior supplier information and the subordinate supplier information are true.
  • the payment voucher transfer module 15 includes:
  • the account book generating unit is used to generate electronic account book information when it detects that an electronic payment voucher transfer request is generated, wherein the electronic account book information includes the payer, the payee and the transaction amount, the payer is the superior supplier, and the payee is the inferior Supplier, the transaction amount is the second payment voucher;
  • the encapsulation unit is used to electronically sign the electronic account book information by using a preset private key to obtain the signature information, and encapsulate the electronic account book information and the signature information into a block body;
  • the block combination unit is used to encapsulate the summary information of the previous block of the blockchain into a block header, so that the block body and block header form a new block, and the new block and the existing block chain Blocks are linked into a new blockchain;
  • the block sending unit is used to send a new block to each terminal of the new blockchain, so that when the terminal corresponding to the lower-level supplier receives the new block, the preset public key is used for the new
  • the signature information in the block body of the block is verified, and after the verification is successful, the electronic account book information in the block body is obtained and updated.
  • the blockchain-based supply chain payment device also includes:
  • the exchange rate acquisition module is used to obtain the conversion rate between the currency type of the actual payment amount and the default currency of the electronic payment voucher if the currency type of the actual payment amount is different from the default currency type of the electronic payment voucher;
  • the currency conversion module is used to generate a default currency amount that is the same as the actual payment amount according to the actual payment amount according to the conversion rate, and use the default currency amount as the converted actual payment amount M.
  • FIG. 8 shows a functional block diagram of a blockchain-based supply chain payment collection device that corresponds one-to-one to the blockchain-based supply chain payment collection method of the above embodiment.
  • the supply chain collection device based on the blockchain includes: a control amount judgment module 21, an authentication information transmission module 22 and a payment voucher merge module 23.
  • the detailed description of each functional module is as follows:
  • the control amount judgment module 21 is used to determine whether the disposable amount in the second electronic payment certificate is equal to the actual payment amount if it is detected that the subordinate supplier successfully receives the second electronic payment certificate sent by the superior supplier;
  • the authentication information sending module 22 is used to confirm that the payment is successful if the disposable amount in the second electronic payment voucher is equal to the actual payment amount, and send the identity verification information of the subordinate supplier to the superior supplier to enable the superior supplier Identify the subordinate suppliers according to the identity authentication information;
  • the payment voucher merging module 23 is used to merge the second payment voucher with the electronic payment voucher of the lower-level supplier after receiving the identity authentication success information sent by the upper-level supplier, and use the combined electronic payment voucher as the lower-level supplier Electronic payment voucher after the transaction.
  • each module in the aforementioned blockchain-based supply chain payment device and the aforementioned blockchain-based supply chain payment device may be implemented in whole or in part by software, hardware, and combinations thereof.
  • the above modules may be embedded in the hardware or independent of the processor in the computer device, or may be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.
  • the computer device may be a server, and its internal structure diagram may be as shown in FIG. 9.
  • the computer device includes a processor, memory, network interface, and database connected by a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities.
  • the memory of the computer device includes a non-volatile storage medium and an internal memory.
  • the non-volatile storage medium stores an operating system, computer-readable instructions, and a database.
  • the internal memory provides an environment for the operation of the operating system and computer-readable instructions in the non-volatile storage medium.
  • the database of the computer device is used to store the target enterprise account, authorized user account, association information between the target enterprise account and the authorized user account, and the authorization period corresponding to the authorized user account and the corresponding authorized user information.
  • the network interface of the computer device is used to communicate with external terminals through a network connection.
  • a computer device which includes a memory, a processor, and computer-readable instructions stored on the memory and executable on the processor.
  • the processor executes the computer-readable instructions
  • the above embodiment is implemented based on the area
  • the steps of the block chain supply chain payment method or the block chain based supply chain payment method in the above embodiment are, for example, steps S11 to S17 shown in FIG. 2, and for example steps S21 to S23 shown in FIG. 6.
  • the processor executes computer-readable instructions
  • the functions of each module / unit of the blockchain-based supply chain payment device in the above embodiment or the blockchain-based supply chain payment device in the above embodiment are implemented, for example, as shown in FIG. 7
  • the functions of the modules 11 to 17 are, for example, the functions of the modules 21 to 23 shown in FIG. 8. To avoid repetition, I will not repeat them here.
  • one or more non-volatile readable storage media are provided, the computer-readable instructions are stored on the non-volatile readable storage media, and the computer-readable instructions are executed by one or more processors Implement the steps of the above-mentioned embodiment based on the blockchain-based supply chain payment method or the above-mentioned embodiments based on the blockchain-based supply chain payment method, or the computer-readable instructions are executed by one or more processors For example, the function of each module / unit in the supply chain payment device based on the blockchain or the supply chain payment device based on the blockchain in the above embodiment. To avoid repetition, I will not repeat them here.
  • the non-volatile readable storage medium may include: any entity or device capable of carrying the computer-readable instructions, recording medium, U disk, removable hard disk, magnetic disk, optical disk, computer memory, read-only Memory (Read-Only Memory, ROM), Random Access Memory (Random Access Memory, RAM), electrical carrier signals, telecommunications signals, etc.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请公开了一种基于区块链的供应链支付方法、收款方法、装置、设备及介质，所述支付方法包括：在接收到上级供应商发送的支付请求时，获取支付请求中包含的上级供应商信息、下级供应商信息和实际支付金额M，并对供应商信息进行真实性验证，在确认均真实后，获取上级供应商的电子支付凭证中的可支配金额N，并与实际支付金额M比较，在N大于M时，对该电子支付凭证进行拆分，得到金额为N-M的第一电子支付凭证和金额为M的第二电子支付凭证，通过区块链的方式，将第二电子支付凭证转移给下级供应商。使得核心企业签发的电子支付凭证，可以通过区块链的方式，在各级供应商之间自由交易，提高金融供应链电子支付的效率和安全性。

Description

基于区块链的供应链支付方法、收款方法、装置、设备及介质
本申请以2018年10月12日提交的申请号为201811191339.9，名称为“基于区块链的供应链支付方法、收款方法、装置、设备及介质”的中国发明专利申请为基础，并要求其优先权。
技术领域
本申请涉及金融科技领域，尤其涉及一种基于区块链的供应链支付方法、收款方法、装置、设备及介质。
背景技术
随着社会经济的迅猛发展和人们生活水平的提高，一些核心企业往往需要的多个一级供应商来进行原料供应，而这些一级供应商也需要多个二级供应商进行原料供应，这使得构成了一个复杂的金融供应链，该金融供应链金融会包含多层级供应商之间的供销关联的情况。
在当前，核心企业为了业务便利，会利用自己的强信用来签发电子支付凭证，通过电子支付凭证与各个一级供应商进行支付交易，在到达指定日期，各个一级供应商可以通过电子支付凭证从核心企业获取货款，但在未收到货款之前，一级供应商需要向自己的下级供应商，即二级供应商，预先支付货款，二级供应商也需要向自己的下级供应商，即向三级供应商预先支付货款，也即，当前通过核心企业签发的电子支付凭证无法在各级供应商之间流通，这使得金融供应链之间的电子支付变得尤其复杂，且效率低下、安全性不高，同时，在一些供应商出现资金短缺时，会使得供应链出现断裂，不利于供应链的稳定发展。
发明内容
本申请实施例提供一种基于区块链的供应链支付方法、收款方法、装置、计算机设备和存储介质，以解决当前金融供应链之间的电子支付复杂程度高、效率低下和安全性不高的问题。
一种基于区块链的供应链支付方法，包括：
若接收到上级供应商发送的支付请求，则获取所述支付请求中包含的上级供应商信息、下级供应商信息和实际支付金额M；
对所述上级供应商信息和所述下级供应商信息进行真实性验证，得到验证结果；
若所述验证结果为所述上级供应商信息和所述下级供应商信息均真实，则获取所述上级供应商的电子支付凭证中的可支配金额N；
当所述上级供应商的电子支付凭证中的可支配金额N超过所述实际支付金额M时，对所述上级供应商的电子支付凭证进行拆分，得到可支配金额为N-M的第一电子支付凭证和可支配金额为M的第二电子支付凭证；
通过区块链的方式，将所述第二电子支付凭证转移给所述下级供应商；
检测所述下级供应商是否已确认收款成功，并对所述下级供应商进行身份认证；
若检测到所述下级供应商已确认收款成功且所述下级供应商进行身份认证通过，则确认支付成功，并将所述第一电子支付凭证作为交易后的所述上级供应商的电子支付凭证。
一种基于区块链的供应链收款方法，包括：
若检测到下级供应商成功接收上级供应商发送的第二电子支付凭证，则判断所述第二电子支付凭证中的可支配金额与所述实际支付金额是否相等；
若所述第二电子支付凭证中的可支配金额与所述实际支付金额相等，则确认收款成 功，并向所述上级供应商发送所述下级供应商的身份认证信息，以使所述上级供应商根据所述身份认证信息对所述下级供应商进行身份认证；
在接收到所述上级供应商发送的身份认证成功信息后，将所述第二支付凭证与所述下级供应商的电子支付凭证进行合并，并将合并后的电子支付凭证作为所述下级供应商交易后的电子支付凭证。
一种基于区块链的供应链支付装置，包括：
支付请求获取模块，用于若接收到上级供应商发送的支付请求，则获取所述支付请求中包含的上级供应商信息、下级供应商信息和实际支付金额M；
真实性验证模块，用于对所述上级供应商信息和所述下级供应商信息进行真实性验证，得到验证结果；
支配金额获取模块，用于若所述验证结果为所述上级供应商信息和所述下级供应商信息均真实，则获取所述上级供应商的电子支付凭证中的可支配金额N；
支付凭证拆分模块，用于当所述上级供应商的电子支付凭证中的可支配金额N超过所述实际支付金额M时，对所述上级供应商的电子支付凭证进行拆分，得到可支配金额为N-M的第一电子支付凭证和可支配金额为M的第二电子支付凭证；
支付凭证转移模块，用于通过区块链的方式，将所述第二电子支付凭证转移给所述下级供应商；
支付检测模块，用于检测所述下级供应商是否已确认收款成功，并对所述下级供应商进行身份认证；
支付确认模块，用于若检测到所述下级供应商已确认收款成功且所述下级供应商进行身份认证通过，则确认支付成功，并将所述第一电子支付凭证作为交易后的所述上级供应商的电子支付凭证。
一种基于区块链的供应链收款装置，包括：
支配金额判断模块，用于若检测到下级供应商成功接收上级供应商发送的第二电子支付凭证，则判断所述第二电子支付凭证中的可支配金额与所述实际支付金额是否相等；
认证信息发送模块，用于若所述第二电子支付凭证中的可支配金额与所述实际支付金额相等，则确认收款成功，并向所述上级供应商发送所述下级供应商的身份认证信息，以使所述上级供应商根据所述身份认证信息对所述下级供应商进行身份认证；
支付凭证合并模块，用于在接收到所述上级供应商发送的身份认证成功信息后，将所述第二支付凭证与所述下级供应商的电子支付凭证进行合并，并将合并后的电子支付凭证作为所述下级供应商交易后的电子支付凭证。
一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机可读指令，所述处理器执行所述计算机可读指令时实现上述基于区块链的供应链支付方法的步骤或所述上述基于区块链的供应链收款方法的步骤。
一个或多个非易失性可读存储介质，所述非易失性可读存储介质存储有计算机可读指令，所述计算机可读指令被一个或多个处理器执行时实现上述基于区块链的供应链支付方法的步骤或所述上述基于区块链的供应链收款方法的步骤。
本申请的一个或多个实施例的细节在下面的附图和描述中提出，本申请的其他特征和优点将从说明书、附图以及权利要求变得明显。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的基于区块链的供应链支付方法和收款方法的应用环境示意图；
图2是本申请实施例提供的基于区块链的供应链支付方法的实现流程图；
图3是本申请实施例提供的基于区块链的供应链支付方法中步骤S12的实现流程图；
图4是本申请实施例提供的基于区块链的供应链支付方法中步骤S15的实现流程图；
图5是本申请实施例提供的基于区块链的供应链支付方法中货币转换的实现流程图；
图6是本申请实施例提供的基于区块链的供应链收款方法的实现流程图；
图7是本申请实施例提供的基于区块链的供应链支付装置的示意图；
图8是本申请实施例提供的基于区块链的供应链收款装置的示意图；
图9是本申请实施例提供的计算机设备的示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
请参阅图1，图1示出本申请实施例提供的基于区块链的供应链支付方法和收款方法的应用环境。该基于区块链的供应链支付方法和收款方法应用在金融供应链中各级供应商进行电子支付场景中。该电子支付场景包括服务端、上级供应商客户端和下级供应商客户端，其中，上级供应商通过上级供应商客户端向服务端发送支付请求，并在需要进行身份验证时，通过上级供应商客户端向服务端提供验证信息，下级供应商通过下级供应商客户端接收服务端发送的电子支付凭证，并在需要进行身份验证时，通过下级供应商客户端提供证信息，服务端对上级供应商信息和下级供应商信息进行认证，并通过区块链的方式实现金融供应链的电子交易。上级供应商客户端和下级供应商客户端具体可以但不限于是便携式计算机、个人电脑、手机和平板电脑等智能设备等，服务端具体可以用独立的服务器或者多个服务器组成的服务器集群实现。
请参阅图2，图2示出本申请实施例提供的一种基于区块链的供应链支付方法，以该方法应用在图1中的服务端为例进行说明，详述如下：
S11：若接收到上级供应商发送的支付请求，则获取支付请求中包含的上级供应商信息、下级供应商信息和实际支付金额M。
具体地，在集团公司，通常存在多级采购的情形，如一级供应商向核心企业供货、二级供应商向一级供应商供货等，而货款支付则恰好对应反向流动，即核心企业向一级供应商支付货款，一级供应商向二级供应商支付货款，这形成了一个金融供应链，在被实施例的电子支付场景中，上级供应商为货款的支付方，下级供应商为货款的收款方，在接收到上级供应商通过网络传输协助发送的支付请求时，服务端获取该支付请求中包含的上级供应商信息、下级供应商信息和实际支付金额M，以便后续对交易的真实性进行验证。
其中，电子支付凭证(Electronic payment voucher)是指具有一定格式、一定金额，于见票时或指定到期日，在指定地点，由发票人或委托他人为付款人，向收款人或持票人无条件支付款项的电子书面凭证。
其中，金融供应链(Supply Chain Finance，SCF)是指银行向客户提供融资和其他结算、理财服务，同时向这些客户的供应商提供贷款及时收达的便利，或者向其分销商提供预付款代付及存货融资服务，也即，银行将核心企业和上下游企业联系在一起提供灵活运用的金融产品和服务的一种融资模式，是商业银行信贷业务的一个专业领域，也是企业尤其是中小企业的一种融资渠道。
其中，网络传输协议包括但不限于：互联网控制报文协议(Internet Control Message  Protocol，ICMP)、地址解析协议(ARP Address Resolution Protocol，ARP)和文件传输协议(File Transfer Protocol，FTP)等。
值得说明的是，在传统的供应链中，核心企业依托其自身的强信用，通过向一级供应商签发电子支付凭证的方式来进行交易，并在电子支付凭证达到指定的支付期限时对签发的电子支付凭证进行兑现，但一级供应商之外的其他供应商，则无法得到核心企业的强信用的便利，在本提案中，通过将电子支付凭证融入到区块链中，使得任意一个上级供应商，和该上级供应商对应的下级供应商之间，可以直接通过核心企业签发的电子支付凭证进行支付，提高了支付的效率和安全性。
S12：对上级供应商信息和下级供应商信息进行真实性验证，得到验证结果。
具体地，在进行电子支付之前，需要先将上级供应商信息和下级供应商信息与预设的数据库中存储的供应商信息进行对比验证，判断该上级供应商信息和下级供应商信息是否真实，并得到验证结果。
容易理解地，只有在验证结果为上级供应商信息和下级供应商信息均真实的情况下，才会进行后续电子支付操作，以提高电子支付的安全性。
S13：若验证结果为上级供应商信息和下级供应商信息均真实，则获取上级供应商的电子支付凭证中的可支配金额N。
具体地，在验证结果为上级供应商和下级供应商信息均真实时，即确认支付合法时，并获取该上级供应商的电子支付凭证中包含的可支配金额N。
其中，可支配金额N是指电子支付凭证中包含的最大可进行交易的金额为N，例如，一电子支付凭证的可支配金额为20000元，即代表使用该电子支付凭证进行电子支付时，可用于支付的金额上限为20000元。
其中，上级供应商的电子支付凭证的获取，具体可以在区块链的上级供应商对应的终端上获取，也可以是从预设的数据库中获取，也可依实际情况中对电子支付凭证存储路径的设置进行确定，此处不作具体限制。
若上级供应商的电子支付凭证是从预设的数据库中获取，则在每次确认支付成功后，对该预设的数据库中的上级供应商的电子支付凭证进行更新。
应理解，当上级供应商信息或下级供应商信息中存在不真实信息，则可确认此次支付不合法，将终止本次支付，并向服务端附属的监控终端发送异常警告。
S14：当上级供应商的电子支付凭证中的可支配金额N超过实际支付金额M时，对上级供应商的电子支付凭证进行拆分，得到可支配金额为N-M的第一电子支付凭证和可支配金额为M的第二电子支付凭证。
具体地，在上级供应商的电子支付凭证中的可支配金额N超过实际支付金额M时，对上级供应商的电子支付凭证进行拆分，得到可支配金额为N-M的第一电子支付凭证和可支配金额为M的第二电子支付凭证，并在拆分后的第一电子支付凭证和第二支付凭证上生成拆分时间。
其中，在对上级供应商的电子支付凭证进行拆分的具体实施过程中，可以是将该电子支付凭证进行复制，得到两个一样的电子支付凭证，并对这两个电子支付凭证的可支配金额进行调整，使得两个电子支付凭证的可支配金额之和等于上级供应商的电子支付凭证的可支配金额N，作为一种优选方式，在进行拆分时，得到可支配金额为N-M的第一电子支付凭证和可支配金额为M的第二电子支付凭证，使得第二支付凭证的可支配金额与支付请求中的实际支付金额相同，从而可以直接使用第二电子支付凭证进行后续电子支付，提高电子支付的效率。
需要说明的是，本实施例中所提及的将上级供应商的电子支付凭证拆分成两个电子支付凭证，仅是本申请中针对电子支付凭证进行拆分的一种优选方式，在实际过程中也可以是拆分成两个以上的电子支付凭证，具体可根据实际情况进行确定，此处不作具体限制。
若上级供应商的电子支付凭证中的金额N等于实际支付金额M，则无需对上级供应商的电子支付凭证进行拆分，即直接将上级供应商的电子支付凭证作为第二电子支付凭证。
应理解，在上级供应商的电子支付凭证中的可支配金额N小于实际支付金额M时，即上级供应商的电子支付凭证中的可支配金额不足以进行本次支付时，拒绝本次支付请求，并向上级供应商客户端发送提示信息。
S15：通过区块链的方式，将第二电子支付凭证转移给下级供应商。
具体地，通过区块链的方式，将第二电子支付凭证转移给下级供应商，使得无法直接进行流通的电子支付凭证可以从上级供应商支付给下级供应商，提高了金融供应链电子支付的效率，同时，这样采用区块链的方式，也提高了电子支付的安全性。
其中，区块链是一种按照时间顺序将数据区块以顺序相连的方式组合成的一种链式数据结构，并以密码学方式保证的不可篡改和不可伪造的分布式账本。
S16：检测下级供应商是否已确认收款成功，并对下级供应商进行身份认证。
具体地，在将第二电子支付凭证转移给下级供应商后，需要检测下级供应商是否确认支付成功，若下级供应商没有确认、或者下级供应商确认支付失败、或者在预设时间范围内检测不到下级供应商是否确认支付成功的信息，则说明存在安全隐患，不可以进行实际支付。
其中，在本申请实施例中，检测下级供应商是否确认支付成功，具体可以是根据是否接收到下级供应商发送的表示确认支付成功的回执信息进行检测，收到该回执信息则判断下级供应商确认支付成功；对于通过区块链进行支付的情形，还可以通过查询区块链中是否有下级供应商上传的针对该支付的确认信息，来判断下级供应商是否确认支付成功，若有所述确认信息，则判断下级供应商确认支付成功；另外，上级供应商和下级供应商也可以进行语音或视频通信，下级供应商可以通过语音或视频告知上级供应商支付成功，由上级供应商在上级供应商客户端中进行确认操作，上级供应商客户端可以根据是否检测到上述确认操作确定下级供应商是否确认支付成功，并将确认结果反馈给服务端。
在对下级供应商确认支付成功进行检测后，还需要对下级供应商进行身份认证，以进一步确保下级供应商就是支付所期望的一方，保证实际支付的下级供应商的合法性和正确性。在本申请实施例中任一实施方式的基础上，对所述下级供应商进行身份认证，可以包括但不限于：对所述下级供应商的身份的合法性和正确性进行认证，具体实施时，下级供应商在确认支付成功后，可以向上级供应商发送下级供应商的身份认证信息，上级供应商根据该身份认证信息对所述下级供应商的合法性和正确性进行认证，只有在认证通过后，才会进行实际支付。
在本申请实施例中，对所述下级供应商进行身份认证可以包括：通过语音通信交互、视频直播交互或多媒体信息交互对下级供应商进行身份认证。例如，上级供应商和下级供应商进行语音或视频通信，上级供应商根据语音通信交互或视频直播交互即可实现对下级供应商进行身份认证；另外，下级供应商也可以录制短视频等多媒体信息并发送给上级供应商，上级供应商根据该多媒体信息对下级供应商进行身份认证。容易理解的是，在进行语音或视频通信时，可以同时实现下级供应商对上级供应商的身份认证，以及上级供应商对下级供应商的身份认证。
另外，上级供应商和下级供应商还可以自定义对下级供应商进行身份认证的方式，例如，在对所述下级供应商进行身份认证前，上级供应商可以指定以上任意一种身份认证方式对下级供应商进行身份认证；相应的，下级供应商也可以指定以上任意一种身份认证方式对上级供应商进行身份认证。
应理解，若在预设时间内检测不到所述下级供应商已确认收款成功，或者对所述下级供应商的身份认证未通过，则说明可能存在安全隐患，不进行实际支付。
S17：若检测到下级供应商已确认收款成功且下级供应商进行身份认证通过，则确认 支付成功，并将第一电子支付凭证作为交易后的上级供应商的电子支付凭证。
具体地，在检测到下级供应商已确认收款成功且下级供应商进行身份认证通过时，则可确认支付成功，此时，将第一电子支付凭证作为交易后的上级供应商的电子支付凭证。
在本实施例中，在接收到上级供应商发送的支付请求时，获取支付请求中包含的上级供应商信息、下级供应商信息和实际支付金额M，并对上级供应商信息和下级供应商信息进行真实性验证，确认验证结果为上级供应商信息和下级供应商信息均真实后，获取上级供应商的电子支付凭证中的金额N，进而将该电子支付凭证中的金额N与实际支付金额M进行比较，在上级供应商的电子支付凭证中的金额N超过实际支付金额M时，对上级供应商的电子支付凭证进行拆分，得到金额为N-M的第一电子支付凭证和金额为M的第二电子支付凭证，进而采用区块链的方式，将第二电子支付凭证转移给下级供应商，并开启对下级供应商是否已确认收款成功以及对下级供应商进行身份认证的检测，若检测到下级供应商已确认收款成功且下级供应商进行身份认证通过，则确认支付成功，并将第一电子支付凭证作为交易后的上级供应商的电子支付凭证，使得核心企业签发的电子支付凭证可以在各级供应商之间自由交易，优化了金融供应链之间电子支付的便捷性，提高金融供应链电子支付的效率，同时，使用区块链技术进行电子支付，使得电子支付具有可溯源性和防篡改性，也提高了电子支付的安全性，同时，这种通过核心企业强信用签发的电子支付凭证进行流转的形式，也避免了供应商之前资金周转不畅导致的金融供应链的异常或者断裂，保证了金融供应链的稳定性。
在图2对应的实施例的基础之上，下面通过一个具体的实施例来对步骤S12中所提及的对上级供应商信息和下级供应商信息进行真实性验证，得到验证结果的具体实现方法进行详细说明。
请参阅图3，图3示出了本申请实施例提供的步骤S12的具体实现流程，详述如下：
S121：从预设的数据库中，查询是否存在目标企业账号，若存在目标企业账号，则查询授权用户账号是否与目标企业账号关联，其中，预设的数据库预先存储有目标企业账号、授权用户账号、目标企业账号与授权用户账号之间的关联信息，以及授权用户账号对应的授权期限和对应的授权用户信息。
具体地，在上级供应商信息和下级供应商信息中，均包含目标企业账号、授权用户账号和登录时间，在服务端预设的数据库中，预先存有目标企业账号、授权用户账号、目标企业账号与授权用户账号之间的关联信息，以及授权用户账号对应的授权期限和对应的授权用户信息，通过在预设的数据库中，对上级供应商信息和下级供应商信息中的目标企业账号、授权用户账号和登录时间与预设的数据库中的这些信息进行查询，看数据库中是否存在与这些信息一致的信息，来判断支付请求中这些信息的真实性。
其中，目标企业帐号是预先完成企业帐号注册的企业帐号。授权用户帐号是经授权的授权用户对应的用户帐号。登录时间是上级供应商客户端触发该验证时的系统当前时间，该系统当前时间可采用企业客户端内置的时间获取函数(如JAVA中，System类中的currentTimeMillis方法)来获取系统当前时间，并将该系统当前时间确定为登录时间。
在本实施例中，服务端预先关联存储有目标企业帐号对应的至少一个授权用户帐号、以及与每一授权用户帐号相对应的授权期限和授权用户信息，以便基于该授权用户信息进行验证。该授权用户信息包括但不限于手机号码和注册生物特征等。
S122：若授权用户账号与目标企业账号关联，则从预设的数据库中，获取授权用户帐号对应的授权期限。
具体地，在查询结果为授权用户账号与目标企业账号关联时，从预设的数据库中，获取该授权用户账户对应的授权期限，并判断登录时间是否在授权期限之内。
其中，授权期限可以是授权用户账号具有有效性的截止时间点，例如，一授权用户账号的授权期限为“2018年10月12日24:00:00”，即代表该授权用户账号在2018年10月 12日24:00:00之前是有效的。
S123：若登录时间在授权期限内，则查询授权用户帐号相对应的授权用户信息，其中，授权用户信息包括手机号码和注册生物特征。
本实施例中，先基于身份验证请求中的登录时间与授权用户帐号对应的授权期限进行对比，若登录时间在该授权期限内，则说明该授权用户帐号处于有效期内，可进行登录、交易或者其他签约行为；反之，若登录时间不在该授权期限内，则说明该授权用户帐号不处于有效期内，不可进行登录、交易或者其他签约行为，以保证目标企业帐号对应的企业的交易安全性。
具体地，服务器只有在登录时间在授权期限内，才会基于授权用户帐号查询数据库，获取与授权用户帐号相对应授权用户信息，以便基于该授权用户信息进行身份验证，以保证目标企业帐号对应的企业的交易安全性，并可避免登录时间不在授权期限内而进行的其他验证行为导致的无用开销，提高处理效率。
S124：向手机号码对应的手机终端发送身份验证码，并接收手机终端返回的登录验证码，若身份验证码与登录验证码一致，则确认验证码验证成功。
其中，身份验证码是平台服务器采用动态码生成工具随机生成的用于进行身份验证的验证码，该身份验证码与授权用户帐号关联存储在服务器，设置有有效期，例如60秒。登录验证码是在用户登录阶段，通过企业客户端上传的用于进行身份验证的验证码。服务器在获取到登录验证码之后，会采用字符串匹配算法对比该登录验证码与身份验证码是否一致，若两者一致，则验证码验证成功；反之，则验证码验证不成功。
S125：获取上机供应商和下级供应商通过客户端上传的待验证生物特征，并计算待验证生物特征与注册生物特征的相似度值，若相似度值不小于预设阈值，则确认生物验证成功。
本实施例中，若服务端存储的授权用户信息中的注册生物特征为注册声纹特征，则通过使上级供应商客户端和下级供应商客户端启动内置或外接的录音设备，采集待验证声纹特征，采用相似度算法对比注册声纹特征和待验证声纹特征，获取其相似度，若相似度是否达到预设阈值，若是，则生物验证成功，反之，则生物验证不成功。
本实施例中，若服务端存储的授权用户信息中的注册生物特征为注册人脸特征，则使上级供应商客户端和下级供应商客户端启动内置或外接的拍摄设备，采集待验证人脸特征，采用相似度算法对比注册人脸特征和待验证人脸特征，获取其相似度，若相似度是否达到预设阈值，若是，则生物验证成功，反之，则生物验证不成功。
进一步地，若服务端存储的授权用户信息中的注册生物特征为注册声纹特征，在生物验证过程中，还可向上级供应商客户端和下级供应商客户端发送待阅读信息，或者安全问题，以使用户阅读该待阅读信息，或者回答安全问题，以采集待验证语音数据，并在提取待验证声纹特征之外，还需识别该待验证语音数据识别到的待验证文本数据是否与待阅读信息相匹配，以避免非法用户采用预先录制的录音数据进行语音验证。
进一步地，若服务端存储的授权用户信息中的注册生物特征为注册人脸特征，在生物验证过程中，除了采用相似度算法对比注册人脸特征和待验证人脸特征，获取其相似度与预设阈值进行对比，确定生物验证是否成功之外，还需要向上级供应商客户端和下级供应商客户端发送动作指令，例如眨眼、摇头，以使拍摄设备采集基于该动作指令形成的短视频，以采用微表情识别模型识别该短视频是否包括上述动作指令对应的动作，以实现活动检测，以避免非法用户采用授权用户的人脸图像进行人脸验证。
需要说明的是，步骤S124和步骤S125没有必然的先后执行顺序，其可以是并列执行的关系，此处不做限制。
S126：若验证码验证与生物验证均成功，则确认验证结果为上级供应商信息和下级供应商信息均真实。
具体地，只有上级供应商和下级供应商验证码验证和特征验证均成功，才认定所述上级供应商信息和下级供应商信息均真实。
在本实施例中，通过从预设的数据库中，对上级供应商信息和下级供应商信息中包含的目标企业账号、授权用户账号、目标企业账号与授权用户账号之间的关联信息进行验证，确定获取的目标企业账号、授权用户账号、及关联信息与数据库即预存的信息一致后，进行验证码验证和生物验证，若验证码验证和生物验证均验证成功，则确认验证结果为上级供应商信息和下级供应商信息均真实，通过采用多个角度进行验证，确保上级供应商信息和下级供应商信息的真实性，提高电子支付的安全性。
在图2对应的实施例的基础之上，下面通过一个具体的实施例来对步骤S15中所提及的通过区块链的方式，将第二电子支付凭证转移给下级供应商的具体实现方法进行详细说明。
请参阅图4，图4示出了本申请实施例提供的步骤S15的具体实现流程，详述如下：
S151：在检测到产生电子支付凭证转移请求时，生成电子账簿信息，其中，电子账簿信息包括支付方、收款方和交易金额，支付方为上级供应商，收款方为下级供应商，交易金额为第二支付凭证。
具体地，在检测到产生电子支付凭证转移请求时，生成电子账簿信息，该电子账簿信息包括支付方、收款方和交易金额，支付方为上级供应商，收款方为下级供应商，交易金额为第二支付凭证。
S152：采用预设的私钥对电子账簿信息进行电子签名，得到签名信息，并将电子账簿信息和签名信息封装成区块体。
具体地，通过预设的私钥对电子账簿信息进行电子签名，得到签名信息，进而将电子账簿信息和签名信息封装成区块体。
其中，进行电子签名具体可以是通过SM2算法来实现。
其中，预设的私钥为上级供应商和下级供应商通过区块链的点对点通讯约定生成，使得包含该私钥的签名信息可以被下级供应商通过对应的公钥解密。
S153：将区块链的上一区块的摘要信息封装成区块头，使区块体和区块头组成新的区块，将新的区块与区块链中已有的区块之间链接成新的区块链。
具体地，将区块链上的上一区块的摘要信息封装成区块头，并将步骤S152中得到的区块体与该区块体组合成新的区块，并使用该新的区块与区块链原有的区块之间进行链接，得到新的区块链。
其中，上一区块的摘要信息包括但不限于上一区块的地址和交易时间戳，对上一区块的摘要信息进行装备具体可以是通过SM3算法来实现。
S154：将新的区块发送至新的区块链的每个终端，以使下级供应商对应的终端在接收到新的区块时，采用预设的公钥对新的区块的区块体中的签名信息进行验证，并在验证成功后，获取并更新区块体中的电子账簿信息。
具体地，对新的区块进行广播，使得下级供应商对应的终端在接收到该新的区块时，采用预设的公钥对该新的区块的区块体中的签名信息进行验证，并在验证成功后，获取区块体中的电子账簿信息，用于在收款过程中进行验证，在交易完成后，对该电子账簿信息进行更新，该更新可以包括对交易时间、交易金额、参与交易的供应商等交易信息的记录。
在本实施例中，在检测到产生电子支付凭证转移请求时，生成电子账簿信息，进而采用预设的私钥对电子账簿信息进行电子签名，得到签名信息，并将电子账簿信息和签名信息封装成区块体，将区块链的上一区块的摘要信息封装成区块头，使区块体和区块头组成新的区块，将新的区块与区块链中已有的区块之间链接成新的区块链，再将新的区块发送至新的区块链的每个终端，以使下级供应商对应的终端在接收到新的区块时，采用预设的公钥对新的区块的区块体中的签名信息进行验证，并在验证成功后，获取并更新区块体中 的电子账簿信息，这种区块链的方式，将第二电子支付凭证发送给下级供应商，使得原本不能直接进行流通的电子支付凭证可以快捷进行电子支付，提高了电子支付的效率，同时，由于区块链具有去中心化、不可篡改、安全可靠等特点，保证了电子支付凭证进行的电子支付的安全性。
在一实施例中，如图5所示，在步骤S11之后，且在步骤S14之前，该基于区块链的供应链支付方法还包括：
S181：若实际支付金额的货币类型与电子支付凭证的默认货币类型不同，则获取实际支付金额的货币类型和与电子支付凭证的默认货币之间的转换汇率。
具体地，在检测到实际支付金额的货币类型与电子支付凭证的默认货币类型不同时，需要获取实际支付金额的货币类型和与电子支付凭证的默认货币之间的转换汇率以便后续对实际支付金额的货币类型进行转换，以使实际支付金额转化为默认货币类型说代表的支付金额，确保后续使用电子支付凭证进行电子支付的正常进行。
其中，获取实际支付金额的货币类型和与电子支付凭证的默认货币之间的转换汇率，可以是通过访问网站查询最新的转换汇率，也可以从预设的数据库中进行转换汇率的获取，也可以根据实际情况选择其他方式，此处不作具体限制。
例如，在一具体实施方式中，实际支付金额为2000美元，即支付金额的货币类型为美元，而电子支付凭证的默认货币类型为人民币，此时，需要获取美元与人民币之间的转换汇率，从预设的数据库中获取到美元转换成人民币的转换汇率为6.9265。
S182：按照转换汇率，根据实际支付金额生成与实际支付金额价值相同的默认货币金额，并将默认货币金额作为转换后的实际支付金额M。
具体地，按照步骤S181中获取到的人民币的转换汇率，基于实际支付金额，生成与实际支付金额价值相同的默认货币金币，并将该默认货币金额作为转换后的实际支付金额M。
继续以步骤S181中的示例为例，基于实际支付金额2000美元，以及美元转换成人民币的转换汇率6.9274，得到与实际支付金额2000美元等价的人民币为13853元，将13853元人民币作为实际支付金额M。
在本实施例中，在实际支付金额的货币类型与电子支付凭证的默认货币类型不同时，获取这两种货币类型之间的转换汇率，进而通过该转换汇率，将实际支付金额转换成与默认货币金额，使得该基于区块链的供应链支付方法可以针对多种货币类型进行交易，而无需人工进行预先转换，提高了电子支付的效率。
请参阅图6，图6示出本申请实施例提供的一种基于区块链的供应链收款方法，以该方法应用在图1中的服务端为例进行说明，详述如下：
S21：若检测到下级供应商成功接收上级供应商发送的第二电子支付凭证，则判断第二电子支付凭证中的可支配金额与实际支付金额是否相等。
具体地，下级供应商在接收到上级供应商发送的第二电子支付凭证后，会向服务端发送成功接收上级供应商发送的第二电子支付凭证的消息，从该消息中获取第二电子支付凭证中的可支配金额，并判断第二电子支付凭证中的可支配金额与实际支付金额是否相等。
容易理解地，电子支付和电子收款均为通过网络虚拟交易，为防止数据传输过程中被篡改破坏，下级供应商在接收到第二电子支付凭证后，需要向服务端发送一条确认消息，进而由服务端来判断下级供应商接收到的第二电子支付凭证中包含的可支配金额是否合法。
S22：若第二电子支付凭证中的可支配金额与实际支付金额相等，则确认收款成功，并向上级供应商发送下级供应商的身份认证信息，以使上级供应商根据身份认证信息对下级供应商进行身份认证。
具体地，在第二电子支付凭证中的可支配金额与实际支付金额相等时，确定接收到的 第二电子支付凭证真实可靠，未被篡改，此时，向上级供应商发送下级供应商的身份认证信息，以使上级供应商根据身份认证信息对下级供应商进行身份认证，具体认证过程可参考步骤S60的描述，为避免重复，此处不再赘述。
S23：在接收到上级供应商发送的身份认证成功信息后，将第二支付凭证与下级供应商的电子支付凭证进行合并，并将合并后的电子支付凭证作为下级供应商交易后的电子支付凭证。
在接收到上级供应商发送的身份认证成功信息后，即可确认交易成功，此时，将下级供应商的电子支付凭证与第二支付凭证进行合并，并将合并后的电子支付凭证作为下级供应商交易后的电子支付凭证，即完成本次收款过程。
在本实施例中，在检测到下级供应商成功接收上级供应商发送的第二电子支付凭证时，判断第二电子支付凭证中的可支配金额与实际支付金额是否相等，在第二电子支付凭证中的可支配金额与实际支付金额相等时，确认收款成功，并向上级供应商发送下级供应商的身份认证信息，以使上级供应商根据身份认证信息对下级供应商进行身份认证，在接收到上级供应商发送的身份认证成功信息后，将第二支付凭证与下级供应商的电子支付凭证进行合并，并将合并后的电子支付凭证作为下级供应商交易后的电子支付凭证，使得收款时对接收到的第二电子支付凭证的可支配金额进行确认，并对收款的供应商进行身份认证，保证收款金额和收款人真实合法，提高了电子收款的安全性。
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
图7示出与上述实施例基于区块链的供应链支付方法一一对应的基于区块链的供应链支付装置的原理框图。如图7所示，该基于区块链的供应链支付装置包括支付请求获取模块11、真实性验证模块12、支配金额获取模块13、支付凭证拆分模块14、支付凭证转移模块15、支付检测模块16和支付确认模块17。各功能模块详细说明如下：
支付请求获取模块11，用于若接收到上级供应商发送的支付请求，则获取支付请求中包含的上级供应商信息、下级供应商信息和实际支付金额M；
真实性验证模块12，用于对上级供应商信息和下级供应商信息进行真实性验证，得到验证结果；
支配金额获取模块13，用于若验证结果为上级供应商信息和下级供应商信息均真实，则获取上级供应商的电子支付凭证中的可支配金额N；
支付凭证拆分模块14，用于当上级供应商的电子支付凭证中的可支配金额N超过实际支付金额M时，对上级供应商的电子支付凭证进行拆分，得到可支配金额为N-M的第一电子支付凭证和可支配金额为M的第二电子支付凭证；
支付凭证转移模块15，用于通过区块链的方式，将第二电子支付凭证转移给下级供应商；
支付检测模块16，用于检测下级供应商是否已确认收款成功，并对下级供应商进行身份认证；
支付确认模块17，用于若检测到下级供应商已确认收款成功且下级供应商进行身份认证通过，则确认支付成功，并将第一电子支付凭证作为交易后的上级供应商的电子支付凭证。
进一步地，真实性验证模块12包括：
关联性查询单元，用于从预设的数据库中，查询是否存在目标企业账号，若存在目标企业账号，则查询授权用户账号是否与目标企业账号关联，其中，预设的数据库预先存储有目标企业账号、授权用户账号、目标企业账号与授权用户账号之间的关联信息，以及授权用户账号对应的授权期限和对应的授权用户信息；
授权期限获取单元，用于若授权用户账号与目标企业账号关联，则从预设的数据库中， 获取授权用户帐号对应的授权期限；
授权用户信息查询单元，用于若登录时间在授权期限内，则查询授权用户帐号相对应的授权用户信息，其中，授权用户信息包括手机号码和注册生物特征；
验证码验证单元，用于向手机号码对应的手机终端发送身份验证码，并接收手机终端返回的登录验证码，若身份验证码与登录验证码一致，则确认验证码验证成功；
生物验证单元，用于获取上机供应商和下级供应商通过客户端上传的待验证生物特征，并计算待验证生物特征与注册生物特征的相似度值，若相似度值不小于预设阈值，则确认生物验证成功；
验证结果确认单元，用于若验证码验证与生物验证均成功，则确认验证结果为上级供应商信息和下级供应商信息均真实。
进一步地，支付凭证转移模块15包括：
账簿生成单元，用于在检测到产生电子支付凭证转移请求时，生成电子账簿信息，其中，电子账簿信息包括支付方、收款方和交易金额，支付方为上级供应商，收款方为下级供应商，交易金额为第二支付凭证；
封装单元，用于采用预设的私钥对电子账簿信息进行电子签名，得到签名信息，并将电子账簿信息和签名信息封装成区块体；
区块组合单元，用于将区块链的上一区块的摘要信息封装成区块头，使区块体和区块头组成新的区块，将新的区块与区块链中已有的区块之间链接成新的区块链；
区块发送单元，用于将新的区块发送至新的区块链的每个终端，以使下级供应商对应的终端在接收到新的区块时，采用预设的公钥对新的区块的区块体中的签名信息进行验证，并在验证成功后，获取并更新区块体中的电子账簿信息。
该基于区块链的供应链支付装置还包括：
汇率获取模块，用于若实际支付金额的货币类型与电子支付凭证的默认货币类型不同，则获取实际支付金额的货币类型和与电子支付凭证的默认货币之间的转换汇率；
货币转换模块，用于按照转换汇率，根据实际支付金额生成与实际支付金额价值相同的默认货币金额，并将默认货币金额作为转换后的实际支付金额M。
图8示出与上述实施例基于区块链的供应链收款方法一一对应的基于区块链的供应链收款装置的原理框图。如图8所示，该基于区块链的供应链收款装置包括：支配金额判断模块21、认证信息发送模块22和支付凭证合并模块23。各功能模块详细说明如下：
支配金额判断模块21，用于若检测到下级供应商成功接收上级供应商发送的第二电子支付凭证，则判断第二电子支付凭证中的可支配金额与实际支付金额是否相等；
认证信息发送模块22，用于若第二电子支付凭证中的可支配金额与实际支付金额相等，则确认收款成功，并向上级供应商发送下级供应商的身份认证信息，以使上级供应商根据身份认证信息对下级供应商进行身份认证；
支付凭证合并模块23，用于在接收到上级供应商发送的身份认证成功信息后，将第二支付凭证与下级供应商的电子支付凭证进行合并，并将合并后的电子支付凭证作为下级供应商交易后的电子支付凭证。
关于基于区块链的供应链支付装置的具体限定可以参见上文中对于基于区块链的供应链支付方法的限定，关于基于区块链的供应链收款装置的具体限定可以参见上文中对于基于区块链的供应链收款方法的限定，在此不再赘述。上述基于区块链的供应链支付装置和上述基于区块链的供应链收款装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
图9是本申请一实施例提供的计算机设备的示意图。该计算机设备可以是服务端，其 内部结构图可以如图9所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机可读指令和数据库。该内存储器为非易失性存储介质中的操作系统和计算机可读指令的运行提供环境。该计算机设备的数据库用于存储目标企业账号、授权用户账号、目标企业账号与授权用户账号之间的关联信息，以及授权用户账号对应的授权期限和对应的授权用户信息。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机可读指令被处理器执行时以实现一种基于区块链的供应链支付方法，或者，该计算机可读指令被处理器执行时以实现一种基于区块链的供应链收款方法。
在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机可读指令，处理器执行计算机可读指令时实现上述实施例基于区块链的供应链支付方法或者上述实施例基于区块链的供应链收款方法的步骤，例如图2所示的步骤S11至步骤S17，又例如图6所示的步骤S21至步骤S23。或者，处理器执行计算机可读指令时实现上述实施例基于区块链的供应链支付装置或者上述实施例基于区块链的供应链收款装置的各模块/单元的功能，例如图7所示的模块11至模块17的功能，又例如图8所示的模块21至模块23的功能。为避免重复，这里不再赘述。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。
在一实施例中，提供一个或多个非易失性可读存储介质，该非易失性可读存储介质上存储有计算机可读指令，该计算机可读指令被一个或多个处理器执行时实现上述实施例基于区块链的供应链支付方法或上述实施例基于区块链的供应链收款方法的步骤，或者，该计算机可读指令被一个或多个处理器执行时实现上述实施例基于区块链的供应链支付装置或上述实施例基于区块链的供应链收款装置中各模块/单元的功能。为避免重复，这里不再赘述。
可以理解地，所述非易失性可读存储介质可以包括：能够携带所述计算机可读指令的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号和电信信号等。
以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (20)

  1. 一种基于区块链的供应链支付方法，其特征在于，所述基于区块链的供应链支付方法包括：
    若接收到上级供应商发送的支付请求，则获取所述支付请求中包含的上级供应商信息、下级供应商信息和实际支付金额M；
    对所述上级供应商信息和所述下级供应商信息进行真实性验证，得到验证结果；
    若所述验证结果为所述上级供应商信息和所述下级供应商信息均真实，则获取所述上级供应商的电子支付凭证中的可支配金额N；
    当所述上级供应商的电子支付凭证中的可支配金额N超过所述实际支付金额M时，对所述上级供应商的电子支付凭证进行拆分，得到可支配金额为N-M的第一电子支付凭证和可支配金额为M的第二电子支付凭证；
    通过区块链的方式，将所述第二电子支付凭证转移给所述下级供应商；
    检测所述下级供应商是否已确认收款成功，并对所述下级供应商进行身份认证；
    若检测到所述下级供应商已确认收款成功且所述下级供应商进行身份认证通过，则确认支付成功，并将所述第一电子支付凭证作为交易后的所述上级供应商的电子支付凭证。
  2. 如权利要求1所述的基于区块链的供应链支付方法，其特征在于，所述上级供应商信息和所述下级供应商信息均包括目标企业账号、授权用户账号和登录时间，所述对所述上级供应商信息和所述下级供应商信息进行真实性验证，得到验证结果包括：
    从预设的数据库中，查询是否存在所述目标企业账号，若存在所述目标企业账号，则查询所述授权用户账号是否与所述目标企业账号关联，其中，所述预设的数据库预先存储有目标企业账号、授权用户账号、目标企业账号与授权用户账号之间的关联信息，以及授权用户账号对应的授权期限和对应的授权用户信息；
    若所述授权用户账号与所述目标企业账号关联，则从所述预设的数据库中，获取所述授权用户帐号对应的授权期限；
    若所述登录时间在所述授权期限内，则查询所述授权用户帐号相对应的授权用户信息，其中，所述授权用户信息包括手机号码和注册生物特征；
    向所述手机号码对应的手机终端发送身份验证码，并接收所述手机终端返回的登录验证码，若所述身份验证码与所述登录验证码一致，则确认验证码验证成功；
    获取所述上级供应商和所述下级供应商通过客户端上传的待验证生物特征，并计算所述待验证生物特征与所述注册生物特征的相似度值，若所述相似度值不小于预设阈值，则确认生物验证成功；
    若所述验证码验证与所述生物验证均成功，则确认所述验证结果为所述上级供应商信息和所述下级供应商信息均真实。
  3. 如权利要求1所述的基于区块链的供应链支付方法，其特征在于，所述通过区块链的方式，将所述第二电子支付凭证转移给所述下级供应商包括：
    在检测到产生电子支付凭证转移请求时，生成电子账簿信息，其中，所述电子账簿信息包括支付方、收款方和交易金额，所述支付方为所述上级供应商，所述收款方为所述下级供应商，所述交易金额为所述第二支付凭证；
    采用预设的私钥对所述电子账簿信息进行电子签名，得到签名信息，并将所述电子账簿信息和所述签名信息封装成区块体；
    将所述区块链的上一区块的摘要信息封装成区块头，使所述区块体和所述区块头组成新的区块，将所述新的区块与所述区块链中已有的区块之间链接成新的区块链；
    将所述新的区块发送至所述新的区块链的每个所述终端，以使所述下级供应商对应的终端在接收到所述新的区块时，采用预设的公钥对所述新的区块的区块体中的签名信息进 行验证，并在验证成功后，获取并更新所述区块体中的电子账簿信息。
  4. 如权利要求1所述的基于区块链的供应链支付方法，其特征在于，在所述若接收到上级供应商发送的支付请求，则获取所述支付请求中包含的上级供应商信息、下级供应商信息和实际支付金额M之后，并且在所述对所述上级供应商的电子支付凭证进行拆分，得到金额为N-M的第一电子支付凭证和金额为M的第二电子支付凭证之前，所述基于区块链的供应链支付方法还包括：
    若所述实际支付金额的货币类型与所述电子支付凭证的默认货币类型不同，则获取所述实际支付金额的货币类型和与所述电子支付凭证的默认货币之间的转换汇率；
    按照所述转换汇率，根据所述实际支付金额生成与所述实际支付金额价值相同的默认货币金额，并将所述默认货币金额作为转换后的实际支付金额M。
  5. 一种基于区块链的供应链收款方法，其特征在于，所述基于区块链的供应链收款方法包括：
    若检测到下级供应商成功接收上级供应商发送的第二电子支付凭证，则判断所述第二电子支付凭证中的可支配金额与所述实际支付金额是否相等；
    若所述第二电子支付凭证中的可支配金额与所述实际支付金额相等，则确认收款成功，并向所述上级供应商发送所述下级供应商的身份认证信息，以使所述上级供应商根据所述身份认证信息对所述下级供应商进行身份认证；
    在接收到所述上级供应商发送的身份认证成功信息后，将所述第二支付凭证与所述下级供应商的电子支付凭证进行合并，并将合并后的电子支付凭证作为所述下级供应商交易后的电子支付凭证。
  6. 一种基于区块链的供应链支付装置，其特征在于，所述基于区块链的供应链支付装置包括：
    支付请求获取模块，用于若接收到上级供应商发送的支付请求，则获取所述支付请求中包含的上级供应商信息、下级供应商信息和实际支付金额M；
    真实性验证模块，用于对所述上级供应商信息和所述下级供应商信息进行真实性验证，得到验证结果；
    支配金额获取模块，用于若所述验证结果为所述上级供应商信息和所述下级供应商信息均真实，则获取所述上级供应商的电子支付凭证中的可支配金额N；
    支付凭证拆分模块，用于当所述上级供应商的电子支付凭证中的可支配金额N超过所述实际支付金额M时，对所述上级供应商的电子支付凭证进行拆分，得到可支配金额为N-M的第一电子支付凭证和可支配金额为M的第二电子支付凭证；
    支付凭证转移模块，用于通过区块链的方式，将所述第二电子支付凭证转移给所述下级供应商；
    支付检测模块，用于检测所述下级供应商是否已确认收款成功，并对所述下级供应商进行身份认证；
    支付确认模块，用于若检测到所述下级供应商已确认收款成功且所述下级供应商进行身份认证通过，则确认支付成功，并将所述第一电子支付凭证作为交易后的所述上级供应商的电子支付凭证。
  7. 如权利要求6所述的基于区块链的供应链支付装置，其特征在于，所述真实性验证模块包括：
    关联性查询单元，用于从预设的数据库中，查询是否存在所述目标企业账号，若存在所述目标企业账号，则查询所述授权用户账号是否与所述目标企业账号关联，其中，所述预设的数据库预先存储有目标企业账号、授权用户账号、目标企业账号与授权用户账号之间的关联信息，以及授权用户账号对应的授权期限和对应的授权用户信息；
    授权期限获取单元，用于若所述授权用户账号与所述目标企业账号关联，则从所述预 设的数据库中，获取所述授权用户帐号对应的授权期限；
    授权用户信息查询单元，用于若所述登录时间在所述授权期限内，则查询所述授权用户帐号相对应的授权用户信息，其中，所述授权用户信息包括手机号码和注册生物特征；
    验证码验证单元，用于向所述手机号码对应的手机终端发送身份验证码，并接收所述手机终端返回的登录验证码，若所述身份验证码与所述登录验证码一致，则确认验证码验证成功；
    生物验证单元，用于获取所述上级供应商和所述下级供应商通过客户端上传的待验证生物特征，并计算所述待验证生物特征与所述注册生物特征的相似度值，若所述相似度值不小于预设阈值，则确认生物验证成功；
    验证结果确认单元，用于若所述验证码验证与所述生物验证均成功，则确认所述验证结果为所述上级供应商信息和所述下级供应商信息均真实。
  8. 如权利要求6所述的基于区块链的供应链支付装置，其特征在于，所述支付凭证转移模块包括：
    账簿生成单元，用于在检测到产生电子支付凭证转移请求时，生成电子账簿信息，其中，所述电子账簿信息包括支付方、收款方和交易金额，所述支付方为所述上级供应商，所述收款方为所述下级供应商，所述交易金额为所述第二支付凭证；
    封装单元，用于采用预设的私钥对所述电子账簿信息进行电子签名，得到签名信息，并将所述电子账簿信息和所述签名信息封装成区块体；
    区块组合单元，用于将所述区块链的上一区块的摘要信息封装成区块头，使所述区块体和所述区块头组成新的区块，将所述新的区块与所述区块链中已有的区块之间链接成新的区块链；
    区块发送单元，用于将所述新的区块发送至所述新的区块链的每个所述终端，以使所述下级供应商对应的终端在接收到所述新的区块时，采用预设的公钥对所述新的区块的区块体中的签名信息进行验证，并在验证成功后，获取并更新所述区块体中的电子账簿信息。
  9. 如权利要求6所述的基于区块链的供应链支付装置，其特征在于，所述支付凭证转移模块包括：
    账簿生成单元，用于在检测到产生电子支付凭证转移请求时，生成电子账簿信息，其中，所述电子账簿信息包括支付方、收款方和交易金额，所述支付方为所述上级供应商，所述收款方为所述下级供应商，所述交易金额为所述第二支付凭证；
    封装单元，用于采用预设的私钥对所述电子账簿信息进行电子签名，得到签名信息，并将所述电子账簿信息和所述签名信息封装成区块体；
    组合单元，用于将所述区块链的上一区块的摘要信息封装成区块头，使所述区块体和所述区块头组成新的区块，将所述新的区块与所述区块链中已有的区块之间链接成新的区块链；
    发送单元，用于将所述新的区块发送至所述新的区块链的每个所述终端，以使所述下级供应商对应的终端在接收到所述新的区块时，采用预设的公钥对所述新的区块的区块体中的签名信息进行验证，并在验证成功后，获取并更新所述区块体中的电子账簿信息。
  10. 一种基于区块链的供应链收款装置，其特征在于，所述基于区块链的供应链收款装置包括：
    支配金额判断模块，用于若检测到下级供应商成功接收上级供应商发送的第二电子支付凭证，则判断所述第二电子支付凭证中的可支配金额与所述实际支付金额是否相等；
    认证信息发送模块，用于若所述第二电子支付凭证中的可支配金额与所述实际支付金额相等，则确认收款成功，并向所述上级供应商发送所述下级供应商的身份认证信息，以使所述上级供应商根据所述身份认证信息对所述下级供应商进行身份认证；
    支付凭证合并模块，用于在接收到所述上级供应商发送的身份认证成功信息后，将所 述第二支付凭证与所述下级供应商的电子支付凭证进行合并，并将合并后的电子支付凭证作为所述下级供应商交易后的电子支付凭证。
  11. 一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机可读指令，其特征在于，所述处理器执行所述计算机可读指令时实现基于区块链的供应链支付方法的如下步骤：
    若接收到上级供应商发送的支付请求，则获取所述支付请求中包含的上级供应商信息、下级供应商信息和实际支付金额M；
    对所述上级供应商信息和所述下级供应商信息进行真实性验证，得到验证结果；
    若所述验证结果为所述上级供应商信息和所述下级供应商信息均真实，则获取所述上级供应商的电子支付凭证中的可支配金额N；
    当所述上级供应商的电子支付凭证中的可支配金额N超过所述实际支付金额M时，对所述上级供应商的电子支付凭证进行拆分，得到可支配金额为N-M的第一电子支付凭证和可支配金额为M的第二电子支付凭证；
    通过区块链的方式，将所述第二电子支付凭证转移给所述下级供应商；
    检测所述下级供应商是否已确认收款成功，并对所述下级供应商进行身份认证；
    若检测到所述下级供应商已确认收款成功且所述下级供应商进行身份认证通过，则确认支付成功，并将所述第一电子支付凭证作为交易后的所述上级供应商的电子支付凭证。
  12. 如权利要求11所述的计算机设备，其特征在于，所述上级供应商信息和所述下级供应商信息均包括目标企业账号、授权用户账号和登录时间，所述对所述上级供应商信息和所述下级供应商信息进行真实性验证，得到验证结果包括：
    从预设的数据库中，查询是否存在所述目标企业账号，若存在所述目标企业账号，则查询所述授权用户账号是否与所述目标企业账号关联，其中，所述预设的数据库预先存储有目标企业账号、授权用户账号、目标企业账号与授权用户账号之间的关联信息，以及授权用户账号对应的授权期限和对应的授权用户信息；
    若所述授权用户账号与所述目标企业账号关联，则从所述预设的数据库中，获取所述授权用户帐号对应的授权期限；
    若所述登录时间在所述授权期限内，则查询所述授权用户帐号相对应的授权用户信息，其中，所述授权用户信息包括手机号码和注册生物特征；
    向所述手机号码对应的手机终端发送身份验证码，并接收所述手机终端返回的登录验证码，若所述身份验证码与所述登录验证码一致，则确认验证码验证成功；
    获取所述上级供应商和所述下级供应商通过客户端上传的待验证生物特征，并计算所述待验证生物特征与所述注册生物特征的相似度值，若所述相似度值不小于预设阈值，则确认生物验证成功；
    若所述验证码验证与所述生物验证均成功，则确认所述验证结果为所述上级供应商信息和所述下级供应商信息均真实。
  13. 如权利要求11所述的计算机设备，其特征在于，所述通过区块链的方式，将所述第二电子支付凭证转移给所述下级供应商包括：
    在检测到产生电子支付凭证转移请求时，生成电子账簿信息，其中，所述电子账簿信息包括支付方、收款方和交易金额，所述支付方为所述上级供应商，所述收款方为所述下级供应商，所述交易金额为所述第二支付凭证；
    采用预设的私钥对所述电子账簿信息进行电子签名，得到签名信息，并将所述电子账簿信息和所述签名信息封装成区块体；
    将所述区块链的上一区块的摘要信息封装成区块头，使所述区块体和所述区块头组成新的区块，将所述新的区块与所述区块链中已有的区块之间链接成新的区块链；
    将所述新的区块发送至所述新的区块链的每个所述终端，以使所述下级供应商对应的 终端在接收到所述新的区块时，采用预设的公钥对所述新的区块的区块体中的签名信息进行验证，并在验证成功后，获取并更新所述区块体中的电子账簿信息。
  14. 如权利要求11所述的计算机设备，其特征在于，在所述若接收到上级供应商发送的支付请求，则获取所述支付请求中包含的上级供应商信息、下级供应商信息和实际支付金额M之后，并且在所述对所述上级供应商的电子支付凭证进行拆分，得到金额为N-M的第一电子支付凭证和金额为M的第二电子支付凭证之前，所述处理器执行所述计算机可读指令时还包括实现如下步骤：
    若所述实际支付金额的货币类型与所述电子支付凭证的默认货币类型不同，则获取所述实际支付金额的货币类型和与所述电子支付凭证的默认货币之间的转换汇率；
    按照所述转换汇率，根据所述实际支付金额生成与所述实际支付金额价值相同的默认货币金额，并将所述默认货币金额作为转换后的实际支付金额M。
  15. 一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机可读指令，其特征在于，所述处理器执行所述计算机可读指令时实现基于区块链的供应链收款方法的如下步骤：
    若检测到下级供应商成功接收上级供应商发送的第二电子支付凭证，则判断所述第二电子支付凭证中的可支配金额与所述实际支付金额是否相等；
    若所述第二电子支付凭证中的可支配金额与所述实际支付金额相等，则确认收款成功，并向所述上级供应商发送所述下级供应商的身份认证信息，以使所述上级供应商根据所述身份认证信息对所述下级供应商进行身份认证；
    在接收到所述上级供应商发送的身份认证成功信息后，将所述第二支付凭证与所述下级供应商的电子支付凭证进行合并，并将合并后的电子支付凭证作为所述下级供应商交易后的电子支付凭证。
  16. 一个或多个存储有计算机可读指令的非易失性可读存储介质，其特征在于，所述计算机可读指令被一个或多个处理器执行时，使得所述一个或多个处理器执行基于区块链的供应链支付方法的如下步骤：
    若接收到上级供应商发送的支付请求，则获取所述支付请求中包含的上级供应商信息、下级供应商信息和实际支付金额M；
    对所述上级供应商信息和所述下级供应商信息进行真实性验证，得到验证结果；
    若所述验证结果为所述上级供应商信息和所述下级供应商信息均真实，则获取所述上级供应商的电子支付凭证中的可支配金额N；
    当所述上级供应商的电子支付凭证中的可支配金额N超过所述实际支付金额M时，对所述上级供应商的电子支付凭证进行拆分，得到可支配金额为N-M的第一电子支付凭证和可支配金额为M的第二电子支付凭证；
    通过区块链的方式，将所述第二电子支付凭证转移给所述下级供应商；
    检测所述下级供应商是否已确认收款成功，并对所述下级供应商进行身份认证；
    若检测到所述下级供应商已确认收款成功且所述下级供应商进行身份认证通过，则确认支付成功，并将所述第一电子支付凭证作为交易后的所述上级供应商的电子支付凭证。
  17. 如权利要求16所述的非易失性可读存储介质，其特征在于，所述上级供应商信息和所述下级供应商信息均包括目标企业账号、授权用户账号和登录时间，所述对所述上级供应商信息和所述下级供应商信息进行真实性验证，得到验证结果包括：
    从预设的数据库中，查询是否存在所述目标企业账号，若存在所述目标企业账号，则查询所述授权用户账号是否与所述目标企业账号关联，其中，所述预设的数据库预先存储有目标企业账号、授权用户账号、目标企业账号与授权用户账号之间的关联信息，以及授权用户账号对应的授权期限和对应的授权用户信息；
    若所述授权用户账号与所述目标企业账号关联，则从所述预设的数据库中，获取所述 授权用户帐号对应的授权期限；
    若所述登录时间在所述授权期限内，则查询所述授权用户帐号相对应的授权用户信息，其中，所述授权用户信息包括手机号码和注册生物特征；
    向所述手机号码对应的手机终端发送身份验证码，并接收所述手机终端返回的登录验证码，若所述身份验证码与所述登录验证码一致，则确认验证码验证成功；
    获取所述上级供应商和所述下级供应商通过客户端上传的待验证生物特征，并计算所述待验证生物特征与所述注册生物特征的相似度值，若所述相似度值不小于预设阈值，则确认生物验证成功；
    若所述验证码验证与所述生物验证均成功，则确认所述验证结果为所述上级供应商信息和所述下级供应商信息均真实。
  18. 如权利要求16所述的非易失性可读存储介质，其特征在于，所述通过区块链的方式，将所述第二电子支付凭证转移给所述下级供应商包括：
    在检测到产生电子支付凭证转移请求时，生成电子账簿信息，其中，所述电子账簿信息包括支付方、收款方和交易金额，所述支付方为所述上级供应商，所述收款方为所述下级供应商，所述交易金额为所述第二支付凭证；
    采用预设的私钥对所述电子账簿信息进行电子签名，得到签名信息，并将所述电子账簿信息和所述签名信息封装成区块体；
    将所述区块链的上一区块的摘要信息封装成区块头，使所述区块体和所述区块头组成新的区块，将所述新的区块与所述区块链中已有的区块之间链接成新的区块链；
    将所述新的区块发送至所述新的区块链的每个所述终端，以使所述下级供应商对应的终端在接收到所述新的区块时，采用预设的公钥对所述新的区块的区块体中的签名信息进行验证，并在验证成功后，获取并更新所述区块体中的电子账簿信息。
  19. 如权利要求16所述的非易失性可读存储介质，其特征在于，在所述若接收到上级供应商发送的支付请求，则获取所述支付请求中包含的上级供应商信息、下级供应商信息和实际支付金额M之后，并且在所述对所述上级供应商的电子支付凭证进行拆分，得到金额为N-M的第一电子支付凭证和金额为M的第二电子支付凭证之前，所述计算机可读指令被一个或多个处理器执行时，使得所述一个或多个处理器还执行如下步骤：
    若所述实际支付金额的货币类型与所述电子支付凭证的默认货币类型不同，则获取所述实际支付金额的货币类型和与所述电子支付凭证的默认货币之间的转换汇率；
    按照所述转换汇率，根据所述实际支付金额生成与所述实际支付金额价值相同的默认货币金额，并将所述默认货币金额作为转换后的实际支付金额M。
  20. 一个或多个存储有计算机可读指令的非易失性可读存储介质，其特征在于，所述计算机可读指令被一个或多个处理器执行时，使得所述一个或多个处理器执行基于区块链的供应链收款方法的如下步骤：
    若检测到下级供应商成功接收上级供应商发送的第二电子支付凭证，则判断所述第二电子支付凭证中的可支配金额与所述实际支付金额是否相等；
    若所述第二电子支付凭证中的可支配金额与所述实际支付金额相等，则确认收款成功，并向所述上级供应商发送所述下级供应商的身份认证信息，以使所述上级供应商根据所述身份认证信息对所述下级供应商进行身份认证；
    在接收到所述上级供应商发送的身份认证成功信息后，将所述第二支付凭证与所述下级供应商的电子支付凭证进行合并，并将合并后的电子支付凭证作为所述下级供应商交易后的电子支付凭证。
PCT/CN2018/122730 2018-10-12 2018-12-21 基于区块链的供应链支付方法、收款方法、装置、设备及介质 Ceased WO2020073491A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811191339.9 2018-10-12
CN201811191339.9A CN109544152A (zh) 2018-10-12 2018-10-12 基于区块链的供应链支付方法、收款方法、装置、设备及介质

Publications (1)

Publication Number Publication Date
WO2020073491A1 true WO2020073491A1 (zh) 2020-04-16

Family

ID=65843866

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/122730 Ceased WO2020073491A1 (zh) 2018-10-12 2018-12-21 基于区块链的供应链支付方法、收款方法、装置、设备及介质

Country Status (2)

Country Link
CN (1) CN109544152A (zh)
WO (1) WO2020073491A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115422192A (zh) * 2022-08-31 2022-12-02 中国工商银行股份有限公司 基于交易的数据处理方法、装置、设备及存储介质

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109978683B (zh) * 2019-04-01 2020-03-20 比亚迪股份有限公司 供应链管理方法、系统、存储介质和电子设备
CA3061266A1 (en) 2019-04-08 2019-06-27 Alibaba Group Holding Limited Transferring digital tickets based on blockchain networks
CN110070443B (zh) * 2019-04-23 2023-07-11 深圳前海微众银行股份有限公司 一种基于区块链的票据处理方法及装置
CN110503435B (zh) * 2019-07-31 2023-10-27 创新先进技术有限公司 基于区块链的交易预警方法、装置及设备
CN110675146A (zh) * 2019-08-30 2020-01-10 深圳壹账通智能科技有限公司 电子凭证交易记录的处理方法、介质及计算机设备
CN110782352A (zh) * 2019-10-31 2020-02-11 中通服创发科技有限责任公司 一种基于智能合约的可分割数字资产交易方法及装置
CN110992034A (zh) * 2019-12-13 2020-04-10 深圳市网心科技有限公司 基于区块链的供应链交易隐私保护系统、方法及相关设备
CN111539712A (zh) * 2020-05-18 2020-08-14 北京俩撇科技有限公司 一种基于区块链的下单、结账方法及装置
CN113706087A (zh) * 2020-05-22 2021-11-26 浙江建连智信科技有限公司 基于区块链的项目管理方法及装置、电子设备
CN112132568A (zh) * 2020-08-27 2020-12-25 绿瘦健康产业集团有限公司 一种预付款支付处理方法、装置、介质及终端设备
CN112232813B (zh) * 2020-10-12 2024-09-24 国网上海市电力公司 基于区块链的可再生能源电力消纳凭证管理方法及装置
CN112561502B (zh) * 2020-12-07 2025-01-07 池州市贵鸿信息技术有限公司 一种Jmatrix通用第三方支付处理系统及方法
CN113052599B (zh) 2021-03-31 2024-05-28 中国人民银行数字货币研究所 交易凭证的生成、验证及存储方法、装置、设备和系统
CN115705601A (zh) * 2021-08-06 2023-02-17 财付通支付科技有限公司 数据处理方法、装置、计算机设备及存储介质
CN113837476B (zh) * 2021-09-27 2024-05-28 北京金山云网络技术有限公司 一种产品交付供应链预测方法、装置、电子设备及计算机可读存储介质
CN116470928A (zh) * 2022-01-12 2023-07-21 瑞昱半导体股份有限公司 可验证供应商信息的无线通信装置与无线通信方法
CN115131019B (zh) * 2022-07-06 2025-09-02 先进新星技术(新加坡)控股有限公司 基于区块链的条件支付数据处理系统、各相关节点及方法
CN117611191B (zh) * 2023-11-27 2024-06-21 哈尔滨工程大学三亚南海创新发展基地 一种产业链的生成方法、系统、计算机设备和存储介质
CN117474534B (zh) * 2023-12-26 2024-03-19 成都天府通数字科技有限公司 一种条件支付的管理系统
CN120851872A (zh) * 2025-07-23 2025-10-28 金网络(北京)数字科技有限公司 一种基于人工智能和区块链的供应链支付系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105303495A (zh) * 2015-11-10 2016-02-03 成都卡恩特医疗科技有限公司 一种基于二维码和云服务的医疗信息管理系统及方法
CN106408279A (zh) * 2016-09-23 2017-02-15 詹博凯 一种去中心化储值凭证的管理方法和系统
CN107437288A (zh) * 2016-05-25 2017-12-05 广西大学 一种新型智能公交投币找零机

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7082412B1 (en) * 1998-11-23 2006-07-25 Enet 30, Inc. Electronic factoring
CN106910066A (zh) * 2017-01-22 2017-06-30 武汉慧通云信息科技有限公司 一种基于区块链技术的支付加密存储系统及方法
CN107609866B (zh) * 2017-09-13 2020-10-30 中国科学院大学 基于虚拟货币的电子支付、电子收款方法及装置
CN108335103B (zh) * 2017-12-28 2021-06-11 中国人民银行数字货币研究所 一种基于数字货币的扣款方法和系统
CN108229981A (zh) * 2018-01-29 2018-06-29 杭州云象网络技术有限公司 一种基于区块链的供应链金融防伪溯源方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105303495A (zh) * 2015-11-10 2016-02-03 成都卡恩特医疗科技有限公司 一种基于二维码和云服务的医疗信息管理系统及方法
CN107437288A (zh) * 2016-05-25 2017-12-05 广西大学 一种新型智能公交投币找零机
CN106408279A (zh) * 2016-09-23 2017-02-15 詹博凯 一种去中心化储值凭证的管理方法和系统

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115422192A (zh) * 2022-08-31 2022-12-02 中国工商银行股份有限公司 基于交易的数据处理方法、装置、设备及存储介质

Also Published As

Publication number Publication date
CN109544152A (zh) 2019-03-29

Similar Documents

Publication Publication Date Title
WO2020073491A1 (zh) 基于区块链的供应链支付方法、收款方法、装置、设备及介质
US11936788B1 (en) Distributed ledger system for identity data storage and access control
KR102054410B1 (ko) 블록체인 서비스 운영을 위해 위탁된 컴퓨팅 파워에 대한 보상을 제공하는 방법
US20220156354A1 (en) System and method for user enrollment in a secure biometric verification system
JP6046765B2 (ja) 秘密情報にアクセスするための、多重パーティ及び多重レベルの承認を可能にするシステム及び方法
CN113468602B (zh) 一种数据检验方法、装置及设备
US10789346B2 (en) Online identity scoring
CA2914956C (en) System and method for encryption
US12301581B2 (en) Systems and methods for enhanced authorization messages
CN103839157A (zh) 一种电子支付方法、装置及系统
US20210217024A1 (en) System and Method of Consolidating Identity Services
CN111144895B (zh) 一种数据处理方法、装置与系统
KR102333811B1 (ko) 블록체인 기반의 카드 결제 처리 시스템 및 방법
CN113269649B (zh) 一种数字货币追踪的系统和方法
US20190257033A1 (en) System and method for a financial transaction system having a secure biometric verification system
CN111669404A (zh) 一种数字证书安装的验证方法及装置
CN107633402A (zh) 一种用于聚合认证的方法及其系统
US12028458B2 (en) Systems and methods for user identity
CN115471227A (zh) 一种数字货币交易方法、装置、电子设备和可读存储介质
US11044250B2 (en) Biometric one touch system
KR102376783B1 (ko) 블록체인 기반의 거래내역 확인 시스템
CN119515406A (zh) 基于笔迹身份特征的企业验证系统、方法、设备及存储介质
CN111275506A (zh) 一种开具票据的方法以及区块链节点设备
CN111681009A (zh) 多平台集中认证授权系统及方法、认证授权及服务装置
CN109934009A (zh) 一种个人信息数据查询交互授权方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18936404

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 06/08/2021)

122 Ep: pct application non-entry in european phase

Ref document number: 18936404

Country of ref document: EP

Kind code of ref document: A1