SYSTEMS AND METHODS FOR PEER-TO-PEER FUNDS REQUESTS

Abstract

A method of facilitating a payment to a merchant is described. The method includes receiving, by a computing system from a first user device, a request to fund a purchase of a first user from the merchant with funds from a second user; transmitting, by the computing system, a message including the request to fund the purchase of the first user to a second user device associated with the second user; transmitting, by the computing system, updated payment information to the first user device, the updated payment information including a payment code; receiving, by the computing system, a transaction request from the merchant, the transaction request including the payment code; and transmitting, by the computing system, an approval message to the merchant.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

The present Application is a continuation of, and claims priority to, U.S. patent application Ser. No. 14/637,603, filed Mar. 4, 2015, which is incorporated herein by reference in its entirety and for all purposes.

BACKGROUND

Consumers complete purchases of goods and services from merchants through various currency transfers. The consumers may provide payment to the merchants via cash, checks, credit cards, debit cards, automated clearing house (“ACH”) transfers, internet payments, mobile wallets, and the like. A financial institution processing a payment from a customer to a merchant may reject the payment if the consumer does not have enough funds to complete the transaction. For example, if a consumer has exhausted his credit limit on his credit card, the credit card processor may deny the transaction request on account of lack of funds or credit. In such situations, the consumer may try another form of payment or leave without acquiring the goods or services from the merchant. However, often if a first a form of payment is unavailable due to lack of funds, other forms of payment are also unavailable due to lack of funds.

SUMMARY

One embodiment relates to a method a method of facilitating a payment to a merchant via a mobile wallet system provided by a financial institution computing system of a financial institution. The method includes receiving, by a processor of the financial institution computing system from a first user device, a request to fund a purchase of a first user from the merchant with funds from a second user via the mobile wallet system. The method further includes transmitting, by the processor, a message including the request to fund the purchase of the first user to a second user device associated with the second user. The method further includes transmitting, by the processor, updated payment information to the first user device, the updated payment information including a payment code. The method includes receiving, by the processor, a transaction request from a point of sale system associated with the merchant, the transaction request including the payment code. The method further includes transmitting, by the processor, an approval message to the point of sale system.

Another embodiment relates to a financial institution computing system associated with a financial institution. The system includes a network interface configured to communicate with a plurality of user devices and a merchant point of sale system associated with a merchant via a network. The system further includes an account database storing information relating to a plurality of financial accounts maintained by the financial institution. The system includes a memory and at least one processor. The at least one processor is configured to receive, from a first user device, a request to fund a purchase of a first user from the merchant with funds from a second user via a mobile wallet system maintained by the financial institution computing system. The at least one processor is further configured to transmit a message including the request to fund the purchase of the first user to a second user device associated with the second user. The at least one processor is configured to transmit updated payment information to the first user device, the updated payment information including a payment code. The at least one processor is further configured to receive a transaction request from the point of sale system, the transaction request including the payment code. The at least one processor is configured to transmit an approval message to the point of sale system.

A further embodiment relates to a method of preauthorizing purchase funding via a mobile wallet system provided by a financial institution computing system of a financial institution. The method includes receiving, by a processor of the financial institution computing system from a first user device, auto-fund permissions relating to a preauthorization for the financial institution to fund purchases of a second user of the mobile wallet system, wherein the auto-fund permissions include an identity of a second user and transaction restrictions. The method further includes receiving, by the processor, a request to fund a transaction at a merchant from an account associated with the first user, wherein the request is received from a point of sale system of the merchant. The method includes determining, by the processor, that the transaction at the merchant is within the permissions set forth in the transaction restrictions received from the first user. The method further includes transmitting, by the processor, an approval message to the point of sale system.

Another embodiment relates to a financial institution computing system associated with a financial institution. The system includes a network interface configured to communicate with a plurality of user devices and a merchant point of sale system associated with a merchant via a network. The system further includes an account database storing information relating to a plurality of financial accounts maintained by the financial institution. The system includes a memory and at least one processor. The at least one processor is configured to receive, from a first user device, auto-fund permissions relating to a preauthorization for the financial institution to fund purchases of a second user of the mobile wallet system, wherein the auto-fund permissions include an identity of a second user and transaction restrictions. The at least one processor is further configured to receive a request to fund a transaction at a merchant from an account associated with the first user, wherein the request is received from a point of sale system of the merchant. The at least one processor is configured to determine that the transaction at the merchant is within the permissions set forth in the transaction restrictions received from the first user. The at least one processor is further configured to transmit an approval message to the point of sale system.

These and other features, together with the organization and manner of operation thereof, will become apparent from the following detailed description when taken in conjunction with the accompanying drawings, wherein like elements have like numerals throughout the several drawings described below.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a diagram of a computing system according to an exemplary embodiment.

FIG. 2 is a flow diagram of a method 200 of facilitating third-party payment for a transaction that was previously denied for lack of funds via a mobile wallet system according to an exemplary embodiment.

FIG. 3 is an exemplary user interface of a mobile wallet client as presented on the display of a mobile device of FIG. 1 according to an exemplary embodiment.

