NOTIFICATIONS FOR SPLITTING TRANSACTIONS

Recommended notifications can be sent to mobile devices based at least in part on one or more conditions. The recommended notifications can recommend a user execute a split transaction workflow or a payment plan workflow for a recently charged transaction. In one examples, a system comprises a computing device. The computing device can be configured to identify an authorization of a transaction submitted by a merchant device and determine a context parameter associated with the transaction based at least in part on transaction data. A split classification can be determined for the transaction using a machine learning model based at least in part on the context parameter. A notification can be transmitted to a client device of a user associated with a payment instrument for the transaction based at least in part on the split classification.

BACKGROUND

During various occasions, a user may pay a bill on behalf of one or more other users. For example, the user may pay for dinner for a group of individuals in order to reduce the amount of time needed for handling the bill. Each individual in the group can desire to pay the user back for their meal. In various mobile applications, each individual can navigate through various user interface for initiating a repayment to the user that paid the bill.

DETAILED DESCRIPTION

The various embodiments of the present disclosure relate to generating notifications that recommend a user execute a workflow for a recently authorized transaction based at least in part on a context of the recently authorized transaction. For example, various embodiments can send a notification that recommends performing a workflow to split a recent transaction. The split transaction workflow can be performed using a mobile application to split the recent transaction among other users. The split transaction workflow ocan coordinate sending repayment requests to the other users at one or more peer-to-peer mobile payment platforms. Various embodiments can send the notification to the user recommending that the user split a transaction because the various embodiments can predict that the user may be interested in splitting the recent transaction among other users.

In certain situations, a user may incur a charge on behalf of one or more users. For example, a user may pay the bill for dinner for a group of friends. In another example, the user may pay the bill for a house rented by a group of friends during a vacation. In these situations, the user has to remember to ask the other users to pay their share of the expense. In some cases, the user may send repayment requests. In order to send the repayment requests, the user may first have to remember to find the transaction in their credit card or banking application. Then, the user may have to initiate a split transaction workflow for the identified transaction. If the user does not remember to take these actions soon after the transaction has occurred, the user may forget to ask other users to pay their share of the bill.

To address these issues, the various embodiments of the present disclosure can identify recent transactions for a user. The embodiments can predict whether each identified transaction was incurred by the user on behalf of a group of users. The various embodiments can also determine whether the user would likely be interested in splitting the transaction. If it is predicted that the user would likely want to split the transaction, a notification can be transmitted to a mobile device of the user as a recommendation. In addition, the embodiments can be used to predict whether the user may be interested in performing other financial workflows for a recent transaction. For example, instead of a split transaction recommendation, the embodiments can predict whether the user may be interested in creating a payment plan for the recently authorized transaction. As such, the embodiments can transmit a notification to the client device of the user based at least in part on a context of the transaction indicating that the user may be interested in paying for the transaction with a series of payments over time.

The embodiments provide certain improvements from prior approaches in the field of mobile payments. The embodiments improve the user experience by making a financial transaction workflow easier and quicker to complete. First, for example, the user does not have to identify and select a particular transaction for a split transaction workflow. Instead, the various embodiments can recommend that the user may be interested in splitting a transaction. Second, the embodiments provide a process that requires fewer user interactions (e.g., fewer user interface selections) to complete a split transaction workflow, which increases the speed at which the user can accomplish the task. As such, the embodiments reduce the amount of time that is required navigated through various user interfaces for completely workflow, such as a split transaction workflow or a payment plan workflow. Third, the user does not have to remember which transaction to select for a transaction workflow. Instead, the embodiments can identify and present to the user transactions they would likely be interested in executing a split transaction workflow, a payment plan workflow or suitable other transaction workflows.

In the following discussion, a general description of the system and its components is provided, followed by a discussion of the operation of the same. Although the following discussion provides illustrative examples of the operation of various components of the present disclosure, the use of the following illustrative examples does not exclude other implementations that are consistent with the principals disclosed by the following illustrative examples.

As illustrated inFIG.1, shown is an example scenario100of a client device103displaying a split notification106superimposed on a user interface109. In the depicted scenario100, a user recently paid a hotel bill at Hotel ABC with a payment instrument (e.g., credit card, debit card, charge card, etc.). Since the charge was recently authorized, the charge has a present status as a pending transaction that has been authorized. Typically, after a charge has been authorized as a pending transaction, the merchant receives an authorization code.

In this scenario100, the pending transaction for the hotel charge is evaluated and determined to likely be splitable with another user based at least in part on various factors. In some instances, a machine learning model can be used to predict whether the hotel charge is likely to be split with at least one other user. For example, the data for the pending transaction may indicate one or more of a number of guests, extra guest fees, and other hotel information. This transaction data, among other possible data, can be used to predict whether to recommend a split transaction workflow to user.

