HYBRID PAYMENT SMARTCARD
Field of Invention
The invention relates to a payment card, and in particular, but not limited to, contactless smartcards.
Background
Debit cards are well known, comprising a plastic card which is used at a point of sale to communicate with the user's bank and authorise a transaction. Advantageously the transaction is guaranteed as the payment is deducted directly from the user's bank account. However a disadvantage of this system is that if communication with the bank is unavailable or interrupted, the transaction cannot be completed.
Electronic payment systems such as Touch 'n Go have been used in Malaysia for many years. The system utilises prepayments wherein cash is stored on a credit card sized smartcard made of plastic with microchip technology embedded therein.
A user loads the smartcard with cash using a dedicated reload machine or via the ATM of certain banks. The smartcard can then be used at appropriate points instead of cash or tickets, simply by pressing the smartcard against the relevant terminal, whereupon the relevant amount of cash is deducted from the smartcard. The advantages of this system are that the requirements for buying individual tickets and for handling cash at each transaction is removed, and because the cash is prepaid i.e. stored on the smartcard, communication with the user's bank is not required.
However, the cash on existing smartcards can only be used for transactions at the designated terminals, and not for example for internet transactions.
An aim of the invention is to provide a smartcard system which can also be used for internet transactions.
Summary of Invention
In an aspect of the invention, there is provided a smartcard system comprising:
a smartcard on which is stored cash defined by one or more values, including an offline limit value and a secured value;
a server on which a user can create an account and a recorded value is stored; one or more transaction terminals capable of communication with the server, the transaction terminals being capable of reading and/or writing a value on the smartcard;
such that at or after the time the smartcard is used for a transaction, the offline limit value is reduced by an amount corresponding to the transaction, and the transaction terminal communicates at least the offline limit value of the smartcard to the server;
characterised in that the server sends an instruction to at least one transaction terminal to decrease the secured value by said amount and increase the offline limit value by said amount when the smartcard is next used for a transaction.
Thus the server administrates the cash flow between the offline limit value and secured value such that at least the cash defined by the offline limit value can be used for transactions at terminals, whereas the cash defined by the secured value can be used for internet transactions as described below.
In one embodiment the server sends the instruction if the offline limit value falls below a predetermined threshold. In one embodiment the value displayed to the user is the total value of the offline limit value and the secured value. Thus the cash flow is typically hidden from the user.
In one embodiment the server sends an instruction to maintain the offline limit value and secured value in a specific ratio. For example the server may maintain the combined balance on the smartcard as 70% in the secured value and 30% in the offline limit value. In one embodiment the secured value of the smartcard is the recorded value most recently communicated from the server to the transaction terminals.
In one embodiment, an amount of cash is stored in the user's account, such that if the secured value falls below a predefined threshold, the server deducts a predetermined amount of cash from the user's account and sends an instruction to at least one transaction terminal to increase the offline limit value and/or secured value by amounts totalling the predetermined amount when the smartcard is next used for a transaction. The recorded value is also updated as appropriate.
Therefore as the server pushes an amount of cash from the secured value to the offline limit value, the amount useable for terminal transactions is automatically reloaded while the remainder of the secured value is assured. In addition, the system has the advantage that communication with the server to approve the terminal transaction is not required during the terminal transaction as the top-up occurs at the subsequent terminal transaction. Thus the smartcard informs the server that the offline limit value is low, after a first terminal transaction if communication is not immediately available, and is topped up when the next terminal transaction occurs, the server having instructed the terminal to do so in the meantime.
In a further embodiment, the offline limit value is set to 0, such that the balance on the smartcard is defined by the secured value. In such circumstances, transactions can only take place if communication with the server is available. The smartcard is therefore a hybrid payment card in that it stores an amount of cash thereon like a prepayment card as an offline limit value, which can also be topped up automatically with an assured amount, akin to a direct debit card, via amendment of the secured value, which can also be used for internet transactions. Advantageously the smartcard is not linked directly to a user's bank account, so if the smartcard is lost or stolen, the risk of significant loss is minimal.
In one embodiment a transaction terminal has to be registered with the smartcard to enable the transaction terminal to read and/or write the smartcard. Typically the transaction terminal is registered by entering a personal identification number (PIN).
In one embodiment the PIN is the last four digits of the user's identification card, but it will be appreciated that any sequence of characters could be used.
In one embodiment the instruction is sent to all the registered transaction terminals. Typically the instruction has a unique identifier which is also written to the smartcard when the offline limit value and/or secured value is increased, to prevent the same instruction being illegitimately applied multiple times.
In one embodiment the smartcard is registered to the user's account on the server by providing details of the user's name, bank account and identification card number, or other identity means. Typically the details are provided to the server by SMS using a mobile phone.
In one embodiment the server sends an instruction to the terminal to write the identification card number and mobile phone number to the smartcard when it is used.
In one embodiment the server sends an SMS to the user's mobile phone to ask for approval to increase a value on the smartcard when it falls below the corresponding threshold, and/or to confirm the update to value.
In one embodiment an administrator sets the thresholds, but it will be appreciated that the user could also be authorised to do this. In one embodiment the user can conduct other transactions using the recorded value, such as internet transactions. Typically, if the user conducts an internet transaction, the server sends an instruction to at least one transaction terminal to decrease the secured value by the transaction amount when the smartcard is next used for a transaction.
In one embodiment the amount that the user can spend in a transaction is the sum of the cash in the user's account and the cash defined by the recorded value. Thus the user can spend more in an internet transaction than is held in the user's account if the additional amount is within the recorded value corresponding to the secured value stored on the smartcard. In one embodiment, if a transaction is made using the cash in the user's account, which exceeds the amount of cash in the user's account, an instruction is sent to at least one transaction terminal to decrease the secured value by the amount exceeded when the smartcard is next used for a transaction. Thus the server debits the smartcard by the amount by which the transaction exceeded the amount in the user's account.
In one embodiment cash can be transferred from the account or smartcard of one user to the account or smartcard of another user via mobile phone or web terminal. Typically an SMS or web instruction is sent from a first user to the server including details of the second user's account or smartcard, and the transfer amount. Typically the server amends the respective secured values accordingly.
In one embodiment the smartcard can be disabled by sending an SMS to the server or calling a pre-specified number associated with the server. Thus the smartcard can be blocked if it is lost or stolen. In one embodiment the user can send a request to top up the amount of cash defined by the secured value via SMS, or calling a specified telephone number. Typically the account on the server or the secured value is topped up from the user's bank account. In a further aspect of the invention, there is provided a method of using a smartcard comprising the following steps:
cash is stored as a total value comprising an offline limit value on a smartcard and a secured value on the smartcard, the cash defined by the offline limit value being useable at one or more transaction terminals in respect of payment for goods and/or services;
such that when a transaction terminal is used it reads at least the offline limit value on the smartcard and if sufficient for the payment, deducts a corresponding amount and writes a new offline limit value;
during or after the time of payment, the transaction terminal communicates at least the offline limit value of the smartcard to a server on which a user has an account;
characterised in that after the transaction has been performed, the server sends an instruction to at least one transaction terminal to decrease the secured value by said amount and increase the offline limit value by said amount when the smartcard is next used for a payment.
In one embodiment the server sends an instruction if the offline limit value on the smartcard falls below a predetermined threshold. In one embodiment the user creates the account on the server by using their mobile phone to send their details via SMS to the server to register the smartcard with the server. Typically the server sends an instruction to the terminal to write the user's details and mobile phone number to the smartcard when it is first used.
In one embodiment the user enters a personal identification number when a transaction terminal is first used with the smartcard to register the transaction terminal with the smartcard for a specified period of time and allow the transaction terminal to read and/or write the smartcard. Typically the instruction is sent to all the registered transaction terminals.
In one embodiment the secured value of the smartcard is stored as a recorded value on the server. Typically the secured value is the recorded value most recently communicated from the server to the transaction terminals. Typically the cash defined by the recorded value can be used for internet transactions. Typically an instruction is sent to at least one transaction terminal to decrease the secured value by the internet transaction amount when the smartcard is next used for a payment. In one embodiment, the user stores an amount of cash in the account on the server, such that if the secured value falls below a predefined threshold, the server deducts a predetermined amount of cash from the account and sends an instruction to at least one transaction terminal to increase the offline limit value and/or secured value by amounts totalling the predetermined amount when the smartcard is next used for a transaction.
In one embodiment the user can make payments for internet transactions using the cash in the account on the server. Typically if payment for an internet transaction is made using the cash in the server account, which exceeds the amount of cash in the server account, an instruction is sent to the registered transaction terminals to decrease the secured value by the amount exceeded, when the smartcard is next used for a payment.
In a yet further aspect of the invention there is provided a smartcard as herein described.
Brief Description of Drawings
It will be convenient to further describe the present invention with respect to the accompanying drawings that illustrate possible arrangements of the invention. Other arrangements of the invention are possible, and consequently the particularity of the accompanying drawings is not to be understood as superseding the generality of the preceding description of the invention.
Figure 1 is a schematic view of a smartcard system according to an embodiment of the invention. Detailed Description
Figure 1 illustrates a smartcard system comprising a server 2 on which a user of smartcard 20 has an account, and a plurality of transaction terminals 4, 6, 8, 10, 12 in communication with the server 2. The transaction terminals 4, 6, 8, 10, 12 can read or write to a smartcard 20 to perform sales or top-up transactions.
The smartcard 20 stores cash, defined by an offline limit value and a secured value, which can be used in transactions.
A sales transaction is a transaction where one or more of the values stored in the smartcard is decreased whereas a top-up transaction is a transaction where one or more of the values stored in the smartcard is increased. There are many ways a smartcard may be registered and associated with a user. For example when a smartcard 20 is sold, the user is also given a PIN associated with the smartcard so that he may register online (using the smartcard serial number and the PIN) to create a web account. He may also register his mobile phone 14 at the same time.
All smartcard transactions done on terminals are sent back to the server. The user may view these transactions records and to effect transactions using his web account. The user may also perform online (Internet) transaction using his web account. Before a sales transaction can be performed on a terminal for the first time, the smartcard must first be registered 18 with the terminal 4. This may be done by the user entering a personal identification number when prompted.
Transactions are only allowed when a correct PIN is entered and the smartcard can thus be associated with this terminal, preferably for a certain timeframe. Prior to expiry of this timeframe, the user need not re-enter the PIN for each transaction. In this manner, there may be hundreds of terminals out there, but there are only very few terminals associated to a particular smartcard. This is to ease communication between the server and the POS terminal. For example, to blacklist a smartcard, a BlackList instruction is only required to be sent to those terminals associated to the smartcard and not the totality of the terminals. In the association process, the terminal may preferably be online so that the smartcard can be checked to see if it has been cancelled and for the data on the smartcard to be updated. The server 2 keeps a record of the registered terminals for each smartcard. Of course, there also may be General terminals where no pre-registration is required such as the ones that need to process very high transaction volume speedily, e.g. the POS terminal found on buses. For such terminals, even upon first use, the user may not be required to enter a PIN. However, these terminals usually only accept small transactions and hence the fraud risks are mitigated.
The smartcard 20 can be used as a prepayment cash card on a terminal in much the same way as a Touch 'n Go card. However, the smartcard of the invention may store two values, namely an offline limit value and a secured value, the sum of which comprise the combined balance visible to the user.
After every transaction, the terminal shall communicate the transaction details back to server 2. The corresponding value of the secured value of smartcard 20 is stored as the recorded value on the server 2.
When a sales transaction is performed at a terminal and the sales value does not exceed the offline limit value, the offline limit value is decreased.
Advantageously, for a sales value not exceeding the offline limit value, the smartcard can be used with transaction terminals even when these are offline i.e. when there is no communication between the transaction terminals and the central server 2.
In the following example, the secured value is RM70, the offline limit value is RM30, so the combined balance on the card is RM100. When the smartcard is used 22 for a sales transaction of RM20, the offline limit value is reduced by the sales amount (to RMIO). Then the transaction terminal 8 informs 24 the server 2 of the sale, and server 2 then deducts the sales amount (RM20 in this example) from the recorded value (leaving RM50 in this example). The server 2 then sends an instruction 26, 28, 30 to the registered transaction terminals 6, 8, 10 to increase the offline limit value and at the same time decrease the secured value by the sales amount when the smartcard 20 is next used for a transaction. As a result the smartcard would then have a secured value of RM50 and an offline limit value is RM30.
The instruction 26, 28, 30 has a unique identifier which is also written to the smartcard so that when one of the other registered terminals 6, 10 is used, the same instruction is not executed twice.
In the example above, as the sales transaction is less than the offline limit value, immediate communication between the transaction terminal and server is not required, and the transaction can take place offline
If however the sales value exceeds the offline limit value but does not exceed the combined balance, the terminal must be online (i.e. where realtime communication is possible between the terminal and the server) for the transaction to go through. When communication is possible, the totality of the combined balance may be used for the sales transaction. Thus where the secured value is RM70 and the offline limit value is RM30, a sales transaction of RM45 would result in the smartcard subsequently having a secured value of RM25 and an (unchanged) offline limit value of RM30. The recorded value on the server would reflect that of the secured value of the smartcard i.e. RM25.
The portion of the combined balance that is allocated to the secured value and offline limit value may be varied depending on the different card types or applications. In the examples above, the system always tries to maintain RM30 in the offline limit value, and if the combined balance falls below RM30, the whole portion is kept only in the offline limit value. In another example, for a combined balance of RM100, the portion allocated to the offline limit value is always set to RMO and the secured value RM100 - in this case, the terminal must be online for any sales transaction to go through. As a yet further example, the combined balance may be allocated based on ratio, say 70% to the offline limit value and 30% to the secured value.
As a sales transaction exceeding that of the offline limit value cannot go though without the server's knowledge, the recorded value on server 2 can be used independently for sales or transactions going through server 2. This is especially useful for e-commerce or Internet purchases.
In the example where a card has a total balance of RM100 and an offline limit value of RM30 is imposed, the central server knows that RM70 is the recorded balance of the card and hence the customer can safely conduct online transactions up to a total of RM70. If for example the customer spends RM50 online, i.e. for Internet or e- commerce purchases, RM50 is deducted from the recorded value and the secured value on the card is updated to reflect the reduced total balance via the registered terminals the next time the card is used.
Even when connectivity is available between the server and terminals, it may be better for the terminals to be operating in an autonomous mode where transactions may be done/approved immediately so that there is no delay if the sales value does not exceed the offline limit value. In such autonomous mode, the transaction data is then sent back to the central server in a leisurely manner - it is not really important if the server is informed about the transaction immediately, it but could be minutes or hours later, or by batch.
A user can also pay for online transactions 34 to a third party 36 using the recorded value on the server 2. After a sales transaction is completed by the server using the recorded value, an instruction is sent to the registered transaction terminals 6, 8, 10 to decrease the secured value by the sales value when the smartcard 20 is next used for a transaction.
Furthermore the user can transfer cash from their smartcard 20, to the smartcard 60 of another user, such as by sending an SMS text message (via mobile phone 14) with the relevant details to the server 2 or a secured web instruction 44 via web terminal 40. Typically the server deducts an amount from the recorded value associated with smartcard 20, at the same time updates the recorded value associated with smartcard 60, and also sends an instruction 66 to the registered terminals 6, 8, 10, 12 of the smartcards 20, 60 so that their secured and offline limit values can be amended 64 accordingly when the smartcards 20, 60 are next used 62 at the terminals.
It should be noted that only the combined balance of a card is visible to the user - the complexity of the secured and offline limit values and how they are updated is unknown to the user. With this invention, it would seem to the user that he has a prepaid card having a balance which can be used for both over-the-counter and Internet purchases. He may even transfer some money (as dictated by the recorded value) from his smartcard to another smartcard which may be located some distance away. Such features are not present in current state of the art systems.
It will be appreciated by persons skilled in the art that the present invention may also include further additional modifications made to the device which does not affect the overall functioning of the device.