US11392920B1 - Smartphone application for securing purchase transactions between a customer and a merchant with self-checkout - Google Patents

Abstract

The present disclosure relates to a mobile computing device that is configured to secure a purchase transaction between a customer and merchant, and facilitate self-checkout between the user and any of several merchants. The system provides a payment processing network that achieves secure transactions free from fraud, while also having low fees. The system is based on establishing a relationship between a merchant's bank and a customer's bank, prior to a purchase transaction by the customer. The customer may then authorize their own bank to push funds to the merchant's bank in order to purchase goods or services using their smartphone, without the need to share any financial information between the user and merchant themselves. The smartphone is further configured to draw from multiple merchant product databases so that the customer may self-checkout, without the need to use a merchant-specific app, all within one app-linked system for payment and shopping.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of Provisional Patent Application No. 62/786,065 filed Dec. 28, 2018, and titled “Smartphone Application for Securing Purchase Transactions Between a User and a Merchant with Self-Checkout,” which is incorporated by reference herein in its entirety.

TECHNICAL FIELD

The present disclosure relates to the field of payment processing networks and banking security, and smartphone apps that enable them. Payment processing networks enable fast and convenient purchase transactions between customers and merchants, while also balancing the needs for security and low fees. Mobile computing device applications are used to interface with payment processing networks, and allow customers to quickly and easily purchase goods from merchants.

BACKGROUND

Modern banking and shopping practices commonly rely on any of several types of well-known payment processing networks. A payment processing network may generally be any system that handles transactions from various channels, such as credit cards and debit cards, that enable a customer to pay a merchant for goods or services. That is, they transfer money (directly or indirectly) from a customer's bank to the merchant's bank in the amount of a purchase. Payment processing networks may often be run by a third party payment processor, such as the major credit card companies Visa, MasterCard, American Express, and Discover. However, other payment processing networks may operate without a private third party company being involved as an intermediary.

In particular, the credit card payment processing networks are some of the most widely known and used of all payment processing networks in the world. Credit cards offer several well-known advantages when used by merchants and customers for payment. For example, from the merchant's perspective, credit cards generally are very good at instantly verifying the availability of a customer's funds/credit limit. This allows merchants to accept non-cash payment from a wide variety of customers, without having to establish a relationship with each individual customer, without fear of the customer reneging on payment.

For example,FIG. 1A shows a prior art diagram of how a credit card payment network generally operates. Generally, acustomer102 engages in a purchase transaction with amerchant104 using acredit card106 that interfaces with a merchant'scredit card reader108 atstep151. Merchant104 then interfaces with a third party creditcard payment processor114 atstep153, relaying information about the purchase in order to ensure that the customer is properly authorized. Third party creditcard payment processor114 then interfaces withbank110 that issued the customer's102credit card106 at step115, checking withbank110 that thecustomer102 has sufficient funds or credit to complete the purchase transaction. Customer'sbank110 then responds to the thirdparty payment processor114 with its answer, authorizing or declining the transaction, atstep157. The thirdparty payment processor114 then relays this authorization/decline back tomerchant104 at step159. Merchant104 then allowscustomer102 to complete the purchase atstep161, As is widely known,steps151,153,155,157,159 and161 can occur very quickly, in as little as seconds. This is one of the advantages of a the credit card payment network.

However, as is also shown inFIG. 1A, credit card payment network also includes transferring the funds used in the purchase transaction—and this includes various fees, Namely, customer'sbank110 engages insettlement163 with the third party creditcard payment processor114—minus an interchange fee. The interchange fee is commonly between 2% and 3% of the purchase transaction price plus a flat fee per transaction of around $0.15. Third party creditcard payment processor114 then settles with the merchant'sbank112 atstep165. The merchant'sbank114 then settles with the merchant's account therein atstep167, while also charging fees.

Accordingly, when a credit card transaction takes place the issuing bank110 (customer's102 bank) pays the acquiring bank112 (merchant's104 bank) for their cardholder's purchase less the interchange fee for the transaction. The acquiringbank112 then pays their merchant from the remaining balance minus a markup for processing the transaction. Merchant104 ultimately receives the gross amount of the sale minus a series of base costs and markups that include interchange, dues, assessments and the processor's markup.

These fees are the price thatmerchant104 pays for the convenience of accepting payment through the credit card payment processor network. On the one hand, this allows merchants to serve more customers while having a reasonable level of trust that they will receive payment. On the other hand, these fees eat into the merchant's profit margins. For some merchants, the buying behavior ofcustomers102 make the need for accepting credit card payments unavoidable. For example, credit card transactions are most commonly used to purchase goods when the purchase price and timing of the purchase transaction are unknown in advance.

However, in other scenarios, a different type of payment network such as is shown inFIG. 1B may be more appropriate for all parties involved,FIG. 1bshows a payment network that debits from a customer's102checking account116 at customer'sbank110, In this type of transaction,customer102 usually receives a bill for some goods or services frommerchant104 atstep173. Thecustomer102 then shares theirchecking account information116 withmerchant104 atstep175. Merchant104 then relays the customer's checkingaccount information116 to the merchant'sbank112. The merchant'sbank112 then “pulls” the funds from the customer'sbank110 by transmitting a request atstep179, The customer'sbank110 then transfers the funds electronically to the merchant'sbank112 atstep181.

This type of transaction commonly uses the Automated Clearing House (“ACH”) payment network, that allows banks to move funds between checking accounts with no (or, extremely low) fees. The ACH network in the United States is organized by the National Automated Clearing House Association (“NACHA”), however NACHA does not act as a third party payment processor. The funds are moved through the governmental organization the Federal Reserve or the Electronic Payments Network that is owned by some 20 major banks.

One drawback to ACH based transfers is that permission must be granted for the money to move, on a merchant-by-merchant basis, Usually, aconsumer102 gives amerchant104 permission to “pull” money from the consumer's checking account atbank110, to pay a bill on a reoccurring monthly basis. For example, aconsumer102 will give theircellphone provider104 permission to debit the consumer's checking account each month to pay for the monthly cellphone charges on an automated payment plan—and the same with utilities like electric service or water service. This requirement for merchant-by-merchant permission may not be overly cumbersome whenconsumer102 does reoccurring business with the merchant, in amounts that are reasonably predictable. However, for irregular transactions at unpredictable times, this type of payment network may be less than ideal for the merchant because it does not allow the merchant to verify the funds before a purchase transaction occurs.

Thus, existing payment processing networks do not currently offer a way for merchants to be assured of receiving electronic payments from a customer in a manner that is simultaneously secure, verified, and low in fees.

