WO2021204042A1 - 机构识别编号的注册 - Google Patents

机构识别编号的注册 Download PDF

Info

Publication number
WO2021204042A1
WO2021204042A1 PCT/CN2021/084319 CN2021084319W WO2021204042A1 WO 2021204042 A1 WO2021204042 A1 WO 2021204042A1 CN 2021084319 W CN2021084319 W CN 2021084319W WO 2021204042 A1 WO2021204042 A1 WO 2021204042A1
Authority
WO
WIPO (PCT)
Prior art keywords
institution
payment
node
information
identification number
Prior art date
Application number
PCT/CN2021/084319
Other languages
English (en)
French (fr)
Inventor
左敏
刘佳伟
杨仁慧
Original Assignee
支付宝(杭州)信息技术有限公司
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 支付宝(杭州)信息技术有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2021204042A1 publication Critical patent/WO2021204042A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G06Q20/206—Point-of-sale [POS] network systems comprising security or operator identification provisions, e.g. password entry
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management

Definitions

  • the embodiments of this specification relate to the field of information technology, and in particular to the registration of institutional identification numbers.
  • Scan code payment has been widely used currently. What followed is that there are more and more payment institutions, and more acquirers are often needed for channel access between payment institutions and merchants. As a result, in order to support multiple payment methods, merchants must connect to multiple acquirers and the cashier system needs to be able to identify payment codes of multiple payment applications. If the merchant's collection code is all-in-one, and the aggregation service provider acts as a centralized information intermediary, the problem of payment information leakage is prone to occur.
  • the purpose of the embodiments of the present application is to provide a more convenient intercommunication payment solution among multiple acquiring institutions and payment institutions.
  • the embodiments of this specification provide a method for registering an institution identification number, and a method for registering an institution identification number, which is applied to a consortium chain composed of multiple institution nodes.
  • the method includes: the institution node determines the The registered institution identification number; the institution node determines the hash value of the registration information, the registration information includes at least the identification number of the institution to be registered and the institution node identifier; the institution node uses the hash value
  • the private key of the institution node is encrypted to generate a digital signature; the institution node generates a transaction that includes the registration information, the digital signature, and the public key corresponding to the private key; the institution node broadcasts the transaction to the alliance Other institutional nodes in the chain; after the transaction is approved by consensus in the alliance chain, any other institutional node determines the institution identification number to be registered contained in the transaction as the institution identification number of the institution node
  • the any other institutional node saves the corresponding relationship between the institutional identification number of the institutional node and the institutional node identifier.
  • the embodiment of this specification provides a payment code generation method, which is applied to the payment institution node of the alliance chain, including: receiving a payment code generation request sent by a user, determining the user ID of the user, and obtaining the payment
  • the institution identification number of the institution node is used to generate payment information including the user ID and the institution identification number; a QR code including the payment information is generated, and the QR code is sent to the user so that the user can display that the payment information includes the
  • the payment code of the payment information is scanned by the merchant; wherein, the transaction including registration information, digital signature and public key generated by the payment institution node has been passed by consensus in the alliance chain and stored in the alliance chain,
  • the registration information includes at least the institution identification number and the institution node identifier of the payment institution node.
  • the embodiment of this specification also provides another payment code generation method.
  • the payment institution node of the application alliance chain includes: receiving the payment code generation request sent by the user, determining the user ID of the user, and obtaining the payment institution Node’s institution identification number, generating payment information containing the user ID and institution identification number; sending the payment information to the user so that the user can generate a payment code containing the payment information, and display the payment information containing the payment
  • the payment code of the information is scanned by the merchant.
  • the transaction including registration information, digital signature and public key generated by the payment institution node has been approved by consensus in the consortium chain and stored in the consortium chain, and the registration information includes at least the payment The organization identification number of the organization node and the organization node ID.
  • the embodiment of this specification provides a payment method applied to the acquiring institution node of the alliance chain, including: receiving a transaction order containing an institution identification number sent by a merchant, wherein the institution identification in the transaction order The serial number is obtained by the merchant scanning the payment code displayed by the user; obtaining the institution identification number contained in the transaction order; querying and obtaining the payment institution node identification corresponding to the institution identification number; forwarding the transaction order to the The payment institution node identifies the corresponding payment institution node, so that the payment institution node makes payment according to the transaction order.
  • the transaction including registration information, digital signature and public key generated by the payment institution node has been approved by consensus in the consortium chain and stored in the consortium chain, and the registration information includes at least the payment The organization identification number of the organization node and the organization node ID.
  • the embodiment of this specification provides a trusted collection code generation method, which is applied to the acquiring institution node of the alliance chain, including: determining the merchant search identifier of the merchant and the institution identification number of the acquiring institution node, and generating The merchant retrieves the initial information of the identification and the institution identification number; encrypts the initial information using the private key of the acquiring institution node to obtain a digital signature, and generates a trusted receipt containing the initial information and the digital signature Payment information; generate a trusted payment code containing the trusted payment information, and send it to the merchant, so that the merchant can display the trusted payment code for the user to scan.
  • the transaction including registration information, digital signature and public key generated by the acquirer node has been approved by consensus in the consortium chain and stored in the consortium chain, and the registration information includes at least the The institution identification number and the institution node ID of the acquiring institution node.
  • the embodiments of this specification provide a payment method based on the aforementioned trusted payment code, including: receiving trusted payment information sent by a user, wherein the trusted payment information is the payment method displayed by the user by scanning the merchant. Obtained by receiving the payment code, the trusted payment information includes initial information and a digital signature to the initial information, and the initial information includes the merchant search identifier and the institution identification number of the acquirer node; and obtains the The institution identification number of the acquiring institution node included in the trusted collection information; the acquiring institution node identification and public key corresponding to the institution identification number are obtained by querying, and comparing the trustworthy collection information with the public key according to the public key After the verification is passed, the merchant search identifier is sent to the acquirer node, so that the acquirer node can determine the corresponding merchant information according to the merchant search identifier; receive the acquirer The merchant information returned by the institution sends the merchant information to the user so as to receive the payment request containing the merchant information generated by the user; and perform payment according to the payment
  • the embodiment of this specification also provides a registration system for an institution identification number, which is applied to a consortium chain composed of multiple institution nodes.
  • the institution node determines the institution identification to be registered. Number; the institution node determines the hash value of the registration information, the registration information includes at least the identification number of the institution to be registered and the identity of the institution node; the institution node uses the private of the institution node for the hash value
  • the key is encrypted to generate a digital signature; the institution node generates a transaction that includes the registration information, the digital signature, and the public key corresponding to the private key; the institution node broadcasts the transaction to other parties in the consortium chain Institutional node; after the transaction is approved by consensus in the alliance chain, any other institution node determines the institution identification number to be registered contained in the transaction as the institution identification number of the institution node; One other institution node, storing the corresponding relationship between the institution identification number of the institution node and the institution node identification.
  • the embodiment of this specification also provides a payment code generation device, which is applied to the payment institution node of the alliance chain, and includes: a receiving module, which receives the payment code generation request sent by the user, and determines the user’s User identification; payment information generation module, which obtains the institution identification number of the payment institution node, and generates payment information containing the user identification and institution identification number; payment code generation module, which generates a QR code containing the payment information; sending The module sends the two-dimensional code to the user so that the user can display the payment code containing the payment information for the merchant to scan.
  • the transaction including registration information, digital signature and public key generated by the payment institution node has been approved by consensus in the consortium chain and stored in the consortium chain, and the registration information includes at least the payment The organization identification number of the organization node and the organization node ID.
  • the embodiment of this specification also provides another payment code generation device.
  • the payment institution node of the application alliance chain includes: a receiving module, which receives the payment code generation request sent by the user, and determines the user ID of the user; payment information A generating module, which obtains the institution identification number of the payment institution node, and generates payment information including the user identification and the institution identification number; a sending module, which sends the payment information to the user, so that the user generates the payment information including the payment The payment code of the information, and display the payment code containing the payment information to the merchant to scan; wherein, the transaction including registration information, digital signature and public key generated by the payment institution node has been agreed in the alliance chain Passed and stored in the alliance chain, the registration information includes at least the institution identification number and the institution node identifier of the payment institution node.
  • the embodiment of the specification also provides a payment device, which is applied to the acquiring institution node of the alliance chain, and includes: a receiving module that receives a transaction order containing an institution identification number sent by a merchant, wherein The institution identification number in the transaction order is obtained by the merchant scanning the payment code displayed by the user; the acquisition module obtains the institution identification number contained in the transaction order; the query module queries and obtains the payment corresponding to the institution identification number Institution node identification; sending module, forwarding the transaction order to the payment institution node corresponding to the payment institution node identification, so that the payment institution node can pay according to the transaction order; wherein, the payment institution node generates The transaction including registration information, digital signature and public key has been approved by consensus in the alliance chain and stored in the alliance chain, and the registration information includes at least the institution identification number of the payment institution node and the institution node Logo.
  • the embodiment of this specification also provides a trusted collection code generation device, which is applied to the acquirer node of the alliance chain, and includes: a determination module that determines the merchant search identifier of the merchant and the acquirer The institution identification number of the institution node generates initial information including the merchant search identifier and the institution identification number; the signature module encrypts the initial information using the private key of the acquiring institution node to obtain a digital signature, and generates The trusted payment information including the initial information and the digital signature; the generating module, which generates a trusted payment code including the trusted payment information, and sends it to the merchant, so that the merchant can display the trusted payment code to the merchant User scan.
  • a trusted collection code generation device which is applied to the acquirer node of the alliance chain, and includes: a determination module that determines the merchant search identifier of the merchant and the acquirer The institution identification number of the institution node generates initial information including the merchant search identifier and the institution identification number; the signature module encrypts the initial information using the private key of the
  • the transaction including registration information, digital signature and public key generated by the acquirer node has been approved by consensus in the consortium chain and stored in the consortium chain, and the registration information includes at least the The institution identification number and the institution node ID of the acquiring institution node.
  • the embodiment of this specification also provides a payment device, which is applied to the payment institution node of the alliance chain, and includes: a receiving module that receives trusted payment information sent by a user, wherein the trusted The payment information is obtained by the user by scanning the trusted payment code displayed by the merchant.
  • the trusted payment information includes the initial information and the digital signature of the initial information, and the initial information includes the merchant search identification and the receipt.
  • the single institution node determines the corresponding merchant information according to the merchant search identifier; the receiving module is also used to receive the merchant information returned by the acquiring institution, and the sending module is also used to send the merchant information to the The user, so as to receive a payment request containing the merchant information generated by the user; a payment module, to perform payment according to the payment request.
  • the transaction including registration information, digital signature and public key generated by the acquirer node has been approved by consensus in the consortium chain and stored in the consortium chain, and the registration information includes at least the The institution identification number and the institution node ID of
  • each payment institution node and each acquiring institution node form a consortium chain.
  • Each institution acts as a node in the consortium chain and can initiate number registration in the consortium chain. After the registration is successful, The institution identification number and routing information of the institution node are written into the alliance chain and can be verified at any time. Then, each payment institution or acquiring institution may need to generate a collection code or payment code containing the institution identification number.
  • any one of the embodiments of the present specification does not need to achieve all the above-mentioned effects.
  • Figure 1 is a schematic diagram of the system architecture involved in an embodiment of the specification
  • FIG. 2 is a schematic flowchart of a method for registering an organization identification number provided by an embodiment of this specification
  • Figure 3 is a logical schematic diagram of a transaction provided by an embodiment of the specification.
  • FIG. 4 is a schematic flowchart of a method for generating a payment code provided by an embodiment of the specification
  • Figure 5 is a schematic diagram of a kind of payment information provided in an embodiment of the specification.
  • Fig. 6 is a schematic flowchart of a payment method provided by an embodiment of the specification.
  • FIG. 7 is a schematic flowchart of a method for generating a trusted payment code provided by an embodiment of this specification
  • FIG. 8 is a schematic diagram of a credible collection information provided by an embodiment of the specification.
  • FIG. 9 is a schematic flowchart of a payment method provided by an embodiment of the specification.
  • FIG. 10 is a schematic structural diagram of a payment code generating device provided by an embodiment of this specification.
  • Figure 11 is a schematic structural diagram of another payment code generating device provided by an embodiment of this specification.
  • Figure 12 is a schematic structural diagram of a payment device provided by an embodiment of this specification.
  • FIG. 13 is a schematic structural diagram of a device for generating a trusted payment code provided by an embodiment of this specification
  • Figure 14 is a schematic structural diagram of a payment device provided by an embodiment of this specification.
  • Fig. 15 is a schematic structural diagram of a device for configuring the method of the embodiment of this specification.
  • FIG. 1 is a schematic diagram of the system architecture involved in an embodiment of this specification.
  • Multiple institutional nodes form a consortium chain, and the status of each institutional node is equal.
  • These nodes form a secure P2P peer-to-peer communication network in the form of an overlay on the public network or private network to ensure that the data on the chain can only be used by legal payment institutions, Access by acquirers and other authorized entities (such as regulatory agencies).
  • a distributed and non-tamperable chain database is maintained on the chain to store relevant information of each payment institution and acquirer in the alliance.
  • the embodiment of this specification provides a convenient payment solution among multiple institutions, which specifically includes the following five aspects: the registration of the institution identification number, and the payment code of the user when paying. Generation, payment based on the payment code, the credible collection code generated by the acquirer to the merchant, and the payment based on the credible collection code.
  • FIG. 2 is a schematic flowchart of a method for registering an organization identification number provided by an embodiment of this specification, which is applied to a consortium chain composed of multiple organization nodes.
  • Nodes include acquiring institution nodes or payment institution nodes, which specifically include:
  • the institution node determines the identification number of the institution to be registered, and determines the hash value of registration information, the registration information including at least the identification number of the institution to be registered and the identification of the institution node.
  • the institution node at this time may be any acquiring institution node or payment institution node in the consortium chain.
  • there is generally a one-to-one correspondence between nodes and entities that is, any institutional node can initiate a registration application in the consortium chain, and an institutional entity owns a node in the consortium chain.
  • the organization identification number can be composed of numbers, letters or any other characters. For example, "00Ali”. In other words, since there is no central management organization, in the embodiment of this specification, the organization identification number can be customized by the organization itself.
  • each organization can also make an agreement in advance, and the organization identification number can be obtained on the basis of the agreement.
  • the agreement can stipulate that the length of the organization identification number is 1 to 8 characters, and the characters that can be used include numbers and language characters of various countries.
  • An institution node can repeatedly register multiple institution identification numbers, as long as the identification numbers of the institutions (including the identification numbers of the institutions that have been registered and those to be registered) cannot be repeated.
  • the institution node After determining the identification number of the institution to be registered, the institution node can obtain its own institution node identification and generate registration information containing at least the identification number of the institution to be registered and the identification of the institution node.
  • registration information may also contain routing information such as the registration authority (for example, the access address of the payment interface or the ip address of the payment server, etc.) to determine the hash value of the registration information.
  • the registration information may also include other information, for example, it may also include other related information such as license plates, random registration factors, and so on.
  • the institution node encrypts the hash value using the private key of the institution node, generates a digital signature, and generates a transaction that includes the registration information, the digital signature, and the public key corresponding to the private key , And broadcast the transaction to other institutional nodes in the alliance chain.
  • the institutional node can use the private key in the pre-generated key pair to further encrypt, and obtain a digital signature for the aforementioned registration information. Any other user or institution can use the public key to decrypt the digital signature to obtain the hash value of the registration information, and can also calculate the hash value of the registration information in the transaction again, so that the two hash values can be compared. To verify that the registration information is complete and has not been tampered with. Asymmetric encryption of information based on key pairs is very mature, so I won’t go into details here.
  • Fig. 3 is a logical schematic diagram of the transaction provided by the embodiment of the specification.
  • other nodes After receiving the transaction, other nodes can determine the consensus node based on the consensus mechanism in the alliance chain to reach a consensus on the transaction.
  • any other institutional node determines the institution identification number to be registered contained in the transaction as the institution identification number of the institution node, and The corresponding relationship between the organization identification number of the organization node and the organization node identifier is stored.
  • the consensus is passed, which means that the transaction has not been tampered with in its propagation. Therefore, the transaction can be distributed and stored in each node in the alliance chain.
  • any institutional node can also verify the transaction. That is, the public key is used to decrypt the digital signature to obtain the hash value of the registration information, and then recalculate the hash value of the registration information in the transaction, and compare the decrypted hash value with the calculated hash value. If the two are consistent, then a follow-up consensus will be made to avoid invalid transactions being written into the alliance chain. If the two are inconsistent, no consensus will be reached.
  • any other institution node will receive the transaction.
  • any other node that receives the transaction can not only write the transaction to the alliance chain, but also maintain a cache locally. Database, determine the institution identification number to be registered contained in the transaction as the institution identification number of the institution node, and establish the corresponding relationship between the institution identification number of the registration institution node and the institution node identification, and save it locally In order to reduce the query load of the alliance chain.
  • the registration information also includes routing information
  • other institutional nodes can also determine the institutional identification number, institutional node identification, and routing information of the institutional node based on the routing information contained in the transaction that has passed the consensus.
  • the corresponding relationship is saved, so as to avoid frequent querying of routing information in the alliance chain, and only need to query locally, which is more convenient.
  • every time a new transaction consensus in the consortium chain succeeds it means that a certain organization needs to update its own information.
  • a notification mechanism for subscription can be included in the alliance chain, and update notifications are actively pushed whenever there is an update on the data on the chain (a payment/acquirer joins, withdraws, or updates routing information).
  • the consensus nodes in the alliance chain can be several institutional nodes with a pre-agreement number (for example, each institutional node is a consensus node), or it can also be a part of institutional nodes temporarily elected based on a consensus method.
  • any consensus node in the alliance chain can act as the information pusher, determine the updated information contained in the new exchange, and push the updated information to other nodes; any other node that receives the updated information , Update the locally stored correspondence according to the update information, where the update information is used to characterize the joining, exiting or routing information changes of the institutional nodes in the alliance chain.
  • the update information should include the organization node identification and update method (ie, join, exit, or change routing information).
  • any acquiring institution node and payment institution node can register an institution identification number on the chain.
  • One organization node can register multiple organization identification numbers.
  • an institution node has both acquiring and payment functions, that is, it is a payment institution and an acquiring institution, in order to facilitate the distinction, the institution node can also be regarded as two logical entities, and the two types of institution identification numbers can be registered separately They are used for payment logic and acquiring logic respectively.
  • FIG. 4 is a schematic flow diagram of a method for generating a payment code provided by the embodiment of this specification, which is applied to the payment institution nodes of the aforementioned alliance chain.
  • the method includes:
  • S401 Receive a payment code generation request sent by a user, and determine a user identity of the user.
  • S403 Obtain the institution identification number of the payment institution node, and generate payment information including the user identification and the institution identification number;
  • S405 Generate a QR code containing the payment information, and send the QR code to the user, so that the user can display the payment code containing the payment information for the merchant to scan.
  • the user Upon receipt of the payment code, the user can display it to the merchant for scanning, so that the merchant can generate a transaction order containing the payment information and forward it to its own acquiring institution.
  • the embodiment of this specification also provides another payment code generation method.
  • the payment institution node of the application alliance chain includes: receiving the payment code generation request sent by the user, determining the user ID of the user, and obtaining the payment institution Node’s institution identification number, generating payment information containing the user ID and institution identification number; sending the payment information to the user so that the user can generate a payment code containing the payment information, and display the payment information containing the payment.
  • the payment code of the information is scanned by the merchant; among them, the transaction including registration information, digital signature and public key generated by the payment institution node has been passed by consensus in the alliance chain and stored in the alliance chain, so
  • the registration information includes at least the institution identification number and the institution node identifier of the payment institution node.
  • the payment institution node can generate a payment code containing payment information on the node side and send it to the user, or only send the payment information to the user, and generate the payment information on the user side.
  • Payment code The other aspects are basically the same, and the same parts will be explained in a unified manner below.
  • the registration information includes at least the payment institution node’s The organization identification number and the organization node identifier, and the digital signature is obtained by encrypting the registration information with the private key corresponding to the public key.
  • the acquiring institution node that receives the order sent by the merchant can query to obtain the corresponding institution node identification (that is, the payment institution node identification of the payment institution) according to the institution identification number contained in the received order, and forward the order to all The payment agency.
  • the corresponding institution node identification that is, the payment institution node identification of the payment institution
  • One query method is to query the transaction containing the institution identification number from the alliance chain, and obtain the corresponding institution node ID from it; the other query method is to query the local cache database to obtain the institution identification number The corresponding institution node ID.
  • any acquiring institution can clearly know which payment institution it should forward the order to, and the forwarding basis "institution identification number" is passed by consensus on the alliance chain. Therefore, it can be based on This kind of payment code realizes fair, just and accurate interconnected payments between multiple institutional nodes.
  • the institution identification number in the payment code is generally fixed in length (for example, 18 digits), and fixed-length characters (for example, the first 2 digits) are used from the beginning to identify the third-party payment institution.
  • this approach is no longer suitable.
  • the separator can be determined among the institutions in advance, and the isolated institution identification number and the user ID can be used, so as to generate a spliced character string by sequentially splicing the institution identification number, the separator, and the user ID;
  • the spliced character string is determined as payment information.
  • FIG. 5 is a schematic diagram of a kind of payment information provided in an embodiment of the specification.
  • the separator can be a designated ASCII letter or special symbol, and the other part uses a pure numeric code string composed of 0-9; for example, if the payment code can only be pure Number, you can specify the first number "0" from the left as the separator, and require the routing/identification code registered by other payment institutions to not contain the number 0.
  • the user can apply immediately when using the payment code, or apply in advance and save it locally, and then call the display locally when needed.
  • the third aspect of the embodiment of this specification also provides a payment method, which is applied to the acquirer node of the alliance chain, as shown in FIG. 6, which is a method provided by the embodiment of this specification.
  • Schematic diagram of the flow of various payment methods including:
  • S601 Receive a transaction order containing an institution identification number sent by a merchant, where the institution identification number in the transaction order is obtained by the merchant by scanning the payment code displayed by the user.
  • the merchant can scan the user's payment code to obtain the payment information contained in the payment code, and send it to its acquirer node.
  • the method of generating the user's payment code has been specifically explained in the second aspect, so I won't repeat it here.
  • S603 Acquire the institution identification number included in the transaction order; based on the foregoing, the institution identification number here is the institution identification number of a certain payment institution.
  • the registration information includes at least the payment institution node’s Institution identification number and institution node identification.
  • the digital signature is obtained by encrypting the registration information using the private key corresponding to the public key.
  • the specific query method can be based on the corresponding relationship retained in the local cache, or query the blockchain system based on the institution identification number contained in the order, so as to obtain the payment institution node identification corresponding to the institution identification number .
  • the routing information of the payment institution can also be obtained from the alliance chain at this time.
  • S607 Forward the transaction order to a payment institution node corresponding to the payment institution node identifier, so that the payment institution node makes a payment according to the transaction order.
  • it can be forwarded according to the routing information queried in the consortium chain, or can be forwarded according to the routing information of the payment institution node usually stored in advance.
  • the user uses a payment application to instantly obtain the payment code and make a payment process as follows:
  • Step 1 The user purchases products/services at the merchant, opens the APP of the payment institution node x, and selects the payment code to pay.
  • Step 2 APP applies for payment code to node x of payment institution.
  • APP can apply for payment codes in batches from payment institutions and cache them locally for backup, but strict security measures are required to protect the security of the cached code numbers and prevent theft.
  • Step 3 The payment institution x generates a payment code according to the rules in Fig. 5 and sends it to the user’s APP.
  • Step 4 The user shows the payment code to the merchant.
  • Step 5 The merchant uses the cash register system code scanning device to read the payment information in the payment code and submit the content together with other payment-related information (such as the amount) to its own acquirer node y.
  • Step 6 Acquiring institution y parses the institution identification number in front of the separator from the payment code, and uses the query interface provided by the above-mentioned blockchain system or from the local cache database to find the payment institution x and the corresponding institution identification number. Its routing information (such as payment interface address).
  • Step 7 Acquiring institution y sends a payment request to payment institution x, including payment code (all fields), payment amount, receiving account and other required information.
  • Step 8 The payment institution x parses the payment code, derives the payment account according to the customized rules, and verifies the correctness of each field (including the random factor) in the payment code. If the verification is passed, the designated amount will be deducted from the user's payment account and transferred to the merchant's receiving account through the payment network.
  • Step 9 The payment institution x sends a payment confirmation message to the acquirer y and the user respectively.
  • Step 10 Acquirer y sends a payment confirmation message to the merchant.
  • Step 11 The user and the merchant complete the transaction.
  • Step 12 The payment institution x and the acquirer y complete the clearing and settlement.
  • the acquirer and the payment institution can be accurate Efficient docking and routing addressing, any acquirer node can accurately forward the order of the merchant under its own name, so as to make accurate and efficient payment and settlement.
  • the embodiment of this specification also provides a method for generating a trusted collection code, which is applied to the acquiring institution node of the alliance chain, as shown in FIG. Schematic diagram of the process of generating the trusted payment code of the institution identification number, including:
  • S701 Determine the merchant search identifier of the merchant and the institution identification number of the acquiring institution node, and generate initial information including the merchant search identifier and the institution identification number.
  • the merchant search identifier may be the merchant's unique identifier (for example, the enterprise's unified social credit code, the desensitized legal person's unique certificate number, etc.), or it may be the identifier given to the merchant by the acquiring institution, The acquiring institution can retrieve the merchant based on the merchant search identifier. In other words, the merchant search identifiers of the same merchant on different acquirers may be different.
  • the acquirer can generate a trusted collection code based on a temporary application of the merchant, or it can be generated in advance and sent to the merchant for use.
  • the transaction including registration information, digital signature and public key generated by the acquirer node has been approved by consensus in the alliance chain and stored in the alliance chain, and the registration information includes at least the acquirer The organization identification number of the organization node and the organization node ID.
  • S703 Encrypt the initial information using the private key of the acquirer node to obtain a digital signature, and generate trusted collection information including the initial information and the digital signature.
  • the private key here should be the same as the private key used by the acquirer in the registration agency identification code.
  • FIG. 8 is a schematic diagram of a kind of trusted payment information provided by an embodiment of this specification.
  • "+” means string splicing
  • the digital signature is a digital signature performed on all the information before the "+digital signature" in the schematic diagram by using the aforementioned private key.
  • S705 Generate a trusted payment code including the trusted payment information, and send it to the merchant, so that the merchant can display the trusted payment code for the user to scan.
  • FIG. 9 is a schematic flow diagram of a payment method based on the aforementioned trusted payment code provided by the embodiment of this specification, which is applied to the payment institution of the alliance chain
  • the nodes include:
  • S901. Receive trusted payment information sent by a user, where the trusted payment information is obtained by the user by scanning a trusted payment code displayed by a merchant, and the trusted payment information includes initial information and a reference to the The digital signature of the initial information, the initial information including the merchant search identifier and the institution identification number of the acquiring institution node;
  • S903 Acquire the institution identification number of the acquiring institution node included in the trusted collection information. For example, when there is a separator in the trusted collection information, the character string before the separator is determined as the institution identification number of the acquirer node.
  • the transaction containing registration information, digital signature and public key generated by the acquiring institution node has been approved by consensus in the consortium chain and stored in the consortium chain, and the registration
  • the information includes at least the institution identification number and the institution node identifier of the acquiring institution node.
  • S905 Obtain the acquiring institution node identification and public key corresponding to the institution identification number by querying, and verifying the digital signature in the trusted payment information according to the public key;
  • the public key is obtained by querying based on the organization identification number, or querying the local cache.
  • S909 Receive the merchant information returned by the acquirer, and send the merchant information to the user, so as to receive a payment request that includes the merchant information generated by the user;
  • S911 Execute payment according to the payment request. Specifically, it is to transfer money from the user's account to the merchant account pointed to by the merchant information.
  • the payment institution needs to verify the digital signature in the receiving code before making the payment, and then query the acquiring institution in the alliance chain based on the "institution identification number" after the verification pains. In this way, the corresponding acquiring institution can be accurately obtained, avoiding the use of the collection code by others, and realizing efficient and accurate payment and settlement by the acquiring institution.
  • the merchant information and verification confirmation information may also be sent to the user, so as to display the verification confirmation information to the user.
  • the verification confirmation information is used to characterize that the trusted two-dimensional code has passed the trusted verification of the consortium chain. For example, after the user terminal receives the verification confirmation information, it can display a "trusted" mark in the payment application to improve user experience.
  • the merchant uses the payment code provided by the acquirer and makes the payment process as follows:
  • Step 1 The user purchases the product/service at the merchant, opens the APP of the payment institution x, and selects the payment code to pay.
  • Step 2 The user uses the APP to scan the trusted payment code (static or dynamic) presented by the merchant, and submits the trusted payment information contained therein to the node x of the payment institution.
  • the trusted payment code static or dynamic
  • Step 3 The payment institution node x uses the query interface provided by the above-mentioned blockchain system or in the local cache database to find the acquiring institution y corresponding to the institution identification number field in the payment code, and the public key of the institution registered on the chain .
  • Step 4 The payment institution x verifies the digital signature in the trusted payment code using the public key found, and if the verification passes, it forwards the initial information or the trusted payment information to the acquirer y, requesting the provider's account information.
  • Step 5 The acquiring institution y finds the merchant/order information according to the merchant/order information retrieval identifier in the payment code, and returns it to the payment institution x.
  • Step 6 The payment institution x forwards the merchant/order information to the user's wallet, and attaches a mark indicating that the trusted payment code has been verified.
  • Step 7 The user APP renders the payment page for the user and displays a "trusted” mark (such as "AlipayConnect+AntChain ⁇ ", etc.) on the page.
  • a "trusted” mark such as "AlipayConnect+AntChain ⁇ ", etc.
  • Step 8 The user confirms that the payment information is correct, and initiates a payment request to payment institution x through the APP.
  • Step 9 The payment institution x and the acquirer y complete the payment through the payment network, and send payment confirmation information to the merchant and the user respectively.
  • Step 10 The user and the merchant complete the transaction.
  • Step 11 The payment institution and the acquirer perform clearing and settlement.
  • each payment institution node and each acquiring institution node form a consortium chain.
  • Each institution acts as a node in the consortium chain and can initiate self-numbered registration in the consortium chain. After the registration is successful , The institution identification number and routing information of the institution node are written into the alliance chain and can be verified at any time, and each payment institution or acquiring institution may need to generate a collection code or payment code containing the institution identification number, and other institutions
  • Open and fair autonomous management is carried out among multiple institutions, which facilitates inter-payment between multiple institutions. And, based on the blockchain support, the payment code provided by the acquirer to the merchant is digitally signed, so as to realize the credible collection code.
  • the embodiment of this specification also provides an institution identification number registration system, which is applied to a consortium chain composed of multiple institution nodes.
  • the institutions include acquiring institution nodes or payment institution nodes.
  • the institution node determines the identification number of the institution to be registered; the institution node determines the hash value of the registration information, and the registration information includes at least the identification number of the institution to be registered and the identification of the institution node; the institution node The hash value is encrypted using the private key of the institution node to generate a digital signature; the institution node generates a transaction that includes the registration information, the digital signature, and the public key corresponding to the private key;
  • the institution node broadcasts the transaction to other institution nodes in the alliance chain; after the transaction is passed by consensus in the alliance chain, any other institution node determines the identification number of the institution to be registered contained in the transaction Is the institution identification number of the institution node; the any other institution node saves the corresponding relationship between the institution identification number of the institution node and the institution no
  • the registration information also includes routing information. Accordingly, storing the corresponding relationship between the institution identification number of the institution node and the institution node identification includes: the institution identification number of the institution node, The corresponding relationship between the institutional node identifier and the routing information is stored.
  • any consensus node in the consortium chain determines the updated information contained in the new transaction, and pushes the updated information to other nodes; Any other node that receives the update information updates the locally stored corresponding relationship according to the update information, where the update information is used to characterize the joining, exiting or routing information changes of the institutional nodes in the alliance chain.
  • the embodiment of this specification also provides a payment code generation device, which is applied to the payment institution node of the alliance chain, as shown in FIG. 10, which is a payment code generation provided by the embodiment of this specification.
  • Schematic diagram of the structure of the device including:
  • the receiving module 1001 receives the payment code generation request sent by the user, and determines the user ID of the user;
  • the payment information generating module 1003 obtains the institution identification number of the payment institution node, and generates payment information including the user identification and the institution identification number;
  • the sending module 1007 sends the two-dimensional code to the user so that the user can display the payment code containing the payment information for the merchant to scan.
  • the transaction including registration information, digital signature and public key generated by the payment institution node has been approved by consensus in the consortium chain and stored in the consortium chain, and the registration information includes at least the payment The organization identification number of the organization node and the organization node ID.
  • the payment information generating module 1003 determines a separator, and sequentially splices the institution identification number, the separator, and the user ID to generate a spliced character string; and determines the spliced character string as payment information.
  • the embodiment of this specification also provides a schematic structural diagram of another payment code generation device, which is applied to the payment institution node of the alliance chain, as shown in FIG. 11, which is a payment code generation device provided by the embodiment of this specification.
  • Schematic diagram of the structure including:
  • the receiving module 1101 receives the payment code generation request sent by the user, and determines the user ID of the user;
  • the payment information generating module 1103 obtains the institution identification number of the payment institution node, and generates payment information including the user identification and the institution identification number;
  • the sending module 1105 sends the payment information to the user, so that the user generates a payment code including the payment information, and displays the payment code including the payment information for the merchant to scan.
  • the transaction including registration information, digital signature and public key generated by the payment institution node has been approved by consensus in the consortium chain and stored in the consortium chain, and the registration information includes at least the payment The organization identification number of the organization node and the organization node ID.
  • an embodiment of this specification also provides a payment device, which is applied to an acquirer node, as shown in FIG. 12, which is a schematic structural diagram of a payment device provided by an embodiment of this specification, including :
  • the obtaining module 1201 obtains the institution identification number included in the transaction order
  • the query module 1203 queries and obtains the payment institution node identification corresponding to the institution identification number
  • the sending module 1205 forwards the transaction order to the payment institution node corresponding to the payment institution node identifier, so that the payment institution node makes payment according to the transaction order.
  • the transaction including registration information, digital signature and public key generated by the payment institution node has been approved by consensus in the consortium chain and stored in the consortium chain, and the registration information includes at least the payment The organization identification number of the organization node and the organization node ID.
  • the embodiment of this specification also provides a device for generating a trusted collection code, which is applied to the node of the acquirer, as shown in FIG. 13, which is a trusted collection code provided by the embodiment of this specification.
  • the structure diagram of the collection code generating device including:
  • the determining module 1301 determines the merchant search identifier of the merchant and the institution identification number of the acquiring institution node, and generates initial information including the merchant search identifier and the institution identification number;
  • the signature module 1303 encrypts the initial information using the private key of the acquirer node to obtain a digital signature, and generates trusted collection information including the initial information and the digital signature;
  • the generating module 1305 generates a trusted payment code containing the trusted payment information, and sends it to the merchant, so that the merchant can display the trusted payment code for the user to scan.
  • the transaction including registration information, digital signature and public key generated by the acquirer node has been approved by consensus in the consortium chain and stored in the consortium chain, and the registration information includes at least the The institution identification number and the institution node ID of the acquiring institution node.
  • an embodiment of this specification also provides a payment device, which is applied to an acquirer node, as shown in FIG. 14, which is a schematic structural diagram of a payment device provided by an embodiment of this specification, including:
  • the receiving module 1401 receives the credible collection information sent by the user, where the credible collection information is obtained by the user scanning the credible collection code displayed by the merchant, and the credible collection information contains the initial information and the comparison The digital signature of the initial information, where the initial information includes the merchant search identifier and the institution identification number of the acquiring institution node;
  • the obtaining module 1403 obtains the institution identification number of the acquirer node included in the trusted collection information
  • the query module 1405 is configured to query and obtain the acquiring institution node identification, public key, and routing information corresponding to the institution identification number, and verify the digital signature in the trusted payment information according to the public key;
  • the sending module 1407 after the verification is passed, sends the merchant search identifier to the corresponding acquirer node according to the routing information, so that the acquirer node determines the corresponding merchant information according to the merchant search identifier and returns it to the payment institution
  • the receiving module 1401 is also used to receive merchant information returned by the acquiring institution, and the sending module 1407 is also used to send the merchant information to the user, so as to receive the user-generated payment request containing the merchant information;
  • the payment module 1409 executes payment according to the payment request.
  • the sending module 1407 sends the merchant information and verification confirmation information to the user, so as to display the verification confirmation information to the user, wherein the verification confirmation information is used to indicate that the trusted QR code has passed Trustworthy verification of the alliance chain.
  • the embodiment of this specification also provides a computer device, which at least includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor implements the payment shown in FIG. 4 when the program is executed. Code generation method.
  • the embodiment of the specification also provides a computer device, which at least includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor implements the payment shown in FIG. 6 when the program is executed. method.
  • the embodiments of this specification also provide a computer device, which includes at least a memory, a processor, and a computer program stored in the memory and capable of running on the processor, wherein the processor implements the program shown in FIG. 7 when the program is executed. How to generate a letter receiving code.
  • the embodiment of this specification also provides a computer device, which at least includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor implements the payment shown in FIG. 9 when the program is executed. method.
  • FIG. 15 shows a more specific hardware structure diagram of a computing device provided by an embodiment of this specification.
  • the device may include a processor 1510, a memory 1520, an input/output interface 1530, a communication interface 1540, and a bus 1550.
  • the processor 1510, the memory 1520, the input/output interface 1530, and the communication interface 1540 realize the communication connection between each other in the device through the bus 1550.
  • the processor 1510 can be implemented by a general CPU (Central Processing Unit, central processing unit), microprocessor, application specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits for execution related Program to implement the technical solutions provided in the embodiments of this specification.
  • CPU Central Processing Unit
  • microprocessor microprocessor
  • application specific integrated circuit Application Specific Integrated Circuit, ASIC
  • ASIC Application Specific Integrated Circuit
  • the memory 1520 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc.
  • the memory 1520 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the related program codes are stored in the memory 1520 and called and executed by the processor 1510.
  • the input/output interface 1530 is used to connect input/output modules to realize information input and output.
  • the input/output/module can be configured in the device as a component (not shown in the figure), or can be connected to the device to provide corresponding functions.
  • the input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and an output device may include a display, a speaker, a vibrator, an indicator light, and the like.
  • the communication interface 1540 is used to connect a communication module (not shown in the figure) to realize the communication interaction between the device and other devices.
  • the communication module can realize communication through wired means (such as USB, network cable, etc.), or through wireless means (such as mobile network, WIFI, Bluetooth, etc.).
  • the bus 1550 includes a path to transmit information between various components of the device (for example, the processor 1510, the memory 1520, the input/output interface 1530, and the communication interface 1540).
  • the above device only shows the processor 1510, the memory 1520, the input/output interface 1530, the communication interface 1540, and the bus 1550, in the specific implementation process, the device may also include the necessary equipment for normal operation. Other components.
  • the above-mentioned device may also include only the components necessary to implement the solutions of the embodiments of the present specification, and not necessarily include all the components shown in the figures.
  • the embodiment of this specification also provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the method for generating the payment code shown in FIG. 4 is implemented.
  • the embodiment of the present specification also provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the payment method shown in FIG. 6 is implemented.
  • the embodiment of this specification also provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the method for generating a trusted payment code shown in FIG. 7 is implemented.
  • the embodiment of the present specification also provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the payment method shown in FIG. 9 is implemented.
  • Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology.
  • the information can be computer-readable instructions, data structures, program modules, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • a typical implementation device is a computer.
  • the specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game control A console, a tablet computer, a wearable device, or a combination of any of these devices.