As a result, the split notification106can be sent as a push notification to the client device103of user (e.g., the account owner) for the payment instrument used for the hotel charge. The split notification106can include text to identify the pending transaction that has been authorized for the hotel charge. The text can include the charge amount, merchant information (e.g., merchant identifier/name, location for the transaction, etc.), and other suitable transaction information. The split notification106can also include a deep link for activating a split transaction workflow of a mobile application executed in the client device103.

As such, upon a receiving a “Tap” or a selection of the split notification106, the deep link for the mobile application can be activated. The deep link can cause the mobile application to be executed and to direct the mobile application to a split transaction user interface. As such, the deep link can direct the mobile application to an advanced stage in the split transaction workflow, which shortens the amount of time used to complete a split transaction workflow. In addition, since the transaction recently occurred, the user can easily decide whether to split the transaction with other users and which users should be included in covering a portion of the hotel charge.

AlthoughFIG.1uses the example of splitting the cost of a hotel bill with multiple users, this is purely an illustrative example to highlight an example of an embodiment of the present disclosure. Other types of charges could be split using the same or a similar process or workflow (e.g., a large purchase such as a restaurant bill, a large purchase for multiple tickets to an event, a purchase of multiple airline tickets, etc.) Additionally, other types of workflows could be performed on a recent transaction.

With reference toFIG.2, shown is a network environment200according to various embodiments. The network environment200can include a computing environment203, a client device103, and a merchant device206, which can be in data communication with each other via a network209. The network209can include wide area networks (WANs), local area networks (LANs), personal area networks (PANs), or a combination thereof. These networks can include wired or wireless components or a combination thereof. Wired networks can include Ethernet networks, cable networks, fiber optic networks, and telephone networks such as dial-up, digital subscriber line (DSL), and integrated services digital network (ISDN) networks. Wireless networks can include cellular networks, satellite networks, Institute of Electrical and Electronic Engineers (IEEE) 802.11 wireless networks (i.e., WI-FI®), BLUETOOTH® networks, microwave transmission networks, as well as other networks relying on radio broadcasts. The network209can also include a combination of two or more networks209. Examples of networks209can include the Internet, intranets, extranets, virtual private networks (VPNs), and similar networks.

The computing environment203can include one or more computing devices that include a processor, a memory, and/or a network interface. For example, the computing devices can be configured to perform computations on behalf of other computing devices or applications. As another example, such computing devices can host and/or provide content to other computing devices in response to requests for content.

Moreover, the computing environment203can employ a plurality of computing devices that can be arranged in one or more server banks or computer banks or other arrangements. Such computing devices can be located in a single installation or can be distributed among many different geographical locations. For example, the computing environment203can include a plurality of computing devices that together can include a hosted computing resource, a grid computing resource or any other distributed computing arrangement. In some cases, the computing environment203can correspond to an elastic computing resource where the allotted capacity of processing, network, storage, or other computing-related resources can vary over time.

Various applications or other functionality can be executed in the computing environment203. The components executed on the computing environment203include a notification service212, a machine learning service215, and other applications, services, processes, systems, engines, or functionality not discussed in detail herein.

The notification service212can be executed to identify recent transactions and determine whether to recommend a split transaction workflow or other suitable transaction workflows available on a mobile application executed on the client device103. If a split is recommended, then the notification service212can transmit a split notification to the client device103of the user associated with the transaction.

The machine learning service215can be executed to develop, train, test, validate, and deploy machine learning models for predicting whether a recent transaction is likely to be split among multiple users. In another context, the machine learning models can be used to predict whether a particular user for a transaction would be interested in splitting the particular transaction among other users. The machine learning service215can be executed to retrain the machine learning models based on feedback data, such as whether prior transactions were split (e.g., splits executed after transmitted split notifications and splits executed without split notification, etc.).

Also, various data is stored in a data store218that is accessible to the computing environment203. The data store218can be representative of a plurality of data stores218, which can include relational databases or non-relational databases such as object-oriented databases, hierarchical databases, hash tables or similar key-value data stores, as well as other data storage applications or data structures. Moreover, combinations of these databases, data storage applications, and/or data structures may be used together to provide a single, logical, data store. The data stored in the data store218is associated with the operation of the various applications or functional entities described below. This data can include one or more user accounts221, machine learning model data224, notification rules227, and potentially other data.

