TWM572510U - Transaction system - Google Patents

Abstract

A first server of a transaction system receives a credit card binding request including an identity data from a user terminal, and transmits a target wallet user identification data corresponding to the identity data to a second server of the transaction system . The second server selects a target cardholder identification data that matches the target wallet user identification data, and transmits a binding credit card list including a target credit card data corresponding to the target cardholder identification data to the user terminal. When the second server receives a binding instruction from the using end, the second server sends the target credit card data to the first server. The first server generates and stores a binding credit card data including the target credit card data and corresponding to the target wallet user identification data.

Description

Trading System

The present invention relates to a trading system, and more particularly to a trading system involving network communication technology.

The existing e-wallet usually provides a credit card binding function. If the user binds a credit card held by the user to an e-wallet account, then if the e-wallet account is used for consumption, it is equivalent to using the binding. The credit card spending of the e-wallet account. However, when you bind a credit card to your e-wallet account, you usually need to enter the credit card number, valid year and month, and security check code. If the user does not carry the credit card number, valid year and month, and security check code information. And the credit card is just not at hand, the user needs to specifically find the credit card to continue the binding operation, which makes the prior art still inconvenient.

Accordingly, it is an object of the present invention to provide a transaction system that can improve the inconvenience of the prior art.

The new transaction system is adapted to be electrically connected to a user terminal. The transaction system includes a first server and a second server, and the first server stores a plurality of wallet user identification data respectively corresponding to the plurality of electronic wallet accounts. The second server is electrically connected to the first server, and stores a plurality of credit card data and a plurality of card identification data corresponding to the credit card data respectively. When the first server receives a credit card binding request from the user terminal and includes an identity data, and determines that there is a target wallet user identification data corresponding to the identity data in the wallet user identification data, The target wallet user identification data is transmitted to the second server. After the second server receives the target wallet user identification data from the first server, and determines that there is a target cardholder identification data corresponding to the target wallet user identification data in the card identification data, A binding credit card list is generated and transmitted to the user terminal, and the bindable credit card list includes the credit card data of the credit card data corresponding to the target card household identification data and used as a target credit card data. After receiving the binding instruction from the user end and indicating the target credit card data, the second server transmits the target credit card data to the first server. When the first server receives the target credit card data from the second server, the first server generates and stores a binding credit card data including the target credit card data and corresponding to the target wallet user identification data.

In some implementations of the new transaction system, each card identification data includes at least one communication data corresponding to a mobile device, and the second server determines that the target card user exists in the card identification data. When the data is identified, a one-time password is first generated, and the one-time password is transmitted to the corresponding mobile device according to the communication data included in the target card identification data, and the second server receives the data. When a verification password from the user end is determined and the verification password is determined to be consistent with the one-time password, the bindable credit card list is generated and transmitted to the user.

In some implementations of the new transaction system, when the second server determines that the target card identification data does not exist in the card identification data, the first server is controlled to generate and transmit a first alert notification. Up to the use end; when the second server receives the verification password and determines that the verification password does not match the one-time password, generating and transmitting a second alert notification related to the verification password to the use end And generating, by the second server, a third alert related to the verification password when the second server determines that the verification password is received and the number of times the verification password does not match the one-time password reaches a predetermined number of times Notify to the user.

In some implementations of the new transaction system, when the second server receives the binding instruction, and determines that the target credit card data is not in a credit card opening procedure and is not allowed in the specific electronic wallet When the application is used for consumption, the second server also sets the target credit card data to a state that is not used by the credit card issuer but is allowed to be used for consumption in the specific electronic wallet application. .

In some implementations of the new transaction system, when the first server determines that the target wallet user identification data does not exist in the wallet user identification data, the first server generates and transmits an identity identification failure notification. To the end of the use.