Landscapes

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

Abstract

公开了一种机构识别编号的注册方法及系统。各支付机构节点和各收单机构节点组成联盟链，每个机构都作为联盟链中的一个节点，可以向联盟链中发起自编号注册，在注册成功之后，该机构节点的机构识别编号和路由信息即写入了联盟链中，并且可以被随时验证，进而各支付机构或者收单机构可以需要生成包含机构识别编号的收款码或者付款码，其它机构在收到收款码或者付款码时即可以根据其中所包含机构识别编号向联盟链中进行查询以进行支付。

Description

机构识别编号的注册 技术领域
本说明书实施例涉及信息技术领域，尤其涉及机构识别编号的注册。
背景技术
扫码支付在当前已经应用非常广泛。随之而来的就是支付机构也越来越多，在支付机构和商户之间也经常需要更多的收单机构来进行渠道接入。这就造成商户为了支持多个支付方式，必须连接多个收单机构且收银系统需要能够识别多个支付应用的付款码。如果将商户收款码进行多合一，聚合服务提供商作为中心化的信息中介，则容易出现支付信息泄露的问题。
基于此，需要一种在多个收单机构和支付机构中更为便利的互通支付方案。
发明内容
本申请实施例的目的是提供一种在多个收单机构和支付机构中更为便利的互通支付方案。
为解决上述技术问题，本申请实施例是这样实现的。
第一方面，本说明书实施例提供一种机构识别编号的注册方法，一种机构识别编号的注册方法，应用于由多个机构节点所组成的联盟链中，所述方法包括：机构节点确定待注册的机构识别编号；所述机构节点确定注册信息的哈希值，所述注册信息至少包含所述待注册的机构识别编号和机构节点标识；所述机构节点对所述哈希值采用所述机构节点的私钥进行加密，生成数字签名；所述机构节点生成包含所述注册信息、所述数字签名和所述私钥所对应的公钥的交易；所述机构节点广播所述交易至联盟链中的其它机构节点；在所述交易在联盟链中被共识通过之后，任一其它机构节点，将所述交易中所包含的待注册的机构识别编号确定为所述机构节点的机构识别编号；所述任一其它机构节点，对所述机构节点的机构识别编号和机构节点标识的对应关系进行保存。
第二方面，本说明书实施例提供一种付款码生成方法，应用于联盟链的支付机构节点中，包括：接收用户所发送的付款码生成请求，确定所述用户的用户标识；获取所述支付机构节点的机构识别编号，生成包含所述用户标识和机构识别编号的付款信息；生 成包含所述付款信息的二维码，并发送所述二维码至所述用户，以便用户展示包含所述付款信息的付款码给商户扫描；其中，所述支付机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述支付机构节点的机构识别编号和机构节点标识。
同时，本说明书实施例还提供另一种付款码生成方法，应用联盟链的支付机构节点中，包括：接收用户所发送的付款码生成请求，确定所述用户的用户标识；获取所述支付机构节点的机构识别编号，生成包含所述用户标识和机构识别编号的付款信息；发送所述付款信息至所述用户，以便所述用户生成包含所述付款信息的付款码，并展示包含所述付款信息的付款码给商户扫描。其中，所述支付机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述支付机构节点的机构识别编号和机构节点标识。
第三方面，本说明书实施例提供一种支付方法，应用于联盟链的收单机构节点中，包括：接收商户所发送的包含机构识别编号的交易订单，其中，所述交易订单中的机构识别编号为商户扫描用户所展示的付款码所得到；获取所述交易订单中所包含的机构识别编号；查询获取所述机构识别编号所对应的支付机构节点标识；转发所述交易订单至对所述支付机构节点标识所对应的支付机构节点，以便所述支付机构节点根据所述交易订单进行支付。其中，所述支付机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述支付机构节点的机构识别编号和机构节点标识。
第四方面，本说明书实施例提供可信收款码生成方法，应用于联盟链的收单机构节点中，包括：确定商户的商户检索标识和所述收单机构节点的机构识别编号，生成包含所述商户检索标识和所述机构识别编号的初始信息；对所述初始信息采用所述收单机构节点的私钥进行加密，得到数字签名，生成包含初始信息和所述数字签名的可信收款信息；生成包含所述可信收款信息的可信收款码，并发送给商户，以便商户展示所述可信收款码给用户扫描。
其中，所述收单机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述收单机构节点的机构识别编号和机构节点标识。
第五方面，本说明书实施例提供一种基于前述可信收款码的支付方法，包括：接收用户所发送的可信收款信息，其中，可信收款信息为用户扫描商户所展示的可信收款码 所得到，所述可信收款信息中包含初始信息和对所述初始信息的数字签名，所述初始信息中包含商户检索标识和收单机构节点的机构识别编号；获取所述可信收款信息所包含的收单机构节点的机构识别编号；查询得到所述机构识别编号所对应的收单机构节点标识和公钥，根据所述公钥和对所述可信收款信息中的数字签名进行验证；在验证通过之后，发送所述商户检索标识至所述收单机构节点，以便所述收单机构节点根据所述商户检索标识确定对应的商户信息；接收所述收单机构所返回的所述商户信息，发送所述商户信息至所述用户，以便接收所述用户生成的包含所述商户信息的支付请求；根据所述支付请求执行支付。其中，所述收单机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述收单机构节点的机构识别编号和机构节点标识。
与第一方面对应的，本说明书实施例还提供一种机构识别编号的注册系统，应用于由多个机构节点所组成的联盟链中，在所述系统中，机构节点确定待注册的机构识别编号；所述机构节点确定注册信息的哈希值，所述注册信息至少包含所述待注册的机构识别编号和机构节点标识；所述机构节点对所述哈希值采用所述机构节点的私钥进行加密，生成数字签名；所述机构节点生成包含所述注册信息、所述数字签名和所述私钥所对应的公钥的交易；所述机构节点广播所述交易至联盟链中的其它机构节点；在所述交易在联盟链中被共识通过之后，任一其它机构节点，将所述交易中所包含的待注册的机构识别编号确定为所述机构节点的机构识别编号；所述任一其它机构节点，对所述机构节点的机构识别编号和机构节点标识的对应关系进行保存。
与第二方面对应的，本说明书实施例还提供一种付款码生成装置，应用于联盟链的支付机构节点中，包括：接收模块，接收用户所发送的付款码生成请求，确定所述用户的用户标识；付款信息生成模块，获取所述支付机构节点的机构识别编号，生成包含所述用户标识和机构识别编号的付款信息；付款码生成模块，生成包含所述付款信息的二维码；发送模块，发送所述二维码至所述用户，以便用户展示包含所述付款信息的付款码给商户扫描。其中，所述支付机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述支付机构节点的机构识别编号和机构节点标识。
同时，本说明书实施例还提供另一种付款码生成装置，应用联盟链的支付机构节点中，包括：接收模块，接收用户所发送的付款码生成请求，确定所述用户的用户标识；付款信息生成模块，获取所述支付机构节点的机构识别编号，生成包含所述用户标识和 机构识别编号的付款信息；发送模块，发送所述付款信息至所述用户，以便所述用户生成包含所述付款信息的付款码，并展示包含所述付款信息的付款码给商户扫描；其中，所述支付机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述支付机构节点的机构识别编号和机构节点标识。
与第三方面对应的，本说明书实施例还提供一种支付装置，应用于联盟链的收单机构节点中，包括：接收模块，接收商户所发送的包含机构识别编号的交易订单，其中，所述交易订单中的机构识别编号为商户扫描用户所展示的付款码所得到；获取模块，获取所述交易订单中所包含的机构识别编号；查询模块，查询获取所述机构识别编号所对应的支付机构节点标识；发送模块，转发所述交易订单至对所述支付机构节点标识所对应的支付机构节点，以便所述支付机构节点根据所述交易订单进行支付；其中，所述支付机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述支付机构节点的机构识别编号和机构节点标识。
与第四方面对应的，本说明书实施例还提供一种可信收款码生成装置，应用于联盟链的收单机构节点中，包括：确定模块，确定商户的商户检索标识和所述收单机构节点的机构识别编号，生成包含所述商户检索标识和所述机构识别编号的初始信息；签名模块，对所述初始信息采用所述收单机构节点的私钥进行加密，得到数字签名，生成包含初始信息和所述数字签名的可信收款信息；生成模块，生成包含所述可信收款信息的可信收款码，并发送给商户，以便商户展示所述可信收款码给用户扫描。
其中，所述收单机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述收单机构节点的机构识别编号和机构节点标识。
与第五方面对应的，本说明书实施例还提供一种一种支付装置，应用于联盟链的支付机构节点，中包括：接收模块，接收用户所发送的可信收款信息，其中，可信收款信息为用户扫描商户所展示的可信收款码所得到，所述可信收款信息中包含初始信息和对所述初始信息的数字签名，所述初始信息中包含商户检索标识和收单机构节点的机构识别编号；获取模块，获取所述可信收款信息所包含的收单机构节点的机构识别编号；查询模块，查询得到所述机构识别编号所对应的收单机构节点标识和公钥，根据所述公钥和对所述可信收款信息中的数字签名进行验证；发送模块，在验证通过之后，发送所述 商户检索标识至所述收单机构节点，以便所述收单机构节点根据所述商户检索标识确定对应的商户信息；所述接收模块还用于接收所述收单机构所返回的所述商户信息，所述发送模块还用于发送所述商户信息至所述用户，以便接收所述用户生成的包含所述商户信息的支付请求；支付模块，根据所述支付请求执行支付。其中，所述收单机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述收单机构节点的机构识别编号和机构节点标识。
通过本说明书实施例所提供的方案，各支付机构节点和各收单机构节点组成联盟链，每个机构都作为联盟链中的一个节点，可以向联盟链中发起编号注册，在注册成功之后，该机构节点的机构识别编号和路由信息即写入了联盟链中，并且可以被随时验证，进而各支付机构或者收单机构可以需要生成包含机构识别编号的收款码或者付款码，其它机构在收到收款码或者付款码时即可以根据其中所包含机构识别编号向联盟链中进行查询，在多个机构之间进行了公开公正的自治管理，便于多个机构之间的互通支付。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书实施例。
此外，本说明书实施例中的任一实施例并不需要达到上述的全部效果。
附图说明
为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
图1为本说明书实施例所涉及的系统架构示意图；
图2为本说明书实施例所提供的一种机构识别编号的注册方法的流程示意图；
图3为本说明书实施例所提供的交易的逻辑示意图；
图4为本说明书实施例所提供的一种付款码生成方法的流程示意图；
图5为本说明书实施例中所提供的一种付款信息的示意图；
图6为本说明书实施例所提供的一种支付方法的流程示意图；
图7为本说明书实施例所提供的一种可信收款码生成方法的流程示意图；
图8为本说明书实施例所提供的一种可信收款信息的示意图；
图9为本说明书实施例所提供的一种支付方法的流程示意图；
图10是本说明书实施例提供的一种付款码生成装置的结构示意图；
图11是本说明书实施例提供的另一种付款码生成装置的结构示意图；
图12是本说明书实施例提供的一种支付装置的结构示意图；
图13是本说明书实施例提供的一种可信收款码生成装置的结构示意图；
图14是本说明书实施例提供的一种支付装置的结构示意图；
图15是用于配置本说明书实施例方法的一种设备的结构示意图。
具体实施方式
为了使本领域技术人员更好地理解本说明书实施例中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于保护的范围。
如图1所示，图1为本说明书实施例所涉及的系统架构示意图。多个机构节点组成一个联盟链，各机构节点地位对等，这些节点在公网或专网上以overlay的形式构成安全的P2P对等通信网络，以确保链上数据只能由合法的支付机构、收单机构及其它被授权的实体(如监管机构)访问。链上维护一个分布式、不可篡改的链式数据库，保存联盟内每个支付机构、收单机构的相关信息。构建安全P2P网络、构建联盟区块链均有主流技术可以采用，本案不再赘述。
基于如图1所示的系统，本说明书实施例提供一种在多个机构间可以便利的互通支付的方案，具体包括如下五个方面：机构识别编号的注册，用户在支付时的付款码的生成，基于付款码的支付，收单机构给商户生成的可信收款码，基于可信收款码的支付。
对于第一方面，如图2所示，图2为本说明书实施例所提供的一种机构识别编号的注册方法的流程示意图，应用于由多个机构节点所组成的联盟链中，所述机构节点包括收单机构节点或者支付机构节点，具体包括：
S201，机构节点确定待注册的机构识别编号，确定注册信息的哈希值，所述注册信 息至少包含所述待注册的机构识别编号和机构节点标识。
此时的机构节点可以是组成联盟链中的任一收单机构节点或者支付机构节点。在实际应用中，一般即为节点和实体机构一一对应，即任一机构节点都可以向联盟链中发起注册申请，一个机构实体在联盟链拥有一个节点。
机构识别编号可以是数字、字母或者其它任意字符所组成。例如，“00Ali”。换言之，由于不存在一个中央管理机构，在本说明书实施例中，机构识别编号可以是由机构自身进行自定义的。
当然，在实际应用中，各机构也可以事先进行协议，机构识别编号可以以该协议为基础得到。例如，协议可以规定机构识别编号的长度为1至8个字符，可以采用的字符包括数字和各国的语言字符等等。
一个机构节点可以重复注册多个机构识别编号，只需各机构识别编号之间(包括已经注册的和待注册的各机构识别编号)不能重复即可。
在确定待注册的机构识别编号之后，机构节点即可以获取自身的机构节点标识，生成至少包含所述待注册的机构识别编号和机构节点标识的注册信息，当然，在实际应用中，为了便利，还可以包含有诸如注册机构的路由信息(例如支付接口访问地址或者支付服务器的ip地址等等)，进而确定注册信息的哈希值。当然，在注册信息中还可以包含有其它信息，例如，还可以包括诸如许可牌照、随机注册因子等其它相关信息。
S203，所述机构节点对所述哈希值采用所述机构节点的私钥进行加密，生成数字签名，生成包含所述注册信息、所述数字签名和所述私钥所对应的公钥的交易，并广播所述交易至联盟链中的其它机构节点。
在确定了前述注册信息的哈希值之后，机构节点即可以采用预先生成的密钥对中的私钥进行进一步加密，得到对于前述注册信息的数字签名。其他任意用户或者机构可以使用公开的公钥对数字签名进行解密得到注册信息的哈希值，以及还可以再计算一次交易中的注册信息的哈希值，从而可以比较两个哈希值的一致性来验证注册信息是否完整未被篡改。基于密钥对的非对称加密信息已经很成熟，此处不再赘述。
由于机构节点本身即为联盟链中的节点，因此，其可以生成包含包含所述注册信息、所述数字签名和所述私钥所对应的公钥的交易，并且广播至联盟链中的其它节点。如图3所示，图3为本说明书实施例所提供的交易的逻辑示意图。
其它节点在接收到该交易之后即可以基于联盟链中的共识机制，确定出共识节点， 对交易进行共识。
S205，在所述交易在联盟链中被共识通过并存储之后，任一其它机构节点，将所述交易中所包含的待注册的机构识别编号确定为所述机构节点的机构识别编号，并对所述机构节点的机构识别编号和机构节点标识的对应关系进行保存。
共识通过，即说明该交易在传播中未被篡改，因此，可以将该交易分布式的存储至联盟链中的每个节点中。
当然，在共识之前，任一机构节点还可以对所述交易进行验证。即采用公钥解密所述数字签名，得到注册信息的哈希值，并且再重新计算一遍交易中的注册信息的哈希值，并且比较解密得到的哈希值和计算得到的哈希值的一致性，若二者一直，才进行后续共识，避免无效交易被写入联盟链中。若二者不一致，则不进行共识。
基于图1中所示的架构，此时任一其它机构节点都会收到该交易，此时任一接收到交易的其它节点，除了将该交易写入联盟链，还可以在本地维持一个缓存式的数据库，将所述交易中所包含的待注册的机构识别编号确定为所述机构节点的机构识别编号，并建立所述注册机构节点的机构识别编号和机构节点标识的对应关系，保存至本地的数据库中，以减轻联盟链的查询负荷。
当注册信息中还包括路由信息时，相应的，其它机构节点还可以基于已经通过共识的交易中所包含的路由信息，对所述机构节点的机构识别编号、机构节点标识和所述路由信息的对应关系进行保存，从而避免频繁向联盟链中查询路由信息，只需在本地查询即可，更为便利。
在一种实施方式中，每当联盟链中有新的交易共识成功之后，说明有某个机构需要更新自己的信息了。此时，可以在联盟链中纳入可供订阅的通知机制，每当链上数据有更新(有支付/收单机构加入、退出或更新路由信息)时都主动推送更新通知。
联盟链中的共识节点可以是预先协议号的若干机构节点(例如，每个机构节点都是共识节点)，或者，也可以是基于共识方式所临时选举得出的部分机构节点。
具体而言，联盟链中的任一共识节点都可以作为信息的推送方，确定所述新的交易所包含的更新信息，推送所述更新信息至其它节点；任一接收到更新信息的其它节点，根据所述更新信息对本地所保存的对应关系进行更新，其中所述更新信息用于表征联盟链中的机构节点的加入、退出或者路由信息的改变。更新信息中应当包含有机构节点标识和更新方式(即加入、退出还是更改路由信息)。
在前述方式中，任一收单机构节点和支付机构节点都可以在链上进行机构识别编号的注册。一个机构节点可以对应注册多个机构识别编号。此外，如果一个机构节点如果同时具有收单和支付功能，即是支付机构又是收单机构，则为了便于区分，还可以将该机构节点视为两个逻辑实体，分别注册两类机构识别编号分别用于支付逻辑和收单逻辑。
对于已经注册了机构识别编号的支付机构节点，则可以在用户需要使用付款码时，基于已经注册的机构识别编号，分发付款码给用户。即本说明书实施例所涉及的第二方面，如图4所示，图4为本说明书实施例所提供的一种基于付款码生成方法的流程示意图，应用于前述联盟链的支付机构节点中，所述方法包括：
S401，接收用户所发送的付款码生成请求，确定所述用户的用户标识。
S403，获取所述支付机构节点的机构识别编号，生成包含所述用户标识和机构识别编号的付款信息；
S405，生成包含所述付款信息的二维码，并发送所述二维码至所述用户，以便用户展示包含所述付款信息的付款码给商户扫描。
用户收到付款码即可以展示给商户进行扫描，从而商户可以生成包含所述付款信息的交易订单，并转发至自己的收单机构。
同时，本说明书实施例还提供另一种付款码生成方法，应用联盟链的支付机构节点中，包括：接收用户所发送的付款码生成请求，确定所述用户的用户标识；获取所述支付机构节点的机构识别编号，生成包含所述用户标识和机构识别编号的付款信息；发送所述付款信息至所述用户，以便所述用户生成包含所述付款信息的付款码，并展示包含所述付款信息的付款码给商户扫描；其中，所述支付机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述支付机构节点的机构识别编号和机构节点标识。
前述的两种付款码的生成方式的区别即为，支付机构节点可以在节点端生成包含付款信息的付款码，并发送给用户，或者仅将付款信息发送给用户，在用户端生成包含付款信息的付款码。而其他方面基本相同，对于相同的部分，以下统一进行说明。
由于支付机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述支付机构节点的机构识别编号和机构节点标识，而所述数字签名是使用该公钥所对应的私钥对所述注册信息加密所得到的。
因此，收到商户发送订单的收单机构节点，可以根据接收到的订单中所包含的机构识别编号查询获取对应的机构节点标识(即该支付机构的支付机构节点标识)，并转发订单至所述支付机构。
一种查询的方式即为从联盟链中查询得到包含所述机构识别编号的交易，并从中获取对应的机构节点标识；另一种查询的方式即为从本地的缓存数据库中查询得到机构识别编号所对应的机构节点标识。
通过基于这种付款码的支付方式，任一收单机构可以明确的知道自己应当转发订单至那个支付机构，并且，转发依据“机构识别编号”是在联盟链上共识通过的，因此，可以基于这种付款码在多个机构节点之间实现公平公正准确的互联互通支付。
在当前，付款码中的机构识别编号和用户标识之间并无间隔。例如在第三方支付应用中，用户的付款码一般是固定了长度(例如，18位)，并且从开头即采用了定长的字符(例如，前2位)来标识第三方支付机构。随着支付机构和收单机构的增加，这种方式就不再适合。
此时，可以预先在各机构间确定分隔符，用隔离机构识别编号和用户标识，从而通过依序拼接所述机构识别编号、分割符和所述用户标识，生成拼接好的字符串；将所述拼接好的字符串确定为付款信息。
如图5所示，图5为本说明书实施例中所提供的一种付款信息的示意图。例如，对于使用code 128码制的条形码而言，分隔符可以是一个指定的ASCII字母或特殊符号，其它部分则采用0～9组成的纯数字码串；又例如，若付款码只能采用纯数字，则可指定左起第一个数字“0”为分隔符，并要求其它支付机构注册的路由/识别码不得包含数字0。
用户使用付款码时可以即时申请，也可以是预先申请并保存于本地，需要时再本地调用展示即可。
基于前述的付款码，本说明书实施例的第三方面，还提供一种支付方法，应用于联盟链的收单机构节点中，如图6所示，图6为本说明书实施例所提供的一种支付方法的流程示意图，包括：
S601，接收商户所发送的包含机构识别编号的交易订单，其中，所述交易订单中的机构识别编号为商户扫描用户所展示的付款码所得到。
具体而言，商户可以扫描用户的付款码，得到付款码中所包含的付款信息，并发送给自己的收单机构节点。用户的付款码的生成方式已经在第二方面进行了具体说明，此 处不再赘述。
S603，获取所述交易订单中所包含的机构识别编号；基于所述，此处的机构识别编号即为某个支付机构的机构识别编号。
由于支付机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述支付机构节点的机构识别编号和机构节点标识。所述数字签名是使用该公钥所对应的私钥对所述注册信息加密所得到的。
S605，查询获取所述机构识别编号所对应的支付机构节点标识；
具体的查询方式可以是基于本地缓存中所保留的对应关系进行查询，也可以是向区块链系统基于订单中所包含的机构识别编号进行查询，从而获取机构识别编号所对应的支付机构节点标识。
当然，若支付机构在注册机构识别编号时所提供的交易中的注册信息还包含了路由信息时，此时还可以向联盟链中获取得到该支付机构的路由信息。
S607，转发所述交易订单至对所述支付机构节点标识所对应的支付机构节点，以便所述支付机构节点根据所述交易订单进行支付。
具体而言，可以根据联盟链中查询得到的路由信息进行转发，也可以根据平时预先存储支付机构节点的路由信息进行转发。
在一种具体的实施方式中，用户采用支付应用进行即时获取付款码并进行支付的流程如下所示：
步骤1，用户在商户处购买产品/服务，打开支付机构节点x的APP选择付款码支付。
步骤2，APP向支付机构节点x申请付款码。为防交易场所网络环境恶劣导致无法支付，APP可以向支付机构批量申请付款码并缓存在本地备用，但需采用严格的安全措施保护缓存码号的安全，防止被盗用。
步骤3，支付机构x按照图5的规则生成付款码并发送给用户的APP。
步骤4，用户向商户出示付款码。
步骤5，商户用收银系统扫码设备读取付款码中的付款信息并将其内容与其它支付相关信息(如金额)一并提交给自己的收单机构节点y。
步骤6，收单机构y从付款码中解析出分隔符前面的机构识别编号，利用上述区块链系统提供的查询接口，或者从本地缓存数据库中，找到这个机构识别编号对应的支付机构x及其路由信息(如支付接口地址)。
步骤7，收单机构y向支付机构x发送支付请求，包含付款码(全部字段)、支付金额、收款账户及其它所需的信息。
步骤8，支付机构x解析付款码、根据自定义的规则推导出付款账户，并验证付款码中各个字段(包括随机因子)的正确性。如验证通过，则从用户付款账户中扣除指定的金额并通过支付网络转入商户的收款账户。
步骤9，支付机构x分别向收单机构y和用户发送支付确认消息。
步骤10，收单机构y向商户发送支付确认消息。
步骤11，用户和商户完成交易。
步骤12，支付机构x与收单机构y完成清算结算。
在存在多个收单机构节点和支付机构节点时，如果机构识别编号不是预先存储于联盟链中，则需要一个专门的管理机构来做机构识别编号的管理工作，机构自身的信息发生改变(例如编号或者路由信息的改变)都需要预先向管理机构递交资料，这就导致了效率低下，以及还带来了资料的可信度的问题。
通过基于这种付款码的支付方式，当存在多个收单机构节点和支付机构节点时，基于预先存在与于联盟链和付款码中的机构节点编号，可以实现收单机构与支付机构进行准确高效的对接和路由寻址，任一收单机构节点都可以将自己名下的商户的订单进行交易订单的准确转发，从而准确高效的支付和结算。
在第四方面，本说明书实施例还提供可信收款码生成方法，应用于联盟链的收单机构节点中，如图7所示，图7为本说明书实施例所提供的一种基于前述机构识别编号的可信收款码生成方法的流程示意图，包括：
S701，确定商户的商户检索标识和所述收单机构节点的机构识别编号，生成包含所述商户检索标识和所述机构识别编号的初始信息。
所述商户检索标识可以是商户的唯一标识(例如，企业的统一社会信用代码、经过脱敏处理的法人唯一证件号等等)，也可以是该收单机构给商户所给给定的标识，该收单机构可以基于商户检索标识检索到该商户。换言之，同一商户在不同的收单机构上的 商户检索标识可能是不同的。
同样的，收单机构可以是基于商户的临时申请来生成可信收款码，也可以是预先已经生成并发送给了商户使用。
所述收单机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述收单机构节点的机构识别编号和机构节点标识。具体的方式在第一方面中已经进行了具体说明，此处不再赘述。
S703，对所述初始信息采用所述收单机构节点的私钥进行加密，得到数字签名，生成包含初始信息和所述数字签名的可信收款信息。此处的私钥和该收单机构在注册机构识别编码时所采用的私钥应当相同。
当然，在实际应用中，可信收款信息中还可以包含其他信息，例如协议、域名等等。如图8所示，图8为本说明书实施例所提供的一种可信收款信息的示意图。在该示意图中，“+”表示字符串拼接，数字签名是利用前述的私钥对该示意图中“+数字签名”之前的全部信息进行的数字签名。
S705，生成包含所述可信收款信息的可信收款码，并发送给商户，以便商户展示所述可信收款码给用户扫描。
在生成了可信收款码之后，商户即可展示该可信收款码给用户进行扫描进行收款。即本说明书实施例所涉及的第五方面如图9所示，图9为本说明书实施例所提供的一种基于前述可信收款码的支付方法的流程示意图，应用于联盟链的支付机构节点中，包括：
S901，接收用户所发送的可信收款信息，其中，可信收款信息为用户扫描商户所展示的可信收款码所得到，所述可信收款信息中包含初始信息和对所述初始信息的数字签名，所述初始信息中包含商户检索标识和收单机构节点的机构识别编号；
S903，获取所述可信收款信息所包含的收单机构节点的机构识别编号。例如，当可信收款信息中存在分割符时，即将分隔符之前的字符串确定为收单机构节点的机构识别编号。
如第一方面所述，所述收单机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述收单机构节点的机构识别编号和机构节点标识。
S905，查询得到所述机构识别编号所对应的收单机构节点标识和公钥，根据所述公钥和对所述可信收款信息中的数字签名进行验证；如前所述，可以向区块链中基于机构识别编号进行查询获取公钥，也可以是向本地缓存中进行查询。
S907，在验证通过之后，发送所述商户检索标识至所述收单机构节点，以便所述收单机构节点根据所述商户检索标识确定对应的商户信息；
S909，接收所述收单机构所返回的所述商户信息，发送所述商户信息至所述用户，以便接收所述用户生成的包含所述商户信息的支付请求；
S911，根据所述支付请求执行支付。具体而言，即为从所述用户的账户中划款至商户信息所指向的商户账户中。
基于该收款码的支付方式，支付机构在进行支付之前，需要首先对收款码中的数字签名进行验证，在验证痛过之后再基于“机构识别编号”向联盟链中进行收单机构查询，从而可以准确的获取对应的收单机构，避免了收款码被人利用，实现高效准确的支付和收单机构的结算。
进一步地，在支付机构对可信验证码中所包含的数字签名进行的验证通过之后，还可以发送所述商户信息和验证确认信息至用户，以便展示所述验证确认信息给用户，其中，所述验证确认信息用于表征所述可信二维码通过了联盟链的可信验证。例如，用户端在接收到验证确认信息之后，即可以在支付应用中展示“可信”的标记，提高用户体验。
在一种实施方式中，商户采用收单机构所提供的收款码并进行支付的流程如下所示：
步骤1，用户在商户处购买产品/服务，打开支付机构x的APP选择收款码支付。
步骤2，用户使用APP扫描商户出示的可信收款码(静态或动态)，并将其中所包含的可信收款信息提交给自己的支付机构节点x。
步骤3，支付机构节点x利用上述区块链系统提供的查询接口或者在本地缓存数据库中，找到收款码中机构识别编号字段对应的收单机构y，及该机构在链上注册的公钥。
步骤4，支付机构x利用查询到的公钥验证可信收款码中的数字签名，如果验证通过，则向收单机构y转发初始信息或者可信收款信息，请求提供商户信息。
步骤5，收单机构y根据收款码中的商户/订单信息检索标识查到商户/订单信息， 并返回给支付机构x。
步骤6，支付机构x向用户钱包转发商户/订单信息，并附上可信收款码验证通过的标记。
步骤7，用户APP为用户渲染付款页面，并在页面上显示“可信”标记(形如“AlipayConnect+AntChain√”等)。
步骤8，用户确认支付信息无误，通过APP向支付机构x发起支付请求。
步骤9，支付机构x与收单机构y通过支付网络完成支付，并分别向商户和用户发送支付确认信息。
步骤10，用户和商户完成交易。
步骤11，支付机构和收单机构进行清算结算。
通过本说明书实施例所提供的方案，各支付机构节点和各收单机构节点组成联盟链，每个机构都作为联盟链中的一个节点，可以向联盟链中发起自编号注册，在注册成功之后，该机构节点的机构识别编号和路由信息即写入了联盟链中，并且可以被随时验证，进而各支付机构或者收单机构可以需要生成包含机构识别编号的收款码或者付款码，其它机构在收到收款码或者付款码时即可以根据其中所包含机构识别编号向联盟链中进行查询，在多个机构之间进行了公开公正的自治管理，便于多个机构之间的互通支付，以及，基于区块链支持对收单机构提供给商户的付款码进行数字签名，从而实现可信收款码。
与第一方面对应的，本说明书实施例还提供一种机构识别编号的注册系统，应用于由多个机构节点所组成的联盟链中，所述机构包括收单机构节点或者支付机构节点，在所述系统中，机构节点确定待注册的机构识别编号；所述机构节点确定注册信息的哈希值，所述注册信息至少包含所述待注册的机构识别编号和机构节点标识；所述机构节点对所述哈希值采用所述机构节点的私钥进行加密，生成数字签名；所述机构节点生成包含所述注册信息、所述数字签名和所述私钥所对应的公钥的交易；所述机构节点广播所述交易至联盟链中的其它机构节点；在所述交易在联盟链中被共识通过之后，任一其它机构节点，将所述交易中所包含的待注册的机构识别编号确定为所述机构节点的机构识别编号；所述任一其它机构节点，对所述机构节点的机构识别编号和机构节点标识的对应关系进行保存。
在所述系统中，所述注册信息中还包含路由信息，相应的，对所述机构节点的 机构识别编号和机构节点标识的对应关系进行保存，包括：对所述机构节点的机构识别编号、机构节点标识和所述路由信息的对应关系进行保存。
当所述联盟链中有新的交易共识成功之后，在所述系统中，联盟链中的任一共识节点，确定所述新的交易所包含的更新信息，推送所述更新信息至其它节点；任一接收到更新信息的其它节点，根据所述更新信息对本地所保存的对应关系进行更新，其中所述更新信息用于表征联盟链中的机构节点的加入、退出或者路由信息的改变。
与第二方面对应的，本说明书实施例还提供一种付款码生成装置，应用于联盟链的支付机构节点中，如图10所示，图10是本说明书实施例提供的一种付款码生成装置的结构示意图，包括：
接收模块1001，接收用户所发送的付款码生成请求，确定所述用户的用户标识；
付款信息生成模块1003，获取所述支付机构节点的机构识别编号，生成包含所述用户标识和机构识别编号的付款信息；
付款码生成模块1005，生成包含所述付款信息的二维码；
发送模块1007，发送所述二维码至所述用户，以便用户展示包含所述付款信息的付款码给商户扫描。
其中，所述支付机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述支付机构节点的机构识别编号和机构节点标识。
进一步地，所述付款信息生成模块1003，确定分隔符，依序拼接所述机构识别编号、分割符和所述用户标识，生成拼接好的字符串；将所述拼接好的字符串确定为付款信息。
同时，本说明书实施例还提供另一种付款码生成装置的结构示意图，应用于联盟链的支付机构节点中，如图11所示，图11是本说明书实施例提供的一种付款码生成装置的结构示意图，包括：
接收模块1101，接收用户所发送的付款码生成请求，确定所述用户的用户标识；
付款信息生成模块1103，获取所述支付机构节点的机构识别编号，生成包含所述用户标识和机构识别编号的付款信息；
发送模块1105，发送所述付款信息至所述用户，以便所述用户生成包含所述付款 信息的付款码，并展示包含所述付款信息的付款码给商户扫描。
其中，所述支付机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述支付机构节点的机构识别编号和机构节点标识。
与第三方面对应的，本说明书实施例还提供一种支付装置，应用于收单机构节点中，如图12所示，图12是本说明书实施例提供的一种支付装置的结构示意图，包括：
获取模块1201，获取所述交易订单中所包含的机构识别编号；
查询模块1203，查询获取所述机构识别编号所对应的支付机构节点标识；
发送模块1205，转发所述交易订单至对所述支付机构节点标识所对应的支付机构节点，以便所述支付机构节点根据所述交易订单进行支付。
其中，所述支付机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述支付机构节点的机构识别编号和机构节点标识。
与第四方面对应的，本说明书实施例还提供一种可信收款码生成装置，应用于收单机构节点中，如图13所示，图13是本说明书实施例提供的一种可信收款码生成装置的结构示意图，包括：
确定模块1301，确定商户的商户检索标识和所述收单机构节点的机构识别编号，生成包含所述商户检索标识和所述机构识别编号的初始信息；
签名模块1303，对所述初始信息采用所述收单机构节点的私钥进行加密，得到数字签名，生成包含初始信息和所述数字签名的可信收款信息；
生成模块1305，生成包含所述可信收款信息的可信收款码，并发送给商户，以便商户展示所述可信收款码给用户扫描。
其中，所述收单机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述收单机构节点的机构识别编号和机构节点标识。
第五方面，本说明书实施例还提供一种支付装置，应用于收单机构节点中，如图14所示，图14是本说明书实施例提供的一种支付装置的结构示意图，包括：
接收模块1401，收用户所发送的可信收款信息，其中，可信收款信息为用户扫描 商户所展示的可信收款码所得到，所述可信收款信息中包含初始信息和对所述初始信息的数字签名，所述初始信息中包含商户检索标识和收单机构节点的机构识别编号；
获取模块1403，获取所述可信收款信息所包含的收单机构节点的机构识别编号；
查询模块1405，查询得到所述机构识别编号所对应的收单机构节点标识、公钥和路由信息，根据所述公钥和对所述可信收款信息中的数字签名进行验证；
发送模块1407，在验证通过之后，根据所述路由信息发送所述商户检索标识至对应的收单机构节点，以便收单机构节点但根据商户检索标识确定对应的商户信息并返回至所述支付机构；所述接收模块1401还用于接收收单机构所返回的商户信息，所述发送模块1407还用于发送所述商户信息至用户，以便接收用户生成的包含所述商户信息的支付请求；
支付模块1409，根据所述支付请求执行支付。
进一步地，所述发送模块1407，发送所述商户信息和验证确认信息至用户，以便展示所述验证确认信息给用户，其中，所述验证确认信息用于表征所述可信二维码通过了联盟链的可信验证。
本说明书实施例还提供一种计算机设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现图4所示的付款码生成方法。
本说明书实施例还提供一种计算机设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现图6所示的支付方法。
本说明书实施例还提供一种计算机设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现图7所示的可信收款码生成方法。
本说明书实施例还提供一种计算机设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现图9所示的支付方法。
图15示出了本说明书实施例所提供的一种更为具体的计算设备硬件结构示意图，该设备可以包括：处理器1510、存储器1520、输入/输出接口1530、通信接口1540和 总线1550。其中处理器1510、存储器1520、输入/输出接口1530和通信接口1540通过总线1550实现彼此之间在设备内部的通信连接。
处理器1510可采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。
存储器1520可采用ROM(Read Only Memory，只读存储器)、RAM(Random Access Memory，随机存取存储器)、静态存储设备、动态存储设备等形式实现。存储器1520可存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供技术方案时，相关程序代码保存在存储器1520中，并由处理器1510来调用执行。
输入/输出接口1530用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。
通信接口1540用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。
总线1550包括一通路，在设备的各个组件(例如处理器1510、存储器1520、输入/输出接口1530和通信接口1540)之间传输信息。
需要说明的是，尽管上述设备仅示出了处理器1510、存储器1520、输入/输出接口1530、通信接口1540以及总线1550，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。
本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现图4所示的付款码生成方法。
本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现图6所示的支付方法。
本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现图7所示的可信收款码生成方法。
本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现图9所示的支付方法。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本说明书实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本说明书实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本说明书实施例各个实施例或者实施例的某些部分所述的方法。
上述实施例阐明的系统、方法、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于方法实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的方法实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述仅是本说明书实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本说明书实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本说明书实施例的保护范围。