Individual user accounts221can represent an account or a profile for individual users. Each user account221can include a device data230, transaction data233, preferences236, user classification237, and other suitable data for a respective user. The device data230can include data relating to a device operated or owned by a user. For example, the device data230can include a device identifier (e.g., an assigned phone number, a device serial number, etc.), a device type, a device operating system, a list of installed applications, and other suitable device data.

The transaction data233can represent transaction information relating to pending transactions (e.g., recent transaction), posted transaction, and/or other suitable transaction data. For example, the transaction data233can include information such as a transaction amount, a transaction type (e.g., online, magnetic stripe, Europay Mastercard and Visa (EMV) security chip, etc.), a transaction location, a payment instrument identifier (e.g., a credit card number, a financial account, etc.), merchant data, a purchase category (e.g., hotel/accommodation, dining, grocery, gas, etc.), and/or other suitable transaction information. The merchant data can include a merchant identifier, transaction context, and/or other suitable data. The transaction context can provide information relating to what goods and services were purchased.

The preferences236can represent one or more preferences or criteria specified by the user regarding split notifications. The preferences236can include a whether the user has decided to participate in the split notifications. The preferences236can also include characteristics of transactions that the user may be interested in splitting. For instance, the preferences236can include a minimum purchase threshold, a purchase category (e.g., lodging charges, dining charges), a time period (e.g., specified time period for a business trip, transactions during a weekday), and/or other suitable preferences236.

The user classification237can be used to represent the spending ability of the user and/or their previous history with splitting transactions. Some example user classifications237can include active split users, business users, dormant split users, inactive split users, and other suitable classification. In some examples, the notification service212can determine the user classification237based at least in part on one or more factors, such as access to financial resources (e.g., employment, assets, etc.), history with executing split transactions, and/or other suitable historical information. In some examples, the notification service212can transmit split notifications to users that are classified as dormant split users or inactive split users because these users may be unaware of this feature for a mobile application.

The machine learning model data224can represent data used by machine learning models, such as feedback data, training data sets, and/or other suitable machine learning data. For example, the machine learning model data224can include data that relates to which features (e.g., variables) are selected for optimizing machine learning models for predicting split transaction events or other suitable transaction workflow events. A machine learning model can be a file that is generated from executing a machine learning algorithm based at least in part on a training data set. Each machine learning model can include rules, patterns, values, and/or other aspects related to making a prediction. The machine learning models can be generated using one or more classification algorithms, such as decision tree, linear regression, logistic regression, artificial neural network, k-nearest neighbors, k-means, and other suitable machine learning algorithms.

The notification rules227can represent one or more rules for determining whether to transmit a notification to a client device103. For example, although the notification service212may determine to send a split notification, a notification rule227can specify whether it is permissible to send the split notification at the present time. The notification rules227can be configured to send notifications at appropriate times in order to not annoy the user or alternatively, at a time where the user may be more likely to review and select the notification. For example, the notification rules227can have time windows that correspond to historical trends of when a particular user is more likely to at least review notification and possibly select the notification.

The client device103is representative of a plurality of client devices that can be coupled to the network209. The client device103can include a processor-based system such as a computer system embodied in the form of a personal computer (e.g., a desktop computer, a laptop computer, or similar device), a mobile computing device (e.g., personal digital assistants, cellular telephones, smartphones, web pads, tablet computer systems, music players, portable game consoles, electronic book readers, and similar devices), media playback devices (e.g., media streaming devices, set-top boxes, and similar devices), a videogame console, or other devices with like capability. The client device103can include one or more displays, such as liquid crystal displays (LCDs), gas plasma-based flat panel displays, organic light emitting diode (OLED) displays, electrophoretic ink (“E-ink”) displays, projectors, or other types of display devices. In some instances, the display can be a component of the client device103or can be connected to the client device103through a wired or wireless connection.

The client device103can be configured to execute various applications such as an operating system238, a client application239, or other applications. The operating system238can be executed to manage computing hardware and software resources. The operating system238can be executed to display one or more user interfaces242and to cause the execution of the client application239. The operating system238can be executed to display notifications (e.g., split notification, payment plan notifications). The notifications can be triggered based at least in part on communication from the notification service212and/or the client application239.

The client application239can be executed to facilitate functionality associated with the notification service212. The client application239can be executed in a client device103to access network content served up by the computing environment203or other servers, thereby rendering a user interface242on the display. In some examples, the client application239can display user interfaces242for the notification service212. Upon a notification being selected on the user interface242, the client application239can be activated to display a particular user interface242in an advanced stage of a split transaction workflow, a payment plan workflow, or other suitable transaction workflows associated with the client application239.