Furthermore, customers also suffer several disadvantages of existing payment processing networks. Namely, customers must carry a credit card with them at all times in order to be ready to conduct a purchase transaction. While this may be an improvement over carry large amounts of cash, this nonetheless may present an inconvenience to the customer. Alternatively, customers must be willing to share their checking account information with a merchant. Customers may find this acceptable with some merchants, such as their cell phone company with whom they have a long-standing business relationship—but may not be willing to share such sensitive information with all merchants.

Many customers use their smartphone mobile computing devices to interact with their financial institution. Most banks have a secure “app” that enables the banking customer to log into their customer profile, and view and interact with all their accounts at that bank. Many people in this day and age are never without their smartphone, bringing their smartphone with them at all times—including when shopping. There are many smartphone apps that help customers when shopping, including merchant specific apps that allow a user to engage only with one particular merchant, or payment apps like PayPal or Apple Pay that facilitate payments across a private third party payment processor. One popular type of merchant-specific app is a “scan-n-go” application that enables a user to scan products to be purchased from a particular merchant, and check out without needing to interact with a cashier. Popular scan-n-go apps are offered by stores such as H-E-B, Sam's Club, and Amazon Go.

However, existing scan-n-go applications are generally limited to only one merchant. The user must therefore download several different apps in order to interact with multiple merchants in this manner. Furthermore, existing scan-n-go applications merely use existing payment processing networks—with all the of drawbacks as discussed above.

Accordingly, there is a need in the art for systems, devices, and methods that addresses the shortcomings of the prior art discussed above.

SUMMARY

In one aspect, the disclosure provides a mobile computing device configured to: (1) allow a user to log into a user portal associated with a first financial institution; (2) receive an input from the user to commence a purchase transaction between the user and a merchant; (3) access account balance information regarding funds available in a cash-equivalent account associated with the user, at the first financial institution; (4) receive a product input for each product being purchased by the user; (5) access a product database associated with the merchant, the product database including prices of products sold by the merchant; (6) compare the product input to the product database and compute a purchase transaction price; (7) compare the purchase transaction price with the funds available in the user's cash-equivalent account; (8) receive an input from the user that the purchase transaction is ready to be checked-out; (9) recall information from the first financial institution describing a pre-established transfer association, between the first financial institution and a second financial institution associated with the merchant, from a merchant transfer association database; (10) cause the first financial institution to initiate a transfer of funds from an initiating cash-equivalent account at the first financial institution directly to a receiving cash-equivalent account at the second financial institution, in accordance with the pre-established transfer association; and (11) generate and display a message that the purchase transaction is successfully completed, the message being configured such that it enables the merchant to verify completion of the purchase transaction.

In a second aspect, this disclosure provides a mobile computing device configured to: (1) allow a user to log into a user portal associated with a first financial institution; (2) receive an input from the user to commence a purchase transaction between the user and a merchant; (3) access account balance information regarding funds available in a cash-equivalent account associated with the user, at the first financial institution; (4) receive a product input for each product being purchased by the user, by scanning a machine readable code using a camera in the mobile computing device; (5) access a product database containing product information, the product database being associated with two or more different merchants, and receive product information associated with the merchant with whom the purchase transaction was commenced by receiving an input that includes scanning a machine readable code generated by the merchant, using a camera in the mobile computing device; (6) compare the product input to the product information and compute a purchase transaction price; (7) compare the purchase transaction price with the funds available in the user's cash-equivalent account; (8) receive an input from the user that the purchase transaction is ready to be checked-out; (9) recall information from the first financial institution describing a pre-established transfer association, between the first financial institution and a second financial institution associated with the merchant, from a merchant transfer association database; the merchant transfer association database including information describing two or more pre-established transfer associations, each of the two or more pre-established transfer associations being associated with a different merchant; (10) cause the first financial institution to initiate a transfer of funds from an initiating cash-equivalent account at the first financial institution directly to a receiving cash-equivalent account at the second financial institution, in accordance with the pre-established transfer association; and (11) generate and display on the mobile computing device a machine readable message that the purchase transaction is successfully completed.

Finally, in another aspect, this disclosure provides a mobile computing device configured to: (1) allow a user to log into a user portal associated with a first financial institution; (2) receive an input from the user to commence a purchase transaction between the user and a merchant; (3) access account balance information regarding funds available in a cash-equivalent account associated with the user, at the first financial institution; (4) receive a product input for each product being purchased by the user; (5) access a product database associated with the merchant, the product database including prices of products sold by the merchant; (6) compare the product input to the product database and compute a purchase transaction price; (7) compare the purchase transaction price with the funds available in the user's cash-equivalent account; (8) receive an input from the user that the purchase transaction is ready to be checked-out; (9) recall information from the first financial institution describing a pre-established transfer association, consisting essentially of an account number and routing number for a receiving cash-equivalent account associated with the merchant at a second financial institution, from a merchant transfer association database; (10) cause the first financial institution to initiate a transfer of funds from the user's cash-equivalent account at the first financial institution directly to the receiving cash-equivalent account at the second financial institution, in accordance with the pre-established transfer association, via the Federal Reserve Automated Clearing House network; (11) generate and display a message that the purchase transaction is successfully completed, the message being configured such that it enables the merchant to verify completion of the purchase transaction; (12) generate and send a message to the user after the purchase transaction is completed regarding available funds in the user's cash-equivalent account; and (13) generate and send instructions to the first financial institution causing the first financial institution to place a temporary hold on an amount of funds in the users cash-equivalent account equal to the purchase transaction price, the temporary hold expiring when the funds are transferred to the second financial institution.

Other systems, methods, features, and advantages of the invention will be, or will become, apparent to one of ordinary skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description and this summary, be within the scope of the invention, and be protected by the following claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention can be better understood with reference to the following drawings and description. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention. Moreover, in the figures, like reference numerals designate corresponding parts throughout the different views.

FIG. 1A shows a prior art credit card payment processing network.

FIG. 1B shows a prior art ACH payment processing network, that pulls funds from a customer's checking account.

FIG. 2 shows a payment processing network in accordance with this disclosure, where a customer's bank pushes funds to a merchant's bank.

FIG. 3 shows a system that operates a payment processing network, including at least one computer device that includes a processor.

FIG. 4 shows a flow chart of a method for operating a payment processing network in accordance with this disclosure, from the perspective of the system operating the network,

FIG. 5A shows a flow chart of a prior art method for operating a credit card payment processing network.

FIG. 5B shows a flow chart of a prior art method for operating an ACH “pull” payment processing network.