The effect of the present invention is that when the user wants to bind a credit card held by the user to the electronic wallet account, the credit card binding request including the identity data is transmitted to the first server by the user terminal. The first server transmits the target wallet user identification data corresponding to the identity data to the second server, so that the second server selects the target card user that matches the target wallet user identification data. Identifying the data, and returning the list of the bindable credit card including the target credit card data corresponding to the target card identification data to the user end, so that the user only needs to select the desired binding by using the user terminal. Credit card, and transmitting the binding instruction indicating the target credit card data to the second server, enabling the second server to transmit the target credit card data to the first server, thereby causing the first servo The binding credit card data containing the target credit card data and corresponding to the target wallet user identification data is completed to complete the binding between the credit card and the electronic wallet account. This way, users do not need to enter the card number, expiration date and security code check information such as credit card will be able to quickly and easily complete the binding, completely overcome the inconveniences of the prior art use.

Before the present invention is described in detail, it should be noted that the term "electrical connection" as used in this specification refers to a wired electrical connection between electronic devices/devices/components via conductors, and data transmission via wireless communication. Radio connection.

Referring to FIG. 1, an embodiment of the novel transaction system 1 is managed, for example, by a banking unit, and the transaction system 1 is adapted to be used by a plurality of users 5 (only one of which is shown in FIG. 1) to communicate over the Internet. connection. For ease of understanding, the following is only described by the user terminal 5 shown in FIG. 1. The user terminal 5 can be, for example, a smart phone, a tablet computer, a notebook computer or a desktop computer, but not This is limited to this.

The transaction system 1 includes a first server 11 and a second server 12 electrically coupled to the first server 11. In this embodiment, the first server 11 is implemented, for example, as an electronic wallet transaction server related to a specific type of electronic wallet, and stores a plurality of wallet user identification materials, and a plurality of corresponding wallet user identifications respectively. Information on the e-wallet account.

In this embodiment, the wallet user identification data and the electronic wallet accounts respectively correspond to a plurality of users. By way of example, the user terminal 5 is assumed to be held by a user A of the users, and the user terminal 5 can be installed, for example, by the bank unit according to the operation received. And corresponding to the specific e-wallet application of the specific type of e-wallet, and connected to the first server 11 through the specific e-wallet application via the e-wallet account corresponding to the user A, and using the specific Types of e-wallets are consumed, but not limited to them. In this embodiment, each wallet user identification information is, for example, the identity information provided by the user when applying for the electronic wallet account. Specifically, the wallet user identification data includes, for example, a corresponding identity card of the user. The font size, a date of birth, and a communication material, and the communication material is, for example, a mobile phone number corresponding to one of the mobile devices held by the user, but is not limited thereto. In addition, in another embodiment, the transaction system 1 may also include a plurality of first servers 11 (ie, including multiple e-wallet transaction servers), and the first servers 11 are respectively related, for example. For a plurality of different specific types of electronic wallets, each of the first servers 11 is electrically connected to the second server 12, and is not limited to the embodiment.

The second server 12 is implemented, for example, as a credit card accounting server, and stores a plurality of credit card materials and a plurality of card identification data corresponding to the credit card materials respectively.

In this embodiment, each credit card data corresponds to a credit card that has been approved by the banking unit, and the credit card information includes, for example, a credit card number and a valid year and month, but is not limited thereto. The identification information of the card corresponding to each credit card data is, for example, the identity information provided to the banking unit when the user applies for the credit card. Specifically, in this embodiment, each card identification information includes, for example, an identity card. Font size, date of birth and a communication material, but not limited to this.

Specifically, for each credit card data, when the credit card information has just been created and stored in the second server 12 (that is, the credit card corresponding to the credit card data has just passed the review of the bank unit) The credit card information is preset to a first state, and the credit card data can also be set by the second server 12 to a second state, a third state, or a fourth state. Specifically, in the present embodiment, the first state represents that the credit card information has not passed a credit card opening procedure and is not allowed to be used for consumption in the particular electronic wallet application. The second state represents that the credit card profile has passed the credit card issuer but is not allowed to be used for consumption in the particular e-wallet application. The third status means that the credit card information has not been passed the credit card opening procedure, but has been allowed to be used for consumption in the particular electronic wallet application. The fourth state then indicates that the credit card data has passed the credit card opening procedure and has also been allowed to be used for consumption in the particular electronic wallet application. In addition, the aforementioned credit card opening procedure generally refers to the voice or network established by the banking unit based on at least the credit card information printed on the credit card after the user receives the credit card entity newly issued by the bank unit. The system performs the procedure of logging in to open the card, which can be understood by those of ordinary skill in the art, so the details thereof will not be described in detail herein.

