Automated third-party messaging

0001This application is a Continuation of U.S. patent application Ser. No. 15/638,223, entitled “ELECTRONIC AUDIBLE PAYMENT MESSAGING,” filed on Jun. 29, 2017, and is a Continuation of U.S. patent application Ser. No. 15/637,631, entitled “AUTOMATED THIRD-PARTY MESSAGING,” filed Jun. 29, 2017, which are incorporated herein by reference.

BACKGROUND

0002Chatbots can be a computer program executed by a computer server or other computerized device that can conduct an auditory or textual conversation with a user and can simulate how a human may behave. Currently, chatbots can generate rudimentary responses to basic one-on-one questions, such as, “Who was the 16th president?” The chatbot can respond with “Abraham Lincoln” and other biographical information, such as date and place of birth. Such chatbots have begun adding information in conversations. For example, a user might receive a photo of a butterfly, and the chatbot might suggest appropriate responses, such as, beautiful, pretty, or nice picture. A chatbot can make restaurant recommendations if it detects a conversation about food. For example, if a conversation contains the string “Italian food,” then the chatbot can insert restaurant recommendations, reviews, and maps to help the users identify a restaurant. Many chatbots, however, often work only on specific, proprietary applications and do not have features that users desire. Messaging applications, such as Facebook Messenger, Slack, and Google Allo, may use chatbots for limited purposes, such as responding to basic questions. But these chatbots have not been capable of initiating a payment within a conversation using the messaging application.

DESCRIPTION OF THE DRAWINGS

0003Non-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.

0004<figref idref="DRAWINGS">FIG. 1</figref> illustrates an example system for third-party participation in a messaging application, according to an embodiment.

0005<figref idref="DRAWINGS">FIG. 2</figref> illustrates an example messaging application with the ability to make a payment request, according to an embodiment.

0006<figref idref="DRAWINGS">FIG. 3</figref> illustrates a second example of a messaging application with the ability to receive a payment request, according to an embodiment.

0007<figref idref="DRAWINGS">FIG. 4</figref> illustrates a third example of a messaging application with the ability to receive a payment request, according to an embodiment.

0008<figref idref="DRAWINGS">FIG. 5A-B</figref> illustrates an example of seamless integration of a third-party payment application with a native communication application to send a payment, according to an embodiment.

0009<figref idref="DRAWINGS">FIG. 6</figref> illustrates an example messaging application with the ability to make a payment request using information from a previous purchase made in a system, according to an embodiment.

0010<figref idref="DRAWINGS">FIG. 7</figref> illustrates a second example messaging application with the ability to make a payment request using information from a previous purchase made in a system, according to an embodiment.

0011<figref idref="DRAWINGS">FIG. 8</figref> illustrates an example process processing a payment request using natural-language processing.

DESCRIPTION

0012The 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.

0013Embodiments of this disclosure include technical solutions to add functionality to chatbots, including automatically detecting requests to make payment transactions, and suggesting payment transactions. A payment-service-system server can detect requests to make payment transactions using natural language processing to detect requests to make payment transactions in human-readable or computer-readable messages. The payment transactions can be processed by a third-party payment application that communicates with at least two other users in a messaging application. The third-party payment application can generate messages to the messaging applications using the same protocol that other users can generate messages.

0014These technical solutions include enhancing third-party messaging platforms that do not have its own payment service to include real-time, automated, streamlined peer-to-peer payments using a chatbot. The technical solution includes communicating with users using either human-readable or machine-readable messages to suggest or process peer-to-peer payments on the third-party messaging platforms. Advantages to using a chatbot vs. an API to process payment include ease of us, fewer resources needed, faster implementation and response, and more accurate communication.

0015The figures and disclosure below provide example implementations technical solutions of messaging platforms interfacing with a chatbot to suggest or process peer-to-peer payments.

0016<figref idref="DRAWINGS">FIG. 1</figref> illustrates an example system <b>100</b> for providing automated third-party messaging. The embodiments illustrated in <figref idref="DRAWINGS">FIG. 1</figref> include a client device <b>102</b>, a server <b>108</b> of a third-party web content provider, a computer server system of a third-party application service (“application server <b>106</b>”), and a payment-service-system <b>113</b>, all of which are remote from each other and in communication over a user-facing network <b>111</b>. In some embodiments, payment-service-system <b>113</b> includes one or more servers <b>104</b> and a software agent <b>114</b>. The one or more servers <b>104</b> are typically equipped with, or are coupled to, one or more databases <b>107</b><i>a</i>-<b>107</b><i>n</i>, 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 <b>104</b>, <b>107</b><i>a</i>-<b>107</b><i>n</i>, <b>111</b>, <b>113</b>, and <b>114</b>, can be similar to those components illustrated in <figref idref="DRAWINGS">FIG. 1</figref>.

0017The network <b>111</b> can include any combination of local area and/or wide area networks, using both wired and wireless communication systems. In some embodiments, the network <b>111</b> uses standard communications technologies and/or protocols. Thus, the network <b>111</b> 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 <b>111</b> 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 <b>111</b> 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 encryption technologies such as secure sockets layer (SSL), transport layer security (TLS), and Internet Protocol security (IPsec).

0018In other embodiments, the environment can have more or fewer components than shown, or a different configuration of components. The various components shown in <figref idref="DRAWINGS">FIG. 1</figref> 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 <figref idref="DRAWINGS">FIG. 1</figref> can be implemented based on other architectures in other embodiments. For example, in some embodiments, the software agent <b>114</b> can exist separately from the payment-service-system <b>113</b>, e.g., as part of the server <b>104</b>, or as a standalone server (e.g., a standalone API server in communication with the server <b>104</b>, the application server <b>106</b>, and the servers <b>104</b>). In another example, in some embodiments, functions of at least some of the servers can be consolidated. The system <b>100</b> also includes components to handle point-of-sale transactions. First, however, this disclosure focuses on transactions between the two client devices <b>102</b>A and <b>102</b>B.

0019The client device <b>102</b> can be any processing device capable of receiving user input as well as transmitting and/or receiving data via the network <b>111</b> by using a transceiver, e.g., one or more input/output devices for communicating over network <b>111</b>, such as an Ethernet or WiFi adapter. In some embodiments, the client device <b>102</b> can be a computer system (e.g., a desktop <b>102</b>A or a laptop computer <b>102</b>B) or a mobile device having computer functionality (e.g., a tablet device, a smartphone, or a mobile phone). The client device <b>102</b> 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.

0020The client device <b>102</b> can be configured to communicate via the network <b>111</b> with the server <b>104</b> and/or the application server <b>106</b>. In some embodiments, the client device <b>102</b> can retrieve or send information to the server <b>104</b> and/or the application server <b>106</b>, and run one or more applications, such as a software agent program, with customized content retrieved from the server <b>104</b> or the application server <b>106</b>. For example, the client device <b>102</b> can execute a browser application to enable communication between the client device <b>102</b> and the server <b>104</b> (e.g., to access a social networking website). In another example, the client device <b>102</b> can execute a customized client to enable communication between the client device <b>102</b> and the application server <b>106</b>. For example, the customized client is a messaging application operated by a messaging-service server. The customized client can further provide a channel of communication between respective client devices of a sender <b>140</b> and a recipient <b>142</b> (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-service servers can include an email application and email server or a social networking messaging application and a social networking server.

0021In accordance with various implementations of payment proxies, the sender <b>140</b> can utilize a given client device <b>102</b> to trigger a money transfer to a recipient <b>142</b>. For example, by accessing a landing page with the client device <b>102</b>, the sender <b>140</b> can submit an amount of money to the recipient <b>142</b> that is associated with the landing page. In another example, the sender <b>140</b>, using the client device <b>102</b>, 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 <b>140</b> to send money to the recipient through use of a specified syntax for one or more inputs in that message. The recipient <b>142</b> can similarly use another given client device <b>102</b> to receive the money, for example, by interacting with a confirmation link sent to the client device of the recipient <b>142</b> as a result of the money transfer triggered by the sender <b>140</b>.

0022In an alternative embodiment, sender <b>140</b> can have an account maintained at the server <b>104</b>, 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 <b>104</b> 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 <b>104</b> can transmit one or more requests (e.g., POST or GET requests) to query the database(s) <b>107</b><i>a</i>-<b>107</b><i>n</i>. The server <b>104</b> 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 <b>142</b>). 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 web site (e.g., login credentials).