FIG. 4 is another exemplary user interface of a mobile wallet client as presented on the display of a mobile device of FIG. 1 according to an exemplary embodiment.

FIG. 5 is another exemplary user interface of a mobile wallet client as presented on the display of a mobile device of FIG. 1 according to an exemplary embodiment.

FIG. 6 is a flow diagram of a method of automatically funding transactions of a user from a third-party's account according to an exemplary embodiment.

DETAILED DESCRIPTION

Referring generally to the figures, a financial institution computing system of a financial institution that provides a mobile wallet system to users is described. The mobile wallet system enables the users to provide payments to merchants via the mobile wallet system. Users' mobile wallets are linked to payment forms associated with the users (e.g., bank accounts, credit cards, gift cards, etc.). To pay for a good or service provided by a merchant, a user selects a form of payment and provides a code to the merchant, which is used by a merchant computing system to initiate payment from the user to the merchant via the financial institution computing system. The code may be a barcode, a two-dimensional barcode, a quick response (“QR”) code, or another code displayed on a mobile device (e.g., a smartphone) of the user such that the code is scannable by a merchant's point of sale (“POS”) system or identifiable by an employee of the merchant. In an alternative arrangement, the code may be wireless transmitted to the merchant POS system from the user's mobile device (e.g., via Bluetooth®, near field communication, radio frequency identification, 802.11 wireless networking, ZigBee®, etc.). Additionally, the mobile wallet system allows a first user to contact a second user of the mobile wallet system to request funding for certain transactions.

Referring to FIG. 1, a diagram of a computing system 100 is shown according to an exemplary embodiment. The computing system 100 includes a financial institution computing system 102. The financial institution computing system 102 is associated with a financial institution, such as a bank. The financial institution provides users 104 (e.g., account holders, mobile wallet users, etc.) a mobile wallet system. As described in further detail below, the mobile wallet system allows the users 104 to use their mobile devices 106 to provide payment for goods and services offered by a merchant 108.

When a user 104 wishes to purchase a good or service from the merchant, the user 104 can request a payment code from the mobile wallet system to provide to a merchant POS system 112. Accordingly, the user 104 interacts with a mobile wallet client 110 on the user's mobile device 106, which requests a payment code from the financial institution computing system 102 via a network 114 based on a user-selected payment source. The network 114 may be the Internet. The financial institution computing system 102 returns a payment code. The payment code may be a barcode, a two-dimensional barcode, a quick response (“QR”) code, or another code that is displayed on a display of the mobile device 106. The code is input into the POS system 112 (e.g., by scanning of the barcode or QR code, by manual entry of the code by an employee into the POS system 112, wireless transmission of the code from the mobile device to the POS system 112, etc.), where the code is sent, along with transaction information (e.g., amount of the transaction, retailer identification information, etc.), to the financial institution computing system 102 via the network 114. Based on the transaction information and the received code, the financial institution 102 determines whether to permit the transaction, and thus the funds transfer from the user 104 to the merchant 108, or to reject the transaction (e.g., due to lack of funds in the user's account or due to the transaction being non-permitted). The financial institution computing system 102 then returns either a transaction confirmation or denial to the POS system 112 to provide an indication to the merchant 108 as to the approval status of the funds transfer.

Still referring to FIG. 1, the financial institution computing system 102 includes a processor 116 and memory 118. In some arrangements, the financial institution computing system 102 includes a plurality of processors. The memory 118 stores programming modules that, when executed by the processor 116, control the operation of the financial institution computing system 102. The programming modules include mobile wallet transaction logic that allows the financial institution computing system 102 to provide the mobile wallet system to users 104 and to the merchant 108. The financial institution computing system 102 includes a network interface 120 that allows the financial institution computing system 102 to communicate data to and from other devices (e.g., mobile device 106, the merchant POS system 112, etc.) via the network 114. The financial institution computing system 102 maintains various information related to customer accounts in an account database 122. In some arrangements, the account database 122 is split into multiple account databases. The account database 122 is where the financial institution computing system 102 stores information relating to financial accounts held with the financial institution, including account balance information and account ownership information. The financial institution computing system 102 further includes a mobile wallet profiles database 124. The mobile wallets profiles database 124 maintains a database of mobile wallet users 104 and associations of the mobile wallet users 104 with various accounts in the account databases 122 (e.g., linking a user's mobile wallet to the user's checking account with the financial institution). Further, the mobile wallet profiles database 124 stores other information concerning the users' mobile wallets, such as contacts lists, user repayment plans, purchase restrictions, and the like.