Additionally, the client application239can include a browser, a dedicated application, or other executable, and the user interface242can include a network page, an application screen, or other user mechanism for obtaining user input. The client device103can be configured to execute applications beyond the client application239such as email applications, social networking applications, word processors, spreadsheets, or other applications.

The merchant device206can represent one or more devices of a payment environment for a merchant. As such, the merchant device206can include point-of-sale (POS) devices (e.g., online and at retail locations), merchant servers (e.g., servers for hosting website and payment processing functionality), and/or other suitable or similar devices. The merchant devices206, such as a PoS device, can accept payment instruments from a user in order to complete a purchase of an item or service. The merchant devices206can store authorization data245received from the notification service212. The authorization data245can comprise pending transactions, posted transactions, and/or other suitable transactions. The pending transactions may have an authorization code that indicates a transaction has been authorized. For example, after the authorization data245has been generated for the merchant device206, then the notification services212can identify the pending transaction for evaluation for a split notification.

Next, a general description of the operation of the various components of the network environment200is provided. To begin, a user of the client device103can agree to participate in receiving split notifications106for transactions completed with their payment instrument. In some embodiments, the notification service212can assess a user account221for the user in order to determine some initial context parameters. For example, the notification service212can determine a user classification237for the user based at least in part on the transaction history, split transaction history, historical transaction types (e.g., business transactions or personal transactions), type of payment instrument (e.g., business credit card, personal credit card), and/or other suitable data.

Afterwards, the user can complete a purchase with his or her payment instrument. The notification service212can determine whether to send a split notification106to the client device103of the user based at least in part on one or more factors. In some examples, the notification service212can use a trained machine learning model to predict whether the user would desire to use the split transaction workflow of the client application239for the purchase. In some scenarios, the machine learning model can predict the likelihood of the user using split transaction workflow based at least in part on one or more factors indicating that the transaction was made on behalf of at least one other user and the user would be interested in requesting repayment of at least a portion of the purchase from the other user.

For example, the machine learning model may predict that the user would likely be interested in a split transaction workflow because the transaction occurred at restaurant and the transaction amount was higher than the typical amount for a single individual at the restaurant. For example, the transaction amount may be compared to an average amount for an entree menu item of a restaurant of a certain tier, an average amount for an entree menu item at the restaurant, or in comparison for other suitable restaurant data. In addition, the machine learning model may also factor in calendar data for the user. The calendar data for the user can indicate the user had a meeting around a breakfast time period, a lunch time period, or a dinner time period.

Accordingly, the notification service212can transmit a split notification106to the client device103of the user. Upon the selection of the split notification106, the operating system238can activate a deep link for executing the client application239. The deep link activation can direct the client application239to an advanced state in the client application239for a split transaction workflow. As previously discussed, this allows a user to skip one or more steps in the typical client-side split transaction workflow because of the selection of the split notification106.

In some examples, the machine learning models can be trained based at least in part on feedback data and preferences236provided by the user. As such, a deployed machine learning model can be optimized for an individual user or a group of individuals with similar preferences236.

Turning now toFIG.3A, shown is an example of a user interface242that is configured for a user to select activating a transaction workflow (e.g., a split transaction workflow or a payment plan workflow). The user interface242is one example that can be displayed on the client device103. InFIG.3A, the user interface242can be displayed in response to an activation of a deep link associated with the split notification106or other notifications for suggesting another workflow associated with the client application239. The activation of the deep link causes the operating system238to execute the client application239and to display the user interface242at an advanced stage of the transaction workflow.

The user interface242can represent one or more user interfaces for receiving data for a split request of a selected transaction or for receiving data for a payment plan request of the selected transaction. The user interfaces242can display transaction data233associated with the selected transaction in a transaction portion306of the user interface242. The transaction data233can include a transaction amount, a merchant identifier, a transaction date, a transaction status (e.g., pending or posted transaction), a transaction location, and other suitable information.

The user interface242can include a user interface elements for display, such as a split user interface element309, a plan user interface element312, and other suitable user interface elements. The user interface242can include a map315that indicates the transaction location. The split user interface element309can be configured to display one or split user interfaces for executing a split transaction workflow. The plan user interface element312can be configured to display one or more payment plan user interfaces for executing a payment plan workflow.

FIG.3Billustrates an example of a split user interface320for a user to provide data for executing a split transaction workflow. In some examples, the split user interface320can be displayed by the client application239in response to a selection of the split user interface element309in the user interface242. In other examples, the split user interface320can be displayed in response to activating the deep link associated with the split notification106. Additionally, the content shown in the split user interface320can be displayed in one or more user interfaces.