Specifically, in this embodiment, each wallet user identification data and each card household identification data each include a corresponding identity card number, date of birth, and communication data of the user. Therefore, taking the user A as an example, if the user A owns the electronic wallet account and holds the credit card issued by the bank unit, the wallet user identification data stored by the first server 11 will be There is a wallet user identification data corresponding to the user A, and the card identification data corresponding to the user A is also present in the card identification data stored by the second server 12, and The wallet user identification data of the user A should match the card identification data corresponding to the user A.

Referring to FIG. 1 and FIG. 2 (FIG. 2a and FIG. 2b), the following describes exemplarily how the transaction system 1 of the present embodiment implements a credit card binding method.

First, step S1 is performed. When receiving the credit card binding request from the user terminal 5 and including an identity data, the first server 11 determines whether there is a target corresponding to the identity data in the wallet user identification data stored therein. Wallet user identification data. When the determination result of the first server 11 is NO, the process proceeds to step S2. When the determination result of the first server 11 is YES, the process proceeds to step S3. It is to be noted that, in this embodiment, the credit card binding request is generated by the user terminal 5 in the state of logging in to the first server 11 according to the user's operation, but is not limited thereto.

In step S2, when the first server 11 determines that the target wallet user identification data does not exist in the wallet user identification data (that is, there is no wallet user identification data corresponding to the identity data), The first server 11 generates and transmits an identity recognition failure notification to the user terminal 5 for the user terminal 5 to output the identity recognition failure notification. In this embodiment, the identity recognition failure may indicate, for example, "user identification data input error", but is not limited thereto.

In step S3, when the first server 11 determines that the target wallet user identification data corresponding to the identity data exists in the wallet user identification data, the target wallet user identification data is transmitted to the second server. 12. Next, step S4 is performed.

In step S4, when the second server 12 receives the target wallet user identification data from the first server 11, it is determined whether there is a target wallet user in the card identification data stored therein. Identify a target cardholder identification data that matches the data. When the determination result of the second server 12 is NO, the process proceeds to step S5. When the determination result of the second server 12 is YES, the process proceeds to step S6.

In step S5, when the second server 12 determines that the target card identification data does not exist in the card identification data (that is, there is no card identification data corresponding to the target wallet user identification data) And generating a corresponding first instruction to the first server 11 to control the first server 11 to generate and transmit a corresponding first alert notification to the use end 5 output according to the first instruction. In this embodiment, the first alert notification may indicate, for example, "no credit card holding/submission data", but is not limited thereto.

In the step S6, when the second server 12 determines that the target card identification data corresponding to the target wallet user identification data exists in the card identification data, the second server 12 generates a single-shot. a One Time Password (OTP), and transmitting the one-time password in the form of a short message to the mobile device corresponding to the communication data according to the communication data included in the target card identification data (not shown) . For example, in the foregoing user A, if the target wallet user identification data described in step S3 is the wallet user identification data corresponding to the user A, the target described in this step S6 is The card identification data is the card identification data corresponding to the user A. It should be noted that the mobile device for receiving the one-time password may be, for example, the user terminal 5 itself, or may be another smart phone different from the user terminal 5 . The second server 12 transmits the one-time password to the mobile device, and then proceeds to step S7.

In step S7, when the second server 12 receives a verification password from the user terminal 5, it is determined whether the verification password matches the one-time password. When the determination result of the second server 12 is NO, the process proceeds to step S8. When the determination result of the second server 12 is YES, the process proceeds to step S11 (shown in Fig. 2b).

In step S8, when the second server 12 determines that the verification password does not match the one-time password, the second server 12 further determines that the verification password is itself received and determines the verification password and the Whether the number of times the one-time password does not match reaches a predetermined number of times. In this implementation, the predetermined number of times may be, for example, three times, but not limited thereto. When the determination result of the second server 12 is NO, step S9 is next performed. When the determination result of the second server 12 is YES, the process proceeds to step S10.