FIG. 5C shows a flow chart of a method for operating a payment processing network in accordance with this disclosure.

FIG. 6 shows a payment processing network in accordance with this disclosure, including multiple merchants and multiple merchants' banks in the merchant transfer database.

FIG. 7A shows a mobile computing device running an app that allows payment via a payment processing network in accordance with this disclosure.

FIG. 7B shows a mobile computing device running an app that has processed a payment, and provided confirmation of the transaction to the user and merchant.

FIG. 8 shows a mobile computing device running an app that facilitates a purchase transaction between a user/customer and a merchant, by allowing the user to scan each item they are purchasing so as to check-out without interacting with a cashier,

FIG. 9 shows a flowchart of a method of operating a mobile computing device to allow a user to scan items themselves and check-out without a cashier, and also pay with a payment network in accordance with this disclosure.

FIG. 10 shows a system that operates a payment processing network in accordance with this disclosure, and further integrates a self-checkout shopping facilitator.

FIG. 11 shows a system that operates a payment processing network and an integrated self-checkout shopping facilitator, among multiple merchants.

FIG. 12 shows a mobile computing device running an app that checks a purchase transaction running total against the customer's personal spending budgets, prior to checkout.

FIG. 13 shows a mobile computing device running an app that offers a coupon to the user/customer from the user's financial institution, based on the user's purchase history.

DETAILED DESCRIPTION

Systems to secure and verify a purchase transaction between a customer and a merchant are broadly disclosed that enable the merchant to reliably receive funds from the customer with no to very-low fees. Related methods and apparatuses, such a mobile computing device aka smartphone, are also disclosed—as well as a non-transitory computer readable storage medium including instructions which, when executed by one or more computing devices, carry out a method for securing a purchase transaction between a customer and a merchant.

Most broadly, a system for facilitating and processing payments between a customer and a merchant may include a pre-established transfer association between the merchant's bank and the customer's bank. This pre-established transfer association may involve the merchant's bank sharing relevant account information, associated with the merchant, with the customer's bank. As a result of this pre-established transfer association, the customer may then initiate a transfer of funds associated with a purchase transaction whenever (and in whatever amount) the customer desires to shop with the merchant. A mobile computing device may also be configured to further facilitate the customer's shopping, by allowing the customer to input information associated with items sold by the merchant into the mobile computing device and completing the purchase transaction without human assistance.

In this way, this disclosure provides various systems and smartphone apps that save the merchant money: by reducing payment processing transaction fees, and reducing the need for cashier employees. The costs savings to the merchant in this way provide an incentive to the merchant to opt-in to creating the pre-established transfer association. The customer also benefits from a such a system, as their purchase transaction can be rung-up and completed within a single smartphone app without the need to rely on another payment method such as carrying a credit card on their person.

In particular,FIG. 2 shows a payment processing network in accordance with this disclosure. This figure is a diagram showing the relationships between various parties and institutions involved in a purchase transaction. Namely,customer202 wishes to purchase goods or services frommerchant204.

Prior to the purchase transaction,merchant204 has previously directed hisbank212 to establish a transfer association between the merchant'sbank212 and the customer'sbank210, per251. The pre-established transfer association between merchant'sbank212 and customer'sbank210 may include a variety of types of information, but in particular may include the routing and account number for a receiving cash-equivalent account atbank212.

Once the pre-established transfer association betweenmerchant bank212 andcustomer bank210 has been created,customer202 may use theirsmartphone206 to begin a purchase transaction. The purchase transaction may begin by receiving some information from the merchant atstep253. For example, the smartphone may receive product information, a checkout code that is manually entered by the user, a checkout code that is machine readable, or an electronic contactless communication, from themerchant204. The customer's may then cause hissmartphone206 to relay information about the purchase transaction to the customer'sbank210 atstep255.

The customer'sbank210 may also be referred to as the “originating” bank, because the funds for the purchase transaction originate at this bank. Furthermore, the terms “bank” and “financial institution” are generally used interchangeable throughout this disclosure. These terms are understood in this context to refer to any institution that offers consumer or corporate banking services. These terms may therefor include various institutions that are otherwise classified as “banks”, “credit unions”, “thrift institutions”, “savings and loan associations”, and others.

Customer'sbank210 then compares at least a purchase transaction price with the funds available in an account associated with the customer. Generally, the customer's account atbank210 may be any cash-equivalent account—such as a checking account, savings account, a money market fund, or other account that is considered similarly liquid. By comparing the funds available in the customer's account with the purchase transaction price, the payment processing network verifies funds prior to completion of the purchase transaction. This verification is done elegantly, because thecustomer202 is merely checking into hisown bank210. The relationship between thecustomer202 and hisown bank210 will likely be longstanding and trustworthy, thereforecustomers202 will not need the services of a private third party payment processor to verify funds, but will instead be able to check funds to be used in the purchase transaction using the same smartphone app as they would check their accounts in circumstances apart from any purchase transaction.

Once the verification of the customer's funds atbank210 is done, thebank210 may then initiate a transfer of funds frombank210 to merchant'sbank212. This initiation is done in accordance with the pre-established transfer association between these two banks. In this way,bank210 will already have the information necessary to conduct a transfer of funds from itself to the merchant's financial institution—so that the transfer may be initiated by the customer when the customer desires, without any need to interrupt the purchase transaction to otherwise share financial or banking information.

Bank210 then generates and sends a message back to thecustomer202 atstep257. This message may be a verification message, confirming that the funds in the customer's account exceeded the transaction purchase price, and that therefore the purchase transaction was allowed to proceed and the funds transfer was initiated. This message may be a simple plain language text popup within the mobile computing device app, “Your transaction was approved.”

Thecustomer202 may then share this message withmerchant204 atstep259. The message may be configured so as to verify the transaction to both the customer and the merchant that the funds transfer has been initiated, and therefore the purchase transaction has been successfully completed. For example, the message may include a machine readable code such as a OR code or a UPC code that may be scanned by a machine operated bymerchant204.

Finally, settlement funds occurs instep261. That is, the step at which funds are actually (electronically or otherwise) moved from the originating financial institution to the merchant's financial institution occurs at a later time, after the purchase transaction itself has been completed. In this step, funds may be transferred directly from an initiating cash-equivalent account at the originating financial institution directly to a receiving cash-equivalent account at the merchant's financial institution without the use of an independent private third party payment processor. The initiating cash-equivalent account may be the user's own account, or it may be another account within the originating financial institution. Similarly, the receiving cash-equivalent account at the merchant's financial institution may be the merchant's own account, or it may be another account within the merchant's financial institution,