As shown, the split user interface320can include a requestee area323and a payback area326. The requestee area323can include a selected requestee (e.g., Jane Done) and a portion amount of the transaction amount. The requestee area323can configured to receive a selection or entry of the requestee and an entry of the portion amount. The selected requestee include a selected account of the requestee to request repayment. For instance, the requestee area323indicates that Jane Doe's “Money Peer-2-Peer Platform” account has been selected.

The payback area326can represent an area for selecting an account of the user for depositing repayment funds received from the requestees. The payback area326can include a first option for a credit account of John Doe and a second option for a peer-to-peer account of John Doe. The payback area326can receive a selection of one of the options.

FIG.3Cillustrates an example of a plan user interface330for a user to provide data for executing a payment plan workflow of the client application239. In some examples, the plan user interface330can be displayed by the client application239in response to a selection of the plan user interface element312. In other examples, the plan user interface element312can be displayed in response to activating the deep link associated with a notification displayed by the operating system238.

The plan user interface330can include a payment area333and a plan duration area336. The payment area33can be configured for the user to set a payment amount (e.g., $100) and the plan duration area336can be configured for the user to set a time period for the plan (e.g., 12 months).

Referring next toFIG.4A, shown is a flowchart that provides one example of the operation of a split workflow of the notification service212. The flowchart ofFIG.4Aprovides merely an example of the many different types of functional arrangements that can be employed to implement the operation of the depicted portion of the notification service212. As an alternative, the flowchart ofFIG.4Acan be viewed as depicting an example of elements of a method implemented within the network environment200.

Beginning with box401, the notification service212can identify authorization data245for a recent transaction. In some examples, the authorization data245can be generated by the notification service212after receiving an authorization request for a transaction from a merchant device206. After the transaction has been approved as a pending transaction, authorization data245can be generated for the transaction and the authorization data245can be transmitted to the merchant device206. In some examples, the authorization data245can include an authorization code.

In box404, the notification service212can determine one or more context parameters for the pending transaction. The context parameters can be identified from the transaction data233and/or the authorization data245, such as a transaction amount, a merchant identifier, a purchase category (e.g., lodging, grocery, retail, travel, entertainment, dining, etc.), a transaction date, a transaction location, and other suitable. In addition, the context parameters can include historical transaction data, such as previous transaction splits, previous spending patterns, and other historical transaction activity.

In some embodiments, the notification service212can determine a user classification237of the user as a context parameter. The user classification237can represent a classification of the user associated with the payment instrument used for the pending transaction. For example, the user classification237can be used to represent the spending ability of the user and/or their previous history with splitting transactions. Some example user classifications237can include active split users, business users, dormant split users, inactive split users, and other suitable classification. In some examples, the notification service212can determine the user classification237based at least in part on one or more factors, such as access to financial resources (e.g., employment, assets, etc.), history with executing split transactions, and other suitable historical information. In some embodiments, the notification service212can use the user classification237to determine the split classification for the pending transaction and/or subsequent actions to be taken for the user associated with the pending transaction.

In box407, the notification service212can determine a split classification for the pending transaction based at least in part on the one or more context parameters. The split classification can be a numerical value or a classification type (e.g., low split likelihood, medium split likelihood, high split likelihood). In some implementations, the notification service212can use a machine learning model for predicting a split classification for the pending transaction. In some examples, the split classification can represent a likelihood of the pending transaction being split with at least one other user or the split classification can be used to encourage the user to perform more split transactions.

In some examples, the split classification can be represented as numerical value for the likelihood of the user to split the pending transaction. In this example, the split classification can be a value generated by a machine learning model based at least in part on one or more inputs. If the value meets a value threshold, then the notification service212can generate a split notification recommendation at box410.

In some examples, the split classification can be based at least in part on the user classification237. For example, users classified as dormant users or active split users can be classified having a medium likelihood or a high split likelihood in order to encourage the user to use a split transaction workflow for the client application239.

In box410, the notification service212can determine whether the split classification meets a threshold. The threshold can be numerical value, a classification type, a combination of different data type, and other suitable threshold for comparison. For example, the threshold can be a numerical value for comparing against a numerical value of the split classification. In other examples, the threshold can represent a minimum classification, such as the split classification has to be at least a medium split likelihood. If the split classification meets the threshold, then the notification service212can proceed to box413. If the split classification does not meet a threshold, then the notification service212can proceed to the end.

In box413, the notification service212can determine whether the notification rules227permit the split notification to be sent to the client device103. The notification rules227can be implemented to prevent overwhelming a user with notifications. For example, a notification rule227can be if a user does not open at least one of a set of split notifications, then the notification service212can pause or temporarily disable split notifications from being transmitted for a time period of thirty days.

