WO2018005635A2

WO2018005635A2 - Physical, logical separation of balances of funds

Info

Publication number: WO2018005635A2
Application number: PCT/US2017/039731
Authority: WO
Inventors: Brian Grassadonia; Ayokunle OMOJOLA; Jochen Bekmann; Dhanji PRASANNA; Peter Westen
Original assignee: Square, Inc.
Priority date: 2016-06-30
Filing date: 2017-06-28
Publication date: 2018-01-04
Also published as: EP3479322A2; WO2018005635A3

Abstract

Users can maintain logical and physical separation of funds maintained in a single account. The account can include the entire balance of a user's funds, but the user can split the funds between several, physically separated sub-accounts that have balances related to the entire balance of the account. Financial transactions, including credit and debit transactions, can then target sub-accounts that the user established.

Description

PHYSICAL, LOGICAL SEPARATION OF BALANCES OF FUNDS

BACKGROUND

[0001] Account holders often have several banking accounts, e.g., checking, business, and savings. A user may establish additional accounts for different purposes, e.g., business and personal accounts. Opening a new account may be a complex process that involves creating an entirely new record associated with that user. But the new account will likely keep a separate ledger from the other account records, thereby making it difficult for the user to maintain and track the funds in each account.

[0002] Conventional banking and payment computing infrastructures are often limited in the types of consumer-facing features they may provide. This is due to the monolithic systems, lacking in robust features and programmability, used to conduct payment transactions in a highly-regulated environment. Typically, each actor or service has a defined role or set of tasks that are performed by the particular service's computing systems in accordance with the appropriate technical protocols and legal obligations. Because these computing systems do not have a dynamic feature set and cannot be used to perform tasks beyond their initial configurations, and because these systems can only conduct transactions and execute certain processes falling within boundaries defining those initial configurations, the existing banking and payment computing infrastructure cannot offer robust and sophisticated features. As such, users are often limited in the types of computing features they can expect from financial companies.

[0003] Financial institutions whose systems are already part of the existing banking infrastructure are beginning to provide some new features to users, such as aggregating transaction data from across multiple accounts. And there is a growing number of third-party computing services that offer consumers similar new features. These new features can take the form of web-based applications, mobile applications, and application programmable interfaces (API) that interact with one of the various existing systems in the conventional infrastructure. However, these new features are also limited in their sophistication and capabilities, because the systems offering these features are merely gathering transaction data reported from some external system. [0004] Various tip calculation tools can help customers choose an appropriate tip amount and perform the correct addition when paying a bill. These conventional tools are standalone, however, and are not integrated with a payment authorization system associated with the merchant's point of sale system.

[0005] Certain merchants, such as restaurants and taxi services, present an option for a tip or gratuity along with the payment. At a restaurant, for example, a credit card is used twice: first, to authorize a charge based on the subtotal of a bill and generate a receipt; and second, to capture the amount of a tip indicated by the diner on the receipt.

[0006] If the server alters a tip (and thus the total bill amount) after the customer has signed the receipt, the customer's only opportunity to discover and rectify the fraud is to review the credit card or bank statement. The customer receives the statement weeks after the event, and the customer must remember the correct total, then initiate a charge back, either through a card issuer or the merchant. Many victims of such fraud never discover the theft.

[0007] Conventional payment systems do not efficiently integrate a mobile device into the authorization and settlement process to allow for alerts and fraud detection.

DESCRIPTION OF THE DRAWINGS

[0008] Non-limiting embodiments of the present disclosure are described by way of example with reference to the accompanying figures which are schematic and are not intended to be drawn to scale. Unless indicated as representing the background art, the figures represent aspects of the disclosure.

[0009] FIG. 1 illustrates an example of a system for processing payments, according to an embodiment.

[0010] FIG. 2 illustrates an example of a process for establishing a sub-account.

[0011] FIG. 3 illustrates an example of a process for processing a financial transaction using a plurality of sub-accounts.

[0012] FIG. 4 illustrates a simplified example payment flow. [0013] FIG. 5 illustrates a graphical user interface (GUI) for presenting a conversational view of financial transactions.

[0014] FIG. 6 illustrates a graphical user interface (GUI) for presenting a conversational view of financial transactions, including a predicted balance.

[0015] FIG. 7 illustrates an example of a network-based environment in which some embodiments of a payment proxy technology can be implemented.

[0016] FIG. 8 illustrates an example embodiment of a conversational view.

[0017] FIG. 9 illustrates an example embodiment of a notification related to an account.

[0018] FIG. 10 illustrates an example embodiment of a notification using analytics.

[0019] FIG. 11 illustrates an example embodiment of a conversational view allowing interaction with a transaction.

[0020] FIG. 12 illustrates an example embodiment of a notification using analytics.

[0021] FIG. 13 illustrates an example embodiment of an account balance over time.

[0022] FIG. 14 illustrates an example embodiment of analytics related to an account.

[0023] FIG. 15 illustrates example pseudo code for two subroutines.

[0024] FIG. 16 illustrates an embodiment of a system that includes several servers that handle various steps in a computerized system for tracking debit and credit transactions.

[0025] FIG. 17 shows execution of a method of provisioning a payment card number to a user, according to an example embodiment.

[0026] FIG. 18 shows a graphical user interface, according to an example embodiment.

[0027] FIG. 19 shows a graphical user interface, according to an example embodiment.

[0028] FIG. 20 shows a graphical user interface, according to an example embodiment.

[0029] FIG. 21 shows a graphical user interface, according to an example embodiment. [0030] FIG. 22 illustrates a system architecture according to an example embodiment.

[0031] FIG. 23 illustrates a data flow diagram of a tip amount notification message system, according to an example embodiment.

[0032] FIG. 24 illustrates a graphical user interface of a mobile device that received a push notification message, according to an example embodiment.

[0033] FIG. 25 illustrates a graphical user interface of a mobile device that received a push notification message, according to an alternative example embodiment.

[0034] FIG. 26 illustrates a graphical user interface of a mobile device that presents a selection of a tip based on recommended tip amounts, according to an example embodiment.

[0035] FIG. 27 illustrates a data flow diagram of a warning notification message system, according to an example embodiment.

DESCRIPTION

[0036] Current payment processes and accounts provide little flexibility and analytics for the state of the account. Today, financial institutions, such as banks, that provide financial services, such as investments, loans and deposits, allow online access to a ledger of transactions to view past and non-posted transactions. Banks also allow users to open more than one account, such as a personal checking, business checking, or savings accounts. However, users open several, independent accounts that have no relationship to each other besides residing in the same bank and having the same account holder. This provides some value to users, but disparate account records are challenging to manage.

[0037] Embodiments described herein can more efficiently track and present account information than the conventional systems that require multiple accounts. Each sub-account is integrated within a single account record, as opposed to separate account records linked to a single user. In a conventional banking system architecture, each bank has a system of record or core processor, which provides the ledger of transactions for the bank's accounts. An account, such as a checking account or savings account, has an account number for electronic data processing. The account can also be associated with an American Bankers Association routing and transit number ("ABA RTN" or "RTN") or an International Bank Account Number ("IB AN"). The exemplary system architecture described herein establishes records having one or more sub-accounts associated with a bank account. Each of the sub-accounts is integrated within the banking account, as the sum of balances of the sub-accounts (positive or negative), can equal the balance of the bank account, and the real-time changes to the ledger reflecting a credit or debit to a sub-account will automatically update the balance of the sub-accounts and the bank account accordingly.

[0038] Other embodiments described herein aim to give users automated notifications and tracking of events affecting their bank accounts, such as by predicting how transactions will affect the balance. This prediction can be presented on a user interface to provide users with information more efficiently and enable tracking of account activity at a level previously unavailable. In one example, an improved system architecture allows presentation on a user interface of a mobile device of credit and debit transactions in a conversational view format with status updates that can reflect scheduled transactions and other recent transactions. Various embodiments of this improved system architecture provide several improvements over system architectures; for example, they can allow for more accurate, real-time accounting information by logically separated subaccounts at a server that has increased visibility of financial transactions. The increased visibility improves the function of the computer by allowing more control over the computer network and transactions that occur over the network, as explained throughout this specification. The system can predict a balance, display the predicted balance on this user interface, and update the user interface upon the execution of scheduled and unscheduled transactions.

[0039] The present disclosure is here described in detail with reference to embodiments illustrated in the drawings, which form a part here. Other embodiments may be used or other changes may be made without departing from the spirit or scope of the present disclosure. The illustrative embodiments described in the detailed description are not meant to be limiting of the subject matter presented here.

[0040] Various embodiments will now be described in further detail. The following description provides specific details for a thorough understanding and enabling description of these embodiments. One skilled in the relevant art will understand, however, that the embodiments discussed herein may be practiced without many of these details. Likewise, one skilled in the relevant art will also understand that the embodiments can include many other obvious features not described in detail herein. Additionally, some well-known structures or functions may not be shown or described in detail below, to avoid unnecessarily obscuring the relevant description.

[0041] The terms "connected" or "coupled" and related terms used throughout the description are used in an operational sense and are not necessarily limited to a direct physical connection or coupling. Thus, for example, two devices may be coupled directly, or via one or more intermediary media or devices. As another example, devices may be coupled in such a way that information can be passed there-between, while not sharing any physical connection with one another. Based on the disclosure provided herein, one of ordinary skill in the art will appreciate a variety of ways in which connection or coupling exists in accordance with the aforementioned definition.

[0042] The phrases "in some embodiments," "according to some embodiments," "in the embodiments shown," "in other embodiments," and the like generally mean the particular feature, structure, or characteristic following the phrase is included in at least one implementation of the disclosed technology, and may be included in more than one implementation. In addition, such phrases do not necessarily refer to the same embodiments or different embodiments.

[0043] The term "module" or "engine" refers broadly to general or specific-purpose hardware, software, or firmware (or any combination thereof) components. Modules and engines are typically functional components that can generate useful data or other output using specified input(s). A module or engine may or may not be self-contained. Depending upon implementation-specific or other considerations, the modules or engines may be centralized or functionally distributed. An application program (also called an "application") may include one or more modules and/or engines, or a module and/or engine can include one or more application programs.

[0044] The term "cause" and variations thereof, as used throughout this description, refers to either direct causation or indirect causation. For example, a computer system can "cause" an action by sending a message to a second computer system that commands, requests or prompts the second computer system to perform the action. Any number of intermediary devices may examine and/or relay the message during this process. In this regard, a device can "cause" an action even though it may not be known to the device whether the action will ultimately be executed or completed.

[0045] Reference will now be made to the exemplary embodiments illustrated in the drawings, and specific language will be used here to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended. Alterations and further modifications of the inventive features illustrated here, and additional applications of the principles of the inventions as illustrated here, which would occur to one skilled in the relevant art and having possession of this disclosure, are to be considered within the scope of the invention.

[0046] FIG. 1 illustrates an embodiment of a system that includes several servers that handle various steps in a computerized system for tracking and presenting financial transactions, as well as displaying an account status based upon predicted transactions. Merchant computing device 101 can be a payment card payment processing terminal, such as a payment card scanner, that can request payment authorization to complete a sale. The merchant computing device 101, which can be any device capable of capturing payment request data on behalf of a merchant, can receive an input (e.g., swipe or dip a card, wireless transmission, keypad entry) of a user' s payment card information, such as card verification value (CVV or CVVI), card verification code (CVC or CVC1), card identifier (CID), and payment card number, into the merchant computing device 101. Non-limiting examples of a merchant computing device 101 may include a point of sales (POS) terminal, a payment card payment processing terminal (e.g., a payment card scanner), a server for an online site, and a cash register. Non-limiting examples of payment instruments may include magnetic stripe cards, EMV cards, debit cards, credit cards, stored value cards, gift cards, and virtual cards or tokens that may be stored on a client device 1 15 (e.g., user computing device, smartphone, or computer). The merchant computing device 101 may comprise or may be coupled to various types of instrument readers configured to capture transaction data from certain types of payment instruments. For instance, if the payment instrument is a virtual card stored on a client device 1 15, and the client device 1 15 is configured to transmit payment request data for the virtual card using near field communications (NFC), then the merchant computing device 101 may comprise or may be coupled to an NFC scanner configured to capture the transaction data related to the virtual card via the NFC signal received from the client device 1 15. The client device can include one or more client applications stored in memory and executed on one or more processors. The client application can present information to the user and receive inputs from the user via, for example, a keyboard, mouse, or touchscreen. The client applications can be stored on a centralized server, such as the Google Play® store or iTunes®, and the user can download the applications from the centralized server to perform functions, such as those describe in this disclosure.

[0047] In operation, the merchant computing device 101 may capture payment card information and then generate and transmit a digital message, such as a payment authorization request, comprising the payment card information along with transaction data (e.g., transaction amount, merchant identifier) to a merchant-acquirer server 102. The merchant computing device 101 may be configured to generate digital messages containing the payment authorization request, which includes the payment card information and transaction data, may be generated according to particular protocols or specifications, e.g., one or more ISO standards in which the payment authorization request can contain certain fields for the payment card information and the transaction data. Non-limiting examples of data fields that may be included the digital message may include a merchant identifier (merchant ID), a merchant category code (MCC), an amount for the transaction, a timestamp (e.g., data, time), and a card number. In some implementations, the merchant computing device 101 may transmit the digital message containing the card and/or other payment information to a merchant-acquirer server 102, although in some embodiments, the digital message may be transmitted to other devices, such as an issuer processor server 103 of an issuer processor system.

[0048] Merchant-Acquirer

[0049] A merchant-acquirer server 102 may be any computing device configured to process an authorization request from a merchant and forward at least some of the information to an issuer processor server 103 over payment network rails 109 or card-issuer network (e.g., Visa® or MasterCard® networks). Each merchant computing device 101 is associated with a merchant-acquirer server 102 to process payment card payments. Although one merchant computing device 101 and one merchant-acquirer server 102 is shown, the system may comprise more than one of each the merchant computing device 101 and the merchant-acquirer server 102.

[0050] Payment Network Rails

[0051] Payment networks (e.g., Visa®, MasterCard®, and American Express®) may be entities that own and operate payment network rails 109, which may be a computing communications network configured to receive and transmit digital messages between merchants and merchant-acquirers to issuer processors and issuing banks. In operation, merchant computing devices 101 and merchant-acquirer servers 102 may generate, manipulate, and transmit digital messages containing payment authorization requests. The digital messages may be generated and manipulated according to the policies, standards, and protocols implemented by each particular payment network.

[0052] Issuer processor

[0053] Issuer processor systems can establish payment card number records for customers, issue bills and statements, and process payments. The issuer processor server 103 can perform these functions and store transactions and payment card numbers in a storage device, such as database 106. Issuer processors will typically forward payment authorization requests to a system of record server 105. However, the exemplary system comprises a server 104 positioned between issuer processor server 103 and system of record server 105. Furthermore, server 104 can perform some or all of the functions typically associated with issuer processors, and therefore, in these embodiments, the merchant-acquirer server 102 can communicate over the payment network rails with server 104. Although the issuer processor server 103 and the server 104 are shown as separate computing platforms, the issuer processor server 103 and the server 104 can be implemented as a single platform. The positioning of server 104 in between issuer processor server 103 and system of record server 105 allows the server 104 to provide added functionality to the system, such as intervene in and record transactions in the payment stream (e.g., intercept payment authorizations). As a result, server 104 can also have access to all transactions associated with an account to provide further services to the client device 1 15 associated with the account. [0054] Note that FIG. 1 illustrates a four-party scheme (or open scheme) in which the issuer processor server 103 is separate from the merchant-acquirer server 102. Embodiments of this disclosure can similarly function with three-party schemes (or closed schemes), such as (American Express, Discover Card, and Diners Club), in which the issuer processor server 103 and the merchant acquirer server 102 are the same entity.

[0055] The server 104 can be positioned between the issuer processor server 103 and the system of record server 105. Server 104 is part of a consumer computing system ("CCS") 113, which can also include an application programming interface (API) 114 and one or more databases 107a-107n. Server 104 can use API 114 to communicate with client device 115 over user-facing network 111, such as the internet. Databases 107a-107n can include information such a user profile, account numbers, and transaction ledgers. With this system architecture, server 104 can intercept transmissions of transaction messages that occur between issuer processor server 103 and system of record server 105. The server 104 does not need to perform an action on every transaction message, as the server 104 can just relay the transaction message. After receiving a transaction from issuer processor server 103 and recording information from that transaction, server 104 can forward the transaction to system of record server 105.

System of Record

[0056] System of record server 105 can be hosted by a bank 116 or a third party that provides a service to a bank 116. Some banks maintain their own system of record servers. The system of record server 105 maintains the accurate information of the balance of an account maintained by bank 116. Other transactions may be pending or in various stages of the payment stream, but the official recordation of those transactions is by the system of record server 105 and database 110. Certain parties, such as the account owner, the merchant, the issuer processor, or the CCS 113, may assume certain risks that an account holder does not have sufficient funds to fund a transaction, until the system of record records and authorizes the transaction. However, these parties may assume that risk to process transactions more quickly and efficiently.

[0057] Upon receiving a payment authorization request, server 104 can forward associated information to system of record server 105, which maintains an account corresponding to the payment card used in the payment transaction. Bank 116 can maintain the account using the system of record server 105, along with a ledger and other user profile information. System of record server 105 can also include database 1 10 that can store a copy of the ledger associated with the account record.

[0058] Server 104 can also be in communication over user-facing networks 1 1 1 (e.g., the internet) with client device 1 15. Client device 1 15 is illustrated in FIG. 1 as a smartphone, but can be any computing device, such as any mobile phone, tablet, smart watch, personal data assistant, gaming console, or personal computer. Consumer computing system 1 13 can also include several databases in communication with server 104, such as database 107a for storing user profile information, and database 107b for storing sub-account balances and ledgers.

[0059] Server 104 can communicate transactions to the system of record server 105, which can record in database 1 10 the payment authorization and further report it to the Federal Reserve and bank 1 16 that maintains the account record associated with the payment card used in the payment authorization. Bank 1 16 may also generate an authorization response to forward to the system of record server 105, back though other devices in the payment stream and eventually to the merchant computing device 101 to confirm that the merchant may complete the payment transaction.

[0060] The system can allow funds in an account to be physically and logically separated using a single account maintained at a bank 1 16 using database 1 10 and system of record server 105. Previously, users wanting to maintain separate accounts would have to open separate accounts at one or more banks 1 16. Embodiments of this disclosure described herein can rely on a single account, but physically and logically separate that account, maintained at system of record server 105, by maintaining a separate record in server 104, using databases 107a-n. For example, one of the databases 107a-n could be configured as a database for storing user profile information. This profile information can include a username, password, account number, routing/transit number, and one or more pointers to sub-accounts and ledgers for the subaccounts. Each sub-account can have a balance that is an allocated amount less than or equal to the balance of the associated account. However, the total of all of the balances of the subaccounts can be equal to balance of the account. In one embodiment, the sub-account totals can also differ from the account balance. [0061] In some embodiments, assigning sub-accounts related to a single account allows for compartmentalization before payment, rather than allocated funds after a transaction. These embodiments allow for immediate updating of accounts during credit or debit transactions because the transactions occur using the sub-accounts, thereby updating the account record and sub-account records in real-time, rather than processing credit and debit transactions after the transaction completes.

[0062] In some embodiments, the sum of balances of all of the sub-accounts records can be different from the balance of the account balance when there are credits and debits that have not been synchronized to the account record. For example, the owner of server 104 might have a promotional bonus for using the service, and such funds from the promotional bonus can be maintained in a database 107 coupled to server 104. The funds can be paid from a separate account owned by the host of server 104. The server 104 might also not immediately synchronize with the system of record server 105 and the account maintained by bank 116, which can cause a temporary discrepancy between the account ledger stored in database 110 and the data in the account record. Note that each bank 116, the system of record server 105, and the server 104 track information about the account record, such as account number and balance.

[0063] Another reason for a discrepancy may be a credit due to paycheck being deposited in a bank account. While some embodiments described herein have visibility into the credit/debit payment stream, server 104 might not have direct access to all transaction data. Some paychecks are directly deposited into an account, which occurs outside of the credit/debit payment stream shown in FIG. 1. In certain embodiments, the system architecture can be configured to identify such deposits by polling banks or systems of record to identify transactions that took place outside of the credit/debit payment stream(s) that server 104 monitors.

[0064] FIG. 2 illustrates an exemplary embodiment for establishing an account record having corresponding sub-accounts. Step 201 includes receiving a request to establish an account. Initially, a user interested in using the system might not have any relationship with server 104, so the user will be registering with server 104 for the first time. The user can input a username and password, and other identifying information, such as name, address, social security number, date of birth, and prior addresses. In some embodiments, server 104 can use this information to execute a credit check on the user. Once registered, the server 104 can open an account record for the user. The server 104 might have pre-provisioned account numbers stored in one of a plurality of databases 107a-n. If server 104 does not have pre-provisioned account numbers, the server 104 can communicate with bank 116 to create the account (step 203) having a routing transit number, account number, and account balance. The account balance can be a copy of an account balance stored on the system of record server 105. The system of record server 105 can maintain the true account balance as reported to government regulators, such as the Federal Reserve. The server 104 can offer the user an option to open the account associated with a particular bank, or the server 104 can open the account without notifying a bank association. By not notifying the user, the server 104 can provide a "white label" service, such that, the user appears to interact only with server 104, and the backend services provided by the bank 116 and system of record server 105 are not visible to the user. However, server 104 can provide certain information, such as name and address of the account owner, to bank 116 to provide notification of who owns the account, and the bank can store such information in database 110.

[0065] Once opened or assigned an account number, the server 104 can notify the user of the account status (step 205), such as the account is available, or that an account was denied for some reason, e.g., terrorist association, bad credit, or insufficient funds. If opening an account was successful, the system can query the user to establish one or more sub-accounts (step 207). This can be accomplished by delivering a webpage to a user's web browser or by providing an application to the user's client device that contains a graphical user interface (GUI) for querying the user to establish one or more sub-accounts. Irrespective of the implementation, either the server 104 or another server associated with server 104 can provide such a query to establish one or more sub-accounts.

[0066] While some embodiment can allow for manual creation of sub-accounts, embodiments can also include automated creation of sub-accounts. For instance, if a user has a predetermined number of transactions within a certain category, e.g., restaurants, clothing, or food, the server 104 can automatically generate of suggest sub-accounts fitting these predetermined categories. The balances of these sub-accounts can be automatically determined based on the past transactions. For instance, the balance can be set to cover the average expenditure on the category, such that the server 104 can automatically notify the user if they exceed the monthly budget. Alternative embodiments can set the budget to the maximum prior monthly spend on in the category. If the server suggests a sub-account and corresponding budget, then the server can automatically deposit funds into the account every month, based on the suggested balance or a manually entered budget that the user assigns.

[0067] Note that this disclosure refers to generating information, e.g., graphics and graphical user interfaces, for display on a client device. Client devices and servers can cooperate in generating such information for display, such that each generates some or all of the information for display. For example, when stating herein that a client device generates information, the information can be generated at the server in response to a request from the client device to generate the information. Alternatively, the client device could generate the information locally for display. Still further, the client device and the server can generate portions of the information for display. For example, the client device can generate a GUI with fields, and the server supplies information to populate the fields. A person of ordinary skill in the art would understand that the server could generate at least part of the information in response to a request from the client.

[0068] The query to establish one or more sub-accounts (step 207) includes several sub- steps to establish a database record that allows at least one sub-account to be updated along with the account balance. These sub-steps include naming the sub-account using a sub-account identifier, which could be a character string, such as "vacation savings," and providing an amount to allocate the sub-account. The term "alphanumeric character" as used here refers to a symbol that can be a number (i.e., numeric), a letter (i.e., alphabetic), or a combination thereof. The amount can be less than or equal to the amount stored in the account. The server 104, or an application on the client device, can query the user about whether they want to set the subaccount as the default for receiving funds or making payments. The defaults can be for every credit or debit, or only certain credits or debits from specific third parties. Once established, the server 104 can record a balance of the sub-account (step 209), its sub-account identifier, and associated settings in an account record in one of databases 107a-n (step 211). The server 104 can also allow the user to identify a sub-account as a default for handling transactions.