0023In one example, the server <b>108</b> 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 software agent <b>114</b>. In such an example, the server <b>104</b> 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 software agent <b>114</b> and/or the server <b>104</b> to process the money transfer. The syntax can either be in human-readable form and identified using natural language processing, or in a computer-readable form and identified using special characters. Human-readable form is natural or ordinary language that occurs naturally between humans without a planned syntax. The computer-readable syntax is planned and unnatural, and can include an opcode followed by one or more operands, e.g., /Cash [recipient] [amount] [reason (optional)]. In some embodiments, the server <b>104</b> parses the user messages simply to identify any message with input(s) having the syntax, and forwards that message to the server <b>104</b> via the software agent <b>114</b>. In such embodiments, the server <b>104</b> 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. In other embodiments, the recipient and sender can be identified by unique identifiers, such as usernames or phone numbers. Upon identifying the recipient, the server <b>104</b> 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 software agent <b>114</b> (e.g., instructed by the server <b>104</b>) can also send back, in a response to the server <b>104</b>, 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 <b>104</b> sends a confirmation message to the sender using information included in the request received from the server <b>104</b>, e.g., an identifier associated with the sender. For example, the identifier can be an email address of the user, and the server <b>104</b> (e.g., via an email server) sends an email message to the user's email address.

0024The server <b>104</b> can identify potential payment requests in the background, while the users conduct a conversation. The users do not need to make any specific request or take any action for the server <b>104</b> to identify potential payment requests. The users may continue to use the messaging application in the foreground, while the server <b>104</b> operates in the background to identify potential payment requests and communicate with the users. In some embodiments, payment requests can only be made between participants of the conversation, and the software agent program will not process a payment request to a user who is not a participant of the conversation. Upon detecting or identifying language that appears to be a payment request, the software agent program will not generate a payment command when at least one recipient of the payment is not a participant of the conversation in the messaging application at the time of the payment request. In other embodiments, the server <b>104</b> can process payment between a participant of the conversation and a party that is not a participant.

0025The messaging-service server <b>106</b> supports an application that includes one or more graphical user interfaces for organizing and presenting content to users. The messaging-service server <b>106</b> can be a mobile application installed on a mobile device or a software application installed on a personal computer. Users can utilize the messaging-service server <b>106</b> to interact with other users. The messaging-service server <b>106</b> can be a messaging application. For example, through the messaging-service server <b>106</b>, 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 messaging-service server <b>106</b> (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 <b>106</b> monitoring the messages for an indication of an intent to transfer money, e.g., by parsing messages at the messaging-service server <b>106</b>. In response to such indications, the application server <b>106</b> can transmit one or more requests (e.g., POST or GET requests) to the software agent <b>114</b> of the server(s) <b>104</b> to query the database(s) <b>107</b><i>a</i>-<b>107</b><i>n</i>, and display the data returned by the software agent <b>114</b> of the server(s) <b>104</b> as appropriate. In some embodiments, the messaging-service server <b>106</b> performs the parsing. Upon identifying the syntax, the messaging-service server <b>106</b> can notify the application server <b>106</b> of the indication of the intent to transfer money. Alternatively, in some embodiments, the messaging-service server <b>106</b> notifies a payment service application executing on the user's device of the indication, where that payment service application communicates with the servers <b>104</b> via the software agent <b>114</b>.

0026In one example, the messaging-service server <b>106</b> monitors at the user device (e.g., client device <b>102</b> of the sender <b>140</b>) 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 messaging-service server transmits a request to the software agent <b>114</b> that includes, e.g., the message and an identifier associated with a creator of the message (e.g., an email address or phone number), for the software agent <b>114</b> and/or the server <b>104</b> to process the money transfer. In such an example, the server <b>104</b> 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 <b>104</b> initiates a money transfer to that recipient. In some embodiments, the messaging-service server <b>106</b> communicates with a payment service application executing at the user's device via message to software agent <b>114</b>. 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 <b>104</b> (e.g., via the software agent <b>114</b>), which processes the money transfer based on this information. In some embodiments, the payment service application forwards the message to the server <b>104</b>, which performs the additional parsing to identify the amount of money and the recipient.

0027In some embodiments, the software agent <b>114</b> (e.g., instructed by the server <b>104</b>) can also send back appropriate data relating to the money transfer for display to the user at the messaging-service server <b>106</b>. 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 <b>104</b> sends a confirmation message to the user using information included in the request received from the application server <b>106</b>, e.g., an identifier associated with the user. For example, the identifier can be a telephone number of the user, and the server <b>104</b> sends a text message to the user's phone number.

0028The payment-service-system <b>113</b> can be a cloud computing environment, a virtualized computing environment, a computer cluster, or any combination thereof. The payment-service-system <b>113</b> 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 payment-service-system <b>113</b> includes the one or more servers <b>104</b>. The payment processor can be a part of the one or more servers <b>104</b>, and can work in coordination with the software agent <b>114</b> to exchange requests and responses with the server <b>104</b>, the application server <b>106</b>, and/or the payment service application associated with the payment-service-system <b>113</b> to process one or more transactions triggered by use of the syntax (e.g., money transfers). The one or more servers <b>104</b> can handle secure transactions (e.g., using a secure server), to process all payment transactions triggered.

0029In general, the servers <b>104</b> store secure information such as credit card numbers, debit card numbers, bank account numbers, user accounts stored in one of databases <b>107</b><i>a</i>-<b>107</b><i>n</i>, 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 <b>132</b>) and can be associated with the card number. In some embodiments, the one or more card accounts are stored at the server <b>104</b> (e.g., at the databases <b>107</b><i>a</i>-<b>107</b><i>n</i>). Generally, the card issuer issues a physical payment card for each card account.

0030In some embodiments, the payment-service-system <b>113</b> includes a payment service application server (e.g., a server of the servers <b>104</b>) that supports a payment application for executing various services provided by the payment-service-system <b>113</b>. 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 software application installed on a personal computer. For example, through the payment service application, users create account logins to utilize financial services offered by the payment-service-system <b>113</b>, to link their financial accounts with the payment-service-system <b>113</b> (e.g., registration with the payment-service-system <b>113</b>), to transfer money using their user accounts and/or financial accounts, and/or otherwise engage with the services offered by the payment-service-system <b>113</b> via the payment service application.

0031To process payment transactions, the payment-service-system <b>113</b> can communicate with one or more financial networks. In some embodiments, the payment-service-system <b>113</b> can communicate with a computer system of a card payment network <b>120</b>, 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 <b>120</b>”). In some embodiments, the payment-service-system <b>113</b> can communicate with the card payment network <b>120</b> over the same user-facing network <b>111</b>, or a different network. In one example, the card payment network <b>120</b> can communicate, in turn, with the computer system of a sender card issuer <b>122</b>, e.g., a bank, and a computer system of a recipient card issuer <b>124</b>, e.g., a same or different bank. The sender card issuer <b>122</b> and the recipient card issuer <b>124</b> can transfer money, e.g., over a debit payment network, in response to a request to transfer money from the payment-service-system <b>113</b>.

0032In some embodiments, the payment-service-system <b>113</b> can communicate with a computer system of an ACH network <b>130</b>. The computer system of the ACH network <b>130</b> can communicate with a sender card issuer <b>132</b> and a recipient bank account <b>134</b>. The sender card issuer <b>132</b> and the recipient bank account <b>134</b> can transfer money, e.g., using the ACH network, in response to a request to transfer money from the payment-service-system <b>113</b>. In other embodiments, there can also be computer systems of other entities, e.g. the card acquirer, between the payment-service-system <b>113</b> and the card issuers, and between the payment-service-system <b>113</b> and the bank accounts.

0033In some embodiments, the payment-service-system <b>113</b> can transfer money between bank <b>116</b> and one or more of the recipient accounts on card payment network <b>120</b> and ACH network <b>130</b>. The transfer of funds occurs similar to that illustrated in <figref idref="DRAWINGS">FIG. 3</figref>. In a first direction, a sender having an account at bank <b>116</b> can initiate a payment transaction to a recipient with an account over the card payment network <b>120</b> or the ACH network <b>130</b>. The sender's account would be debited according to <figref idref="DRAWINGS">FIG. 3</figref>; 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 <b>120</b> or ACH network <b>130</b> can begin a payment transaction by sending money to a recipient with an account at bank <b>116</b>. System or record <b>105</b> can maintain the account in database <b>110</b>. The sender would send the funds using the protocols associated with either card payment network <b>120</b> or ACH network <b>130</b>, whereas the recipient would receive the funds in accordance with <figref idref="DRAWINGS">FIG. 3</figref>. In this way, server <b>104</b> can coordinate transactions between account holders having several different types of accounts.

0034In accordance with various embodiments, a payment transaction (e.g., a transferring of money) can originate at a device of the sender <b>140</b> (“sender device”), such as the desktop <b>102</b>A. For example, the sender <b>140</b> 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 <b>104</b>. Alternatively, the sender <b>140</b> 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 <b>142</b>. In another example, the sender <b>140</b> can initiate a payment transaction by using a sender device to access an application such as a messaging application supported by the application server <b>106</b>. 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 payment-service-system <b>113</b>.

0035The payment-service-system <b>113</b> 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 <b>107</b><i>a</i>-<b>107</b><i>n </i>of the payment-service-system <b>113</b>), and transferring funds between the accounts.