Another notification rule227can include disabling split notifications after three cycles of a sending a set of split notifications and implementing a pause period of time (e.g., thirty days). In this example, disabling notifications may require an administrator user to enable notifications for subsequent notifications.

Another example of a notification rule227can be configured to deny sending a notification if the operating system238of the client device103or other mobile applications have sent a prior notification within a time period. If transmission of the notification is permitted by the one or more notification rules227, the notification service212can proceed to box416. If transmission of the notification is not permitted by the one or more notification rules227, the notification service212can proceed to back to box413.

In box416, the notification service212can transmit a split notification or other notifications to the client device103. The notification service212can identify a client device103of the user of the payment instrument for the pending transaction. The device data230can include a device identifier that can be used for routing the notification to the client device103. The notification can be a push notification, a short message service (e.g., a text message), and other suitable notification techniques for client devices103. The notification can have a deep link for directing the client application239to an advanced state in a split transaction workflow. As such, the client application239can display a user interface242or an alternative user interface (e.g., a split user interface320).

Accordingly, if the user selects the notification, the operating system238can execute the client application239to display the user interfaces242. The user interface242can represent an advanced stage of a split transaction workflow. In some examples, the user interfaces242can be displayed to collect data for preparing a split request associated with the split transaction workflow.

In other examples, the user interface242can include a split user interface element309. If the split user interface element309has been selected, one or more split user interfaces320can be displayed and used to collect one or more of the following: the selected transaction, an amount portion of the selected transaction, a selected requestee, a requestor financial account (e.g., user sending the payment request) for depositing the repayment funds, a peer-to-peer platform account for the requestee, and other suitable data. After the data has been collected from the split user interfaces320, then the operating system238and/or the client application239can transmit a split request that includes the collected data for completing split transaction workflow in the computing environment203.

In some examples, the notification service212can determine whether the split notification has been selected. If the split notification is not selected, the notification service212can proceed to the end. In some examples, the operating system238can indicate whether the split notification has been selected within a threshold time period from displaying the notification on the client device103.

In some embodiments, if the split notification is selected, the notification service212can direct the operating system238to display the user interface242. The user interface242can be displayed for identifying a selection of a client workflow via a user interface element (e.g., via a split user interface element309), such as a split transaction workflow. The split user interface320can be displayed to collect input data from the user. The collected input data can be used for transmitting a split request to the computing environment.

In box419, the notification service212can determine whether a split request has been received from the client device103. If the split request has been received then, the notification service212can proceed to box422. If the split request has not been received then, the notification service212can proceed to the end.

In box422, the notification service212can activate a split transaction workflow based at least in part on the split request received from the client device103. The split request can include a requestee, a selected transaction, a requestee, and other suitable data. The split transaction workflow can represent a process for splitting a transaction by requesting repayment for a portion of the selection transaction from selected requestees. The repayment request can be transmitted via one or more peer-to-peer payment platforms (e.g., Venmo®, Cashapp®, Zelle®, Paypal®, etc.). Then, the notification service212can proceed to the end.

Referring next toFIG.4B, shown is a flowchart that provides one example of the operation of a payment plan workflow of the notification service212. The flowchart ofFIG.4Bprovides merely an example of the many different types of functional arrangements that can be employed to implement the operation of the depicted portion of the notification service212. As an alternative, the flowchart ofFIG.4Bcan be viewed as depicting an example of elements of a method implemented within the network environment200.

Beginning with box425, the notification service212can identify authorization data245for a recent transaction. In some examples, the authorization data245can be generated by the notification service212after receiving an authorization request for a transaction from a merchant device206. After the transaction has been approved as a pending transaction, authorization data245can be generated for the transaction and the authorization data245can be transmitted to the merchant device206. In some examples, the authorization data245can include an authorization code.

In box428, the notification service212can determine one or more context parameters for the pending transaction. The context parameters can be identified from the transaction data233and/or the authorization data245, such as a transaction amount, a merchant identifier, a purchase category (e.g., lodging, grocery, retail, travel, entertainment, dining, etc.), a transaction date, a transaction location, and other suitable. In addition, the context parameters can include historical transaction data, such as previous transaction splits, previous spending patterns, and other historical transaction activity.

In some embodiments, the notification service212can determine a user classification237of the user as a context parameter. The user classification237can represent a classification of the user associated with the payment instrument used for the pending transaction. For example, the user classification237can be used to represent the spending ability of the user and/or their previous history with setting up payment plans for transactions. Some example user classifications237can include active payment plans users, business users, dormant payment plans users, inactive payment plan users, and other suitable classification. In some examples, the notification service212can determine the user classification237based at least in part on one or more factors, such as access to financial resources (e.g., employment, assets, etc.), history with setting up payment plans for transactions, and other suitable historical information. In some embodiments, the notification service212can use the user classification237to determine the transaction classification for the pending transaction and/or subsequent actions to be taken for the user associated with the pending transaction.