[0069] While the system will debit a specific or default sub-account to complete the transaction, the system can enable a user to reassign the transaction to a different sub-account. If the user accidentally charged a coffee to a vacation savings account, the user could reassign that payment to the coffee sub-account later. Sub-accounts can have several settings, for example, the user can establish a sub-account identifier, e.g., "coffee," such that the server 104 can process every payment made to a coffee shop, either based on, for example, merchant name or MCC, instead of using the default sub-account. The user can establish settings or rules that all payments on a certain day/time period are from a particular logical account (e.g., account with the most funds), or the desired sub-account is based on the MCC of the merchant (e.g., restaurant-related MCC deducts from food logical account).

[0070] When the balance of the sub-account is exhausted, the server 104 may notify the user that the sub-account has a negative balance, i.e., an overdraft, or decline the transaction due to insufficient funds. Note that the negative balance may not be an overdraft of all of the user's funds because the user might have additional funds in their account, but not allocated to the overdrafted sub-account. The user can choose either behavior by configuring sub-account settings stored in a database 107a-n coupled to server 104.

[0071] FIG. 3 illustrates an embodiment for processing credit and debit transactions according to certain embodiments. Steps 301 and 303 correspond to FIG. 2, which explains the process for establishing one or more sub-accounts and recording information in the databases 107a-n. After establishing the account and sub-accounts, according to FIG. 2 and steps 301 and 303, the user is ready to receive a financial transaction (step 305). The financial transaction can be a debit or a credit transaction, a request for authorization, a hold on an amount, funds transfer, or a balance inquiry. For a credit transaction (i.e., receiving funds), the server 104 can receive a response to a polling query from either bank 116 or system of record server 105 that the bank account maintained by bank 116 received additional funds. In the example of FIG. 3, the server 104 can next determine a sub-account to apply the financial transaction to; note that this step can be performed before or after step 305. An account can also receive funds from other users' accounts. The other user's accounts would be debited, while the recipient's account would be credited. Server 104 can update its copy of the account balance, stored in databases 107a-n, to reflect the additional funds. The server first determines whether one or more sub-accounts are set to receive funds by default (step 307). If the server 104 also has settings for one or more default sub-accounts to receive the funds, then the server 104 can update sub-accounts accordingly. For instance, server 104 can credit certain amounts on a percentage or amount basis to predefined accounts or sub-accounts, e.g., $20 or 15% to a specific account, with the remainder going to one or more additional accounts.

[0072] Examples of default sub-accounts to receive funds can be savings accounts for purchases, such as a vacation or car, or accounts for budgeting, such as groceries, entertainment, and bills. Each credit to the account can be allocated across one or more sub-accounts. For example, amounts to be allocated can be on an amount or percentage bases. One or more subaccounts can receive specific amounts, e.g., $25 for coffee and $100 for entertainment. Other sub-accounts can receive portions of the total amount of the credit or what is left over after specific allocations, e.g., 10% vacation savings and 2% for college savings fund. Another account can be set to receive the remainder of funds, e.g., general savings receives remainder of funds. If there is no default for receiving funds, then the server 104 can present a selection of sub-accounts in a GUI (step 309) to the user to select, via an interactive element (e.g., button, dropdown menu, radio button, or hyperlink) which account should receive the funds. In other embodiments, the server 104 can put the funds into a main account without allocating them to a sub-account. Note that the sum of sub-account balances can be equal to or less than the total balance of the main account because not all funds in the main account need be maintained in a sub-account too. Therefore, the server 104 can receive a sub-account identifier from a user before a transaction occurs via a default setting, or during the transaction by querying the user. Once a sub-account is identified for receiving the funds (step 311), the server can read the subaccount balance associated with the sub-account identifier from one of the databases 107a-n (step 313). The server 104 can then write a new value to the balance stored in the sub-account record in databases 107a-n. The system may also optionally provide an automatic notification to the user of the updates to their accounts. Finally, if the account ledgers at the system of record server 105 require updating, the server 104 can transmit a message to system of record server 105 to synchronize the balance across ledgers and store a transaction record containing data about the transaction in a transaction database 107a-n (step 315). The server 104 may also simultaneously, or within a predetermined amount of time (e.g., minutes or hours), transmit a message to the system of record server 105 or bank server 116 to synchronize the balances of the account records stored at both servers by transmitting at least a portion of the transaction data to system of record server 105 (step 316). Once completed, the server 104 can return to a sleep state until receiving another financial transaction (step 305). [0073] When processing debit transactions (i.e., withdrawals), the server first determines whether one or more sub-accounts are set to pay for transactions (step 317). If the server 104 also has settings for one or more default sub-accounts to pay for a debit transaction, then the server 104 can update sub-accounts accordingly. For instance, server 104 can debit certain amounts on a percentage or amount basis from predefined accounts, e.g., $10 or 25% from a specific account, with the remainder coming from one or more additional accounts.