0036In 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 payment-service-system <b>113</b> (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 payment-service-system <b>113</b>. In this example, the payment-service-system <b>113</b>, 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 payment-service-system <b>113</b> automatically registers the financial account and the payment proxy with the payment-service-system <b>113</b> 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 payment-service-system <b>113</b> (e.g., databases <b>107</b><i>a</i>-<b>107</b><i>n</i>). Information of the financial accounts can be used for future payment transactions (e.g., money transfers).

0037In 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 payment-service-system <b>113</b> can receive the sender identifier from the server <b>104</b> or the application server <b>106</b>. In some embodiments, the payment-service-system <b>113</b> receives the sender identifier from the payment service application supported by the payment-service-system <b>113</b>.

0038The payment-service-system <b>113</b> 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 payment-service-system <b>113</b> (e.g., an interactive payment receiving interface). In such an example, the payment-service-system <b>113</b> 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 payment-service-system <b>113</b> 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 payment-service-system <b>113</b>). 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 payment-service-system <b>113</b> (e.g., databases <b>107</b><i>a</i>-<b>107</b><i>n</i>). Information of these financial accounts can be used for future payment transactions (e.g., money transfers).

0039If no financial account information is identified for either the sender user or the recipient user, the payment-service-system <b>113</b> 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.

0040When 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 payment-service-system <b>113</b> sends a request to transfer money, e.g. via the card payment network <b>120</b>, the ACH network <b>130</b>, or the bank <b>116</b>. In particular, to transfer money between the sender user and the recipient user (identified based on the payment proxy), the payment-service-system <b>113</b> can operate as a gateway or a middleman.

0041To operate as a gateway, the payment-service-system <b>113</b> can identify debit card accounts, e.g. stored at the servers <b>104</b>, for both the sender user and the recipient user. The payment-service-system <b>113</b> 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.

0042To operate as a middleman, the payment-service-system <b>113</b> 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 payment-service-system <b>113</b> 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 payment-service-system <b>113</b> can also forward the payment once the recipient user links the account with the payment-service-system <b>113</b>. Alternatively, the payment-service-system <b>113</b> 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 payment-service-system <b>113</b> can generate a transaction to system of system of record <b>105</b> to either debit or credit an account stored at bank <b>116</b>, according to a corresponding transaction over either card payment network <b>120</b> or ACH network <b>130</b>.

0043In an embodiment in which the application server <b>106</b> acts as a messaging server with a messaging-service application, a plurality of client devices <b>102</b> can communicate over network <b>111</b> with the application server <b>106</b>. Similarly, the software agent <b>114</b> can allow for the server <b>104</b> to communicate with application server <b>106</b> over network <b>111</b>. In this way, the plurality of client devices <b>102</b> and the server <b>104</b> can each communicate via the messaging application on the application server.

0044System <b>100</b> further includes several servers that handle various steps in a computerized system for processing point-of-sale transactions and for tracking debit and credit transactions to add additional functionality to automated third-party messaging. The example system <b>100</b> may comprise a plurality of entity systems associated and operated by various entities of the system <b>100</b>, including a merchant, merchant-acquirer, issuer processor, payment-service-system, host banking system working in collaboration with the payment-service-system 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 <b>121</b>, server computers <b>122</b>, <b>123</b>, <b>104</b>, <b>105</b>, <b>106</b>) that execute the various processes described herein and networking devices that facilitate intercommunications between the various entities. Embodiments may comprise additional or alternative entity systems; and that some embodiment may omit or combine certain entity systems of the example system <b>100</b> shown in <figref idref="DRAWINGS">FIG. 1</figref>.

0000Merchant Computing Device

0045A merchant computing device <b>121</b> may be employed by a merchant to request payment authorization for a particular transaction. The merchant computing device <b>121</b> 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 <b>100</b>. Non-limiting examples of a merchant computing device <b>121</b> 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 client device(s) <b>102</b>A and <b>102</b>B. As mentioned, the merchant computing device <b>121</b> 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 client device(s) <b>102</b>A and <b>102</b>B, and the client device(s) <b>102</b>A and <b>102</b>B is configured to transmit payment request data for the virtual card using near field communications (NFC), then the merchant computing device <b>121</b> 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(s) <b>102</b>A and <b>102</b>B.

0046In operation, a merchant computing device <b>121</b> 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 <b>122</b>. The merchant computing device <b>121</b> 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 <b>121</b> 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 <b>121</b> may transmit the digital message to containing the card and/or other payment information to a merchant-acquirer server <b>122</b>, although in some implementations, the digital message may be transmitted to other devices, such as an issuer processor server <b>123</b> of an issuer processor system.

0047The merchant computing device <b>121</b> can communicate with the payment-service-system server <b>104</b> to handle many forms of merchant-related computing needs, including process payments, track inventory, transfer funds, purchase inventory, receive software updates, transfer purchase- and user-related data, and make special offers. The merchant computing device <b>121</b> can be a proprietary device or run proprietary software associated with the payment-service-system server <b>104</b>. By having access to such data from the merchant computing device <b>121</b> and from the client device(s) <b>102</b>A and <b>102</b>B, the payment-service-system server <b>104</b> has much more visibility into the payment process than prior art systems, which only have visibility on one side of a transaction, i.e., the merchant or the customer. In some embodiments, the payment-service-system server <b>104</b> communicates with and has data from both the merchant and the client.

0000Merchant-Acquirer

0048Merchant-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 <b>122</b> may be any computing device configured to communicate, over predetermined payment network rails <b>127</b>, digital messages containing payment transaction data to and from one or more merchant computing devices <b>121</b>, as well as transaction data to and from the issuer processor server <b>123</b>. In operation, the merchant-acquirer server <b>122</b> 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 <b>121</b> to the issuer processor server <b>123</b> over the payment network rails <b>127</b> of a particular payment network entity (e.g., Visa® or MasterCard® networks). In some implementations, the merchant-acquirer server <b>122</b> may forward to the merchant computing device <b>121</b> payment authorization response messages from the issuer processor server <b>123</b>, indicating whether the payment was authorized or declined.

0049In operation, the merchant computing device <b>121</b> 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 <b>122</b>. The merchant computing device <b>121</b> 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 <b>121</b> may transmit the digital message containing the card and/or other payment information to a merchant-acquirer server <b>122</b>, although in some embodiments, the digital message may be transmitted to other devices, such as an issuer processor server <b>123</b> of an issuer processor system.

0000Payment Network Association and Payment Network Rails

0050Payment network entities (e.g., Visa®, MasterCard®, American Express®) may be entities that operate payment network rails <b>127</b>, which may be a computing communications network configured to receive and transmit digital messages between and among merchant computing devices <b>121</b> and merchant-acquirer servers <b>122</b>, as well as messages between merchant-acquirer servers <b>122</b> and issuer processor server <b>123</b>. In operation, merchant computing devices <b>121</b> and merchant-acquirer servers <b>122</b> 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.

0000Issuer Processor

0051Issuer processor systems can establish payment card number records for customers, issue bills and statements, and process payments. The issuer processor server <b>123</b> can perform these functions and store transactions and payment card numbers in a storage device, such as an issuer database <b>125</b>. Issuer processors will typically forward payment authorization requests to a core processor server <b>105</b>. However, the example system comprises a payment-service-system server <b>104</b> positioned between issuer processor server <b>123</b> and core processor server <b>105</b>. Furthermore, the payment-service-system server <b>104</b> can perform some or all of the functions typically associated with issuer processors, and therefore, in these embodiments, the merchant-acquirer server <b>122</b> can communicate over the payment network rails with the payment-service-system server <b>104</b>. Although the issuer processor server <b>123</b> and the payment-service-system server <b>104</b> are shown as separate computing platforms, the issuer processor server <b>123</b> and the payment-service-system server <b>104</b> can be implemented as a single platform. The positioning of the payment-service-system server <b>104</b> between issuer processor server <b>123</b> and core processor server <b>105</b> allows the payment-service-system server <b>104</b> 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 payment-service-system server <b>104</b> can also have access to all transactions associated with an account to provide further services to the client device(s) <b>102</b>A and <b>102</b>B associated with the account.

0052In some embodiments, the issuer processor server <b>123</b> 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 client device(s) <b>102</b>A and <b>102</b>B. The payment-service-system server <b>104</b> may transmit a new payment card number to the issuer processor server <b>123</b> after the payment-service-system server <b>104</b> generates the payment card number. In some instances, the payment-service-system server <b>104</b> may transmit a token that was generated by the payment-service-system server <b>104</b> to represent the payment card number, based on predetermined tokenization algorithms promulgated by the payment-service-system server <b>104</b>. However, the client device(s) <b>102</b>A and <b>102</b>B may execute one or more digital wallet applications allowing the client device(s) <b>102</b>A and <b>102</b>B to securely store payment card numbers and conduct payment transactions using the client device(s) <b>102</b>A and <b>102</b>B instead of a physical payment card. The issuer processor server <b>123</b> 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 payment-service-system server <b>104</b>) to the client device(s) <b>102</b>A and <b>102</b>B for storage and use in digital wallet-based transactions.

0000Host Bank