In box431, the notification service212can determine a payment plan classification for the pending transaction based at least in part on the one or more context parameters. The transaction classification can be a numerical value or a classification type (e.g., low payment plan likelihood, medium payment plan likelihood, high payment plan likelihood). In some implementations, the notification service212can use a machine learning model for predicting a payment plan classification for the pending transaction. In some examples, the payment plan classification can represent a likelihood of the pending transaction being paid with a payment plan or the payment plan classification can be used to encourage the user to set up more payment plan of his/her transactions.

In some examples, the payment plan classification can be represented as numerical value for the likelihood of the user to set up a payment plan for the pending transaction. In this example, the payment plan classification can be a value generated by a machine learning model based at least in part on one or more inputs. If the value meets a value threshold, then the notification service212can generate a payment plan notification recommendation at box434.

In box434, the notification service212can determine whether the payment plan classification meets a threshold. The threshold can be numerical value, a classification type, a combination of different data type, and other suitable threshold for comparison. For example, the threshold can be a numerical value for comparing against a numerical value of the payment plan classification. In other examples, the threshold can represent a minimum classification, such as the split classification has to be at least a medium likelihood. If the payment plan classification meets the threshold, then the notification service212can proceed to box437. If the payment plan classification does not meet a threshold, then the notification service212can proceed to the end.

In box437, the notification service212can determine whether the notification rules227permit a payment plan notification to be sent to the client device103. The notification rules227can be implemented to prevent overwhelming a user with notifications. For example, a notification rule227can be if a user does not open at least one of a set of notifications, then the notification service212can pause or temporarily disable notifications from being transmitted for a time period of thirty days.

Another notification rule227can include disabling notifications after three cycles of a sending a set of notifications and implementing a pause period of time (e.g., thirty days). In this example, disabling notifications may require an administrator user to enable notifications for subsequent notifications.

Another example of a notification rule227can be configured to deny sending a notification if the operating system238of the client device103or other mobile applications have sent a prior notification within a time period. If transmission of the notification is permitted by the one or more notification rules227, the notification service212can proceed to box416. If transmission of the notification is not permitted by the one or more notification rules227, the notification service212can proceed to back to box440.

In box440, the notification service212can transmit a payment plan notification to the client device103. The notification service212can identify a client device103of the user of the payment instrument for the pending transaction. The device data230can include a device identifier that can be used for routing the payment plan notification to the client device103. The payment plan notification can be a push notification, a short message service (e.g., a text message), and other suitable notification techniques for client devices103. The payment plan notification can have a deep link for directing the client application239to an advanced state in a payment plan workflow. As such, the client application239can display a user interface242or an alternative user interface242(e.g., a plan user interface330).

Accordingly, if the user selects the payment plan notification, the operating system238can execute the client application239to display the user interfaces242. The user interface242can represent an advanced stage of a payment plan workflow. In some examples, the user interfaces242can be displayed to collect data for preparing a payment plan request associated with the payment plan workflow.

In other examples, the user interface242can include a split user interface element309and/or a plan user interface element312. If the plan user interface element312has been selected, one or more plan user interfaces330can be displayed and used to collected one or more of the following: a payment amount, a payment time period for receiving each payment amount, and other suitable payment plan conditions. After the data has been collected from the plan user interfaces330, then the operating system238and/or the client application239can transmit a plan request that includes the collected data for perform a server-side payment plan workflow.

In some examples, the notification service212can determine whether the notification has been selected. If the notification is not selected, the notification service212can proceed to the end. In some examples, the operating system238can indicate whether the notification has been selected within a threshold time period from displaying the notification on the client device103.

In some embodiments, if the notification is selected, the notification service212can direct the operating system238to display the user interface242. The user interface242can be displayed for identifying a selection of a client workflow via a user interface element (e.g., via a split user interface element309), such as a payment plan workflow. The plan user interface330can be displayed to collect input data from the user. The collected input data can be used for transmitting a payment plan request.

In box443, the notification service212can determine whether a payment plan request has been received from the client device103. If the payment plan request has been received then, the notification service212can proceed to box447. If the payment plan request has not been received then, the notification service212can proceed to the end.