[0074] Default sub-accounts to pay for debit transactions can include "purchases" (e.g., a vacation or car or "budgeting" (e.g., groceries, entertainment, and bills). Each debit to the account can be allocated across one or more sub-accounts. For example, amounts to be allocated can be on an amount or percentage bases. One or more sub-accounts can be debited for one transaction, e.g., $20 from entertainment and $30 from food. Other sub-accounts can pay for portions of the total amount of the debit or what is left over after specific allocations, e.g., 10% vacation savings and 2% from general savings. Another account can be set to pay the remainder of funds, e.g., main account pays for any remainder. If there is no default account for paying funds, then the server 104 can present a selection of sub-accounts in a GUI (step 319) to the user to select which account should pay the funds. In other embodiments, the server 104 can pay the funds from the main account without allocating them from one or more sub-accounts. Therefore, the server 104 can receive a sub-account identifier from a user, who selected a sub-account identifier, before a transaction occurs via a default setting, or during the transaction by querying the user. Once a sub-account is identified for paying the funds (step 321), the server 104 determines whether the sub-account is a line of credit or an account that has funds (step 322.) If the sub-account is a line of credit, then the process continues to step 329, discussed later. Server 104 can provide one or more lines of credit, either issued by the owner of server 104, issued by a bank on card payment network 720 (see FIG. 7), or issued by bank 1 16. If the sub-account contains a balance, server 104 can read the sub-account balance associated with the sub-account identifier from one of the databases 107a-n (step 323).

[0075] Once server 104 identifies one or more sub-accounts for payment, server 104 can generate a payment authorization message to return to the merchant to approve the transaction. In one embodiment, server 104 can authorize the payment without first verifying whether funds exist in system of record server 105 or bank 116. This imposes additional risk on server 104 for authorizing a transaction for which funds may not exist in the account. However, generating an authorization message from server 104 can create a faster response and does not require waiting for a response from the system of record server 105 or bank 1 16. In another embodiment, the server can wait for a response from system of record server 105 or bank 1 16 (step 325) to make a determination of whether an account or sub-account has sufficient funds, which can result in a delay, but has the benefit of assurance that the funds are available and the transaction is recorded at the bank server 1 12 and at the system of record server 105, such that the various ledgers are updated to avoid overdrafts. The server 104, bank server 1 16 or system of record server 105 generates a payment authorization message (step 327) to signify approval of the payment request. The server 104 may then transmit the payment authorization message back through the payment stream to the merchant computing device 101 to approve the transaction, which the merchant may then complete with the user at the merchant computing device (e.g., POS terminal) (step 329). Even though the server 104 approved the transaction, it can still continue to document the transaction by updating copy of the account balance and sub-account balance to reflect the completion of the payment transaction and store a transaction record containing data about the transaction in a transaction database 107a-n (step 331), which can occur substantially simultaneously, or within a predetermined amount of time (e.g., minutes or hours), with the server 104 transmitting the authorization message to the merchant computing device 101. The server 104 may also simultaneously transmit a message to the system of record server 105 or bank server 1 16 to synchronize the balances of the account records stored at both servers by transmitting at least a portion of the transaction data to system of record server 105 (step 333). Finally, server 104 will return to waiting to receive another financial transaction (step 305).

[0076] Note that in an additional embodiment, a user can send funds to third parties using a paper check. The process would be similar to steps 317-333; however, rather than transmitting an authorization message in step 329, the server 104 can request that a paper check be printed and mailed to the third party. The rest of the steps would remain substantially the same. The server 104 can update the account balances in step 331 either in parallel with printing the check or after the check is cashed, and the server 104 may similarly synchronize account balances at that time in step 333. [0077] FIG. 4 illustrates a swim lane diagram of an embodiment for processing a payment transaction. In step 401, the merchant device 101 can begin a payment transaction by, for example, swiping or dipping a credit card or receiving an NFC payment. The merchant device 101 can then transmit payment transaction through the merchant-acquirer 102 to the issuer processor server 103 (step 403) and to CCS server 104 (step 405). The CCS server 104 can then decide whether to authorize payment based on user instructions and account balances (step 407). If the CCS server 104 authorizes the transaction, it can simultaneously update the copy of the account balance stored in one of databases 107a-n (step 413), transmit a message to update the account balance stored at the system of record server 105 (step 415), and transmit an authorization message to the merchant device 101 (step 417.) If the CCS server 104 declines the transaction, it can send a decline message to the merchant device 409 and a message to the client device 1 15 to notify the user of the decline of the transaction. The user can optionally not receive a message or receive information about why the transaction was declined.

[0078] FIG. 5 illustrates a conversational view of a GUI for viewing a summary of financial transactions, including credit and debit transactions, that occurred in a "main account" according to label 509, e.g., the account or a sub-account. The conversational view can be presented on the client device 1 15. The conversational view includes items or transactions from two or more parties and can identify parties to the item or transaction. The user can request to view a summary of transactions in a conversational view, such as illustrated in FIG. 5. Upon receiving such a request, the client device 1 15 can retrieve a list of all transactions, or a subset of all transactions, from memory in client device 1 15 or server 104 and databases 107a-n. In one embodiment, the conversational view can include interface elements, such as light gray and dark gray bubbles or polygons embedding text or graphical account summary information, one color for each respective party. However, rather than having two parties, the conversational view of this disclosure can include multiple parties associated with the same color. In the example of FIG. 5, the credits can appear in bubbles aligned on a right side of the GUI (e.g., as a right column) and debits can appear in bubbles on aligned on a left side of the GUI (e.g., as a left column). In some embodiments, all credits can have the same color and all debits can have the same color, but different from the color used for credits. However, other embodiments are possible, such as a two-column conversational view with large amounts (e.g., over $100) appearing on one side or the other. Another embodiment could place transactions initiated by third parties on one side, such as credits or charges, and the other side could be transactions initiated by the user, such as transferring funds to sub-accounts or to a third party. Alternatively, transactions involving predefined parties can appear on one side or the other. Some embodiments can allow the user to configure which transactions appear on which side of the GUI. Continuing with the example of FIG. 5, credit 501 ("$100 - money from Susan") and credit 503 ("$50 - money from Sam") appear in bubbles on the right; the right bubbles can have a different color from the bubbles on the left. Debit 505 ("$14.76 - lunch at Restaurant") and debit 507 ("$2.79 - Coffee at Shop") appear in bubbles on the left of the GUI. Transactions 501-507 in FIG. 5 can also optionally contain timestamps for when they occurred. Note that the bubbles or polygons can be other shapes, such as ovals, clouds, or rectangles.

[0079] Alternative embodiments allow for credits and debits to have multiple colors to signify additional information, such as who originated the transaction, the type of party (e.g., restaurant or grocery store), transactions over a predetermined amount (e.g., $100), which subaccount processed a transaction.

[0080] Additional messages that can appear in the conversational view include reminders to pay bills, notifications that there are insufficient funds to satisfy a recurring payment, or that there will be insufficient funds to satisfy a recurring payment based on a predicted balance. The server 104 can also repeat certain messages other than credits and debits that are deemed important. For example, reminders to pay bills, notices of insufficient funds, messages from third parties, balance updates, notices of upcoming payments, notices of recurring payments, or any other messages that users may deem important. The server 104 may also allow users to modify which types of messages are important in their profile. Users might want repeated reminders of certain notifications, such as to pay the rent or electricity bill. The server 104 can allow users to program their profiles to repeat such notifications. Users may also select certain messages to select to be reminded about the notification again later, e.g., 1 hour, 1 day, or one week. If a user receives a notice that there are insufficient funds to make a payment, the server 104 can automatically generate a reminder to make the payment when the account or sub-account is sufficiently funded to make the payment. For example, whenever server 104 detects a credit, it can determine whether there are any upcoming or past-due debits, and, if the credit is large enough, notify the user that they now have sufficient funds to pay for the debit. [0081] Users may scroll through their messages to see past notifications or future messages by, for example, swiping up, swiping down, or refreshing the GUI. Past notifications may also change based on events that occurred after server 104 generated the notification. For example, if server 104 generates a notification that rent is due, and the user pays the rent, then the server 104 can modify the notification that rent is due to clarify that rent is no longer due. Alternatively, the server 104 can simply identify that the rent was paid and delete the reminder to pay rent. Other examples include if a predicted balance is going to fall below a predetermined amount. If that is no longer true because the account or sub-account received a credit, then the server 104 can modify or remove the notification to state that the predicted balance will no longer fall below the predetermined amount.

[0082] Users may interact with the user interface elements or notifications to get additional information or modify the transaction. In the example of FIG. 5, the user may be able to select (e.g., touch, click, and tap) transaction 501 to see which sub-account the $100 was applied to, or to change the sub-account that the $100 was automatically applied to based on predetermined rules. Other information that the user may receive by clicking on transaction 501 can include the method of payment, e.g., payment card, bank account, or cash balance. Alternatively, server 104 could deliver a list of transactions that also occurred with Susan, who sent the $100. Similarly, for transactions 505 and 507, which are debits, the user may select either of those transactions to learn similar information, such as the particular sub-account used to pay the debit, other transactions associated with that third party, date/time of transaction, etc. The user may also be able to change the account used to pay the debit. For instance, if the $14.76 for lunch in transaction 505 was accidentally paid for out of a vacation savings sub-account, the user could change the sub-account used to pay for the lunch to a more appropriate sub-account, such as a budgeted amount for food for the month.

[0083] In some embodiments, the notifications in the conversational view can be time- ordered, i.e., appear in a temporal sequence. In other embodiments, the notifications in the conversational view can be in a contextual sequence, e.g., notifications related to coffee shops, restaurants, or funds transfers between friends. The contextual sequence can depend on parties to a transaction, MCC code, type of transaction, etc. [0084] The GUI of FIG. 5 further includes a "Menu" button 511 and an "Edit" button

513. The "Menu" button 511 can allow the user to view a list of sub-accounts to view transactions or messages associated with the sub-accounts. The "Edit" button 513 can allow a user to edit transactions by, for example, moving the transaction to a different sub-account. In this example, each transaction was processed using the main account. The user can select the "Edit" button 513 for any transaction, such as "$100 - money from Susan" to a sub-account, such as "Vacation." In this way, the user can save the $100 towards a vacation. The user can use button 519 to take pictures of receipts used for transactions. Sometimes merchants do not breakout what a payment amount was for. For example, for transaction 505, part of the $14.76 amount could have been used to purchase merchandise. The user may want to maintain a copy of the receipt associated with transaction 505 to record what exactly the $14.76 was spent on for business, tax, or accounting purposes. The user can click the button 519, take the picture, then select the transaction associated with the photograph. In the alternative to the "Edit" button 513, the user can select specific transactions by, for example, touching them associated interface elements, e.g., polygons, to get more information about the transaction or to edit the transaction.

[0085] The GUI of FIG. 5 also includes an input field 517 and send button 515 at the bottom of the GUI. A user could, for instance, send money to a third party or record a note in the account using the input field 517 and send button 515. To send money, the user could insert an identifier of the third party, such as a "cash tag," described further below, or email address, and an amount to send or request a sum. The conversational view of the GUI of FIG. 5 could be updated to reflect that message, and the amount, whether a credit or debit, would go to or come from the main account as identified by label 509. For example, the message could be "$50 sent to Bob" or "$50 requested from Chris." The messages could be updated, either via color change or notation, that Bob received the money or Chris paid the money upon completion of those events. Alternatively, each update could be stored as meta data in one of databases 107a-n, and the user could retrieve the meta data by clicking on the associated transaction to see the transaction status, e.g., scheduled for payment pending, completed, or money sent. Note that the status can be implied by the color of a polygon corresponding to the transaction, e.g., each status corresponds to a unique color. Other meta data that can be stored in a record in the database includes time of payment, payment due date, date payment was received, date payment was retrieved, method of payment, payee profile information, payor profile information, bank information, account numbers, sub-account identifiers, transaction status, method of payment, interest rates, type of currency, exchange rates, and expiration dates.

[0086] In some embodiments, all transactions will appear under the "Main Account" because every transaction affects the balance of the "Main Account," i.e., the account at bank 116. However, the user may select that only transactions that are not associated with a subaccount appear under the "Main Account." In addition, each sub-account can have different transactions in their respective conversational views to ensure that only transactions associated with the particular sub-account are reflected in its respective conversational view.

[0087] The client device 115 can have software installed on it to present the conversational view, either using an API native to the particular operating system {e.g., iOS or Android) or use proprietary functions to produce the conversational view. However, the information presented in the conversational view can come either from a database of transactions stored on the client device 115 or in one of databases 107a-n. The information and the behavior performed by clicking on a transaction in the conversational view is further controlled by the client device 115 in communication with server 104 through API 114 over user-facing networks 111. The client device can store a subset of all transactions that have occurred, but the server 104 maintains a record of all transactions processed using all accounts.

[0088] Server 104 can automatically identify recurring payments. For example, if the user pays the same amount of money on substantially the same day each month, then server 104 can identify that as a recurring payment. The recurring payment might be $700 for rent and appear around the 10th of the month. After a predetermined number of times for that payment appearing, the server 104 can record the recurring payment in one of databases 107a-n and expect a similar payment in every month. In this way, the server can predict a balance by subtracting all recurring payments from the current account balance. The same can be done for credits. If the user receives a $2,000 credit in the middle and at the end of each month for a paycheck, the server 104 can record a recurring credit and expect that recurring credit each month. This can be added to the current account balance to predict a balance.

[0089] Other embodiments can find that two or more transactions match, even if they are not exactly the same, e.g., certain parameters such as payees or amounts differ slightly. For example, a user might have a recurring payment for rent that includes incidentals, such as utilities, and therefore the rent payment may vary by within $50 dollars; however, the majority of the payment remains largely the same. The server 104 can still identify that the payments are sufficiently related by identifying that the payments were made at roughly the same time of month for roughly the same amount, within certain predefined thresholds, e.g., $50 or 5 days, respectively. In another embodiment, the server 104 can allow different payees to receive the payment. If a user pays different payees each month, but the amount and time of payment are within the predefined thresholds, then the server 104 can also identify those payments as related or recurring. When the server 104 identifies a potential recurring transaction, the server can assume that it is recurring or query the user to verify that the transaction will indeed recur.

[0090] Users can also identify financial transactions as recurring. For example, in the conversational views of FIGS. 5 and 6, the user can configure a recurring financial transaction with the server 104. The server 104 can then expect similar transactions in the future. If the financial transactions differ slightly, the server 104 can average them together or take the most recent transaction to predict what amount and time of the next recurring transaction will be. The transaction might not be the same because the amount could be an average of prior similar transactions and the future transaction will occur on a different date from the past transactions.

[0091] Once the server 104 identifies a recurring transaction, either automatically or via user input, the server 104 can query the user about whether the user wants to create a scheduled transaction, e.g., a scheduled payment of the recurring transaction, such that the user does not need to make any further input before the server 104 executes payment of the recurring transaction. A user can generate a transaction request using client device 115. The server 104 can schedule financial transactions for payment, including recurring transactions, in response to the transaction request. Users can also submit a transaction request to schedule financial transactions for one-time payment. Such a request can include a future date of payment, a payee, and a subaccount identifier corresponding to the account or sub-account to process the payment from. The server 104 can similarly ensure that there are sufficient funds in accounts used to pay the scheduled financial transactions, and notify the user if there are insufficient funds.

[0092] FIG. 6 illustrates an example of using the predicted balance. In this example, the user receives a payment request 601 for $150. This can happen when, for example, a friend asks for a $150 payment. Either in response to the payment request or due to a period of time passing, the server 104 can generate a predicted balance message 603. The predicted balance message 603 includes the date 7/6/18 when the predicted balance is $25. The user may use this information when deciding whether to satisfy the $150 payment request.

[0093] Server 104 can make adjustments or provide notifications based on the predicted balance. For instance, a user can set up automatic bill pay such that the phone bill should be paid after the 10th of each month but before it is late, and server 104 is familiar enough with the user's transaction history to avoid automatically paying the bill until the user is paid sometime between the 10th and the 15th each month. For instance, if a recurring or automatic payment will create a negative balance in the future, server 104 can postpone payment or notify the user that the predicted balance will be less than some predetermined amount (e.g., $0) at some point in the future, so the user can take steps to ensure that important payments are made or deposit more funds in their account to avoid an overdraft. The server 104 can also allow the user to modify the predetermined amount. For example, the user may want a notification if their balance is ever predicted to go below $100.

[0094] The server 104 can predict balances on any time scale based on stored recurring transactions. Irrespective of the period of the recurring payments (e.g., weekly, monthly, bimonthly, yearly), the server 104 can predict a balance based on how many recurring transactions will occur between the current time and a selected future time.

[0095] Alternatively, the server 104 can modify payment dates based on the predicted balance. If the predicted balance is below the predetermined amount, server 104 can attempt to rearrange payments to avoid dropping below the predetermined amount. In the example above, a phone bill of $50 is due on the 20th, but the user typically pays it on the 10th. If server 104 predicts that this will cause the account balance to drop below the predetermined amount, then the server 104 automatically postpone or prompt the user to consider postponing the payment until after the 20th to avoid having the balance drop below the predetermined amount.

[0096] FIG. 15 includes exemplary pseudo code for two subroutines. The first is named

"is recurring," and is an exemplary method for determining whether a transaction is recurring. The server 104 can compare the current incoming transaction to all previous debit or credit transactions to see whether the transaction matches a previous transaction. The comparison between transactions can use an overloaded comparison method for determining whether two transactions match. The overloaded method can assess time of transaction, number of recurrences, amounts, etc. to determine whether the transactions match. To determine whether there is a match, the server 104 can compare transaction data to determine whether they are sufficiently similar. For example, if the dates are sufficiently similar to the same day of the month within a predetermined number of days, e.g., 5 days; if the amounts are sufficiently the same within a predetermined amount, e.g., $50 or 10%, or if the payees or payors are the same. The server 104 can take any combination of the parameters, such as if there are one, two or three matches, then that can mean that the transactions are sufficiently similar. Other transaction data can similarly be checked, such as MCC code, account numbers, addresses, and payment types. If the there is a match, then the server 104 can create a new recurring transaction using a make recurring method, which can generate a predicted debit or credit transaction or potential transaction, comprising transaction data, such as amount, date, and payee/payor, which can be stored in one of databases 107a-n and used to predict a balance. The server 104 can also remove recurring transactions if they do not in fact occur, therefore the predicted transactions will only potentially occur. For example, if a user moves and no longer pays rent, the server 104 can expect a recurring payment to be made, but does not see it, and therefore can prompt the user to approve removing that recurring payment.

[0097] FIG. 15 also includes exemplary pseudo code for a second subroutine,

"predict balance," to predict a balance based on a future date. The subroutine can receive as an input a future date at which to predict the balance. The subroutine can then sum the current balance and all future recurring transaction data or potential transaction data that could occur between the present time/current date and on or before the future date to predict balance to produce a summed balance. The summing can be accomplished by adding positive numbers corresponding to credits and negative numbers corresponding to debits. Alternatively, the server 104 can subtract debits rather than add negative numbers, as the operations are mathematically equivalent.

[0098] The server 104 can also optionally run the predicted balance subroutine any time the user attempts to process a debit transaction to make sure that the predicted balance will not run below a predetermined threshold value, e.g., $100 or $0. The server can do this for the entire account balance or only the amount allocated to a sub-account used to complete the debit transaction. If the predicted balance will drop below the threshold amount, the server 104, or the client device 115, can issue a notification to the user to confirm the transaction and notify the user of the possibility that the balance will drop below the predetermined threshold value. The server 104 can either deny the transaction or allow the user to proceed at their option.

[0099] The predictive balance can also be an input to a financial health calculation. For instance, if a user is living "paycheck-to-paycheck," i.e., does not have a growing balance and frequently returns to near $0, this is a signal of poor financial health. Conversely, if a user is able to maintain a large balance or a growing balance, then the server 104 can generate a higher financial score. The scores can be numerical, e.g., 1-10 or color-coded, e.g., red, yellow or green. The scores can be associated with the main account balance or sub-account balances. In this way, a user can have a financial score associated with each sub-account and their main account. The user may optionally enable or disable the financial score for any account. When establishing a sub-account, the server 104 can query the user about whether they would like the financial health of the sub-account scored.

[00100] Server 104 can use other inputs to calculate the financial score. For instance, if the server 104 expects to receive a recurring paycheck, but it does not, then the server 104 can lower the financial health score because funds are being depleted without being replenished. Server 104 can also use data science, heuristics, and statistics in determining and weighting inputs to the financial score. For example, if the user routinely is capable of making payments, then they will have a higher financial score.

[00101] While the sub-account identifier was previously described as a character string, there are other examples. For instance, cash tag identifiers can be used as an account identifier, sub-account identifier, or "payment proxy." Cash tag identifiers can simplify transfer of funds between a sender and a recipient by use of a tagging mechanism. As used herein, the term "tagging" refers to a marking of an alphanumeric character (or a string of alphanumeric characters) to identify it (i.e., the character or string) for treatment in a specified way. Briefly described, the cash tag identifier enables a sender, who desires to send cash to a recipient, to trigger a money transfer by specifying, in any communication message, an amount and a recipient using one or more inputs having a particular syntax. The syntax includes a monetary currency indicator (or "currency indicator") prefixing one or more alphanumeric characters. The currency indicator operates as the tagging mechanism that indicates to a computer system to treat the inputs as a request from the sender to transfer cash, where detection of the syntax (which includes one or more alphanumeric characters tagged by a monetary currency indicator) triggers a transfer of cash. The currency indicator can correspond to various currencies, e.g., dollar ($), euro (€), pound (£), rupee (Z), yuan (¥), etc. Although use of the dollar currency indicator ($) is used herein, the system could equally use any currency symbol.

[00102] In addition to the credit and debit examples discussed previously, cash tag identifiers provide efficient execution of other financial transactions {e.g., payment transfers between two users) by enabling a sender to trigger a money transfer using the syntax in any communication message. In particular, the sender can specify, in a communication message, an amount of money to transfer by including an input having the syntax, where the input can include the monetary indicator and one or more numeric characters {e.g., $10). In some instances, the sender can also specify, in the communication message, the recipient to whom the sender intends to send the money by including another input having the syntax. The input can include the monetary indicator and one or more alphabetic and/or numeric characters {e.g., $alex or $alexl23). Such input identifying the recipient is referred to as a "payment proxy" in this description, as shorthand.

[00103] FIG. 7 illustrates an example of a network-based environment in which some embodiments of the cash tag identifiers can be implemented. The embodiments illustrated in FIG. 7 include a client device 702, a server 708 of a third-party web content provider, a computer server system of a third-party application service ("application server 706"), and a consumer computing system 713, all of which are in communication over a user-facing network 711. In some embodiments, the CCS 713 includes one or more servers 704 and an Application Programming Interface API 714 ("API 714"). The one or more servers 704 are typically equipped with, or are coupled to, one or more databases 707a-707n, which can include one or more hard drives, a centralized or distributed data cluster, a cloud-storage service provider, or other suitable storage systems suitable for storing digital data. Items 704, 707a-707n, 711, 713, and 714, can be similar to those components illustrated in FIG. 1. [00104] In other embodiments, the environment can have more or fewer components than shown, or a different configuration of components. The various components shown in FIG. 7 can be implemented by using hardware, software, firmware or a combination thereof, including one or more signal processing and/or application specific integrated circuits. Further, the environment of FIG. 7 can be implemented based on other architectures in other embodiments. For example, in some embodiments, the API 714 can exist separately from the CCS 713, e.g., as part of the server 704 or the application server 706, or as a standalone server (e.g., a standalone API server in communication with the server 704, the application server 706, and the servers 704). In another example, in some embodiments, functions of at least some of the servers can be consolidated.

[00105] The network 711 can include any combination of local area and/or wide area networks, using both wired and wireless communication systems. In some embodiments, the network 711 uses standard communications technologies and/or protocols. Thus, the network 711 can include links using technologies such as Ethernet, 802.11, worldwide interoperability for microwave access (WiMax), 3G, 4G, CDMA, digital subscriber line (DSL), etc. Similarly, the networking protocols used on the network 71 1 may include multiprotocol label switching (MPLS), transmission control protocol/Internet protocol (TCP/IP), hypertext transport protocol (HTTP), and/or file transfer protocol (FTP). Data exchanged over the network 711 can be represented using technologies and/or formats including hypertext markup language (HTML) or extensible markup language (XML). In addition, all or some links can be encrypted using conventional encryption technologies such as secure sockets layer (SSL), transport layer security (TLS), and Internet Protocol security (IPsec).

[00106] The client device 702 can be any processing device capable of receiving user input as well as transmitting and/or receiving data via the network 711 by using a transceiver, e.g., one or more input/output devices for communicating over network 71 1, such as an Ethernet or WiFi adapter. In some embodiments, the client device 702 can be a conventional computer system {e.g., a desktop 702 A or a laptop computer 702B) or a mobile device having computer functionality {e.g., a tablet device 702C, a smartphone 702D, or a conventional mobile phone (not shown)). The client device 702 typically includes a display that can be used to display a user interface, and may include suitable input devices (not shown for simplicity) such as a touchscreen, a keyboard, a mouse, or a touchpad. In some embodiments, the display may be a touch-sensitive screen that includes input functionalities.

[00107] The client device 702 can be configured to communicate via the network 71 1 with the server 704 and/or the application server 706. In some embodiments, the client device 702 can retrieve or send information to the server 704 and/or the application server 706, and run one or more applications with customized content retrieved from the server 704 or the application server 706. For example, the client device 702 can execute a browser application to enable communication between the client device 702 and the server 704 (e.g., to access a social networking website). In another example, the client device 702 can execute a customized client to enable communication between the client device 702 and the application server 706. For example, the customized client is a messaging application operated by a messaging server. The customized client can further provide a channel of communication between respective client devices of a sender 740 and a recipient 742 (e.g., a channel that enables transmission of one or more electronic messages including, e.g., text, audio, and/or video). For example, the customized client enables an instant exchange of electronic messages between the respective client devices. Other example messaging applications and/or messaging servers can include an email application and email server or a social networking messaging application and a social networking server.

[00108] In accordance with various implementations of the cash tag identifiers, the sender

740 can utilize a given client device 702 to trigger a money transfer to a recipient 742. For example, by accessing a landing page with the client device 702, the sender 740 can submit an amount of money to the recipient 742 that is associated with the landing page. In another example, the sender 740, using the client device 702, can transmit a message to the recipient (e.g., via a chat application or a forum), where that message includes an indication of an intent of the sender 740 to send money to the recipient through use of a specified syntax for one or more inputs in that message. The recipient 742 can similarly use another given client device 702 to receive the money, for example, by interacting with a confirmation link sent to the client device of the recipient 742 as a result of the money transfer triggered by the sender 740.

[00109] In an alternative embodiment, sender 740 can have an account maintained at the server 704, which can host a website that includes one or more graphical user interfaces (GUIs) for organizing and presenting content to users. For example, through the system website, users create account logins to connect to their social identities (e.g., social profiles or social accounts or shopping accounts), read content (e.g., messages, comments, posts), create or post content, communicate in real-time with other users (e.g., chat, post messages, comment on posts, etc.), and/or otherwise engage or interact with other users of the system website (e.g., "friends," "followers," "social contacts," or other types of social network connections). In some embodiments, the user interactions on the system website lead to internal API communication, which involves the server 704 monitoring the user interactions for an indication of an intent to transfer money, e.g., by parsing messages at the system website. In response to such indications, the server 704 can transmit one or more requests (e.g., POST or GET requests) to the API 714 of the server(s) 704 to query the database(s) 707a-707n, and display the data returned by the API 714 of the server(s) 704 as appropriate. The server 704 can determine the indication of the intent based on an identification of a user input, e.g., a string of characters, that has a particular syntax, the syntax being a monetary indicator preceding one or more alphanumeric characters. The user input having the syntax operates as a trigger to send money to a particular recipient (e.g., recipient 742). The recipient can be identified based on a user input with the syntax (e.g., payment proxy represented by the user input), or based on a user account of a user currently accessing the system website (e.g., login credentials).

[00110] In one example, the server 708 monitors user messages on the system website for any particular message that includes a user input having the syntax of the monetary indicator preceding the alphanumeric characters, and forwards a request to the API 714. In such an example, the server 704 can identify the syntax by parsing the user messages to find, for example, a message that includes the syntax, and further parses that message to identify a payment amount and a payment proxy, and forwards such information to the API 714 and/or the server 704 to process the money transfer. In some embodiments, the server 704 parses the user messages simply to identify any message with input(s) having the syntax, and forwards that message to the server 704 via the API 714. In such embodiments, the server 704 can receive the message and can parse it for a payment proxy (e.g., one or more alphabetic characters of the user input having the syntax) to identify a recipient associated with the payment proxy. Upon identifying the recipient, the server 704 can identify an associated recipient financial account or sub-account based on the identifier or payment proxy, and initiate a money transfer to that recipient financial account. In some embodiments, the API 714 (e.g., instructed by the server 704) can also send back, in a response to the server 704, appropriate data for display to the user. For example, the data can be an HTML string that displays a confirmation message with a link for prompting the sender to confirm his/her intent to transfer money to the recipient associated with the payment proxy. In some embodiments, the server 704 sends a confirmation message to the sender using information included in the request received from the server 704, e.g., an identifier associated with the sender. For example, the identifier can be an email address of the user, and the server 704 (e.g., via an email server) sends an email message to the user's email address.

[00111] The application server 706 supports an application (hereinafter, "system application") that includes one or more graphical user interfaces for organizing and presenting content to users. The system application can be a mobile application installed on a mobile device or a conventional software application installed on a conventional personal computer. Users can utilize the system application to interact with other users. The system application can be a messaging application. For example, through the system application, users create account logins to connect to their social identities (e.g., social profiles or social accounts or shopping) to communicate with other social identities, read messages, create or post messages, communicate in real-time with other users (e.g., chat), and/or otherwise engage or interact with other users of the system application (e.g., "friends," "social contacts," or other types of social network connections). In some embodiments, the user interactions on the system website lead to internal API communication, which involves the application server 706 monitoring the messages for an indication of an intent to transfer money, e.g., by parsing messages at the system application. In response to such indications, the application server 706 can transmit one or more requests (e.g., POST or GET requests) to the API 714 of the server(s) 704 to query the database(s) 707a-707n, and display the data returned by the API 714 of the server(s) 704 as appropriate. In some embodiments, the system application performs the parsing. Upon identifying the syntax, the system application can notify the application server 706 of the indication of the intent to transfer money. Alternatively, in some embodiments, the system application notifies a payment service application executing on the user' s device of the indication, where that payment service application communicates with the servers 704 via the API 714. [00112] In one example, the system application monitors at the user device (e.g., client device 702 of the sender 740) for any particular message that includes a user input that has the syntax of the monetary indicator preceding the alphanumeric characters. Upon identifying such a message, the system application notifies the application server 706, which transmits a request to the API 714 that includes, e.g., the message and an identifier associated with a creator of the message (e.g., an email address), for the API 714 and/or the server 704 to process the money transfer. In such an example, the server 704 can parse the message for a payment proxy (e.g., the user input having the syntax) to identify a recipient associated with the payment proxy. Upon identifying the recipient and an associated recipient financial account, the server 704 initiates a money transfer to that recipient. In some embodiments, the system application communicates with a payment service application executing at the user' s device via an API call (e.g., through API server 714). The payment service application can then further parse the identified message having the syntax to identify an amount of money for the transfer and a recipient for the transfer (e.g., payment proxy). The payment service application can communicate this information to the server 704 (e.g., via the API server 714), which processes the money transfer based on this information. In some embodiments, the payment service application forwards the message to the server 704, which performs the additional parsing to identify the amount of money and the recipient.

[00113] In some embodiments, the API 714 (e.g., instructed by the server 704) can also send back appropriate data relating to the money transfer for display to the user at the system application. For example, the data includes text that can be incorporated in, e.g., a push notification, that displays a confirmation message with an action link for the user to confirm his/her intent to transfer money to the recipient associated with the payment proxy. In some embodiments, the server 704 sends a confirmation message to the user using information included in the request received from the application server 706, e.g., an identifier associated with the user. For example, the identifier can be a telephone number of the user, and the server 704 sends a text message to the user' s phone number.

[00114] The CCS 713 can be a cloud computing environment, a virtualized computing environment, a computer cluster, or any combination thereof. The CCS 713 includes a payment processor (not shown) configured to process money transfers conducted between a sender and a recipient identified by a payment proxy. As discussed briefly above, the CCS 713 includes the one or more servers 704. The payment processor can be a part of the one or more servers 704, and can work in coordination with the API 714 to exchange requests and responses with the server 704, the application server 706, and/or the payment service application associated with the CCS 713 to process one or more transactions triggered by use of the syntax (e.g., money transfers). The one or more servers 704 can handle secure transactions (e.g., using a secure server), to process all payment transactions triggered.

[00115] In general, the servers 704 store secure information such as credit card numbers, debit card numbers, bank accounts, user accounts stored in one of databases 707a-707n, e.g., payment proxies associated with users, user identifying or profile information, financial account information, or other sensitive information. Each user account can be associated with one or more card accounts of the user, e.g., debit or credit card accounts. A card account can be a financial account managed by a card issuer (e.g., a card issuer 732) and can be associated with the card number. In some embodiments, the one or more card accounts are stored at the server 704 (e.g., at the databases 707a-707n). Generally, the card issuer issues a physical payment card for each card account.

[00116] In some embodiments, the CCS 713 includes a payment service application server (e.g., a server of the servers 704) that supports a payment application for executing various services provided by the CCS 713. The payment service application includes one or more graphical user interfaces for presenting content and processing user requests. The payment service application can be a mobile application (e.g., "mobile payment application") installed on a mobile device or a conventional software application installed on a conventional personal computer. For example, through the payment service application, users create account logins to utilize financial services offered by the CCS 713, to link their financial accounts with the consumer computing system 713 (e.g., registration with the CCS 713), to transfer money using their user accounts and/or financial accounts, and/or otherwise engage with the services offered by the CCS 713 via the payment service application.

[00117] To process payment transactions, the CCS 713 can communicate with one or more financial networks. In some embodiments, the CCS 713 can communicate with a computer system of a card payment network 620, e.g., a debit card payment network (e.g., STAR or PULSE) or a credit card payment network (e.g., Visa® or MasterCard®), (collectively, "card payment network 720"). In some embodiments, the CCS 713 can communicate with the card payment network 720 over the same user-facing network 711, or a different network. In one example, the card payment network 720 can communicate, in turn, with the computer system of a sender card issuer 722, e.g., a bank, and a computer system of a recipient card issuer 724, e.g., a same or different bank. The sender card issuer 722 and the recipient card issuer 724 can transfer money, e.g., over a debit payment network, in response to a request to transfer money from the CCS 713.

[00118] In some embodiments, the CCS 713 can communicate with a computer system of an ACH network 730. The computer system of the ACH network 730 can communicate with a sender card issuer 732 and a recipient bank account 734. The sender card issuer 732 and the recipient bank account 734 can transfer money, e.g., using the ACH network, in response to a request to transfer money from the CCS 713. In other embodiments, there can also be computer systems of other entities, e.g. the card acquirer, between the CCS 713 and the card issuers, and between the CCS 713 and the bank accounts.

[00119] In some embodiments, the CCS 713 can transfer money between bank 716 and one or more of the recipient accounts on card payment network 720 and ACH network 730. The transfer of funds occurs similar to that illustrated in FIG. 3. In a first direction, a sender having an account at bank 716 can initiate a payment transaction to a recipient with an account over the card payment network 720 or the ACH network 730. The sender's account would be debited according to FIG. 3; however, the recipient's account would be credited in accordance with the processes associated with the respective networks. In the other direction, a sender with an account on card payment network 720 or ACH network 730 can begin a payment transaction by sending money to a recipient with an account at bank 716. System or record 705 can maintain the account in database 710. The sender would send the funds using the protocols associated with either card payment network 720 or ACH network 730, whereas the recipient would receive the funds in accordance with FIG. 3. In this way, server 704 can coordinate transactions between account holders having several different types of accounts.

[00120] In accordance with various embodiments, a payment transaction (e.g., a transferring of money) can originate at a device of the sender 740 ("sender device"), such as the desktop 702A. For example, the sender 740 can initiate a payment transaction by using the sender device to access and/or interact on a forum, such as a microblog hosted by the server 704. Alternatively, the sender 740 can initiate, for example, the payment transaction by using the sender device to access a landing page that is associated with a personalized URL, which incorporates a payment proxy of the recipient 742. In another example, the sender 740 can initiate a payment transaction by using a sender device to access an application such as a messaging application supported by the application server 706. In yet another example, a user can initiate a payment transaction by using a sender device to access an application such as the payment service application supported by the CCS 713.

[00121] The CCS 713 can process the payment transaction on behalf of the user. Processing the payment transaction involves identifying a financial account of a sender user and a financial account of a recipient user (e.g., by accessing the databases 707a-707n of the CCS 713).

[00122] In accordance with various embodiments of the disclosed technology, the financial account of the recipient user can be identified based on a payment proxy associated with the recipient user. For example, the recipient user may have previously created a payment proxy (e.g., $redcross) to be used with a service provided by the CCS 713 (e.g., a money transfer service), and entered financial account information through a GUI (e.g., an interactive payment receiving interface) of the payment service application of the CCS 713. In this example, the CCS 713, in turn, associates the financial account information with the recipient user' s newly created payment proxy in this registration process. In other words, upon submission of information by the recipient user, the CCS 713 automatically registers the financial account and the payment proxy with the CCS 713 on behalf of the recipient user. The recipient user can submit financial account information for one or more financial accounts. Associations of the one or more financial accounts with the recipient user's payment proxy can be stored on the CCS 713 (e.g., databases 707a-707n). Information of the financial accounts can be used for future payment transactions (e.g., money transfers).

[00123] In accordance with various embodiments of the disclosed technology, the financial account of the sender user can be identified based on identifier associated with the sender user ("sender identifier"). In some embodiments, the CCS 713 can receive the sender identifier from the server 704 or the application server 706. In some embodiments, the CCS 713 receives the sender identifier from the payment service application supported by the CCS 713.

[00124] The CCS 713 can identify a financial account of the sender user based on an association between that financial account and the sender identifier. For example, the sender user may have previously received payment (e.g., from another sender user) and entered financial account information through a GUI of the payment service application of the CCS 713 (e.g., an interactive payment receiving interface). In such an example, the CCS 713 may have identified the sender identifier of the sender user (e.g., via email sent to the sender user or text message). In turn, the CCS 713 stores the financial account information in association with the sender identifier newly created by virtue of accepting the payment from the other sender user (using the service provided by the CCS 713). The sender user can submit financial account information for one or more financial accounts. Associations of the one or more financial accounts with the sender identifier can be stored on the CCS 713 (e.g., databases 707a-707n). Information of these financial accounts can be used for future payment transactions (e.g., money transfers).

[00125] If no financial account information is identified for either the sender user or the recipient user, the CCS 713 can send a message (e.g., a financial account request message) to the respective user requesting that financial account information to be submitted. The message can be a confirmation message that includes a secure link to enter the financial account information, such as a debit card number or a credit card number and associated authentication information (e.g., expire date, ZIP Code, PIN number, or security code). For example, the respective user can simply input financial account information, such as a debit card number or a credit card number.

[00126] When the financial account information is identified for both the sender user and the recipient user (either initially or later submitted through the confirmation message), the CCS 713 sends a request to transfer money, e.g. via the card payment network 720, the ACH network 730, or the bank 716. In particular, to transfer money between the sender user and the recipient user (identified based on the payment proxy), the CCS 713 can operate as a gateway or a middleman.

[00127] To operate as a gateway, the CCS 713 can identify debit card accounts, e.g. stored at the servers 704, for both the sender user and the recipient user. The CCS 713 can submit a request to an appropriate card issuer e.g., to the sender user's card issuer or to the receiving user's card issuer, to transfer money. For example, the request can be sent over debit rails. That is, a debit card network can receive the request and can carry out the request to transfer money. The appropriate card issuer can receive and process the request by transferring money to the appropriate card account.

[00128] To operate as a middleman, the CCS 713 can receive a payment amount by processing a payment card, e.g., a credit card or a debit card, of the user sender and hold the payment amount. The CCS 713 can push the payment amount, e.g., over debit rails, to a debit account of the recipient user. Instead of holding the payment amount, the CCS 713 can also forward the payment once the recipient user links the account with the CCS 713. Alternatively, the CCS 713 can generate a transaction ACH that debits an amount from the sender bank account and can credit the amount into a recipient bank account, e.g., using ACH, or onto a debit account, e.g., over debit rails, of the recipient user. Alternatively, the CCS 713 can generate a transaction to system of record server 705 to either debit or credit an account stored at bank 616, according to a corresponding transaction over either card payment network 720 or ACH network 730.

[00129] While payment proxies can be non-hierarchical, such as $redcross, they can also be hierarchical. For instance, if several users want an account labeled $redcross, they can name the account hierarchically using, for example, their username, e.g., $JaneDoe/redcross and $JohnSmith/redcross. The account hierarchy can be multiple levels deep, such as $JaneDoe/redcross/syrianRefugees or $JaneDoe/redcross/japanEarthquake. Embodiments are not limited to a certain number of levels of hierarchy for payment proxies.

[00130] Sub-accounts can have other settings, such as reminders to save money or pay bills. In one embodiment, a sub-account can be used to save for a trip and have a deadline for saving a certain amount, with reminders at certain intervals, such as 6 months before, 3 months before, and 1 month before. Each reminder can state the progress of savings, such as the amount and percentage towards goal. Accounts can also have monthly reminders to contribute to savings, or automatically make those contributions. The ability to set up and configure sub-accounts, without having to visit a bank, gives users much more flexibility and efficiency than previously available. Placing server 104 between the issuer processor server 103 and the system of record server 105 enables this flexibility and efficacy, along with the programing structure to accomplish these goals.

[00131] Another goal is to pay bills and provide reminders to pay bills. Users can configure their sub-accounts to pay bills by inputting payment information, such as account and transit routing numbers to make an ACH payment at periodic intervals. For instance, a user may owe $1,000 each month for rent, and can configure a sub-account to be credited $1000 each month and debited $1,000 when rent is due. Alternatively, the user could manually perform either or both of these tasks. Again, this system provides the user with much more flexibility than previously available.

[00132] FIG. 8 illustrates another exemplary embodiment of a conversational view, similar to FIGs. 5 and 6. The embodiment of FIG. 8 includes a back button 801, which can allow a user to return to the previous menu or screen. This embodiment also includes a title 803,

"Activity," and includes a more options icon 805 ("···"), which can allow a user to see additional options for the screen that they are on. In this embodiment, the additional options can include an option to edit the activity, e.g., move transactions to different sub-accounts, remove transactions from the activity log, or make notes on the transactions. Alternatively, a user could select a transaction via, for example, a double-click, click, long-press, or hard press.

[00133] The conversational view of FIG. 8 can have a listing of several transactions. Each transaction can appear in a polygon or bubble, and can have information such as amount, transaction type (e.g., credit or debit parameter, or positive/negative amount), name of payee or payor, or a picture of the payee or payor. In this example, user-initiated transactions appear on the right, and third-party-initiated transactions appear on the left. Transaction 809 is a debit and states, "$35 at The Dutch," and can appear beside a picture of the user. Transaction 811 is a debit and states "$100.25 at AT&T," and appears besides a picture of the user. Transaction 811 also contains a "Recurring" indication, indicating that this is a recurring payment, such as a phone or internet bill. Server 104 could previously have identified payments to AT&T of similar amounts at the same time of month as recurring. Transaction 813 is another debit that states, "$20.50 for Wine." Transaction 815 can be a reminder that states, "remember your January rent is due in 2 days." Transaction 815 can further include dismiss button 817 to dismiss or remove the transaction from the conversational view. Transaction 815 can also include pay button 819, which can allow the user to pay the rent, which is discussed further in FIG. 1 1. The conversational view of FIG. 8 can also include transaction 821, which states, "You just received your paycheck!" Transaction 823 is a credit that states, "$40 for Uber," and further states that it is from Lauren and includes her picture.

[00134] FIG. 9 illustrates an exemplary embodiment of a notification related to an account.

Notification 901 from "Bills" states "Good morning, Erin! Yesterday your balance only went down by $5. Your new balance is $925.61." Bills can be the name of the application that runs on the user's device. Either the server 104 or the user device can automatically inform the user of their balance at a predetermined time each day, e.g., 9 AM. A user may be able to configure when and whether to receive a daily notification such as notification 901. FIG. 10 illustrates another exemplary embodiment of a notification using analytics. Notification 1001 is also from "Bills" and states, "You just received your paycheck! Your balance is now $2,035.20. Want to send your rent check now?" In this example, server 104 can compute and determine that the user did not have enough funds to pay a bill, e.g., the rent, prior to receiving their paycheck, and can therefore proactively remind the user to pay the rent once they receive their paycheck. The user can also request a reminder to pay the rent later. For example, in FIG. 8, the conversational view includes transaction 815 stating that rent is due. If the user presses dismiss button 817, the user device can display an option for a reminder, such as notification 1001, or can automatically generate a reminder such as notification 1001 after receiving the paycheck.

[00135] FIG. 1 1 illustrates an exemplary embodiment of a conversational view when the user clicks pay button 819 or after opening notification 1001. In either case, a window can appear that includes payment information, such as field 1 101 containing the amount of rent due, field 1 103 containing the address to send the rent check to, and field 1 105 containing shipping options for the payment. The shipping options can also include printing and mailing a check. Some embodiments can allow the user to click on any of these fields to edit them. For example, the user can select field 1 105 to change shipping or payment options to, for example, have the server 104 print and mail a check. Send button 1 107 can allow the user to complete the payment, possibly including printing and mailing a paper check, or doing an electronic funds transfer. The user can use cancel button 1109 to cancel rent payment and return to a similar screen as presented in FIG. 8.

[00136] FIG. 12 illustrates an exemplary embodiment of a notification using analytics.

Notification 1201 states, "Your June statement is complete! Your balance went up by $132.35 this month. See more details now." Similar to FIG. 10, the user can configure when, how, or whether to display notifications such as notification 1201.

[00137] FIG. 13 illustrates an exemplary embodiment of an account balance over time.

Field 1301 can contain a chart demonstrating a user's balance over a period, such as a month. In this example, field 1301 includes the balance over the month of June, and lists the starting and ending balances ("$610 to $742"). Field 1303 can contain a sum of all credits over the period, and in this example is labeled, "You Earned + $2,680.52." Field 1305 can contain a sum of all debits over the period, and in this example is labeled, "You Spent - $2,548.17." Field 1307 can contain the change in balance over the period of time, and in this example states, "You Saved + $132.35." Field 1309 can contain a listing of "Top Merchants" where the user spent the most money or had the most transactions. Arrow 131 1 can allow the user to return to the previous menu or screen. Share button 1313 can allow a user to email or post to social media their balance over time.

[00138] FIG. 14 illustrates an exemplary embodiment of analytics related to an account. Field 1401 can present the amount of funds the user spent in the month of April, i.e., -$688.49. Field 1403 can present the average amount the user spends in a month, i.e., -$4,350.34. Field 1405 can present the user's average income for a period of time, e.g., a month, and in this case presents +$6,402.86. Field 1407 can present the amount the user spends on certain categories or budget items; this example includes "Home & Utilities." Field 1407 further includes the amount spent on "Home & Utilities" in April, i.e., -$2385.52. Field 1409 can present the user's income in a month, i.e., +$100. Field 1411 can present a comparison spending between April and March in the form of a line graph. In this example, April is not over, so the graph of spending in April is incomplete. Field 1411 can also include the total amount of spending ($688.49).

[00139] Disclosed herein are systems and methods for real-time provisioning of new card numbers to users of a consumer computing system. A consumer computing system ("CCS") may have servers and databases situated within a banking infrastructure in order to provide various features to users via a software application executed by a client device. The software application may interact with the CCS servers, such that the CCS servers and the software application offer the client device and the user certain features not ordinarily available in conventional banking infrastructures. These features may include the real-time provisioning of card numbers for a user's banking account. In operation, the client device may submit a request for a new card number to a CCS server, which may be generated in real-time and active in the payment stream when the card number is generated.

[00140] Conventional monolithic financial systems required consumers to wait several days to receive a new credit or debit card in the mail. This is due to the manual or semi- automated fashion in which new card numbers were generated and the resulting cards were distributed. In conventional systems, consumers would request a new card from an issuing entity, usually a consumer-facing bank (e.g., Chase®, Bank of America®, Citi®), by mail or online. The issuing entity would then take several days to confirm whether to issue the card and then sends a physical card to the consumer. Once the consumer received the card, the consumer would have to activate the card, which is an additional step of the conventional process requiring the consumer to ask the issuing entity to activate and acknowledge the card number of the new card. In contrast, embodiments disclosed herein, and variations thereof, employ one or more servers of a consumer-facing computing system inserted and deployed within the conventional financial processing system, allowing the consumer computing system to tap into the financial processing system in a new way, thereby facilitating a number of consumer-oriented feature sets. For instance, by having the servers of the consumer-facing system inserted into the financial services stream where others were not previously, new card numbers may be generated and sent directly to an application at a consumer device (e.g., smartphone, tablet). When the card numbers are generated, they may be active and useable before the card number is even received by the consumer. Thus, the systems and methods disclosed herein may provision new card numbers for consumers in real-time, which may be useable by the consumer via their device, without needing to wait for physical card to arrive in the mail.

[00141] By extension, new security measures may be necessary to protect consumers from fraud, as the new card numbers are active by the time the consumer recieves the card number. To address this concern, the systems and methods disclosed herein may provide new server behaviors to protect consumers from fraud through improved, intelligent server behaviors, which were not previously possible because servers were not deployed into the financial services stream in this manner.

[00142] Example System Components

[00143] Payment System with Consumer Computing System (CCS)

[00144] FIG. 16 illustrates an embodiment of a system 1600 that includes several servers that handle various steps in a computerized system for tracking debit and credit transactions. The example system 1600 may comprise a plurality of entity systems associated and operated by various entities of the system 1600, including a merchant, merchant-acquirer, issuer processor, consumer computing system ("CCS"), host banking system working in collaboration with the CCS to provide user-oriented services, and core processor system. Each of the example entity systems may comprise any number of electronic devices (e.g., merchant computing devices 1601, server computers 1602, 1603, 1604, 1605, 1606) that execute the various processes described herein and networking devices that facilitate intercommunications between the various entities. One having skill in the art will appreciate that embodiments may comprise additional or alternative entity systems; and that some embodiment may omit or combine certain entity systems of the example system 1600 shown in FIG. 16.

[00145] Merchant Computing Device

[00146] A merchant computing device 1601 may be employed by a merchant to request payment authorization for a particular transaction. The merchant computing device 1601 may be any device capable of capturing payment request data from various types of payment instruments, and then transmitting payment authorization requests containing the request data to various components of a system 1600. Non-limiting examples of a merchant computing device 1601 may include a point of sale (POS) terminal, a credit card payment processing terminal (e.g., a credit card scanner), and a cash register. Non-limiting examples of payment instruments may include magnetic stripe cards, EMV cards, and virtual cards that may be stored on a client device 1614. As mentioned, the merchant computing device 1601 may comprise or may be coupled to various types of instrument readers configured to capture transaction data from certain types of payment instruments. For instance, if the payment instrument is a virtual card stored on a client device 1614, and the client device 1614 is configured to transmit payment request data for the virtual card using near field communications (NFC), then the merchant computing device 1601 may comprise or may be coupled to an NFC scanner configured to capture the transaction data related to the virtual card via the NFC signal received from the client device 1614.

[00147] In operation, a merchant computing device 1601 may capture payment transaction data, such as a card identifier (CID) or card number, and then transmit the payment transaction data to a merchant-acquirer server 1602. The merchant computing device 1601 may be configured to generate digital messages containing the payment authorization request and transaction data, which, in some embodiments, may be generated according to particular protocols or specifications. For example, the merchant computing device 1601 may generate a payment authorization request according to one or more ISO standards in which the payment authorization request contains certain fields of payment transaction data. Non-limiting examples of data fields that may be included the digital message may include a merchant identifier (merchant ID), a merchant category code (MCC), an amount for the transaction, a timestamp (e.g., data, time), and a card number. In some implementations, the merchant computing device 1601 may transmit the digital message to containing the card and/or other payment information to a merchant-acquirer server 1602, although in some implementations, the digital message may be transmitted to other devices, such as an issuer processor server 1603 of an issuer processor system.

[00148] Merchant-Acquirer

[00149] Merchant-acquirers may be financial institutions that process credit or debit card payments on behalf of a merchant. A merchant-acquirer may be configured to receive payments from banks that issue payment cards within a payment network entity (also referred to as a payment network association entity); examples of payment network entities may include Visa®, MasterCard®, Discover®, and American Express®. A merchant-acquirer server 1602 may be any computing device configured to communicate, over predetermined payment network rails 1617, digital messages containing payment transaction data to and from one or more merchant computing devices 1601, as well as transaction data to and from the issuer processor server 1603. In operation, the merchant-acquirer server 102 may perform one or more processes on the digital message, and forward at least some of the payment transaction data collected by the merchant computing device 1601 to the issuer processor server 1603 over the payment network rails 1617 of a particular payment network entity (e.g., Visa® or MasterCard® networks). In some implementations, the merchant-acquirer server 1602 may forward to the merchant computing device 1601 payment authorization response messages from the issuer processor server 1603, indicating whether the payment was authorized or declined.

[00150] In operation, the merchant computing device 1601 may capture payment card information and then generate and transmit a digital message, such as a payment authorization request, comprising the payment card information along with transaction data (e.g. , transaction amount, merchant identifier) to a merchant-acquirer server 1602. The merchant computing device 1601 may be configured to generate digital messages containing the payment authorization request, which includes the payment card information and transaction data, may be generated according to particular protocols or specifications, e.g. , one or more ISO standards in which the payment authorization request can contain certain fields for the payment card information and the transaction data. Non-limiting examples of data fields that may be included the digital message may include a merchant identifier (merchant ID), a merchant name, a merchant category code (MCC), an amount for the transaction, a timestamp (e.g., data, time), and a card number. In some implementations, the merchant computing device 1601 may transmit the digital message containing the card and/or other payment information to a merchant-acquirer server 1602, although in some embodiments, the digital message may be transmitted to other devices, such as an issuer processor server 103 of an issuer processor system.

[00151] Payment Network Association and Payment Network Rails

[00152] Payment network entities (e.g., Visa®, MasterCard®, American Express®) may be entities that operate payment network rails 1617, which may be a computing communications network configured to receive and transmit digital messages between and among merchant computing devices 1601 and merchant-acquirer servers 1602, as well as messages between merchant-acquirer servers 1602 and issuer processor server 1603. In operation, merchant computing devices 1601 and merchant-acquirer servers 1602 may generate, manipulate, and transmit digital messages containing payment transaction request messages and payment transaction data. The digital messages may be generated and manipulated according to the policies, standards, and protocols implemented by each particular payment network.

[00153] Issuer Processor

[00154] Issuer processor systems can establish payment card number records for customers, issue bills and statements, and process payments. The issuer processor server 1603 can perform these functions and store transactions and payment card numbers in a storage device, such as an issuer database 1615. Issuer processors will typically forward payment authorization requests to a core processor server 1605. However, the example system comprises a CCS server 1604 positioned between issuer processor server 1603 and core processor server 1605. Furthermore, the CCS server 1604 can perform some or all of the functions typically associated with issuer processors, and therefore, in these embodiments, the merchant-acquirer server 1602 can communicate over the payment network rails with the CCS server 1604. Although the issuer processor server 1603 and the CCS server 1604 are shown as separate computing platforms, the issuer processor server 1603 and the CCS server 1604 can be implemented as a single platform. The positioning of the CCS server 1604 between issuer processor server 1603 and core processor server 1605 allows the CCS server 1604 to provide added functionality to the system, such as intervene in and record transactions in the payment stream (e.g., intercept payment authorizations). As a result, the CCS server 1604 can also have access to all transactions associated with an account to provide further services to the client device 1614 associated with the account.

[00155] In some embodiments, the issuer processor server 1603 may be configured to generate a cryptogram token for a payment card number, according to various predetermined algorithms and requirements associated with a digital wallet application executed by a client device 1614. The CCS server 1604 may transmit a new payment card number to the issuer processor server 1603 after the CCS server 1604 generates the payment card number. In some instances, the CCS server 1604 may transmit a token that was generated by the CCS server 1604 to represent the payment card number, based on predetermined tokenization algorithms promulgated by the CCS server 1604. However, the client device 1614 may execute one or more digital wallet applications allowing the client device 1614 to securely store payment card numbers and conduct payment transactions using the client device 1614 instead of a physical payment card. The issuer processor server 1603 may generate the cryptogram token for the payment card, using the payment card number and additional input parameters, and may transmit the cryptogram token directly or indirectly (through the CCS server 1604) to the client device 1614 for storage and use in digital wallet-based transactions.

[00156] Host Bank

[00157] A host bank may be a third-party financial institution that works in collaboration with the CCS to provide various services to users through consumer-facing applications. The host bank system may have a bank server 1606 and bank database 1609. The bank server 1606 may communicate with a CCS server 1604 via one or more networks, and may be any computing device comprising a processor configured to execute the various processes and tasks described herein. In operation, the bank server 1606 may generate new bank accounts and may interact with the CCS, issuer processor system, and a core processor system to debit or credit the various bank accounts managed by the host bank system. The host bank may have a bank database 1609 that may store banking data for various accounts, including routing numbers, account numbers, and account ledgers, among other types of information. The bank server 1606 may generated and update records of the bank database 1609 based on new and updated account information received from the various entities, according to account update requests and transaction data.

[00158] In some embodiments, the CCS may have one or more accounts with the host bank and user funds may be deposited into the account, where user-owned monies are tracked according to ledgers and user records in a CCS database 1607. In such embodiments, the bank server 1606 may generate a routing number and account number for the CCS, and various forms of information about the CCS and transactions may be tracked in the bank database 1609. Users who use the CCS services to facilitate payments or for other services may deposit funds into the account of the CCS held at the host bank. The CCS server 1604 may update a record of the user in the CCS database 1607 to reflect the amount of user money held in the CCS account at the host bank. The bank server 1606 may update the amount of money in the CCS account reflected in the account data and ledgers stored in the bank database 1609, based on various transaction request messages received from the CCS server 1604. The CCS server 1604 may similarly update the amount of money belonging to the user in the CCS database 1607, based on various transactions. [00159] In some embodiments, the host bank may open and manage a financial account for each user registered in the CCS database 1607. In such embodiments, the bank server 1606 may receive instructions from the CCS server 1604 to open a new account for a user, when the user registers with the CCS services, in response to some other trigger or instruction received from the CCS server 1604. The bank server 1606 may execute one or more Know-Your- Customer (KYC) processes designed for collecting certain types of information about the user. In some cases, the bank server 1606 or the CCS server 1604 may generate one or more graphical user interfaces (GUIs) configured to receive user information from the client device 1614. And in some cases, the CCS database 1607 may contain the requisite KYC process data in a record of the user, which the CCS server 1604 may transmit to the bank server 1606. The bank server 1606 may generate one or more records for the user in bank databases 1609, which may include generating a bank account number for the user. The bank server 1606 may transmit the host bank account information for the user to the CCS server 1604, where the information may be stored into a record for the user in the CCS database 1607, identified by a user ID associated with the user.

[00160] Consumer Computing System (CCS)

[00161] A consumer computing system ("CCS") may comprise CCS servers 1604, which may be any computing device capable of performing various tasks and processes described herein. A CCS server 1604 may comprise a memory and a processor, whereby the memory comprises a set of computer-readable instructions that are executed by the processor. Although the CCS server 1604 is shown as a single server, it should be appreciated the functionality of a CCS server 1604 may be performed by any number of computing devices. In the example system 1600, a CCS server 1604 may be coupled to issuer processor servers 1603 and core processor servers 1605, such that the CCS server 1604 may be situated between the issuer processor system and the core processor system. As mentioned previously, it should be appreciated that in some embodiments the CCS server 1604 may be configured to execute tasks and processes of an issuer processor server 1603, such that the CCS may function as an issuer processor system. It should also be appreciated that in some embodiments the CCS server 1604 may additionally or alternatively be configured to perform various tasks and processes of a core processor server 1605, such that the CCS may function as a core processor system. [00162] Additionally, the CCS system may have one or more CCS databases 1607 that store records of users, account and transaction ledgers, and other forms of information. A CCS database 1607 may be hosted on the machine-readable storage of one or more computing devices, such as servers, laptops, and desktops, among other types of computing devices. The CCS databases 1607 may comprise or may otherwise be coupled to a CCS server 1604 via one or more internal networks (not shown), within the operational boundaries of CCS network devices.

[00163] A CCS database 1607 may include a user account database that stores user profile records containing data fields for various types of data; non-limiting examples of information stored in records of the user account database may include user identifiers (user ID), user payment card numbers, transaction data, bank account data, and machine-readable tokens representing payment card numbers, among other types of information about users and user accounts. In operation, a CCS server 1604 may generate and update a user record according to registration or demographic data received from the client device 1614 during a registration process; and according to transaction data received from the client device 1614 or other entities of the system 1600, such as the host bank, issuer processor, and core processor, among other entities, during other processes.

[00164] As an example of processes affecting a CCS database 1607 containing user information, in embodiments where the host bank holds accounts for each individual user, during a registration process the CCS server 1604 may receive a new account request and various types of user information and client device data from a client application published by the CCS and executed by the client device 1614. The CCS server 1604 may forward the request to a bank server 1606 that may generate a new financial account for the user in the bank database 1609, which may include generating and returning to the CCS server 1604 the routing number of the host bank and a unique account number for the user's new financial account. The CCS server 1604 may store into the user profile record of the CCS database 1607, the data about the user, the data associated with the client application and/or the client device 1614, and the data associated with new account held at the host bank. Alternatively, in embodiments where the host bank manages accounts for the CCS entity, during the registration process the CCS server 1604 may generate the user record in the CCS database 1607, and may update the user record to reflect amounts deposited or debited, into or out of the CCS account held at the host bank. The CCS server 1604 may also receive from the client device 1614 and store into the user profile record of the CCS database 1607, the data about the user, the data associated with the client application and/or the client device 1614.

[00165] As another example of a process affecting a CCS database 1607 that contains user information, the CCS server 1604 may receive a new card request from the client application executed by the client device 1614, thereby prompting the CCS server 1604 to execute various processes for generating a unique new payment card number for the user. The CCS server 1604 may generate the payment card number and store the payment card number into the user record of the CCS database 1607. In some implementations, the CCS server 1604 may execute a tokenization algorithm to generate a token that represents the payment card number, such that the token may operate as an alias or encoded representation of the payment card number. In such implementations, the CCS server 1604 may store the token into the CCS database 1607 records for the user, and may then exchange the token with various devices of the system 1600 during operational processes, allowing the devices to communicate transaction data using the token instead of transmitting the payment card number "openly" over the various computing networks. The CCS server 1604 may transmit the token and/or payment card number to the client device 1614 for storage and later usage. In addition, the CCS server 1604 may transmit the payment card number to the issuer processor server 1603, the bank server 1606, and/or core processor server 1605, or other computing device of entities that would require the payment card number generated for the user prior to any transactions being conducted using the payment card number.

[00166] A CCS server 1604 can communicate transaction data to a core processor server 1605, which may record the payment authorization and other transaction data into a system of record database 1610 and may further report the transaction data to the Federal Reserve and/or other entities that may be associated with the transaction. Although the core processor server 1605 may transmit response messages indicating whether a transaction request associated with a user's payment card number should be authorized, The CCS server 1604 may make various determinations whether to confirm or otherwise authorization payments based on certain criteria, such as whether the transaction would cause an overdraft on the user account; such criteria may additionally or alternatively consider the recommendation of the response message, unless the recommendation to reject the transaction based on a legal authority to deny the transaction. In some implementations, the CCS server 1604 may be configured to reject all transaction requests until a request to activate a payment card number has been received from an authorized client device 1614 associated with the user. Conventional systems may take several days to activate a new payment card and payment card number. But unlike conventional payment systems, a CCS server 1604 may be situated between the host bank and issuer processor, and thus the payment card numbers are capable of being active and used in real-time, the moment the card number is generated. As such, the CCS server 1604 transmits an active card number to the client device 1614, among other parties of the system 1600. For the user's protection, because the payment card is indeed active when the payment card number is transmitted to the client device 1614, the CCS server 1604 may reject all payment transaction requested by default. Likewise, the activation status of the payment card number in a user record in the CCS database 1607 may indicate that the card number has not been activated yet. The CCS server 1604 may prompt the user, via a client-side GUI presented on the client device 1614, to activate the card, even though the card is indeed active. The activation request from the client device 1614 may instruct the CCS database 1607 to update the activation status of the payment card number in the user profile to indicate the card has been activated, and thus the CCS server 1604 may authorize payment transaction satisfying any other criteria that might be verified by the CCS server 1604.

[00167] Devices of the CCS may include, or may otherwise be coupled to, one or more user-facing networks 1611, such as the Internet, through which client devices 1614 of users may access the CCS server 1604 and CCS databases 1607. One having ordinary skill in the art would appreciate that the user-facing networks 1611 may comprise any number of hardware and software computing-communications components configured to support communications between the client devices 1614 and the CCS server 1604, where at least some of the networks 1611 include internet protocol (IP) based networking technologies that allow the client devices 1614 to communicate with the CCS server 1604. Non-limiting examples of components of the user-facing networks 1611 may include routers, switches, firewalls, and the like.

[00168] Core Processor and System of Record

[00169] A core processor may be a financial institution responsible for authorizing transactions, releasing funds, managing a system of record database 1610, and conducting various transaction and identity verification processes. The core processor entity may be a bank or a third party that provides software services to the bank allowing the bank to function as the core processor. Some financial institutions may maintain core processor servers 1605 internal to the financial institution network boundaries. It should be appreciated that in some implementations the various entities may function as a core processor entity. For instance, in some circumstances, the core processor and the host bank may be the same entity, and thus the computing devices may be the same devices.

[00170] A core processor server 1605 receives and updates a system of record database 1610 that maintains the accurate information of the balance of an account maintained by various banks. Transactions may be pending or in various stages of the payment stream, but the official recordation of those transactions is by the system of record database 1610. Certain parties, such as the account owner (e.g., user, CCS), the merchant, the issuer processor, or the CCS, may assume certain risks that an account holder does not have sufficient funds to fund a transaction, until the core processer server 1605 authorizes the transaction and records the transaction in the system of record database 1610.

[00171] In operation, when a CCS server 1604 receives a payment authorization request from a merchant computing device 1601 via the various entities and devices, the CCS server 1604 can forward the associated transaction information to core processor server 1605, which maintains an account corresponding to the payment card used in the payment transaction. The system of record database 1610 may manage the account information using the core processor server 1605, along with a ledger of transactions for the account and other user profile information. In some cases, the core processor server 1605 may transmit account information, such as an indication for an amount of funds available to cover a transaction amount, to the CCS server 1604. The CCS server 1604 may determine based on preconfigured criteria whether to authorize the transaction based upon the account information received from the core processor server 1605. As previously mentioned, in some embodiments, the CCS server 1604 may be configured to deny all transactions associated with a payment card number associated with a user profile in the CCS database 1607 until the an activation request is received from the user via an authorized client device 1614 associated with the user, as indicated by the user profile record stored in a CCS databases 1607. The CCS server 1604 may be configured to make additional or alternative determinations regarding authorizing payment transaction requests independent of the core processor server 1605 determinations and indications. For instance, the CCS server 1604 may reject transaction requests associated with the payment card number of the user when the CCS server 1604 determines that there would be overdraft the account, even though the bank hosting the account of the user would permit the overdraft.

[00172] The CCS server 1604 can communicate transactions to the core processor server

1605, which may update the system of record database 1610 transaction information associated with user accounts registered with the CCS services. The core processor server 1605 may further report the transaction data and the daily ledger results in the system of record database 1610 to the Federal Reserve and any other banks that maintain account records associated with the payment card used in payment authorizations and transactions. In some instances, the core processor server 1605 may generate an authorization response that may be forwarded through the CCS server 1604 to various devices and entities of the system 1600 (e.g., merchants, issuer processor, merchant-acquirer, merchant), in order to confirm how the merchant may complete the payment transaction, indicating whether the transaction request was authorized or rejected by any particular entity in the payment authorization stream of the system 1600.

[00173] In the conventional payment stream, an issuer processor typically forwards payment authorization requests to a core processor server 1605. However, according to embodiments described in the disclosure, such as the example system 1600, and variations of such embodiments, a CCS server 1604 is situated between an issuer processor server 1603 and a core processor server 1605. Situating the CCS server 1604 between issuer processor server 1603 and core processor server 1605 allows for the CCS server 1604 to intervene in and record transactions in the payment stream, such as payment authorizations. Consequently, the CCS server 1604 can have visibility into data generated for all transactions associated with a user's account and payment card number to provide additional services to the user using the account. As such, the CCS server 1604 may execute additional features and transaction processes that were not available in the conventional payment and financial systems. Furthermore, the CCS server 1604 can perform some or all of the functions typically associated with issuer processors, and therefore, in some embodiments, the merchant-acquirer can communicate directly with the CCS server 1604. In other words, some embodiment may facilitate collapsing the number of entities required to be involved in conventional payment transaction processing streams. [00174] Client Device

[00175] A client device 1614 may be any computing devices capable of executing a locally-installed application or accessing a web-based application executed by a CCS server 1604. Non-limiting examples of client devices may include s mobile phone, tablet, smart watch, personal data assistant, gaming console, and personal computer, among other computing devices. The client device 1614 may transmit various forms of device data with user data, during registration, authorization, and verification processes. For example, during a registration process, the user may input into a registration GUI presented on the client device 1614, demographic information associated with the user (e.g., name, DOB, addresses, social security number). In addition, the client application may query a MAC address of the client device 1614 and an IP address of the client device 1614, as well as other types of information about the client device 1614. The device data may be submitted with the user data during the registration process, and may be stored in the user record in the CCS database 1607. As another example, a tokenization algorithm designed to mask the actual payment card number generated by the CCS server 1604 may use data inputs, such as the user ID of the user and/or a device identifier (device ID) associated with the client device 1614; the device ID may be generated by the CCS server 1604 according to various input values, or the device ID may be an existing data field, such as the MAC address of the client device 1614. As mentioned, the client device 1614 may access and communicate with the CCS server 1604 over one or more user-facing networks 1611 (e.g., the internet).

[00176] Generating Payment Card Numbers

[00177] FIG. 17 shows execution of a method 1700 of provisioning a payment card number to a user, according to an example embodiment. The example method 1700 comprises steps 1701, 1703, 1705, 1707, 1708, 1709, 1711, and 1713. However, it should be appreciated that some embodiments may include additional and/or alternative steps. It should also be appreciate that some embodiments may omit one or more steps without departing from the scope of this disclosure.

[00178] In a first step 1701, a CCS server may generate a user record in a CCS database. During a registration process with a CCS service provider system, the user may download and install on a client device an application associated with the CCS system, or the user may use the client device to interact with a web-application hosted on a webserver of the CCS system. The user may provide user data information, such as demographic data and other identifying information, which may then be stored in a user record that is identifiable by a unique user identifier (user ID) uniquely associated with the user. The client device may also transmit device data and/or client application data to the CCS server, such as MAC address, IP address, application-instance identifier, and the like. The data may be used in generating any number of unique identifiers and/or credentials, authorizing data exchanges between devices, and performing any number of additional or alternative secure processes. After establishing the user credentials and the user record, the CCS server may authenticate the user through user credentials and/or through device credentials, such as a MAC address received from the client device. The authentication may occur at login, as well as instances where the CCS server is requested to execute a transaction, manipulate the user's funds, and/or update user information in the record of the user.

[00179] In a next step 1703, after the CCS server has authenticated the user, the CCS server may receive a request for a payment card number from the client application of the client device. In some embodiments, the CCS server may receive various customization inputs from the user, such as aesthetic customizations and transaction configurations limiting the circumstances in which the CCS server may authorize payment transactions.

[00180] In a next step 1705, the CCS server may generate a payment card number and a token representing the payment card number. The CCS server may generate the payment card number by appending together several sets of digits, including a predetermined bank identification number (BIN) prefix, a set of randomly generated digits representing a randomly generated number generated according to a random number generator algorithm, and one or more checksum digits generated and applied according to a checksum algorithm that confirms the uniqueness and accuracy of the new payment card number as a whole. Generally, the BIN prefix is a set of digits, typically six digits, associated with a bank or card issuer. The issuer processor or other entity may provide the BIN prefix to the CCS server; the CCS server may store the BIN prefix digits and may be configured to apply the BIN prefix digits to new payment cards generated by the CCS server, in accordance with the issuer processor or other entity. The CCS server may also generate a set of digits for the random number portion of the card number using a random number generator algorithm and generate a set of one or more digits based on a Luhn check algorithm (or other checksum algorithm) dictated by the issuer processor or other entity. The CCS server may append the set of one or more Luhn check digits to the randomly generated set of digits. The CCS server may then use the Luhn check digits to determine whether the randomly generated number is unique. The Luhn check digits and randomly generated digits may be appended to the BEST prefix together, at the same time, or individually, such that the Luhn check algorithm may determine the uniqueness of the randomly generated value with or without the BEST prefix value. In the example embodiment, the CCS server may use the Luhn check digits and the Luhn check algorithm to confirm that the payment card number, comprising the digits of the randomly generated number appended to the BIN prefix digits, is a unique payment card number that does not match a second payment card number. In the event the CCS server determines that the Luhn check fails, and thus there is a collision with a second payment card number (e.g., an existing or already-used payment card number), then the CCS server may continue generating sets of digits for a random number until the CCS server identifies a payment card number that satisfies the Luhn check algorithm, and does not match another payment card number. In some implementations, the CCS server may calculate a token for the payment card number, where the payment card number may be generated and stored in a high- security module of the same or different CCS server and CCS database, and the token may be exchanged with external entities and stored in any number of databases and devices, such as the client device and the databases of third-party entities. The CCS server may be configured to generate the token using an algorithm that uses a random number generator and one or more predetermined input values (e.g., user ID values, MAC address of client device). In some implementations, the tokenization algorithm may evolve or change over time, so as to require additional or alternative parameter inputs. The CCS server may execute a random number generator generates cryptographically secure random numbers according to the algorithm. One having skill in the art would recognize that when a computer generates cryptographically secure random numbers, it is distinguishable from what may ordinarily be considered as identifying a number randomly. It is understood that patterns may emerge over time when computers are instructed to select a number at random, and thus special functions must be constructed to handle very large numeric values or alphanumeric strings in order for the random numbers to be truly random, to avoid collisions, and to prevent attackers from reverse engineering a pattern.

[00181] In some embodiments, a CCS server may be configured to generate any number of payment card numbers or account number, for new payments cards or accounts, according to any number of predetermined rules that limit where and how the payment card number, physical payment card, or account number may be used in transactions. For example, a request for a new payment card received from a user may indicate that the user wants the CCS server to generate a payment card number that may only be authorized for transactions involving particular merchants or a certain category of merchants. Various customization or configuration interfaces may allow the user to select particular certain rules, or payment limitation parameters, which may be user-defined transaction authorization parameters limiting the application of payment card numbers stored in the user record of the CCS database. The user may indicate, for example, that a payment number or account number may only be authorized for transactions involving restaurants, and thus the record of the user may associate the payment card number or account number with a merchant category code (MCC) associated with restaurants. Accordingly, when the CCS server determines whether to authorize a payment transaction request involving the payment account number or account number, after the CCS server queries the record of the user in the CCS database, the CCS server will authorize transactions having transaction data identifying a merchant with a matching MCC, and reject transactions having transaction data that do not contain the matching MCC. As another example, the user may establish a rule linking the payment card number to transactions involving a particular merchant. In this example, the CCS server may authorize transactions where the transaction data of the payment transaction request message contains a string or data field indicating that the transaction involves the particular merchant. It should be appreciated that the determination of whether to authorize the payment based upon the user configurations is generated by the CCS server, rather than an external server, such as a core processor server. In some circumstances, an external server, such as a core processor server or bank server may determine that the payment should or could be authorized according to conventional criteria executed by these external entity devices, yet the CCS server may determine that the user has chosen not to honor payments outside of the user's preconfigured limitations. [00182] Moreover, the CCS server may generate a plurality of payment card numbers or other account numbers in the user record that are associated with the user ID. Each user may generate multiple payment card numbers that are each distinct accounts to the merchants other entities, but are linked to the common bank account information according to the record of the user in the CCS database. As such, the user may request payment card numbers for dedicated merchants or merchant categories that the user may use for those particular merchants, yet the funds are drawn from the common, hidden account by the CCS server when the server matches the account number of the user with the payment card number generated according to the particular set of limiting rules or data fields.

[00183] In some embodiments, in an optional next step 1706, where a bank may host a separate bank account for each individual user of the CCS services, the CCS server may request that the host bank open a new financial account for the user, and may receive account data (e.g., account number, routing number) in return. The CCS server may be configured to transmit to the bank servers, data from a user record containing additional Know-Your-Customer (KYC) data, according to the requirements of the host bank or regulations. The bank servers may transmit back to the CCS server the account information for the user's account after the account is established in the bank servers and bank databases.

[00184] Alternatively, in some embodiments, the host bank may establish and manage bank accounts for the CCS service provider, where funds may be deposited by the user into an account held by the CCS service. Although in the account of the CCS service at the host bank, the funds are owned by the user, which is reflected accordingly in the records of the various databases of the CCS and host bank, as well as the client application. In such embodiments, the payment card number may be associated with the user ID in the CCS databases in order to monitor the amount of money available to the user. When conducting transactions, the payment card number may be associated with the routing and account number of the CCS service provider's financial account held at the host bank.

[00185] In a next step 1707, the CCS server may update the user record in the CCS database according to the payment card number generated by the CCS server, the token representing the payment card number, and, in some cases, the user account data generated and received from the bank server of the host bank. In later payment authorization processes, the CCS server may query the records of users in the CCS database according to any number of data fields, such as user IDs, routing numbers, bank-customer identifiers (bank-customer IDs), payment card numbers, token values representing payment card numbers, and the like.

[00186] In some implementations, the CCS server may update the record of the user based upon the account data (e.g., routing number, account number) received from the third-party host bank, thereby associating the new payment card number with the account data in the records of the CCS service provider. The host bank may additionally transmit a bank-customer identifier (bank-customer ID) uniquely identifying the user in the host bank database. This bank-customer ID may also be stored into the record of the user in the CCS database. In some embodiments, this bank-customer ID may function as a token or proxy for the routing number, and the CCS server may generate the account number that the CCS server may transmit to the host bank, issuer processor, and card printer.

[00187] In a next step 1709, the CCS server may transmit the token representing the payment card number to the client device, an issuer processor, and/or a card printer service. The client device may store the token in a non-transitory machine-readable memory of the client device. The client application may access the token and display the payment card number via one or more GUIs; and the client application may access the token to transmit the token or payment card number to a merchant computing device or to another a client device in order to conduct a payment transaction through a digital environment, without requiring the physical payment card. In some implementations, the client device may also receive from an issuer processor server, a cryptogram token representing the payment card in a third-party digital wallet application. In embodiments where the CCS service provider functions as the issuer processor, the CCS server may generate the cryptogram token for the digital wallet application and transmit the cryptogram token to the client device.

[00188] In some embodiments, where the CCS service provider is a distinct entity from the issuer processor, the CCS server may transmit the payment card number to the issuer processor server. The issuer processor server may update an issuer processor database to reflect the newly issued payment card number, which may allow the issuer processor server to execute any number of authorization, verification, and/or authentication processes that protect the user and may ease the processing burden of CCS server, when payment transaction request messages are received from merchants, merchant-acquirers, and/or other client devices. The issuer processor may additionally update the databases of the payment network entity (e.g., Visa®, MasterCard®, American Express®) to indicate that the payment card number has been issued to operated accord the particular payment network rails.

[00189] The CCS server may transmit the payment card number to a server of a card- printing entity that is authorized by the issuer processor and/or payment network entity to print and ship physical payment cards to users. The payment card may be shipped to the user, who may then employ the payment card with the payment card number in payment transactions like any ordinary payment card. In some implementations, the CCS server may transmit graphical data to the card-printing entity, generated by the user through one or more design GUIs executed on the client application of the client device. Accordingly, the payment card may be customized according to the real-time payment card number generated in response to the user's request, and according to the aesthetic graphics generated by the user interacting with the design GUIs.

[00190] In some circumstances, at a next step 1710, the CCS server may update an activation status data field in the record of the user, or some other database record, in a CCS database. As previously mentioned, due to the real-time generation of an active payment card number, the payment card number may be employed by the user as soon as the user receives the payment card number from the CCS server. As such, regardless of whether other entities, such as a core processor, would authorize a transaction associated with the payment card number, the CCS server may be configured to reject all transactions associated with the payment card number until the CCS database indicates that the card is activated. In this way, should a third-party intercept the physical payment card en route from the card-printing entity to the user, the CCS server will prohibit the third-party from fraudulently conducting any transactions using the payment card. After transmitting the payment card number to the client device, the client application may display the payment card number to the user, and may display on a graphical user interface (GUI) prompting the user to activate the payment card number.

[00191] In some implementations, users may be allowed to selectively update the activation status of a payment card number by submitting subsequent activation requests through the appropriate GUI present on the client application. This feature allows the user to continually and selectively "turn on" and "turn off a payment card number listed in the database record of the user. Each subsequent request indicates to the CCS server whether to update the status field to indicate that the payment card number is activate or inactive, and thus indicates to the CCS server whether to authorize payment transaction requests associated with the payment card number.

[00192] In circumstances where the CCS server receives an initial or subsequent activation request from the client application of the client device (in previous step 1710), then the CCS server, in a next step 1711, may update the activation status field in the user record of the CCS database for the corresponding payment card number. Based on the activation request, the activation status field in the record of the user and/or record for the payment card number may indicate that the user has received or otherwise accepted the payment card number and the responsibilities for tracking the payments. In addition, the user has also indicated that CCS server should permit payment transaction requests linked to the payment card number, where the CCS would otherwise reject payment transaction requested associated with the payment card number by default. As previously mentioned, the CCS server may receive subsequent requests to deactivate the payment card number that instruct the CCS server to update the activation status field to indicate that the user wants to "turn off or deactivate the payment card number, and thus instructs the CCS server to deny payment transaction requests when the CCS server queries the activation status field.

[00193] In a next step 1712, when the CCS server receives a payment transaction request and associated transaction data, the CCS server may determine whether to permit the payment transaction based on any number of factors, including the activation status field in a database record associated with the payment card number. Because payment card numbers generated by the CCS server are technically active card numbers as far as other entities, external to the CCS, are concerned, it is possible that a new payment card number would be honored by various entities before the user or possess the new payment card number or before the user wants the new payment card number to be useable. For instance, a payment transaction request containing transaction data identifying the new payment card number may be received and processed by a core processor. The core processor may honor the payment card number and determine that the payment card number should be honored by an issue processor, merchant-acquirer, and/or a merchant. For security purposes, the CCS server may make a determination whether to honor the payment transaction request independently from the core processor or other external entities. Here, the CCS server may independently determine whether to accept or reject the payment transaction request based upon the activation status field associated with the new payment card number.

[00194] In a next step 1713, after the CCS server receives a payment transaction request message from a payee (e.g., merchant), where the transaction requests indicate that the payment card number is involved in the transaction, the CCS server may receive from a core processor server, a payment authorization response message containing data about the transaction and indicating whether the CCS server and/or an issuer processor server should authorize the payment request. The CCS server may determine whether the card activation status field indicates that the payment card number has been activated. The CCS server may further determine whether to authorize the payment transaction according to any number of payment or transaction authorization parameters and criteria, such as an amount of funds in the account available to the user and the amount of the transaction. If the activation status field of associated with the payment card number indicates that the payment card number is activated by the user, then the CCS server may permit the payment by transmitting an authorization message to one or more entity systems, such as the banking system, the core processor, the issue processor, the merchant-acquirer, and/or the merchant. Likewise, regardless of whether any of the external entities would authorize the transaction, the CCS server may automatically deny, and thus transmit rej ection messages to any of the external entity systems, when the CCS server determines that the activation status field associated with the payment card number indicates that the payment card number is not activated by the user.

[00195] In some implementations, the client device may present a GUI allowing the user to selectively activate and de-activate the payment card number. The input will instruct the CCS server to update the record of the user in the CCS database to indicate an activation status. Based on this activation status, the CCS server may determine whether to authorize payment transaction requests received from merchant computing devices or other payees (e.g., other client applications executed by client devices).

[00196] Similarly, in some embodiments, the user may selectively activate and de-activate payment card numbers associated with particular merchants in the user record. The CCS server may update the activation status field for the payment card number in the user record to indicate that the particular payment card number is activated or de-activated according to the user's selection. The CCS server may then authorize or reject payment transaction requests accordingly. For example, if a user has generated a payment card number that is associated with a particular merchant that charges a regular subscription fee, the user may de-activate the payment account number in the user record to stop the CCS server from authorizing payment transactions for that particular merchant, even when the other external entities may permit the transactions.

[00197] Example REGISTRATION GRAPHICAL User Interfaces

[00198] FIG. 18 shows a graphical user interface (home screen GUI 1800), according to an example embodiment. The home screen GUI 1800 may be a home screen that shows various options and information about the user's account. The home screen GUI 1800 may display an account balance, which may be an amount of money available to the user according to a user record stored in a CCS database or may be an amount of money indicated by the records or ledger of a third-party bank as indicated to the CCS server. The GUI 1800 displays a graphical depiction of the user's payment card; but in some instances, as in the example embodiment, the GUI 1800 may indicate that the user has not yet received the physical payment card, and/or has not yet activated the payment card number generated by the CCS server. In such circumstances, the home screen GUI 1800 may provide a selectable button or hyperlink that instructs the client application to submit to the CCS server a request for a new payment card and/or a request for a new payment card number. The home screen GUI 1800 may additionally provide options for the user comment various types of transactions, such as sending a check and depositing funds from an account at another financial institution.

[00199] FIG. 19 shows a graphical user interface (customization GUI 1900), according to an example embodiment. After the user selects an option to generate and receive a new payment card on the home screen GUI 1800, the client application may present a customization GUI 1900 comprising one or more input fields 1901 that capture inputs from the user, thereby allowing the user to input a signature into the customization GUI 1900, and optionally aesthetically personalize the payment card through the client application. For example, the customization GUI 1900 may capture the user's finger touch or stylus to generate a graphical display that traces the user's contact with the screen of the client device. When the user is satisfied with the personalization, the client device may save the graphical representation of the customized payment card in memory.

[00200] FIG. 20 shows a graphical user interface (shipping GUI 2000), according to an example embodiment. After completing the personalization of the payment card, a shipping GUI 2000 may be presented to the user to capture the user's shipping address. The CCS server may forward this information from the client device to a server of a card-printing entity, along with the graphical representation of the payment card and the payment card number. The card- printing entity may be responsible for printing and shipping credit/debit cards according to a user's and/or a financial institution's specifications. In some implementations, the CCS server may use the information received via the shipping GUI 2000 as an additional user verification step, by comparing the information received from the shipping GUI 2000 against existing data records for the user that may be stored in the CCS database. In some implementations, when the user confirms submission of the shipping address information, the CCS server may be triggered to generate the payment card number.

[00201] FIG. 21 shows a graphical user interface (confirmation GUI 2100), according to an example embodiment. The confirmation GUI 2100 may display: a confirmation message indicating the payment card has been requested for the user's account, a graphical representation of the payment card, and information about the user's various accounts (e.g., account data, payment card number). The confirmation GUI 2100 may also display selected options instructing the client application to request a cryptogram token for a third-party digital wallet application (e.g, Apple Pay®, Google Wallet®) executed by the client device. When the user selects the option to establish a cryptogram token for the digital wallet application, the input may instruct the client application and the client device to submit the payment card number to a computing device (e.g., issuer processor server, CCS server) configured to generate a compatible cryptogram token according to the digital wallet application requirements. The client device may then receive the cryptogram token from the computing device, and store the cryptogram token into memory accessible to the digital wallet application.

[00202] Technology is disclosed that uses an electronic payment stream to generate a notification to a customer for a suggested tip amount on a purchase, and the electronic payment stream offers additional security to ensure that the desired tip amount is captured. The term "tip" as used herein refers to an additional payment above the minimum payment for the service, and may be characterized as a tip, gratuity, bonus, gift, or donation. A tip is customary in industries such as restaurants, barbers, maids, taxi drivers, and bartenders.

[00203] A conventional tip calculator can provide an amount to pay based on a subtotal of a bill and a percentage to tip. For example, if the subtotal of the bill is $100, and the customer wants to tip 20%, the tip calculator may suggest a tip amount of $20. This calculator function may be provided by an application on a mobile device. When the customer desires a tip calculation (such as upon receiving a bill), the customer can input the subtotal and tip amount, and the application can present a suggested tip amount on a user interface. This application is not tied to the payment process and must be initiated by the customer.

[00204] In some instances, a receipt presented by a merchant may include suggested tip amounts for that subtotal. For example, after charging a subtotal to a customer's card, a restaurant prints a receipt with fields for entering a tip amount, a total amount, and a signature of the customer. The receipt may also include a calculation, whereby a receipt for a bill of $100 would recite $20 for 20%, $15 for 15%, or $10 for 10%. The tip calculations are printed on the receipt by a point of sale system, but the calculation is merely a suggestion and does not add any security to the payment process.

[00205] EMV chip cards are processed differently from magnetic stripe cards. For example, EMV chip cards may only allow the tip amount to be entered before processing the card, and a tip amount may not be added at a later time. In a conventional magnetic stripe card transaction, the customer signs the receipt and adds the tip amount along with the total amount. Because an EMV chip card transaction may not allow for the tip amount to be added, it is desirable to have a payment process that integrates the addition of a tip to the bill. In an attempt to address this issue, a card issuer may allow authorization of a bill for an additional 20% to account for a tip to be added, but such a workaround adds complexity and uncertainty to the payment stream.

[00206] In contrast, the notification message system introduced here can use a payment request message during an authorization process to generate a message recommending a tip amount. In an example process, a customer provides a payment card number for payment at a merchant, such as a customer providing a payment card to a waiter at a restaurant. The merchant swipes or inputs the card into a point of sale terminal, which initiates a payment request authorization message (or "authorization message") using the payment card number for an amount. An authorization message includes the payment card number (e.g., a credit card number) and a transaction amount. The authorization message is transmitted to a merchant-acquirer, who then transmits the authorization message to issue processing services, such as Visa or MasterCard. The issue processing services transmits the authorization message to consumer computing system. The consumer computing system can use a merchant category code to determine whether the merchant is one that customarily receives a tip, such as a non-quick service restaurant. When the merchant is a type that customarily receives a tip, the consumer computing system calculates a tip amount based on the transaction amount. The consumer computing system generates a message and pushes the message to a mobile device of the user associated with the payment card number. The message pushed to the mobile device includes a suggested tip amount. The notification message is pushed upon processing of the authorization message, because the customer should receive the recommended tip amount at the time of the transaction. A significant delay in the push notification message may cause the customer to wait an undesirable amount of time or be too late for the customer to use during the transaction. The customer can write that tip amount on a receipt presented by the merchant. The merchant will submit the total amount, along with the tip, for authorization.

[00207] The notification message system automatically triggers the generation and push of a notification message having a tip amount upon receiving the authorization message in the payment stream. The notification message is pushed to the mobile device within a certain time period to ensure it is useful in the transaction. If, however, the consumer computing system is unable to deliver the message within the certain period of time, then the consumer computing system may delete the notification because it would be too late to affect the transaction. So the consumer computing system receives the authorization message, which automatically initiates the calculation of the tip amount and the generation of a notification message with that calculated tip amount. The notification message can then be pushed from the consumer computing system to the mobile device without requiring a request to be inputted in or transmitted from the mobile device. Such a notification message is generated and transmitted within a network-based computing environment and enabled by the consumer computing system and the functionality of messaging to a mobile device. The notification message cannot be generated in a similar manner without being integral to the payment stream. The integrated consumer computing system is able to perform functionality that is not present in human-implemented transactions.

[00208] The notification message system can also more securely ensure that the customer's selected tip amount is not revised by a merchant. In an example embodiment, once the customer receives the push notification message on the mobile device, the customer can select a tip amount by tapping a corresponding selectable link (e.g., button) on the mobile device. The selection is transmitted by the mobile device to the consumer computing system. The customer then completes the receipt with the tip amount and signs the receipt. If the merchant alters the tip amount, thereby also changing the total payment amount, the transaction may be declined, and the consumer computing system will push a notification message to the consumer warning of an unexpected capture amount. In one example, upon determining that total payment amount does not match, the consumer computing system may generate a request to decline the transaction (e.g., cancel authorization or capture, request chargeback from system of record for the total amount of the transaction).

[00209] The notification message system automatically triggers the generation and push of the unexpected capture amount notification message upon receiving the authorization message for an improper amount in the payment stream. The consumer computing system receives the authorization message, which automatically initiates the determination of whether the total amount matches the selected tip amount and total transaction amount. Upon a determination that there is no match, the consumer computing system may decline the transaction and automatically generates the notification message alerting the customer to the unexpected capture amount. The notification message can then be pushed from the consumer computing system to the mobile device without requiring the mobile device to request a confirmation of the amount in the authorization message. Such a notification message is generated and transmitted within a network-based computing environment and enabled by the consumer computing system and the functionality of messaging to a mobile device. The notification message cannot be generated in a similar manner without being integral to the payment stream. The integrated consumer computing system is able to perform functionality that is not present in human-implemented transactions. [00210] The notification technology introduced here can be embodied as special-purpose hardware (e.g., circuitry), as programmable circuitry appropriate programmed with software and/or firmware, or as a combination of special-purpose and programmable circuitry. Hence, embodiments may include a machine-readable medium having stored thereon instructions that may be used to cause one or more processors to perform the methods, variations of the methods, and other operations described here. The machine readable medium may include, but is not limited to, floppy diskettes, optical discs, compact disc read-only memories (CD-ROMs), magneto-optical discs, read-only memories (ROMs), random access memories (RAMs), erasable programmable read-only memories (EPROMs), application-specific integrated circuits (ASICs), magnetic or optical cards, flash memory, or other type of media/machine-readable medium suitable for storing electronic instructions.

[00211] The present disclosure is here described in detail with reference to embodiments illustrated in the drawings, which form a part here. Other embodiments may be used or other changes may be made without departing from the spirit or scope of the present disclosure. The illustrative embodiments described in the detailed description are not meant to be limiting of the subject matter presented here.

[00212] Various embodiments will now be described in further detail. The following description provides specific details for a thorough understanding and enabling description of these embodiments. One skilled in the relevant art will understand, however, that the embodiments discussed herein may be practiced without many of these details. Likewise, one skilled in the relevant art will also understand that the embodiments can include many other obvious features not described in detail herein. Additionally, some well-known structures or functions may not be shown or described in detail below, to avoid unnecessarily obscuring the relevant description.

[00213] FIG. 22 illustrates a system architecture of an electronic payment system according to an example embodiment. A merchant computing device 2201 can be a payment card payment processing terminal, such as a payment card scanner or reader, that can request payment authorization to complete a sale. The merchant computing device 2201, which can be any device capable of capturing payment request data on behalf of a merchant, can receive an input (e.g., swipe or dip a card, wireless transmission, keypad entry) of a user's payment card information, such as card verification value (CVV or CVVI), card verification code (CVC or CVC 1), card identifier (CID), and payment card number, into the merchant computing device 2201. Non-limiting examples of a merchant computing device 2201 may include a point of sales (POS) terminal, a payment card payment processing terminal (e.g., a payment card scanner), a server for an online site, and a cash register. Non-limiting examples of payment instruments may include magnetic stripe cards, EMV cards, debit cards, credit cards, stored value cards, gift cards, and virtual cards or tokens that may be stored on a client device 2215 (e.g., user computing device, smartphone, or computer). The merchant computing device 2201 may comprise or may be coupled to various types of instrument readers configured to capture transaction data from certain types of payment instruments. For instance, if the payment instrument is a virtual card stored on a client device 2215, and the client device 2215 is configured to transmit payment request data for the virtual card using near field communications (NFC), then the merchant computing device 2201 may comprise or may be coupled to an NFC scanner configured to capture the transaction data related to the virtual card via the NFC signal received from the client device 2215. The client device can include one or more client applications stored in memory and executed on one or more processors. The client application can present information to the user and receive inputs from the user via, for example, a keyboard, mouse, or touchscreen. The client applications can be stored on a centralized server, such as the Google Play® store or iTunes®, and the user can download the applications from the centralized server to perform functions, such as those describe in this disclosure.

[00214] In operation, the merchant computing device 2201 may capture payment card information and then generate and transmit a digital message, such as a payment authorization request, comprising the payment card information along with transaction data (e.g., transaction amount, merchant identifier) to a merchant-acquirer server 2202. The merchant computing device 2201 may be configured to generate digital messages containing the payment authorization request, which includes the payment card information and transaction data, may be generated according to particular protocols or specifications, e.g., one or more ISO standards in which the payment authorization request can contain certain fields for the payment card information and the transaction data. Non-limiting examples of data fields that may be included the digital message may include a merchant identifier (merchant ID), a merchant name, a merchant category code (MCC), an amount for the transaction, a timestamp (e.g., data, time), and a card number. In some implementations, the merchant computing device 2201 may transmit the digital message containing the card and/or other payment information to a merchant-acquirer server 2202, although in some embodiments, the digital message may be transmitted to other devices, such as an issue processor server 2203 of an issue processor system.

[00215] Merchant-Acquirer

[00216] The merchant-acquirer server 2202 may be any computing device configured to process an authorization request from a merchant and forward at least some of the information to an issue processor server 2203 over payment network rails 2209 or an issue processor system network {e.g., Visa® or MasterCard® networks). A merchant point of sale system can comprise a merchant computing device 2201 that is associated with a merchant-acquirer server 2202 to process payment card payments. Although one merchant computing device 2201 and one merchant-acquirer server 2202 is shown, the system may comprise more than one of each the merchant computing device 2201 and the merchant-acquirer server 2202.

[00217] Payment Network Rails

[00218] Payment networks {e.g., Visa®, MasterCard®, and American Express®) may be entities that own and operate payment network rails 2209, which may be a computing communications network configured to receive and transmit digital messages between merchants and merchant-acquirers to issue processors and issuing banks. In operation, merchant computing devices 2201 and merchant-acquirer servers 2202 may generate, manipulate, and transmit digital messages containing payment authorization requests. The digital messages may be generated and manipulated according to the policies, standards, and protocols implemented by each particular payment network.

[00219] Issue Processor

[00220] Issue processor systems can establish payment card number records for customers, issue bills and statements, and process payments. The issue processor server 2203 can perform these functions and store transactions and payment card numbers in a storage device, such as database 2206. Issue processors will typically forward payment authorization requests to a system of record server 2205. However, the example system comprises a server 2204 positioned between issue processor server 2203 and system of record server 2205. Furthermore, the server 2204 can perform some or all of the functions typically associated with issue processors, and therefore, in these embodiments, the merchant-acquirer server 2202 can communicate over the payment network rails with the server 2204. Although the issue processor server 2203 and the server 2204 are shown as separate computing platforms, the issue processor server 2203 and the server 2204 can be implemented as a single platform. The positioning of server 2204 in between issue processor server 2203 and system of record server 2205 allows the server 2204 to provide added functionality to the system, such as intervene in and record transactions in the payment stream (e.g., intercept payment authorizations). As a result, server 2204 can also have access to all transactions associated with an account to provide further services to the client device 2215 associated with the account.

[00221] Note that FIG. 22 illustrates a four-party scheme (or open scheme) in which the issue processor server 2203 is separate from the merchant-acquirer server 2202. Embodiments of this disclosure can similarly function with three-party schemes (or closed schemes), such as American Express, Discover Card, and Diners Club, in which the issue processor server 2203 and the merchant-acquirer server 2202 are the same entity.

[00222] The server 2204 comprises a memory and a processor, whereby the memory comprises a set of computer-readable instructions that are executed by the processor. Although the server 2204 is shown as a single server, it is intended that the functionality of server 2204 can be performed by more than one server.

[00223] The server 2204 of a consumer computing system can be positioned between the issue processor server 2203 and the system of record server 2205. Server 2204 is part of a consumer computing system ("CCS") 2213, which can also include an application programming interface (API) 2214 and one or more databases 2207a-2207n. Server 2204 can use API 2214 to communicate with client device 2215 over user-facing networks 2211, such as the internet. Databases 2207a-2207n can include a profile database, with information such as a user profile, account numbers, and transaction ledgers. With this system architecture, server 2204 can intercept transmissions of transaction messages that occur between issue processor server 2203 and system of record server 2205. The server 2204 does not need to perform an action on every transaction message, as the server 2204 can just relay the transaction message. After receiving a transaction from issue processor server 2203 and recording information from that transaction, server 2204 can forward the transaction to system of record server 2205.

[00224] System of Record

[00225] System of record server 2205 can be hosted by a bank 2216 or a third party that provides a service to a bank 2216. Some banks maintain their own system of record servers. The system of record server 2205 maintains the accurate information of the balance of an account maintained by bank 2216. Other transactions may be pending or in various stages of the payment stream, but the official recordation of those transactions is by the system of record server 2205 and database 2210. Certain parties, such as the account owner, the merchant, the issue processor, or the CCS 2213, may assume certain risks that an account holder does not have sufficient funds to fund a transaction, until the system of record records and authorizes the transaction. However, these parties may assume that risk to process transactions more quickly and efficiently.

[00226] Upon receiving a payment authorization request, server 2204 can forward associated information to system of record server 2205, which maintains an account corresponding to the payment card used in the payment transaction. Bank 2216 can maintain the account using the system of record server 2205, along with a ledger and other user profile information. System of record server 2205 can also include database 2210 that can store a copy of the ledger associated with the account record.

[00227] Server 2204 can also be in communication over user-facing networks 2211 {e.g., the internet) with client device 2215. Client device 2215 is illustrated in FIG. 22 as a smartphone, but can be any computing device, such as any mobile phone, tablet, smart watch, personal data assistant, gaming console, or personal computer. Consumer computing system 2213 can also include several databases in communication with server 2204, such as database 2207a for storing user profile information, and database 2207b for storing sub-account balances and ledgers.

[00228] Server 2204 can communicate transactions to the system of record server 2205, which can record in database 2210 the payment authorization and further report it to the Federal Reserve and bank 2216 that maintains the account record associated with the payment card used in the payment authorization. Bank 2216 may also generate an authorization response to forward to the system of record server 2205, back though other devices in the payment stream and eventually to the merchant computing device 2201 to confirm that the merchant may complete the payment transaction.

[00229] Server 2204 has a notification engine 2208. Upon a determination by the server

2204 to alert the client device 2215 or otherwise transmit a notification message (or "message") to the client device 2215, the notification engine 2208 generates the message (e.g., an alert) for transmission over the user-facing networks 2211 to the client device 2215. The notification message can be, for example, a notification generated via a mobile OS notification, email message, or text message. The notification engine 2208 can query information from databases 2207a-2207n to obtain data regarding a recent transaction and client device contact information (e.g., mobile phone number for text messaging or an e-mail address for e-mailing). When generating the message, the notification engine 2208 can determine how to populate fields of the message using the obtained information. For example, the notification engine 2208 can direct the message to the address identified in a contact record for the client device; the address can be, for example, an email address, IP address, or phone number. In another example, the notification engine 2208 can calculate how much of a tip to offer based upon a transaction amount. In one embodiment, the notification engine 2208 can populate a plurality of tip amount fields in a message based upon the transaction amount. The notification engine 2208 is also configured to receive instructions from the server 2204. For example, the server 2204 may instruct the notification engine 2208 when to send a message to the client device 2215.

[00230] The notification engine 2208 of the server 2204 can also be configured to receive a response message transmitted from the client device 2215 over the user-facing networks 2211. When the client device 2215 receives a message from the server 2204, the client device 2215 can generate a message for transmission back to the server 2204. This message can be generated via a text messaging application, an e-mail application, or other messaging application on the client device 2215. The message generated on the client device 2215 can include a selection of an option presented by the notification engine 2208 or other data. For example, the message generated by the client device 2215 can contain a value representing an amount that the user of the client device 2215 intends to tip in the subject transaction. The server 2204 can process the selection or other data (e.g., tip amount) and determine whether the received value is the same as the value transmitted via the authorization process for that same transaction. [00231] A tippable transaction can be processed using a single authorization request containing a tip in a final amount or using two authorization requests from the merchant. In a two-message authorization request process, upon receiving an input that includes a tippable transaction, the merchant computing device 2201 generates an initial request message that includes a final amount of the transaction for authorization. This message can be hashed and encrypted when transmitted to the merchant-acquirer server. The merchant-acquirer server 2202 receives the message and decrypts it for processing. The merchant-acquirer server 2202 creates a clearing request for transmission to the issue processor system via the payment rails for authorization. At a later time, once the merchant computing device 2201 receives an input of a merchant tip amount, the merchant computing device 2201 stores the merchant tip amount in a record of database 2207, then generates a capture message with the tip and final amount for authorization. This subsequent message contains an indicator that it is an updated transaction. Upon receiving the authorization request, the server 2204 of the consumer computing system can accept or decline the transaction.

[00232] The server 2204 of the consumer computing system determines whether to authorize the initial or subsequent capture message transaction requests. The server 2201 can make this determination based upon a determination of risk, an assessment of the customer balance, and the like.

[00233] During the authorization process, when the server 2204 receives a transaction request that is tip eligible, the server 2204 causes a notification to be generated and transmitted (e.g., via SMS message, push notification, or e-mail) for display on the client device 2215. The notification can include a tip suggestion as well as a suggestion of the associated total (authorization amount plus tip). The notification can also include an outstanding balance as of the authorization. In one embodiment, the suggested tip amount is not binding, and the customer can use any tip amount in the transaction. The server 2204 will proceed to authorize the tip amount in the capture message, even if it differs from the amount in the notification message. In another embodiment, once the customer selects a tip amount via an interface on the client device 2215, and that selection is transmitted back to the server 2204, the customer is bound by the selected tip amount. [00234] In an example where the customer is bound by the selected tip amount, the server 2204 may generate a decline request when the merchant tip amount in the payment request authorization message is not the same as the selected tip amount represented by the value in the database 2207 record. Upon a determination that there is no match, the notification engine 2208 may automatically generate a notification message for the client device 2215 alerting the customer to the unexpected capture amount. The server 2204 may also transmit a message to the issue processor system server 2203 or the system of record server 2205 requesting that authorization for the transaction be declined. The server 2204 can also request initiation of a charge back. The charge back can be the total amount of the transaction or a difference between the selected tip amount and the merchant tip amount.

[00235] FIG. 23 illustrates a data flow diagram of a tip amount notification message system, according to an example embodiment. This example flow 2300 begins at a merchant point of sale transmitting transaction information to the merchant-acquirer, in step 2305. The merchant, such as a restaurant, can swipe a magnetic stripe of a payment card, insert an EMV chip card into a point of sale chip card reader, contactless payment via wireless card reader (e.g., NFC), or otherwise input the payment card information into the point of sale system. The point of sale system transmits the payment card number and transaction amount, along with information such as expiration date and name of the customer.

[00236] In step 2310, the merchant-acquirer transmits the transaction information over payment network rails to the issue processor system. The payment network rails may be proprietary for each issue processor system, or issue processor systems may share a network. The issue processor system can begin the authorization process for a transaction request.

[00237] In a conventional transaction, the authorization message may be transmitted from the issue processor system directly to a system of record, but the notification system described herein has a consumer computing system positioned to receive from the issuer processor system. In step 2315, the issue processor system transmits the authorization message to the consumer computing system.

[00238] The consumer computing system can determine whether the transaction with merchant should include a tip. The consumer computing system can use information from one or more of the merchant name, merchant identifier, or MCC code. For example, the consumer computing system can the MCC code to determine whether to generate instructions for processing the transaction as a tip transaction.

[00239] The merchant is associated with a MCC or other code, such as North American Industry Classification System (NAICS), that identifies a primary business or industry category of the merchant. The MCC can be assigned by the issue processor system or the consumer computing system and can be stored in an associated database. Upon receiving the authorization message, the merchant's MCC is identified to determine the primary business category. The primary business or industry category can be used to determine whether the merchant customarily accepts tips with each transaction. A merchant that customarily accepts tips with each transaction will likely present a tip amount field on a receipt presented to a customer after initially authorizing the transaction for a subtotal amount. In one example, MCC 5812 corresponds to "eating places and restaurants," which customarily accepts tips. In another example, MCC 5813 corresponds to "drinking places (alcoholic beverages), bars, taverns, cocktail lounges, nightclubs, and discotheques," which customarily accepts tips. In yet another example, MCC 5814 corresponds to "fast food restaurants," which does not customarily receive tips. In step 2320, the consumer computing system determines whether a suggested tip notification message should be transmitted based on only those transactions at certain merchants. In this example, transactions initiated by a merchant corresponding to MCCs 5812 or 5813 would cause such a notification message, but a transaction initiated by a merchant associated with MCC 5814 would not cause the tip amount notification message.

[00240] In step 2325, if the MCC does not correspond to a merchant that customarily accepts tips, the authorization message will proceed using the transaction amount as the final, total amount.

[00241] In step 2330, if the MCC corresponds to a merchant that customarily accepts tips, then the consumer computing system automatically calculates a tip amount based upon the amount in the authorization request. In one embodiment, the consumer computing system may set a default tip percentage, which may be selected by the customer. For example, the consumer computing system can have a default tip percentage of 20%, so any transaction amount will initiate a calculation of a tip based upon 20% of the transaction amount. In another embodiment, the consumer computing system can present the customer with more than one option for a tip. For example, the consumer computing system can present a tip amount based upon 10% of the transaction, 15% of the transaction, and 25% of the transaction. Although these example percentages are used, it is intended that any number of tip amounts can be presented, and any tip percentages may be used.

[00242] In step 2335, the notification engine of the consumer computing system generates a notification message to be transmitted to the customer's client device, which is described in this example embodiment as a mobile device, such as a cellular phone or a smartphone. The notification message can be SMS message, MMS message, or other application-based message. For example, if the mobile device of the customer has an application installed on the mobile device associated with the consumer computing system, the consumer computing system can transmit instructions to mobile device to restore the application to execute a notification for presentation on the mobile device.

[00243] In step 2340, the consumer computing system determines an address of the mobile device of the customer. The consumer computing system can use the payment card number, which may be associated with a mobile device address in the user account database. The address may be a phone number or any other identifiable information used to send a notification message to that mobile device.

[00244] In step 2345, the notification engine of the consumer computing system pushes the notification message having the tip amount to the mobile device of the customer. As described above, the notification message is generated and transmitted upon the receipt of an authorization message from a merchant having a MCC that corresponds to an industry that typically accepts tips.

[00245] In one embodiment, the notification message is pushed to the mobile device within a certain time period to ensure it is useful in the transaction. Because of the automatic generation and transmission of the notification message, the notification message is configured to be sent as soon as possible after the receipt of the authorization message, which may be in real time or take just a few seconds. In one embodiment, a time period for pushing the notification message has an end time, such that if generation and transmission of the notification message is to occur after the end time, then the notification message will not be sent. A customer may be completing a transaction, but the customer does not want to stay beyond a certain length of time at a restaurant, in the back of a taxi cab, or at a bar waiting for the tip amount to be transmitted. The consumer computing system may set a default end time, which may be selected by the customer. If the consumer computing system receives an authorization message comprising a tip amount before the notification message is pushed to the mobile device, then the notification message will not be sent. Accordingly, the consumer computing system is configured to push the notification message to the mobile device within a time period to maintain the benefit of the service.

[00246] FIG. 24 illustrates a graphical user interface 2410 of a mobile device 2400 that received a push notification message 2420, according to an example embodiment. In this example embodiment, the push notification message 2420 is shown on a locked home screen of the mobile device 2400. In this example, the push notification message says, "You paid $98.50 at Nolita Sushi. Add $19.70 to tip 20% (total of $1 18.20)." This example notification message includes the transaction amount (e.g., $98.50), a suggested tip amount ($19.70 based upon 20% of the transaction amount), a total amount ($1 18.20), and the name of the merchant. Including the name of the merchant can assist the customer with ensuring a secure transaction, because the customer may not be present at that merchant when a fraudulent transaction is being processed, so the customer can terminate the transaction immediately.

[00247] FIG. 25 illustrates a graphical user interface 2510 of a mobile device 2500 that received a push notification message 2520, according to an alternative example embodiment. In this example embodiment, the push notification message 2520 is shown on a locked home screen of the mobile device 2500. In this example, the push notification message says, "You paid $98.50 at Nolita Sushi. Add $1 1.82 to tip 10% (total of $1 10.32). Add $14.78 to tip 15% (total of $1 13.28). Add $19.70 to tip 20% (total of $1 18.20). " The notification message includes the transaction amount (e.g., $98.50), a suggested tip amount using three different tip percentages (based upon 10%, 15%, and 20% of the transaction amount), a total amount for each tip percentage, and the name of the merchant.

[00248] FIG. 26 illustrates a graphical user interface 2610 of a mobile device 2600 that presents a selection of a tip based on recommended tip amounts, according to an example embodiment. A message 2620 on the graphical user interface says, "You paid $98.50 at Nolita Sushi." A plurality of buttons 2630, 2640, 2650 are presented on the graphical user interface 2610 for selection by the customer. Button 2630 corresponds to a selection of a 10% tip for the transaction and is presented after a message of "Add $1 1.82 to tip 10% (total of $1 10.32). " Button 2640 corresponds to a selection of a 15% tip for the transaction and is presented after a message of "Add $14.78 to tip 15% (total of $1 13.28). " Button 2650 corresponds to a selection of a 20%) tip for the transaction and is presented after a message of "Add $19.70 to tip 20% (total of $1 18.20). " The recommended tip amount can also include an average tip amount. For instance, the server can monitor tip amounts from other users and average them together to get an typical tip amount, e.g., 22%. The server can then provide this average tip amount to the user. Note that the average tip amount can vary between merchants. Still further, the suggested tip amount may be determined by the consumer computing system based on average tip amounts given the by the user in the past for that particular merchant or, alternatively, for merchants of that particular MCC. Also, the suggested tip amount may be based upon a classification of the merchant (e.g., upscale merchant may require higher suggested tip) or the profile of the user (e.g., young, middle-class user may see a different suggested tip amount than an older upper middle-class user).

