Methods and devices for binding financial attribute card numbers

Abstract

This invention discloses a method and apparatus for binding financial attribute card numbers, relating to the field of bank card processing technology and also applicable to the financial sector. The method includes: generating a first encrypted identifier based on the user's basic information and sending the first encrypted identifier to the UnionPay database; receiving search results from the UnionPay database, and if the search results indicate that at least one financial attribute card number has been found, obtaining a list of the user's financial attribute card numbers based on the search results, wherein the list of financial attribute card numbers includes at least one financial attribute card number; displaying the list of financial attribute card numbers on a user interface; receiving a financial attribute card number selection result and sending the selection result to the UnionPay database. This invention can improve the convenience for customers binding bank cards on non-bank apps.

Description

Technical Field

[0001] This invention relates to the field of bank card processing technology, and can also be used in the financial field, particularly to a method and apparatus for binding financial attribute card numbers. Background Technology

[0002] Mobile payment has become the mainstream payment method. Customers need to bind their bank cards before using any payment method. Currently, there are two main methods for binding cards: manually entering the card number and selecting and binding the card through a commercial bank's or UnionPay app or H5 page. Both methods have drawbacks, namely incomplete bank card information and inconvenience. The technical problem of the inconvenience for users to bind bank cards on non-bank apps urgently needs to be solved. Summary of the Invention

[0003] To address the problems in the prior art, embodiments of the present invention provide a method and apparatus for binding financial attribute card numbers, thereby solving the technical problem that it is not convenient for users to bind bank cards on non-bank apps in the prior art.

[0004] This invention provides a method for binding a financial attribute card number, applied to a terminal, including:

[0005] A first encrypted identifier is generated based on the user's basic information and sent to the UnionPay database. The UnionPay database then searches for the user's corresponding financial attribute card number based on the first encrypted identifier and returns the search results. The UnionPay database stores all financial attribute card numbers corresponding to the basic information. The financial attribute card number is the card number corresponding to the card created by the user when conducting business at a financial institution.

[0006] Receive the search results from the UnionPay database, and if the search results indicate that at least one financial attribute card number has been found, obtain the user's list of financial attribute card numbers based on the search results, wherein the list of financial attribute card numbers includes at least one financial attribute card number;

[0007] Display a list of financial attribute card numbers in the user interface;

[0008] The system receives the selection result of the financial attribute card number and sends it to the UnionPay database. The selection result contains the target financial attribute card number, and the UnionPay database authorizes and binds the target financial attribute card number.

[0009] Optionally, in one embodiment of the present invention, after receiving the search results from the UnionPay database, the method further includes: prompting the user to manually bind a card when the search results indicate that there is no at least one financial attribute card number in the UnionPay database; obtaining the predetermined financial attribute card number entered by the user; and sending the predetermined financial attribute card number and basic information to the UnionPay database.

[0010] Optionally, in one embodiment of the present invention, the method further includes: before generating the first encrypted identifier based on the user's basic information, the user creating a financial attribute card number includes: obtaining the basic information initially entered by the user, generating a second encrypted identifier based on the basic information, wherein the second encrypted identifier is the plaintext key generated by the first encrypted identifier and the basic information; encrypting and encoding the public key corresponding to the plaintext key using the encryption certificate provided by the UnionPay database, obtaining the ciphertext key, and sending the ciphertext key to the UnionPay database.

[0011] This invention provides a method for binding financial attribute cards, applied to the UnionPay database, including:

[0012] The receiving terminal transmits a first encrypted identifier, and performs a search based on the first encrypted identifier to obtain the search results;

[0013] If the search results indicate the existence of a first identifier corresponding to the first encrypted identifier, then at least one financial attribute card number of the user is obtained based on the first identifier;

[0014] Package at least one card number with financial attributes to obtain a list of card numbers with financial attributes;

[0015] The list of financial attribute card numbers is sent to the terminal, which then displays the list of financial attribute card numbers on its user interface.

[0016] The receiving terminal sends the financial attribute card number selection result, which includes the target financial attribute card number.

[0017] Authorize and bind the target financial attribute card number based on the selection result of the financial attribute card number.

[0018] Optionally, in one embodiment of the present invention, the method further includes: if no first identifier corresponding to the first encrypted identifier is found, the query result indicating that at least one financial attribute card number does not exist in the UnionPay database is returned to the terminal.

[0019] Optionally, in one embodiment of the present invention, it further includes: the UnionPay database includes a first database and a second database, the first database stores financial attribute card numbers with the authority to bind financial attribute cards, and the second database stores financial attribute card numbers without the authority to bind financial attribute cards.

[0020] Optionally, in one embodiment of the present invention, the method further includes: upon receiving a signal indicating that a customer is authorizing a financial attribute card number that does not have the authority to bind a financial attribute card, performing a search based on a first encrypted identifier to obtain a first financial attribute card number corresponding to the first encrypted identifier and determining the current database information of the first financial attribute card number; if the current database information is a second database, storing the first financial attribute card number in a first database and feeding back the permission information of the first financial attribute card number to the terminal, wherein the permission information indicates that the first financial attribute card number has the authority to bind a financial attribute card.

[0021] Optionally, in one embodiment of the present invention, the method further includes: obtaining the user's predetermined financial attribute card number and basic information sent by the terminal; verifying the predetermined financial attribute card number and basic information; and authorizing the binding of the predetermined financial attribute card number if the verification is successful.

[0022] Optionally, in one embodiment of the present invention, the method further includes: before generating the first encrypted identifier based on the user's basic information, the user creating a financial attribute card number includes: obtaining the key ciphertext sent by the terminal; decoding the key ciphertext and then decrypting it using an encryption certificate to obtain the key plaintext; obtaining the user's first encrypted identifier and basic information through the key plaintext; generating at least one financial attribute card number corresponding to the first encrypted identifier and basic information; and sending at least one financial attribute card number to the user's terminal through the communication means corresponding to the user contained in the basic information to inform the user.

