BACKGROUND1. Field of the Invention
The present disclosure relates generally to financial transactions and more particularly to a universal funding card and the delayed assignment of a funding instrument for a financial transaction.
2. Related Art
In many instances, customers shopping for products and/or services directly from a merchant will typically fund the face-to-face purchases of those goods and services with a funding instrument such as a credit or debit card (cash or check). Customers will typically carry any number of credit cards to satisfy a variety of accounting purposes including one or more cards for business related purchases and one or more cards for personal related purchases. Accordingly, in addition to being cumbersome and inconvenient, carrying or being in possession of many cards at one time substantially increases the risk of the card being lost or stolen. There is also the possibility that some forms of payment are not accepted by the merchant (e.g. American Express, personal checks, etc). Furthermore, having to make an on-the-spot decision as to which card to use for which purchase may be confusing and pose a financial risk for many individuals. In this regard, many credit cards include joint accounts that may be accessed and utilized by two or more individuals. As such, accurate knowledge of associated balances for one or more cards at any given time may be difficult if not impossible.
Likewise, customers may search for and purchase products and/or services through electronic communications with online merchants over electronic networks such as the Internet. During the course of these transactions, customers may provide payment for items in various ways including, for example, credit cards, electronic fund transfers, and other payment schemes offered by service providers. Similar to their direct purchase counterparts, online customers may encounter confusion, indecision, and financial risk as they must decide at the time of purchase which funding instrument to use for each purchase and whether or not the funding instrument is sufficiently funded to avoid overdraft and other penalties.
Accordingly, there exists a need for a universal funding card and the delayed assignment of a funding instrument for a financial transaction.
SUMMARYFor purposes of summarizing the disclosure, exemplary embodiments for a universal funding card and the delayed assignment of a funding instrument for a financial transaction have been described herein.
In one embodiment, a system for facilitating a financial transaction comprises a communications interface; a database storing data regarding a user and a plurality of funding instruments associated with that user; and a payment processing system configured to receive a request for payment authorization from a merchant via the communications interface, to authorize payment to the merchant prior to selection of a funding instrument, and after authorizing payment to the merchant, receive instructions regarding a funding instrument to debit for the payment.
In another embodiment, a network payment processing system configured to receive a purchase request for one or more items, authorize the immediate purchase of the one or more items, and permit the delayed assignment of a funding instrument at the time of purchase for the one or more items is disclosed.
In still another embodiment, a method for facilitating a financial transaction comprises receiving a purchase request; processing the purchase request; and authorizing the purchase of the one or more items prior to the assignment of a funding instrument for the payment of the one or more items.
These and other embodiments will become readily apparent to those skilled in the art form the following detailed description of the various embodiments having reference to the attached figures, the invention not being limited to any particular preferred embodiment(s) disclosed.
BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 shows a block diagram of a known networked system configured to facilitate online transactions with a funding instrument.
FIG. 2 shows a block diagram of a universal funding card method for a financial transaction in the networked system ofFIG. 1 in accordance with one embodiment.
FIG. 3 shows a block diagram of a delay assignment of a funding instrument method in a financial transaction in the network system ofFIG. 1 in accordance with one embodiment.
FIG. 4 shows a method for a delayed assignment of a funding instrument in a financial transaction with reference to a client in accordance with one embodiment.
FIG. 5 shows a method for a delayed assignment of a funding instrument in a financial transaction with reference to a payment provider in accordance with one embodiment.
Embodiments of the invention are understood by referring to the detailed description that follows. It should be appreciated that like reference numerals are used to identify like elements illustrated in one or more of the figures, wherein showings therein are for purposes of illustrating embodiments of the invention and not for purposes of limiting the same.
DETAILED DESCRIPTIONExemplary embodiments will now be described with references to the accompanying figures, wherein like reference numbers refer to like elements throughout. The terminology used in the description presented herein is not intended to be interpreted in any limited or restrictive manner simply because it is being utilized in conjunction with a detailed description of certain embodiments. Furthermore, various embodiments (whether or not specifically described herein) may include novel features, no single one of which is solely responsible for its desirable.
Embodiments of the present disclosure enable users to overcome the inconvenience, confusion, indecision, and financial risk typically associated with the possession and/or use of multiple funding instruments for the real-time purchase of products and/or services by providing a universal funding card and the delayed assignment of a funding instrument for a financial transaction.
Embodiments of the present disclosure are described herein as they relate to a financial transaction as it may occur in an electronic payment system environment. An electronic payment system is generally considered as any kind of network service that includes the exchange of money for goods or services. Such network payment system includes, for example, a credit and/or debit card processing system. For convenience, simplicity, and efficiency the present disclosure is described relative to and online or web-based transaction. However, persons of ordinary skill in the art will understand that the teachings of the present disclosure apply equally to financial transactions that occur directly between a buyer and a merchant such as in a face-to-face transaction that may occur in department store or similar type business environment.
In one embodiment, the network may be implemented as a single network or a combination of multiple networks. For example, in various embodiments, the network may include the Internet and/one or more intranets, landline networks, wireless networks, and/or other appropriate types of communication networks. In other example, the network may comprise a wireless telecommunications network (e.g., cellular phone network) adapted to communicate with other communication networks, such as the Internet.
In one known scheme, as generally shown inFIG. 1, besides a client system5 (also referred to as a “user” system herein), amerchant system10, and a merchant providedwebsite15 for the sale of goods and/or services, the flow of information and money between the parties in acredit card system20 occurring along anetwork25 such as the Internet, generally includes several intermediaries involved in a typical credit card transaction.
Generally, in thecredit card system20, a customer2 (also referred to as a “user”, “buyer”, “client”, or “cardholder” herein) is issuedcredit30 after an account has been approved by a credit provider orissuer35 such as a financial institution or other organization. Thecredit provider35 registers thecardholder2, issues a credit card(s), and operates a card account to which payments can be charged. Thecardholder2 is able to make purchases with the credit card for products and/or services from a merchant accepting that credit card up to a pre-established credit limit.
By one definition, credit card interchange is the process by which all parties involved in a credit card transaction manage the processing, clearing and settlement of credit card transactions, including the assessment, and collection and/or distribution of fees between parties.
In this regard, thecardholder2 chooses one ofmultiple funding instruments40, such as a credit card, to pay for the purchase and the merchant submits the transaction forauthorization45. The issuing bank orcredit provider35 has up-to-date information on the customer's account status. However, as there are many banks that issue credit cards, it would be inconvenient if each merchant had to figure out which bank issued the card and contact the bank for credit card verification. Accordingly, a financial institution or other organization (acquirer)50 acting as a payment provider, processor, or gateway may provide card services to the merchant. In this regard, to process credit cards in real-time, merchants establish a connection from theirwebsite15 to thepayment processing system50. Gateway connections may be made by developing in-house solutions, or by contracting with an outsourcedpayment processing system50 having an application programming interface (API) for card verification and processing service to themerchant10. The APIs are generally HTTP or TCP/IP based and provide a relatively simple interface to communicate with the merchant's application software.
In this regard, apayment processing system50 such the system provided by PayPal Inc. of San Jose, Calif., USA may act as the payment provider gateway between the buyer and seller (merchant) to provide payment processing for online transactions on behalf of the buyer so that the buyer never has to expose his payment information directly to the seller. Instead the buyer registers his credit card or bank account with thepayment processing system50, maps the account to an email address, and then uses thepayment processing system50 to make purchases when redirected60 to thepayment processing system50 from the merchant'ssite15. Upon completion of the purchase the buyer is directed back to the merchant'ssite15 to an order confirmation page
In this regard, thepayment processing system50 may include one ormore payment applications56 and user and/or merchant accounts57, which may be configured to interact with theclient system5 and/or each of themerchant servers10 over thenetwork25 to facilitate the purchase of items, products and/or services by theuser2 from themerchant server10.
Thepayment processing system50 receives the credit card data, validates65 the card, and communicates with the credit provider'ssystem35 to verify the amount for the transaction is available in the customer's account70. If the card is good and the funds are available, thepayment processing system50 sends an approved message back to the merchant. If the card is bad or if funds are not available, thepayment processing system50 sends a declined message back to the merchant. After the transaction is authorized45 it is then stored in a batch, which the merchant sends to thepayment processing system50 later to receive payment.
As transactions (payments and credits) arrive at thepayment processing system50, they are batched75 through to the appropriate clearinghouse orcard association80. In this case, thecustomer2 may get a message from thewebsite15 stating their order was received and will be processed. Later, thesystem20 might send thecustomer2 an e-mail with notification of a successful card authorization (or failure). As theclearinghouse80 receives transactions from all the gateways, the clearinghouse batch the transactions for all the banks involved, debitingmonies85 from the customer's bank (credit provider)35 and crediting90 the merchant'sbank95.
Theissuer35 charges the cardholder's account70 at regular intervals and notifies thecardholder2 of the transactions and accumulated charges. Thecardholder2 pays30 the corresponding charges to theissuer35.
Persons of ordinary skill in the art will understand that although each of the tasks in the credit card interchange may be performed by a different entity, one or more of the tasks may be done by a single entity. For example, the task of issuing credit may be done by a credit provider, while the tasks of establishing and maintaining a merchant's account, authorization, and clearing and settlement may all be done by a full-service third-party processing company or commerce service provider (CSP).
As indicated above, unfortunately, when making real-time point of sale purchases consumers are often forced to make hasty decisions regard which card and account type to use to make the purchase. Furthermore, it is often difficult or inconvenient for customers to determine whether sufficient funds are available to make a certain purchases while visiting a merchant'swebsite15. For example, it is typically incumbent on customers to access their personal financial records, or visit a separate financial website in order to ascertain the current account balance associated with a desired method of payment. These additional steps can detract from the customer's online experiences and inconvenience consumers when malting online purchases. In addition, the inability to ascertain whether sufficient funds are available may result in overdraft or other associated fees for purchases made when funds are unavailable at the time of purchase.
For merchants, such inconveniences can translate into potential lost sales to the extent that otherwise willing customers are deterred from completing online transactions. In particular, if customers are forced to visit other websites or retrieve locally-stored records before engaging in online transactions, customers may become distracted or attracted to a merchant's competitors while taking such actions.
The present disclosure addresses, among other things, the problem of having to decide at the time of purchase which funding instrument(s) to use to make a particular purchase by providing a universal funding card and the complete or partial delayed assignment of a funding instrument(s) for a financial transaction.
A block diagram of a universal funding card method for a financial transaction in the networked system ofFIG. 1 in accordance with one embodiment is shown inFIG. 2. Other than the use of a universal funding card to make real-time purchases, delayed assignment of a funding instrument for a financial transaction, eventual assignment of the funding instrument, and debiting of the assigned funding instrument based on the assignment, the interchange process described above in regard to the use of a credit card including authorization, batching, clearing and settlement, and funding generally remains the same.
In one embodiment, theclient system5 may include one ormore browser applications6 which may be used, for example, to provide a user interface to permit theuser2 to browse information available over thenetwork25. For example, thebrowser application6 may be implemented as a web browser to view information available over the Internet.
Theclient system5 may include one ormore toolbar applications7, which may be used, for example, to provide client-side processing for performing tasks in response to operations selected by theuser2. For example, thetoolbar application7 may display a graphical user interface (GUI) in connection with thebrowser application6.
Theclient system5 may further include aservice application8 for facilitating financial transactions on thenetwork25 andother applications9 to provide additional features to theuser2. In one implementation, theservice application8 comprises a software program, such as a graphical user interface (GUI), executable by a processor that is configured to interface and communicate with the one ormore merchant servers10 and thepayment processing system50 via thenetwork25. Theuser2 is able to accessmerchant websites15 viamerchant servers10 to view and select items for purchase, and theuser2 is able to purchase selected items from merchants by communicating with thepayment processing system50.
When installed and executed by theclient system5, theservice application8 may be configured to provide and display a payment mechanism, such as an image or icon, on the display component (e.g., monitor) of theclient system5.
In one embodiment, the one ormore merchant servers10 may be maintained, for example, by one or more merchants offering one or more items, such as products and/or services, in exchange for financial payment to be received from users, such as theuser2 or from thepayment processing system50 acting on behalf of theuser2, over thenetwork25. In this regard, each of the one ormore merchant servers10 may include adatabase16 for identifying available products and/or services, which may be made available to theclient system5 for viewing and purchase by theuser2. Accordingly, each of themerchant servers10 may include amarketplace application17, which may be configured to provide information over thenetwork25 to thebrowser application6 of theclient system5. For example, theuser2 may interact with themarketplace application17 through thebrowser application6 over thenetwork25 to search and view various items, products and/or services identified in thedatabase6.
Each of the one ormore merchant servers10 may include acheckout application18, which may be configured to facilitate online purchase transactions by theuser2 of products and/or services identified by themarketplace application17. In this regard, thecheckout application18 may be configured to accept payment information from theuser2 and/or frompayment processing system50 over thenetwork25.
The one ormore merchant servers10 may include one ormore merchant identifiers19, which may be included as part of the one or more items made available for purchase so that particular items are associated with a particular merchant. Themerchant identifier19 may include attributes related to the merchant, such as business and banking information. In various implementations, themerchant identifier19 may be passed with a user purchase request to thepayment processing system50 when theuser2 selects an item for purchase, and themerchant identifier19 may be used by thepayment processing system50 to associate a particular item purchased with aparticular merchant account110 maintained by thepayment processing system50.
In one embodiment, as shown inFIG. 2, auser2 is issued a universal funding card (UFC)100 that is used to complete a product and/or service purchase. Upon selection of a product and/or service the UFC100 is swiped at a point-of-sale terminal in a direct financial transaction or the UFC card number is entered at a merchant'swebsite15. In the case of an online transaction, entering the UFC card number at the merchant'swebsite15 redirects the user to thepayment processing system50 where theuser2 is given a choice of complete or partial assignment of afunding instrument105 for the financial transaction at the time of purchase and/or the complete or partial delayed assignment of the funding instrument for the financial transaction until some later date. In either case, the products and/or services are purchased by theuser2 immediately, i.e., in real-time, while the choice of one or more funding instruments for the financial transaction may or may not be delayed.
Funding instruments105 made available to theuser2 are embedded on one or more lines of the magnetic card stripe found on the UFC100.Funding instruments105 for purchase and immediate assignment of the funding instrument for the financial transaction may include, but are not limited to, a bank account, gift certificate, debit account, credit card account, and/or other account such as a designated business or personal account. When one ormore funding instruments105 are assigned at the time of purchase thepayment processing system50 processes the user's assignedfunding instrument105 as generally detailed above in regarding the a credit card interchange. Accordingly, thefunding instrument105 is authorized, and funds are cleared, settled, and distributed to the merchant'saccount110 and debited from the user's account70 (seeFIG. 1).
In one embodiment, by choosing an appropriate icon, for example, a “remind me later” (delayed assignment option) icon, theuser2 may choose to purchase a product and/or service but delayed assignment of afunding instrument105 for a financial transaction until some later date which may be set or established by thepayment processing system50. In this regard, theuser2 may decide at the time of purchase to delay assignment of one ormore funding instruments105 for the payment of the one or more items purchased to some later date. Alternatively, theuser2 may decide to make a partial assignment of one ormore funding instruments105 for the payment of the one or more items and delay assignment of one ormore funding instrument105 for the remaining payment of the one or more items purchased.
Authorization (acceptance or decline) for such a delayed assignment of a funding instrument may be based on such factors as credit worthiness, payment history, cash reserves, etc., and determined by an acceptance logic application. Upon authorization, the products and/or services are purchased by theuser2.
As shown inFIG. 3,data117 relating to each of the financial transactions opted by theuser2 for complete or partial delayed assignment of a financial instrument is communicated from the one ormore merchant servers10 to thepayment processing system50 where thedata117 may be stored in apurchase database120.Such data117, which may be contained in themerchant identifier19, may include identification of the product and/or service purchased, cost or amount owed, and merchant information.
At regular intervals, perhaps monthly, a financial transaction orpurchase statement125 indicated the data of each financial transaction(s) in which delayed assignment of a financial instrument was chosen during the purchase of a product and/or service may be communicated130 to theuser2.
Upon receipt of theperiodic purchase statement125 theuser2 is able to review finances, account information including balances, as well as make appropriate funding deposits, withdrawals, and/or transfers to various accounts prior to assigning one ormore funding instruments105 to each of the financial transaction(s) contained in thepurchase statement125. Of course, the user102 may also make a deposits, withdrawal, and payments to one or more of the funding instrument accounts at anytime prior to receivingpurchase statement125. In this manner, theuser2 is better able to evaluate and decide on whichfunding instrument105 to assign for each financial transaction to better manage business and personal finances, as well as potentially avoiding overdraft and other penalties when compared to the immediate real-time assignment of a funding instrument for a financial transaction.
Theuser2 then communicates135 back to thepayment processing system50 the desired assignment of the one ormore funding instruments105 for each financial transaction in which the complete or partial delay assignment of the funding instrument was chosen. Thepayment processing system50 then debits the corresponding funding instrument account accordingly, and communicates140 to theuser2 information regarding financial activities for each funding instrument account insubsequent account statements145 or in a singleaccounts summary statement150.
Accordingly, in one embodiment, funds for purchase of the selected products and/or services in the delayed assignment of a funding instrument are distributed immediately to the merchant'saccount110 from an account maintained by thepayment processing system50. Accounting of such distributions are tracked by thepayment processing system50 until the user102 assigns a funding instrument, at which time, funds are debited from the designated funding instrument account of the user102 and distributed into the account maintained by thepayment processing system50.
In another embodiment, an initial default funding instrument may be assigned by user102 so that funds for a particular purchase may be distributed to the merchant within a reasonable time. In this regard, the user102 may do nothing and funds from the initial default account would be withdrawn as required and paid to the merchant within a predetermined time limit. Alternatively, if, within the predetermined time limit the user102 wanted to reassign the purchase to another funding instrument, the user102 may do so and the funds for the purchase would be debited from the alternative funding account and distributed to the merchant.
FIG. 4, shows amethod400 for a delayed assignment of a funding instrument in a financial transaction with reference to a user in accordance with one embodiment.
As previously discussed, theservice application8 allows theclient device5 to communicate with one or more of themerchant servers15 via thenetwork25 to select items for purchase and further communicate with thepayment processing system50 to process online purchase requests and/or transactions for items selected for purchase.
In one embodiment, upon user instruction, theservice application8 may be installed and/or run on the client system5 (block405) to access at least onemerchant website15 via a related merchant server15 (block410) to search the accessedmerchant website15 and view one or more items for purchase (block415). In one embodiment, upon installation, theuser2 may be prompted to establish a user account57 with thepayment processing system50, wherein theuser2 may use theclient system5 to access thepayment processing system50 via thenetwork25. When establishing a user account57, theuser2 may be asked to provide personal information, such as name, address, phone number, etc., and financial information, such as banking information, credit card information, etc.
Next, theuser2 may generate a purchase request for at least one item by selecting the at least one item (block420) from the merchant'ssite15. Methods of item selection (product and/or service) and communication of the purchase request including user information, merchant information, and selected item information to thepayment processing system50 for payment processing is generally well-known in the art. It should be appreciated by those skilled in the art that more than one item may be selected for purchase prior to completing the online purchase transaction as well as deciding whether to assign a single funding instrument or multiple funding instruments at the time of purchase or delaying complete or partial assignment of the one or more funding instruments. For example, a plurality of items may be selected and placed in a virtual shopping cart and then purchased in a single online purchase transaction.
At this point, theuser2 is given a choice of assigning afunding instrument105 at the time of purchase or delaying the assignment of the funding instrument (block425). In other words, even though the items are purchased in real-time, the user may decide to delay assignment of a funding instrument of the financial transaction. As explained below, even though one or more items may have been purchased in a single financial transaction, the subsequent assignment of funding instrument may include multiple funding instruments including one or more funding instruments for each item purchased.
In either case of assigning a funding instrument or delaying assignment of the funding instrument, theuser2 may provide user identification or at least verify the user identification for a related user account57 stored inpayment processing system50 so that authorization (acceptance or decline) for the financial transaction by thepayment processing system50 can be completed. Once proper user identification is provided and/or verified, the online purchase transaction may be completed (blocks430 and440).
As indicated above, at regular intervals, perhaps monthly, a financial transaction orpurchase statement125 indicated the data of each financial transaction(s) in which complete or partial delayed assignment of a financial instrument was chosen during the purchase of a product and/or service is received by the user2 (block450). Theuser2 then transmits, communicates, or otherwise sends back to thepayment processing system50 the desired assignment of the one ormore funding instruments105 for each of the one or more items purchased in each of the one or more financial transaction in which the complete or partial delay assignment of the funding instrument (block460) was indicated.
FIG. 5 shows amethod500 for a delayed assignment of a funding instrument in a financial transaction with reference to a payment processing system in accordance with one embodiment. As shown inFIG. 5, thepayment processing system50 receives a purchase request from theuser2 via the client system5 (block505). As previously discussed in reference toFIG. 4, theuser2 will typically begin an online transaction by selecting an item for purchase which initiates the user purchase request with thepayment processing system50.
Upon receiving the user purchase request (block505), thepayment processing system50 may determine whether theuser2 is an existing user having an established user account57 by, for example, checking a user account list in a user account database (block510). If theuser2 does not have an established user account, then thepayment processing system50 may prompt theuser2 to establish a user account57 by providing user information (block520), and thepayment processing system50 uploads theservice application8 to theclient system5 so that theuser2 may install and run theservice application8 on client system5 (block530). Once theservice application8 is installed and run on theclient device5, thepayment processing system50 processes the purchase information provided in the user purchase request (block550).
Otherwise, if theuser2 is determined to be an existing user by the payment processing system (block510), then thepayment processing system50 verifies the user account and user identification information provided byuser2 in the user purchase request (block515). For example, as previously discussed, theuser2 may be prompted to provide user identification to purchase any selected items and complete the online transaction. Next, thepayment processing system50 may determine if the user account is current and active (block540). In some instances, a user's account information may need to be updated, and thus, thepayment processing system50 may prompt theuser2 to update user account information in the user account57 for the user2 (block560). If the user account57 is current and active, then thepayment processing system50 processes the purchase information in the user purchase request (block550). It should be appreciated by those skilled in the art that thepayment processing system50 may cancel the online purchase transaction at any point in the process if it is determined, for example, that theuser2 enters wrong information.
The purchase information may include information related to the item selected for purchase, information related to the merchant providing the item selected for purchase, information related to the user including user account number, balance information, credit card information, etc. In one implementation, thepayment processing system50 may optionally access themerchant site15 via themerchant server10 to verify purchase information including verifying that the selected item is available (e.g., in stock), verifying the pricing information, verifying that the merchant account is up-to-date, etc.
Thepayment processing system50 then determines if theuser2 has assigned afunding instrument105 or chosen complete or partial delayed assignment of the funding instrument (block570). In either case, authorization (acceptance or decline) for the financial transaction by thepayment processing system50 may be completed by verifying user information and account57 details stored in thepayment processing system50. Once proper user identification is provided and/or verified, the online purchase transaction may be completed (blocks580 and590). In one example embodiment, completing the purchase request may include redirecting theuser2 to a page on themerchant site15 that confirms their purchase of the selected product to provide, for example, a receipt to theuser2.
Data117 relating to each of the financial transaction(s) chosen for delayed assignment of afunding instrument105 is stored in a purchase database120 (block595).Such data117, which may be contained in themerchant identifier19, may include identification of the product and/or service purchased, cost or amount owed, and merchant information.
At regular intervals, perhaps monthly, a financial transaction orpurchase statement125 indicated thedata117 of each financial transaction(s) in which delayed assignment of a financial instrument was chosen during the purchase of a product and/or service may be communicated130 to the user2 (block596).
Thepayment processing system50 receives back from theuser2 the assignment of the one ormore funding instruments105 for each item of each financial transaction in which the delay assignment of the funding instrument was chosen (block597). Thepayment processing system50 then debits and/or credits the corresponding funding instrument account(s), and communicates140 to theuser2 information regarding financial activities for each funding instrument account incorresponding account statements145 or in a single accounts summary statement150 (block599).
Although the method(s)/step(s) are illustrated and described herein as occurring in a certain order, the specific order, or any combination or interpretation of the order, is not required. Obvious modifications will make themselves apparent to those of ordinary skill in the art, all of which will not depart from the essence of disclosed subject matter, and all such changes and modifications are intended to be encompassed within the appended claims.