0053A host bank may be a third-party financial institution that works in collaboration with the payment-service-system to provide various services to users through consumer-facing applications. The host bank system may have a bank server <b>106</b> and bank database <b>129</b>. The bank server <b>106</b> may communicate with a payment-service-system server <b>104</b> 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 <b>106</b> may generate new bank accounts and may interact with the payment-service-system, 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 <b>129</b> that may store banking data for various accounts, including routing numbers, account numbers, and account ledgers, among other types of information. The bank server <b>106</b> may generate and update records of the bank database <b>129</b> based on new and updated account information received from the various entities, according to account update requests and transaction data.

0054In some embodiments, the payment-service-system 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 payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n</i>. In such embodiments, the bank server <b>106</b> may generate a routing number and account number for the payment-service-system, and various forms of information about the payment-service-system and transactions may be tracked in the bank database <b>129</b>. Users who use the payment-service-system services to facilitate payments or for other services may deposit funds into the account of the payment-service-system held at the host bank. The payment-service-system server <b>104</b> may update a record of the user in the payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n </i>to reflect the amount of user money held in the payment-service-system account at the host bank. The bank server <b>106</b> may update the amount of money in the payment-service-system account reflected in the account data and ledgers stored in the bank database <b>129</b>, based on various transaction request messages received from the payment-service-system server <b>104</b>. The payment-service-system server <b>104</b> may similarly update the amount of money belonging to the user in the payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n</i>, based on various transactions.

0055In some embodiments, the host bank may open and manage a financial account for each user registered in the payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n</i>. In such embodiments, the bank server <b>106</b> may receive instructions from the payment-service-system server <b>104</b> to open a new account for a user, when the user registers with the payment-service-system services, in response to some other trigger or instruction received from the payment-service-system server <b>104</b>. The bank server <b>106</b> 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 <b>106</b> or the payment-service-system server <b>104</b> may generate one or more graphical user interfaces (GUIs) configured to receive user information from the client device(s) <b>102</b>A and <b>102</b>B. And in some cases, the payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n </i>may contain the requisite KYC process data in a record of the user, which the payment-service-system server <b>104</b> may transmit to the bank server <b>106</b>. The bank server <b>106</b> may generate one or more records for the user in bank databases <b>129</b>, which may include generating a bank account number for the user. The bank server <b>106</b> may transmit the host bank account information for the user to the payment-service-system server <b>104</b>, where the information may be stored into a record for the user in the payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n</i>, identified by a user ID associated with the user.

0000Payment-Service-System

0056A payment-service-system may comprise payment-service-system servers <b>104</b>, which may be any computing device capable of performing various tasks and processes described herein. A payment-service-system server <b>104</b> 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 payment-service-system server <b>104</b> is shown as a single server, it should be appreciated the functionality of a payment-service-system server <b>104</b> may be performed by any number of computing devices. In the example system <b>100</b>, a payment-service-system server <b>104</b> may be coupled to issuer processor servers <b>123</b> and core processor servers <b>105</b>, such that the payment-service-system server <b>104</b> 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 payment-service-system server <b>104</b> may be configured to execute tasks and processes of an issuer processor server <b>123</b>, such that the payment-service-system may function as an issuer processor system. It should also be appreciated that in some embodiments the payment-service-system server <b>104</b> may additionally or alternatively be configured to perform various tasks and processes of a core processor server <b>105</b>, such that the payment-service-system may function as a core processor system.

0057Additionally, the payment-service-system system may have one or more payment-service-system databases <b>107</b> that store records of users, account and transaction ledgers, and other forms of information. Payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n </i>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 payment-service-system databases <b>107</b> may comprise or may otherwise be coupled to a payment-service-system server <b>104</b> via one or more internal networks (not shown), within the operational boundaries of payment-service-system network devices.

0058Payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n </i>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 payment-service-system server <b>104</b> may generate and update a user record according to registration or demographic data received from the client device(s) <b>102</b>A and <b>102</b>B during a registration process; and according to transaction data received from the client device(s) <b>102</b>A and <b>102</b>B or other entities of the system <b>100</b>, such as the host bank, issuer processor, and core processor, among other entities, during other processes.

0059As an example of processes affecting payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n </i>containing user information, in embodiments where the host bank holds accounts for each individual user, during a registration process the payment-service-system server <b>104</b> may receive a new account request and various types of user information and client device data from a client application published by the payment-service-system and executed by the client device(s) <b>102</b>A and <b>102</b>B. The payment-service-system server <b>104</b> may forward the request to a bank server <b>106</b> that may generate a new financial account for the user in the bank database <b>129</b>, which may include generating and returning to the payment-service-system server <b>104</b> the routing number of the host bank and a unique account number for the user's new financial account. The payment-service-system server <b>104</b> may store into the user profile record of the payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n</i>, the data about the user, the data associated with the client application and/or the client device(s) <b>102</b>A and <b>102</b>B, and the data associated with new account held at the host bank. Alternatively, in embodiments where the host bank manages accounts for the payment-service-system entity, during the registration process the payment-service-system server <b>104</b> may generate the user record in the payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n</i>, and may update the user record to reflect amounts deposited or debited, into or out of the payment-service-system account held at the host bank. The payment-service-system server <b>104</b> may also receive from the client device(s) <b>102</b>A and <b>102</b>B and store into the user profile record of the payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n</i>, the data about the user, the data associated with the client application and/or the client device(s) <b>102</b>A and <b>102</b>B.

0060As another example of a process affecting payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n </i>that contains user information, the payment-service-system server <b>104</b> may receive a new card request from the client application executed by the client device(s) <b>102</b>A and <b>102</b>B, thereby prompting the payment-service-system server <b>104</b> to execute various processes for generating a unique new payment card number for the user. The payment-service-system server <b>104</b> may generate the payment card number and store the payment card number into the user record of the payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n</i>. In some implementations, the payment-service-system server <b>104</b> 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 payment-service-system server <b>104</b> may store the token into the payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n </i>records for the user, and may then exchange the token with various devices of the system <b>100</b> 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 payment-service-system server <b>104</b> may transmit the token and/or payment card number to the client device(s) <b>102</b>A and <b>102</b>B for storage and later usage. In addition, the payment-service-system server <b>104</b> may transmit the payment card number to the issuer processor server <b>123</b>, the bank server <b>106</b>, and/or core processor server <b>105</b>, 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.

0061A payment-service-system server <b>104</b> can communicate transaction data to a core processor server <b>105</b>, which may record the payment authorization and other transaction data into a system of record database <b>110</b> 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 <b>105</b> may transmit response messages indicating whether a transaction request associated with a user's payment card number should be authorized, The payment-service-system server <b>104</b> 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 payment-service-system server <b>104</b> may be configured to reject all transaction requests until a request to activate a payment card number has been received from authorized client device(s) <b>102</b>A and <b>102</b>B 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 payment-service-system server <b>104</b> 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 payment-service-system server <b>104</b> transmits an active card number to the client device(s) <b>102</b>A and <b>102</b>B, among other parties of the system <b>100</b>. For the user's protection, because the payment card is indeed active when the payment card number is transmitted to the client device(s) <b>102</b>A and <b>102</b>B, the payment-service-system server <b>104</b> may reject all payment transaction requested by default. Likewise, the activation status of the payment card number in a user record in the payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n </i>may indicate that the card number has not been activated yet. The payment-service-system server <b>104</b> may prompt the user, via a client-side GUI presented on the client device(s) <b>102</b>A and <b>102</b>B, to activate the card, even though the card is indeed active. The activation request from the client device(s) <b>102</b>A and <b>102</b>B may instruct the payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n </i>to update the activation status of the payment card number in the user profile to indicate the card has been activated, and thus the payment-service-system server <b>104</b> may authorize payment transaction satisfying any other criteria that might be verified by the payment-service-system server <b>104</b>.

0062Devices of the payment-service-system may include, or may otherwise be coupled to, one or more user-facing networks <b>111</b>, such as the Internet, through which client devices <b>102</b>A of users may access the payment-service-system server <b>104</b> and payment-service-system databases <b>107</b>. One having ordinary skill in the art would appreciate that the user-facing networks <b>111</b> may comprise any number of hardware and software computing-communications components configured to support communications between the client devices <b>102</b>A and the payment-service-system server <b>104</b>, where at least some of the networks <b>111</b> include internet protocol (IP) based networking technologies that allow the client devices <b>102</b>A to communicate with the payment-service-system server <b>104</b>. Non-limiting examples of components of the user-facing networks <b>111</b> may include routers, switches, firewalls, and the like.

0000Core Processor and System of Record

0063A core processor may be a financial institution responsible for authorizing transactions, releasing funds, managing a system of record database <b>110</b>, 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 <b>105</b> 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.

0064A core processor server <b>105</b> receives and updates a system of record database <b>110</b> 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 <b>110</b>. Certain parties, such as the account owner (e.g., user, payment-service-system), the merchant, the issuer processor, or the payment-service-system, may assume certain risks that an account holder does not have sufficient funds to fund a transaction, until the core processer server <b>105</b> authorizes the transaction and records the transaction in the system of record database <b>110</b>.