[0023] This invention provides a device for binding a financial card number, applied to a terminal, comprising:

[0024] The generation module is used to generate a first encrypted identifier based on the user's basic information and send the first encrypted identifier to the UnionPay database. The UnionPay database searches for the user's corresponding financial attribute card number based on the first encrypted identifier and returns the search results. The UnionPay database stores all financial attribute card numbers corresponding to the basic information. The financial attribute card number is the card number corresponding to the card created by the user when conducting business with a financial institution.

[0025] The receiving module is used to receive the search results fed back by the UnionPay database, and when the search results indicate that at least one financial attribute card number has been found, to obtain the user's list of financial attribute card numbers based on the search results, wherein the list of financial attribute card numbers includes at least one financial attribute card number.

[0026] The display module is used to show a list of financial attribute card numbers in the user interface;

[0027] The sending module is used to receive the financial attribute card number selection result and send the financial attribute card number selection result to the UnionPay database. The financial attribute card number selection result carries the target financial attribute card number, and the UnionPay database authorizes and binds the target financial attribute card number.

[0028] Optionally, in one embodiment of the present invention, it further includes: a manual card binding unit, used to, after receiving the search results fed back by the UnionPay database, prompt the user to manually bind the card when the search results indicate that there is no at least one financial attribute card number in the UnionPay database; and an acquisition unit, used to acquire the predetermined financial attribute card number input by the user and send the predetermined financial attribute card number and basic information to the UnionPay database.

[0029] Optionally, in one embodiment of the present invention, it further includes: a creation unit, used to create a financial attribute card number before generating a first encrypted identifier based on the user's basic information; the creation unit includes: an acquisition subunit, used to acquire the basic information initially input by the user, generate a second encrypted identifier based on the basic information, the second encrypted identifier being the plaintext key generated by the first encrypted identifier and the basic information; and an encryption subunit, used to encrypt and encode the public key corresponding to the plaintext key using an encryption certificate provided by the UnionPay database, obtain the ciphertext key, and send the ciphertext key to the UnionPay database.

[0030] This invention provides a device for binding financial attribute cards, applied to a UnionPay database, comprising:

[0031] The first receiving module is used to receive the first encrypted identifier transmitted by the terminal, and perform a search based on the first encrypted identifier to obtain the search result;

[0032] The acquisition module is used to acquire at least one financial attribute card number of the user based on the first identifier if the search result indicates that there is a first identifier corresponding to the first encrypted identifier;

[0033] The packaging module is used to package at least one financial attribute card number to obtain a list of financial attribute card numbers;

[0034] The sending module is used to send a list of financial attribute card numbers to the terminal, whereby the terminal displays the list of financial attribute card numbers on the terminal's user interface.

[0035] The second receiving module is used to receive the financial attribute card number selection result fed back by the terminal, wherein the financial attribute card number selection result carries the target financial attribute card number.

[0036] The authorization binding module is used to authorize and bind target financial attribute card numbers based on the selection results of financial attribute card numbers.

[0037] Optionally, in one embodiment of the present invention, it further includes: the UnionPay database includes a first database and a second database, the first database stores financial attribute card numbers with the authority to bind financial attribute cards, and the second database stores financial attribute card numbers without the authority to bind financial attribute cards.

[0038] Optionally, in one embodiment of the present invention, it further includes: a retrieval unit, configured to, upon receiving a signal indicating that a customer is authorizing a financial attribute card number that does not have the authority to bind a financial attribute card, perform a retrieval based on a first encrypted identifier, obtain the first financial attribute card number corresponding to the first encrypted identifier, and determine the current database information of the first financial attribute card number; and a feedback unit, configured to, if the current database information is a second database, store the first financial attribute card number in a first database and feed back the permission information of the first financial attribute card number to the terminal, wherein the permission information indicates that the first financial attribute card number has the authority to bind a financial attribute card.

[0039] Optionally, in one embodiment of the present invention, it further includes: a return unit, configured to return a query result to the terminal indicating that at least one financial attribute card number does not exist in the UnionPay database if no first identifier corresponding to the first encrypted identifier is found.

[0040] Optionally, in one embodiment of the present invention, it further includes: an acquisition unit, used to acquire the user's predetermined financial attribute card number and basic information sent by the terminal; and a verification unit, used to verify the predetermined financial attribute card number and basic information, and to authorize and bind the predetermined financial attribute card number if the verification is successful.

[0041] Optionally, in one embodiment of the present invention, it further includes: a creation unit, used to create a financial attribute card number before generating a first encrypted identifier based on the user's basic information; the creation unit includes: an acquisition subunit, used to acquire ciphertext of a key sent by a terminal; a decryption subunit, used to decode the ciphertext of the key and then decrypt it using an encryption certificate to obtain plaintext of the key, and to obtain the user's first encrypted identifier and basic information through the plaintext of the key; and a generation subunit, used to generate at least one financial attribute card number corresponding to the first encrypted identifier and basic information, and to send at least one financial attribute card number to the user's terminal through a communication method corresponding to the user contained in the basic information to inform the user.

[0042] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-mentioned method for binding financial attribute cards.

[0043] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for binding financial attribute cards.

[0044] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described method for binding financial attribute cards.

[0045] In this embodiment of the invention, compared with the technical solutions in the prior art, a first encrypted identifier is generated based on the user's basic information and sent to the UnionPay database. The UnionPay database then searches for the user's corresponding financial attribute card number based on the first encrypted identifier and returns the search results. The UnionPay database stores all financial attribute card numbers corresponding to the basic information; these financial attribute card numbers are the card numbers corresponding to cards created by the user when conducting business with financial institutions. The system receives the search results from the UnionPay database, and if the search results indicate that at least one financial attribute card number has been found, it obtains a list of the user's financial attribute card numbers based on the search results. This list includes at least one financial attribute card number. The system displays the list of financial attribute card numbers on the user interface. Finally, it receives the selection result for a financial attribute card number and sends it to the UnionPay database. The selection result carries the target financial attribute card number, and the UnionPay database authorizes and binds the target financial attribute card number. This improves the convenience for users binding bank cards on non-commercial bank apps, thereby solving the technical problem of inconvenience in binding bank cards on non-bank apps in the prior art. Attached Figure Description