Claims (23)

  1. 一种机构识别编号的注册方法，应用于由多个机构节点所组成的联盟链中，所述方法包括：
    机构节点确定待注册的机构识别编号；
    所述机构节点确定注册信息的哈希值，所述注册信息至少包含所述待注册的机构识别编号和机构节点标识；
    所述机构节点对所述哈希值采用所述机构节点的私钥进行加密，生成数字签名；
    所述机构节点生成包含所述注册信息、所述数字签名和所述私钥所对应的公钥的交易；
    所述机构节点广播所述交易至联盟链中的其它机构节点；
    在所述交易在联盟链中被共识通过之后，任一其它机构节点，将所述交易中所包含的待注册的机构识别编号确定为所述机构节点的机构识别编号；
    所述任一其它机构节点，对所述机构节点的机构识别编号和机构节点标识的对应关系进行保存。
  2. 如权利要求1所述的方法，所述注册信息中还包含路由信息，
    相应的，对所述机构节点的机构识别编号和机构节点标识的对应关系进行保存，包括：
    对所述机构节点的机构识别编号、机构节点标识和所述路由信息的对应关系进行保存。
  3. 如权利要求1所述的方法，当所述联盟链中有新的交易共识成功之后，所述方法还包括：
    联盟链中的任一共识节点，确定所述新的交易所包含的更新信息，推送所述更新信息至其它节点；
    任一接收到更新信息的其它节点，根据所述更新信息对本地所保存的对应关系进行更新，其中所述更新信息用于表征联盟链中的机构节点的加入、退出或者路由信息的改变。
  4. 一种付款码生成方法，应用于联盟链的支付机构节点中，包括：
    接收用户所发送的付款码生成请求，确定所述用户的用户标识；
    获取所述支付机构节点的机构识别编号，生成包含所述用户标识和机构识别编号的付款信息；
    生成包含所述付款信息的二维码，并发送所述二维码至所述用户，以便用户展示包 含所述付款信息的付款码给商户扫描；
    其中，所述支付机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述支付机构节点的机构识别编号和机构节点标识。
  5. 如权利要求4所述的方法，生成包含所述用户标识和机构识别编号的付款信息，包括：
    确定分隔符，依序拼接所述机构识别编号、分割符和所述用户标识，生成拼接好的字符串；
    将所述拼接好的字符串确定为付款信息。
  6. 一种付款码生成方法，应用联盟链的支付机构节点中，包括：
    接收用户所发送的付款码生成请求，确定所述用户的用户标识；
    获取所述支付机构节点的机构识别编号，生成包含所述用户标识和机构识别编号的付款信息；
    发送所述付款信息至所述用户，以便所述用户生成包含所述付款信息的付款码，并展示包含所述付款信息的付款码给商户扫描；
    其中，所述支付机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述支付机构节点的机构识别编号和机构节点标识。
  7. 如权利要求6所述的方法，生成包含所述用户标识和机构识别编号的付款信息，包括：
    确定分隔符，依序拼接所述机构识别编号、分割符和所述用户标识，生成拼接好的字符串；
    将所述拼接好的字符串确定为付款信息。
  8. 一种支付方法，应用于联盟链的收单机构节点中，包括：
    接收商户所发送的包含机构识别编号的交易订单，其中，所述交易订单中的机构识别编号为商户扫描用户所展示的付款码所得到；
    获取所述交易订单中所包含的机构识别编号；
    查询获取所述机构识别编号所对应的支付机构节点标识；
    转发所述交易订单至对所述支付机构节点标识所对应的支付机构节点，以便所述支付机构节点根据所述交易订单进行支付；
    其中，所述支付机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在 所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述支付机构节点的机构识别编号和机构节点标识。
  9. 一种可信收款码生成方法，应用于联盟链的收单机构节点中，包括：
    确定商户的商户检索标识和所述收单机构节点的机构识别编号，生成包含所述商户检索标识和所述机构识别编号的初始信息；
    对所述初始信息采用所述收单机构节点的私钥进行加密，得到数字签名，生成包含初始信息和所述数字签名的可信收款信息；
    生成包含所述可信收款信息的可信收款码，并发送给商户，以便商户展示所述可信收款码给用户扫描；
    其中，所述收单机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述收单机构节点的机构识别编号和机构节点标识。
  10. 一种支付方法，应用于联盟链的支付机构节点中，包括：
    接收用户所发送的可信收款信息，其中，可信收款信息为用户扫描商户所展示的可信收款码所得到，所述可信收款信息中包含初始信息和对所述初始信息的数字签名，所述初始信息中包含商户检索标识和收单机构节点的机构识别编号；
    获取所述可信收款信息所包含的收单机构节点的机构识别编号；
    查询得到所述机构识别编号所对应的收单机构节点标识和公钥，根据所述公钥和对所述可信收款信息中的数字签名进行验证；
    在验证通过之后，发送所述商户检索标识至所述收单机构节点，以便所述收单机构节点根据所述商户检索标识确定对应的商户信息；
    接收所述收单机构所返回的所述商户信息，发送所述商户信息至所述用户，以便接收所述用户生成的包含所述商户信息的支付请求；
    根据所述支付请求执行支付；
    其中，所述收单机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述收单机构节点的机构识别编号和机构节点标识。
  11. 如权利要求10所述的方法，发送所述商户信息至用户，包括：
    发送所述商户信息和验证确认信息至用户，以便展示所述验证确认信息给所述用户，其中，所述验证确认信息用于表征所述可信二维码通过了联盟链的可信验证。
  12. 一种机构识别编号的注册系统，应用于由多个机构节点所组成的联盟链中，在 所述系统中，
    机构节点确定待注册的机构识别编号；
    所述机构节点确定注册信息的哈希值，所述注册信息至少包含所述待注册的机构识别编号和机构节点标识；
    所述机构节点对所述哈希值采用所述机构节点的私钥进行加密，生成数字签名；
    所述机构节点生成包含所述注册信息、所述数字签名和所述私钥所对应的公钥的交易；
    所述机构节点广播所述交易至联盟链中的其它机构节点；
    在所述交易在联盟链中被共识通过之后，任一其它机构节点，将所述交易中所包含的待注册的机构识别编号确定为所述机构节点的机构识别编号；
    所述任一其它机构节点，对所述机构节点的机构识别编号和机构节点标识的对应关系进行保存。
  13. 如权利要求12所述的系统，所述注册信息中还包含路由信息，
    相应的，对所述机构节点的机构识别编号和机构节点标识的对应关系进行保存，包括：对所述机构节点的机构识别编号、机构节点标识和所述路由信息的对应关系进行保存。
  14. 如权利要求12所述的系统，当所述联盟链中有新的交易共识成功之后，在所述系统中，
    联盟链中的任一共识节点，确定所述新的交易所包含的更新信息，推送所述更新信息至其它节点；
    任一接收到更新信息的其它节点，根据所述更新信息对本地所保存的对应关系进行更新，其中所述更新信息用于表征联盟链中的机构节点的加入、退出或者路由信息的改变。
  15. 一种付款码生成装置，应用于联盟链的支付机构节点中，包括：
    接收模块，接收用户所发送的付款码生成请求，确定所述用户的用户标识；
    付款信息生成模块，获取所述支付机构节点的机构识别编号，生成包含所述用户标识和机构识别编号的付款信息；
    付款码生成模块，生成包含所述付款信息的二维码；
    发送模块，发送所述二维码至所述用户，以便用户展示包含所述付款信息的付款码给商户扫描；
    其中，所述支付机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在 所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述支付机构节点的机构识别编号和机构节点标识。
  16. 如权利要求15所述的装置，所述付款信息生成模块，确定分隔符，依序拼接所述机构识别编号、分割符和所述用户标识，生成拼接好的字符串；将所述拼接好的字符串确定为付款信息。
  17. 一种付款码生成装置，应用联盟链的支付机构节点中，包括：
    接收模块，接收用户所发送的付款码生成请求，确定所述用户的用户标识；
    付款信息生成模块，获取所述支付机构节点的机构识别编号，生成包含所述用户标识和机构识别编号的付款信息；
    发送模块，发送所述付款信息至所述用户，以便所述用户生成包含所述付款信息的付款码，并展示包含所述付款信息的付款码给商户扫描；
    其中，所述支付机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述支付机构节点的机构识别编号和机构节点标识。
  18. 如权利要求17所述的装置，所述付款信息生成模块，确定分隔符，依序拼接所述机构识别编号、分割符和所述用户标识，生成拼接好的字符串；将所述拼接好的字符串确定为付款信息。
  19. 一种支付装置，应用于联盟链的收单机构节点中，包括：
    接收模块，接收商户所发送的包含机构识别编号的交易订单，其中，所述交易订单中的机构识别编号为商户扫描用户所展示的付款码所得到；
    获取模块，获取所述交易订单中所包含的机构识别编号；
    查询模块，查询获取所述机构识别编号所对应的支付机构节点标识；
    发送模块，转发所述交易订单至对所述支付机构节点标识所对应的支付机构节点，以便所述支付机构节点根据所述交易订单进行支付；
    其中，所述支付机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述支付机构节点的机构识别编号和机构节点标识。
  20. 一种可信收款码生成装置，应用于联盟链的收单机构节点中，包括：
    确定模块，确定商户的商户检索标识和所述收单机构节点的机构识别编号，生成包含所述商户检索标识和所述机构识别编号的初始信息；
    签名模块，对所述初始信息采用所述收单机构节点的私钥进行加密，得到数字签名， 生成包含初始信息和所述数字签名的可信收款信息；
    生成模块，生成包含所述可信收款信息的可信收款码，并发送给商户，以便商户展示所述可信收款码给用户扫描；
    其中，所述收单机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述收单机构节点的机构识别编号和机构节点标识。
  21. 一种支付装置，应用于联盟链的支付机构节点，中包括：
    接收模块，接收用户所发送的可信收款信息，其中，可信收款信息为用户扫描商户所展示的可信收款码所得到，所述可信收款信息中包含初始信息和对所述初始信息的数字签名，所述初始信息中包含商户检索标识和收单机构节点的机构识别编号；
    获取模块，获取所述可信收款信息所包含的收单机构节点的机构识别编号；
    查询模块，查询得到所述机构识别编号所对应的收单机构节点标识和公钥，根据所述公钥和对所述可信收款信息中的数字签名进行验证；
    发送模块，在验证通过之后，发送所述商户检索标识至所述收单机构节点，以便所述收单机构节点根据所述商户检索标识确定对应的商户信息；
    所述接收模块还用于接收所述收单机构所返回的所述商户信息，所述发送模块还用于发送所述商户信息至所述用户，以便接收所述用户生成的包含所述商户信息的支付请求；
    支付模块，根据所述支付请求执行支付；
    其中，所述收单机构节点所生成的包含注册信息、数字签名和公钥的交易，已经在所述联盟链中被共识通过并存储于所述联盟链中，所述注册信息至少包含所述收单机构节点的机构识别编号和机构节点标识。
  22. 如权利要求21所述的装置，所述发送模块，发送所述商户信息和验证确认信息至用户，以便展示所述验证确认信息给用户，其中，所述验证确认信息用于表征所述可信二维码通过了联盟链的可信验证。
  23. 一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如权利要求4至11任一项所述的方法。
