CA2384927A1 - Cash initiated system for paying web transactions - Google Patents
Cash initiated system for paying web transactions Download PDFInfo
- Publication number
- CA2384927A1 CA2384927A1 CA002384927A CA2384927A CA2384927A1 CA 2384927 A1 CA2384927 A1 CA 2384927A1 CA 002384927 A CA002384927 A CA 002384927A CA 2384927 A CA2384927 A CA 2384927A CA 2384927 A1 CA2384927 A1 CA 2384927A1
- Authority
- CA
- Canada
- Prior art keywords
- voucher
- consumer
- merchant
- payment
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/28—Pre-payment schemes, e.g. "pay before"
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/342—Cards defining paid or billed services or quantities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/02—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices
- G07F7/025—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices by means, e.g. cards, providing billing information at the time of purchase, e.g. identification of seller or purchaser, quantity of goods delivered or to be delivered
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce
Description
r TEM File No. 246.1 TITLE: CASH INITIATED SYSTEM FOR PAYING WEB TRANSACTIONS
s FIELD OF THE INVENTION
The present invention relates to electronic commerce on the World Wide Web (referred to herein as the "Web"), generally, and in particular relates to the ability to make cash-based payments on the Web.
1o BACKGROUND OF THE INVENTION
The number of e-commerce transactions is increasing dramatically.
Estimated B2B (Business to Business) transactions in 2001 are just under one trillion US dollars. By the end of 2004, B2B transactions are expected to reach
s FIELD OF THE INVENTION
The present invention relates to electronic commerce on the World Wide Web (referred to herein as the "Web"), generally, and in particular relates to the ability to make cash-based payments on the Web.
1o BACKGROUND OF THE INVENTION
The number of e-commerce transactions is increasing dramatically.
Estimated B2B (Business to Business) transactions in 2001 are just under one trillion US dollars. By the end of 2004, B2B transactions are expected to reach
2.5 trillion US dollars annually, and up to 4.3 trillion US dollars annually by 2005.
is Impressive compound growth of 68%, 91 % and 109% is expected for the USA, Western Europe and Asia-Pacific, respectively, between 200'1 and 2005. B2C
(Business to Consumer) volume in the US has been estimated at just under US$50 billion for 2001 and growing.
Currently Web payments are made by a handful of established systems, 2o the predominant one being credit cards. There are about a half dozen other payment systems which enjoy varying degrees of acceptance by Web merchants and consumers. The sustainability and growth of such other systems and any future new systems will depend on their ability to achieve broad acceptance by merchants and consumers alike. Credit cards, on the other hand, are the principal choice of merchants as they are the main choice of consumers because they have been in existence the longest and vast global coverage has been built up over the years.
s Some of the above-noted payment systems are briefly set out below, together with their advantages and disadvantages.
1. Credit Cards: They are the choice of a vast number of merchants and consumers on the Web, but both eligible merchants and consumers have to first qualify from the issuing financial institution to be able to deal in andlor io use the cards. A large number of merchants and consumer s do not qualify, and hence they cannot accept or use credit cards. Additionally, many credit card holders are apprehensive about using credit cards over' the Internet because of fears and risks of misuse of information.
2. CyberCash: After sending a credit card or bank account number, the is consumer is issued an "electronic wallet" with an encryption process giving the consumer the ability to pay a Web merchant. This system requires a consumer to have means to transfer funds (credit card, bank account or wire transfer) to CyberCash, which is an intermediary.
is Impressive compound growth of 68%, 91 % and 109% is expected for the USA, Western Europe and Asia-Pacific, respectively, between 200'1 and 2005. B2C
(Business to Consumer) volume in the US has been estimated at just under US$50 billion for 2001 and growing.
Currently Web payments are made by a handful of established systems, 2o the predominant one being credit cards. There are about a half dozen other payment systems which enjoy varying degrees of acceptance by Web merchants and consumers. The sustainability and growth of such other systems and any future new systems will depend on their ability to achieve broad acceptance by merchants and consumers alike. Credit cards, on the other hand, are the principal choice of merchants as they are the main choice of consumers because they have been in existence the longest and vast global coverage has been built up over the years.
s Some of the above-noted payment systems are briefly set out below, together with their advantages and disadvantages.
1. Credit Cards: They are the choice of a vast number of merchants and consumers on the Web, but both eligible merchants and consumers have to first qualify from the issuing financial institution to be able to deal in andlor io use the cards. A large number of merchants and consumer s do not qualify, and hence they cannot accept or use credit cards. Additionally, many credit card holders are apprehensive about using credit cards over' the Internet because of fears and risks of misuse of information.
2. CyberCash: After sending a credit card or bank account number, the is consumer is issued an "electronic wallet" with an encryption process giving the consumer the ability to pay a Web merchant. This system requires a consumer to have means to transfer funds (credit card, bank account or wire transfer) to CyberCash, which is an intermediary.
3. DigiCash: This system requires a bank to be part of its system for accepting zo cash withdrawn from consumers' bank accounts, and uses software to store this cash in the consumers' computer hard drives for payment to merchants.
This again requires the consumers to first make a deposit to the DigiCash system via credit card or bank account.
This again requires the consumers to first make a deposit to the DigiCash system via credit card or bank account.
4. eCHARGE and iBill: These systems bill the consumer through a 1-900 phone number and are limited to people owning phones, and as well are s limited in the number of transactions that can be made over a period.
In sum, most prior art systems require a consumer to be <able to make a transfer of funds to the "paymasters", or the consumer must have a credit card or communication device like a telephone or mobile phone on which charges can be made. Even so, the consumer has to first be assessed as creditworthy by a 1o phone company in order to take a charge. Credit cards, which have the highest e-commerce usage, are prone to fraud by hackers and merchants.
What is therefore desired is a novel method and system which overcomes the limitations and disadvantages of the existing methods and systems.
is SUMMARY OF THE PRESENT INVENTION
The methods and systems of the present invention, sometimes referred to herein as the "CIT"" payment system", or "CIT"" system", were developed because there are many consumers in the world-wide marketplace that do not have means of Web payment or credit cards, either because they fail to qualify due to 2o bad credit, or are minors in law who cannot obtain such cards, or do not have access to such cards, or simply do not like to use credit cards tin the Web because of the fear of insecurity or divulging personal details. There are consumers in the third world who have no payment modes in their regions, but a common aspect with such consumers is that they have money and access to the Internet (also referred to as the "Net"), whether they are in the middle of Africa or the Amazon jungle. Hence, the present invention puts a system in place that s takes advantage of existing payment-system infrastructures without the need to "reinvent the wheel".
BRIEF DESCRIPTION OF THE DRAWING FIGURES
Embodiments of the invention will now be described, by way of example so only, with reference to the accompanying drawings, wherein:
Figure 1 depicts a voucher employed in the systems and methods according to a preferred embodiment of the present invention;
Figure 2a depicts a flow chart of the steps performed in one embodiment of the method of the present invention;
15 Figure 2b depicts an alternate embodiment of the step:; performed in an alternate embodiment of the method of the present invention;
Figure 3 shows a sample Web page for a user of the present system; and, Figure 4 shows a table of the estimated users of the Web by global regions.
2o _q_ LIST OF REFERENCE NUMBERS IN DRAWINGS
20 - The voucher (or its contents) which is dispensed from a point of sale (POS) be it a bank counter, automatic teller machine (ATM), on-line terminal or other venue.
s 22 - The identification number of the issuer or seller of the voucher. In the case of an ATM or on-line terminal the identification number of the owner of the ATM
or on-line website.
24 - Three fields, each of numeric, alphabetical and alphanumeric code respectively.
so 26 - The usable or face value for which the voucher has been purchased.
28 - A barcode embodying information 22 and 24.
30 - The user who purchases the voucher, also referred to as the consumer or customer 32 - The issuer or seller of the voucher.
is 34 - The system server of the issuer or seller of the voucher 36 - The system server of the CI system 38 - The merchant conducting business over the Internet (or Web) 40 -The payment processor, or sometimes referred to as an acquiring processor, who is an intermediary enabling settlement of transactions between credit card ao consumers, their issuing financial institutions and the Internet merchant.
42 - The merchant bank is the bank of the Internet merchant 38 -s-44 -The designated account is the account where the issuer or seller of the voucher deposits the proceds of the sale of vouchers.
50 - A drop-down box enabling the user 30 to choose the type of currency on the voucher s 52 - The blank boxes allowing for multiple voucher usage 54 - A drop-down box giving the user 30 the option to choose the currency in which he wishes to have the total displayed.
56 - The key or button to commence processing of the transaction DESCRIPTION OF PREFERRED EMBODIMENTS
The method and system of the present invention is a remote, anonymous, simple, low-risk, versatile and mutt-market targetable Web-payment system that has the potential of rivalling the dominance of credit cards. In essence the s invention provides for a voucher to be purchased for a sum of money (from a seller) which bears identification (ID) codes. The codes correspond to that sum of money, and these ID codes are stored on the CI system server along with its corresponding sum of money . The CI system server is linked to the servers of other parties who are part of the CI system. Based on the implementing system, so anyone able to produce the subject ID codes correctly to the CI system and its links can have access to that money, be it for Internet purchases, money transfers or bill payments. This system can be utilised globally under multiple-currency platforms as long as electronic linkages are available. This provision for multi-currency payment truly gives the CI system global dimensions in that 1s vouchers in any currency issued in any country can be used for purchasing in and from any other country.
OVERVIEW
An overview of the present invention is first presented.
zo At a Point of Sale (POS), a user (also referred to herein as a consumer, purchaser or customer) intending to transact over the Internet purchases a voucher 20 (as illustrated in fig.1 ) for any denomination of money 26. The voucher contains thereon an identification number of the POS, or "Issuer" 22, and preferably three separate fields of numeric, alphabetical and alphanumeric code 24 and the denominated amount, or "usable value" 26. The data of the three fields 24 is bar-coded at 28. If the user has a bar-code reader attached to s his terminal it provide for easy transcription of code 24 to the merchant's payment website (described later with reference to Figure 3).
The sale of the voucher 20 to the purchaser is conducted by a human or automated counter attendant of the issuer receiving the money (by cash, cheque, bank account, credit card or other) from the purchaser and entering the 1o required information (to produce a voucher 20 for the amount of money received) into the issuer's system network, such as through a keyboard. The voucher is issued from a printing device which communicates with (i.e. is "connected to") the issuer's system network.
The issuer's system network is connected to the CI system's server (and 1s identified to the CI system server by its issuer ID no. 22) which generates the three codes 24 in fields 1, 2 and 3 and conveys them to the issuer's system to be printed on the voucher 20. These codes along with the issuer ID no. are now inventoried on the CI server and represent the denominated amount or usable value 26. The same information (codes 24 and monetary value 26) is also zo inventoried on the issuer's system.
_g_ The purchaser of this voucher 20 now has an ability to spend the denominated amount 26 at the site of any merchant accepting the CI payment system on its website.
A preferred method of commercially implementing the CI system is to s licence the CI system to existing Financial Institutions andlor payment processors (referred to herein collectively as "Fls") that are already issuers of credit cards and have an established network of e-commerce merchants.
Hence, unlike some prior art systems, the implementation of the present system would avoid the effort of signing up merchants from scratch, since such 1o merchant sign-up procedure is resource intensive and time con suming. The Fls would in essence use their Information Technology (IT) hardware which is already in place to connect to the CI system server, and in exchange for money from a customer would issue to that customer the above-noted voucher bearing the particulars corresponding to that amount of money. The codes 24 would be is based on a method of generating random numbers and have three separate fields of numbers to make fraud and duplication difficult. This voucher can be purchased over-the-counter at FI locations, at Automated Teller Machines (ATMs) or through on-line banking for any monetary denomination, with such codes 24 corresponding to that monetary amount 26. The codes are inventoried 2o on a server which is linked to the Fls system server and now represents a sum of money sold to a customer which can be used over the Web for transactions by means of entering and transmitting the codes on a merchant's website.
The amount 26 on the voucher can potentially be spent at any Net merchant of the FI (i.e. merchants of Fls that are authorized to accept credit cards over the Net). When the FI opts to be licensed under the CI system, the FI
will inform its merchants to register for the CI payment system and the FI
will s send software to the merchants to enable them to accept the CI payment system. Hence, by licensing the FI, the CI system benefits from an established network of merchants.
MORE DETAILED EXPLANATION
1o A more detailed example of the CI system of the present invention is now presented.
1. The method of the present invention is initiated when the coinsumer attends at an FI's counter (or ATM or on-line terminal ) and proceeds to purchase a voucher 20 (see fig.1) for, say, $135.00.
is 2. Upon receipt of the $135.00, the FI ~~~~, ~~ r~~~ holds the amount as a deposit in a designated account and the $135.00 deposit is provided with a corresponding code 24. With the money in the FI's account, the FI is now able to meet a payment to a merchant when the customer spends any or all of the $135.00 amount.
20 3. The code 24 corresponding to the amount of $135.00 is inventoried (i.e.
recorded) on both the CI system server and the FI system server.
u~ i 4. Once the consumer purchases the voucher, the consumer may then visit a Web merchant's site (which merchant is signed up already by the FI and onto the CI system) and makes a purchase for, say, $120.00 by entering the codes 24 from the voucher on the website (see figure 3) as well as any other s required details of shipping, under a Secure Sockets Layer (SSL) protocol, or like secure means. The accepting merchant's website will already have the option of choosing the CI payment system. After entering the necessary details, the consumer submits the transaction for processing by clicking the "submit" button or key on that website.
In sum, most prior art systems require a consumer to be <able to make a transfer of funds to the "paymasters", or the consumer must have a credit card or communication device like a telephone or mobile phone on which charges can be made. Even so, the consumer has to first be assessed as creditworthy by a 1o phone company in order to take a charge. Credit cards, which have the highest e-commerce usage, are prone to fraud by hackers and merchants.
What is therefore desired is a novel method and system which overcomes the limitations and disadvantages of the existing methods and systems.
is SUMMARY OF THE PRESENT INVENTION
The methods and systems of the present invention, sometimes referred to herein as the "CIT"" payment system", or "CIT"" system", were developed because there are many consumers in the world-wide marketplace that do not have means of Web payment or credit cards, either because they fail to qualify due to 2o bad credit, or are minors in law who cannot obtain such cards, or do not have access to such cards, or simply do not like to use credit cards tin the Web because of the fear of insecurity or divulging personal details. There are consumers in the third world who have no payment modes in their regions, but a common aspect with such consumers is that they have money and access to the Internet (also referred to as the "Net"), whether they are in the middle of Africa or the Amazon jungle. Hence, the present invention puts a system in place that s takes advantage of existing payment-system infrastructures without the need to "reinvent the wheel".
BRIEF DESCRIPTION OF THE DRAWING FIGURES
Embodiments of the invention will now be described, by way of example so only, with reference to the accompanying drawings, wherein:
Figure 1 depicts a voucher employed in the systems and methods according to a preferred embodiment of the present invention;
Figure 2a depicts a flow chart of the steps performed in one embodiment of the method of the present invention;
15 Figure 2b depicts an alternate embodiment of the step:; performed in an alternate embodiment of the method of the present invention;
Figure 3 shows a sample Web page for a user of the present system; and, Figure 4 shows a table of the estimated users of the Web by global regions.
2o _q_ LIST OF REFERENCE NUMBERS IN DRAWINGS
20 - The voucher (or its contents) which is dispensed from a point of sale (POS) be it a bank counter, automatic teller machine (ATM), on-line terminal or other venue.
s 22 - The identification number of the issuer or seller of the voucher. In the case of an ATM or on-line terminal the identification number of the owner of the ATM
or on-line website.
24 - Three fields, each of numeric, alphabetical and alphanumeric code respectively.
so 26 - The usable or face value for which the voucher has been purchased.
28 - A barcode embodying information 22 and 24.
30 - The user who purchases the voucher, also referred to as the consumer or customer 32 - The issuer or seller of the voucher.
is 34 - The system server of the issuer or seller of the voucher 36 - The system server of the CI system 38 - The merchant conducting business over the Internet (or Web) 40 -The payment processor, or sometimes referred to as an acquiring processor, who is an intermediary enabling settlement of transactions between credit card ao consumers, their issuing financial institutions and the Internet merchant.
42 - The merchant bank is the bank of the Internet merchant 38 -s-44 -The designated account is the account where the issuer or seller of the voucher deposits the proceds of the sale of vouchers.
50 - A drop-down box enabling the user 30 to choose the type of currency on the voucher s 52 - The blank boxes allowing for multiple voucher usage 54 - A drop-down box giving the user 30 the option to choose the currency in which he wishes to have the total displayed.
56 - The key or button to commence processing of the transaction DESCRIPTION OF PREFERRED EMBODIMENTS
The method and system of the present invention is a remote, anonymous, simple, low-risk, versatile and mutt-market targetable Web-payment system that has the potential of rivalling the dominance of credit cards. In essence the s invention provides for a voucher to be purchased for a sum of money (from a seller) which bears identification (ID) codes. The codes correspond to that sum of money, and these ID codes are stored on the CI system server along with its corresponding sum of money . The CI system server is linked to the servers of other parties who are part of the CI system. Based on the implementing system, so anyone able to produce the subject ID codes correctly to the CI system and its links can have access to that money, be it for Internet purchases, money transfers or bill payments. This system can be utilised globally under multiple-currency platforms as long as electronic linkages are available. This provision for multi-currency payment truly gives the CI system global dimensions in that 1s vouchers in any currency issued in any country can be used for purchasing in and from any other country.
OVERVIEW
An overview of the present invention is first presented.
zo At a Point of Sale (POS), a user (also referred to herein as a consumer, purchaser or customer) intending to transact over the Internet purchases a voucher 20 (as illustrated in fig.1 ) for any denomination of money 26. The voucher contains thereon an identification number of the POS, or "Issuer" 22, and preferably three separate fields of numeric, alphabetical and alphanumeric code 24 and the denominated amount, or "usable value" 26. The data of the three fields 24 is bar-coded at 28. If the user has a bar-code reader attached to s his terminal it provide for easy transcription of code 24 to the merchant's payment website (described later with reference to Figure 3).
The sale of the voucher 20 to the purchaser is conducted by a human or automated counter attendant of the issuer receiving the money (by cash, cheque, bank account, credit card or other) from the purchaser and entering the 1o required information (to produce a voucher 20 for the amount of money received) into the issuer's system network, such as through a keyboard. The voucher is issued from a printing device which communicates with (i.e. is "connected to") the issuer's system network.
The issuer's system network is connected to the CI system's server (and 1s identified to the CI system server by its issuer ID no. 22) which generates the three codes 24 in fields 1, 2 and 3 and conveys them to the issuer's system to be printed on the voucher 20. These codes along with the issuer ID no. are now inventoried on the CI server and represent the denominated amount or usable value 26. The same information (codes 24 and monetary value 26) is also zo inventoried on the issuer's system.
_g_ The purchaser of this voucher 20 now has an ability to spend the denominated amount 26 at the site of any merchant accepting the CI payment system on its website.
A preferred method of commercially implementing the CI system is to s licence the CI system to existing Financial Institutions andlor payment processors (referred to herein collectively as "Fls") that are already issuers of credit cards and have an established network of e-commerce merchants.
Hence, unlike some prior art systems, the implementation of the present system would avoid the effort of signing up merchants from scratch, since such 1o merchant sign-up procedure is resource intensive and time con suming. The Fls would in essence use their Information Technology (IT) hardware which is already in place to connect to the CI system server, and in exchange for money from a customer would issue to that customer the above-noted voucher bearing the particulars corresponding to that amount of money. The codes 24 would be is based on a method of generating random numbers and have three separate fields of numbers to make fraud and duplication difficult. This voucher can be purchased over-the-counter at FI locations, at Automated Teller Machines (ATMs) or through on-line banking for any monetary denomination, with such codes 24 corresponding to that monetary amount 26. The codes are inventoried 2o on a server which is linked to the Fls system server and now represents a sum of money sold to a customer which can be used over the Web for transactions by means of entering and transmitting the codes on a merchant's website.
The amount 26 on the voucher can potentially be spent at any Net merchant of the FI (i.e. merchants of Fls that are authorized to accept credit cards over the Net). When the FI opts to be licensed under the CI system, the FI
will inform its merchants to register for the CI payment system and the FI
will s send software to the merchants to enable them to accept the CI payment system. Hence, by licensing the FI, the CI system benefits from an established network of merchants.
MORE DETAILED EXPLANATION
1o A more detailed example of the CI system of the present invention is now presented.
1. The method of the present invention is initiated when the coinsumer attends at an FI's counter (or ATM or on-line terminal ) and proceeds to purchase a voucher 20 (see fig.1) for, say, $135.00.
is 2. Upon receipt of the $135.00, the FI ~~~~, ~~ r~~~ holds the amount as a deposit in a designated account and the $135.00 deposit is provided with a corresponding code 24. With the money in the FI's account, the FI is now able to meet a payment to a merchant when the customer spends any or all of the $135.00 amount.
20 3. The code 24 corresponding to the amount of $135.00 is inventoried (i.e.
recorded) on both the CI system server and the FI system server.
u~ i 4. Once the consumer purchases the voucher, the consumer may then visit a Web merchant's site (which merchant is signed up already by the FI and onto the CI system) and makes a purchase for, say, $120.00 by entering the codes 24 from the voucher on the website (see figure 3) as well as any other s required details of shipping, under a Secure Sockets Layer (SSL) protocol, or like secure means. The accepting merchant's website will already have the option of choosing the CI payment system. After entering the necessary details, the consumer submits the transaction for processing by clicking the "submit" button or key on that website.
5. The SSL protocol encrypts the consumer's submitted data, secures it and sends it over the Internet to the merchant's website. The payment software in the merchant's web server sends the encrypted data to a processing centre used by the issuer FI.
6. The Fls processing centre then communicates the transaction amount figures is ($120, issuer ID 22 and codes 24) to the CI system server and, if a sufficient balance exists, the CI system server debits (I.e. charges) that code 24 (I.e.
account) for $120. If an insufficient or no balance exists, then the CI system server declines the transaction and the consumer is prompted to check his balance by being directed via a web link to the CI website. The processing zo centre then communicates the transaction figures ($120, issuer ID 22 and codes 24) to the FI that issued the voucher (via the issuer ID number 22) and deducts the amount of $120.00 (corresponding to the code 24) from the designated account at the FI where it was deposited. The issuing FI will give an authorization number.
account) for $120. If an insufficient or no balance exists, then the CI system server declines the transaction and the consumer is prompted to check his balance by being directed via a web link to the CI website. The processing zo centre then communicates the transaction figures ($120, issuer ID 22 and codes 24) to the FI that issued the voucher (via the issuer ID number 22) and deducts the amount of $120.00 (corresponding to the code 24) from the designated account at the FI where it was deposited. The issuing FI will give an authorization number.
7. The Web merchant's payment is settled through the existing credit card payment settlement convention already established between the FI, s processing centre and the merchant.
8. Regardless of the currency used, at the time of payment settlement the mechanism in place would deal with the conversions. The method would be the same as credit cards issued in different currencies.
9. Now, continuing with the above scenario, the consumer has X15.00 left to his 1o credit under the subject codes 24 (since a voucher for $135.00 was bought and only $120.00 was spent). The consumer may access the CI system website and, upon entering his code 24 and issuer ID no. 22, can check the remaining balance on that voucher.
10.The consumer can spend the remaining $15.00 on a subsequent purchase is and can also combine additional codes from other vouchers to make a greater amount. The merchants' CI enabled payment site would allow the option of multiple codes to be used in combination.
FURTHER EXAMPLES OF THE CI SYSTEM
ao Another example of the present system follows, with specific reference to the flow chart of fig.2a:
Step 1: The consumer 30 attends at a voucher issuer 32, which can be a bank, an ATM (automatic teller machine), on-line bank or any other designated location to buy a voucher 20 (as shown in fig.1 ). Except for an on-line voucher purchase, the consumer will always be issued a physical voucher. In the case of s an online voucher purchase, the consumer will get the required data fields (codes 24 and issuer ID no. 22) on his terminal screen which may be safely printed or copied. The consumer pays a desired amount, which is deposited in a designated account 44 by the voucher issuer 32. The amount paid will correspond to the code generated in step 3 below. At the different venues where 1o a voucher can be purchased (eg. Bank, ATM, on-line or other), the consumer will use the established operating procedure to obtain the voucher. For instance at a bank the consumer will likely interact with a human, convey verbal instructions, pay the money (or equivalent value in acceptable form) and receive a voucher.
At an ATM he will likely use his usual means of access to the ATM and follow a is menu-driven screen to request a voucher which is printed by the ATM while his bank account is debited by the value of the voucher. At an on-line terminal the consumer will log in using his normal procedure and will seek the voucher-purchase option whereby he will receive the codes 24, issuer ID no. 22 and value 26 on-screen to be safely copied or printed. Simultaneously his bank 2o account will be debited by the value of the voucher.
Step 2: At the time of the voucher purchase, the consumer's request is routed to the issuer's system server 34.
Step 3: The issuer's server 34 connects to the CI server 36. The server 36 generates the random sequence code 24 for the amount of money requested by the consumer.
Step 4: The CI server 36 inventories this issued code 24 and the issuer ID
s no. 22 with the corresponding monetary value and conveys this data to the issuer's server 34, which inventories the data in the same manner. This data will be accessed later at the time of payment steps 8-11 below.
Step 5: A voucher 20 is then printed bearing this data and other details (as shown on the sample voucher of fig.1 ) and issued to the consumer 30.
1o Step 6: The consumer 30 visits the Web merchant's site 38, which is enabled to process transactions via the CI payment system, to purchase the merchant's product or service at the merchant's selling price. The consumer enters the data from the voucher according to the required format and submits the transaction for processing through a secure server, which encrypts this data.
is One example of a CI payment system Web page the consumer may be prompted to use when paying at the merchant's site is shown in fig. 3. The information entered on this site is codes 24, issuer ID no. 22 and amount 26.
A
drop-down box 50 prompts the consumer to choose the type of currency, and in this example it is the US$. This Web page is designed to accept multiple 2o vouchers 52 in combination made up of any currency 50 in which they are issued. The consumer simply selects the currency pertaining to the particular voucher. After all vouchers are entered, the consumer is further prompted to choose the currency in which he wishes to view his total amount 54 (this currency will most likely be the currency acceptable to the merchant). At that point all the data pertaining to amount and currency is transmitted to the payment processor's server where a currency conversion takes place to the s consumers desired choice of currency and the amount is relayed back to the consumer. Once the consumer is satisfied with the total amount he presses the "submit" key 56 on the Web page to process the transaction.
Step 7: The merchant's payment software sends this encrypted data to a payment processor 40 for authorization.
1o Step 8: The payment processor 40 connects to the CI server 36 to determine the validity and authenticity of the data. There may be several vouchers and additionally different voucher issuers so the validity and authenticity of all is checked.
Step 9: If the data is validated by the CI server 36, then a signal is sent to is the payment processor 40 to proceed with the transaction. If the data is not validated, the transaction is declined by the CI server. Data would result in non-validation if any of the information is discrepant such as no funds, inadequate funds or non-corresponding fields.
Step 10: If the transaction data is validated, the payment processor 40 zo connects to the issuer's server 34 for authorization. If multiple vouchers are used and more than one issuer is noted then all such issuers are contacted for authorization.
Step 11: The issuer's server 34 will then transmit to the payment processor 40 an authorization number after deducting the requested transaction amount (i.e. the merchant's selling price or in the case of multiple vouchers the amount on the voucher pertaining to the particular issuer) from the designated account s 44 in step 1 above.
Step 11 a: Using the authorization number in step 11 above as recorded evidence the payment processor will debit (charge or reduce) the codes on CI
server 36 for the amount.
Step 12: The payment processor 40 will authorize the transaction to the 1a merchant 38.
Step 13: The merchant 38 ships, digitally conveys or otherwise provides the goods or services to the consumer 30.
Step 14: The merchant's account is credited at his merchant bank 42.
Step 15: The merchant 38 has access to the cashlfunds at the merchant is bank 42.
In an alternative embodiment of the GI system shown in fig. 2b, steps 8 and 9 which are described in the fig.2a embodiment above are eliminated and the process is as follows:
Steps 1-7 are the same as shown above.
zo Steps 8 and 9 are eliminated.
Step 10: The payment processor 40 connects directly to the FI server 34 to determine the validity and authenticity of the data. Applicant notes that there ~.=~°....~. u,"_...~....,......... ~.-.. _....--.~. ~... ~...--.--.-_~
__._ _~...,- .. _.~.
may be several vouchers and additionally different voucher issuers, and so the validity and authenticity of all vouchers is checked at the various FI servers which have issued the different vouchers. If the data is validated by the FI server 34, then the transaction proceeds and the amount pertaining to codes 24, which is s held in the designated account 44, is debited (charged or reduced). An authorization number is generated by the FI server upon debiting the amount.
If the data is not validated, the transaction is declined by the FI server. Non-validation would result if any of the information is discrepant such as no funds, inadequate funds or non-corresponding fields.
1o Step 11: The issuer's server 34 will then transmit to the payment:
processor 40 the authorization number generated in the preceding step after deducting the requested transaction amount (i.e. the merchant's selling price or in the case of multiple vouchers the amount on the voucher pertaining to the particular issuer) from the designated account 44 in step 1 above. The authorization number is serves as evidence that the voucher has been charged.
Step 11a: Using the authorization number in step 11 above as recorded evidence the payment processor will debit (charge or reduce) the codes on CI
server 36 for the amount so that the information held at both the FI and CI
server is the same.
2o Steps 12-15 are the same as shown above.
GENERAL DISCUSSION
The operation and many advantages of the present invention may now be better understood, with particular reference to the figures.
Why is this system aimed at Financial Institutions ?
Internet-based payment systems currently require the signing up of Web merchants. This is an enormous task in terms of resources, finances and time.
However, without Web merchants accepting a system there cannot be customers using that system of payment and vice versa.
1o The Fls have their established base of credit card merchants who are already captive and can easily be brought on stream to subscribe to a new form of payment. They also have an existing mechanism of payment settlement.
Therefore, the CI system merely piggybacks on what is already in place, but it works for cash-initiated vouchers rather than credit cards.
1s The participating FI receives payment instantaneously and funds are available for immediate settlement, and so unlike credit cards there is less risk.
Essentially, then, the FI is always covered for its outstanding voucher liabilities.
The FI, together with its branches, ATMs and on-line platforms, forms a huge dispensing arm to CI system customers.
Why would financial institutions be interested in the CI system?
1. The CI system is within the line and range of financial products currently offered by Fls.
2. The CI system creates a new source of revenue for Fls. Such revenue s may be derived from:
merchant sign up fees for adopting the CI system option;
merchant monthly fees for using the CI system;
per transaction fee when using the CI system;
percentage fee of transaction value on the CI system equivalent to current credit io card regimes;
service fee from the consumer at time of his voucher purchase; and, currency exchange commissions.
3. The start-up investment should not be significant compared to the expected volume of transactions as established IT hardware can be used.
1s 4. There should be the prospect of a new customer base to which existing products could be targeted.
5. The possibility of fraud and loss should be substantially lower using the CI
system than using credit cards. Unlike credit cards, any fraud would be limited only to the amount issued for the voucher, and so would be no more than the 2o risk associated with a person carrying cash.
6. Those merchants who do not qualify from their merchant banks for selling over the Web using credit cards may, nonetheless, be rated as second tier and qualify for CI system transactions.
7. By adopting the CI system, the Fls should remain revenue-neutral even if s there were to be substitution between CI system vouchers and credit cards.
Benefits to the owner of the CI system Revenue may be derived from licensing fees which would be based on a percentage of gross revenues of the Fls from adopting the CI system.
so Advertising on the CI system's website should be beneficial as the website would be expected to have numerous hits from consumers visiting to check their balances.
Unclaimed voucher balances after three months of first using the voucher could be subject to service charges so as to deplete the unused balances.
Other attributes of the CI system No prior deposit or prepayment of funds is required.
There is no Personal Identification Number (PIN) to remember.
No user name appears on a voucher nor is it required for a transaction.
2o No swipe cards are employed.
Anyone may use the system as there is no age or other limit on the user.
There are no eligibility or credit checks required, as for credit cards.
-zo-One cannot overspend as usable value on the voucher is set.
No account, whether with a bank or otherwise, need be set up.
No account loading as with other intermediary-based systems.
There is no disclosure of the user's personal information.
s There is no future risk of fraud as the risk is limited to the face value of the voucher.
The voucher is transferable, and so may be provided to a third party as a gift, for instance.
The present system has the potential of global applicability for retail Net 1o commerce (B2C), for money transfers, for B2B commerce, for bill payments to businesses and utilities, and for payments to governments (fees, licences, tickets, taxes, fines etc).
Security Issues is As in any financial system there are security issues to be addressed.
Regarding the CI system, the principal risks are that the consumer could lose a voucher, or that someone might try to replicate the codes at a Web merchant's site. By virtue of its inherent character and make-up, a consumer would likely have no remedy for a lost voucher, just as there is usually no remedy for lost zo cash, unless it is found. If a computer "hacker" should try to run the codes on a merchant's site, server-based software should be provided to block that particular code for a time period, say for four hours, and deem it delinquent.
After four hours the block would be removed and a fresh attempt can be made. The code would be determined to be delinquent when two of the three fields are entered as correct with three attempts made to find the third code.
Furthermore cracking a voucher code would not be a very productive undertaking for a hacker s because: each voucher number is different; all three fields have 1:o match;
the three field must correspond with the issuer ID no.; and, an erroneous insertion would block the hacker's attempt for four hours so that the whole exercise would be discouraging.
1o Target market of users for the CI system 1. Credit card users 2. People unable to get credit cards 3. The under 18s (minors) 4. Populations in emerging markets e.g. South East Asia, China, India, Latin is America, Middle East, North and South Africa 5. Businesses Market potential of the CI system Aside from the markets of North America, Western Europe and Asia-zo Pacific, new markets of consumers from less-developed and under-developed countries may come on stream via the CI system as these countries have populations with money to spend as well as Net access but no currently workable -z2-system of payment. The banking networks in such countries are ideally suited to host the system of the present invention. Consumers in those countries would be able to access Web merchant services, which are of an on-line digital type but which do not necessarily entail a shipment of goods, such as news services, s on-line gambling, adult industry services and many others.
The expected growth may be explosive. Vast populations are expected to come onto the Net in Asia. China apparently has only about 2% of its current population on the Net. India only has an estimated 0.5% of its population on the Net compared to developed countries in which upwards of 30-60% of the so population has Net access. The worldwide figure is estimated to be under 9%.
A table showing an estimate of the number of people with Net access as of August 2001 is shown in fig.4.
The above description is intended in an illustrative rather than a restrictive sense, and variations to the specific configurations described may be apparent 15 to skilled persons in adapting the present invention to other specific applications.
Such variations are intended to form part of the present invention insofar as they are within the spirit and scope of the claims below. For instance, in another alternate embodiment of the present invention, the CI system may be employed in non-FI type outlets. The CI system may also process (as in fig. 3) single ao vouchers in a single currency rather than multiple vouchers in different currencies or any combination thereof.
FURTHER EXAMPLES OF THE CI SYSTEM
ao Another example of the present system follows, with specific reference to the flow chart of fig.2a:
Step 1: The consumer 30 attends at a voucher issuer 32, which can be a bank, an ATM (automatic teller machine), on-line bank or any other designated location to buy a voucher 20 (as shown in fig.1 ). Except for an on-line voucher purchase, the consumer will always be issued a physical voucher. In the case of s an online voucher purchase, the consumer will get the required data fields (codes 24 and issuer ID no. 22) on his terminal screen which may be safely printed or copied. The consumer pays a desired amount, which is deposited in a designated account 44 by the voucher issuer 32. The amount paid will correspond to the code generated in step 3 below. At the different venues where 1o a voucher can be purchased (eg. Bank, ATM, on-line or other), the consumer will use the established operating procedure to obtain the voucher. For instance at a bank the consumer will likely interact with a human, convey verbal instructions, pay the money (or equivalent value in acceptable form) and receive a voucher.
At an ATM he will likely use his usual means of access to the ATM and follow a is menu-driven screen to request a voucher which is printed by the ATM while his bank account is debited by the value of the voucher. At an on-line terminal the consumer will log in using his normal procedure and will seek the voucher-purchase option whereby he will receive the codes 24, issuer ID no. 22 and value 26 on-screen to be safely copied or printed. Simultaneously his bank 2o account will be debited by the value of the voucher.
Step 2: At the time of the voucher purchase, the consumer's request is routed to the issuer's system server 34.
Step 3: The issuer's server 34 connects to the CI server 36. The server 36 generates the random sequence code 24 for the amount of money requested by the consumer.
Step 4: The CI server 36 inventories this issued code 24 and the issuer ID
s no. 22 with the corresponding monetary value and conveys this data to the issuer's server 34, which inventories the data in the same manner. This data will be accessed later at the time of payment steps 8-11 below.
Step 5: A voucher 20 is then printed bearing this data and other details (as shown on the sample voucher of fig.1 ) and issued to the consumer 30.
1o Step 6: The consumer 30 visits the Web merchant's site 38, which is enabled to process transactions via the CI payment system, to purchase the merchant's product or service at the merchant's selling price. The consumer enters the data from the voucher according to the required format and submits the transaction for processing through a secure server, which encrypts this data.
is One example of a CI payment system Web page the consumer may be prompted to use when paying at the merchant's site is shown in fig. 3. The information entered on this site is codes 24, issuer ID no. 22 and amount 26.
A
drop-down box 50 prompts the consumer to choose the type of currency, and in this example it is the US$. This Web page is designed to accept multiple 2o vouchers 52 in combination made up of any currency 50 in which they are issued. The consumer simply selects the currency pertaining to the particular voucher. After all vouchers are entered, the consumer is further prompted to choose the currency in which he wishes to view his total amount 54 (this currency will most likely be the currency acceptable to the merchant). At that point all the data pertaining to amount and currency is transmitted to the payment processor's server where a currency conversion takes place to the s consumers desired choice of currency and the amount is relayed back to the consumer. Once the consumer is satisfied with the total amount he presses the "submit" key 56 on the Web page to process the transaction.
Step 7: The merchant's payment software sends this encrypted data to a payment processor 40 for authorization.
1o Step 8: The payment processor 40 connects to the CI server 36 to determine the validity and authenticity of the data. There may be several vouchers and additionally different voucher issuers so the validity and authenticity of all is checked.
Step 9: If the data is validated by the CI server 36, then a signal is sent to is the payment processor 40 to proceed with the transaction. If the data is not validated, the transaction is declined by the CI server. Data would result in non-validation if any of the information is discrepant such as no funds, inadequate funds or non-corresponding fields.
Step 10: If the transaction data is validated, the payment processor 40 zo connects to the issuer's server 34 for authorization. If multiple vouchers are used and more than one issuer is noted then all such issuers are contacted for authorization.
Step 11: The issuer's server 34 will then transmit to the payment processor 40 an authorization number after deducting the requested transaction amount (i.e. the merchant's selling price or in the case of multiple vouchers the amount on the voucher pertaining to the particular issuer) from the designated account s 44 in step 1 above.
Step 11 a: Using the authorization number in step 11 above as recorded evidence the payment processor will debit (charge or reduce) the codes on CI
server 36 for the amount.
Step 12: The payment processor 40 will authorize the transaction to the 1a merchant 38.
Step 13: The merchant 38 ships, digitally conveys or otherwise provides the goods or services to the consumer 30.
Step 14: The merchant's account is credited at his merchant bank 42.
Step 15: The merchant 38 has access to the cashlfunds at the merchant is bank 42.
In an alternative embodiment of the GI system shown in fig. 2b, steps 8 and 9 which are described in the fig.2a embodiment above are eliminated and the process is as follows:
Steps 1-7 are the same as shown above.
zo Steps 8 and 9 are eliminated.
Step 10: The payment processor 40 connects directly to the FI server 34 to determine the validity and authenticity of the data. Applicant notes that there ~.=~°....~. u,"_...~....,......... ~.-.. _....--.~. ~... ~...--.--.-_~
__._ _~...,- .. _.~.
may be several vouchers and additionally different voucher issuers, and so the validity and authenticity of all vouchers is checked at the various FI servers which have issued the different vouchers. If the data is validated by the FI server 34, then the transaction proceeds and the amount pertaining to codes 24, which is s held in the designated account 44, is debited (charged or reduced). An authorization number is generated by the FI server upon debiting the amount.
If the data is not validated, the transaction is declined by the FI server. Non-validation would result if any of the information is discrepant such as no funds, inadequate funds or non-corresponding fields.
1o Step 11: The issuer's server 34 will then transmit to the payment:
processor 40 the authorization number generated in the preceding step after deducting the requested transaction amount (i.e. the merchant's selling price or in the case of multiple vouchers the amount on the voucher pertaining to the particular issuer) from the designated account 44 in step 1 above. The authorization number is serves as evidence that the voucher has been charged.
Step 11a: Using the authorization number in step 11 above as recorded evidence the payment processor will debit (charge or reduce) the codes on CI
server 36 for the amount so that the information held at both the FI and CI
server is the same.
2o Steps 12-15 are the same as shown above.
GENERAL DISCUSSION
The operation and many advantages of the present invention may now be better understood, with particular reference to the figures.
Why is this system aimed at Financial Institutions ?
Internet-based payment systems currently require the signing up of Web merchants. This is an enormous task in terms of resources, finances and time.
However, without Web merchants accepting a system there cannot be customers using that system of payment and vice versa.
1o The Fls have their established base of credit card merchants who are already captive and can easily be brought on stream to subscribe to a new form of payment. They also have an existing mechanism of payment settlement.
Therefore, the CI system merely piggybacks on what is already in place, but it works for cash-initiated vouchers rather than credit cards.
1s The participating FI receives payment instantaneously and funds are available for immediate settlement, and so unlike credit cards there is less risk.
Essentially, then, the FI is always covered for its outstanding voucher liabilities.
The FI, together with its branches, ATMs and on-line platforms, forms a huge dispensing arm to CI system customers.
Why would financial institutions be interested in the CI system?
1. The CI system is within the line and range of financial products currently offered by Fls.
2. The CI system creates a new source of revenue for Fls. Such revenue s may be derived from:
merchant sign up fees for adopting the CI system option;
merchant monthly fees for using the CI system;
per transaction fee when using the CI system;
percentage fee of transaction value on the CI system equivalent to current credit io card regimes;
service fee from the consumer at time of his voucher purchase; and, currency exchange commissions.
3. The start-up investment should not be significant compared to the expected volume of transactions as established IT hardware can be used.
1s 4. There should be the prospect of a new customer base to which existing products could be targeted.
5. The possibility of fraud and loss should be substantially lower using the CI
system than using credit cards. Unlike credit cards, any fraud would be limited only to the amount issued for the voucher, and so would be no more than the 2o risk associated with a person carrying cash.
6. Those merchants who do not qualify from their merchant banks for selling over the Web using credit cards may, nonetheless, be rated as second tier and qualify for CI system transactions.
7. By adopting the CI system, the Fls should remain revenue-neutral even if s there were to be substitution between CI system vouchers and credit cards.
Benefits to the owner of the CI system Revenue may be derived from licensing fees which would be based on a percentage of gross revenues of the Fls from adopting the CI system.
so Advertising on the CI system's website should be beneficial as the website would be expected to have numerous hits from consumers visiting to check their balances.
Unclaimed voucher balances after three months of first using the voucher could be subject to service charges so as to deplete the unused balances.
Other attributes of the CI system No prior deposit or prepayment of funds is required.
There is no Personal Identification Number (PIN) to remember.
No user name appears on a voucher nor is it required for a transaction.
2o No swipe cards are employed.
Anyone may use the system as there is no age or other limit on the user.
There are no eligibility or credit checks required, as for credit cards.
-zo-One cannot overspend as usable value on the voucher is set.
No account, whether with a bank or otherwise, need be set up.
No account loading as with other intermediary-based systems.
There is no disclosure of the user's personal information.
s There is no future risk of fraud as the risk is limited to the face value of the voucher.
The voucher is transferable, and so may be provided to a third party as a gift, for instance.
The present system has the potential of global applicability for retail Net 1o commerce (B2C), for money transfers, for B2B commerce, for bill payments to businesses and utilities, and for payments to governments (fees, licences, tickets, taxes, fines etc).
Security Issues is As in any financial system there are security issues to be addressed.
Regarding the CI system, the principal risks are that the consumer could lose a voucher, or that someone might try to replicate the codes at a Web merchant's site. By virtue of its inherent character and make-up, a consumer would likely have no remedy for a lost voucher, just as there is usually no remedy for lost zo cash, unless it is found. If a computer "hacker" should try to run the codes on a merchant's site, server-based software should be provided to block that particular code for a time period, say for four hours, and deem it delinquent.
After four hours the block would be removed and a fresh attempt can be made. The code would be determined to be delinquent when two of the three fields are entered as correct with three attempts made to find the third code.
Furthermore cracking a voucher code would not be a very productive undertaking for a hacker s because: each voucher number is different; all three fields have 1:o match;
the three field must correspond with the issuer ID no.; and, an erroneous insertion would block the hacker's attempt for four hours so that the whole exercise would be discouraging.
1o Target market of users for the CI system 1. Credit card users 2. People unable to get credit cards 3. The under 18s (minors) 4. Populations in emerging markets e.g. South East Asia, China, India, Latin is America, Middle East, North and South Africa 5. Businesses Market potential of the CI system Aside from the markets of North America, Western Europe and Asia-zo Pacific, new markets of consumers from less-developed and under-developed countries may come on stream via the CI system as these countries have populations with money to spend as well as Net access but no currently workable -z2-system of payment. The banking networks in such countries are ideally suited to host the system of the present invention. Consumers in those countries would be able to access Web merchant services, which are of an on-line digital type but which do not necessarily entail a shipment of goods, such as news services, s on-line gambling, adult industry services and many others.
The expected growth may be explosive. Vast populations are expected to come onto the Net in Asia. China apparently has only about 2% of its current population on the Net. India only has an estimated 0.5% of its population on the Net compared to developed countries in which upwards of 30-60% of the so population has Net access. The worldwide figure is estimated to be under 9%.
A table showing an estimate of the number of people with Net access as of August 2001 is shown in fig.4.
The above description is intended in an illustrative rather than a restrictive sense, and variations to the specific configurations described may be apparent 15 to skilled persons in adapting the present invention to other specific applications.
Such variations are intended to form part of the present invention insofar as they are within the spirit and scope of the claims below. For instance, in another alternate embodiment of the present invention, the CI system may be employed in non-FI type outlets. The CI system may also process (as in fig. 3) single ao vouchers in a single currency rather than multiple vouchers in different currencies or any combination thereof.
Claims
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002384927A CA2384927A1 (en) | 2002-05-06 | 2002-05-06 | Cash initiated system for paying web transactions |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002384927A CA2384927A1 (en) | 2002-05-06 | 2002-05-06 | Cash initiated system for paying web transactions |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2384927A1 true CA2384927A1 (en) | 2003-11-06 |
Family
ID=29410080
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002384927A Abandoned CA2384927A1 (en) | 2002-05-06 | 2002-05-06 | Cash initiated system for paying web transactions |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2384927A1 (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2005013163A2 (en) * | 2003-07-30 | 2005-02-10 | Jan-Georges Zizka | Electronic payment system and method |
| GB2517723A (en) * | 2013-08-29 | 2015-03-04 | Belegin Ltd | Token verification |
-
2002
- 2002-05-06 CA CA002384927A patent/CA2384927A1/en not_active Abandoned
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2005013163A2 (en) * | 2003-07-30 | 2005-02-10 | Jan-Georges Zizka | Electronic payment system and method |
| WO2005013163A3 (en) * | 2003-07-30 | 2005-06-02 | Jan-Georges Zizka | Electronic payment system and method |
| GB2517723A (en) * | 2013-08-29 | 2015-03-04 | Belegin Ltd | Token verification |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10489753B2 (en) | Electronic purchasing and funds transfer systems and methods | |
| US9665862B2 (en) | Conducting commerce between individuals | |
| US8315929B2 (en) | Online incremental payment method | |
| US6805289B2 (en) | Prepaid card payment system and method for electronic commerce | |
| US8200575B2 (en) | Secure electronic payment system and methods | |
| US20050033645A1 (en) | Virtual cashier | |
| US20070150413A1 (en) | Apparatus and Method for Creating and Using Electronic Currency on Global Computer Networks | |
| US20030004828A1 (en) | Prepaid card authorization and security system | |
| US20060143119A1 (en) | Secure networked transaction system | |
| US20090070265A1 (en) | System and method for cashback funding | |
| JP5036131B2 (en) | Method and system for transferring funds | |
| US8799089B1 (en) | Virtual payment system for the physical world | |
| US20030041022A1 (en) | Electronic money instrument | |
| WO2000067178A2 (en) | Anonymous on-line payment system and method | |
| CA2384927A1 (en) | Cash initiated system for paying web transactions | |
| KR20010049120A (en) | System for paying electronic commercial transaction on internet | |
| WO2007137336A1 (en) | Sale transaction method | |
| Bennett | Information access and electronic commerce | |
| JP2002109443A (en) | Online commerce method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued | ||
| FZDE | Discontinued |
Effective date: 20050124 |