Method and system for providing electronic bill payment and presentment

Abstract

An embodiment of the present invention relates to capturing payer information and biller information for generating menu delivered to a customer to activate the billers for electronic payment and/or electronic presentment by selecting one or more billers. A method for facilitating electronic payment related services to at least one payer entity for making payments to at least one biller may comprise the steps of collecting payer information associated with the at least one payer entity; collecting billing information associated with the at least one payer entity; identifying one or more billers associated with the at least one payer entity from the payer information and the billing information, where the at least one payer entity has a relationship with each of the one or more billers; generating a menu for the at least one payer entity to select one or more billers for activating one or more electronic payment related services; and activating the one or more electronic payment related services in response to the at least one payer entity's selection of the one or more billers.

Description

FIELD OF THE INVENTION

The present invention relates generally to processing payments, and more particularly, to a method and system for providing electronic bill payment and presentment services to a customer.

BACKGROUND OF THE INVENTION

Consumer adoption of electronic bill payment and presentment (also referred to as “EBPP”) has been much slower than anticipated. Many banks are eager to encourage their customers to use bill payment. Electronic payments would also provide banks with savings in cost and resources. Although variations in costs may alter the calculation, many banks and customers find that EBPP services are attractive provided that several bills (e.g., seven recurring bills) can be paid.

In general, initiating bill payment services, such as an EBPP, may be daunting for consumers. Many banks do not make the process easy, and at best provide only a list of billers. For billers already listed, payers must add information regarding their individual account numbers and other information necessary to make payments. For all other billers, complete information about the biller must be input manually by the customer or bill payer. This can be a tedious and time consuming process with a high potential for errors and mistakes.

On the merchant side, replacing checks with electronic payments for automatic reconciliation would provide cost reductions. Transactions may be completed more efficiently and in a more timely manner.

Checkfree™ is the dominant bill payment service provider, largely because at great cost they developed a very large biller database. However, even though Checkfree™ has attempted to increase the number of billers that will accept electronic payment, each month a substantial percentage of Checkfree™ bills are still sent physically through the mail. As a result, the efficiencies associated with automatic bill payment are not realized.

As with many new payment systems, EBPP faces the classic ‘chicken or the egg’ conundrum. Both payers and billers generally require a clear value proposition before they will change their behavior. Accelerating the change to EBPP will require benefits to be increased or the burdens to be reduced. Billers need an adequate number of payers willing to pay electronically to justify making changes. From the perspective of payers, the aggravation of setting up a bill payment account must be reduced and the number of bills payable electronically increased.

If a bank operates a biller's lockbox and holds the payer's demand deposit account (also referred to as a “DDA”), a simple on-the-bank transaction is possible.

Further, a payer's bank may not know which of the biller's accounts should be credited and will rarely know the specific customer account number. Thus, the payer's bank does not have enough information from a check to facilitate future electronic transfers.

The biller's lockbox bank may have the information needed to replace future checks with electronic transfers (e.g., the payer's checking account number, payer's account number with biller and biller's payment account). However, the lockbox bank does not have the payer customer relationship.

Other drawbacks may also be present.

SUMMARY OF THE INVENTION

Accordingly, one aspect of the invention is to address one or more of the drawbacks set forth above.

According to an exemplary embodiment of the present invention, a method for facilitating electronic payment related services to at least one payer entity for making payments to at least one biller comprises the steps of collecting payer information associated with the at least one payer entity; collecting billing information associated with the at least one payer entity; identifying one or more billers associated with the at least one payer entity from the payer information and the billing information, where the at least one payer entity has a relationship with each of the one or more billers; generating a menu for the at least one payer entity to select one or more billers for activating one or more electronic payment related services; and activating the one or more electronic payment related services in response to the at least one payer entity's selection of the one or more billers.

In accordance with other aspects of this exemplary embodiment of the present invention, the payer information comprises payer identification data and payer account number; the payer information is gathered from a payment item; the payer information is gathered from a payer bank associated with the at least one payer; the billing information comprises biller identification data, biller's payment account and payer account number at the biller; the biller information is gathered from one of remittance advice and coupon associated with a payment item, both sent from the at least one payer; the biller information is gathered from at least one lockbox entity associated with the at least one biller; the billing information is collected from a consortium of billers wherein the billers comprise merchants; the billing information is collected from a consortium of banks associated with one or more of billers and payers; the one or more electronic payment related services comprise one or more of electronic payment and electronic presentment; the menu is a graphical user interface accessible via the Internet; the menu is electronically transmitted to the at least one payer entity; the method further comprises the step of generating one or more incentives for the at least one payer entity for participation in the one or more electronic payment related services; a lockbox entity receives the payer information and billing information for gathering data to perform electronic payment related services; and the payer modifies the one or more electronic payment related services.

According to another exemplary embodiment of the present invention, a system for facilitating electronic payment related services to at least one payer entity for making payments to at least one biller comprises collect payer data module for collecting payer information associated with the at least one payer entity; collect biller data module for collecting billing information associated with the at least one payer entity; biller list module for identifying one or more billers associated with the at least one payer entity from the payer information and the billing information, where the at least one payer entity has a relationship with each of the one or more billers; menu module for generating a menu for the at least one payer entity to select one or more billers for activating one or more electronic payment related services; and activate module for activating the one or more electronic payment related services in response to the at least one payer entity's selection of the one or more billers.

According to yet another exemplary embodiment of the present invention, at least one signal embodied in at least one carrier wave for transmitting a computer program of instructions configured to be readable by at least one processor for facilitating electronic payment related services to at least one payer entity for making payments to at least one biller comprises payer data collecting means for collecting payer information associated with the at least one payer entity; biller data collecting means for collecting billing information associated with the at least one payer entity; identifying means for identifying one or more billers associated with the at least one payer entity from the payer information and the billing information, where the at least one payer entity has a relationship with each of the one or more billers; generating means for generating a menu for the at least one payer entity to select one or more billers for activating one or more electronic payment related services; and activating means for activating the one or more electronic payment related services in response to the at least one payer entity's selection of the one or more billers.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an exemplary diagram illustrating a system for gathering information for facilitating electronic bill payment and/or presentment services according to an embodiment of the present invention.

