System and Method for Electronic Bill Pay and Presentment
A system and method is disclosed enabling a customer payor to make payment to a payee in a networked environment using a credit card, revolving credit, or other credit account. The payment system may provide for online receipt and review of bills, and may allow a customer payor to optionally select one or more alternative secondary accounts for payment in the event that payment cannot be made from a primary credit account. The secondary account may be another credit account, a checking account, a brokerage account, or another type of account. Actual payment may be accomplished by electronic settlement of a credit transaction, electronic funds transfer, or by printing and physically delivering a paper check. A customer payor using the system and method may receive notification concerning the success or failure of the transaction.
This application claims priority from U.S. provisional application Ser. No. 60/264,681 filed Jan. 30, 2001, having one or more of the same inventors as this application, assigned or under an obligation of assignment to the same entity as this application, and which application is incorporated herein by reference.
FIELD OF INVENTIONThe invention relates to the field of financial systems, and more particularly to enabling an individual consumer or other entity to pay bills on a network-based application using a credit account.
BACKGROUND OF THE INVENTIONIn the modern economy, individual consumers and other entities are presented with bills for goods and services purchased from multiple vendors, service providers and others. Payment for many such goods and services are made on a periodic basis, often monthly. Others are one-time transactions. Consumers and other entities may wish to pay periodic and other bills using credit accounts. This may be desirable, for example, where liquid funds are not available to make payment, where the consumer or other entity seeks to take advantage of reward or other incentive programs for making payment with credit, or for other reasons.
In recent years, enabled by the pervasiveness of the Internet, some Web-based services have been developed to enable consumers to view and pay bills online. Such services, however, facilitate payment only from the consumer's checking account, or at times from brokerage or other accounts with check-writing privileges. Such systems therefore may not function for credit accounts, and may not be optimized for the consumer who wishes to pay with credit instead of cash or cash equivalent, on a recurring basis, at certain times of the month, or with other parameters taken into account.
These and other drawbacks exist.
SUMMARY OF THE INVENTIONThe invention overcoming these and other problems in the art relates to a system and method for receiving, viewing, and paying bills online with an option to make payment from one or more credit accounts. One embodiment of the system relies on Internet architectures and Web-based components to arrange selective bill paying using credit facilities and other payment modes. One embodiment of the method includes receiving bills, selecting a bill for payment, selecting a time for payment, selecting a credit account for payment, automatically receiving authorization for payment, and automated settlement of the credit account transaction. Another embodiment allows a consumer to also send payments to persons where a bill has not been received (i.e. a “pay anyone” model).
An object of the invention in one regard is to facilitate the receipt of bills that a consumer wishes to pay with credit. Another object of the invention is to enable on-time payment of bills with credit, providing a benefit to both the payor and the payee. Another object of the invention is to provide for an automated backup or rollover mechanism for payment where a credit account has reached its credit limit, when a payee does not accept payment by credit, or for other reasons.
The invention will be described with reference to the accompanying drawings, in which like elements are referenced with like numbers.
Servers 100, 110, and 120 may host applications facilitating transactions for banks, merchants, or other financial institutions. Servers 100, 110, and 120 may be or include, for instance, a workstation running the Microsoft Windows NT™ NT™, Windows™ 2000, Unix, Linux, Xenix, IBM AIX™, Hewlett-Packard UX™, Novell Netware™, Sun Microsystems Solaris™, OS/2™, BeOS™, Mach, Apache, OpenStep™ or other operating system or platform.
Servers 100, 110 and 120 may interface to one or more databases. As an illustration,
Clients 140, 150, and 160 may be customer terminals such as customer terminal 400 depicted in
Servers 100, 110, and 120 may be connected to each other or to clients 140, 150, or 160 via communications link 170. Communications link 170 may be, include or interface to any one or more of, for instance, the Internet, an intranet, a PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network) or a MAN (Metropolitan Area Network), a storage area network (SAN), a frame relay connection, an Advanced Intelligent Network (MN) connection, a synchronous optical network (SONET) connection, a digital T1, T3, E1 or E3 line, Digital Data Service (DDS) connection, DSL (Digital Subscriber Line) connection, an Ethernet connection, an ISDN (Integrated Services Digital Network) line, a dial-up port such as a V.90, V.34 or V.34bis analog modem connection, a cable modem, an ATM (Asynchronous Transfer Mode) connection, or an FDDI (Fiber Distributed Data Interface) or CDDI (Copper Distributed Data Interface) connection. Communications link 170 may furthermore be, include or interface to any one or more of a WAP (Wireless Application Protocol) link, a GPRS (General Packet Radio Service) link, a GSM (Global System for Mobile Communication) link, a CDMA (Code Division Multiple Access) or TDMA (Time Division Multiple Access) link such as a cellular phone channel, a GPS (Global Positioning System) link, CDPD (cellular digital packet data), a RIM (Research in Motion, Limited) duplex paging type device, a Bluetooth, BlueTeeth or WhiteTooth radio link, or an IEEE 802.11-based radio frequency link Communications link 170 may yet further be, include or interface to any one or more of an RS-232 serial connection, an IEEE-1394 (Firewire) connection, a Fibre Channel connection, an IrDA (infrared) port, a SCSI (Small Computer Systems Interface) connection, a USB (Universal Serial Bus) connection or other wired or wireless, digital or analog interface or connection.
Servers 100, 110, and 120, and clients 140, 150, and 160 may utilize network enabled code in order to facilitate functionality in a network-based environment. Network enabled code may be, include or interface to, for example, Hyper text Markup Language (HTML), Dynamic HTML, Extensible Markup Language (XML), Extensible Stylesheet Language (XSL), Document Style Semantics and Specification Language (DSSSL), Cascading Style Sheets (CSS), Synchronized Multimedia Integration Language (SMIL), Wireless Markup Language (WML), Java™, Jini™, C, C++, Perl, UNIX Shell, Visual Basic or Visual Basic Script, Virtual Reality Markup Language (VRML), ColdFusion™, Common Gateway Interface (CGI) or other compilers, assemblers, interpreters or other computer languages or platforms.
In step 210, the customer may receive and review bills online. An online bill may indicate, for example, the name of the payee, a description of the goods or services provided in exchange for payment, the amount owed, and the date payment is due. In one embodiment, the electronic bill may be posted to the system directly by the merchant. In another embodiment, a service provider may receive a hard copy of the bill, and post the information to the bill payment system so that the customer can receive and review the information online. In another embodiment, step 210 may not apply, for example in the case where a customer has received only a hard copy of a bill, or in the case where the customer seeks to make payment for goods or services, or to make a gift payment, in the absence of a bill or other invoice.
In step 220, the customer payor may enter payment data in preparation for an online payment transaction. In the case where a bill has not been received online, a customer payor may enter payee information 222 such as name, account number, and a description of the goods or services for which payment is to be made; in this instance, it is also necessary to specify the amount of payment 224. The customer may also specify one or more payor accounts 226 from which to make payment. Payor account 226 may be, for example, a checking, brokerage, or money market account, and may be a Direct Deposit Account (DDA). A DDA may be, for instance, a checking or savings account which a bank customer has authorized for direct deposit of wages from an employer.
Payor account 226 may also be a credit card account, a revolving credit account, or other credit account. In one embodiment of the invention, the customer payor may enter a primary account and one or more secondary accounts. A secondary account may be used for payment if, for instance, sufficient funds or credit are not available from the primary account. It also may be the case that certain payees will not accept payment from a credit account. In one embodiment of step 220, a customer may enter the date and time 228 that payment is to be made from the payor to the payee. It may be advantageous, for example, to schedule payment prior to the time that payment is due, but after automatic deposit of payroll funds into the customer's account. Step 228 may also allow a customer payor to request immediate payment to the payee. As described here, an immediate transaction may be a transaction that is initiated within minutes, seconds, or less.
Data entry in step 220 may be accomplished via menu selection, for example where a customer has received more than one online bill or where the customer has already specified one or more payor account alternatives. In another embodiment, data entry step 220 may entail manual entry of alphanumeric characters into pre-defined fields. In one embodiment, a customer may specify payment data for payment transactions in step 220 that are to be executed automatically and without further customer intervention on a recurring basis.
It may be that before a payment transaction can be executed, a certain set of data is required. In step 230, then, a decision may be made by the payment system as to whether the customer payor has specified all necessary data. Where the customer has not, the system may return the customer to step 220 to enter payment data, and the system may further prompt the customer for information that is both missing and necessary. In the case where the customer payor has entered all necessary information, the payment system may initiate the payment transaction.
From the customer payor's perspective, the next step may be an acknowledgement in step 240 that payment has been successfully made to the payee. In one embodiment, step 240 may be near real-time, and while the customer is still logged onto the system. In this instance, a customer payor may receive a system-generated message that is displayed within seconds or minutes from an immediate request for payment. In another embodiment of acknowledgment step 240, the system may send an email or other acknowledgment to the customer payor. In the case where a customer payor has specified a primary and at least one secondary account, the acknowledgement in step 240 may indicate which account or accounts from which payment has been drawn. In this instance, the system may also provide a reason in step 240 explaining why payment was not made from the customer's primary account. Once step 240 concludes, the payment transaction terminates in step 250.
In step 300, data related to payee information 222, amount 224, payor account 226, date and time 228, or other information, may be subjected to initial data processing in step 300. Step 300 processing may check for the availability of all necessary information, such as the decision described in step 230. Step 300 may also validate one or more pieces of data, for example to ensure that a valid date has been entered in step 220, or that the credit card account supplied by the customer payee in step 220 contains the correct number of numeric digits. Other validations may also be performed in step 300. Step 300 processing may additionally entail formatting data into a particular string format or other format required by downstream processes.
In step 302, formatted transaction data may be forwarded to a merchant processor, merchant, or other entity as a request for authorization. In the instance of a payment from a credit card or other credit account, credit approval step 306 will be required. The authorization performed in step 306 may involve several different entities, for example a merchant processor 406, a credit card association 408, an issuer processor 410, and a card issuer 412 as will be later described. The underlying inquiries in step 306 may be whether the credit card or other credit account is a valid account, whether the payee is an authorized user of the account, whether sufficient credit exists for the amount of payment requested, and other inquiries.
If credit is approved, a response code or other indication of approval may be sent to the merchant processor or merchant in step 308, the account may be settled with the merchant biller in step 310 (i.e., the merchant's bank account is credited for the amount of the payment), and the customer may be notified of a successful transaction in step 312.
If, on the other hand, the payor's credit is not approved in step 306, then the system may convert the payment request to a Direct Deposit Account (DDA) withdrawal in step 314, instead of a payment with credit. This may be the case, for instance, where the customer payor has specified a DDA as a secondary source for payment in step 220. In step 316, the system may verify that the DDA has sufficient funds for the requested payment transaction. If it does, then funds may be transferred from the payor's DDA to the merchant's account to settle with the merchant biller in step 310. Where the payment is made from the secondary DDA, step 312 notification may indicate that payment was made from the secondary account and not, for example, the primary credit card account that the customer payor previously selected. Of course, where it is determined in step 316 that the DDA also has insufficient funds, then the customer may be notified of a failed transaction in step 318.
In other embodiments, the secondary source for payment may be another credit account, a checking account, a brokerage account, or other account types that are not Direct Deposit Accounts.
Middleware platform 402, bank 404, Merchant processor 406, credit card association 408, issuer processor 410, and card issuer 412 may each be a server 100, 110, or 120 as illustrated in
Middleware platform 402 may contain network enabled code to collect information entered in step 220, and may also perform step 300 initial data processing. In the event that credit is not approved in step 306, middleware platform 402 may execute conversion step 314. Additionally, middleware platform 402 may provide notification to customer terminal 402 as defined in notification steps 312 and 318, and as appropriate for the circumstances. The commercial Corillian™ or other service may supply the middleware platform or associated middleware services of functional element 402.
The functions of Bank 404 may include step 302 forwarding data to the merchant processor 406 and other process steps. Bank 404 may also perform step 316, determining the sufficiency of funds in a direct deposit account. In an alternative embodiment, the functional node of Bank 404 may be eliminated, in which case middleware platform 402 may communicate directly with merchant processor 406. It may be advantageous for developers of a system embodying the invention to retain Bank 404 as a component of the functional architecture as depicted in
Merchant processor 404 may initiate the request for authorization step 304. This request may be forwarded to credit card association 408, issuer processor 410, and card issuer 412 as shown in
Credit card association 408 may be, for example, the VISA/MasterCard™, American Express™, or other payment network or interchange. Issuer processor 410 may be or include services, application software, or processors provided by, for example, First Data Corporation, Inc. (FDR), Total Systems Services, Inc. (Total), Electronic Data Systems, Inc. (EDS), or other providers. Card issuer 412 may be First USA, Citibank, or another financial institution that issued a credit card, opened a revolving credit account, or otherwise extended credit to the customer payor.
If the transaction is approved, card issuer 412 may initiate the step 308 approval message, which may be forwarded through the issuer processor 410 and credit card association 408 on its way to merchant processor 406. The actual settlement in step 310 may follow a path identical to that of request for authorization step 304 and approval step 306, except that settlement step 310 may also require that data be passed from merchant processor 406 to merchant biller 414. The execution of settlement step 310 just described is illustrated in
Claims
1-62. (canceled)
63. A method for enabling a payor to make one or more online payments to one or more payees using a payment system which enables the payor to make bill payments using a credit card account, of the payor, to payees who do not accept credit card payments, the method comprising:
- providing the payor with access to an online payment system operated by a payment administrator, the online payment system operative to process payment to a payee regardless of whether the payee has agreed to use said online payment system;
- displaying to the payor, by way of a user terminal, a bill owed to the payee who does not accept credit card payments for the bill;
- receiving a bill payment instruction from the terminal, the bill payment instruction comprising information to identify a credit card account of the payor;
- charging the credit card account of the payor an amount corresponding to the bill owed to the payee;
- causing a payment to be made from the payment administrator to the payee by a payment mechanism not using the credit card account of the payor,
- thereby allowing the payee to receive a non-credit card payment for the bill while the payor is charged against the payor's credit card account.
64. The method of claim 63, wherein the online payment system is operative to pay a payee without an electronic interface to the payee.
65. The method of claim 63, wherein causing the payment to be made comprises at least one of: electronic funds transfer into an account of the payee, and printing a paper check and causing the paper check to be delivered to an address of the payee by the online payment system.
66. The method of claim 63, wherein receiving the bill payment instruction comprises receiving identification of at least one secondary account to be used in the event that a payment transaction cannot be completed from the credit card account.
67. The method of claim 63, wherein incentives are credited based on use of the credit card account in connection with the payment.
68. The method of claim 63 wherein the payment administrator comprises the financial institution that issued the credit card account.
69. The method of claim 63, wherein the payor is provided with access to the online payment system via a browser-equipped device.
70. The method of claim 63, wherein the payment comprises a payment scheduled by the payor for a future date.
71. The method of claim 63, wherein the bill payment instruction comprises an instruction for a recurring payment.
72. A method for a payor to make one or more online payments using an online payment system which enables the payor to make bill payments using, a credit card account, to payees who accept credit cards as well as to payees who do not accept credit cards, the method comprising:
- providing the payor with access to the online payment system operated by a payment administrator, the online payment system operative to process payment to a payee regardless of whether the payee has agreed to receive payment through said online payment system, wherein the online payment system is operative to pay the payee without an electronic interface to the payee;
- presenting to the payor a payment mode of operation for payment of a bill owed the payee that does not accept payment by credit card, the payment mode comprising: identifying the bill due to the payee, the payee being one that does not accept payment from credit card accounts, the identifying comprising at least one of: (a) presenting to the payor, by way of a user terminal, the bill owed to the payee, and (b) receiving from the payor, by way of the user terminal, information to identify an amount owed to the payee, the bill not being presented to the payor by way of the user terminal;
- receiving a bill payment instruction, the bill payment instruction comprising information to identify a credit card account of the payor;
- causing a payment to be made from the payment administrator to the payee by a payment mechanism not using the credit card account; and
- charging the credit card account of the payor for the payment.
73. The method of claim 72, wherein the online payment system is further operative to receive and process online payment instructions for both bills received online and bills received off-line.
74. The method of claim 72, wherein the payment administrator that operates the online payment system comprises the financial institution that issued the credit card account.
75. The method of claim 72, wherein receiving the bill payment instruction comprises receiving identification of at least one secondary account to be used in the event that the payment cannot be completed from the credit card account.
76. The method of claim 75, wherein the at least one secondary account comprises a non-credit card account.
77. The method of claim 72, wherein incentives are credited based on use of the credit card account in connection with the payment.
78. The method of claim 72 wherein the payment mechanism comprises electronically transferring funds into a payee account owned by the payee.
79. A system for a payor to make a payment to a payee who does not accept credit cards, the system comprising a memory for storing instructions and a processor for executing the instructions, which instructions when executed cause the processor to:
- provide the payor with access to an online payment interface operated by a payment administrator, the online payment interface operative to process payment to the payee regardless of whether the payee has agreed to receive payment through said online payment interface;
- present to the payor a bill owed to the payee;
- receive a bill payment data set comprising information to identify a credit card account of the payor;
- request authorization for a credit card transaction on said credit card account;
- cause a payment to be made from the payment administrator to the payee from the credit card account of the payor; and
- charge the credit card account an amount corresponding to the payment.
80. The system of claim 79, wherein the online payment system is operative to pay the payee without an electronic interface to the payee.
81. The system of claim 79, wherein the payment administrator comprises the financial institution that issued the credit card account.
82. The system of claim 79, wherein the payment mechanism comprises electronically transferring funds into a payee account owned by the payee.
83. The system of claim 79, wherein the online payment interface is accessed via a browser-equipped device.
84. The system of claim 79, wherein the payment comprises a payment scheduled by the payor for a future date.
85. The system of claim 79, wherein the payment instruction comprises an instruction for a recurring payment.
Type: Application
Filed: Jul 1, 2014
Publication Date: Oct 23, 2014
Inventors: Karen Lavern Brown (Bear, DE), Lisa Kim Manarky (Wilmington, DE)
Application Number: 14/321,145
International Classification: G06Q 20/10 (20060101); G06Q 20/34 (20060101); G06Q 20/24 (20060101);