FIG. 3 next shows a system that operates a payment network in accordance with this disclosure. The system may include a variety ofuser input devices302, such asdesktop computer304,mobile computing device306, orlaptop computer308. Generally, as long as a user may input an electronic signal regarding a purchase transaction, the particular device used to do so may be within the scope of this disclosure.

Theuser input devices302 may be in communication with anetwork312.Network312 generally includes the hardware and software used to communicate a message from a user to the originatingbank310.Network312 may include wireless cell phone networks such as 3G or LTE, Wi-Fi networks, and the vast multitude of hardwired cable communications hardware that make up the backbone of the internet.

Originatingbank310 then receives an input from thedevices302 vianetwork312. Originatingbank310 generally includes at least onecomputing device316 that includes a processor and other general purpose computing hardware that enablescomputing device316 to execute programmed instructions. Originatingbank310 includes not only the physical bank itself314, but also the at least onecomputing device316 and a merchant transfer database318 in communication with the at least onecomputing device316. In this way, computing device may be owned, operated, and controlled by the originatingbank310. Merchant transfer database318 may also be owned, operated, and controlled by originatingbank310.

Merchant transfer database318 may be a database created and maintained by originatingbank310 to store the pre-established transfer relationships between originatingbank310 and the merchant'sbank212. As this information must be received by originatingbank310 before a purchase transaction can commence, the information described in the pre-existing transfer association would be stored by the originatingbank310 until such time as needed.

In some embodiments, the pre-established transfer relationship may include merchant account information. Specifically, in some embodiments, the merchant account information that is stored in the merchant transfer database318 may include an account number and routing number for the merchant's receiving cash-equivalent account at the merchant's financial institution. In some embodiments, the account number and routing number for the merchant's receiving cash-equivalent account may be the only information that is necessary for the customer'sbank310 to transfer funds to the merchant'sbank212. Namely, an Automated Clearing House (“ACH”) network transfer that is “pushed” from the customer's originatingbank310 to the merchant'sbank212 need only have the account number and routing number for the merchant's receiving cash-equivalent account in order for the funds to be moved. In such embodiments, the merchant account information that is stored in the merchant transfer database as part of the pre-established transfer association may consist essentially of an account number and routing number for the merchant's receiving cash-equivalent account at the merchant's financial institution.

That the at least onecomputing device316 and the merchant transfer database318 may be owned, operated, and controlled by the originatingbank310 ensures that the payment network may operate without private third party involvement in the purchase transaction. This configuration may ensure that the merchant's bank need share financial information (about a receiving account) only with the consumer's bank, and need not otherwise share this sensitive information with other parties. The merchant's bank may be more willing to share this information with a trusted fellow banking institution than with private third parties. This configuration may also ensure that the user's trust and familiarity with the originatingbank310, as the customer's own bank, can be used to drive adoption and wide usage of the payment processing network described herein. A user may generally be more trustful of their own bank, with all the attendant security features and customer service, with a funds transfer transaction than an otherwise unknown smartphone app startup. This configuration therefore offers multiple advantages for both the merchant and the customer/user.

In some embodiments,computing device316 is configured to operate the payment processing network discussed above and throughout herein.

FIG. 4 shows a flowchart of the steps involved in conducting a purchase transaction using the payment processing network disclosed herein, as conducted by the at least onecomputing device316. These steps are similar to as discussed above, but are described as from the perspective of thecomputing device316—and additional features and details are also disclosed.

In some embodiments, a system that includes the at least onecomputing device316 controls and performs the steps of the payment processing network disclosed herein. However, in other embodiments the payment processing network may be executed from a non-transitory computer readable storage medium including instructions which, when executed by one or more computing devices, carry out a method for operating the payment processing network disclosed herein.

First,computing device316 may be configured to access account balance information regarding funds available in a user's account at the originating financial institution atstep400. The user's account information may be stored indatabase402 whichcomputing device316 accesses. Generally, as discussed above,computing device316 and all of the steps performed by computingdevice316 may be within the originating financial institution, as shown inFIG. 4 byboundary422. Therefore,computing device316 would be able to access the user'saccount database402, because both are under the control of the user's own bank (that is the originating financial institution).

Next, instep404 thecomputing device316 may receive a request, set from theuser406 to the originatingfinancial institution422, to commence a purchase transaction. This request may include information about the purchase transaction such as the purchase transaction price, as well as other information.Computing device316 may then compare the purchase transaction price with the amount of funds available in the user's account.

Instep410,computing device316 recalls the pre-established transfer association for the merchant frommerchant transfer database412. In some embodiments, the pre-established transfer association may be made up of merchant account information comprising an account number and a routing number of the merchant's account at the merchant's bank. In other embodiments, the pre-established transfer association may also include additional information beyond just the merchant's account inform. For example, the pre-established transfer association may include one or more criteria for allowing the purchase transaction to be completed. These one or more criteria may be defined by any of the user, the merchant, the merchant's bank, or the originating bank.

In particular embodiments, the one or more criteria may be based on a factor selected from the group consisting of: purchase transaction price amount, prior transaction history between the user and the merchant, a nature of goods or services being transacted, relationship between the purchase transaction price and the amount funds available in the user's cash-equivalent account, time and date at which the purchase transaction occurs in relation to business hours, and combinations thereof. These criteria may allow any of the parties involved in the transaction to set appropriate risk mitigating standards for conditions under which they will allow or not allow the purchase transaction, and related transfer of funds, to occur.

For example, some banks may wish to exclude a purchase transaction based on the nature of the goods or services being transacted. Currently, some payment processing networks exclude certain merchants entirely, such as merchant who sell substances legal under some state's laws but not currently legal under U.S. federal law. In accordance with this disclosure, the present features may allow a merchant to conduct purchase transaction using a payment processing network in accordance with this disclosure—but only when the specific goods being purchased by the customer do not include a specific prohibited item. In other embodiments, criteria like the prior transaction history between the user and the merchant may be used when the customer is attempting to purchase an abnormally large amount of goods having a much higher than normal purchase transaction price. In yet other embodiments, a merchant or bank may wish to set a criteria of a relationship between the purchase transaction price and the amount funds available in the user's account that is more than merely a default of whether the funds available is equal to or greater than the purchase price. Finally, a party to the transaction may wish to set a criteria regarding a time and date at which the purchase transaction occurs in relation to business hours, because settlement of the actual transfer of funds may generally occur only during business hours.