In box447, the notification service212can activate a payment plan workflow based at least in part on the plan request being received from the client device103. The plan request can include a payment amount, a plan time period for the payment amount, and other suitable payment plan conditions. The payment plan workflow can represent a process for creating a payment plan of a number of payments over a period of time for the selected transaction. Then, the notification service212can proceed to the end.

Referring next toFIG.5, shown is a flowchart that provides one example of the operation of a portion of the client application239. The flowchart ofFIG.5provides merely an example of the many different types of functional arrangements that can be employed to implement the operation of the depicted portion of the client application239. As an alternative, the flowchart ofFIG.5can be viewed as depicting an example of elements of a method implemented within the network environment200.

Beginning with box501, the operating system238can display a split notification received106received from the notification service212. The split notification106can be transmitted by the notification service212. In some examples, the split notification106may be played via a speaker of the client device103using a voice synthesizer. The split notification106can include one or more components such as a transaction identifier, a merchant identifier, a financial service provider identifier, and other suitable information. The split notification106can be associated with a deep link for the client application239. The deep link can activate the client application239to an advance stage of a client split transaction workflow. The deep link can represent a link for specific webpage using a Hypertext Transfer Protocol (HTTP) uniform resource locator (URL) or the deep link can represent a mobile deep link for directly linking to in-application content using non-HTTP uniform resource identifier (URI).

In box504, the operating system238can identify a selection of the split notification106. The selection of the split notification106can activate the deep link to the client application239. The selection of the split notification106can cause the operating system238to execute the client application239. In some embodiments, the selection causes the operating system238to provide the client application239data associated with the split notification106for the advance stage of the client split transaction workflow. For example, the operating system238can provide one or more elements such as, a notification identifier, a transaction identifier, a transaction amount, an application reference for displaying the split user interface303, and other suitable data. As such, the operating system238can activate the client application239and direct the client application239display the split user interface303based at least in part on the selection of the split notification106.

In box507, the operating system238can display a split user interface303on the client device103. The split user interface303can represent one or more user interfaces for receiving data for a split request of a selected transaction. The split user interfaces303can display transaction data233associated with the selected transaction. The transaction data233can include a transaction amount, a merchant identifier, a transaction date, a transaction status (e.g., pending or posted transaction), a transaction location, and other suitable information.

The user interface242can include a user interface elements for display, such as a split user interface element309, a plan user interface element312, and other suitable user interface elements. The user interface242can include a map315that indicates the transaction location.

In box510, the operating system238can receive data from the split user interface303. The data received from the split user interface303can include one or more data elements, such as selected requestees, a portion amount of the transaction, a selected peer-to-peer payment platform account for the selected requestee, a selected payment instrument for depositing the repayment funds, and other suitable data.

In box513, the operating system238can transmit a split request to the notification service212in the computing environment203. The split request can include data received from the split user interfaces303. Then, the client application239can proceed to the end.

A number of software components previously discussed are stored in the memory of the respective computing devices and are executable by the processor of the respective computing devices. In this respect, the term “executable” means a program file that is in a form that can ultimately be run by the processor. Examples of executable programs can be a compiled program that can be translated into machine code in a format that can be loaded into a random access portion of the memory and run by the processor, source code that can be expressed in proper format such as object code that is capable of being loaded into a random access portion of the memory and executed by the processor, or source code that can be interpreted by another executable program to generate instructions in a random access portion of the memory to be executed by the processor. An executable program can be stored in any portion or component of the memory, including random access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, Universal Serial Bus (USB) flash drive, memory card, optical disc such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape, or other memory components.

The flowcharts ofFIGS.4and5show the functionality and operation of an implementation of portions of the various embodiments of the present disclosure. If embodied in software, each block can represent a module, segment, or portion of code that includes program instructions to implement the specified logical function(s). The program instructions can be embodied in the form of source code that includes human-readable statements written in a programming language or machine code that includes numerical instructions recognizable by a suitable execution system such as a processor in a computer system. The machine code can be converted from the source code through various processes. For example, the machine code can be generated from the source code with a compiler prior to execution of the corresponding application. As another example, the machine code can be generated from the source code concurrently with execution with an interpreter. Other approaches can also be used. If embodied in hardware, each block can represent a circuit or a number of interconnected circuits to implement the specified logical function or functions.

Further, any logic or application described herein can be implemented and structured in a variety of ways. For example, one or more applications described can be implemented as modules or components of a single application. Further, one or more applications described herein can be executed in shared or separate computing devices or a combination thereof. For example, a plurality of the applications described herein can execute in the same computing device, or in multiple computing devices in the same computing environment203.

Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., can be either X, Y, or Z, or any combination thereof (e.g., X; Y; Z; X or Y; X or Z; Y or Z; X, Y, or Z; etc.). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present.