FIG. 2 is an exemplary diagram of an electronic bill payment and presentment system according to an embodiment of the present invention.

FIG. 3A illustrates an example of a graphical user interface for presenting a menu to a payer for electronic services selection according to an embodiment of the present invention.

FIG. 3B illustrates an example of a graphical user interface for presenting a menu to a payer for payment services according to an embodiment of the present invention.

FIG. 4 is a flowchart illustrating a process for providing electronic bill payment and/or presentment according to an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the present invention are directed to various aspects of electronic bill payment and presentment. According to one exemplary embodiment, a retailer or lockbox operator may capture payer information as well as biller information where a menu is generated for a customer to activate the billers for electronic payment and/or electronic presentment by selecting one or more billers.

FIG. 1 is an exemplary diagram illustrating a system for gathering information for facilitating electronic bill payment and/or presentment services according to an embodiment of the present invention. While most the elements are shown as a single element, it is understood that multiple elements, participants and/or entities may be implemented. In the exemplary embodiment of system 100, Payer 110 may receive a bill from a merchant or biller entity, represented by Biller 140. Biller may represent a merchant or other provider of services and/or goods for sale to a customer, who may be represented by Payer 110. Examples of purchases may include, but are not limited to, telephone services, cable services, credit card statements, health club fees, mortgage payments, mobile telephone services, rental payments, insurance premiums and other one-time and/or recurring payments.

Payer 110 may represent a customer, recipient and/or payer of services and/or goods from a merchant or biller, and/or other paying entity. Payer 110 may include an individual, small business, corporation, government entity, public service entity, non-profit organization, or other entity. It is understood that the payer may or may not be the customer who receives the goods and/or services. Payer 110 may be associated with a Payer Bank 112. Payer Bank 112 may represent a financial institution from which funds may be deposited and/or withdrawn. Financial institutions may include any entity that performs financial services, such as check processing, deposits, wire transfers, etc. For example, Payer 110 may have an account at Payer Bank 112 from which funds may be transferred to an intended recipient.

Upon receipt of a bill (or bill presentment), Payer 110 may forward a payment item (e.g., a check) and associated paperwork which may include a coupon, remittance advice or other paperwork. Generally, the Payer 110 may receive a preaddressed envelope with the address of the intended recipient of the payment. Payment may be sent to a financial institution (or other receiving entity) associated with the merchant or biller.

In this exemplary embodiment, the payment item and associated paperwork may be received at Lockbox 120 or Lockbox Operator 122. While a single Lockbox is shown, multiple Lockboxes or a consortium of Lockboxes may be implemented. Some banks or financial institutions may operate physical lockbox operations on behalf of their biller clients. Lockbox 120 may represent a bank-owned or bank-operated lockbox, a retail lockbox, a lockbox operated by one or more billers, or other equivalent entity or service. In addition, Lockbox 120 may be operated by Lockbox Operator 122. Lockbox Operator 122 may include a biller, biller bank, lockbox bank, a non-bank operator or other entity.

Lockbox 120 may receive customer payments and process the payments. For example, from the payment item (e.g., a check), payer name, address and other contact information may be identified as well as the payment amount and payer bank (or financial institution). Other information may be obtained from the check or other payment item. From the associated paperwork (e.g., coupon, remittance advice, etc.), the biller, payer name, payer address (and/or other contact information), payment amount, biller's assigned account number for the payer and/or other information may be obtained. Lockbox 120 may associate each check (or payment item) and associated paperwork received from a payer with a particular biller account. Through this processing, Lockbox 120 may collect payer data, biller data and/or other data associated with electronic payment, presentment and/or other services. With this information, Lockbox 120 may identify various billers for which electronic payment, presentment and/or other services may be provided. Lockbox 120 may maintain information for replacing checks with electronic transfers, such as the payer's checking account number, the payer's account number with the biller and the biller's payment account. In addition, Lockbox 120 may send information to Biller Bank 130 and/or individual billers. For example, remittance advice (or other information) may be sent to Biller 142 directly or through Biller Bank 130. Other data may be forwarded via various schemes.

Electronic payment may involve transferring funds from a payer account at Payer Bank 112 to an appropriate account at Biller Bank 130. Electronic payment may include electronic transfer of funds, image replacement document (IRD), Automated Clearing House (ACH), Accounts Receivable Conversion (ARC) and other forms of electronic payment. Electronic presentment may involve presenting a bill or other request for payment via an electronic or other communication to Payer 110 from Biller 140 or Biller Bank 130 (or other agent or representative). For example, an electronic bill may be emailed to Payer 110. In another example, an email (or other) notification may instruct Payer 110 to access a secure website to view a bill as well as other information. Electronic presentment may include Electronic Check Presentment (ECP) and other variations.

Customer payments may be delivered to an appropriate biller bank where the biller bank may then process the payments for deposit directly into an appropriate bank account. Biller clients may include Biller Bank 130, 132. Biller Bank 130 may be associated with a plurality of billers, as shown by Billers 140, 142. Similarly, Biller Bank 132 may be associated with Billers 144, 146.