0065In operation, when a payment-service-system server <b>104</b> receives a payment authorization request from a merchant computing device <b>121</b> via the various entities and devices, the payment-service-system server <b>104</b> can forward the associated transaction information to core processor server <b>105</b>, which maintains an account corresponding to the payment card used in the payment transaction. The system of record database <b>110</b> may manage the account information using the core processor server <b>105</b>, along with a ledger of transactions for the account and other user profile information. In some cases, the core processor server <b>105</b> may transmit account information, such as an indication for an amount of funds available to cover a transaction amount, to the payment-service-system server <b>104</b>. The payment-service-system server <b>104</b> may determine based on preconfigured criteria whether to authorize the transaction based upon the account information received from the core processor server <b>105</b>. As previously mentioned, in some embodiments, the payment-service-system server <b>104</b> may be configured to deny all transactions associated with a payment card number associated with a user profile in the payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n </i>until the an activation request is received from the user via authorized client device(s) <b>102</b>A and <b>102</b>B associated with the user, as indicated by the user profile record stored in payment-service-system databases <b>107</b>. The payment-service-system server <b>104</b> may be configured to make additional or alternative determinations regarding authorizing payment transaction requests independent of the core processor server <b>105</b> determinations and indications. For instance, the payment-service-system server <b>104</b> may reject transaction requests associated with the payment card number of the user when the payment-service-system server <b>104</b> determines that there would be overdraft the account, even though the bank hosting the account of the user would permit the overdraft.