The mobile device 106 may be used by an individual user (e.g., a business owner or employee, a consumer, and so on) to create and interact with a mobile wallet account maintained by the financial institution computing system 102. The mobile device 106 may, for example be, handheld computer, a cellular phone, smartphone, mobile handheld wireless e-mail device, a tablet computer, personal digital assistant, portable gaming devices, or another suitable device. The mobile device 106 includes a processor 126 and memory 128. The memory 128 includes programming modules and logic that, when executed by the processor 126, control the operation of the mobile device 106. In some arrangements, the memory 128 includes the mobile wallet client 110. The mobile device 106 includes a network interface 130. The network interface 130 may be a wireless network interface that communicates with a wireless communication protocol (e.g., 802.11a/b/g/n, Bluetooth®, ZigBee®, CDMA, GSM, LTE, WiMax, etc.). The mobile device 106 includes a display 132 and an input 134. In some arrangements, the display 132 and input 134 are integrated in a touchscreen display. The mobile device 106 may receive and display user interfaces including account information, transaction instructions, and so on. In some arrangements, the user interfaces may be used to initiate payments from the user's mobile wallet to merchants 108. In other arrangements, the user interfaces may be used to facilitate a third-party mobile wallet user funding a purchase by the user. As will be appreciated, in addition to or instead of the mobile device 106, users may also be provided with the ability to access the mobile wallet system using another type of computer (e.g., a desktop or laptop computer executing browser software) to perform the operations described herein as being performed by the mobile device 106.

The mobile wallet client 110 includes program logic executable by the processor 126 to implement at least some or all of the functions described herein. As will be appreciated, the level of functionality that resides on the mobile device 106 as opposed to the financial institution computing system 102 may vary depending on the implementation. The mobile wallet client 110 may be a web browser that is configured to receive and display mobile web pages (e.g., web pages prompting the user to provide information to create an account, web pages displaying account balance information and past transactions, and so on) or an application executed by the mobile device 106. The mobile wallet client 110 may also include a code/token generator capable of generating a unique code/token for each transaction. The unique code/token may then be transmitted by the mobile device 106 as part of a transaction to facilitate authentication of the transaction and the user of the mobile device 106. As will be appreciated, the user may also use other devices (e.g., laptop or desktop computer system, not shown) to create and access the mobile wallet accounts.

In FIG. 1, the mobile wallet client 110 is used in connection with the merchant POS system 108 located at various physical store locations. In some arrangements, the merchant POS system 108 is a web server that hosts an internet retailer website. Accordingly, the mobile wallet client 110 may also be used in connection with online transactions via the internet retailer. For example, in another embodiment, merchants 106 may be provided with the ability to have a mobile storefront and profile within the mobile wallet client 110. For example, the merchants 108 may be provided with the ability to display marketing material, provide information, and promote products or discounts. Merchants 108 may also be provided with the ability to sell items directly through their mobile storefront for the account holder to purchase from within the mobile client 110.

The mobile wallet client 110 may include, among other features, transaction logic 136 and account information 138. The transaction logic 136 allows users 104 of the mobile devices 106 to provide funds to the merchants 108 in exchange for goods or services from an account with maintained by the financial institution computing system 102 via the mobile wallet client 110. This process is described in further detail in U.S. patent application Ser. No. 14/501,856, entitled “MOBILE WALLET ACCOUNT ACTIVATION SYSTEMS AND METHODS,” filed on Sep. 30, 2014, and in U.S. patent application Ser. No. 14/501,880, entitled “MOBILE WALLET ACCOUNT PROVISIONING SYSTEMS AND METHODS,” filed on Sep. 30, 2014, both of which are hereby incorporated by reference in their entireties and for all purposes. The account information 136 stores associations between the user 104 and any accounts the users 104 that may be associated with at the financial institution. The account information 136 is periodically updated based on information received from the financial institution computing system 102 (e.g., every minute, every ten minutes, every time the user logs into the mobile wallet client 110, etc.). The account information 138 may also include the user's mobile wallet contact book or listing. The contact book or listing includes information relating to other mobile wallet users associated with the user. For example, John's mobile wallet contact book may include relatives and friends that are also mobile wallet users, such as his mom, his dad, his sister, and the like, as well as friends. The contact book or listing may pull contact information from the financial institution computing system 102 or another contact database stored in the memory 128.

Still referring to FIG. 1, the merchant POS system 112 includes a processor 140 and memory 142. The memory 142 stores programming modules and logic that, when executed by the processor 140, control the operation of the merchant POS system 112. The merchant POS system also includes a network interface 144. The network interface 144 allows the POS system 112 to communicate data to and from the mobile device 106 directly or via the network 114 and to and from the financial institution computing system 102 via the network 114. The memory 142 includes transaction logic that allows the POS system 112 to accept mobile wallet payments from the mobile devices 106. The payments are account t052ransfers from the financial institution into accounts associated with the merchant 108.

Referring to FIG. 2, a flow diagram of a method 200 of facilitating third-party payment for a transaction that was previously denied for lack of funds via a mobile wallet system is shown according to an exemplary embodiment. Generally, method 200 is initiated when a first user attempts to make a purchase from merchant 108 via the mobile wallet client 110 running on the first user's mobile device. The merchant POS system 112 relays payment information from the mobile wallet client 110 (e.g., by scanning a barcode presented on the display 132) to the financial institution computing system 102, however, the financial institution computing system 102 indicates to the POS system 112 returns a transaction rejection because the first user does not have sufficient funds in his account. The POS system 112 then denies the transaction. The first user, via the mobile wallet client 110, is presented the opportunity to contact a third-party (i.e., a second mobile wallet user), such as a relative or friend of the first user, to request funding for the transaction. The second user can then fund the previously denied transaction via the mobile wallet system. Method 200 is performed by the financial institution computing system 102 (e.g., by processor 116 controlling the various components of the financial institution computing system 102). Method 200 is described in further detail below.

Method 200 begins when a transaction request is received at 202. The transaction request is received by the financial institution computing system 102 from the merchant POS system 112 via the network 114. The transaction request indicates that the first user is attempting to pay for a purchase from the merchant 108 via the first user's mobile wallet. Accordingly, the transaction includes information identifying the first user and an identification of a payment source, such as the first user's checking account information or credit card information. Additionally, the transaction request includes information about the purchase. The purchase information includes an identity of the merchant 108 and a cost of the purchase. In some arrangements, the purchase information also includes an identification of the specific items or goods attempted to be purchased by the first user.

The transaction request is denied at 204. When the financial institution computing system 102 receives the transaction request, the financial institution computing system 102 checks the first user's account (e.g., a credit card, a checking account, etc.) for sufficient funds to complete the transaction. The financial institution computing system 102 cross-references the account database 122 to determine whether there are sufficient funds in the first user's account to complete the transaction. If there are sufficient funds, the financial institution computing system 102 transmits an approval message to the POS system 112 and transfers funds from the first user's account to an account associated with the merchant 108. However, in method 200, the first user's account does not have sufficient funds to complete the transaction. Accordingly, the financial institution computing system 102 transmits a transaction denial message to the POS system 112.

Additionally, the financial institution computing system 102 transmits a transaction denial message to the first user's mobile device. For example, FIG. 3 shows an exemplary user interface 300 of the mobile wallet client 110 as presented on the display 132 of the mobile device 106 associated with the first user. The user interface 300 is populated based on information received from the financial institution computing system 102. In some arrangements, the financial institution computing system 102 pushes the user interface 300 to the user device 106. The user interface 300 includes an indication 302 that the transaction was denied for insufficient funds. The indication may include an amount of the transaction and an amount of funds available in the first user's account. The user interface 300 further includes the option for the first user to request funds for the transaction from a second mobile wallet user, such as a contact. Accordingly, the user interface 300 allows the first user to select a second user from a contact list (e.g., via a drop down list 304). The second user is also a registered user of the mobile wallet system. The second user is a person that the first user would like to request funds from in order to proceed with the transaction with the merchant 108. For example, the second user may be the first user's mom. After the first user selects a second user, the first user has the option to send a note to the second user along with the request to fund by interacting with the note field 306 of the user interface 300. For example, the first user may indicate to the second user that the originally denied transaction is to purchase books for school. After the first user has entered a note, or if the first user does not want to enter the note, the first user can either send the request (e.g., by interacting with the “send request” button 308) or cancel the transaction altogether (e.g., by interacting with the “cancel transaction” button 310).

A request to fund via a third-party is received at 206. The financial institution computing system 102 receives the request to fund via the third-party from the first user's mobile device. For example, the request may be sent from the first user's mobile device after the first user interacts with the “send request” button 308. The request includes an identification of the second user targeted in the request, an indication of the amount of funds needed, an identity of the requestor (i.e., the first user), a time of the request, a merchant identifier, a merchant location, and any note included in the request by the first user. A funding request message is transmitted at 208. The financial institution computing system 102 transmits the funding request message to the second user's mobile device. The request may be transmitted as an e-mail message or an in-application message (e.g., a push notification processed by the mobile wallet client 110). The request includes information about the previously denied transaction. The information includes the requestor's identity (i.e., the first user's identity), an amount of money requested, a date and time of the request, an identification of the merchant 108 associated with the previously denied transaction, a location of the merchant 108, a note from the requestor (if provided by the first user), and a location of the first user.

An indication that the funding request message was opened is received at 210. The financial institution computing system 102 receives an indication from the second user's mobile device. The indication informs the financial institution computing system 102 that the second user is viewing the funding request message. In response to receiving the indication at 210, updated first user location information is transmitted to the second user's mobile device at 212. The financial institution computing system 102 requests location information relating to the first user's mobile device and transmits the received location information to the second user's mobile device. The updated first user location information lets the second user know where the first user is at the time of the contact reading the funding request message. The first user's location may be used by the second user to determine that the first user is in the vicinity of the merchant 108. This information may be used by the second user to determine that the first user is still seeking funding for the purchase and that the request is still valid. For example, if the current location of the first user is fifty miles away from the merchant 108, the second user may choose to deny the request for funding because it is evident that the first user no longer needs the goods or services offered by the merchant 108. The updated first user location is displayed to the second user along with the funding request message.

Referring to FIG. 4 shows an exemplary user interface 400 of the mobile wallet client 110 as presented on the display 132 of the mobile device 106. The user interface 400 shows the mobile device 106 of the second user that received the funding request message from the first user. As shown in FIG. 4, the fund request message provides basic information 402 relating to the fund request. The basic information 402 includes an identification of the first user (e.g., “John”), a date and time of the request, an amount of money requested, and an identification of the merchant where the funds will be spent. In some arrangements, the identification of the merchant also includes a location of the merchant (e.g., a street address). The fund request message includes a note 404 from the first user if the first user included the optional note in the fund request. Additionally, the fund request message includes current first user location information 408. The current first user location information 408 is received from the first user's mobile device at 210 of method 200. In some arrangements, the current first user location information 408 is updated periodically (e.g., every minute, every five minutes, etc.) or in real time.

The user interface 400 includes a plurality of response options. The response options allow the second user to accept the funding request as sent by interacting with the accept button 408 or to reject the funding request by interacting with the reject button 410. The second user can also alter the initial request. For example, the second user may reply to the initial request with a conditional acceptance of the funding request contingent on the first user agreeing to a repayment plan by interacting with button 412. The repayment plan terms may be set by the second user. The repayment plan may include repayment of the amount requested and interest accrued at an interest rate set by the second user. The repayment plan may include automatic payments (e.g., monthly payments until the requested amount is returned, a single payment repaying the total amount owed to the contact at a scheduled date, etc.) from an account of the first user into an account of the second user that are facilitated by the financial institution computing system 102. The second user can also respond with a modified amount by interacting with button 414. For example, as shown in FIG. 4, the request is for thirty five dollars; however, the second user may only want to provide twenty dollars of funding to the first user. Button 414 allows the second user to provide a different amount of funding than requested. Other reply options may be provided by interacting with button 416. For example, the other reply options may allow the second user to limit the provided funds to only purchases of specified items, to limit the provided funds to only certain merchants, to provide an expiration for the provided funds, and the like. In some arrangements, the other reply options allow the second user to suggest splitting the cost of the attempted transaction with the first user or other mobile wallet users (e.g., a third user, a fourth user, etc.). For example, the second user can reply with the offer to pay for a certain percentage of the transaction (e.g., the first user pays 50% while the second user pays the remaining 50%). In such arrangements, if the first user accepts the split transaction, the payment code generated (at 220 as discussed below) may draw funds from multiple payment sources at the agreed upon split percentages: an account associated with the first user and an account associated with the second user.

Referring again to FIG. 2, the second user decides whether to accept the request to fund from the first user or to deny the request to fund at 214. Based on the second user's decision, the second user's mobile device transmits the decision to the financial institution computing system 102. If the second user denied request for funds (e.g., by interacting with the reject button 410 of user interface 400), a funding request denial is transmitted to the first user's user mobile device at 216. In some arrangements, the financial institution computing system 102 transmits a denial at 216 if the second user has not responded to the request within a set period of time (e.g., within thirty minutes). In such arrangements, the request to fund expired and is no longer acceptable by the second user. The financial institution computing system 102 then determines whether the first user wants to send another funding request to another contact at 218. The first user can restart the process and transmit a request to another contact (e.g., another mobile wallet user). In these situations, method 200 returns to step 206. In some arrangements, any additional requests sent by the first user to other contacts may include an indication that the first user previously requested funds from at least one other contact (i.e., the second user), and the at least one other contact already denied the first user's request. For example, if a child first requests funds from his mother, and the mother hasn't responded or denied the initial request, the child may send a second fund request to his dad. The second fund request includes an indication that the child previously requested funds from his mother, but that the mother did not approve of the fund request. Based on this information, the dad may decide not to approve the fund request as well. If no additional request is sent by the first user, method 200 ends.

If the second user approved the funding request at 214, updated payment information is transmitted at 220. The updated payment information is transmitted from the financial institution computing system 102 to the first user's mobile device. The updated payment information includes a payment code. In some arrangements, the payment code can be displayed on the display of the first user's mobile device such that the payment code can be input into the merchant POS system 112 (e.g., by manually typing the payment code into the POS system 112, by scanning the payment code, etc.). In such arrangements, the payment code may be a barcode, a QR code, a string of numbers, or the like, that can then be relayed to the merchant POS system 112 to complete the transaction. In other arrangements, the payment code is a digital token or file that can be transmitted to the merchant POS system 112 from the first user's mobile device (e.g., via Bluetooth®, near field communication, radio frequency identification, WiFI, ZigBee®, etc.). The payment code may be a limited use payment code (e.g., a one-time use payment code). In some arrangements, the payment code includes a geographic restriction (e.g., the payment code is only valid in certain geography defined by the second user). For example, FIG. 5 shows an exemplary user interface 500 of the mobile wallet client 110 as presented on the display 132 of the mobile device 106 associated with the first user. The user interface 500 includes a QR code 502, which can be scanned by the merchant POS system 112 to effectuate payment from the second user (i.e., the individual funding the first user's purchase) to the merchant 108. The user interface 500 may also indicate that the payment is coming from a contact of the first user (e.g. as shown here, the payment is coming from “Mom”) at 504 and an indication of the amount of money that is approved for the specific transaction at 506.