In one particular embodiment, the criteria may allow the purchase transaction to proceed only when the funds available in the user's cash-equivalent account exceed the purchase transaction price by a preset amount determined by at least one of the originating financial institution and the user. In particular, the user may set a minimum balance threshold for the user's account at the originating financial institution such that any purchase transaction that would draw down the user's balance to below this threshold would be rejected. This may allow the user to plan their personal finances and avoid overdrafts from other transactions that, for example, include a check that hasn't yet been cashed.

In these embodiments involving any of various criteria,computing device316 therefore checks information contained within thepurchase transaction initiation404 fromuser406 against the criteria in the pre-establishedmerchant transfer association412 atstep414. If the criteria is not met,computing device316 generates and sends a message to theuser416. Thecomputing device316 may then again receive aninput406 so as to initiate another loop of checking the newly received purchase transaction initiation information against the criteria. If the criteria is met,computing device316 may proceed to initiate the transfer of funds from the originating bank to the merchant's bank atstep418.

After the funds transfer is initiated,computing device316 then may generate a message confirming completion of the purchase transaction atstep420.

FIGS. 5A-C show several flowcharts that compare prior art payment processing networks (FIG. 5A andFIG. 5B) with a payment processing network in accordance with this disclosure (FIG. 5C). These figures may be compared and contrasted withFIG. 4 described above. These figures may also be understood with reference toFIGS. 1A, 1B, and 2 also described above.

Specifically,FIG. 5A is a flow chart showing the operation of a prior art credit card payment processing network as illustrated inFIG. 1A. In a credit card payment processing network, thefirst step551 occurs when the customer swipes their credit card with a merchant's credit card machine. Step551 therefore includes an exchange of sensitive financial information between the customer and the merchant, as noted by the dashed outline ofstep551.

Next, the merchant transmits data about the purchase transaction, such as the price, to the third party payment processing network instep553—such as the well-known credit card processors Visa, MasterCard, American Express, and Discover Card. The third party processor then requests verification of funds from the customer's bank that issued the credit card atstep555. The credit card issuing bank then responds to the third party credit card payment processor to verify the funds atstep557. The third party credit card payment processor then relays that verification back to the merchant atstep559. After receiving the verification, the merchant then allows the customer to finalize the purchase transaction atstep561.