0066The payment-service-system server <b>104</b> can communicate transactions to the core processor server <b>105</b>, which may update the system of record database <b>110</b> transaction information associated with user accounts registered with the payment-service-system services. The core processor server <b>105</b> may further report the transaction data and the daily ledger results in the system of record database <b>110</b> 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 <b>105</b> may generate an authorization response that may be forwarded through the payment-service-system server <b>104</b> to various devices and entities of the system <b>100</b> (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 <b>100</b>.

0067In the conventional payment stream, an issuer processor typically forwards payment authorization requests to a core processor server <b>105</b>. However, according to embodiments described in the disclosure, such as the example system <b>100</b>, and variations of such embodiments, a payment-service-system server <b>104</b> is situated between an issuer processor server <b>123</b> and a core processor server <b>105</b>. Situating the payment-service-system server <b>104</b> between issuer processor server <b>123</b> and core processor server <b>105</b> allows for the payment-service-system server <b>104</b> to intervene in and record transactions in the payment stream, such as payment authorizations. Consequently, the payment-service-system server <b>104</b> 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 payment-service-system server <b>104</b> may execute additional features and transaction processes that were not available in the conventional payment and financial systems. Furthermore, the payment-service-system server <b>104</b> 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 payment-service-system server <b>104</b>. In other words, some embodiment may facilitate collapsing the number of entities required to be involved in conventional payment transaction processing streams.

0000Client Device

0068Client device(s) <b>102</b>A and <b>102</b>B may be any computing devices capable of executing a locally-installed application or accessing a web-based application executed by a payment-service-system server <b>104</b>. 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(s) <b>102</b>A and <b>102</b>B 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(s) <b>102</b>A and <b>102</b>B, 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(s) <b>102</b>A and <b>102</b>B and an IP address of the client device(s) <b>102</b>A and <b>102</b>B, as well as other types of information about the client device(s) <b>102</b>A and <b>102</b>B. The device data may be submitted with the user data during the registration process, and may be stored in the user record in the payment-service-system databases <b>107</b><i>a</i>-<b>107</b><i>n</i>. As another example, a tokenization algorithm designed to mask the actual payment card number generated by the payment-service-system server <b>104</b> may use data inputs, such as the user ID of the user and/or a device identifier (device ID) associated with the client device(s) <b>102</b>A and <b>102</b>B; the device ID may be generated by the payment-service-system server <b>104</b> according to various input values, or the device ID may be an existing data field, such as the MAC address of the client device(s) <b>102</b>A and <b>102</b>B. As mentioned, the client device(s) <b>102</b>A and <b>102</b>B may access and communicate with the payment-service-system server <b>104</b> over one or more user-facing networks <b>111</b> (e.g., the internet).

0069As explained, the payment-service-system server <b>104</b> can have visibility to transaction information from both the merchant computing device <b>121</b> and the client device(s) <b>102</b>A and <b>102</b>B. Regarding the client device(s) <b>102</b>A and <b>102</b>B, the information can include account balances, credit and debit history, user-identifying information, and other transaction history. Regarding the merchant computing device <b>121</b>, the information can include sales history (including item descriptions and prices), inventory, funds transfers, purchase history, restaurant party size, and special offers. By having access to all of this information, the system illustrated in <figref idref="DRAWINGS">FIG. 1</figref> can provide additional features, such as offering to split checks at restaurants, making purchasing suggestions, or recalling past purchases for repayment. <figref idref="DRAWINGS">FIGS. 2 and 3</figref> illustrate an example messaging application. For example, a software agent or the payment-service-system server can recall transaction history information associated with the context of a messaging conversation, and use the information to suggest payments or provide reminders to the users about what transpired, e.g., “You had dinner at El Mitch's Sit-Eat-And-Go last Thursday and spent $37.59.”

0070<figref idref="DRAWINGS">FIG. 2</figref> illustrates two users, John Doe and Jack Smith, communicating using human-readable syntax in messaging application <b>212</b>. Messaging application <b>212</b> running on Jack Smith's user computing device <b>200</b>. The messaging application <b>212</b> includes a back button <b>202</b> to view other messages and a contacts button <b>204</b> to view additional contacts to add to a conversation, or to start a new conversation with. Prior to commencing the message, Jack Smith can select, via contacts button <b>204</b>, John Doe and a third-party messaging application, payment-service-system instant messenger (“PSSIM”), to the conversation. The example conversation includes a message <b>206</b> from Jack Smith to John Doe stating, “Did you pay me for BBQ last night?” Jack Smith can enter human-readable textual inputs in the text message field <b>214</b> and send the messages by pressing the send button <b>216</b>. The example conversation includes a response from John Doe in message <b>208</b> stating, “No, I'll pay you $20 now.” A third-party messaging application can identify the offer to pay by, for example, identifying that the message <b>206</b> contains the word “pay” and the string “$20.” The third-party messaging application can also identify predefined identifiers, such as keywords or characters, such as currency indicators (e.g., $, €, £, or ¥), payment words (e.g., pay, sale, sold, owe, or repay), and an amount, (e.g., twenty or 20). The payment-service-system server can also identify the reason for the payment by identifying nouns that are nearby the currency indicator. In the example of <figref idref="DRAWINGS">FIG. 2</figref>, the payment-service-system can identify the noun “BBQ” in message <b>206</b> and “$20” in message <b>208</b> as a reason associated with the payment command, to make clear what the payment is for.

0071The server <b>104</b> can receive this information via software agent <b>114</b>, and, based on identifying these strings, can suggest that John Doe make a payment by sending message <b>210</b>. The server <b>104</b> can also identify payment-service-system usernames for both Jack Smith and John doe, based on user identifying information, such as phone numbers. After identifying user names and the intent to make a payment, the server <b>104</b> can generate a message, such as, “PSSIM: Send $20.00 to @jackSmith for BBQ?” The colors of the messages <b>206</b>, <b>208</b>, and <b>210</b> can be different colors to identify them as from different senders. Alternatively, the messages can have usernames, pictures, or some other distinguishing characteristics to identify that they are from different senders.

0072<figref idref="DRAWINGS">FIG. 3</figref> illustrates an example of the conversation on John Doe's user computing device <b>300</b>. The user computing device <b>300</b> is illustrated with a messaging application <b>312</b> that has elements similar to those of messaging application <b>212</b>, including back button <b>302</b>, contacts button <b>304</b>, text message field <b>314</b>, and send button <b>316</b>. In addition, the messages are generally the same, but can appear on different sides because the sender and receiver are switched. In this example, message <b>306</b> corresponds with <b>206</b>; message <b>308</b> corresponds with <b>208</b>, and message <b>310</b> corresponds with <b>210</b>. However, since John Doe is the one sending money to Jack Smith, the messaging application <b>312</b> can include send button <b>320</b> and cancel button <b>318</b> corresponding to the message <b>310</b>, stating, “PSSIM: Send $20.00 to @jackSmith for BBQ?” By pressing send button <b>320</b>, John Doe can initiate a payment transaction to Jack Smith. By pressing cancel button, John Doe can notify the payment-service-system server that he does not want to complete a payment transaction.

0073Send button <b>320</b> and cancel button <b>318</b> can be generated using an API of messaging application <b>312</b>. The payment-service-system server can use the API to generate the two buttons <b>320</b> and <b>318</b>, the strings (send and cancel) in the buttons, and the response to pressing the buttons, e.g., return a message corresponding to the pressed button to the payment-service-system server. The payment-service-system server can then either continue to process the payment or discontinue suggesting the payment option after receiving the cancel message. For example, if the payment-service-system server sees another transaction for $20 for BBQ, the payment-service-system server can ignore that possible transaction because the user already declined that payment transaction. However, other embodiments can suggest the same payment option again, and the payment-service-system server can include a feature to allow users to set preferences on whether to repeat a past payment suggestion.

0074In an alternative embodiment, some messaging applications might not have an API for generating buttons. In these embodiments, users can respond to the third-party messaging application with human-readable commands, such as send or cancel. Other strings are possible too, such as “Yes, send $20” “OK” “Sounds good” and the like. If the payment-service-system server is unsure of the user's response, it can request a confirmation by sending another message, e.g., “Confirm request to send $20.00 to Jack Smith, respond with Yes or No.” Note that this embodiment can be combined with an embodiment that does allow for button APIs. In these embodiments, the user can either press the send button <b>320</b>, or respond with a send command or similar. In either case, the user can initiate a payment request as further illustrated in <figref idref="DRAWINGS">FIG. 4</figref>.

0075In still further embodiments, the payment-service-system server can be more explicit as to the messages it expects to receive from a user. For example, message <b>310</b> can instead state, “PSSIM: Send $20.00 to @jackSmith for BBQ? Respond with Send or Cancel.” If John Doe responds with anything but Send or Cancel, then the payment-service-system server can repeat the message, send a different message clarifying the desired response, or send a message that there will not be a payment transaction.

0076Embodiments can include a timeout mechanism, such that if the user does not respond within a predetermined time period, e.g., five minutes, then the payment-service-system server can send a message identifying that there will be no payment transaction, e.g., “The response time has elapsed. Please visit [URL] if you want to make a payment.”

0077Similarly, if the user expressly cancels the payment by sending a cancel message, either by pressing a cancel button or sending a message to cancel the transaction, the payment-service-system server can send a message confirming the termination of the payment transaction, e.g., “Payment transaction terminated.” In other embodiments, the payment-service-system server will not respond with a message, assuming that the user understands that there will be no payment transaction.

0078<figref idref="DRAWINGS">FIG. 4</figref> illustrates an embodiment in which John Doe notified the payment-service-system server that he wanted to proceed with a payment transaction, e.g., pressed the Send button <b>320</b>. In response to identifying a possible payment request, the payment-service-system server can generate a message <b>404</b>, stating, for example, “PSSIM: @johnDoe sent you $20.00.” In addition, the third-party messaging application <b>212</b> can also display a Deposit button <b>402</b> and a Decline button <b>400</b>. As previously explained, these buttons can be generated using an API, and pressing the buttons can cause a message to be returned to the third-party messaging application.

0079In this example, if Jack Smith presses the Deposit button <b>402</b>, this can generate a confirmation that Jack Smith accepts the $20, and the server <b>104</b> can transfer funds from an account corresponding to John Doe to an account corresponding to Jack Smith. Upon completing the funds transfer, the server <b>104</b> can send a message confirming completion, such as, “Transfer of $20.00 from @johnDoe to @jackSmith completed.”

0080If Jack Smith presses the Decline button <b>400</b>, then the messaging application <b>212</b> can transmit a decline message to server <b>104</b>. In response, the server <b>104</b> can terminate the payment transaction and generate a message, such as, “@jackSmith declined the $20.00.” (Not illustrated).

0081Alternative embodiments can use computer-readable syntax. For example, John Doe can input a computer-readable command, such as “/PSSIM $20 @jackSmith BBQ”. The payment-service-system server can then automatically effect the payment without further input from either user, or the process can pick up similar to <figref idref="DRAWINGS">FIG. 4</figref>. That is, the payment-service-system can generate a message to Jack Smith to determine whether he approves depositing the funds or would rather cancel the transaction.

0082<figref idref="DRAWINGS">FIGS. 5A and 5B</figref> further illustrate an example process for an automated third-party messaging application for providing payments. The process includes a system comprising at least six components: a first user computing device, a messaging-service server, a second user computing device, a software agent, a payment-service-system server, and a system of record server. Note that the software agent can run on the payment-service-system server or on a separate computing device. Starting with step <b>500</b>, the first user computing device begins a group messaging session. This can include adding participants to a list of recipients. In this example, the recipients can include at least a second user computing device and a payment-service-system, but more participants in the group are possible. Next, in step <b>502</b>, the first user computing device can generate a human-readable textual message that can include a human-readable textual command, and transmit the message to the messaging-service server. The human-readable textual message can include a message text portion and the list of recipients. Each recipient can be identified by a unique identifier, e.g., a username or phone number. The messaging-service server can receive the human-readable textual message (step <b>506</b>) and identify the recipients by the unique identifiers or payment proxies in the human-readable textual messages. In step <b>508</b>, the messaging-service server can forward the human-readable textual messages to the recipients of the group message. The second user computing device can display the message in step <b>510</b>, and the payment-service-system server can receive the human-readable textual message or human-readable textual input in step <b>512</b>.

0083The payment-service-system server can then process the human-readable textual message to identify a potential payment request command in step <b>514</b>. In some embodiments, the payment-service-system can verify that the potential payment request is made between participants of the conversation, and not identify a potential payment request if the conversation implies a payment to a person that is not a participant of the conversation. In other embodiments, the server <b>104</b> can process payment between a participant of the conversation and a party that is not a participant. If there is no potential payment request, the payment-service-system server returns to a wait state for receiving another message in step <b>512</b>. To identify a payment command, the payment-service-system can identify predefined keywords or characters, such as currency indicators (e.g., $, €, £, or ¥), payment words (e.g., pay, sale, sold, owe, or repay), and an amount, (e.g., twenty or 20). The payment-service-system server can also identify the reason for the payment by identifying nouns that are nearby the currency indicator. In the example of <figref idref="DRAWINGS">FIG. 2</figref>, the payment-service-system can identify the noun “BBQ” in message <b>206</b> and “$20” in message <b>208</b>, and identify this information as a human-readable textual command potentially related to a payment. The first and second user computing devices can correspond to unique user identifiers, such as phone numbers or online usernames. The payment-service-system server can also automatically identify whether the first and second user computing devices are associated with payment accounts on the payment-service-system server. To do this, the payment-service-system server can query a database to assess whether the unique user identifiers correspond to accounts. If the unique identifiers are associated with accounts, and the payment-service-system identified a payment command, the payment-service-system instant messaging application can suggest that the users might be interested in a payment option, and generate such an option in step <b>516</b>. Alternatively, the payment-service-system server can generate a payment transaction and seek immediate approval of the payee using the second user computing device, and proceed directly to step <b>532</b>. In this embodiment, the process can skip steps <b>516</b>-<b>530</b>. Alternatively, the process can proceed with these steps in parallel, and terminate when each party either cancels or approves the transaction. If the unique user identifiers are not associated with an account, the payment-service-system server can optionally allow one or more of the users to identify themselves by their user names, or ask them to associate their unique identifier with their account via a separate webpage. In step <b>518</b>, the software agent can convert the payment option into a human-readable message (e.g., “Would you like to send user $20?”) for transmission to the messaging-service server. In step <b>520</b>, the messaging-service server can receive the payment option from the payment-service-system server, and forward the payment option to the first user computing device (step <b>522</b>) and to the second user computing device (step <b>524</b>). <figref idref="DRAWINGS">FIG. 5B</figref> continues the process.

0084In <figref idref="DRAWINGS">FIG. 5B</figref>, the second user computing device can choose whether to continue with the payment option in step <b>526</b>. As an example, <figref idref="DRAWINGS">FIG. 3</figref> illustrates the giving a second user computing device an option press Send button <b>320</b> or Cancel button <b>318</b>. Optionally, the payment-service-system server can timeout if the second user computing device does not respond within a predetermined time, e.g., 2 minutes, in which case the payment transaction can terminate in step <b>528</b>. Similarly, if the second user presses the Cancel button <b>318</b>, the process can continue to step <b>528</b>, which terminates the payment transaction. (Note that the message may alternatively go to the software agent first). If the second user presses the Send button <b>320</b>, the second user computing device can send an acceptance message to the messaging-service server in step <b>530</b>, which then forwards the message to the payment-service-system server. (Note that the message may alternatively go to the software agent first.) The payment-service-system server can generate a payment transaction or suggestion to complete a payment transaction in step <b>532</b>. Also in step <b>532</b>, the payment-service-system server can verify that the sender of the message is the person that is sending the funds. Because at least two parties, a sender and a receiver, are part of the group messaging session, the payment-service-system server receives messages from both users. Therefore, as a layer of security, the payment-service-system server can ignore messages masquerading as selections from the recipient, and only continue if the payment-service-system server receives a response from the appropriate party. The payment-service-system server can transmit the payment transaction to the software agent, in step <b>534</b>, which can then transform the payment transaction into a human-readable form. For example, if the payment transaction includes an amount, a recipient, and deposit or decline options, the software agent can transform these fields into a message, such as, “Would you like to deposit or decline the $20 from Steve?” The software agent can then transmit the payment transaction to the messaging-service server in step <b>536</b>, which can then forward it to the second user computing device in step <b>538</b>, and to the first user computing device in step <b>540</b>.

0085<figref idref="DRAWINGS">FIG. 4</figref> illustrates an example payment transaction displayed on a first user device, which can include an identifier of the sender or recipient and the amount. On the first user computing device, the payment transaction can include the Deposit button <b>402</b> and the Decline button <b>400</b>, whereas the second user computing device can just display the message. If the first user presses the Decline button <b>400</b>, the first user computing device can send a termination message to the messaging-service server in step <b>542</b>. The messaging-service server can forward the termination message to the payment-service-system server in step <b>544</b>. The payment-service-system server can then return to step <b>512</b> and wait to identify another payment command. If the first user presses the Deposit button <b>402</b>, the process can proceed to step <b>546</b>, in which the messaging-service server can receive a deposit instruction or payment confirmation message, which it can forward to the software agent in step <b>548</b> (and optionally the second user computing device.) In step <b>550</b>, which can include executing a payment instruction to debit an account corresponding to the second user and to credit an account corresponding to the first user. Also in step <b>552</b>, the payment-service-system server can verify that the sender of the message is the person that is receiving the funds. Because at least two parties, a sender and a receiver, are part of the group messaging session, the payment-service-system server receives messages from both users. Therefore, as a layer of security, the payment-service-system server can ignore messages masquerading as selections from the appropriate party, and only continue if the payment-service-system server receives a response from the recipient. The payment-service-system server can then update a system of record server in step <b>548</b>, to ensure that the transaction is properly recorded in a system of record database.

0086The above processes described examples, such as steps <b>528</b> and <b>544</b>, of users terminating the transactions. The payment-service-system server can also offer other options for users to cancel a transaction. For example, the payment-service-system server can terminate a transaction when a user types the words “terminate” or “cancel.” If the process terminates for any reason, the payment-service-system server can avoid offering a similar payment transaction in the future. For example, the payment-service-system can ignore similar payment requests forever of for a predetermined time, e.g., 1-24 hours. If, after the predetermined time, the payment-service-system server identifies a similar or identical payment request, it can make the same offer again. If the predefined time has not elapsed, the payment-service-system server can ignore the payment request.

0087<figref idref="DRAWINGS">FIGS. 6-8</figref> illustrate an offer to split checks. The payment-service-system server <b>104</b> can receive purchase information related to a multi-party restaurant bill from a merchant computing device <b>121</b>, where one user paid the entire bill. The user computing device <b>600</b> is illustrated with a messaging application <b>618</b> that has elements similar to those of messaging application <b>212</b>, including back button <b>602</b>, contacts button <b>604</b>, text message field <b>614</b>, and send button <b>616</b>. The purchase information on the multi-party restaurant bill can include amount, party size, and itemized purchases with descriptions. If the party size is 4 and the bill is for $100, for example, then each person could pay one-fourth, or $25. If the one who paid is in a 4-way group messaging conversation, and the conversation includes information associated with the multi-party restaurant bill, such as the amount, the 4-way split amount, the restaurant name, or the items purchased, then the payment-service-system server can offer suggestions to the users, such as offering to repay the 4-way split amount or recalling purchase information. As an example, in <figref idref="DRAWINGS">FIG. 6</figref>, the payor, Pedro, can send a message <b>604</b>, such as, “Would you guys pay me back for dinner last night?” Upon receiving this message, the payment-service-system can automatically identify purchase information consistent with a restaurant dinner expense from the previous evening. The purchase information can be stored in one or more databases <b>107</b><i>a</i>-<i>n</i>. Once recalled, the purchase information can include the number of people at the table, which in this example is four. The payment-service-system server can also identify user information based on unique identifiers of the participants in the group messaging conversation. As previously explained, the payment-service-system server can look up user information based on unique identifiers, such as phone numbers or user names. In this case, the payment-service-system server can identify the other parties as Fae, Steve, and Tim. If the group messaging conversation has four people in it, the payment-service-system server can decide to offer to split payment amongst the four group messaging participants. If there are not four participants, the payment-service-system server can decide not to offer to split the payment, or it still can, suggesting that perhaps at least some of the group messaging participants were also at the dinner.

0088In one embodiment, after receiving a message (e.g., message <b>604</b>) related to a possible payment request involving a multi-way split of a bill, the payment-service-system server can send a message <b>606</b> to suggest a payment, such as, “PSSIM: Pedro, would you like to split the $100 dinner bill at Restaurant with Fae, Steve, and Tim?” offering Pedro to request payment. When making the payment suggestion, the payment-service-system server can request that Pedro, who needs reimbursement, select participants from the group message to send payment requests to. In this way, Pedro can explicitly identify those who owe him by one or more of buttons <b>608</b>, <b>610</b>, and <b>618</b>, corresponding to Fae, Steve, and Tim, respectively. After Pedro selects who should receive payment requests, (e.g., select each person or only a couple) he can press send button <b>609</b>. Alternatively, Pedro can press cancel button <b>613</b> to terminate the payment transaction. Embodiments can also allow a natural language response, such as “yes,” or “yes, but only Fae and Steve.”

0089After the payment-service-system server receives a response, the payment process can proceed similar to the process as illustrated in <figref idref="DRAWINGS">FIGS. 5A-5B</figref>, except that instead of one payor second user computing device, there is also a third and a fourth user computing device, which each behave similarly to the illustrated second user computing device. <figref idref="DRAWINGS">FIG. 7</figref> illustrates the process from the point of view if the payee using user computing device <b>600</b>. In this example, Pedro selected each of Fae, Steve, and Tim to receive payment requests, represented by messages <b>700</b>, <b>702</b>, and <b>704</b>, respectively. Each of these users can receive the all the messages, and decide whether to proceed using buttons similar to those illustrated in <figref idref="DRAWINGS">FIG. 3</figref>. However, since the payment-service-system server knows who originates each message, the payment-service-system server will know who responds to each question, and can keep track who approved paying for the split checked—the payment-service-system can ignore responses if they do not come from the correct person. After receiving responses from Fae, Steve and Tim, the payment-service-system server can generate one or more messages to request that Pedro deposit or decline the payments using buttons similar to those illustrated in <figref idref="DRAWINGS">FIG. 4</figref>. Alternatively, Pedro can input a natural language response, such as “yes,” or “please deposit the funds.”

0090Rather than paying splitting the bill into fourths, the bill could be split up by entrées. For example, Pedro can assign meals to each user, e.g., Fae ordered fries, Steve ordered salami, and Ted ordered Texas BBQ. The payment-service-system server could send purchase information, including an itemized bill, and anyone could split the various menu items, and any remaining items such as appetizers could be split in fourths. The payment-service-system server can also calculate tax and tip to split those items appropriately based on what users purchased.

0091In addition to the check splitting embodiment, users can split other purchases, such as groceries or items purchased for others. The payment-service-system server could recall the cost of these items and split them between other participants in an instant messaging application in a manner similar to that described in the context of <figref idref="DRAWINGS">FIGS. 6-8</figref>.

0092In another embodiment, the payment-service-system server can also make other suggestions to participants in an instant messaging conversation. For instance, if the payment-service-system server notices users discussing getting coffee, the payment-service-system server can suggest making a transaction similar to past transactions, such as pre-purchasing a specialty coffee drink that the user has purchased in the past. Upon receiving a confirmation that the user would like to make the purchase, the payment-service-system server can contact a merchant computing device to notify it of the transaction and to make the specialty coffee drink for the user to pick up.

0093The client device(s) <b>102</b>A and <b>102</b>B can also be voice-activated and process natural language, such as smart speakers (e.g., Amazon Echo Google Home) or a virtual assistant that listens for verbal commands (e.g., Microsoft Cortana, Google Now, or Apple Siri). These voice-activated devices can include APIs for adding third-party applications. One such third-party application can be a payment application activated through voice-operated commands. <figref idref="DRAWINGS">FIG. 6</figref> illustrates an embodiment for processing a payment using a smart speaker.

0094Users can configure their smart speakers or personal assistants (i.e., user computing device) or their payment-service-system server accounts to process natural language payment commands. To do this, the user can, for example, make voice commands (e.g., “register with payment-service-system server”) to register an account on a payment-service-system server with their user computing device. The payment-service-system server can respond with follow-up questions to authenticate the user, such as their password or with security questions. The payment-service-system server can also use two-factor authentication by requesting that the user verify the registration via a pre-registered second user computing device, such as a smartphone or by clicking a link in an email. Alternatively, the user can logon to a web site of the payment-service-system server to pre-authorize the user computing device to use payment commands. Embodiments can also require special keywords to prevent others from making unauthorized payment commands

0095<figref idref="DRAWINGS">FIG. 8</figref> illustrates an embodiment for processing payments using voice-activated commands on a smart speaker or a virtual assistant, which <figref idref="DRAWINGS">FIG. 8</figref> illustrates as a first user computing device. The first user computing device can receive a voice command in step <b>800</b>. The voice command can include an activation command to notify the first user computing device to listen for a command. An activation command can include the press of a button or a keyword, such as “wakeup.” Once listening, the user can speak a payment request to the first user computing device, such as, “Please pay John $20” or “Please request $25 from John.” The payment request can also optionally include a password or secret keyword to authenticate the payment request. After receiving the voice command, the first user computing device can transmit the payment request to a voice-recognition server to do the natural-language processing in step <b>802</b>. The voice-recognition can include identifying parameters for the payment request, including a recipient, an amount, a reason for the payment request, and optional authentication information, such as a password or secret keyword to complete the payment transaction. After identifying the command as a payment request, the voice-recognition server can transform the voice command into a computer-readable payment request, encapsulate the payment request in a network packet, and transmit the payment request to a payment-service-system server. The payment-service-system server receives the payment request in step <b>804</b>. In the optional embodiment with authentication, the payment-service-system server can authenticate the user computing device by, for example, using two-factor authentication or verifying the keyword in the payment request. If the payment-service-system server cannot authenticate the user, the process can terminate in step <b>812</b>. If the user is authenticated, the payment-service-system server can proceed to step <b>806</b> to identify user information in the payment request and corresponding payment accounts.

0096Upon identifying user information, the payment-service-system server can request additional information or confirmation from the first user computing device in step <b>808</b>. The request can be via an audible message, or, alternatively as a textual message via a separate device, e.g., another user computing device or over email. The request can be to confirm the recipient and the amount. The request for additional information can include a last name, for example, if there are two possible recipients with the same last name. The user can input a confirmation or additional information in step <b>809</b>. If, for example, the payment-service-system server requests confirmation that the user intends to send a payment request to “John Smith,” the user can respond by stating that the recipient is “John Doe.” The user can also respond with a command to stop the transaction, e.g., “terminate payment transaction.” The voice-recognition server can receive and process the response from the first user computing device in step <b>810</b>. The possible responses can be predefined, e.g., “cancel,” “different user,” or “confirm.” Each of these commands can be associated with synonyms that can be found in a thesaurus or preprogrammed into the voice-recognition server. If a user responds with any synonym of these commands, the voice recognition server can convert the synonym to a command that the payment-service-system server will understand, and send the response to the payment-service-system server in an encapsulated network packet. The payment-service-system server can process the request in step <b>811</b>. Processing the request can include canceling the transaction in step <b>812</b>. Alternatively, the payment-service-system server can identify a new command, such as instead of sending a payment request to John Smith, it should go to John Doe, in which case the process can proceed back to step <b>806</b> to re-identify user information and request confirmation again. Finally, if the user confirmed the payment transaction, the process can continue to step <b>812</b> to generate a notification to the payment request recipient to authorize the payment request.

0097In step <b>814</b>, the second user computing device can receive the payment request via an SMS message, an email, or notification in an application from the payment-service-system server. The user can either decline authorization or authorize the payment request. Upon receiving the user's selection, the process can continue to step <b>812</b> to cancel the transaction, or to step <b>816</b> to process the payment transaction. Processing the payment transaction can include transferring funds from one account to another, i.e., from an account associated with the first user computing device to an account associated with the second user computing device, or vice versa. The payment-service-system server can update the account information in local databases, and transmit a transaction to a system of record server in step <b>818</b> to record the transaction in a database associated with a bank. In addition to updating the system of record server, the payment-service-system server can send notifications to the first user computing device (step <b>822</b>) and the second user computing device (step <b>820</b>) to notify them that the transaction was completed. In alternative embodiments, the notifications in steps <b>822</b> and <b>820</b> can be sent first to the voice-recognition server, which can then transmit the notifications to the respective user computing devices.

0098<figref idref="DRAWINGS">FIG. 8</figref> illustrates the notifications going to the same user computing devices that were used to process the payment request, but they could alternatively be sent to other user computing devices associated with the same users. For example, some smart speakers might not allow third-party servers to send notifications to or request information from users on the same smart speakers. Therefore, some embodiments contemplate initiating a payment transaction on a smart speaker, but completing subsequent steps in the process on a different user computing device, such as a smartphone, but owned by the same user.

0099By recognizing text and speech the systems and methods described above can add additional functionality to messaging applications, chatbots, smart speakers, etc. As described above, this additional functionality includes making online payments, accessing online banking information (including past transactions, balance, funds transfer, etc.) The systems can recognize textual conversations and respond in intelligent and useful ways to provide payment and banking services.

0100The 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.

0101The 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.

0102The 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.

0103The 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.

0104One or more different inventions may be described in the present application. Further, for one or more of the invention(s) described herein, numerous embodiments may be described in this patent application, and are presented for illustrative purposes only. The described embodiments are not intended to be limiting in any sense. One or more of the invention(s) may be widely applicable to numerous embodiments, as is readily apparent from the disclosure. These embodiments are described in sufficient detail to enable those skilled in the art to practice one or more of the invention(s), and it is to be understood that other embodiments may be utilized and that structural, logical, software, electrical and other changes may be made without departing from the scope of the one or more of the invention(s). Accordingly, those skilled in the art will recognize that the one or more of the invention(s) may be practiced with various modifications and alterations. Particular features of one or more of the invention(s) may be described with reference to one or more particular embodiments or figures that form a part of the present disclosure, and in which are shown, by way of illustration, specific embodiments of one or more of the invention(s). It should be understood, however, that such features are not limited to usage in the one or more particular embodiments or figures with reference to which they are described. The present disclosure is neither a literal description of all embodiments of one or more of the invention(s) nor a listing of features of one or more of the invention(s) that must be present in all embodiments.

0105Headings of sections provided in this patent application and the title of this patent application are for convenience only, and are not to be taken as limiting the disclosure in any way.

0106Devices that are in communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. In addition, devices that are in communication with each other may communicate directly or indirectly through one or more intermediaries.

0107A description of an embodiment with several components in communication with each other does not imply that all such components are required. To the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of one or more of the invention(s).

0108Further, although process steps, method steps, algorithms or the like may be described in a sequential order, such processes, methods and algorithms may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described in this patent application does not, in and of itself, indicate a requirement that the steps be performed in that order. The steps of described processes may be performed in any order practical. Further, some steps may be performed simultaneously despite being described or implied as occurring non-simultaneously (e.g., because one step is described after the other step). Moreover, the illustration of a process by its depiction in a drawing does not imply that the illustrated process is exclusive of other variations and modifications thereto, does not imply that the illustrated process or any of its steps are necessary to one or more of the invention(s), and does not imply that the illustrated process is preferred.

0109When a single device or article is described, it will be readily apparent that more than one device/article (whether or not they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described (whether or not they cooperate), it will be readily apparent that a single device/article may be used in place of the more than one device or article.

0110The functionality and/or the features of a device may be alternatively embodied by one or more other devices that are not explicitly described as having such functionality/features. Thus, other embodiments of one or more of the invention(s) need not include the device itself.

0111Techniques and mechanisms described or referenced herein will sometimes be described in singular form for clarity. However, particular embodiments include multiple iterations of a technique or multiple instantiations of a mechanism unless noted otherwise.

0112Various techniques will now be described in detail with reference to a few example embodiments thereof as illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a thorough understanding of one or more aspects and/or features described or reference herein. It will be apparent, however, to one skilled in the art, that one or more aspects and/or features described or reference herein may be practiced without some or all of these specific details. In other instances, well known process steps and/or structures have not been described in detail in order to not obscure some of the aspects and/or features described or reference herein.

0113Embodiments of the subject matter and the operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, e.g., one or more modules of computer program instructions, encoded on a non-transitory computer storage medium for execution by, or to control the operation of, data processing apparatus. Alternatively or in addition, the program instructions can be encoded on an artificially-generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. A computer storage medium can be, or be included in, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, while a computer storage medium is not a propagated signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially-generated propagated signal. The computer storage medium can also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

0114The operations described in this specification can be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources.

0115The term “data processing apparatus” encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, a system on a chip, or multiple ones, or combinations, of the foregoing The apparatus can include special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). The apparatus can also include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination of one or more of them. The apparatus and execution environment can realize various different computing model infrastructures, such as web services, distributed computing and grid computing infrastructures.

0116A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language resource), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

0117The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

0118Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for performing actions in accordance with instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive), to name just a few. Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

0119To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending resources to and receiving resources from a device that is used by the user; for example, by sending web pages to a web browser on a user's client device in response to requests received from the web browser.

0120Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), an inter-network (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

0121The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some embodiments, a server transmits data (e.g., an HTML page) to a client device (e.g., for purposes of displaying data to and receiving user input from a user interacting with the client device). Data generated at the client device (e.g., a result of the user interaction) can be received from the client device at the server.

0122A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.

0123While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any inventions or of what may be claimed, but rather as descriptions of features specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

0124Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

0125Presently 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.

0126Thus, particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous.