CA2213424A1 - Payment processing system for making electronic payments without a preexisting account relationship - Google Patents

Abstract

A method for making electronic payments without a preexisting account relationship. This system may be used by any person who has access to the system via a personal computer, such as through the Internet. Access to the system may be provided through the system's own home page or by a system icon that is present on the home pages of the merchants who have elected the system as one of their payment options. Once the system has been accessed by the user, the user will be able to select from a list of companies who have previously agreed to accept electronic funds transfers from the system as payments on their customer's accounts. It is not necessary for the user to have previously established a relationship with the system provider in order to use the system to make payments on his accounts (although the system may record the user's personal data after first use in order to make subsequent uses more convenient). The user may select whether he wishes to pay from his bank checking account, or through one of several credit cards. After the selection, the user is prompted to input his bank account number or credit card account number information, as well as the amount he wishes to pay. Once this information has been entered satisfactorily, the user selects a "send" icon, the data is encrypted and sent to the system central computer via the Internet. The data remains in its encrypted form until it reaches the system's central computer. The system's central computer determines if the entered information is valid (and may also obtain an authorization) and, if so, sends a receipt message which is displayed on the user's computer screen. This receipt may be printed if the user desires to retain a hard copy verification of the transaction.

Description

CA 022l3424 l997-08-l8 PAYMENT PROCESSING SYSTEM FOR MAKING ELECTRONIC
PAYMENTS ~ll~Oul A ~K~ STING AG~Ou..l RELATIONSHIP

TECHNICAL FIELD OF THE INVENTION

The present invention generally relates to electronic funds transfers and, more particularly, to a method for making electronic payments without a preexisting account relationship.

BACKGROUND OF THE INVENTION

Previously, there have been many systems devised for allowing a consumer to pay bills, either over the telephone or by use of a personal computer within the home.
Typically, such systems require the user to establish an account with the payment processing system prior to being able to use the system. For instance, most such systems require that potential users of the system complete and submit an application containing personal and financial information of the user. This application is then processed by the system provider, which may include a check of the potential user's credit history. If the potential user is accepted, an account number is assigned under which the user will conduct all future transactions on the system.
These prior art systems therefore require a certain amount of overhead and commitment on the part of the user.
In other words, because a not insignificant amount of time is required on the user's part to establish the ability to pay bills through the prior art system, the user must have committed himself to future use of the system before it becomes worthwhile to go to the trouble of establishing an account with the payment processing system. Furthermore, most such prior art payment processing systems charge a monthly or per-transaction fee to the user for the convenience of paying the user's bills through the system.
There is therefore a need for a system which will allow a consumer to pay bills through the use of his personal computer without the requirement of having to establish an account with the payment processing system prior to doing so (although the merchant may have to establish an account with the payment processing system). Furthermore, with the increasing proliferation of personal computer owners who lS have access to the Internet, there is a need for a system which will allow consumers to access the payment processing system through the Internet in order to pay a variety of different bills. The present invention is directed toward meeting these needs.

SUMMARY OF THE INVENTION

The present invention relates to a method for making electronic payments without a preexisting account relationship. This system may be used by any person who has access to the system via a personal computer, such as through the Internet. Access to the system may be provided through the system's own home page or by a system icon that is present on the home pages of the merchants who have elected the system as one of their payment options. Once the system has been accessed by the user, the user will be able to select from a list of companies who have previously agreed to accept electronic funds transfers from the system as payments on their customer's accounts. It is not necessary for the user to have previously established a relationship with the system provider in order to use the system to make payments on his accounts (although the system may record the user's personal data after first use in order to make subsequent uses more convenient). The user may select whether he wishes to pay from his bank checking account, or through one of several credit cards. After the selection, the user is prompted to input his bank account number or credit card account number information, as well as the amount he wishes to pay. Once this information has been entered satisfactorily, the user selects a "send" icon, the data is encrypted and sent to the system central computer via the Internet. The data remains in its encrypted form until it reaches the system's central computer. The system's central computer determines if the entered information is valid (and may also obtain an authorization) and, if so, sends a receipt message which is displayed on the user's computer screen. This receipt may be printed if the user desires to retain a hard copy verification of the transaction.
In one form of the invention, a method for making electronic payments from a user to a merchant is disclosed, comprising the steps of: (a) coupling a user computer to a first software program in a merchant computer; (b) selecting a payment option in the first software program; (c) coupling the user computer to a second software program in a payment system computer in response to selecting the payment option in step (b); (d) transmitting payment information from the user computer to the second software program; and (e) effecting the payment by electronic funds transfer.
In another form of the invention, a method for making electronic payments from a user to a merchant is disclosed, comprising the steps of: (a) coupling a user computer to a software program in a payment system computer; (b) selecting the merchant from a list of other merchants displayed by the lS software program; (c) transmitting payment information from the user computer to the software program; and (d) effecting the payment by electronic funds transfer without requiring any pree~isting account relationship between the user and a provider of the software program.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic block diagram of a preferred embodiment computer network linking a home user to the system of the present invention.
FIG. 2 is a schematic flow diagram illustrating a preferred embodiment payment method selection process.
FIG. 3 is a schematic flow diagram illustrating a preferred embodiment credit card processing method.
FIG. 4 is a schematic flow diagram illustrating a preferred embodiment check processing method.
FIG. 5 is a schematic flow diagram illustrating a preferred embodiment payment transaction file reading routine.
FIG. 6 is a schematic flow diagram illustrating a preferred embodiment routine for determining a file type.
FIG. 7 is a schematic flow diagram illustrating a preferred embodiment routine for determining between a header record and a credit card record.
FIG. 8 is a schematic flow diagram illustrating a preferred embodiment header date checking routine.
FIG. 9 is a schematic flow diagram illustrating a preferred embodiment process for generating a credit card report.
FIG. 10 is a schematic flow diagram illustrating a preferred embodiment process for generating an error report.
FIG. 11 is a schematic flow diagram illustrating a preferred embodiment process for storing data for use with ACH software.
FIG. 12 is a schematic flow diagram illustrating a preferred embodiment check processing routine.
FIG. 13 is a schematic flow diagram illustrating a preferred embodiment process for processing ACH transactions.
FIG. 14 is a schematic flow diagram illustrating a preferred embodiment process for completing customer transactions.

DESCRIPTION OF THE PREFERRED EMBODIMENT

For the purposes of promoting an understanding of the principles of the invention, reference will now be made to the embodiment illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended, such alterations and further modifications in the illustrated device, and such further applications of the principles of the invention as illustrated therein being contemplated as would normally occur to one skilled in the art to which the invention relates. For example, the term electronic funds transfer as used herein encompasses any transaction which transfers assets without physically moving the assets at the time of the transfer, such as electronically debiting a user's checking account and crediting a merchant's account, authorizing a transfer from a user's credit card account to a merchant's account, etc. Furthermore, the terms ~merchant" and "customer" are synonymous in the present description as the merchant is the customer of the system provider.
FIG. 1 is a schematic block diagram illustrating a preferred embodiment computer network for coupling a home user of the system of the present invention to the system's dedicated server. It will be appreciated by those skilled in the art that although a particular network configuration is illustrated in FIG. 1 as the preferred embodiment, any network configuration which enables the home user to communicate with the system server is comprehended by the present invention. In the preferred embodiment of FIG. l, the home user lO connects to the computer network through the Internet front end 12. The communications link to the mainframe computer/system server 18, which executes the process of the present invention, is completed through the Internet front end provider 20, which is coupled to the Internet front end 12 via the communication link 14.
Once a link between the home user 10 and the system server 18 has been identified, the home user 10 may execute the process of FIGS. 2-4 in order to initiate a payment to a merchant which will accept payment from the system of the present invention. All data communication between the home user 10 and the system server 18 is encrypted. The data remains encrypted until it reaches the system server 18, where it is then de-encrypted.
As illustrated in FIG. 2, the home user 10 utilizes--some form of telecommunications 22 in order to gain access to the Internet front end 20. For example, the telecommunications 22 may be the preferred embodiment link schematically illustrated in FIG. 1. Once this link has been established, the home user 10 may initiate a payment transaction in one of two ways. First, the home user 10 may access the home page 24 of the provider of the system of the present invention. This system home page 24 will identify a list of merchants (i.e. customers of the system provider) which have agreed to accept electronic payments from the system provider. The home user 10 may then select one of these customers at 26. Alternatively, instead of accessing the system on home page 24, the home user 10 may directly access a home page 28 that has been established by any of the system provider's customers. Among the other information provided in the customer's home page 28, there will preferably be a payment icon which refers to the provider of the system of the present invention. After selecting this payment icon at the customer's home page 28, or after selecting a customer from the list provided on the system's home page 24, the home user 10 is prompted at 30 to select an electronic funds transfer payment method. For example, the user may be prompted to select payment by credit card or by bank check. The system determines at step 32 which of the available payment options has been selected by the home user l0, and the process flow branches accordingly.
FIG. 3 illustrates the preferred embodiment process flow if the home user l0 selected a credit card for payment at step 30. If the home user l0 has selected a credit card payment option, step 34 requests that the home user l0 enter relevant information about the credit card account, the customer account to which the home user l0 wishes to make a payment, and the amount of the payment to be made. A credit card authorization is then performed by the system in order to verify that a valid account number has been entered and that the expiration date of the credit card has not passed.
Various payment edits are also performed, such as verifying the home user's customer account number and payment amount (e.g. the customer may limit the dollar amount that can be paid through this system). Any other special information processing requested by the customer may also be performed at this step, and any additional information required from the home user l0 will be requested. Based upon the information processed at step 34, the process determines at step 36 whether the payment request entered by the home user l0 is acceptable. If it is not, then a denial of the payment request is sent to the home user at 38. Otherwise, the payment request is processed at 40 and a confirmation is sent to the home user's computer. If the home user l0 desires to retain a hard copy verification of completion of his payment transaction, this confirmation may be printed using any printing device coupled to the computer of the home user l0. Details of the payment processing completed at step 40 are discussed hereinbelow with reference to FIG.
5.
Referring now to FIG. 4, there is illustrated the preferred embodiment process flow if the home user l0 selected a check for payment at step 30. If the home user l0 has selected a check payment option, step 42 requests that the home user l0 enter relevant information about the checking account, the customer account to which the home user l0 wishes to make a payment, and the amount of the payment to be made. A check authorization is then performed by the system in order to verify that a valid account routing and transit number has been entered. Various payment edits are also performed, such as verifying the home user's customer account number and payment amount (e.g. the customer may limit the dollar amount that can be paid through this system). Any other special information processing requested by the customer may also be performed at this step, and any additional information required from the home user l0 will be requested. For example, the checking account may be compared to a "negative file" which includes account numbers of checks that should not be accepted. Based upon the information processed at step 42, the process determines at step 44 whether the payment request entered by the home user l0 is acceptable. If it is not, then a denial of the payment request is sent to the home user at 46. Otherwise, the payment request is processed at 48 and a confirmation is sent to the home user's computer. If the home user l0 desires to retain a hard copy verification of completion of his payment transaction, this confirmation may be printed using any printing device coupled to the computer of the home user l0. Details of the payment processing completed at step 48 are discussed hereinbelow with reference to FIG. 5.
Referring now to FIG. 5, there is illustrated a schematic flow diagram detailing the processing performed by the mainframe computer 18 operating the system of the present invention. First, the mainframe 18 makes a backup of the payment file from the Internet 20 at step 50. This payment file contains records of all of the payment transactions that have been requested since the last backup file has been made. These payment requests are then sorted at 52 by merchant (customer) and by whether the payment is by check or credit card. The sorted file is then read at 54 in order to extract the next payment request from the file.
The system checks at 56 in order to determine if the next record retrieved from the payment file is an end-of-file (EOF) indicator. If the record is an EOF indicator, then the entire payment file has been processed by the system and a summary report of all of the credit card transactions is prepared at 58 and a summary report of all of the check transactions is prepared at 60.
If the next record from the payment file is not an EOF
indicator at step 56, then the process continues in FIG. 6, where the record is identified as either a check payment, a credit card payment or a header record at step 62. A header record is a block of information at the beginning of each file which contains data in a standardized format identifying various characteristics of the file. If the next record in the payment file is not one of these three options, then the system proceeds to FIG. l0, in which an entry is made upon a cumulative error report at 64 (a separate error report 64 is generated for each customer).
The process then returns to step 54 of FIG. 5 in order to obtain the next record from the payment file. If step 62 determines that the record is of a valid type, then the process continues to step 66, where the system reads a control file for the selected merchant (customer). This control file houses particular merchant information which is necessary in order to direct payment to that merchant, such as the clearing ACH (automated clearing house) number. The process next determines at step 68 whether there is a current record to be processed by the system. If not, then an entry is made on the error report 64 of FIG. l0, otherwise the process continues to FIG. 7 where the record is examined at 70 in order to determine if it is a header record. If it is, then the process continues to FIG. 8 in , which the date in the header record is analyzed at step 72 in order to determine if the date is good (e.g. is it a valid date, is it in mm/dd/yy format, etc.?). If thè header date is not good, then an entry is made on the error report 64 in FIG. 10. Otherwise, the process continues to FIG. 11 where an entry is made to a file that will be used as input to the ACH software (described in greater detail hereinbelow with reference to FIG. 13) at step 74. The process then returns to FIG. 5 in order to obtain the next record.
Returning once again to FIG. 7, if step 70 determines that the current record is not a header record, then step 76 determines if the current record is a credit card payment record. If the record is a credit card payment record, then the credit card transaction is effected through the credit lS granting organization and the process continues to FIG. 9 where this data is entered on a credit card report at step 78 which is prepared for each merchant. The process then continues at FIG. 5, step 54. However, if step 76 determines that the record is not a credit card record, then the record must be a check record and the process continues at FIG. 12.
FIG. 12 first performs a check digit operation upon the customer's ABA account number in order to verify that it is a valid account number (i.e. a good transit routing) at step 80. If it is determined at step 82 that the customer's ABA
account number is not valid, then an entry is made on the error report 64 of FIG. 10. Otherwise, the system performs the customer required check edits at step 84, as described in greater detail hereinabove with reference to FIG. 4. If these customer edits are failed at step 86, then an entry is made on the error report 64 of FIG. 10. Otherwise, an entry is made on the customer-specific check report 88 and the information is written to a file at step 74 (FIG. 11) for entry into the ACH software of FIG. 13. The process once again continues at step 54 of FIG. 5.

Eventually, the process of FIG. 5 will read through all of the records in the payment file and will reach the EOF
indicator at step 76. Once this has been reached, the credit card summary report 58 and check summary report 60 are generated and the ACH software 90 is accessed. The ACH
software 90 is a standard bank software interface which is known to those having ordinary skill in the art. The ACH
software 90 performs processing to build a data file that is in the proper format for transmission to the federal reserve bank. The federal reserve bank will then act as a clearing house for transferring the check payment information from each home user l0 to each of the merchants. The specific functioning of the ACH software is described in greater detail hereinbelow with reference to FIG. 13.
The ACH software 90 of FIG. 13 accesses the data saved to disk at step 74 (FIG. ll). This data file details a series of transactions in which debits are to be made in the bank accounts of the home users l0 and credits are to be made to the accounts of each of the customers (merchants).
The ACH software 90 compiles a list of consumer (home user) ACH debits to be made at step 92 and transmits this information at 94 to a bank 96 which handles banking activities for the provider of the system of the present invention. The ACH software 90 compiles the consumer ACH
debits into the required format for transmission to the federal reserve bank, therefore the bank 96 simply transmits this data on to the federal reserve bank at 98. The federal reserve bank will then perform its automated clearing house function by debiting the necessary amounts from the bank accounts of each of the home users l0 and transmitting this amount back to the bank 9 6 ( as an electronic funds transfer). The bank 96 will then credit these amounts to a bank account maintained for each of the customers at l00.
The ACH software 90 also compiles a list of ACH credits for each of the merchants at 102. The remaining processes of FIGS. 13 and 14 relate to providers of the system of the present invention which also handle other forms of payment remittance processing for the customers which receive electronic payment through the system of the present invention.
For such further remittance processing, the system mainframe 18 retrieves the customer ACH credit file 102 and writes these customer credits to an ACH file at step 104.
This information is compiled with information from a customer lock box remittance file 106 at step 108 where the data is reformatted. If step 110 determines that this -is the end of the remittance process, then this combined information is transmitted to the customer at step 112 so that the customer may update its records. However, step 110 may determine that this is not the end of the remittance process because further processing must be done on the remittance data. If so, the process continues at step 114 (FIG. 14) where various edits are performed upon the remittance data in order to verify the accuracy of this data. Step 116 determines if the data passes these edits and, if not, an entry is made upon an error report at 118.
The process then returns to step 108 of FIG. 13. However, if step 116 determines that the edits were successful, step 120 determines if this particular customer has a stop file which must be checked. If so, the customer's stop file 122 is read at 124 in order to determine if there are any reasons to identify the transaction as being in error. Such reasons might include an invalid account number prefix, a lost check, etc. Step 126 determines if any of the stop file parameters are applicable. If the transaction is deemed to be good, or if the customer does not have a stop file at step 120, the transaction is entered on the customer's daily remittance report at 128 and this information is entered into a file at step 130 which will later be transmitted electronically to the customer. If step 126 determines that the transaction is not good because of some criteria found in the stop file, then the process will skip to step 118 and an entry will be made on the customer's error report. In either situation, the process returns to step 108 of FIG. 13 and the loop is repeated until step 110 determines that this is the end of the remittance process.
In light of the foregoing description, those having ordinary skill in the art will recognize that the system of the present invention represents a significant improvement over prior art electronic payment systems. Because it 7 S
not necessary for the consumer to enroll with the payment processing system prior to using the system, there is a strong likelihood that many people will use the system at least occasionally who would not otherwise use the system.
Many people hesitate to sign up for an electronic payment processing system fearing that they will go through the time and effort required to sign up for the system and then determine that they do not enjoy paying their bills using the system, thereby wasting the time and effort necessary to sign up. With the system of the present invention, any user may access the system and pay a bill to a customer which has agreed to accept payment from the system without any prior contact to the system. Additionally, there is no extra charge to the home user 10 for utilizing the system of the present invention. The system is completely funded by the customers (merchants) who have agreed to accept payment through the system. Such customers find use of the system to be advantageous because they have use of the payment funds much quicker than if the home user had simply mailed a check to the customer. In most cases, the customer will gain several days of interest on the money paid through the system due to the elimination of mail delays and manual remittance processing delays. The system of the present invention has the further advantage that the home user 10 does not have to directly access the system in order to be able to use the system. For example, the home user I0 may access an Internet home page developed by one of the merchants. This home page may have many attributes and pieces of data which are of interest to the home user lO
including an icon which, when selected, will connect the home user lO with the system of the present invention. This feature, coupled with the fact that the home user lO does not have to have previously set up an account with the system, make it more likely that many users will try the system, owing to the fact that the home user lO does not even need to be aware of this system's existence prior to gaining access to it through one of the merchants' home pages. For all of these reasons, it will be appreciated that the system of the present invention represents a significant advance in the art of electronic funds payment.
While the invention has been illustrated and described in detail in the drawings and foregoing description, the same is to be considered as illustrative and not restrictive in character, it being understood that only the preferred embodiment has been shown and described and that all changes and modifications that come within the spirit of the invention are desired to be protected. For example, the term "credit card" as used herein is intended to encompass bank credit cards, non-bank credit cards, debit cards, and other cards that provide access to a source of funds for payment. Similarly, the term "payment" as used herein is intended to encompass a payment toward a pre-existing bill as well as a payment made at the time of purchase.

Claims (14)

1. A method for making electronic payments from a user to a merchant, comprising the steps of:
(a) coupling a user computer to a first software program in a merchant computer;
(b) selecting a payment option in the first software program;
(c) coupling the user computer to a second software program in a payment system computer in response to selecting the payment option in step (b);
(d) transmitting payment information from the user computer to the second software program; and (e) effecting the payment by electronic funds transfer.

2. The method of claim 1, wherein the electronic funds transfer includes a debit to a demand deposit account of the user.

3. The method of claim 1, wherein the electronic funds transfer comprises a credit transaction.

4. The method of claim 1, wherein the first software program is a home page operated by the merchant on the Internet.

5. The method of claim 1, wherein step (b) comprises activating a payment icon displayed by the first software program on the user computer.

6. The method of claim 1, wherein step (c) comprises linking the user computer to a home page operated by a payment system provider on the Internet.

7. The method of claim 1, further comprising the step of:
(f) transmitting a confirmation of the payment from the second software program to the user computer.

8. The method of claim 1, further comprising the step of:
(f) transmitting a summary report from a payment system provider to the merchant summarizing the payment made to the merchant.

9. A method for making electronic payments from a user to a merchant, comprising the steps of:
(a) coupling a user computer to a software program in a payment system computer;
(b) selecting the merchant from a list of other merchants displayed by the software program;
(c) transmitting payment information from the user computer to the software program; and (d) effecting the payment by electronic funds transfer without requiring any preexisting account relationship between the user and a provider of the software program.

10. The method of claim 9, wherein the electronic funds transfer includes a debit to a demand deposit account of the user.

11. The method of claim 9, wherein the electronic funds transfer comprises a credit transaction.

12. The method of claim 9, wherein the software program is a home page operated by the provider on the Internet.

13. The method of claim 9, further comprising the step of:
(e) transmitting a confirmation of the payment from the software program to the user computer.

14. The method of claim 9, further comprising the step of:
(e) transmitting a summary report from the provider to the merchant summarizing the payment made to the merchant.