[00249] In an example, a diner finishes his meal at a restaurant and gives his payment card to a waiter. The waiter swipes the card at a point of sale system to capture the payment card information and an amount of a bill. The diner's mobile device receives a push notification that recites the subtotal of $122.45 and three buttons associated with: " 15%: $18.37; total $140.82;" " 18%: $22.04, total $144.49;" and "20%: 24.49, total $146.94. " The diner taps the " 18%" button on the mobile device, which is transmitted back to the consumer computing system. The diner receives a receipt, on which he enters the tip amount corresponding to 18% ($22.04), the total ($144.49), and signs the receipt. If the waiter alters the tip amount to $32.04 and the total to $154.49, then the transaction will be declined by the consumer computing system. The consumer computing system will generate and transmit a notification message warning the diner of the unexpected capture amount.

[00250] FIG. 27 illustrates a data flow diagram 2700 of a warning notification message system, according to an example embodiment, whereby a notification message has been transmitted to a client device with one or more suggested tip amounts, as described in the example embodiment of FIG. 23. In step 2710, upon receiving a message from the client device comprising a selection of a tip amount, the server populates a database record (or "record") for a transaction associated with the account number corresponding to the client device that transmitted the message. The record is populated with the tip amount in a field corresponding to the transaction information.

[00251] In step 2720, the server receives transaction information via the payment rails.