The payment to the merchant 108 is processed at 222. The financial institution computing system 102 receives an updated transaction request with the updated payment information from the merchant POS system 112. The updated transaction request includes the payment code. The financial institution computing system 102 verifies that the funds are available in the contact's account in a similar manner as discussed above with respect to 204. When the payment is processed, the financial institution computing system 102 transmits an approval message to the merchant POS system 102. In some arrangements, the financial institution computing system 102 also transmits approval messages to the user devices 106 associated with both the first user and the second user. The second user's account balance is updated at 224. The financial institution computing system 102 updates the appropriate account balance in the account database 122 to account for the payment to the merchant 108. If the first user agreed to a repayment plan, the financial institution computing system 102 implements the repayment rules associated with the repayment plan at 226. For example, the financial institution computing system 102 may schedule an automatic payment from an account associated with the first user to an account associated with the second user.

Referring to FIG. 6, a flow diagram of a method 600 of automatically funding transactions of a user from a third-party's account is shown according to an exemplary embodiment. In some arrangements, the mobile wallet system allows a first user (i.e., a first mobile wallet user) to preauthorize funding for transactions initiated by a second user (i.e., a second mobile wallet user) without an initial denied transaction (e.g., as described above with respect to method 200). For example, a mother may preauthorize her son to purchase certain items or initiate a transaction that is funded from the mother's account. As described in further detail, the first user can setup auto-fund permissions that allow the second user to make purchases funded from the first user's account without asking for approval each time. If the attempted transaction of the second user is within the permissions setup by the first user, the transaction will go through. Then, the first user will have the opportunity to fine-tune the permissions based on the transaction. Method 600 is performed by the financial institution computing system 102 (e.g., by processor 116 controlling the various components of the financial institution computing system 102). Method 600 is described in further detail below.

Method 600 begins when auto-fund permissions are received at 602. Auto-fund permissions are received at the financial institution computing system 102 from a first user's mobile device. The auto-fund permissions indicate a preauthorization for the financial institution to fund purchases of a second user of the mobile wallet system. The preauthorization relates to a one-off funding preauthorization (e.g., for a single purchase made by the second user) or to an open-ended preauthorization for purchases made by the second user (e.g., at a specific merchant). The auto-fund permissions include the identity of the second user (e.g., at least one of a username, a phone number, an e-mail address, etc.) and transaction restrictions. The transaction restrictions define which transactions are to be authorized by the financial institution computing system 102 and which transactions are to be denied by the financial institution computing system 102. The transaction restrictions may include an approved amount limit. The amount limit may limit the amount of an individual transaction (e.g., preauthorization for transactions under thirty dollars) and/or the amount of a series of transactions occurring within a given time period (e.g., preauthorization for transactions not to exceed one hundred dollars within a calendar month, within a week, etc.). The transaction limits may include limitations on the merchant, such as limiting preauthorized transactions to specific merchants, limiting transactions to specific classes or types of merchants (e.g., grocery stores, gas stations, etc.), and excluding transactions from specific merchants or from specific classes or types of merchants (e.g., liquor stores). The transaction limits may also include geographic limitations, such as limiting purchases to certain occurring at merchants within specific geographic regions or excluding purchases attempted at merchants within specific geographic regions. The geographic regions may be defined the first user as a country, a state, a county, a city, a geofence (e.g., a geographic area defined by a plurality of geographic points, such as GPS coordinates or landmarks; within a specific building, such as a shopping mall; etc.), or a combination thereof. In some arrangements, the first user may opt to have the financial institution set default transaction restrictions. As set forth in further detail below, the initial transaction restrictions may be fine-tuned based on approved or denied transactions.

The payment auto-fund permissions database is updated at 604. The financial institution computing system 102 updates an internal database that stores the auto-fund permissions of its mobile wallet users. In some arrangements, the auto-fund permissions are stored in the mobile wallet profiles database 124. After the auto-fund permissions database is updated, the second user's mobile wallet may display the first user as a payment source along with other payment sources (e.g., the second user's bank accounts, credit cards, etc.) during transactions. For example, when the second user is attempting to make a purchase from the merchant 108 via the mobile wallet client 110 running on the second user's mobile device 106, the second user can select the first user as a payment source for the contemplated transaction.

A request to fund a transaction via a third-party is received at 606. The request is received by the financial institution computing system 102 from the second user. In some arrangements, the request is received via the merchant POS system 112. In such arrangements, the second user provided a payment code to the merchant POS system 112 in a similar manner as described above with steps 220 and 222 of method 200. Accordingly, the request may include a payment code generated by the mobile wallet client 110 (via the financial institution computing system 102) that identifies the first user as the payment source. The second user is attempting to pay for goods or services from the merchant 108 via the mobile wallet client 110. In attempting the transaction, the second user selected to fund the transaction via the first user. The request includes transaction information. The transaction information includes an identification of the second user, a payment source (i.e., the first user), a transaction amount, and an identification of the merchant 108. The financial institution computing system 102 determines whether the request is within the auto-fund permissions set up by the first user at 608. The financial institution computing system 102 cross-references the received transaction information against the auto-fund permissions stored in the auto-fund permissions database.

If the request is not within the auto-fund permissions, the transaction is denied at 610. The financial institution computing system 102 transmits a denial to the merchant POS system 112 to inform the merchant 108 that funds will not be provided. Additionally, denied transaction messages are sent at 612. The financial institution computing system 102 sends denied transaction messages to the mobile devices 106 of both the first user and the second user. In some arrangements, the denied transaction messages include information about the attempted transaction (e.g., amount, merchant identification, location information of the second user at the time of the attempted transaction, specific items being purchased in the attempted transaction, and the like) and a rationale for why the transaction was denied (e.g., attempted transaction exceeds the preauthorized limit, the merchant is an excluded merchant, etc.).