Generally, Payer Bank 112 alone does not know which of the biller's account should be credited and does not know the specific customer account number with the biller. Thus, the payer bank by itself does not have enough information from a check to facilitate future electronic transfers. According to an exemplary application, Lockbox 120 may have an arrangement with Payer Bank 112, as shown by 160, for converting each transaction to an electronic payment. For example, the arrangement may involve Lockbox 120 paying a fee to Payer Bank 112 for each converted payment. According to another example, Payer Bank 112 may pay a fee to Lockbox 120 for each electronic conversion or other agreed services. Other arrangements with fees and/or other incentives may be implemented between Payer Bank 112 and Lockbox 120. Further, various information and/or data may be exchanged between Payer Bank 112 and Lockbox 120. By contract with Payer Bank 112, Lockbox 120 may agree to facilitate payers making electronic transfers to billers. For example, Payer Bank 112 may provide Lockbox 120 with payment files, providing information concerning the payer's checking account, the biller's name and/or other information. Lockbox 120 may automatically credit the correct payer account at the biller. According to another example, Lockbox 120 may convey a list of payers that pay Lockbox 120 to Payer Bank 112. Payer Bank 112 may then offer electronic services to the payers, such as Payer 110. Transparency makes it easy for various participants to audit the fees owed by Lockbox 120 to Payer Bank 112.

In addition, Payer Bank 112 may offer incentives to Payer 110 to encourage acceptance of electronic bill presentment and/or other electronic services. Various incentive arrangements involving credits, bonuses, discounts and/or other inducements may be implemented. For example, Payer Bank 112 may offer an incentive (e.g., monetary incentive) to Payer 110 to participate in electronic services for a certain time period (e.g., 6 months). Once Payer 110 participates in the services for the time period, it is likely that the payer will continue to use the electronic services indefinitely. According to another example, a biller (e.g., merchant) may purchase (or otherwise acquire) email addresses of payers from Payer Bank 112 to facilitate electronic presentment services. Other arrangements for acquiring email addresses of payers may be implemented. As billers have great economic incentives to convert paper bills to electronic presentment, various incentives may be provided to payers from billers themselves.

In this exemplary embodiment, lockboxes have an important role in facilitating conversion from expensive physical bill/check processing to electronic transmissions. Lockboxes may negotiate attractive compensation arrangements with billers (and/or other participants) to accelerate this process. It may also provide motivation for banks to consider buying additional physical lockbox operations or services. For example, a particular bank may offer billers an attractive fixed price, multi-year contract for lockbox transactions.

With agreements between payer banks and lockboxes shown by 160, the payer set-up for electronic bill payment may be vastly simplified. By referencing a payer's check history, payer banks may create a list of a payer's past payees. This list may be matched against billers serviced by lockbox banks with which a payer bank has an agreement. Payer bank may then present the payer with a list of entities for which the bank can facilitate electronic payments. Payers may then decide on a check by check, automatic draw or other basis to pay bills electronically. The entire process is efficient and very convenient for payers. Further, the process does not depend on electronic bill presentment. As the lockbox associates a payer's payments with specific biller accounts, a payer may pay any biller electronically.

According to another exemplary application, banks may leverage their historic network advantages. For example, banks may agree to collaborate on a reciprocal basis to identify, from bill-pay customer checks, information that will facilitate future electronic payments between the payer and the payee, e.g., did the payee's lockbox bank register the payee's billing account identifier for the payer, which account of the payee credited the check(s), etc. Such information may facilitate electronic payment to payees, with or without cooperation from the billers.

According to another example, banks may offer customers a list of payees of historical checks from payee account information available from the cancelled check (or other payment item). The customer may then electronically make payments to any payee. This may provide much of the functionality of peer-to-peer payments, except for non-recurring payments, such as one-time auction payments. According to an exemplary application, the value is to use existing accounts and payment methods wherever possible. In this manner, the banks may isolate certain payment systems to the narrow purposes (e.g., ad hoc payments to strangers) for which they can provide the easiest solution.