[0046] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:

[0047] Figure 1 This is a flowchart of the binding method for financial attribute cards in an embodiment of the present invention;

[0048] Figure 2 This is a flowchart illustrating another method for binding a financial attribute card in an embodiment of the present invention;

[0049] Figure 3 This is a flowchart illustrating the authorization process during card binding in an embodiment of the present invention;

[0050] Figure 4This is a flowchart illustrating the encryption and decryption of bank card information transmission in an embodiment of the present invention;

[0051] Figure 5 This is a flowchart illustrating the process of binding a bank card to a non-commercial bank app in an embodiment of the present invention;

[0052] Figure 6 This is a flowchart illustrating the process of binding a bank card via a commercial bank's mobile app, as described in this invention.

[0053] Figure 7 This is a schematic diagram of the binding device for the financial attribute card in an embodiment of the present invention;

[0054] Figure 8 This is a schematic diagram of another financial attribute card binding device in an embodiment of the present invention;

[0055] Figure 9 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0057] Figure 1 This is a flowchart of the binding method for financial attribute cards in an embodiment of the present invention, as shown below. Figure 1 As shown, this embodiment of the invention provides a method for binding a financial attribute card number, applied to a terminal, including:

[0058] Step S101: Generate a first encrypted identifier based on the user's basic information and send the first encrypted identifier to the UnionPay database. The UnionPay database searches for the user's corresponding financial attribute card number based on the first encrypted identifier and returns the search results. The UnionPay database stores all financial attribute card numbers corresponding to the basic information. The financial attribute card number is the card number corresponding to the card created by the user when conducting business at a financial institution.

[0059] In the above steps, the terminal side transforms the user's basic information using an algorithm to generate a USERID (i.e., the first encrypted identifier). The basic information includes the user's ID card, mobile phone number, and other personal information. The USERID is then sent to the UnionPay database to retrieve all bank card numbers under the user's name. It should be noted that the UnionPay database stores all activated bank card numbers (i.e., financial card numbers) corresponding to the user's basic information. The UnionPay database in this invention integrates the databases of all banks, allowing the user to retrieve all bank cards activated at all banks in one go when searching the UnionPay database.

[0060] Step S102: Receive the search results from the UnionPay database, and if the search results indicate that at least one financial attribute card number has been found, obtain the user's list of financial attribute card numbers based on the search results, wherein the list of financial attribute card numbers includes at least one financial attribute card number.

[0061] In the above steps, after sending the USERID to the UnionPay database, the UnionPay database searches for bank cards under the user's name based on the USERID and returns the search results to the terminal. If the result is that the bank card number under the user's name has been found, the list of the searched bank card numbers is obtained.

[0062] Step S103: Display a list of financial attribute card numbers on the user interface;

[0063] In the above steps, these bank card lists (i.e., lists of financial card numbers) are displayed to the user so that the user can choose which card to bind.

[0064] Step S104: Receive the financial attribute card number selection result and send the financial attribute card number selection result to the UnionPay database. The financial attribute card number selection result carries the target financial attribute card number, and the UnionPay database authorizes and binds the target financial attribute card number.

[0065] In the above steps, after the user selects the bank card they want to bind from the bank card list, the selection result of the selected bank card is sent to the UnionPay database for binding and data upload.

[0066] In this embodiment of the invention, a first encrypted identifier is generated based on the user's basic information and sent to the UnionPay database. The UnionPay database retrieves the user's corresponding financial attribute card number based on the first encrypted identifier and returns the retrieval results. The UnionPay database stores all financial attribute card numbers corresponding to the basic information; these financial attribute card numbers are the card numbers corresponding to cards created by the user when conducting business with financial institutions. The system receives the retrieval results from the UnionPay database, and if the retrieval results indicate that at least one financial attribute card number has been found, it obtains the user's list of financial attribute card numbers based on the retrieval results. This list includes at least one financial attribute card number. The system displays the list of financial attribute card numbers on the user interface. The system receives the selection result for a financial attribute card number and sends it to the UnionPay database. The selection result carries the target financial attribute card number, and the UnionPay database authorizes and binds the target financial attribute card number. The method provided by this embodiment of the invention can improve the convenience for users binding bank cards on non-commercial bank apps, thereby solving the technical problem of inconvenience in binding bank cards on non-bank apps in the prior art.

[0067] As an embodiment of the present invention, after receiving the search results from the UnionPay database, the method further includes: prompting the user to manually bind a card when the search results indicate that there is no at least one financial attribute card number in the UnionPay database; obtaining the predetermined financial attribute card number entered by the user; and sending the predetermined financial attribute card number and basic information to the UnionPay database.

[0068] In the above optional embodiments, when the bank card number under the user's name cannot be found in the UnionPay database through USERID, the user is prompted to manually bind the card, the bank card number manually entered by the user is obtained, and the bank card number and the user's basic information are sent to the UnionPay database for manual card binding.

[0069] As an embodiment of the present invention, the method further includes: before generating the first encrypted identifier based on the user's basic information, the user creating a financial attribute card number includes: obtaining the basic information initially entered by the user, generating a second encrypted identifier based on the basic information, wherein the second encrypted identifier is the plaintext key generated by the first encrypted identifier and the basic information; encrypting and encoding the public key corresponding to the plaintext key using the encryption certificate provided by the UnionPay database, obtaining the ciphertext key, and sending the ciphertext key to the UnionPay database.