PCT/CN2021/084319 2020-04-10 2021-03-31 机构识别编号的注册 WO2021204042A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010277268.5A CN111192040B (zh) 2020-04-10 2020-04-10 一种机构识别编号的注册方法及系统
CN202010277268.5 2020-04-10

Publications (1)

Publication Number Publication Date
WO2021204042A1 true WO2021204042A1 (zh) 2021-10-14

Family

ID=70708707

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/084319 WO2021204042A1 (zh) 2020-04-10 2021-03-31 机构识别编号的注册

Country Status (3)

Country Link
CN (1) CN111192040B (zh)
TW (1) TWI763392B (zh)
WO (1) WO2021204042A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111192040B (zh) * 2020-04-10 2021-02-09 支付宝(杭州)信息技术有限公司 一种机构识别编号的注册方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170243177A1 (en) * 2016-02-22 2017-08-24 Bank Of America Corporation System for routing of process authorization and settlement to a user in process data network based on specified parameters
CN108197913A (zh) * 2017-12-18 2018-06-22 深圳前海微众银行股份有限公司 基于区块链的支付方法、系统以及计算机可读存储介质
CN110458542A (zh) * 2019-08-02 2019-11-15 中国工商银行股份有限公司 基于区块链的离线支付系统及方法
CN110839029A (zh) * 2019-11-14 2020-02-25 腾讯科技（深圳）有限公司 一种微服务注册方法和装置
CN111192040A (zh) * 2020-04-10 2020-05-22 支付宝(杭州)信息技术有限公司 一种机构识别编号的注册方法及系统

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107038638A (zh) * 2017-02-24 2017-08-11 杭州象链网络技术有限公司 一种基于联盟链的股权登记交易系统构建方法
US10896418B2 (en) * 2017-12-29 2021-01-19 Ebay Inc. Secure management of data files using a blockchain
CN109191108B (zh) * 2018-08-07 2022-03-11 广东蓝蜜蜂信息技术有限公司 基于区块链的二维码聚合支付系统及其工作方法
TW202013299A (zh) * 2018-09-20 2020-04-01 美林能源科技股份有限公司 分散式能源交易系統與方法
CN109088722B (zh) * 2018-10-08 2021-10-19 深圳投时科技有限公司 区块链节点演进方法及区块链节点
CN110570179B (zh) * 2019-09-11 2023-07-28 腾讯科技（深圳）有限公司 订单显示方法、装置、设备及存储介质
CN110852734B (zh) * 2019-11-06 2021-07-02 上海景域文化传播股份有限公司 基于区块链的景区业务结算方法、系统及电子设备
CN110798483A (zh) * 2019-11-12 2020-02-14 北京芯际科技有限公司 一种基于区块链的身份认证的方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170243177A1 (en) * 2016-02-22 2017-08-24 Bank Of America Corporation System for routing of process authorization and settlement to a user in process data network based on specified parameters
CN108197913A (zh) * 2017-12-18 2018-06-22 深圳前海微众银行股份有限公司 基于区块链的支付方法、系统以及计算机可读存储介质
CN110458542A (zh) * 2019-08-02 2019-11-15 中国工商银行股份有限公司 基于区块链的离线支付系统及方法
CN110839029A (zh) * 2019-11-14 2020-02-25 腾讯科技（深圳）有限公司 一种微服务注册方法和装置
CN111192040A (zh) * 2020-04-10 2020-05-22 支付宝(杭州)信息技术有限公司 一种机构识别编号的注册方法及系统