A constantly or periodically updated list of payees (which behind the scenes may be connected with either or both, the bank account destination and the payer's account, if the payee is a biller) may be generated, any one of which may be sent cash or other payment automatically. According to an embodiment of the present invention, a new payee may receive a physical check the first time, but thereafter the payee may receive electronic funds paid to the account shown on the cancelled check (or other payment item).

From an economic perspective, there are benefits and incentives for various participants involved. For example, payer banks may facilitate enrolling their customers in electronic bill payment and/or presentment services thereby reducing the cost of paying checks on their behalf. Payer banks have great incentive to switch to electronic payment and presentment services due, at least in part, to the high cost of clearing physical checks. Payer banks also have a trusted relationship with the payer. As many banks participate in online banking, payer banks may also have payer email addresses and other contact information. By engaging payers in electronic services, such as electronic payment, payer banks are able to reduce expenses and increase efficiencies. Further, billers (e.g., merchants) also have great incentives to convert payers/customers to electronic services to avoid mailing physical bills each month (or other time period), for example. Thus, billers may have an agreement with payer banks to pay for each mailed check avoided. Other arrangements may be implemented to encourage conversion to electronic services.

Lockbox banks may reduce manual processes by switching from physical to electronic processes, leveraging their position in the physical world into an evolution to increase their electronic lockbox business. Biller lockbox charges may be reduced and electronic payment may facilitate consumer acceptance of electronic bill presentment. Therefore, banks may generate new revenues by leveraging information they currently have, arising out of existing customer relationships.

According to an embodiment of the present invention, certain entities within system 100 may have access to payer address, biller name and the biller account number (e.g., the payer account at the biller). In this example, the lockbox or lockbox operator may have the necessary information to facilitate electronic services. For example, the lockbox or lockbox operator may have access to certain data from the check (or other payment item) against the payer's account. For example, the MICR line may be retrieved from a check, which may be used to facilitate electronic services. For ACH participation, payer authorization may be required which may be facilitated by the payer bank. An embodiment of the present invention efficiently combines the information needed to facilitated electronic services and provides economic and other benefits to various participants involved in the process.

Another embodiment of the present invention may be directed to facilitating electronic peer-to-peer payments, as well as customer-to-customer, merchant-to-merchant, supplier-to-merchant, customer-to-government, merchant-to-government, government-to-customer and various other payment scenarios. Provided that a payer has already paid using a check (or other payment item), the payee's bank may facilitate future electronic payments to the same, affiliated and/or related party.

An embodiment of the present invention recognizes the advantages of an on-us transaction. An on-us transaction may involve any banking transaction in which the acquirer and the issuer are the same institution. For example, the payer bank and the biller bank may be the same (or affiliated) bank. Therefore, on-us transactions are low-cost electronic transfers within the same (or affiliated) bank. An embodiment of the present invention provides technology that recognizes that a lockbox payment is received from a payer having a correspondent relation. Thus, by expanding the number of correspondent relations, an increase in on-us transactions may be realized thereby lowering further costs and achieving higher efficiencies. According to another example, on-us transactions may be increased by implementing a lockbox operator that operates a plurality of lockboxes thereby increasing the occurrence of on-us transactions. According to yet another example, lockbox operators may be linked to an additional one or more lockbox operators where electronic files and other formation may be shared to further recognize on-us transactions.

According to another embodiment of the present invention, a consortium of merchants (or billers) may be implemented to consolidate consumer data and/or other data, as shown by Consortium 150. For EBPP to be broadly adopted, a critical mass should be achieved. With regard to lockbox services, merchants are more alike than different. Many merchants may benefit from services, such as check replacement, that minimize merchant discount and conversion to electronic bill presentment. Banks may be easily co-opted by a merchant consortium, since replacement of checks with electronic payments will reduce bank expense.

Various advantages are available to billers of a merchant consortium. For example, merchants would have greater control of their own destiny. Establishing EBPP standards may reduce cost and complexity while assuring aggressive pricing competition among product/service providers. A centralized EBPP utility may minimize merchant technology investment, by spreading the costs across a large base of users. Broad merchant acceptance of a consortium may be realized by focusing on goals that benefit merchants. An exemplary proposition for consumers may involve a single centralized EBPP where a merchant consortium may allocate costs, based on various benefits to individual billers and facilitate current capital/start-up expenses that can be amortized over future transaction volumes.

A merchant consortium of an embodiment of the present invention may consolidate customer data across an entire group. The consortium may send each consumer an individualized list of billers and permit each consumer to enable electronic presentment/payments by simply selecting billers from the list. For example, the consumer may receive a menu of potential billers and select billers by checking off boxes or other user action. By providing a mechanism to share the cost, the merchant consortium may offer consumers attractive financial inducements to make the change to electronic payment, presentment and/or other services. For example, rewards and bonuses may be graduated to incentivize behavior beneficial to merchants, e.g., incremental sums for each biller paid electronically, bonuses for payments by ACH, large premiums for replacing physical bills with electronic bill presentment and/or other inducements.

According to another embodiment of the present invention, a consortium of banks may be implemented for bank centered Lockbox/EBPP consolidation, also shown by Consortium 150. Further, a combination of banks and merchants may be implemented as well. For example, bank strategies may include a combination of seeking to sign merchants to comprehensive lockbox service contracts (e.g., 5 year contacts, etc.), which may include a proviso that the biller make available its client address list and lockbox information, in order to facilitate the bank's attempts to convert its customers to EBPP. Bank strategies may include implementing contracts providing banks with customer address and lockbox information, and merchant agreement to pay a bounty if, and to the extent, the bank is able to convert customers to electronic payment and/or presentment and contracts for banks to host a consolidated site for bill presentment by many merchants. For example, these contracts may provide that billers would not compete with the bank's efforts to convert biller customers to EBPP. If the bank is quickly able to sign up a group of billers, their weight may preclude subsequent attempts to build critical mass for a merchant consortium. In addition, banks may facilitate on behalf of other lockbox service providers use of information available to them.

FIG. 2 is an exemplary diagram 200 of an electronic bill payment and presentment system according to an embodiment of the present invention. Electronic Bill Payment and Presentment (EBPP) System 210 may include various modules for facilitating electronic payment and presentment services for various participants. EBPP system 210 may include Collect Payer Data Module 212, Collect Biller Data Module 214, Identify Biller List Module 216, Generate Menu Module 218, Forward Menu Module 220, Activate Electronic Services 222, Collect Fees Module 224, Apply Incentives Module 226 and/or other module 228. Additional functionality may also be supported by EBPP system 210. Further, the modules may be combined in various combinations and further separated, if so desired. While a single system is shown, multiple systems may be implemented. The modules may be spread throughout multiple systems as well. Various other formats and implementations may be realized. EBPP system 210 may be provided by or affiliated with various participants, including Lockbox 234, Payer bank 232, Biller Banks 240, 242, Consortium 260 and/or others.

Data received by the modules of EBPP system 210 may be stored, manipulated, indexed in various storage devices, including Databases 270, 272. Databases may be combined or further separated, as preferred by various applications.

Collect Payer Data Module 212 may receive information about payers from various sources, including lockboxes, banks, payment items (e.g., check, coupon, remittance advice, etc.) and/or other sources of information. Payer data may include payer identification data, check account number, and/or other data. Collect Biller Data Module 214 may receive biller information, such as biller's payment account data, payer account number with the biller and/or other information. Billers 254, 256 may interface directly with EBPP system 210. In another example, Billers 250, 252 may interface with EBPP 210 through Biller Banks 240, 242. As discussed above, a Consortium 260 of Billers 262, Banks 264 and/or combination of both billers and banks may also communicate with EBPP 210.

Identify Biller List module 216 may identify a list of eligible billers from the payer data and/or biller data. For example, based on previously paid bills, a list of billers may be generated. The list of eligible billers may then be matched against eligible billers, such as billers that participate in electronic bill payment and presentment services and/or billers associated with Lockbox 234. In addition, adjustments to the biller list may be made. For example, a payer may switch mobile phone companies where the previous mobile phone company will be removed and the new mobile phone company will be added. Other adjustments and/or changes may be made.

Generate Menu Module 218 may generate a menu for each payer (or group of payers), as illustrated by Customer 230 for allowing the selection of electronic bill payment and/or presentment (and/or other electronic services) for the billers identified by module 216. The list of billers and associated information for electronic payment and presentment may be automatically generated through an embodiment of the present invention where manual input of data for each biller is avoided. In this example, a user can simply select the desired billers for electronic payment and/or presentment activation. The menu may be forwarded to Customer/Payer 230 via Forward Module 220. Forward Module 220 may forward the menu to the Customer/Payer 230 via various forms of communication, including email, Internet, voice, mobile phone, text message, PDA, other wireless mobile devices and/or other forms of communication. In another example, the customer may access EBPP 210 through an interface to view the menu for the specific customer.

Activate Electronic Services 222 may activate electronic payment, presentment and/or other services for the billers selected by Customer/Payer 230. For electronic payment, funds may be transferred electronically from Payer Bank 232 to a Biller Bank (e.g., 242). For electronic presentment, a biller (e.g., 250) may electronically transmit a bill (or billing information) to the Customer/Payer 230. Electronic services may be activated by the customer/payer. In another example, the electronic services may be activated by a biller, bank, lockbox or other authorized entity, after receiving authorization from the customer/payer. For example, with the bill, a customer/payer may receive an offer for electronic payment, presentment and/or other services. The customer/payer may indicate activation of electronic services by selecting a box (e.g., checking a box for electronic services activation) or other user action. The indication of activation of electronic services may be forwarded with the check (or other payment). For example, the indication of electronic services may be a separate form, part of the remittance advice, coupon or other paperwork. The activating entity, which may include biller, bank, lockbox, or other entity, may then receive the indication of electronic services and activate the appropriate services for the identified merchant(s) on behalf of the payer.

If a payer selects electronic bill payment, a financial institution associated with the merchant/biller to be paid may be notified about the amount to be paid and the financial institution associated with the payer from which payment will be received. At the appropriate time, the merchant's financial institution may send a request for the funds to the payer's financial institution. The payer's financial institution may process the request and electronically send the payment to the merchant's financial institution. Verification of receipt of the payment may then be sent from the merchant's financial institution to the payer's financial institution as warranted. The accounts may be updated as necessary to account for the transfer of funds.

If a payer selects electronic bill presentment, merchant/billers may electronically present bills to payers. Electronic bill presentment may include an electronic communication, such as sending an email transmission containing the bill. In addition, electronic bill presentment may include sending an email notification to a payer that a bill has been presented on a website accessible to the payer or presenting a bill on a website that is accessible to the payer, where the payer knows that the bill will be posted periodic basis (e.g., monthly, etc.). Other forms of electronic presentment may be used. It is understood that bills presented on a website accessible by one or more payers may include one or more levels of security based on the information presented. Thus, it may be desirable to allow unlimited access of a website for non-sensitive information (e.g., a web posting informing all health club payers that they will be billed $50.00 on August 15). Alternatively, it may be desirable to create a more secure environment requiring a password and login to access a web site containing sensitive information (e.g., viewing credit card purchase information, etc.).

According to another example, certain fees may be collected by Collect Fees Module 224. Depending on a contract or other agreement, fees may be collected for each conversion (or other number of conversions) to electronic transmission from certain participants. For example, fees may be received from Payer Bank 232 to Lockbox 234 (or Lockbox Operator 236) for electronic conversions and/or other services. In addition, fees may be received from Lockbox 234 (or Lockbox Operator 236) to Payer Bank 232 for electronic conversions and/or other services. Payer Bank 232 may charge fees for sharing customer/payer contact information, such as email addresses, to facilitate electronic presentment or other services. Other services may also be charged for various participants.

Incentives may be generated and provided to customers (and/or other participants) via Apply Incentives Module 226. For example, customers may be offered an incentive to participate in electronic payment and/or presentment services. Incentives may include monetary incentives ($X per each transaction, a percentage or other amount), discounts, credits and/or other forms of incentive. For example, Payer Bank 232 may offer Customer/Payer 230 incentives to participate in electronic services. The incentives may include a monetary incentive for electronic services participation for a time period, such as 6 months or other time period, to encourage continued participation even after the end of the time period. In another example, a biller may present a customer with an option for both electronic bill payment and electronic bill presentment, as well as an inducement of $25.00 for selecting one of the options. The customer may be asked to provide customer addresses and lockbox information. Incentives between other participants may be implemented. Incentives may be customized for particular types of customers. For example, an avid health club member may receive credit for gym equipment, discounts at a sporting goods store and/or other related activities or products. Therefore, certain targeted information may be used for more customized incentives.

FIG. 3A illustrates an example of a graphical user interface 300 for presenting a menu to a payer for electronic services selection according to an embodiment of the present invention. The graphical user interface 300 includes a function bar 310 having functions used in graphical user interfaces, such as, but not limited to, a back function key, a forward function key, a stop function key, and a print function key. The graphical user interface may be available to a user on a website, via the Internet or other electronic communication. The user may also receive the graphical user interface by an electronic communication, such as an email or other transmission. In addition, the information provided on the graphical user interface may be provided via mail or other form of communication. User selections may be made by various modes of communication, including Internet, email, phone, mail, etc.

In the example illustrated in FIG. 3A, the graphic user interface 300 provides a menu having a merchant portion 320, an electronic bill payment selection portion 312 and an electronic bill presentment selection portion 314. Merchant portion 320 contains a listing of merchants that have presented bills to the payer in the past. In the example of FIG. 3A, the merchants may include a telephone services provider, an electric company, a cell phone services provider, a health club, a credit card, a mortgage provider, an internet services provider, and a merchant card company. It will be understood that the list presented in graphical user interface 300 is exemplary only and that other merchants may also be included in a list, while one or more of the merchants on the exemplary list may be omitted, depending upon the particular customer and the availability of the merchant/biller information.

As described above, the menu presented on graphical user interface 300 may include electronic bill payment selection portion 312 and electronic bill presentment selection portion 314. Other electronic services may also be provided. In the present exemplary embodiment, electronic bill payment selection portion 312 is in the form of buttons (or other activation mechanism) that a customer may activate by way of a mouse or other selection mechanism (e.g., keyboard, touch screen, infrared pointer, etc.). The customer may activate those buttons corresponding to the particular merchant for which electronic bill payment is desired. In the present exemplary embodiment, electronic bill presentment selection portion 314 is also in the form of buttons that a payer may activate by way of a mouse or other selection mechanism (e.g., keyboard, touch screen, infrared pointer, etc.). The customer may also activate the buttons corresponding to the particular merchant for which electronic bill presentment is desired. The payer may select any combination of electronic bill presentment and payment for one or more merchants. For example, the payer may select electronic bill presentment and payment for the health club, electronic bill presentment only for the credit card, electronic bill payment only for the Internet provider and neither electronic bill presentment nor electronic bill payment for the mortgage provider. Other combinations may also occur.

Incentives for participation may be provided to the payer, as shown by Incentive 316. In this example, an incentive of $10.00 is provided for participation in electronic payment and electronic presentment services, as selected by the payer where $5.00 may be offered for each electronic payment selection and another $5.00 for electronic presentment selection. Other monetary amounts, which may be different for electronic payment and presentment, may be provided. A total incentive amount may be provided. In addition, the incentives may be effective for a certain time period of participation, e.g., 6 months. The payer may select submit button 230 to activate the selected electronic services for the merchants.

FIG. 3B illustrates an example of a graphical user interface 300 for presenting a menu to a payer for payment services according to an embodiment of the present invention. The graphical user interface 300 includes a function bar 310 having functions used in graphical user interfaces, such as, but not limited to, a back function key, a forward function key, a stop function key, and a print function key. The graphical user interface may be available to a user on a website, via the Internet or other electronic communication. The user may also receive the graphical user interface by an electronic communication, such as an email or other transmission. In addition, the information provided on the graphical user interface may be provided via mail or other form of communication. User selections may be made by various modes of communication, including Internet, email, phone, mail, etc.

In the example illustrated in FIG. 3B, the graphic user interface 300 provides a menu having a merchant portion 320, an electronic bill payment selection portion 330 and an electronic bill presentment selection portion 340 displaying the payer's selections made at the menu of FIG. 3A.

As shown by 360, the payer may enter an amount (which may be the total amount, partial amount, minimum amount, etc.) for each merchant/biller for automatic bill payment. For some services, a flat monthly (or other periodic) fee may apply. For such services, the amount may be automatically filled in for the payer. As shown in this example, health club charges may be $50.00 each month and mortgage payment may be $2000 each month. Other payments may be filled in by the payer.

Other payment and/or presentment functions may also be provided. For example, a scheduling option including a calendar, an alert system including payer specified notifications and/or other functions may be available to the payer. For example, calendar 370 enables a payer to schedule specific times of payment, including day of month and even time of day. For example, if a merchant card has a monthly payment deadline of the 15^th of each month, the payer may schedule payment to be made on the 13^th of each month. According to another example, payment may be made right before each due date to ensure maximum fund availability to the payer. Alert 372 enables a payer to specify alerts based on predetermined conditions. For example, an alert may be sent to the payer's preferred mode of communication (e.g., email) for payment reminders of one or more payments. In another example, a notification identifying a condition, such as insufficient funds or other low threshold, may be relayed to the payer. Other forms of notification may be applied, such as phone reminders, cell phone messages, emails and/or other forms of communication. Different conditions may warrant different forms of communication.

Other functions may include History 374 and Reject 376. History 374 may provide historical data related to payment, presentment or other data. For example, the payer may view historical electronic payment and/or presentment data for each merchant for a designated time period. Previous payment amounts may be viewed and analyzed for accuracy or other purpose. Reject 376 may provide the payer with an option to reject (or dispute) a bill presentment (or other unilateral action) from a merchant. For example, if a payer is erroneously charged, the payer may reject the bill presentment for a specific merchant, amount or transaction. For example, a payer may make a one-time purchase for an item and receive recurring bills for the same or related product—the subsequent bills may be rejected (or challenged) by Reject 376. In another example, a payer may make a one-time payment for another recipient (e.g., child, sibling, parent, etc.) but continue to receive bills on behalf of the recipient. Other functions and tools may be implemented to facilitate electronic payment and presentment services. Once the payer has made the desired selections, the submit button 340 may be activated.

FIG. 4 is a flowchart illustrating a process for providing electronic bill payment and/or presentment according to an embodiment of the invention. At step 410, payer information may be collected. At step 412, biller information may be collected. At step 414, a list of eligible billers for electronic payment and/or presentment services may be identified and further matched against a list of participating billers. A list of potential billers for payer activation may be generated at step 416. At step 418, customers may be allowed to select billers for payment and/or presentment services. For example, a menu may be generated and presented to a payer. Appropriate electronic payment and/or presentment services may be activated as identified by the customer, at step 420. Based on customer activities and/or other circumstances, the list of potential billers may be adjusted, at step 422. Although the process illustrated in FIG. 4 has been described in one particular combination of steps, it is understood that other steps may be included within the process, steps may be omitted from the process, steps may be performed in a different order, or some combination thereof. The process illustrated in FIG. 4 will now be described in greater detail.

At step 410, payer information may be collected. Payer information may be gathered from various sources. For example, payer information may be gathered from a check (or other payment item), which may include payer name, billing address of the payer, and/or other contact information (e.g., telephone numbers, email addresses, etc.) Payer information may also include the payer's account number or other account identification. In addition, payment amount may be verified from the payment item. Financial institution information may also be gathered. By way of example, financial institution information may include, but is not limited to, information regarding the relationship between the payer and the financial institution, such as the payer's name, the name of the financial institution, the account number(s) associated with the payer, the financial routing number associated with the financial institution, the address of the financial institution, and contact information for the financial institution (e.g., telephone number, email address, website address, etc.). According to an embodiment of the invention, financial institution information may be gathered by the financial institution itself.

At step 412, merchant/biller information may be gathered. By way of example, merchant/biller information may include, but is not limited to, information regarding the relationship between a payer and the merchant/biller, such as the identity of the merchant that is supplying the goods and/or service, the account number(s) the merchant/biller has associated with the payer, biller payment account and/or other information. According to an embodiment of the invention, merchant/biller information may be gathered by the merchant/biller itself.

With the payment item, associated paperwork may be received, which may include a coupon, remittance advice or other paperwork The associated paperwork may include information, such as biller (or other payee identifier), payer name, payer address, other payer contact information, biller assigned account number for the payer, payment amount and/or other information.

At step 414, a list of potential billers may be identified for electronic payment and/or presentment services. The list of billers may be identified from payer information, biller information and/or other data. The list of potential billers may be matched against participating billers associated with the lockbox.

At step 416, the list of potential billers may be identified and presented to the user as a menu, at step 418. According to an embodiment of the invention, based on payer information and merchant/biller information, the menu may include a list of billers (or merchants) with which the customer has a relationship. This menu may be presented to the customer in a number of ways, such as, but not limited to, electronic presentation (e.g., website, email transmission, etc.), hard copy presentation (e.g., mailing the menu printed on a piece of paper), and voice presentation (e.g., telephone message) and/or other forms of communicating information. An exemplary menu is shown by FIG. 3, as discussed above.

At step 418, payers may select one or more billers for electronic payment, presentment and/or other services. According to one example, customer selections may be received based on the manner in which the menu is presented to the customer. Thus, if the menu is presented on a graphical user interface, such as that illustrated in FIG. 3, the payer selections may be received via an electronic transmission. Other manners of receiving selections (e.g., voice instructions, mail, etc.) may also be used. The received selections may be associated into the payer account. The selections may be associated with the information stored within a database.

At step 420, electronic payment and/or presentment may be activated for future electronic services, as identified by the customer's selections. At step 422, adjustments to the list of billers for electronic payment and/or presentment may be made periodically or as new billers are identified and added. Modifications may also include timing of payment, amount of payment, format of presentment, and other various characteristics associated with electronic payment, presentment and/or other services. Other payment and/or presentment modifications may also be implemented, per the customer's instructions.

According to an embodiment of the invention, bills may be analyzed to identify periodic bill presentments, e.g., weekly, monthly, bi-monthly, quarterly, yearly, etc., for conversion to an electronic bill payment and presentment process. Because of the periodic nature of these types of bills, payers may be more likely to desire electronic bill presentment and payment than with bills that are more sporadic in nature. However, it is understood that all types of bills may be included in the present invention.

According to an embodiment of the invention, the systems and processes described in this invention may be implemented on any general purpose computational device, either as a standalone application or applications, or even across several general purpose computational devices connected over a network and as a group operating in a client-server mode. According to another embodiment of the invention, a computer-usable and writeable medium having a plurality of computer readable program code stored therein may be provided for practicing the process of the present invention. The process and system of the present invention may be implemented within a variety of operating systems, such as a Windows® operating system, various versions of a Unix-based operating system (e.g., a Hewlett Packard, a Red Hat, or a Linux version of a Unix-based operating system), or various versions of an AS/400-based operating system. For example, the computer-usable and writeable medium may be comprised of a CD ROM, a floppy disk, a hard disk, or any other computer-usable medium. One or more of the components of the system or systems embodying the present invention may comprise computer readable program code in the form of functional instructions stored in the computer-usable medium such that when the computer-usable medium is installed on the system or systems, those components cause the system to perform the functions described. The computer readable program code for the present invention may also be bundled with other computer readable program software. Also, only some of the components may be provided in computer-readable code.

Additionally, various entities and combinations of entities may employ a computer to implement the components performing the above-described functions. According to an embodiment of the invention, the computer may be a standard computer comprising an input device, an output device, a processor device, and a data storage device. According to other embodiments of the invention, various components may be computers in different departments within the same corporation or entity. Other computer configurations may also be used. According to another embodiment of the invention, various components may be separate entities such as corporations or limited liability companies. Other embodiments, in compliance with applicable laws and regulations, may also be used.

According to one exemplary embodiment of the present invention, the system may comprise components of a software system. The system may operate on a network and may be connected to other systems sharing a common database. Other hardware arrangements may also be provided.

Other embodiments of the present invention are also envisioned.

Claims

1. An automated method for facilitating electronic payment related services to at least one payer entity for making payments to at least one biller, wherein the method is executed by a programmed computer processor, the method comprising the steps of: collecting payer information associated with the at least one payer entity from a lockbox entity;collecting billing information associated with the at least one payer entity from the lockbox entity, wherein the lockbox entity is operated by a lockbox operator that further operates a plurality of lockbox entities to effectuate on-us transactions through correspondent relations;automatically identifying a list of one or more eligible billers associated with the at least one payer entity from the payer information and the billing information collected from the lockbox entity using the programmed computer processor, without manual entry of the one or more billers by the at least one payer entity to the programmed computer processor, where the at least one payer entity has a relationship with each of the one or more billers;matching the list of one or more eligible billers with one or more billers serviced by a lockbox bank with which a payer bank, associated with the at least one payer entity, has an agreement;generating a menu for the at least one payer entity to select one or more of the one or more billers, automatically identified from the payer information and billing information collected from the lockbox entity using the programmed computer processor, for activating one or more electronic payment related services; andactivating the one or more electronic payment related services in response to the at least one payer entity's selection of the one or more billers, wherein the one or more billers form a consortium to consolidate payer data.

2. The method of claim 1, wherein the payer information comprises payer identification data and payer account number.

3. The method of claim 2, wherein the payer information is gathered from a payment item.

4. The method of claim 2, wherein the payer information is gathered from a payer bank associated with the at least one payer.

5. The method of claim 1, wherein the billing information comprises biller identification data, biller's payment account and payer account number at the biller.

6. The method of claim 5, wherein the biller information is gathered from one of remittance advice and coupon associated with a payment item, both sent from the at least one payer.

7. The method of claim 5, wherein the biller information is gathered from at least one lockbox entity associated with the at least one biller.

8. The method of claim 1, wherein the billing information is collected from a consortium of billers wherein the billers comprise merchants.

9. The method of claim 1, wherein the billing information is collected from a consortium of banks associated with one or more of billers and payers.

10. The method of claim 1, wherein the one or more electronic payment related services comprise one or more of electronic payment and electronic presentment.

11. The method of claim 1, wherein the menu is a graphical user interface accessible via the Internet.

12. The method of claim 1, wherein the menu is electronically transmitted to the at least one payer entity.

13. The method of claim 1, further comprising the step of: generating one or more incentives for the at least one payer entity for participation in the one or more electronic payment related services.

14. The method of claim 1, wherein a lockbox entity receives the payer information and billing information for gathering data to perform electronic payment related services.

15. The method of claim 1, wherein the payer modifies the one or more electronic payment related services.

16. A system for facilitating electronic payment related services to at least one payer entity for making payments to at least one biller, the system comprising a programmed computer processor which communicates with a user via a network;payer data module configured to collect payer information associated with the at least one payer entity from a lockbox entity;biller data module configured to collect billing information associated with the at least one payer entity from the lockbox entity, wherein the lockbox entity is operated by a lockbox operator that further operates a plurality of lockbox entities to effectuate on-us transactions through correspondent relations;biller list module configured to automatically identify a list of one or more eligible billers associated with the at least one payer entity from the payer information and the billing information collected from the lockbox entity using the programmed computer processor, without manual entry of the one or more billers by the at least one payer entity to the programmed computer processor, where the at least one payer entity has a relationship with each of the one or more billers and further configured to match the first list of one or more eligible billers with one or more billers serviced by a lockbox bank with which a payer bank, associated with the at least one payer entity, has an agreement;menu module configured to generate a menu via the network for the at least one payer entity to select one or more of the one or more billers, automatically identified from the payer information and billing information collected from the lockbox entity using the programmed computer processor, for activating one or more electronic payment related services; andactivate module configured to activate the one or more electronic payment related services in response to the at least one payer entity's selection of the one or more billers, wherein the one or more billers form a consortium to consolidate payer data.

17. The system of claim 16, wherein the payer information comprises payer identification data and payer account number.

18. The system of claim 17, wherein the payer information is gathered from a payment item.

19. The system of claim 17, wherein the payer information is gathered from a payer bank associated with the at least one payer.

20. The system of claim 16, wherein the billing information comprises biller identification data, biller's payment account and payer account number at the biller.

21. The system of claim 20, wherein the biller information is gathered from one of remittance advice and coupon associated with a payment item, both sent from the at least one payer.

22. The system of claim 20, wherein the biller information is gathered from at least one lockbox entity associated with the at least one biller.

23. The system of claim 16, wherein the billing information is collected from a consortium of billers wherein the billers comprise merchants.

24. The system of claim 16, wherein the billing information is collected from a consortium of banks associated with one or more of billers and payers.

25. The system of claim 16, wherein the one or more electronic payment related services comprise one or more of electronic payment and electronic presentment.

26. The system of claim 16, wherein the menu is a graphical user interface accessible via the Internet.

27. The system of claim 16, wherein the menu is electronically transmitted to the at least one payer entity.

28. The system of claim 16, further comprising: incentive module for generating one or more incentives for the at least one payer entity for participation in the one or more electronic payment related services.

29. The system of claim 16, wherein a lockbox entity receives the payer information and billing information for gathering data to perform electronic payment related services.

30. The system of claim 16, wherein the payer modifies the one or more electronic payment related services.

31. An automated method for facilitating electronic payment related services to at least one payer entity for making payments to at least one biller, wherein the method is executed by a programmed computer processor, the method comprising the steps of: collecting payer information associated with the at least one payer entity, wherein the payer information comprises payer identification data and payer account number;collecting billing information associated with the at least one payer entity, wherein the billing information comprises biller identification data, biller's payment account and payer account number at the biller and wherein a lockbox entity receives the payer information and billing information for gathering data to perform electronic payment related services, wherein the lockbox entity is operated by a lockbox operator that further operates a plurality of lockbox entities to effectuate on-us transactions through correspondent relations;automatically identifying a list of one or more eligible billers associated with the at least one payer entity from the payer information and the billing information collected from the lockbox entity using the programmed computer processor, without manual entry of the one or more billers by the at least one payer entity to the programmed computer processor, where the at least one payer entity has a relationship with each of the one or more billers;matching the list of one or more eligible billers with one or more billers serviced by a lockbox bank with which a payer bank, associated with the at least one payer entity, has an agreement;generating a menu for the at least one payer entity to select one or more of the one or more billers, automatically identified from the payer information and billing information collected from the lockbox entity using the programmed computer processor, for activating one or more electronic payment related services;activating the one or more electronic payment related services in response to the at least one payer entity's selection of the one or more billers, wherein the one or more electronic payment related services comprise one or more of electronic payment and electronic presentment, wherein the one or more billers form a consortium to consolidate payer data; andenabling the payer to modify the one or more electronic payment related services.

32. The method of claim 31, wherein the billing information is collected from a consortium of billers wherein the billers comprise merchants.

33. The method of claim 31, wherein the billing information is collected from a consortium of banks associated with one or more of billers and payers.

34. The method of claim 31, further comprising the step of: generating one or more incentives for the at least one payer entity for participation in the one or more electronic payment related service.