The transaction information contains a first value representing the sub-total amount, a second value representing a tip amount, a third value representing a total amount, and an account number. The server populates a record for the transaction associated with the account number. Although step 2720 is shown as occurring after step 2710, step 2720 can be performed before step 2710, or steps 2710, 2720 can be performed simultaneously.

[00252] In step 2730, the server determines whether the tip amount from the client device matches the second value received over the payment rails to determine whether the user entered a tip amount that is the same as the tip amount transmitted from the merchant.

[00253] In one embodiment, if the server does not receive a message from the client device, the transaction can still be authorized. The server may not receive a message if the client device is off or has no or limited network connectivity. Accordingly, the server may have a time window in which a response is expected from the client device, and if the server times out, the server will not decline the transaction due to a tip amount entry.

[00254] In step 2740, when these values are the same, the server allows the transaction to proceed. The server may relay a transaction request message from the payment rails or an issue processor system to the system of record. The server can update the database accordingly.

[00255] In step 2750, when these values are not the same, the server can prevent the transaction from proceeding. The server may intercept the transaction request message from the payment rails or the issue processor system and prevent the transaction from reaching the system of record. The server can update the database accordingly. [00256] In step 2760, the server can transmit a message to the client device indicating that the transaction was processed by the merchant using a different amount than the amount. This message transmitted to the client device alerts the account holder in a more efficient manner than conventional systems, which may require the account holder to confirm the desired transaction amount with the merchant-submitted transaction weeks later when the account statement is transmitted or otherwise delivered to the account holder. Additionally, example embodiments serve to improve the authorization and transaction payment flow between payment processing systems when conducting transactions involving post-authorization tipping, while also signaling time-sensitive fraudulent activity to unsuspecting consumers.