After these steps occur, after some delay, the settlement part of the process happens whereby funds are actually transferred electronically between the banks with the third party payment processor as an intermediary. Namely, the credit card issuing bank (the customer's bank) settles with the third party credit card payment processor atstep563 by transferring funds electronically from the customer's bank to the third party credit card payment processor. This step involves approximately 2%-3% of the transaction purchase price in fees. The third party credit card payment processor then settles with the merchant's bank, by transferring funds to them, atstep565. Finally, the merchant's bank settles with the merchant's own account at the merchant's bank and charges some additional fees atstep567.

Overall, existing credit card payment networks provide the advantage of verification of funds prior to complete of the purchase transaction—but they do this at the cost of significant fees.

For comparison,FIG. 5B shows an ACH “pull” bill pay payment processing network in action, as discussed with respect toFIG. 1B above, Namely, a customer first received a bill from the merchant atstep573, This may be before or after services are rendered or goods are transferred. The customer may then typically allow some delay before acting on the bill. Next, the customer shares the customers checking account information with the merchant atstep575. In this step, the customer may typically authorize the merchant to pull the currently billed amount, or any future billed amounts, or both. Step575 therefore includes an exchange of sensitive financial information between the customer and the merchant, as noted by the dashed outline ofstep575.

Next, the merchant shares the customers checking account information with the merchant's own bank, atstep577. Instep579, the merchant's bank “pulls” the funds from the customer's checking account by transmitting a request for the funds to the customers bank. After some delay, usually three business days, the funds arrive in the merchant's checking account at settlement atstep581. Little to no fees are charged to either the merchant or the customer, because the ACH system on which this payment network is based generally charges almost zero fees.

Overall, this existing ACH “pull” payment network therefore provides low cost payment processing. However, there is no verification of funds prior to a transaction occurring—and this payment network still includes an exchange of sensitive financial information between the customer and the merchant.

In contrast,FIG. 5C shows how a payment processing network in accordance with this disclosure provides verification of funds prior to closing a purchase transaction, yet still charges little to no fees. As discussed with respect toFIG. 2 andFIG. 4, the process begins with a merchant who opts in to atransfer association database584 at the user's financial institution atstep582. As noted, the process also of course requires that the user have a checking account (or other cash-equivalent account) at a first financial institution at586.

Next the user receives product or transaction information from the merchant to initiate a specific purchase transaction atstep588. The user then sends a purchase transaction initiation to the user's own financial institution atstep590, the initiation generally including at least a purchase transaction price. The user's financial institution then verifies that the funds are available in the user's account, atstep592. If the funds available are equal to or greater than the purchase transaction price, the user's financial institution proceeds to initiating a “push” of funds from the user's financial institution to the merchant's financial institution, in accordance with the information in themerchant transfer association584 atstep594.

In some embodiments, thestep594 of initiating a transfer of funds may include additional features designed to provide additional benefits. Namely, one of the drawback of ACH based transfer is that funds are not actually “settled” (transferred) until one or more business days later after the initiation of the funds transfer. This may create complications for the user, the user's bank, or both. For example, the funds may sit in the use's account until settlement—and this may cause the user to think they have more money than they actually do, and cause overdrafts when the money earmarked for the purchase transaction is otherwise spent or withdrawn by another method. As a result, payment processing networks in accordance with this disclosure may include one or more features to alleviate this problem.

Specifically, in one embodiment the system may generate and send a message to the user regarding available funds in the user's cash-equivalent account after the purchase transaction is completed, so as to notify the user that: (1) funds used in the purchase transaction will not be withdrawn from the user's cash-equivalent account until a later time, and that (2) the user should not otherwise withdraw or spend the funds used in the purchase transaction. This message may act as a reminder, so as to continually inform the user of the of the “true” balance in their account—without the need to place a true hold on any funds. In some embodiments, this message may be transmitted to a user's smartphone app that is provided by the user's financial institution.

In alternative embodiments, the user's financial institution may structure the payment processing system so as to best control which account the funds are transferred out of, in order to address these issues. Namely, as discussed above, in some embodiments the funds may be transferred directly out of the user's own cash-equivalent account—in these embodiments, the user's financial institution may place a hold on the funds in the user's account in an amount equal to the purchase transaction price. Specifically, the system generates and sends instructions to the originating financial institution causing the originating financial institution to place a temporary hold on an amount of funds in the user's cash-equivalent account equal to the purchase transaction price, the temporary hold expiring when the funds are transferred to the merchant's financial institution. In these embodiments, the system may also generate and send a message to the user after the purchase transaction is completed regarding available funds in the user's cash-equivalent account—so that the user is aware of the hold. The hold then expires when the funds are transferred to the merchant's financial institution.

In a different embodiment, the user's financial institution may create a “sweep” account to act as the initiating cash-equivalent account at the originating financial institution from which funds are transferred.

In these embodiments, the system causes the originating financial institution to transfer funds from the user's cash-equivalent account to the sweep account at the time of the purchase transaction. Then the system causes the originating financial institution to transfer funds from the sweep account directly to the merchant's financial institution at a time subsequent to the purchase transaction. In this way, the originating financial institution creates a sweep account owned by the originating financial institution and transfers funds from the user's account to the sweep account immediately—which is easily done because this is an intra-bank transfer. The funds then sit in the sweep account until settlement occurs later between the two different banks.

After the details of initiating the funds transfer have been worked through by the system, the user's financial institution then sends a message to at least one of the user and the merchant that verifies that the purchase transaction has been successful instep596.

Finally, after some delay commonly of one or more business day, the funds arrive at the merchant's financial institution instep598. Specifically, in some embodiments, the fund arrive directly into the merchant's checking account at the merchant's financial institution.

FIG. 6 shows another embodiment of a payment processing network in accordance with this disclosure, that includes multiple merchants and multiple merchants' banks associated with the merchant transfer database. Specifically,user602 may wish to do business with any ofseveral merchants604,620,622 using the same payment processing network. In order to do so, each of the merchant's banks would have to opt-in to provide merchant transfer information that may be stored in the merchant transfer database.

Specifically,first merchant604 may be associated with first merchant'sbank612 that opts-in to a first merchant transfer association655 by sharing relevant account information with the customer'sbank610.Second merchant620 may then be associated with second merchant'sbank624 that creates a second merchant transfer association653 withcustomer bank610. Similarly,third merchant622 may be associated with third merchant'sbank626 that establishes thirdmerchant transfer association651 withcustomer bank610. Each of themerchant transfer associations651,653,655 are then stored in the merchanttransfer association database618 that is a part of the customer'sbank610. As a result,customer602 may use hissmartphone606 to receive information (657,659,661) from any of the several merchants to initiate a purchase transaction, then communicate this (663) to the user'sbank610 to verify funds. As discussed above, user'sbank610 then confirms that the purchase transaction is completed665 and the user may communicate this back tomerchants604,620,622 at667,669,671. Settlement between user'sbank610 and any of the merchant'sbanks612,624,626 then occurs at alater time673,675,677. In this way, the merchant transfer association database includes information describing two or more pre-established transfer associations, each of the two or more pre-established transfer associations being associated with a different merchant.

FIG. 7A shows asmartphone700app701 that interfaces with the payment processing network described in this disclosure. In some embodiments,smartphone700 may be the at least computing device in a system that performs the steps associated with operating the payment processing network in accordance with this disclosure. In other embodiments,smartphone700 may execute instructions stored on a non-transitory computer readable storage medium, that includes instructions which, when executed by thesmartphone700, carry out a method for securing purchase transactions between a user and a merchant.

Smartphone app701 includes auser portal702 associated with the user's financial institution. The user portal allows a user to log into theapp701 securely, by using for example ausername704,password706, and a twofactor authentication code708. Generally, themobile computing device700 is further configured to include one or more user security and verification features (704,706,708), so as to ensure that the mobile computing device user is authorized to access the account at the user's financial institution. Other security measure may include fingerprint scanning, facial recognition, retina scans, and others. Generally,app701 is the “authorized” app created and maintained by the user's financial institution as the official smartphone app for accessing accounts at that financial institution.

After logging in,smartphone700app701 may prompt710 the user to initiate a purchase transaction. Prompt710 may include locationaware features712 that use the smartphone's700 GPS location system. For example,smartphone700 may automatically detect if the user is physically located near (or within) a merchant that uses a payment processing network in accordance with this disclosure. Additional location aware features may also be included inapp701, such as: a geographic relationship between the user's home and a preferred merchant, geographic relationship between a merchant's multiple sites, or others.

Prompt710 may displaydetails714 about a payment processing network in accordance with this disclosure, so as to explain the nature of the payment processing network to new users. The user would, of course, have the ability to accept or decline716 use of the payment processing network.

As shown inFIG. 7B, a user next receives a checkout code from the merchant regarding the nature, price, etc. of the transaction. With reference toFIG. 2,user202 receivedinformation253 frommerchant204 regarding the purchase transaction.Mobile computing device700app701 then may display718 that the checkout code has been received720, thepurchase transaction price722, and the funds available in the user'saccount724. User may then select prompt726 to proceed to complete the purchase transaction, or prompt728 to cancel the transaction.

Mobile computing device700app701 may then display730 aconfirmation message732,734 showing that the purchase transaction has been completed successfully. In particular,confirmation message732 may be sent to the user for the user's benefit—andconfirmation message734 may be displayed for the merchant's benefit. Namely;confirmation message734 may be a machine readable QR code that the user may scan in order to exit the merchant's building—to comply with a security precaution installed by the merchant to prevent theft.

FIG. 8 shows an additional feature of asmartphone800application801 that further facilitates a user's shopping with a merchant. As discussed above;app801 may include locationaware features812 displayed with a prompt814,816 to use the payment processing network. Butsmartphone800app801 may also include features that allow a user to scan items sold by the merchant into theapp801. These features may allow a user to check-out from the merchant without the need for a cashier to ring-up the user's products.

Specifically,smartphone800app801 may includedisplay818 that prompts theuser820 to use the smartphone'scamera822 as ascanner824 to identify one or more products to be purchased. As shown inFIG. 8,product825 may be a box of cereal with a UPC machine readable code827.App801 may in this way receive a product input for each product being purchased by the user. Although not necessarily limited to this embodiment,app801 may therefore receive said product input by scanning a machine readable code using a camera in themobile computing device800.

Display818 may also include a runningtotal826 of the purchase transaction price of items for which a product input has been received by the mobile computing device.Display818 may then further include a prompt828 that allows the user to indicate that they are done scanning items; and ready to complete the purchase transaction. After completing the purchase transaction,app801 may generate and display830 amessage832,834 confirming that the purchase transaction has been completed successfully.Message834 may again be a OR machine readable code.

FIG. 9 is a flowchart further detailing the process by whichsmartphone app801 operates.

As discussed above with respect to other embodiments, mobilecomputing device app801 may first access900 a user portal at a first financial institution associated with theuser902.App801 next may receive a purchase transaction initiation instep904, as shown inFIG. 8 indisplay810. Next,app801 may receiveproduct input910 as shown inFIG. 8 indisplay818. Importantly,app801 may access amerchant product database912.Merchant product database912 may include details about each product or service offered by the merchant, including at least a price of each.App801 may compare eachproduct input910 to theproduct database912 to compute a purchase transaction total price.

Purchase transaction price computed instep908 may be displayed at826 inFIG. 8.App801 may then compare the purchase transaction price to the funds available in a user's account with the first financial institution. Although not shown inFIG. 8, in someembodiments app801 may include a display likedisplay718 inFIG. 7B which visually compares the purchase transaction price to the funds available in the user's account.

However, in other embodiments,app801 may compute and re-compute a running total price after receiving each of two or more product inputs, then compare the running total price to the funds available in the user's cash-equivalent account after receiving each product input, and finally generate and display a message to the user when the running total price accords with one or more criteria predefined by the user, alerting the user to the criteria being triggered.FIG. 9 shows howsteps908 and914 may loop, for each product input received. The message altering the user to the criteria being triggered may be, for example, a direct comparison between the purchase transaction price and the funds available in the user's account—so that no alert is displayed until the purchase transaction price exceeds the funds available. In other embodiments, the criteria in this feature may accord with one or more budgeting predefined personal spending limits discussed below.

App801 then receives auser input918 to check-out atstep916.FIG. 8 shows prompt828 that accords withstep916. Onceapp801 receives the check-outinput918,app801 may then920 recall a pre-established merchant transfer association from a merchanttransfer association database922, as discussed variously above.Steps924,926, and928 are also substantially similar to equivalent steps discussed above with respect to other embodiments.

FIG. 10 shows a system that operates the payment processing network and related product identification features. Namely,mobile computing device1002 is in communication with anetwork1012, which in turn is in communication with firstfinancial institution1010 at which a user has an account. In this embodiment, in contrast with the embodiment shown inFIG. 3,merchant1022 provides information to themerchant transfer database1018 and also themerchant product database1020. Specifically,merchant transfer database1018 may include the routing and account number for the merchant's bank account—whilemerchant product database1020 may be a much more complicated database of various product information (including price) for a wide number of products or services sold by the merchant.Product database1020 may therefore require regular communication betweenmerchant1022 and firstfinancial institution1010. In some instances,merchant1022 may offer an application programming interface (“API”) that provides electronic access to their product database for use by third parties likefinancial institution1010.

FIG. 11 shows another system that operates a payment processing network and related product identification features in accordance with this disclosure. Specifically,FIG. 11 shows how multiple merchants may play a role in the system.First merchant1120 may provide information to merchanttransfer association database1118 at firstfinancial institution1110,second merchant1122 may also provide information into merchanttransfer association database1118, andthird merchant1124 may also provide merchant transfer association information intodatabase1118. In this embodiment, each merchant runs its own separate merchant product database.Mobile computing device1102 may then be in communication with each of firstmerchant product database1126, secondmerchant product database1128, and thirdmerchant product database1130 vianetwork1112.

In the embodiment shown inFIG. 11, the mobile computing device is thus configured so that the user may conduct a purchase transaction at any of multiple different merchants within a single mobile computing device application.

The embodiment shown inFIG. 11 differs from the embodiment shown inFIG. 10 not only in the number of merchants (and associated merchant product databases), but also in the nature of how the merchant product databases are operated. Namely, inFIG. 10 the merchant product database is part of the firstfinancial institution1010. In contrast, inFIG. 11 each of themerchant product databases1126,1128,1130 are separate from the firstfinancial institution1110. Each of these system architectures may present certain advantages and disadvantages, such as ensuring smooth interface with app801 (when the merchant product database is part of the first financial institution1010) vs. the ability to constantly ensure the merchant product database is fully updated and accurate (when apart from firstfinancial institution1110.)

In another embodiment not shown, one merchant product database within first financial institution may include information associated with two or more different merchants. As a result of this configuration, themobile computing device800 receives information in the product database from the first financial institution. In this embodiment, the merchant transfer association database also includes information describing two or more pre-established transfer associations, each of the two or more pre-established transfer associations being associated with a different merchant.

In any of these several embodiments, merchanttransfer association database1018,1118 are part of the firstfinancial institution1010,1110.

FIG. 12 shows an additional feature of amobile computing device1200application1201 that further enhances its utility to the user/customer. Specifically,App1201 includesdisplay1203 that is substantially similar todisplay818 inFIG. 8—with the additional of prompt1212 that allows a user to check the items scanned to be purchased against one or more personal spending budgets.Display1205 shows how the totalpurchase transaction price1214 may be graphically compared against three personal spending categories.

Specifically, firstpersonal spending category1216 is labeled food budget.Bar graph1218 shows a total budgetary valuation, broken down into three categories: previously spentamount1220, amount in thistransaction1222, and leftover to spend1224. Second personal spendingcategory pharmacy budget1226 similarly includes previously spendamount1230, amount in this transaction1232, and leftover to spend1234 split acrosssecond bar graph1228. Third personal spending category sporting goods budgeting1236 does not include a previously spent amount, and so only includes an amount in thistransaction1240 and an amount leftover to spend1242 inthird bar graph1238.

In order to create the budget categories,smartphone1200app1201 may receive an input from the user specifying one or more budgeting categories and a valuation for each budgeting category, the budgeting categories being classifications of the user's spending. During a purchase transaction,app1201 may then classify each product being purchased by the user into the one or more budget categories as each product input is received by the mobile computing device.App1201 may then compare a price of each product being purchased by the user to the valuation for each budgeting category and any prior spending in each budgeting category, to determine by what amount the total spent in each budgeting category would change upon completion of the purchase transaction.

Finally, as shown inFIG. 12,app1201 may generate and display on the mobile computing device a message to the user indicating by what amount the total spent in each budgeting category would change upon completion of the purchase transaction. All of these steps occur prior to receiving an input from the user that the purchase transaction is ready to be checked-out. These features thereby allow a user to compare their in-progress spending to their personal budget, before completing the transaction, on an item-by-item basis. This may provide useful feedback to the user on their spending habits in real time, so that different decisions about spending could be made before completing the purchase transaction.

Finally,FIG. 13 shows another feature of amobile computing device1300app1301 in accordance with this disclosure.Smartphone app1301 includesdisplay1303 that is substantially similar todisplay818 inFIG. 8 except thatmessage1314 is displayed.Message1314 indicates that a coupon is available to apply to this purchase transaction. If the use is interested in using the coupon, the user may click onmessage1314 so as to causemobile computing device1300app1301 to change todisplay1305.Display1305 includes amessage1316 communicating one or more criteria for receiving the coupon.

Namely,display1305 indicates that the user's purchase history included a first item1318 that triggered acoupon1320 applicable to asecond item1322. In this embodiment, the user's purchase of ribeye steak1318 triggered acoupon1320 forbroccoli1322.Display1305 then further includes a prompt1324 by which a user can accept the coupon, and then a new running total of the purchase transaction price after the coupon would be applied1326. Additional navigation prompts1328 and1330 also gives the user the choice of which action to take next.

The embodiment ofFIG. 13 may include these features as a result ofapp1301 sending to the first financial institution a record of each prior purchase transaction, to be stored in a user purchase history database. The user's financial institution may therefore have a record of items purchased by the user, with the user's opt-in permission to share this information with the user's financial institution. This feature provides the user's financial institution with specific data about the user's spending habits, that would not be available to the user's financial institution absent the present system that incorporates a merchant product database. The user's financial institution may use this data to better serve its customers, in ways like insurance products, financial products, customer service, and others.

In return for sharing this data, the user's financial institution may offer the user an incentive, such as the coupon, based on the information associated with the user in the user purchase history database. This incentive may both reward the user, and also nudge the user's future actions toward behavior that is desired by both the user and the user's financial institution—such as eating healthier. Nudging future behavior may occur by targeting the incentive towards a certain benefit during a future purchase transaction with a merchant, such as buying broccoli next time the user is at the grocery store.

While various embodiments of the invention have been described, the description is intended to be exemplary, rather than limiting and it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible that are within the scope of the invention. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents. Also, various modifications and changes may be made within the scope of the attached claims.

Claims (8)

We claim:

1. A mobile computing device configured to:

allow a user to log into a user portal associated with a first financial institution;

receive an input from the user to commence a purchase transaction between the user and a merchant;

access account balance information regarding funds available in a cash-equivalent account associated with the user, the cash-equivalent account associated with the user being at the first financial institution;

receive a product input for each product being purchased by the user, by scanning a machine readable code using a camera in the mobile computing device;

access a product database containing product information, the product database being associated with two or more different merchants, and receive product information associated with the merchant with whom the purchase transaction was commenced by receiving an input that includes scanning a machine readable code generated by the merchant, using a camera in the mobile computing device;

compare the product input to the product information and compute a purchase transaction price;

compare the purchase transaction price with the funds available in the cash-equivalent account associated with the user at the first financial institution;

receive an input from the user that the purchase transaction is ready to be checked-out;

send a purchase transaction initiation directly to the first financial institution, in response to the input from the user that the purchase transaction is ready to be checked-out;

recall information, in response to the input from the user that the purchase transaction is ready to be checked-out, from a merchant transfer association database integrated with the first financial institution describing a pre-established transfer association between the first financial institution and a second financial institution associated with the merchant; the merchant transfer association database including information describing two or more pre-established transfer associations, each of the two or more pre-established transfer associations being associated with a different merchant having a different respective second financial institution;

wherein the first financial institution initiates, responsive to the mobile computing device, a transfer of funds from the cash-equivalent account associated with the user at the first financial institution directly to a receiving cash-equivalent account associated with the merchant at the second financial institution, in accordance with the pre-established transfer association;

wherein each of the two or more pre-established transfer associations includes a routing number and account number of the receiving cash-equivalent account at the respective second financial institution, such that the pre-established transfer association enables an electronic transfer of funds via an Automated Clearing House network,

wherein the transfer of funds from the cash-equivalent account associated with the user at the first financial institution directly to the receiving cash-equivalent account associated with the merchant at the second financial institution occurs via the Automated Clearing House network;

receive a message from the first financial institution that the purchase transaction is successfully completed; and

display a message that the purchase transaction is successfully completed, the message including a machine readable code comprises a QR code or a UPC code scannable by a machine operated by the merchant for verifying completion of the purchase transaction.

2. The mobile computing device ofclaim 1, wherein:

the pre-established transfer association includes an account number and routing number for the merchant's receiving cash-equivalent account at the second financial institution.

3. The mobile computing device ofclaim 1, wherein the mobile computing device is further configured to:

send to the first financial institution a record of the purchase transaction, to be stored in a user purchase history database;

receive from the first financial institution an incentive, based on information associated with the user in the user purchase history database, that allows the user to receive a benefit during a future purchase transaction with the merchant.

4. The mobile computing device ofclaim 1, wherein the mobile computing device is further configured to:

receive an input from the user specifying one or more budgeting categories and a valuation for each budgeting category, the budgeting categories being classifications of the user's spending; and

classify each product being purchased by the user into the one or more budget categories as each product input is received by the mobile computing device;

compare a price of each product being purchased by the user to the valuation for each budgeting category and any prior spending in each budgeting category, to determine by what amount the total spent in each budgeting category would change upon completion of the purchase transaction;

generate and display a message to the user indicating by what amount the total spent in each budgeting category would change upon completion of the purchase transaction, prior to receiving an input from the user that the purchase transaction is ready to be checked-out.

5. The mobile computing device ofclaim 1, wherein

each of the two or more pre-established transfer associations including data was transferred by each respective second financial institution from the second financial institution to the first financial institution, and stored by the first financial institution, upon request by the merchant prior to the first financial institution receiving the input from the user that the purchase transaction is ready to be checked-out.

6. The mobile computing device ofclaim 1, wherein the mobile computing device is further configured to:

compute and re-compute a running total price after receiving each of two or more product inputs;

compare the running total price to the funds available in the user's cash-equivalent account after receiving each product input; and

generate and display a message to the user when the running total price accords with one or more criteria predefined by the user alerting the user to the criteria being triggered.

7. The mobile computing device ofclaim 1, wherein the mobile computing device is further configured to:

generate and send a message to the user after the purchase transaction is completed regarding available funds in the cash-equivalent account associated with the user; and

generate and send instructions to the first financial institution to place a temporary hold on an amount of funds in the cash-equivalent account associated with the user equal to the purchase transaction price, the temporary hold expiring when the funds are transferred to the second financial institution.

8. The mobile computing device ofclaim 1, wherein

the mobile computing device is further configured to include one or more user security and verification to ensure that the user is authorized to access the cash-equivalent account at the first financial institution.

Images