Also Published As

Publication number Publication date
TWI763392B (zh) 2022-05-01
CN111192040A (zh) 2020-05-22
CN111192040B (zh) 2021-02-09
TW202143140A (zh) 2021-11-16

Similar Documents

Publication Publication Date Title
CN113169980B (zh) 使用区块链的交易账户数据维护系统和方法
US20200058023A1 (en) Decentralized Data Marketplace
KR101862861B1 (ko) Utxo 기반 프로토콜을 사용하여 페이먼트 게이트웨이 서비스를 제공하는 방법 및 이를 이용한 서버
US20200042999A1 (en) Method, apparatus and electronic device for blockchain transactions
US20150317626A1 (en) Secure proximity exchange of payment information between mobile wallet and point-of-sale
WO2021204273A1 (zh) 资产类型注册、交易记录验证
US20220188815A1 (en) Distributed ledger systems, methods and devices
KR20170056536A (ko) 캐리어 시스템으로부터 획득된 고객 정보를 클라이언트 디바이스로 제공하는 것
US20230095123A1 (en) Systems and Methods for Digitally Signed Contracts with Verifiable Credentials
EP4358000A1 (en) Digital currency-based payment method, platform, terminal, and payment system
US11856107B2 (en) Methods and systems for exchanging confidential information via a blockchain
CN111178840A (zh) 业务处理方法及装置、系统、电子设备、存储介质
US20220245262A1 (en) Secure information storage, transfer and computing
KR101862860B1 (ko) Utxo 기반 프로토콜에서 머클 트리 구조를 사용하여 페이먼트 게이트웨이 서비스를 제공하는 방법 및 이를 이용한 서버
WO2021204042A1 (zh) 机构识别编号的注册
CN111861462B (zh) 基于区块链的金融产品交易方法及装置
US20200242573A1 (en) Cryptographic transactions supporting real world requirements
US20230114697A1 (en) Zero-knowledge proof-based virtual cards
KR101862859B1 (ko) Utxo 기반 프로토콜을 사용하여 페이먼트 게이트웨이 서비스를 제공하는 방법 및 이를 이용한 서버
KR101862862B1 (ko) Utxo 기반 프로토콜에서 머클 트리 구조를 사용하여 페이먼트 게이트웨이 서비스를 제공하는 방법 및 이를 이용한 서버
WO2021121030A1 (zh) 一种资源转移的方法及结账终端、服务器节点
KR20230006535A (ko) 개인 정보 보호 분산 지불 수단 네트워크
US20240193594A1 (en) Method, Terminal and System for Splitting and Managing Digital Currency in Transaction
US20240089122A1 (en) Systems and methods for securing interconnecting directories
US20240171399A1 (en) Using secondary blockchain addresses to prevent malicious transfers

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: 21785660

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21785660

Country of ref document: EP

Kind code of ref document: A1