[00257] Although certain illustrative, non-limiting exemplary embodiments have been presented, various changes, substitutions, permutations, and alterations can be made without departing from the scope of the appended claims. Further, the steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Thus, the scope of the invention should not necessarily be limited by this description.

[00258] Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing," "computing," "transmitting," "receiving," "determining," "displaying," "identifying," "presenting," "establishing," or the like, can refer to the action and processes of a data processing system, or similar electronic device that manipulates and transforms data represented as physical (electronic) quantities within the system' s registers and memories into other data similarly represented as physical quantities within the system's memories or registers or other such information storage, transmission or display devices. The system or portions thereof may be installed on an electronic device.

[00259] The exemplary embodiments can relate to an apparatus for performing one or more of the functions described herein. This apparatus may be specially constructed for the required purposes, or it may comprise a special purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a machine (e.g. computer) readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs and magnetic-optical disks, read only memories (ROMs), random access memories (RAMs) erasable programmable ROMs (EPROMs), electrically erasable programmable ROMs (EEPROMs), magnetic or optical cards, or any type of media suitable for storing electronic instructions for operations on a processor, and each coupled to a bus.

[00260] The exemplary embodiments described herein are described as software executed on at least one server, though it is understood that embodiments can be configured in other ways and retain functionality. The embodiments can be implemented on known devices such as a personal computer, a special purpose computer, cellular telephone, personal digital assistant ("PDA"), a digital camera, a digital tablet, an electronic gaming system, a programmed microprocessor or microcontroller and peripheral integrated circuit element(s), and ASIC or other integrated circuit, a digital signal processor, a hard-wired electronic or logic circuit such as a discrete element circuit, a programmable logic device such as a PLD, PLA, FPGA, PAL, or the like. In general, any device capable of implementing the processes described herein can be used to implement the systems and techniques according to this invention.