[0070] In the above optional embodiments, the bank card needs to be activated before the user binds it. The user first provides basic information, and a USERID is generated based on the basic information. A second encrypted identifier is generated through the USERID and the basic information. Then, the public key corresponding to the second encrypted identifier is encrypted and encoded using the encryption certificate provided by the UnionPay database. After obtaining the key ciphertext, it is sent to the UnionPay database to complete the data collection and encryption, thereby improving the data security.

[0071] Figure 2 This is a flowchart of another method for binding a financial attribute card according to an embodiment of the present invention, such as... Figure 2 As shown, this embodiment of the invention provides a method for binding a financial attribute card, applied to the UnionPay database, including:

[0072] Step S201: Receive the first encrypted identifier transmitted by the terminal, and perform a search based on the first encrypted identifier to obtain the search result;

[0073] In the above steps, the USERID (i.e., the first encrypted identifier) ​​sent by the terminal is received first, and the bank card number corresponding to the USERID is retrieved based on the USERID.

[0074] Step S202: If the search result indicates the existence of a first identifier corresponding to the first encrypted identifier, then at least one financial attribute card number of the user is obtained based on the first identifier;

[0075] In the above steps, the identification information corresponding to the USERID is retrieved through the USERID, and all bank card numbers corresponding to the identification information are obtained through the identification information.

[0076] Step S203: Package at least one financial attribute card number to obtain a list of financial attribute card numbers;

[0077] In the above steps, the obtained bank card numbers are packaged and compiled into a list for easy selection by the user.

[0078] Step S204: Send the list of financial attribute card numbers to the terminal, wherein the terminal displays the list of financial attribute card numbers on the terminal's user interface;

[0079] In the above steps, multiple bank card numbers in list format are sent to the terminal, and the terminal displays the list of bank card numbers on the terminal's user interface for the user to select the bank card number to bind.

[0080] Step S205: Receive the financial attribute card number selection result fed back by the terminal, wherein the financial attribute card number selection result carries the target financial attribute card number;

[0081] In the above steps, after the user selects the bank card number to be bound, the receiving terminal returns the bank card number selection result.

[0082] Step S206: Authorize and bind the target financial attribute card number based on the financial attribute card number selection result.

[0083] In the above steps, the user's selected bank card number is authorized for binding based on the user's choice.

[0084] In this embodiment of the invention, a first encrypted identifier transmitted by a receiving terminal is received, and a search is performed based on the first encrypted identifier to obtain a search result. If the search result indicates the existence of a first identifier corresponding to the first encrypted identifier, at least one financial attribute card number of the user is obtained based on the first identifier. The at least one financial attribute card number is packaged to obtain a list of financial attribute card numbers. The list of financial attribute card numbers is sent to the terminal, wherein the terminal displays the list of financial attribute card numbers on the terminal's user interface. The financial attribute card number selection result fed back by the terminal is received, wherein the financial attribute card number selection result carries a target financial attribute card number. The target financial attribute card number is authorized and bound based on the financial attribute card number selection result. The method provided by this embodiment of the invention can improve the convenience for users when binding bank cards on non-commercial bank apps, thereby solving the technical problem of insufficient convenience for users when binding bank cards on non-bank apps in the prior art.

[0085] As an embodiment of the present invention, it further includes: the UnionPay database includes a first database and a second database, the first database stores financial attribute card numbers with the authority to bind financial attribute cards, and the second database stores financial attribute card numbers without the authority to bind financial attribute cards.

[0086] In the above optional embodiments, the UnionPay database uses a hierarchical storage method to store all bank cards. Specifically, all bank cards of all users are classified and stored hierarchically. Bank cards that have been authorized to use the quick binding method provided in this embodiment are stored in the first database, and bank cards that have not been authorized to use the quick binding method provided in this embodiment are stored in the first database. After determining whether the user agrees to use quick card binding (or "one-click card binding"), the system queries whether the user's corresponding bank card has been authorized. If it has not been authorized, it is authorized in advance.

[0087] As an embodiment of the present invention, it further includes: when receiving a signal indicating that a customer is authorizing a financial attribute card number that does not have the authority to bind a financial attribute card, performing a search based on a first encrypted identifier to obtain a first financial attribute card number corresponding to the first encrypted identifier and determining the current database information of the first financial attribute card number; if the current database information is a second database, storing the first financial attribute card number in the first database and feeding back the permission information of the first financial attribute card number to the terminal, wherein the permission information indicates that the first financial attribute card number has the authority to bind a financial attribute card.

[0088] In the above optional embodiments, specifically, Figure 3 This is a flowchart of the authorization process during card binding in an embodiment of the present invention, such as... Figure 3 As shown, the specific steps are as follows:

[0089] Step S301: The user clicks to re-authorize;

[0090] Step S302: The commercial bank / non-commercial bank APP guides the customer to select the authorized institution and check the agreement;

[0091] Step S303: The commercial bank / non-commercial bank server calls the supplementary authorization interface and sends supplementary authorization information, including APPID, USERID, institution number, etc.

[0092] Step S304: The data integration application UnionPay server changes the customer's bank card from unauthorized primary storage to authorized secondary storage based on the authorization institution.

[0093] Step S305: The UnionPay server notifies the re-authorization institution to update the re-authorization status;

[0094] Step S306: Update the unauthorized status of the authorized agency.

[0095] As an embodiment of the present invention, it further includes: if no first identifier corresponding to the first encrypted identifier is found, the query result that at least one financial attribute card number does not exist in the UnionPay database is returned to the terminal.

[0096] In the above optional embodiments, if no bank card number corresponding to USERID is found, the search result that there is no identifier corresponding to USERID in the UnionPay database is returned to the terminal.

[0097] As an embodiment of the present invention, it further includes: obtaining the user's predetermined financial attribute card number and basic information sent by the terminal; verifying the predetermined financial attribute card number and basic information; and authorizing the binding of the predetermined financial attribute card number if the verification is successful.