In step S9, when the second server 12 determines that the number of times the verification password does not match the one-time password has not reached the predetermined number of times, generating and transmitting a second warning related to the verification password. Notify the output to the user terminal 5. In this embodiment, the second alert notification may indicate, for example, "authentication password input error", but is not limited thereto. Next, step S7 is performed again.

In step S10, when the second server 12 determines that the number of times the verification password does not match the one-time password has reached the predetermined number of times, generating and transmitting a third number related to the verification password. The notification is sent to the user terminal 5 for output, and the credit card binding method ends. In this embodiment, the third alert notification may indicate, for example, that "the number of times the password is incorrectly verified has reached the upper limit, please re-operate", but not limited thereto.

In the step S11 (shown in FIG. 2b) following the step S7, the second server 12 further determines whether a target credit card data corresponding to the target card identification data in the credit card data is in the first state or The second state, that is, determining whether the target credit card profile is in an unbound state that is not allowed to be used for consumption in the particular e-wallet application. When the determination result of the second server 12 is NO, the process proceeds to step S12. When the determination result of the second server 12 is YES, the process proceeds to step S13.

In step S12, when the second server 12 determines that the target credit card data is not in the first state, it is not in the second state (that is, not in the unbound state), but is in the third state. Or when the fourth state (ie, in a bound state that has been allowed to be used for consumption in the particular e-wallet application), generating and transmitting a second command to the first server 11, The first server 11 generates a corresponding fourth alert notification to the user terminal 5 according to the second instruction. In this embodiment, the fourth alert notification may indicate, for example, that "your credit card is bound", but not limited thereto.

In the step S13 after the step S11, when the second server 12 determines that the target credit card data is in the first state or the second state (that is, it is determined that the target credit card data is in the unbound state) The second server 12 generates a list of bindable credit cards including the target credit card data, and transmits the bindable credit card list to the user terminal 5 for output. Next, step S14 is performed.

In step S14, the second server 12 sets the target credit card data to the third state or the fourth state when receiving a binding instruction from the user terminal 5 and indicating the target credit card data. That is, the target credit card data is set to the bound state) to allow the credit card corresponding to the target credit card data to be used for consumption in the specific electronic wallet application, and the second server 12 further A binding request containing the target credit card data is generated and transmitted to the first server 11. Specifically, if the second server 12 determines in step S11 that the target credit card data is in the first state, the second server 12 sets the target credit card data to the third in this step. a state, on the other hand, if the second server 12 determines in step S11 that the target credit card data is in the second state, the second server 12 sets the target credit card data as the The fourth state. It should be noted that the binding instruction is generated, for example, by the user terminal 5 according to an operation performed by the user on the bindable credit card list. Next, step S15 is performed.

In step S15, when receiving the binding request from the second server 12, the first server 11 generates and stores a target credit card data corresponding to the target wallet according to the binding request. Binding credit card information, whereby the first server 11 is equivalent to binding the target credit card data to the electronic wallet account corresponding to the target wallet user identification data, so that the target credit card data can be used by the target wallet The e-wallet account corresponding to the user identification data is used for consumption. Next, step S16 is performed.

In step S16, the first server 11 generates and transmits a binding success notification to which the credit card data should be bound to the user terminal 5, so that the user terminal 5 can output the binding success notification.

In addition, after the bank unit approves the credit card applied by the user, the bank unit sends the physical credit card to the user by post. Since the mailing process takes time, there may be several days between the issuance of the credit card by the bank unit and the actual receipt of the credit card by the user, that is, the user cannot start using the bank unit’s nuclear card within the first time. credit card.