[00261] The exemplary embodiments can relate to an apparatus for performing one or more of the functions described herein. This apparatus may be specially constructed for the required purposes or be selectively activated or reconfigured by computer executable instructions stored in non-transitory computer memory medium or non-transitory computer-readable storage medium.

[00262] It is to be appreciated that the various components of the technology can be located at distant portions of a distributed network or the Internet, or within a dedicated secured, unsecured, addressed/encoded or encrypted system. Thus, it should be appreciated that the components of the system can be combined into one or more devices or co-located on a particular node of a distributed network, such as a telecommunications network. As will be appreciated from the description, and for reasons of computational efficiency, the components of the system can be arranged at any location within a distributed network without affecting the operation of the system. Moreover, the components could be embedded in a dedicated machine.

[00263] Furthermore, it should be appreciated that the various links connecting the elements can be wired or wireless links, or any combination thereof, or any other known or later developed element(s) that is capable of supplying or communicating data to and from the connected elements. The term "module" as used herein can refer to any known or later developed hardware, software, firmware, or combination thereof that is capable of performing the functionality associated with that element.

[00264] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

[00265] The use of the terms "a" and "an" and "the" and similar referents in the context of describing the invention (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms "comprising," "having," "including," and "containing" are to be construed as open-ended terms (i.e., meaning "including, but not limited to,") unless otherwise noted. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of all examples, or exemplary language (e.g., "such as") provided herein, is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.

[00266] Presently preferred embodiments of this invention are described herein, including the best mode known to the inventors for carrying out the invention. Variations of those preferred embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description. The inventors expect skilled artisans to employ such variations as appropriate, and the inventors intend for the invention to be practiced otherwise than as specifically described herein. Accordingly, this invention includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the invention unless otherwise indicated herein or otherwise clearly contradicted by context.

[00267] Although the present technology has been described in detail for the purpose of illustration based on what is currently considered to be the most practical and preferred implementations, it is to be understood that such detail is solely for that purpose and that the technology is not limited to the disclosed implementations, but, on the contrary, is intended to cover modifications and equivalent arrangements that are within the spirit and scope of the appended claims. For example, it is to be understood that the present technology contemplates that, to the extent possible, one or more features of any implementation can be combined with one or more features of any other implementation.

Claims

We claim:

1. A method for logically creating sub-accounts for processing payments comprising: establishing, by a server upon receiving a request from a user computing device executing an application, at least one sub-account associated with an account maintained by a financial institution, the request including a sub-account identifier, wherein the account and the sub-account correspond to a routing transit number, account number, and an account balance, maintained in a record in a system of record server;

storing, by the server in an account record in a database, the sub-account identifier associated with the sub-account having a sub-account balance, wherein the sub-account balance is an allocated amount of the account balance, wherein the sub-account is associated with the routing transit number and the account number of the account, and wherein the account record maintains a copy of the routing transit number, the account number, and the account balance; synchronizing, by the server, the copy of the account balance with the account balance maintained in the record in the system of record server;

upon receiving a payment request, comprising an amount, from a merchant computing device over a card-issuer network, and before the payment request reaches the system of record server, generating, by the server, a graphical user interface for display by the application, wherein the graphical user interface presents an interactive element for selection of at least one sub-account from which to withdraw funds in response to the payment request;

receiving, by the server, a selected sub-account identifier from the application executed by the user computing device;

identifying, by the server , a sub-account associated with the selected sub-account identifier;

generating, by the server an authorization message based on at least whether the identified sub-account balance is greater than the amount of the payment request;

transmitting, by the server over the card-issuer network, the authorization message to the merchant computing device;

upon approving the payment request, simultaneously updating, by the server, the identified sub-account balance associated with the identified sub-account and the copy of the account balance; simultaneously transmitting, by the server to the system of record server, a message to reflect the approval of the payment request and update a balance stored in the system of record server; and

synchronizing, by the server, the copy of the account balance with the account balance maintained in the record in the system of record server.

2. The method according to claim 1 further comprising: polling, by the server, the system of record server to determine whether the account balance maintained in the record in the system of record server received one or more credits, wherein, if the account balance maintained in the record in the system of record server received one or more credits, applying the one or more credits to one or more sub-accounts established by the server.

3. The method according to claim 2 further comprising applying, by the server, at least one credit to at least two sub-accounts on a percentage basis.

4. The method according to claim 2 further comprising receiving, at the server, a command to transfer at least a portion of the one or more credits to a different sub-account.

5. The method according to claim 2 further comprising:

receiving, at the server, a plurality of financial transactions comprising credits and debits; displaying, by a display of the user computing device, the credits and the debits in a conversational view of a second graphical user interface on the user computing device.

comparing, by the server, the plurality of debit transactions with one or more previous debit transactions to determine whether there is a match;

generating, by the server if there is a match, a predicted debit transaction based on the matched debit transactions; and

recording, at the server, the predicted debit transaction in the database.

6. The method according to claim 5 further comprising:

receiving, at the server, a current financial transaction comprising a current transaction amount; identifying, by the server, one or more predicted transactions, wherein each predicted transaction comprises a respective amount;

summing, by the server, a balance of the account and the amounts of the one or more predicted transactions; and

generating, by the server, a predicted balance based on the summed balance and amounts. generating, by the server in response to receiving the current financial transaction, a current predicted balance by summing the current transaction amount and the predicted balance; comparing, by the server, the current predicted balance to a predetermined amount; and transmitting, by the server if the current predicted balance is less than the predetermined amount, a notification to the user computing device notifying the user computing device that the predicted balance will be less than the predetermined amount.

7. A method comprising:

upon receiving a plurality of transactions comprising transaction data from a merchant- acquirer server or a system of record server, generating, by a server, in a transaction database a transaction record of each transaction, wherein the transaction record of each transaction comprises a credit or a debit to a copy of an account balance, wherein the account balance is maintained by the system of record server;

identifying, by the server, a first transaction record and a second transaction record in the transaction database having sufficiently similar transaction data to qualify as recurring transactions, based on one or more predetermined criteria stored in the transaction database; generating, by the server if the first transaction and the second transaction qualify as recurring transactions, a potential transaction record comprising potential transaction data based on the first transaction record and the second transaction record;

storing, by the server, in the transaction database, the potential transaction record, wherein the potential transaction record comprises an indication that the potential transaction data represents a potential transaction that has not yet occurred;

receiving, by the server, a payment request from a user computing device or a merchant- acquirer computing device;

identifying, by the server, a sub-account associated with the payment request; upon approving the payment request, simultaneously updating, by the server, a subaccount balance of the identified sub-account and the copy of the account balance;

simultaneously transmitting, by the server to the system of record server, a message to reflect the approval of the payment request and update the balance stored in the system of record server; and

8. The method of claim 7 further comprising, in response to receiving the payment request:

retrieving, by the server, one or more transaction records comprising potential transaction data from the transaction database;

applying, by the server, the retrieved one or more transaction records comprising potential transaction data to a current balance of the account to determine a predicted balance; and

generating, from the server, to the user computing device, a second message for display on a graphical user interface of the user computing device upon determining that the payment request would cause the predicted balance to cross a threshold value.

9. The method according to claim 7 further comprising: polling, by the server, the system of record server to determine whether the account received one or more credits, wherein, if the account received one or more credits, applying the one or more credits to one or more subaccounts established by the server.

10. The method according to claim 9 further comprising: receiving a command to transfer at least a portion of the one or more credits to a different sub-account.

11. The method according to claim 9 further comprising: displaying, on the user computing device, at least a portion of the transaction data in a conversational view of the graphical user interface on the user computing device.

12. The method according to claim 7 further comprising: crediting or debiting, by the server, two or more sub-accounts on a percentage basis upon receiving a transaction.

13. The method according to claim 7 further comprising:

receiving, at the server, an additional credit to the account, wherein an amount of the additional credit is sufficient to pay for the potential transaction and raise the account balance to greater than the threshold value; and

generating, from the server in response to receiving the additional credit, to the user computing device, a message for display on a graphical user interface of the user computing device, upon determining that the account balance is sufficient to satisfy the potential transaction.

14. A computer-readable storage medium storing instructions that, when executed by a computing system, cause the computing system to perform operations comprising:

receiving, at a server, a financial transaction comprising an amount, a transaction type, and an account number for an account, wherein the account comprises a balance;

determining, at the server, whether the financial transaction is a credit transaction or a debit transaction based on the transaction type;

identifying, at the server, one or more sub-accounts to update according to the amount in the financial transaction, wherein each sub-account is associated with the account, wherein the sub-account comprises a balance containing at least a portion of the account balance;

retrieving, by the server from a database, one or more sub-account records corresponding to the identified one or more sub-accounts;

crediting, at the server in response to each credit transaction, at least one sub-account balance of the retrieved one or more sub-account records according to the amount in the financial transaction;

debiting, at the server in response to each debit transaction, at least one sub-account balance of the retrieved one or more sub-account records according the amount in the financial transaction;

storing, by the server in the database, the retrieved one or more sub-account records comprising the credited or debited at least one sub-account balance; and simultaneously synchronizing, by the server, the account balance with a copy of the account balance maintained in a record in a system of record server.

15. The computer-readable storage medium according to claim 14, the operations further comprising:

receiving, at the server, a second financial transaction from a first user device associated with the account, wherein the second financial transaction is a funds transfer transaction comprising a first sub-account identifier and a second sub-account identifier;

debiting, at the server in response to the second financial transaction, at least one subaccount associated with the account and the first sub-account identifier; and

crediting, at the server in response to the second financial transaction, at least one subaccount associated the second sub-account identifier.

16. The computer-readable storage medium according to claim 14, wherein the crediting comprises applying funds two or more sub-accounts on a percentage basis upon receiving a second financial transaction.

17. The computer-readable storage medium according to claim 14, the operations further comprising:

receiving, at the server, from a merchant-acquirer server, the financial transaction; and transmitting, from the server, at least a portion of the financial transaction to a system of record server.

18. The computer-readable storage medium according to claim 14, the operations further comprising:

receiving, at the server, a second financial transaction comprising a second amount, a second transaction type, and the account number for the account;

comparing, at the server, the second financial transaction to the financial transaction; and storing, at the server, a recurring transaction, if the second financial transaction matches the financial transaction.

19. The computer-readable storage medium according to claim 14, the operations further comprising:

generating, by the server, information to be presented in a conversational view on a user device, wherein the information comprises data related to the financial transaction.

20. The computer-readable storage medium according to claim 14, the operations further comprising:

receiving, from a user device associated with the account, an instruction to identify the financial transaction as a recurring transaction.

21. The computer-readable storage medium according to claim 14, the operations further comprising:

identifying, by the server, one or more recurring transactions, wherein each recurring transaction comprises a respective amount;

summing, by the server, a balance of the account and the amounts of the one or more recurring transactions; and

generating, by the server, a predicted balance based on the summed balance and amounts.

22. A system for separating accounts into sub-accounts comprising:

a server, comprising a memory, a processor, and a transceiver, configured to:

receive from a client device one or more requests to open an account and one or more sub-accounts associated with the account;

communicate with a system of record server to establish the account;

communicate, with a merchant-acquirer server, transaction data corresponding to a plurality of transactions;

store the transaction data in one or more transaction records; and

simultaneously communicate with the system of record server the transaction data corresponding to the plurality of financial transactions; and

one or more databases, configured to: receive instructions, from the server, to store information corresponding to the account, including sub-account identifiers corresponding to the sub-accounts, in one ore more sub-account records; and

store the transaction data in the one or more transaction records.

23. The system according to claim 22, wherein the server is further configured to:

receive a first financial transaction from a first client device associated with the account, wherein the first financial transaction is a funds transfer transaction comprising a first subaccount identifier and a second sub-account identifier;

debit, in response to the first financial transaction, at least one sub-account associated with the account and the first sub-account identifier; and

credit, in response to the first financial transaction, at least one sub-account associated the second sub-account identifier.

24. The system according to claim 22, wherein the server is further configured to:

receive a first financial transaction comprising a first amount, a first transaction type, and an account number for the account;

receive a second financial transaction comprising a second amount, a second transaction type, and the account number for the account;

compare the first financial transaction to the second financial transaction; and

store, in the database, a recurring transaction, if the first financial transaction matches the second financial transaction.

25. The system according to claim 22, wherein the server is further configured to:

credit two or more sub-accounts on a percentage basis upon receiving a first financial transaction.

26. The system according to claim 22, wherein the server is further configured to:

generate information to be presented in a conversational view on the client device, wherein the information comprises data related to the plurality of financial transactions.

27. The system according to claim 22, wherein the server is further configured to:

receive, from a user device associated with the account, an instruction to identify a financial transaction as a recurring transaction.

28. The system according to claim 22, wherein the server is further configured to:

identify one or more recurring transactions, wherein each recurring transaction comprises a respective amount;

sum a balance of the account and the amounts of the one or more recurring transactions; generate a predicted balance based on the summed balance and amounts; and

transmit, to the client device, the predicted balance for display on the client device.

29. The system according to claim 28, wherein the server is further configured to:

receive a current financial transaction comprising a current transaction amount;

generate, in response to receiving the current financial transaction, a current predicted balance by summing the current transaction amount and the predicted balance;

compare the current predicted balance to a predetermined amount; and

transmit, if the current predicted balance is less than the predetermined amount, a notification to the client device notifying the client device that the predicted balance will be less than the predetermined amount.

30. A computer-implemented method of generating payment card numbers for individual user accounts held at banking entity, the method comprising:

generating, by a computer, during registration process, in a user database a user record based upon user data received from a client device via registration graphical user interface (GUI) presented on the client device, the user record comprising one or more data fields including a user identifier (ID) that identifies the user record, the user data associated with the user, an amount of funds available to the user, and one or more payment card numbers;

transmitting, by the computer, to a banking server of a third-party financial institution a request to open a banking account for the user, the request containing the user data associated with the user;

receiving, by the computer, from the client device a request to generate a payment card number, wherein the request contains device data associated with the client device that identifies the device, and wherein the request is accompanied by a graphical depiction of a payment card having the payment card number, wherein the graphical depiction is generated according to one or more inputs to a graphical user interface of the client device;

generating, by the computer, a set of random digits based upon one or more input parameters and using a random number generator algorithm;

generating, by the computer, the payment card number to include a bank identification number (BEST) prefix that comprises a predetermined set of digits;

determining, by the computer, that the payment card number does not match at least one second payment card number, wherein the computer continues to generate a next set of random digits for the payment card number until the payment card number does not match the at least one second payment card number;

generating, by the computer, using a tokenization algorithm and based upon a random number value, a token representing the payment card number;

receiving, by the computer, from the banking server, a bank-customer ID uniquely identifying the user in the banking server and account data for the banking account, the account data including an account number and a routing number;

storing, by the computer, into the one or more data fields of the user record in the user database: the bank-customer ID, the account data, the token representing the payment card number, and the payment card number;

transmitting, by the computer, the user data, the token representing the payment card number, and the graphical depiction of the payment card having the payment card number to a card-printing entity server for printing a physical payment card having the payment card number, the user data including a shipping address for the physical payment card;

transmitting, by the computer, to an issuer processor server coupled to an issuer database, the token representing the payment card number, and the user data associated with the user; transmitting, by the computer, the token representing the payment card number to the client device, wherein the client device is configured to display a graphical representation of the payment card number;

receiving, by the computer, from the client device an activation request instructing the computer to update an activation status for the payment account number in the user record; updating, by the computer, the activation status for the payment account number in the user record to indicate that the payment account number is activated; and

authorizing, by the computer, a transaction request containing transaction data received from a merchant computing device, when the transaction request identifies the payment card number or the token representing the payment card number, when the computer determines that the activation status of the payment account number indicates that the payment account number is activated.

31. The method according to claim 30, wherein receiving the request to generate the payment card number further comprises:

receiving, by the computer, one or more payment limitation parameters associated with the payment card number; and

storing, by the computer, the one or more payment limitation parameters associated with the payment card number into the user record of the user database,

wherein the computer further authorizes the transaction request when the transaction data of the transaction request received from the merchant computing device satisfies the one or more payment limitation parameters.

32. The method according to claim 31, wherein the computer declines the transaction request when the transaction data fails to satisfy the one or more payment limitation parameters.

33. The method according to claim 31, wherein a payment limitation parameter of the one or more payment limitation parameters is selected from the group consisting of a merchant name and a merchant category code.

34. A computer-implemented method of generating user payment card numbers for an account held at a banking entity for a service provider entity, the method comprising:

generating, by a computer of a service provider entity, in a user database during a registration process, a user record based upon user data received from a client device via registration graphical user interface (GUI) presented on the client device, the user record comprising one or more data fields including a user identifier (ID) that identifies the user record, the user data associated with a user, an amount of funds available to the user, and one or more payment card numbers; receiving, by the computer, from the client device a request to generate a payment card number, wherein the request contains client device data associated with the client device that identifies the device, and wherein the request is accompanied by a graphical depiction of a payment card having the payment card number, wherein the graphical depiction is generated according to one or more inputs to a graphical user interface of the client device;

generating, by the computer, the payment card number that includes a bank identification number (BEST) prefix that comprises a predetermined set of digits; generating, by the computer, using a tokenization algorithm and based upon a random number value, a token representing the payment card number;

storing, by the computer, the token and the payment card number into one or more data fields of the user record in the user database;

transmitting, by the computer, to an issuer processor server coupled to an issuer database, the token representing the payment card number, and the user data associated with the user; transmitting, by the computer, to the client device the token representing the payment card number, wherein the client device is configured to display a graphical representation of the payment card number;

receiving, by the computer, from the client device an activation request instructing the computer to update an activation status for the payment card number in the user record;

updating, by the computer, the activation status for the payment account number in the user record to indicate that the payment account number is activated; and

authorizing, by the computer, a transaction request containing transaction data received from a merchant computing device, when the transaction request identifies the payment card number or the token representing the payment card number, and when the computer determines that the activation status of the payment account number indicates that the payment account number is activated.

35. The method according to claim 34, wherein receiving the request to generate the payment card number further comprises:

receiving, by the computer, one or more payment limitation parameters associated with the payment card number; and storing, by the computer, the one or more payment limitation parameters associated with the payment card number into the user record of the user database,

36. The method according to claim 35, wherein the computer declines the transaction request when the transaction data fails to satisfy the one or more payment limitation parameters.

37. The method according to claim 35, wherein a payment limitation parameter of the one or more payment limitation parameters is selected from the group consisting of a merchant name and a merchant category code.

38. The method according to claim 34, further comprising determining, by the computer, that the payment card number does not match at least one second payment card number based upon a check algorithm using a check digit included in the payment card number, wherein the computer continues to generate a next set of random digits for the payment card number until the payment card number does not match the at least one second payment card number according to the check algorithm.

39. The method according to claim 34, further comprising transmitting, by the computer, the user data and the token representing the payment card number, to a card-printing entity server for printing a physical payment card having the payment card number, the user data including a shipping address for the physical payment card.

40. A computer-readable storage medium of storing instructions that, when executed by a computer, cause the computer to execute the operations of:

receiving, by a computer, from a client device associated with a user, a request for a card number associated with the user;

generating, by the computer, the card number using a random number generator, wherein the computer continually generates the card number until the computer determines that the card number does not match at least one second payment card number; generating, by the computer, a token representing the card number using a tokenization algorithm, wherein the token includes the card number;

storing, by the computer, the token and the payment card number into a user record stored in a database configured to store one or more user records of one or more users respectively;

transmitting, by the computer, the token representing the payment card number to the client device of the user and to a server of an issuer processor;

receiving, by the computer, from a merchant computing device via one or more payment network rails a transaction request message containing transaction data identifying the card number; and

transmitting, by the computer, to the merchant computing device, a payment authorization response message responsive to the transaction request message containing transaction data identifying the card number, wherein the computer generates the response message based upon one or more transaction authorization parameters.

41. The computer-readable storage medium according to claim 40, the instructions further causing the computer to execute the operations of:

determining, by the computer, an activation status of the card number according to a status of the card number in the user record,

wherein the one or more transaction authorization parameters includes the activation status of the card number.

42. The computer-readable storage medium according to claim 41, the instructions further causing the computer to execute the operations of:

determining, by the computer, that the activation status of the card number in the user record indicates the card number is not activated; and

transmitting, by the computer, to the merchant computing device a payment declined message responsive to the transaction request message, in response to determining that the activation status of the card number is not activated.

43. The computer-readable storage medium according to claim 41, the instructions further causing the computer to execute the operations of: receiving, by the computer, an activation request from the client device; and updating, by the computer, the activation status of the card number in the user record, in response to the activation request,

wherein the activation status of the card number is updated to indicate the card number is activated.

44. The computer-readable storage medium according to claim 43, the instructions further causing the computer to execute the operations of:

determining, by the computer, that the activation status of the card number in the user record indicates that the card number is activated; and

transmitting, by the computer, to the merchant computing device the payment authorization response message in response to the computer determining that the activation status of the card number is activated.

45. The computer-readable storage medium according to claim 40, the instructions further causing the computer to execute the operations of:

transmitting, by the computer, a request for a physical payment card having the card number to a server of a card-printing entity, the request for the physical payment card including at least a portion of user data associated with the user stored in the user record containing an address.

46. The computer-readable storage medium according to claim 45, the instructions further causing the computer to execute the operations of:

receiving, by the computer, from the client device, one or more graphical depictions of the physical payment card associated with the card number,

wherein the request for the physical payment card further includes the one or more graphical depictions of the physical payment card.

47. The computer-readable storage medium according to claim 40, the instructions further causing the computer to execute the operations of:

updating, by the computer, the user record according to an amount of funds indicated by the transaction request message, upon transmitting a payment authorization response message to the merchant computing device; and transmitting, by the computer, to a banking server the amount of funds indicated by the transaction request message, and instructions to update an account of a service provider entity according to the amount of the transaction request message.

48. The computer-readable storage medium according to claim 40, the instructions further causing the computer to execute the operations of:

transmitting, by the computer, a request for a user account to a banking server;

updating, by the computer, the user record for the user according to account data received from the banking server; and

upon the computer transmitting a payment authorization response message to the merchant computing device, transmitting, by the computer, an amount of the transaction request message and the account data to the banking server.

49. The computer-readable storage medium according to claim 40, the instructions further causing the computer to execute the operations of:

storing, by the computer, into the user record, one or more payment limitation parameters associated with the card number and received from the client device,

wherein the one or more transaction authorization parameters includes the one or more payment limitation parameters of the user.

50. A computing system comprising:

a user database hosted on one or more computing devices comprising non-transitory machine-readable storage media configured to store one or more user records of one or more users respectively; and

a server coupled to the user database and comprising a processor configured to:

in response to receiving a request for a card number from a client device, generate the card number using a random number generator, wherein the computer is configured to continually generate the card number according to the random number generator until the computer determines that the card number does not match at least one second card number;

generate using a tokenization algorithm a token representing the card number; store into a user record data comprising the token and the card number; transmit to the client device and to a server of an issuer processor the token representing the card number;

receive a transaction request message containing transaction data identifying the card number from a merchant computing device via one or more payment network rails; and transmit to the merchant computing device a payment authorization response message responsive to the transaction request message, wherein the computer generates the payment authorization response message based upon one or more transaction authorization parameters and the data stored in the user record.

51. The system according to claim 50, wherein the server is further configured to determine an activation status of the card number according to the user record, and wherein the one or more transaction authorization parameters includes the activation status of the card number.

52. The system according to claim 51, wherein, upon the server determining that the activation status of the card number in the user record indicates the card number is not activated, the server is further configured to transmit to the merchant computing device a payment declined message responsive to the transaction request message.

53. The system according to claim 51, wherein the server is further configured to:

receive an activation request from the client device; and

update the activation status of the card number in the user record in response to the activation request, wherein the activation status of the card number updated to indicate the card number is activated.

54. The system according to claim 53, wherein, upon the server determining that the activation status of the card number in the user record indicates that the card number is activated, the server is further configured to transmit to the merchant computing device a payment authorization message in the response message.

55. The system according to claim 50, wherein the server is further configured to: transmit a request for a physical payment card having the card number to a second server of a card-printing entity, the request for the physical payment card including at least a portion of the user data stored in the user record containing an address.

56. The system according to claim 55, wherein the server is further configured to receive, from the client device, one or more graphical depictions of the physical payment card associated with the card number, and

57. The system according to claim 50, wherein the server is further configured to:

update the user record according to an amount of funds for the transaction indicated by the transaction request message, upon the server transmitting a payment authorization response message to the merchant computing device; and

transmit to a banking server the amount of funds for the transaction, and instructions to update an account of a service provider entity according to the amount of funds for the transaction.

58. The system according to claim 50, wherein the server is further configured to:

transmit a request for a user account to a banking server, and update the user record for the user according to account data received from the banking server; and

wherein, upon the computer transmitting a payment authorization response message to the merchant computing device, the server is further configured to transmit an amount of the transaction and the account data to the banking server.

The system according to claim 50, wherein the server is further configured to store into the user record, one or more payment limitation parameters associated with the card number and received from the client device, and wherein the one or more transaction authorization parameters includes the one or more payment limitation parameters of the user.

60. A method for displaying a notification message on a mobile device, the method comprising:

upon receiving, by a server, a payment request authorization message transmitted over a issue processor system network and initiated from a merchant point of sale system, the payment request authorization message comprising a payment card number and a transaction amount of a transaction:

determining, by the server, whether a merchant category code of a merchant associated with the merchant point of sale system that initiated the payment request authorization message matches one of a set of merchant category codes associated with a tip amount field;

when the payment request authorization message is associated with a merchant category code associated with the tip amount field:

automatically generating, by the server, a notification message comprising a

recommended tip amount based upon a percentage of the transaction amount in the payment request authorization message;

identifying, by the server, in a profile database, an address of a mobile device associated with the payment card number;

pushing, by the server, the notification message containing the recommended tip amount to the mobile device upon receiving the payment request authorization message and before authorization of the transaction;

upon receipt of a reply message from the mobile device, updating, by the server, a database record associated with the transaction to contain a value of a selected tip amount;

authorizing, by the server, the payment request authorization message when a merchant tip amount in the payment request authorization message is the same as the selected tip amount represented by the value in the database record; and

generating, by the server, a decline request when the merchant tip amount in the payment request authorization message is not the same as the selected tip amount represented by the value in the database record.

62. The method according to claim 61, further comprising populating, by the server, the notification message with a first value representing the recommended tip amount and a second value representing a second recommended tip amount.

63. The method according to claim 62, wherein the first value and the second value of the notification message are configured to be populated in a message for display on a user interface of the mobile device.

64. The method according to claim 63, whereby the user interface populates the message for display having the first value associated with a first selectable link and the second value associated with a second selectable link.

65. The method according to claim 61, wherein the notification message comprises a text message or an e-mail message.

66. A computer-implemented method comprising:

receiving, by a consumer computing system server, an authorization message transmitted over a issue processor system network, the authorization message comprising a payment card number and a transaction amount of a transaction;

generating, by the consumer computing system server, a notification message comprising a recommended tip amount based upon a percentage of the transaction amount in the

authorization message;

identifying, by the consumer computing system server, an address of a mobile device associated with the payment card number; and

pushing, by the consumer computing system server, the notification message containing the recommended tip amount to the mobile device upon receiving the authorization message.

67. The method according to claim 66, further comprising populating, by the consumer computing system server, the notification message with a first value representing the

recommended tip amount and a second value representing a second recommended tip amount.

68. The method according to claim 67, wherein the first value and the second value of the notification message are configured to be populated in a message for display on a user interface of the mobile device.

69. The method according to claim 68, whereby the user interface populates the message for display having the first value associated with a first selectable link and the second value associated with a second selectable link.

70. The method according to claim 69, wherein upon receipt of a reply message from the mobile device, updating, by the consumer computing system server, a database record associated with the transaction to contain a value of a selected tip amount.

71. The method according to claim 70, further comprising authorizing, by the consumer computing system server, the authorization message when a merchant tip amount in the payment request authorization message is the same as the selected tip amount represented by the value in the database record.

72. The method according to claim 71, further comprising generating, by the server, a decline request when the merchant tip amount in the payment request authorization message is not the same as the selected tip amount represented by the value in the database record.

73. The method according to claim 68, wherein the notification message comprises a text message or an e-mail message.

74. A notification system comprising:

a network interface through which to communicate with one or more mobile devices; a processor coupled to the network interface; and

a memory coupled to the processor, the memory storing instructions comprising:

instructions for receiving a payment request authorization message transmitted over a issue processor system network initiated from a merchant point of sale system, the payment request authorization message comprising a payment card number and a transaction amount of a transaction;

instructions for determining, upon receiving the payment request authorization message, whether an industry category of a merchant associated with a merchant point of sale system that initiated the payment request authorization message matches one of a set of industry categories associated with a tip amount field;

instructions for automatically generating a notification message comprising a

recommended tip amount based upon a percentage of the transaction amount in the payment request authorization message when the payment request authorization message is associated with an industry category associated with the tip amount field;

instructions for identifying, in a profile database, an address of a mobile device associated with the payment card number; and

instructions for pushing the notification message containing the recommended tip amount to the mobile device upon receiving the payment request authorization message and before authorization of the transaction.

75. The notification system according to claim 74, wherein the memory further comprises instructions for populating the notification message with a first value representing the recommended tip amount and a second value representing a second recommended tip amount.

76. The notification system according to claim 75, wherein the first value and the second value of the notification message are configured to be populated in a message for display on a user interface of the mobile device.

77. The notification system according to claim 76, whereby the user interface populates the message for display having the first value associated with a first selectable link and the second value associated with a second selectable link.

78. The notification system according to claim 77, wherein the memory further comprises instructions for updating a database record associated with the transaction to contain a value of a selected tip amount upon receipt of a reply message from the mobile device.

79. The notification system according to claim 78, wherein the memory further comprises instructions for authorizing the payment request authorization message when a merchant tip amount in the payment request authorization message is the same as the selected tip amount represented by the value in the database record.

80. The notification system according to claim 79, wherein the memory further comprises instructions for generating a decline request when the merchant tip amount in the payment request authorization message is not the same as the selected tip amount represented by the value in the database record.

81. The notification system according to claim 74, wherein the notification message comprises a text message or an e-mail message.

82. A computer-readable storage medium of a server storing instructions that, when executed by a computing system, cause the computing system to perform a method comprising: receiving, by the server, a payment request authorization message transmitted over a issue processor system network initiated from a merchant point of sale system, the payment request authorization message comprising a payment card number and a transaction amount of a transaction;

determining, by the server, upon receiving the payment request authorization message, whether an industry category of a merchant associated with the merchant point of sale system that initiated the payment request authorization message matches one of a set of industry categories associated with a tip amount field;

automatically generating, by the server, a notification message comprising a

identifying, by the server, in a profile database, an address of a mobile device associated with the payment card number; and

pushing, by the server, the notification message containing the recommended tip amount to the mobile device upon receiving the payment request authorization message and before authorization of the transaction.

83. The computer-readable storage medium according to claim 82, further comprising populating, by the server, the notification message with a first value representing the

84. The computer-readable storage medium according to claim 83, wherein the first value and the second value of the notification message are configured to be populated in a message for display on a user interface of the mobile device.

85. The computer-readable storage medium according to claim 84, whereby the user interface populates the message for display having the first value associated with a first selectable link and the second value associated with a second selectable link.

86. The computer-readable storage medium according to claim 85, wherein upon receipt of a reply message from the mobile device, updating, by the server, a database record associated with the transaction to contain a value of a selected tip amount.

87. The computer-readable storage medium according to claim 86, further comprising authorizing, by the server, the payment request authorization message when a merchant tip amount in the payment request authorization message is the same as the selected tip amount represented by the value in the database record.

88. The computer-readable storage medium according to claim 87, further comprising generating, by the server, a decline request when the merchant tip amount in the payment request authorization message is not the same as the selected tip amount represented by the value in the database record.

89. The computer-readable storage medium according to claim 82, wherein the notification message comprises a text message or an e-mail message.

90. A method comprising:

generating, by a server, in a transaction database a database record of each transaction of a plurality of transactions comprising transaction data from a merchant-acquirer server or a system of record server, wherein the record of each transaction comprises a credit or a debit to an account;

generating, by the server, a graphical user interface for display by an application executing on a user computing device that presents a summary of the transactions in a conversational view, wherein the conversational view comprises two columns, wherein debits and credits are presented in different columns, and wherein each debit or credit is displayed in a corresponding polygon having a field that is populated with transaction data from the transaction database;

determining, by the server, a scheduled transaction status of a scheduled transaction record of the transaction database, wherein the scheduled transaction record comprises a transaction to be scheduled;

generating, by the server, a scheduled transaction polygon of the conversational view on the graphical user interface for display on the user computing device, the scheduled transaction polygon comprising scheduled transaction data from the scheduled transaction record, the scheduled transaction data including a scheduled transaction status,

wherein, when the scheduled transaction status is paid, the scheduled transaction polygon comprises text displaying a debit amount and a payee or subject of the transaction, and

wherein, when the scheduled transaction status is unpaid, the scheduled transaction polygon comprises one or more interface elements configured to receive a selection to complete the scheduled transaction from the application executing on the user computing device;

upon receiving, by the server from the user computing device executing the application, an activation of the one or more interface elements indicating the selection to complete the scheduled transaction:

generating, by the server, a transaction request to complete the scheduled transaction; updating, by the server, the scheduled transaction status of the scheduled transaction record to reflect the generation of the transaction request; and

updating, by the server, the text of the scheduled transaction polygon based upon the updated scheduled transaction status.

91. The method of claim 90, wherein the selection of the one or more interface elements comprises detecting a touch of the scheduled transaction polygon on the graphical user interface.

92. The method of claim 90, wherein a color of a polygon represents the scheduled transaction status of the scheduled transaction.

93. The method of claim 90, further comprising generating a second polygon comprising text displaying a reminder to make a payment, wherein the second polygon further includes a button to enable completing the payment.

94. The method of claim 90, wherein the scheduled transaction polygon further includes an indication that the scheduled transaction is a recurring transaction.

95. One or more computer-readable storage media storing instructions that, when executed by a computing system, cause the computing system to perform operations comprising: receiving, at a server, a plurality of transactions from at least one merchant-acquirer server or a system of record server, the transactions associated with an account having an account balance;

recording, by the server, a plurality of transaction records in a database, wherein the plurality of transaction records correspond to respective transactions of the plurality of transactions;

receiving, by the server from a client application executing on a client device, a request to generate a conversational view of at least a portion of the plurality of transaction records;

selecting, by the server, the portion of the plurality of transaction records; and

transmitting, from the server in response to the request, the selected transaction records to the client application executing on the client device for generating the conversational view of the portion of the plurality of transaction records, wherein the conversational view comprises a graphical user interface of a plurality of polygons corresponding to respective transaction records, the conversational view for display by the client application executing on the client device.

96. The one or more computer-readable storage media according to claim 95, the operations further comprising:

comparing, by the server, the plurality of transactions to determine whether there are one or more matching transactions;

identifying, by the server, one or more groups of the one or more matching transactions; generating, by the server for each group of the one or more matching transaction records, one or more recurring transactions that are at least similar to a corresponding group of the one or more matching transactions; and

storing, by the server, the one or more recurring transaction records in the database, wherein each recurring transaction record comprises an amount.

97. The one or more computer-readable storage media according to claim 96, wherein the conversational view includes a recurring transaction in a polygon that identifies the recurring transaction as recurring.

98. The one or more computer-readable storage media according to claim 96, the operations further comprising:

receiving, at the client application, a request to display a predicted balance, the request comprising a future date of the predicted balance;

retrieving, by the client application, one or more recurring transaction records corresponding to recurring transactions that are scheduled to occur between a present time and the future date;

computing, by the client application, a sum of the account balance and the amounts stored in the retrieved recurring transaction records to generate the predicted balance; and

presenting, by the client application, the predicted balance in response to the request to display the predicted balance.

99. The one or more computer-readable storage media according to claim 95, wherein the plurality of transactions include debits and credits, and the conversational view presents the debits and credits in separate columns.

100. The one or more computer-readable storage media according to claim 95, wherein the plurality of transactions include messages other than debits and credits.

101. The one or more computer-readable storage media according to claim 100, wherein the messages are selected from the group consisting of reminders to pay bills, notices of insufficient funds, messages from third parties, balance updates, notices of upcoming payments, and notices of recurring payments.

102. The one or more computer-readable storage media according to claim 95, wherein at least one of the plurality of transactions is a reminder to pay a bill, and the reminder to pay the bill includes a selectable graphical user interface element to pay the bill.

103. The one or more computer-readable storage media according to claim 95, the operations further comprising:

receiving, at the client application from an input device, a selection of one of the plurality of transactions;

retrieving, by the client application, meta data associated with the selected transaction; and

transmitting, by the client device to the display of the client device, the meta data associated with the selected transaction.

104. A computer-implemented method comprising:

receiving, at a server logically located between a merchant-acquirer server and a system of record server, a plurality of financial transactions;

storing, at the server, a transaction record in a database, wherein each transaction record comprises data for a respective financial transaction;

receiving, at a client application upon a selection of a linked object on a user interface, a request to view data for a plurality of the transaction records;

generating, by the server, one or more messages comprising data from the plurality of transaction records; transmitting, by the server to a client device, the one or more messages comprising data from the plurality of transaction records;

generating, by the client application, a conversational view on the user interface of the data from the plurality of transaction records; and

transmitting, by the client application, instructions to display the data from the plurality of transaction records in the conversational view.

105. The computer-implemented method of claim 104, wherein the messages are selected from the group consisting of debits, credits, reminders to pay bills, notices of insufficient funds, messages from third parties, balance updates, notices of upcoming payments, and notices of recurring payments.

106. The computer-implemented method according to claim 104 further comprising: comparing, by the server, the plurality of transactions to determine whether there are one or more matching transactions;

identifying, by the server, one or more groups of the one or more matching transactions; generating, by the server, for each group of the one or more matching transactions, one or more recurring transactions that are at least similar to a corresponding group of the one or more matching transactions; and

storing, by the server, the one or more recurring transactions in the database.

107. The computer-implemented method according to claim 104 further comprising: receiving, at the client application, a request to display a predicted balance;

determining, by the client device, a future date for the predicted balance;

summing, by the client device, one or more recurring transactions that are scheduled to occur between a present time and the future date to generate the predicted balance; and

presenting, by the client device, the predicted balance in response to the request to display the predicted balance.

108. The computer-implemented method according to claim 104, wherein the plurality of financial transactions include debits and credits, and the conversational view presents the debits and credits in separate columns.

109. The computer-implemented method according to claim 104, wherein at least one of the plurality of transactions is a reminder to pay a bill, and the reminder to pay the bill includes a selectable graphical user interface element to pay the bill.

110. A system comprising:

a server comprising:

a server memory;

one or more server processors;

a server transceiver configured to receive a plurality of financial transactions from at least one merchant-acquirer server and a system of record;

a database configured to store transaction data contained in the plurality of financial transactions; and

a client application configured to run on a client device, the client device comprising a processor communicatively coupled to a client memory and operable to execute instructions stored in the client memory, the client application configured to:

communicate with the server to send and to receive the transaction data;

receive a request to display a conversational view of the transaction data; and

present a graphical user interface, in response to the request, including the conversational view of the transaction data, wherein the conversational view includes one or more polygons, with each polygon configured to contain transaction data from the database.

111. The system according to claim 110, wherein the client application is further configured to receive an input comprising a scheduled financial transaction comprising a payment date, and the client application is further configured to transmit the scheduled financial transaction to the server; and the one or more server processors and the server memory are further configured to pay the scheduled financial transaction when a current date matches the payment date of the scheduled financial transaction.

112. The system according to claim 111, wherein the client application is further configured to display an additional polygon corresponding to the scheduled financial transaction to the conversational view.

113. The system according to claim 112, wherein the server transceiver is further configured to transmit a message to the client device indicating payment of the scheduled financial transaction.

114. The system according to claim 113, wherein the client application is further configured to update the polygon corresponding to the scheduled financial transaction in response to the message indicating payment of the scheduled financial transaction.

115. The system according to claim 110, wherein the server transceiver is further configured to receive a payment request, and, in response to the payment request, the server is further configured to determine whether an account corresponding to the client device has sufficient funds to satisfy the payment request.

116. The system according to claim 115, wherein, if the server determines that the account has insufficient funds to satisfy the payment request, the server is further configured to transmit a message warning of an overdraft to the client application.

117. The system according to claim 116, wherein the client application is further configured to generate a notification on the client device of the overdraft.

118. The system according to claim 117, wherein the notification on the client device further comprises a selectable graphical user interface element to deny the payment request.

119. The system according to claim 110, wherein the client application is further configured to display a polygon indicating a transaction is a recurring transaction.