[0098] In the above optional embodiments, after the terminal retrieves the corresponding bank card using the USERID, it receives the bank card number selected by the user and the corresponding basic information, and performs security and integrity verification on the bank card number and basic information. If the verification is successful, the bank card is bound; if the verification fails, the terminal is returned with the reason for the failure, prompting for supplementary information or verification of the card number.

[0099] As an embodiment of the present invention, it further includes: before generating the first encrypted identifier based on the user's basic information, the user creating a financial attribute card number includes: obtaining the key ciphertext sent by the terminal; decoding the key ciphertext and then decrypting it using an encryption certificate to obtain the key plaintext, obtaining the user's first encrypted identifier and basic information through the key plaintext; generating at least one financial attribute card number corresponding to the first encrypted identifier and basic information, and sending at least one financial attribute card number to the user's terminal through the communication means corresponding to the user contained in the basic information to inform the user.

[0100] Figure 4 This is a flowchart of bank card information transmission encryption and decryption in an embodiment of the present invention, such as... Figure 4 As shown, the commercial bank randomly generates a plaintext key, encrypts it using the public key corresponding to the encryption certificate ID provided by UnionPay according to the encryption algorithm, and then base64 encodes it to generate the ciphertext key. Upon receiving the request, the UnionPay data integration application decrypts the information, specifically by base64 decoding the ciphertext key, decrypting it using the encryption certificate's private key to obtain the symmetric plaintext key, and then decrypting it according to the encryption algorithm to form the sensitive data plaintext, which is then stored.

[0101] It should be noted that this embodiment of the invention involves three parties: 1. Data integration application (UnionPay server): On the one hand, it provides bank card information security and tiered storage space; on the other hand, it provides bank card information transmission interfaces, bank card information query interfaces, and authorization interfaces. 2. Front-end of each APP: The front-end page of the APP that requires card binding can guide customers to bind their bank cards. 3. Servers of each APP: Including commercial bank servers and non-commercial bank servers. The commercial bank server calls the data integration application to send customer bank card information on the one hand, and calls the data integration application to obtain the customer's full bank card information on the other hand; the non-commercial bank server mainly calls the data integration application to obtain the customer's full bank card information. For ease of explanation, each APP front-end and each APP server can be regarded as one end for explanation.

[0102] The bank card information transmission interface involves commercial bank servers calling a scheduled task to encrypt and send incremental customer bank card information. The sent fields include APPID, USERID, customer's registered name, customer's registered ID type, customer's registered ID number, customer's registered mobile phone number, customer's bank, customer's bank card number, and authorization status (agstatus). USERID is a modified combination of customer's registered name, registered ID type, and the last six digits of the registered ID; the modification rules are consistent across all commercial banks, forming the primary key. The authorization status indicates whether the customer agrees to use the bank card for the one-click card binding function; if agreed, the authorization status (agstatus) is 1; otherwise, it is 0. The data integration application (UnionPay server) receives the incremental bank card information and stores it hierarchically according to the authorization status.

[0103] Among them, the bank card information query interface: After the customer initiates a card binding request in each APP, each APP guides the customer to verify their identity information. The verification method can be face recognition, fingerprint, SMS verification code, etc. After the verification is successful, the server of each APP calls the bank card information query interface.

[0104] The commercial bank's server sends the USERID. After receiving the request message, the UnionPay data integration application parses it, matches it with the USERID, and returns the list of authorized cards from the account opening bank and secondary storage. The commercial bank's APP receives the card list information, decrypts it, and displays it to the customer, supporting one-click card binding. If no USERID is matched, the customer is guided to manually fill in the card information.

[0105] After customer authorization, non-commercial bank servers send the USERID (if the non-commercial bank client has customer information stored, it sends the USERID directly; if not, it guides the customer to fill in the information before sending). UnionPay's data integration application receives and parses the request message, matches it with the USERID, encrypts it, and returns the account opening bank and card list information from secondary storage. Commercial bank apps receive the card list information, decrypt it, and display it to the customer, supporting one-click card binding. If no USERID is matched, the customer is guided to manually fill in the card information. If the customer has not authorized the service, the same manual card information applies to existing customers.

[0106] In this process, after the customer selects a bank card and verifies the information, the data integration application will synchronize the card binding information to the relevant banks. The relevant banks will then perform the actual card binding operation. If the card binding fails, the application will return a notification to the customer indicating that the transaction is abnormal.

[0107] If a customer has not authorized a certain bank but wishes to bind a bank card from that bank when binding their card, they can click to "re-authorize". The commercial bank / non-commercial bank will call the re-authorization interface, submitting APPID, USERID, and the unauthorized institution number, etc., and then notify UnionPay to change the first-level unauthorized bank card information to the second-level authorized bank card information and return it to support customer binding. At the same time, UnionPay will notify the bank to update the authorization status.

[0108] To enhance information transmission security, USERID can be modified to include both document type and document number. When calling the API, only the modified USERID needs to be transmitted, without transmitting the specific document type or document number. If necessary, UnionPay can decipher the information based on the modification rules.

[0109] Furthermore, the following provides a detailed explanation of the scenarios involving commercial bank apps and non-commercial bank apps.

[0110] Figure 5 This is a flowchart illustrating the process of binding a bank card to a non-commercial bank app in an embodiment of the present invention;

[0111] Step S501: The customer initiates a card binding transaction on a non-commercial bank's APP;

[0112] Step S502: Non-commercial bank apps guide customers to verify their identity information (i.e., basic information);

[0113] Step S503: Non-commercial bank APP server verifies customer identity information;

[0114] Step S504: Non-commercial bank apps prompt customers whether to authorize the one-click card binding function;

[0115] If you do not agree to the authorization: proceed to steps S515-S517;

[0116] If you agree to the authorization:

[0117] Step S505: Determine whether customer identity information is stored;

[0118] If customer information is stored: Proceed to step S508;

[0119] If no customer information is stored:

[0120] Step S506: Non-commercial bank APP front-end guides customers to fill in their name, document type and the last six digits of document number;

[0121] Step S507: The customer enters their name, selects the document type, and fills in the last six digits of the document number;

[0122] Step S508: Non-commercial bank APP server combines and transforms name + ID type + last six digits of ID number to generate USERID, and then encrypts and sends it up.

[0123] Step S509: The UnionPay server (data integration application) determines whether a USERID is matched.

[0124] If a USERID is matched, then

[0125] Step S510: UnionPay server (data integration application) returns the list of bank cards;

[0126] Step S511: The commercial bank server obtains the list of bank cards;

[0127] Step S512: The commercial bank's APP displays a list of bank cards, supporting one-click card binding;

[0128] Step S513: The customer completes the card binding.

[0129] If no USERID is matched, then

[0130] Step S514: UnionPay server (data integration application) returns no information found;

[0131] Step S515: The non-commercial bank APP server returns the manual card input page;

[0132] Step S516: Non-commercial bank APP front-end guides users to manually bind cards;

[0133] Step S517: The customer binds their bank card;

[0134] Step S518, UnionPay notifies you to bind your card;

[0135] Step S519: The commercial bank completes the card binding process.

[0136] in addition, Figure 6 This is a flowchart illustrating the process of binding a bank card via a commercial bank's mobile app, as described in this invention.

[0137] Step S601: The customer initiates a card binding transaction on the commercial bank's APP;

[0138] Step S602: The commercial bank's APP guides the customer to verify their identity information;

[0139] Step S603: The commercial bank's server verifies the customer's identity information;

[0140] Step S604: The commercial bank server calls the UnionPay server (data integration application) bank card information query interface and sends the USERID to query the bank card information.

[0141] Step S605: UnionPay server (data integration application) determines and matches USERID;

[0142] If a USERID is matched

[0143] Step S606: UnionPay server (data integration application) returns the list of bank cards;

[0144] Step S607: The commercial bank server obtains the list of bank cards;

[0145] Step S608: The commercial bank's APP displays a list of bank cards, supporting one-click card binding;

[0146] Step S609: The customer completes the card binding.

[0147] If no USERID is matched

[0148] Step S610: UnionPay server (data integration application) returns no information found;

[0149] Step S611: The commercial bank server returns the manual card input page;

[0150] Step S612: The commercial bank's APP guides users to manually bind their cards;

[0151] Step S613: The customer binds their bank card;

[0152] Step S614: UnionPay notifies the commercial bank to bind the card;

[0153] Step S615: The commercial bank completes the card binding.

[0154] In the method provided in this embodiment of the invention, UnionPay establishes a tiered bank card information storage space. The first tier stores unauthorized bank card information, and the second tier stores authorized bank card information. A standardized interface for bank card information transmission is provided. Each commercial bank, as a member of the alliance, applies to call this interface. UnionPay assigns an APPID to each commercial bank. Every hour, the commercial bank calls the interface using the RSA asymmetric encryption algorithm to send incremental customer bank card information. The sent fields include APPID, USERID, customer pre-registered information, bank card number, mobile phone number, and whether authorization has been granted. After receiving the message information, UnionPay stores the information tiered according to the authorization flag. The customer pre-registered information includes name, ID type, and ID number. The USERID is a modified and encrypted transmission of the customer's pre-registered name, ID type, and the last six digits of the ID number. Each commercial bank sends information according to this rule, forming a query primary key. The bank card number is transmitted in encrypted form.

[0155] UnionPay provides a standardized interface for bank card information query. UnionPay assigns an APPID to each caller. When a customer binds a card on a commercial bank's APP, the APP calls the query interface, submitting the APPID and USERID to initiate the call request. UnionPay accepts the request and returns a list of authorized bank cards in secondary storage, supporting one-click card binding. After the customer selects a card, UnionPay sends the card binding information to the respective commercial banks based on the bank card's ownership, and each commercial bank performs the actual card binding operation. When a customer binds a card on another APP, the user's identity information is first verified (using various verification methods such as facial recognition, fingerprint, and SMS verification code). After successful verification, the customer is prompted whether to use the one-click card binding function. If the customer agrees and the APP already has the customer's name, ID type, and ID number, it submits the APPID and USERID to initiate the call request. UnionPay accepts the request and returns a list of bank cards, supporting one-click card binding. After the customer selects a card, UnionPay sends the card binding information to the respective commercial banks based on the bank card's ownership, and each commercial bank performs the actual card binding operation. If the customer agrees but does not provide their name, ID type, or ID number, guide the customer to enter the information before submitting it to the query card list. If the customer does not agree, guide the customer to manually fill in the card information, similar to the existing card list.

[0156] This solution allows customers to complete authorization during the one-click card binding process. If a customer has not authorized a particular bank but wishes to bind a card from that bank during the binding process, they can click to complete the authorization. This will notify UnionPay to change the first-level unauthorized bank card information to the second-level authorized bank card information and return the information. This supports customer binding, and UnionPay simultaneously notifies the bank to update the authorization status, improving the user experience and convenience during the card binding process. Furthermore, this invention establishes a data integration application, with commercial banks forming an alliance to create a full bank card information database by transmitting incremental bank card numbers at different levels via scheduled tasks. This allows commercial and non-commercial bank apps to display a complete list of bank cards to customers at once by sending modified USERIDs through API calls. This enables customers to bind cards with one click, eliminating the need to manually fill in card information or sequentially launch a bank's app / H5 to add cards, significantly improving the efficiency of card binding and payment.

[0157] Figure 7 This is a schematic diagram of the binding device for a financial attribute card in an embodiment of the present invention, as shown below. Figure 7 As shown, this embodiment of the invention provides a device for binding a financial attribute card number, applied to a terminal, comprising:

[0158] The generation module 71 is used to generate a first encrypted identifier based on the user's basic information and send the first encrypted identifier to the UnionPay database. The UnionPay database searches for the financial attribute card number corresponding to the user based on the first encrypted identifier and returns the search results. The UnionPay database stores all financial attribute card numbers corresponding to the basic information. The financial attribute card number is the card number corresponding to the card created by the user when conducting business at a financial institution.

[0159] The receiving module 72 is used to receive the search results fed back by the UnionPay database, and when the search results indicate that at least one financial attribute card number has been found, to obtain the user's list of financial attribute card numbers based on the search results, wherein the list of financial attribute card numbers includes at least one financial attribute card number.

[0160] Display module 73 is used to display a list of financial attribute card numbers in the user interface;

[0161] The sending module 74 is used to receive the financial attribute card number selection result and send the financial attribute card number selection result to the UnionPay database. The financial attribute card number selection result carries the target financial attribute card number, and the UnionPay database authorizes and binds the target financial attribute card number.

[0162] Optionally, in one embodiment of the present invention, it further includes: a manual card binding unit, used to, after receiving the search results fed back by the UnionPay database, prompt the user to manually bind the card when the search results indicate that there is no at least one financial attribute card number in the UnionPay database; and an acquisition unit, used to acquire the predetermined financial attribute card number input by the user and send the predetermined financial attribute card number and basic information to the UnionPay database.

[0163] Optionally, in one embodiment of the present invention, it further includes: a creation unit, used to create a financial attribute card number before generating a first encrypted identifier based on the user's basic information; the creation unit includes: an acquisition subunit, used to acquire the basic information initially input by the user, generate a second encrypted identifier based on the basic information, the second encrypted identifier being the plaintext key generated by the first encrypted identifier and the basic information; and an encryption subunit, used to encrypt and encode the public key corresponding to the plaintext key using an encryption certificate provided by the UnionPay database, obtain the ciphertext key, and send the ciphertext key to the UnionPay database.

[0164] Figure 8 This is a schematic diagram of another financial attribute card binding device according to an embodiment of the present invention, such as... Figure 8 As shown, this embodiment of the invention provides a binding device for a financial attribute card, applied to a UnionPay database, comprising:

[0165] The first receiving module 81 is used to receive the first encrypted identifier transmitted by the terminal, and perform a search based on the first encrypted identifier to obtain the search result;

[0166] The acquisition module 82 is used to acquire at least one financial attribute card number of the user based on the first identifier if the search result indicates that there is a first identifier corresponding to the first encrypted identifier;

[0167] Packaging module 83 is used to package at least one financial attribute card number to obtain a list of financial attribute card numbers;

[0168] The sending module 84 is used to send the list of financial attribute card numbers to the terminal, wherein the terminal displays the list of financial attribute card numbers on the terminal's user interface;

[0169] The second receiving module 85 is used to receive the financial attribute card number selection result fed back by the terminal, wherein the financial attribute card number selection result carries the target financial attribute card number.

[0170] The authorization binding module 86 is used to authorize and bind the target financial attribute card number based on the selection result of the financial attribute card number.

[0171] Optionally, in one embodiment of the present invention, it further includes: the UnionPay database includes a first database and a second database, the first database stores financial attribute card numbers with the authority to bind financial attribute cards, and the second database stores financial attribute card numbers without the authority to bind financial attribute cards.

[0172] Optionally, in one embodiment of the present invention, it further includes: a retrieval unit, configured to, upon receiving a signal indicating that a customer is authorizing a financial attribute card number that does not have the authority to bind a financial attribute card, perform a retrieval based on a first encrypted identifier, obtain the first financial attribute card number corresponding to the first encrypted identifier, and determine the current database information of the first financial attribute card number; and a feedback unit, configured to, if the current database information is a second database, store the first financial attribute card number in a first database and feed back the permission information of the first financial attribute card number to the terminal, wherein the permission information indicates that the first financial attribute card number has the authority to bind a financial attribute card.

[0173] Optionally, in one embodiment of the present invention, it further includes: a return unit, configured to return a query result to the terminal indicating that at least one financial attribute card number does not exist in the UnionPay database if no first identifier corresponding to the first encrypted identifier is found.

[0174] Optionally, in one embodiment of the present invention, it further includes: an acquisition unit, used to acquire the user's predetermined financial attribute card number and basic information sent by the terminal; and a verification unit, used to verify the predetermined financial attribute card number and basic information, and to authorize and bind the predetermined financial attribute card number if the verification is successful.

[0175] Optionally, in one embodiment of the present invention, it further includes: a creation unit, used to create a financial attribute card number before generating a first encrypted identifier based on the user's basic information; the creation unit includes: an acquisition subunit, used to acquire ciphertext of a key sent by a terminal; a decryption subunit, used to decode the ciphertext of the key and then decrypt it using an encryption certificate to obtain plaintext of the key, and to obtain the user's first encrypted identifier and basic information through the plaintext of the key; and a generation subunit, used to generate at least one financial attribute card number corresponding to the first encrypted identifier and basic information, and to send at least one financial attribute card number to the user's terminal through a communication method corresponding to the user contained in the basic information to inform the user.

[0176] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-mentioned method for binding financial attribute cards.

[0177] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for binding financial attribute cards.

[0178] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described method for binding financial attribute cards.

[0179] Figure 9 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of the present invention, such as... Figure 9 As shown, the electronic device includes: a processor 901, a memory 902, and a bus 903.

[0180] The processor 901 and the memory 902 communicate with each other via the bus 903.

[0181] The processor 901 is used to call program instructions in the memory 902 to execute the methods provided in the above-described method embodiments.

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

[0183] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

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

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