If the request is within the auto-fund permissions, the transaction is approved and payment is processed at 614. The financial institution computing system 102 transmits an approval to the merchant POS system 112 such that the merchant 108 can proceed with the transaction. Approval messages are sent at 618. The financial institution computing system 102 transmits a first approval message to the second user's mobile device to indicate that funding for the transaction was approved. The financial institution computing system 102 transmits a second approval message to the first user's mobile device to indicate that a transaction for the second user was funded based on the auto-fund permissions. The second approval message includes information about the attempted transaction (e.g., amount, merchant identification, location information of the second user at the time of the attempted transaction, specific items being purchased in the attempted transaction, and the like).

If the transaction contemplated in the auto-fund permissions received at 602 is a one-off transaction, then method 600 ends after the denied transaction messages are transmitted at 612 or after the approval messages are transmitted at 618. If the auto-fund permissions received at 602 relate to a plurality of preauthorized transactions, the first user has the opportunity to fine-tune the auto-fund permissions based on received any denied transaction messages or any approval messages. For example, a received denied transaction message may indicate that the second user attempted to have the first user pay for a purchase at the merchant 108. However, the merchant 108 is included in a category of merchants not permitted in the initial auto-fund permissions. In such a situation, the denied transaction message may allow the first user to add the merchant 108 to permitted merchants such that future attempted transactions by the second user at the merchant 108 would be allowed (assuming the attempted transaction meets the other rules set forth in the auto-fund permissions). Additionally, if the transaction is denied based on the permissions, the second user may still send a request for (manual) approval of the contemplated purchase to the first user. For example, the second user can send a funding request message similar to those contemplated in method 200 after the initial contemplated transaction was automatically denied by the system. The message may include an explanation as to why the request should be approved by the first user (e.g., “Please Mom! I really need these shoes!”). Similarly, a transaction that was allowed (as indicated in an approval message) may be used by the first user to fine tune the initial auto-fund permissions such that later attempted transactions matching the one that was allowed are later denied the future.

Accordingly, a permissions update request is received at 620. The financial institution computing system 102 receives the permissions update request from the mobile device 106 associated with the first user. The permissions update request includes updated transaction restrictions. The updated transaction restrictions are provided in response to receipt of messages at 612 or 618. The messages received at 612 or 618 may include options for the first user to fine-tune the initially provided auto-fund permissions by modifying any previously provided transaction restrictions. The updated transaction restrictions may further limit the second user's access to the first user's funds or expand on the second user's ability to access the first user's funds. The auto-fund permissions database is updated at 622. The financial institution computing system 102 updates the stored auto-fund permissions based on the received updated transaction restrictions.

The above-described mobile wallet systems and methods allow mobile wallet users to pay for goods and services from merchants even when the users do not have sufficient funds in the account. The users reach out to contacts, such as friends and relatives, for funding of transactions. The mobile wallet systems and methods allow for quicker transactions in circumstances where users attempting purchases do not have sufficient funds because the users can ask for funding on the spot, without needing to go through traditional loan sources, such as banks and lenders. Additionally, the above-described mobile wallet systems and methods permit users to preauthorize funding requests of other users, which also leads to quicker transactions by eliminating the need for individual funding requests.

The embodiments of the present invention have been described with reference to drawings. The drawings illustrate certain details of specific embodiments that implement the systems and methods and programs of the present invention. However, describing the invention with drawings should not be construed as imposing on the invention any limitations that may be present in the drawings. The present invention contemplates methods, systems and program products on any machine-readable media for accomplishing its operations. The embodiments of the present invention may be implemented using an existing computer processor, or by a special purpose computer processor incorporated for this or another purpose or by a hardwired system.

As noted above, embodiments within the scope of the present invention include program products comprising machine-readable media for carrying or having machine-executable instructions or data structures stored thereon. Such machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions.

Embodiments of the present invention have been described in the general context of method steps which may be implemented in one embodiment by a program product including machine-executable instructions, such as program code, for example in the form of program modules executed by machines in networked environments. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Machine-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represent examples of corresponding acts for implementing the functions described in such steps.

As previously indicated, embodiments of the present invention may be practiced in a networked environment using logical connections to one or more remote computers having processors. Those skilled in the art will appreciate that such network computing environments may encompass many types of computers, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and so on. Embodiments of the invention may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination of hardwired or wireless links) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

An example system for implementing the overall system or portions of the invention might include a general purpose computing computers in the form of computers, including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit. The system memory may include read only memory (ROM) and random access memory (RAM). The computer may also include a magnetic hard disk drive for reading from and writing to a magnetic hard disk, a magnetic disk drive for reading from or writing to a removable magnetic disk, and an optical disk drive for reading from or writing to a removable optical disk such as a CD ROM or other optical media. The drives and their associated machine-readable media provide nonvolatile storage of machine-executable instructions, data structures, program modules and other data for the computer. It should also be noted that the word “terminal” as used herein is intended to encompass computer input and output devices. Input devices, as described herein, include a keyboard, a keypad, a mouse, joystick or other input devices performing a similar function. The output devices, as described herein, include a computer monitor, printer, facsimile machine, or other output devices performing a similar function..