However, the transaction system 1 of the present embodiment can solve the aforementioned inconvenience. For example, the user A in the foregoing, in step S11, if the target credit card data is in the first state (ie, has not passed the credit card opening procedure and is not allowed to be used in the specific electronic wallet application) The status of the consumer to purchase may indicate that the user A has not received the credit card corresponding to the target credit card data, and the credit card opening procedure cannot be performed on the credit card. However, in step S14, the target credit card data is set to the third state by the second server 12 (ie, has not been used by the credit card issuing program but is allowed to be used in the specific electronic wallet application). In the state of consumption, the target credit card data can be used for consumption in the specific electronic wallet application, and therefore, in step S15, the first server 11 generates and stores the bound credit card data. After that, even if the user A has not received the credit card corresponding to the target credit card data and cannot perform the credit card opening procedure, the user can still use the target credit card data for consumption in the specific electronic wallet application. The transaction system 1 of an embodiment enables a user to begin using a credit card through the particular e-wallet application within the first time that the credit card is approved by the banking unit.

In summary, the transaction system 1 of the embodiment can implement the credit card binding method, so that the user can conveniently and quickly complete the credit card and the electronic without inputting the credit card number, the effective year and month, and the security check code. Binding between wallet accounts, completely overcoming the inconvenience of the prior art. In addition, the transaction system 1 of the embodiment can also be used for the user to bind the credit card to the e-wallet account through the specific e-wallet application before the approved credit card is received, and thus can be achieved. The purpose of this new type.

However, the above is only the embodiment of the present invention, and when it is not possible to limit the scope of the present invention, all the simple equivalent changes and modifications according to the scope of the patent application and the contents of the patent specification are still This new patent covers the scope.

1‧‧‧ trading system

11‧‧‧First server

12‧‧‧Second server

5‧‧‧Use side

S1~S16‧‧‧Steps

Other features and effects of the present invention will be apparent from the following description of the drawings, wherein: FIG. 1 is a schematic diagram of a hardware block of an embodiment of the present transaction system coupled to a user terminal; 2 (consisting of Figures 2a and 2b) is a flow chart that exemplarily illustrates how the embodiment implements a credit card binding method.

Claims (5)

A transaction system, configured to be electrically connected to a user terminal, the transaction system comprising: a first server storing a plurality of wallet user identification data respectively corresponding to the plurality of electronic wallet accounts; and a second server, electrically connecting The first server stores a plurality of credit card data and a plurality of card identification data corresponding to the credit card data respectively; wherein the first server receives a credit card from the user end and includes an identity data Determining the request, and determining that the target wallet user identification data corresponding to the identity data exists in the wallet user identification data, transmitting the target wallet user identification data to the second server; the second server receiving Generating and transmitting a bindable data to the target wallet user identification data from the first server, and determining that a target cardholder identification data corresponding to the target wallet user identification data exists in the cardholder identification data a list of credit cards to the user end, the list of bindable credit cards including the credit card data corresponding to the target card identification data And the credit card data used as a target credit card data; the second server transmits the target credit card data to the first server after receiving a binding instruction from the user end and indicating the target credit card data When the first server receives the target credit card data from the second server, the first server generates and stores a binding credit card data including the target credit card data and corresponding to the target wallet user identification data. The transaction system of claim 1, wherein each of the card identification data includes at least one communication material corresponding to a mobile device, and the second server determines that the target card user exists in the card identification data. When the data is identified, a one-time password is first generated, and the one-time password is transmitted to the corresponding mobile device according to the communication data included in the target card identification data, and the second server receives the data. When a verification password from the user end is determined and the verification password is determined to be consistent with the one-time password, the bindable credit card list is generated and transmitted to the user. The transaction system of claim 2, wherein: when the second server determines that the target card identification data does not exist in the card identification data, controlling the first server to generate and transmit a first alert notification When the second server receives the verification password and determines that the verification password does not match the one-time password, generating and transmitting a second warning notification related to the verification password to the user end And generating, by the second server, a third alert related to the verification password when the second server determines that the verification password is received and the number of times the verification password does not match the one-time password reaches a predetermined number of times Notify to the user. The transaction system of claim 1, wherein the second server receives the binding instruction, and determines that the target credit card data is not in a credit card opening procedure and is not allowed in the specific electronic wallet. When the application is used for consumption, the second server also sets the target credit card data to a state that is not used by the credit card issuer but is allowed to be used for consumption in the specific electronic wallet application. . The transaction system of claim 1, wherein the first server generates and transmits an identity identification failure notification when the first server determines that the target wallet user identification data does not exist in the wallet user identification data. To the end of the use.