[0186] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for binding a financial attribute card number, characterized in that, Applied to terminals, including: A first encrypted identifier is generated based on the user's basic information and sent to the UnionPay database. The UnionPay database searches for the financial attribute card number corresponding to the user based on the first encrypted identifier and returns the search results. The UnionPay database stores all financial attribute card numbers corresponding to the basic information. The financial attribute card number is the card number corresponding to the card created by the user when conducting business at a financial institution. The system receives the search results from the UnionPay database, and if the search results indicate that at least one financial attribute card number has been found, it obtains a list of the user's financial attribute card numbers based on the search results, wherein the list of financial attribute card numbers includes the at least one financial attribute card number. The list of card numbers with the financial attributes is displayed in the user interface; The system receives the selection result of the financial attribute card number and sends the selection result to the UnionPay database. The selection result carries the target financial attribute card number, and the UnionPay database authorizes and binds the target financial attribute card number.

2. The method as described in claim 1, characterized in that, After receiving the search results from the UnionPay database, the process further includes: When the search results indicate that the at least one financial attribute card number does not exist in the UnionPay database, the user is prompted to manually bind the card. Obtain the pre-selected financial attribute card number input by the user, and send the pre-selected financial attribute card number and the basic information to the UnionPay database.

3. The method as described in claim 1, characterized in that, Also includes: Before generating the first encrypted identifier based on the user's basic information, the creation of the user's financial attribute card number includes: Obtain the basic information initially input by the user, and generate a second encrypted identifier based on the basic information. The second encrypted identifier is the plaintext key generated by the first encrypted identifier and the basic information. The plaintext key is encrypted using the public key corresponding to the encryption certificate provided by the UnionPay database, and then the ciphertext key is obtained and sent to the UnionPay database.

4. A method for binding a financial attribute card, characterized in that, Applied to the UnionPay database, including: The receiving terminal transmits a first encrypted identifier, and performs a search based on the first encrypted identifier to obtain the search results; If the search result indicates the existence of a first identifier corresponding to the first encrypted identifier, then at least one financial attribute card number of the user is obtained based on the first identifier; Package the at least one financial attribute card number to obtain a list of financial attribute card numbers; The list of financial attribute card numbers is sent to the terminal, wherein the terminal displays the list of financial attribute card numbers on the user interface of the terminal; The terminal receives the financial attribute card number selection result, wherein the financial attribute card number selection result carries the target financial attribute card number; Authorize and bind the target financial attribute card number based on the selection result of the financial attribute card number.

5. The method as described in claim 4, characterized in that, Also includes: The UnionPay database includes a first database and a second database. The first database stores financial attribute card numbers that have the authority to bind financial attribute cards, while the second database stores financial attribute card numbers that do not have the authority to bind financial attribute cards.

6. The method as described in claim 5, characterized in that, Also includes: When a signal is received indicating that a customer is authorizing a financial attribute card number that does not have the authority to bind a financial attribute card, a search is performed based on the first encrypted identifier to obtain the first financial attribute card number corresponding to the first encrypted identifier and to determine the current database information of the first financial attribute card number. If the current database information is the second database, the first financial attribute card number is stored in the first database and the permission information of the first financial attribute card number is fed back to the terminal. The permission information indicates that the first financial attribute card number has the permission to bind a financial attribute card.

7. The method as described in claim 4, characterized in that, Also includes: If the first identifier corresponding to the first encrypted identifier is not found, the query result indicating that the at least one financial attribute card number does not exist in the UnionPay database will be returned to the terminal.

8. The method as described in claim 4, characterized in that, Also includes: Obtain the user's pre-ordered financial card number and basic information sent by the terminal; The predetermined financial attribute card number and basic information are verified, and the predetermined financial attribute card number is authorized and bound if the verification is successful.

9. The method as described in claim 4, characterized in that, Also includes: Before generating the first encrypted identifier based on the user's basic information, the creation of the user's financial attribute card number includes: Obtain the key ciphertext sent by the terminal; After decoding the ciphertext of the key, the encryption certificate is used to decrypt it to obtain the plaintext of the key. The user's first encrypted identifier and basic information are then obtained from the plaintext of the key. Generate at least one financial attribute card number corresponding to the first encrypted identifier and basic information, and send the at least one financial attribute card number to the user's terminal through the communication means corresponding to the user contained in the basic information to inform the user.

10. A device for binding a financial card number, characterized in that, Applied to terminals, including: The generation module is used to generate a first encrypted identifier based on the user's basic information and send the first encrypted identifier to the UnionPay database. The UnionPay database searches for the financial attribute card number corresponding to the user based on the first encrypted identifier and returns the search results. The UnionPay database stores all financial attribute card numbers corresponding to the basic information. The financial attribute card number is the card number corresponding to the card created by the user when conducting business at a financial institution. A receiving module is configured to receive the search results fed back by the UnionPay database, and, if the search results indicate that at least one financial attribute card number has been retrieved, obtain a list of the user's financial attribute card numbers based on the search results, wherein the list of financial attribute card numbers includes the at least one financial attribute card number; The display module is used to display the list of financial attribute card numbers in the user interface; The sending module is used to receive the financial attribute card number selection result and send the financial attribute card number selection result to the UnionPay database. The financial attribute card number selection result carries the target financial attribute card number, and the UnionPay database authorizes and binds the target financial attribute card number.

11. A binding device for a financial attribute card, characterized in that, Applied to the UnionPay database, it includes: a first receiving module, used to receive a first encrypted identifier transmitted by a terminal, and perform a search based on the first encrypted identifier to obtain search results; The acquisition module is configured to acquire at least one financial attribute card number of the user based on the first identifier when the search result indicates the existence of a first identifier corresponding to the first encrypted identifier; The packaging module is used to package the at least one financial attribute card number to obtain a list of financial attribute card numbers; A sending module is used to send the list of financial attribute card numbers to the terminal, wherein the terminal displays the list of financial attribute card numbers on the user interface of the terminal; The second receiving module is used to receive the financial attribute card number selection result fed back by the terminal, wherein the financial attribute card number selection result carries the target financial attribute card number; The authorization binding module is used to authorize and bind the target financial attribute card number based on the selection result of the financial attribute card number.

12. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 9.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 9.

Images