It should be noted that although the diagrams herein may show a specific order and composition of method steps, it is understood that the order of these steps may differ from what is depicted. For example, two or more steps may be performed concurrently or with partial concurrence. Also, some method steps that are performed as discrete steps may be combined, steps being performed as a combined step may be separated into discrete steps, the sequence of certain processes may be reversed or otherwise varied, and the nature or number of discrete processes may be altered or varied. The order or sequence of any element or apparatus may be varied or substituted according to alternative embodiments. Accordingly, all such modifications are intended to be included within the scope of the present invention as defined in the appended claims. Such variations will depend on the software and hardware systems chosen and on designer choice. It is understood that all such variations are within the scope of the invention. Likewise, software and web implementations of the present invention could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps and decision steps.

The foregoing description of embodiments of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. The embodiments were chosen and described in order to explain the principals of the invention and its practical application to enable one skilled in the art to utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. Other substitutions, modifications, changes and omissions may be made in the design, operating conditions and arrangement of the embodiments without departing from the scope of the present invention as expressed in the appended claims.

Claims

1. A method of facilitating a payment to a merchant, the method comprising:

receiving, by a computing system from a first user device, a request to fund a purchase of a first user from the merchant with funds from a second user;

transmitting, by the computing system, a message including the request to fund the purchase of the first user to a second user device associated with the second user;

transmitting, by the computing system, updated payment information to the first user device, the updated payment information including a payment code;

receiving, by the computing system, a transaction request from the merchant, the transaction request including the payment code; and

transmitting, by the computing system, an approval message to the merchant.

2. The method of claim 1, further comprising transmitting, by the computing system, location information relating to a location of the first user device to the second user device.

3. The method of claim 2, further comprising receiving, by the computing system, an indication from the second user device that the message was opened by the second user.

4. The method of claim 3, further comprising transmitting, by the computing system, updated location information relating to the location of the first user device to the second user device.

5. The method of claim 1, further comprising:

receiving, by the computing system, a funding request denial from the second user device;

receiving, by the computing system, a second request to fund the purchase of the first user, wherein the second request identifies a third user as a source of funds to fund the purchase; and

transmitting, by the computing system, a second message including the second request to a third user device associated with the third user.

6. The method of claim 5, wherein the second message indicates that the second user already denied the request.

7. The method of claim 1, further comprising transferring funds from a first account associated with the second user into a second account associated with the merchant.

8. The method of claim 1, further comprising scheduling, by the computing system, an automated transfer from a first account associated with the first user to a second account associated with the second user based on a repayment agreement between the first user and the second user.

9. The method of claim 1, wherein the payment code is a barcode, a quick reference code, or a string of numbers.

10. The method of claim 1, wherein the payment code is a digital token.

11. The method of claim 1, wherein the request to fund the purchase is received after the first user attempted an initial transaction which was denied by a financial institution.

12. The method of claim 1, wherein the request to fund the purchase is a funding request to at least partially fund the purchase.

13. A financial institution computing system associated with a financial institution, the system comprising:

a network interface configured to communicate with a plurality of user devices via a network;

at least one memory; and

at least one computing system coupled to the at least one memory that stores instructions that, when executed by the at least one computing system, cause the at least one computing system to: receive, from a first user device, a request to fund a purchase of a first user with funds from a second user; transmit a message including the request to fund the purchase of the first user to a second user device associated with the second user, the request comprising location information; receive, from the second user device, an indication that the message is being viewed by the second user; in response to receiving the indication that the message is being viewed, (1) generate a location request for updated location information, (2) transmit the request for the updated location information to the first user device, (3) receive the updated location information from the first user device, and (4) transmit the updated location information of a current location of the first user device to the second user device; and upon receiving an approval from the second user device, transmit updated payment information to the first user device.

14. The system of claim 13, wherein the at least one computing system is further configured to transmit location information relating to a location of the first user device to the second user device.

15. The system of claim 14, wherein the at least one computing system is further configured to receive a second indication from the second user device that the message was opened by the second user.

16. The system of claim 15, wherein the at least one computing system is further configured to transmit the updated location information relating to the location of the first user device to the second user device.

17. The system of claim 13, wherein the at least one computing system is further configured to:

receive a funding request denial from the second user device; and

receive a second request to fund the purchase of the first user, wherein the second request identifies a third user as a source of funds to fund the purchase; and

transmit a second message including the second request to a third user device associated with the third user.

18. The system of claim 17, wherein the second message indicates that the second user already denied the request.

19. The system of claim 13, wherein the at least one computing system is further configured to transfer the funds from a first account associated with the second user into a second account associated with a merchant.

20. The system of claim 13, wherein the at least one computing system is further configured to schedule an automated transfer from a first account associated with the first user to a second account associated with the second user based on a repayment agreement between the first user and the second user.