Providing application notifications for computing application restrictions

Abstract

Systems and methods are provided for providing application notifications for computing application restrictions. A user may perform a transaction with another user, such as purchasing an item, service, or other item from a merchant using a payment account and / or a payment card via a software application. An online transaction processor may provide monitoring operations to enforce electronic transaction processing restrictions by applying usage and / or payment restrictions of one or more accounts. The limit may correspond to a processing limit or throttling mechanism, which may limit the use of the consumption limit in the application below an allowed maximum use amount. When utilizing the restriction, the online transaction processor may determine that the throttling mechanism is approved or violated, and may allow a user to configure such restriction through slidable and / or adjustable application icons and interfaces.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. patent application No. 18 / 148,956, filed on December 30, 2022, and claims priority to U.S. patent application No. 18 / 148,979, filed on December 30, 2022, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present application relates generally to data processing and, more particularly, to providing one or more selectable interface throttling mechanisms (throttles) or options for providing application limits in computing applications. Background Art

[0004] Users can utilize online transaction processors to process payments between different entities through device applications and digital accounts. In addition, these online transaction processors can also provide payment options, loans and / or extensions for face-to-face transaction processing and use at merchants. When payment options and spending limits are provided through one or more software applications, users can receive credit limits and / or use credit balances, real funds, or virtual funds linked to digital accounts. Although users may wish to obtain additional credit (for example, to enable greater purchasing power or improve the user's credit rating), users may not want to make all limits available based on personal decisions. In addition, because the account is used by the user rather than by a computing device such as a mobile phone, the user may not be able to view the available balance or bill balance, credit limit or used credit limit, and / or other available funds within the cycle. Therefore, the online transaction processor may wish to enforce preemptive and / or adjustable limits on the account. Therefore, with the increasing threat of cyberattacks, phishing schemes, and malware that could compromise user accounts or digital accounts, users and online transaction processors may wish to implement preemptive, adjustable, and / or real-time limits on account usage to reduce the risk to account funds. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 is a block diagram of a network system suitable for implementing the processes described herein, according to an embodiment;

[0006] Figures 2A-2C is an example diagram for establishing and adjusting spending and / or electronic transaction processing limits for a digital account using an online transaction processor, according to an embodiment;

[0007] Figure 3is an exemplary system environment for interaction between system components for generating and dynamically adjusting application limits to enforce account usage limits according to an embodiment;

[0008] Figure 4A is a flow chart of an exemplary process for generating application restrictions to enforce account usage restrictions, according to an embodiment;

[0009] Figure 4B is a flow chart of an exemplary process for dynamically adjusting application limits to enforce account usage limits, according to an embodiment; and

[0010] Figure 5 is suitable for implementing according to an embodiment Figure 1 A block diagram of a computer system that contains one or more components.

[0011] The embodiments of the present disclosure and their advantages may be best understood by reference to the following detailed description. It should be understood that like reference numerals are used to identify like elements shown in one or more figures, which are shown to illustrate, but not to limit, the embodiments of the present disclosure. DETAILED DESCRIPTION

[0012] A method for processing a throttling mechanism to enforce account usage limits is provided. Also provided is a system suitable for practicing the disclosed method.

[0013] The user may utilize a digital account, payment card, and / or other funding source to process payments through an electronic card or transaction network associated with a back-end payment processor or other entity on the network. The identifier may be linked to the user's online transaction processor (e.g., a payment service provider (e.g., )) digital account, the online transaction processor can provide electronic transaction processing services to the user through the online transaction processor or merchant's account and one or more websites and / or applications. The digital account can be established with a credit line and / or can have a balance or value available for the digital account. The online transaction processor can include an integration mechanism with the electronic card network to allow data exchange and communication between the two networks. The user and / or the online transaction processor can establish one or more spending or transaction processing limits on the digital account and / or available spending limits and balance, such as for the use of credit lines and / or balances, and the spending or transaction processing limits can include different configurable levels or parameters. For example, transaction processing limits and / or spending limits can limit the available credit line of the digital account to less than the maximum credit line, for example, limiting the available credit line to US$3,000 even if the maximum credit line is US$10,000. Thereafter, the online transaction processor can monitor the digital account and / or the use of the digital account on the electronic card network to enforce spending limits and restrict card use. This data processing can occur at specific time intervals, or after a certain time period or cycle, such as weekly, monthly, etc. (for example, after a billing cycle). Furthermore, the user can use the software application to adjust these limits, for example by accepting a maximum scalable limit and / or throttling or moving the limit to a lower level. Thereafter, when the user processes a transaction using the digital account, if a certain level, threshold, or scalable balance is exceeded, the online transaction processor can block data processing. Furthermore, if such a configurable balance is exceeded, the online transaction processor can alert the user and provide options such as deleting the lower level balance, adjusting the balance, and / or approving the transaction based on the available and / or scalable credit balance.

[0014] In this regard, the user may process the purchase of goods through a software application and / or digital account that provides value, credit, or other funds to the user through an online transaction processor and / or electronic card network. In-person transactions at brick-and-mortar merchants or selection of one or more goods through an online marketplace or other digital platform may require the user to use a payment instrument for electronic transaction processing. The user may utilize an online service provider or other transaction processor (e.g., ) using a digital wallet or other account and a digital account (e.g., by presenting a card and having the card data read or by entering card details and / or account number) to pay for one or more transactions. An account with a service provider and / or a corresponding digital account may be established by providing account details such as a login name, a password (or other authentication credentials, such as a biometric fingerprint, a retinal scan, etc.) and other account creation details. The account creation details may include identifying information used to establish an account, such as a user's personal information, an entity's business or merchant information, or other types of identifying information including name, address, and / or other information.

[0015] When processing transactions with merchants and / or other users or entities, users may also be asked to provide financial information, including digital account (e.g., credit / debit card) information, bank account information, gift card information, benefits / rewards, and / or financial investments. Account creation may also be used to establish account funds and / or value, such as by transferring funds to an account and / or establishing a credit line and corresponding credit value available on an account and / or card. Online payment providers may offer digital wallet services that may: provide financial services for sending, storing, and receiving funds, process financial instruments, and / or provide transaction history, including tokenization of digital wallet data for transaction processing. Service providers (e.g., or other online payment providers) can provide payment and other transaction processing services. The digital account linked to the user can also correspond to a peer-to-peer payment account and / or a social networking account, such as an account that can be used on a peer-to-peer payment and social networking platform provided by an online transaction processor. In addition, the digital account can be used through one or more mobile applications or other software applications for a mobile device.

[0016] In order to complete a transaction payment (e.g., to transfer or pay to another user, merchant, or other entity), a user can provide digital account or source of funds information, or can log in to an account for a service provider through authentication information in a software application. Payment can then be issued to the other party of the transaction, and the transaction information can be stored in a digital wallet or account. In this regard, a digital token or other data can authorize and / or authenticate the user to use their digital wallet and / or the payment instrument in the digital wallet, which can be transmitted to the other party (e.g., an agent and / or merchant) for payment processing. The data can be stored in one or more storage media for the digital account, such as a magnetic stripe or EMV chip. For example, a POS device and / or a card reader can be used to read card data from a merchant device at a merchant location. This can allow the user to pay through a payment account and / or digital wallet. In some embodiments, the account and / or digital wallet can be linked to the user's device or application, and the checkout process can be authorized by the user, wherein selecting the account or other data can automatically start the process of purchasing goods using the account and / or digital wallet.

[0017] After a digital account is opened (e.g., after opening, setting up, and / or linking a credit and / or debit card to the user's digital account), the user may receive an available balance that the user can use. This may correspond to real or virtual assets or value, or it may be a revolving credit line provided to the user. The user may wish to enforce limits on electronic transactions and spending on the available balance (e.g., revolving credit line). For example, a user may be offered a higher maximum credit line (e.g., $5,000, $10,000, $30,000), but if the user's spending reaches this limit, the higher maximum credit line provided will negatively impact the user's budget. In this regard, regardless of whether the revolving credit billing cycle or time period is temporary or recurring, the user's budget may only be able to afford $2,000 in credit repayments or balance payments (e.g., to pay off the extended credit balance) during the revolving credit billing cycle or time period. Therefore, the user may establish a lower limit to prevent the use of the digital account and / or the digital account for electronic transactions.

[0018] In this regard, users can utilize mobile and / or resident software applications on computing devices and / or websites to receive and / or view one or more spending limits and / or transaction processing limits for digital accounts and / or digital account credit lines. These interfaces can allow users to view maximum spending limits, which can be extended according to one or more rules, regulations, and / or budgets related to the user. For example, government and / or regulatory laws or rules can set available limits for users. In addition, the user's budget, income, past repayment data, credit rating, or other user data can set these limits. These limits can also be determined using rule-based and / or machine learning (ML)-based artificial intelligence (AI) engines, which can pre-calculate and recalculate these limits based on real-time and / or available user data. Such AI engines can also use merchant data, merchant agreements, and other data to calculate such limits. After calculating the limits, the limits can be transmitted to the user's user device so that these data can be obtained and viewed through one or more user interfaces.

[0019] Thereafter, the user can set the spending limit to be at or below the maximum credit limit provided to the user. For example, when the maximum credit limit is $10,000, the user can set the spending limit to any level between $1 and $10,000. The user can set the spending limit to a level that corresponds to the user's budget for a specific time period or recurring time periods, and / or a budget can be recommended to the user. The spending limit can correspond to an electronic transaction processing limit that prevents the use of extended credit or other balances of a digital account when electronic transaction processing is performed through an application and / or using another payment instrument. Thus, if the spending limit or other set threshold for credit usage of extended credit is reached or exceeded, the online transaction processor can prevent processing (e.g., by rejecting the transaction and / or instructing the back-end credit processor system and electronic card network to reject the transaction and prevent transaction processing and use of credit).

[0020] Users can set different spending limits, for example, through a budget setting tool, and / or by limiting the use of extended credit balances or other values of digital accounts and / or digital accounts for electronic transaction processing. The budget setting tool can be attached to the total risk exposure limit (risk exposure limit) that the online transaction processor can provide to the user, such as a maximum credit limit. The spending limits available through the budget setting tool can also be configured and / or calculated using the engine of such a service provider, and can be static (such as a monthly spending limit) or dynamic (such as based on the budget available to the user over a period of time). However, the budget setting tool associated with the total risk exposure limit is independent of the monthly authorization limit (power) or monthly available funds determined by the risk team and risk analysis operations of the online transaction processor. The monthly authorization limit can be based on the user's risk profile (profile), payment availability check constraints, etc., wherein the constraints may be based on local or regional laws, regulations and / or compliance requirements.

[0021] For example, a spending limit can be a static amount, such as a $2,000 limit, preventing the user from exceeding the limit. The limit can be user-configurable in a user interface between a minimum and maximum amount available to the user. This limit may not reset after a period of time, or may reset based on the user's income, budget, or other preferences and data. A spending limit can also be a dynamic or variable limit, such as $2,000 per month, which can reset after a time limit and / or based on spending. Furthermore, other data can be used to set different types of spending limits, such as based on merchant agreements, merchant category codes (MCCs) and transaction categories, time of day, purchase type, etc. When a spending limit restricts specific types of transaction processing and / or is dynamic or variable, the spending limit may be for a certain time period (e.g., a payment and / or billing cycle) and may reset after that time period. Furthermore, a spending limit can be specific to a digital account among multiple accounts and / or a limit provided to the user. Furthermore, spending limits can be tiered, and additional credit or other funds and value can be released gradually (e.g., when each spending limit is reached, on different days or months, etc.). Thus, a user may configure and / or adjust spending limits utilizing one or more user interfaces, such as via slideable or scrollable bars, icons, and the like.

[0022] Thereafter, the transaction can be processed using (one or more) digital accounts, which can generate and process transaction data for the transaction on the digital network. The transaction data may also include information such as one or more items, item cost (e.g., itemized) and / or total cost, transaction time, corresponding merchant or merchant identifier, other users participating in the transaction, transaction location, an MCC identifying a specific category for each transaction, and / or other transaction data. An online transaction processor can provide electronic transaction processing services for processing transactions using transaction data and / or card data. However, in other embodiments, to receive this data, the online transaction processor may need to interface with a backend card processor and / or electronic card or transaction network that transmits, receives, and / or processes transaction data based on relevant payment instrument data (e.g., payment card, bank account, etc.). In this regard, the online transaction processor can utilize an application programming interface (API) to communicate and integrate with one or more APIs of the electronic card network. This enables the online transaction processor to detect, receive, and process transaction data, for example, by setting and / or enforcing spending limits on transactions processed on the electronic payment network. Thereafter, the transaction data may be detected and / or transmitted to an online transaction processor via one or more APIs. This may include receiving and processing the data in real time (e.g., as the transaction occurs) to enforce spending limits and other electronic transaction processing restrictions on the digital account when used for electronic transaction processing on one or more networks.

[0023] When the online transaction processor receives transaction data for a transaction when the transaction is requested for processing, the transaction data can be analyzed to determine whether the transaction complies with or violates the limit(s) established when the account was applied for. This can be accomplished by listening for card read and / or scan events and receiving corresponding transaction information, or by monitoring incoming communications from electronic card networks, merchants, point-of-sale (POS) devices, etc., or by identifying electronic transaction payments requested through digital accounts. In addition, the online transaction processor can provide card products that utilize physical payment cards (e.g., cards with magnetic stripes, EMV chips, NFC or RFID transceivers, etc.) to convey information. This can allow users to unlock future monthly authorization limits when checking out at merchant locations (e.g., cash registers or POS devices in real-world stores and locations). Thus, users can use the physical card to select and / or change the due date for the next month on the POS device.

[0024] If the transaction complies with the restrictions, the online transaction processor may approve the transaction or allow the transaction to be approved on the electronic card network (e.g., by not declining the transaction or not requesting the electronic card network and / or back-end credit card processing system to decline the transaction). However, if the transaction violates the restrictions or is otherwise inconsistent with the restrictions (e.g., if the transaction amount causes the digital account balance and / or digital account to exceed the limit balance limit), the online transaction processor may decline the transaction by refusing to process the transaction and / or requesting the electronic card network and / or back-end credit card processing system to decline or overturn the transaction.

[0025] If a transaction exceeds or violates a limit, the online transaction processor may refuse to process the transaction and / or may send a message with a notification or alert to the user's device. The device may include an application with one or more interface options, elements, or graphics, including executable options, actions, and / or selectable elements for removing or adjusting spending limits, thereby allowing the transaction to be processed. This may include a sliding adjustment that allows spending limits to be configured between different available transactions and / or credit limits. Such limits may be scalable according to various merchant agreements and / or regulatory guidelines and may also be set at one or more levels by the service provider's AI engine. Notifications or alerts may be transmitted via text message (e.g., SMS or MMS) or via other messaging systems and protocols (e.g., instant messaging, mobile application push notifications, email, website chat interfaces, etc.). The user may also be provided with the option to access the user's digital account and change spending limits, for example, by authenticating the user through the application or website and viewing one or more spending limits using selectable interface options and / or interface fields to enter data to adjust the spending limits. Thereafter, the online transaction processor may update the spending limit and continue to monitor the digital account and / or digital account usage for compliance with the updated spending limit.

[0026] Figure 1 is a block diagram of a network system 100 suitable for implementing the processes described herein, according to an embodiment. As shown, the system 100 may include or implement multiple devices, servers, and / or software components that operate to perform the various methods according to the described embodiments. Exemplary devices and servers may include appliances, stand-alone machines, and enterprise-level servers that operate such as operating system, operating system, operating system, or other suitable device and / or server-based operating system. Figure 1The devices and / or servers shown in the figures may be deployed in other ways, and the operations performed and / or services provided by such devices and / or servers may be combined or separated for a given embodiment and may be performed by more or fewer devices and / or servers. One or more devices and / or servers may be operated and / or maintained by the same or different entities.

[0027] System 100 includes a client device 110, a merchant device 120, and an online transaction processor 130 that communicate via a network 150. Client device 110 can be used to establish a transaction and process payment for the transaction using an account managed by client device 110. In this regard, when processing a transaction, transaction data can be provided via a transaction network, which can be obtained via network 150. Client device 110 and merchant device 120 can be used to set spending limits or other electronic transaction processing limits regarding balance usage, such as the maximum amount of an extended credit line. Online transaction processor 130 can then be used to inspect the transaction data and determine whether the transaction data complies with the spending limits.

[0028] The client device 110, the merchant device 120, and the online transaction processor 130 may each include one or more processors, memories, and other appropriate components for executing instructions (e.g., program code and / or data) stored on one or more computer-readable media to implement the various applications, data, and steps described herein. For example, such instructions may be stored on one or more computer-readable media (e.g., memories or data storage devices internal to and / or external to various components of the system 100) and / or may be accessible via the network 150.

[0029] The client device 110 can be implemented using any appropriate hardware and software that is configured to communicate wired and / or wirelessly with the merchant device 120 and / or the online transaction processor 130 to process transactions based on one or more spending limits. The client device 110 can correspond to a user who processes payments and sales through an executable software application. In various embodiments, the client device 110 can be implemented as a personal computer (PC), a smartphone, a laptop / tablet, a watch with appropriate computer hardware resources, other types of wearable computing devices, and / or other types of computing devices capable of sending and / or receiving data. Although only one computing device is shown, multiple computing devices can function similarly.

[0030] Figure 1The client device 110 includes a purchase application 112, a database 116, and a network interface component 118. The purchase application 112 may correspond to an executable process, program, and / or application with associated hardware. In other embodiments, the client device 110 may include additional or different modules with dedicated hardware and / or software as needed.

[0031] Purchasing application 112 may correspond to one or more processes that execute software modules and related components of client device 110 to provide functionality, services, and other operations to a user via network 150, which may include accessing and utilizing computing services provided by online transaction processor 130. In this regard, purchasing application 112 may correspond to specialized software used by a user of client device 110 to access a website or application (e.g., a mobile application, a rich internet application, or a resident software application) that may display one or more user interfaces that allow interaction with the computing services of online transaction processor 130. In various embodiments, purchasing application 112 may correspond to a general-purpose browser application configured to retrieve, present, and transmit information via the Internet (e.g., utilizing resources on the World Wide Web) or a private network. For example, purchasing application 112 may provide a web browser that can send and receive information via network 150, including retrieving website information, presenting website information to a user, and / or transmitting information to a website. However, in other embodiments, purchasing application 112 may comprise a specialized application of online transaction processor 130 or another entity.

[0032] The purchasing application 112 may be associated with account information, user financial information, and / or transaction history. However, in other embodiments, different services may be provided through the purchasing application 112, including social networking, media publishing or sharing, microblogging, data browsing and searching, online shopping, and other services available through the online transaction processor 130. Thus, the purchasing application 112 may also correspond to different service applications, etc. When using the purchasing application 112 with the online transaction processor 130, the purchasing application 112 may request the processing of an interaction 114 (e.g., a payment request and / or a spending limit request or adjustment with the online transaction processor 130). The interaction 114 may correspond to requesting, establishing, and / or adjusting a spending limit using the purchasing application 112 via one or more application icons, interfaces, and / or interactions with such displayable data. The interaction 114 may also include a payment request to one or more merchants, which may be specific to a specific merchant's spending limit or may be specific to spending limits available to multiple merchants. The interaction 114 may be used in conjunction with the user's user account, and the interaction 114 may include corresponding user input regarding spending limits.

[0033] In various embodiments, the client device 110 includes other applications that may be required in a particular embodiment to provide functionality to the client device 110. For example, the other applications may include security applications for implementing client-side security functions, programming client applications for interfacing with appropriate application programming interfaces (APIs) via the network 150, or other types of applications. The other applications may also include email, text messaging, voice, and IM applications that allow users to send and receive emails, phone calls, text messages, and other notifications via the network 150. In various embodiments, the other applications may include financial applications, such as banking applications. Other applications may include social networking applications, media viewing, and / or merchant applications.

[0034] Other applications may also include other location detection applications that can be used to determine the user's location, such as maps, compasses, and / or GPS applications, which may include a dedicated GPS receiver for determining the location information of the client device 110. Other applications may include device interface applications and other display modules that can receive input from the user and / or output information to the user. For example, other applications may include software programs executable by the processor, including a graphical user interface (GUI) configured to provide an interface to the user. Therefore, other applications may use devices of the client device 110, such as a display device capable of displaying information to the user and other output devices including speakers.

[0035] The client device 110 may also include a database 116 stored on transient and / or non-transitory memory of the client device 110, which may store various applications and data and may be used during execution of various modules of the client device 110. The database 116 may include, for example, identifiers such as operating system registry entries, cookies associated with the purchasing application 112 and / or other applications, identifiers associated with the hardware of the client device 110, or other suitable identifiers (e.g., identifiers used for payment / user / device authentication or identification), which may be transmitted to the online transaction processor 130 when identifying the user / client device 110. In addition, the database 116 may include data for the interaction 114, such as data that may be provided as a data payload processed by the online transaction processor 130.

[0036] The client device 110 includes at least one network interface component 118 that is adapted to communicate with the online transaction processor 130 and / or other devices and servers via a network 150. In various embodiments, the network interface component 118 may include a DSL (e.g., digital subscriber line) modem, a PSTN (public switched telephone network) modem, an Ethernet device, a broadband device, a satellite device, and / or various other types of wired and / or wireless network communication devices (including microwave communication devices, radio frequency communication devices, infrared communication devices, Bluetooth communication devices, and near field communication devices).

[0037] Merchant device 120 may be maintained by, for example, a merchant or other entity that offers goods for sale to users. Merchant device 120 may correspond to one or more physical and / or online merchant marketplaces, sales platforms, point-of-sale (POS) devices, websites, and / or online resources that users can access to purchase goods. For example, merchant device 120 may correspond to one or more POS devices located at a physical merchant location for processing transactions, as well as a digital platform accessible by a website and / or application, on which users can offer or be offered products, services, and other goods for sale, and users can browse goods, select goods to purchase, and participate in electronic transaction processing. Merchant device 120 may also include other platforms, websites, and resources that allow users to participate in electronic transaction processing, such as platforms, websites, and resources related to payment processors, money transfers, utility or living bill payments, and other payments or purchases, which users may use to pay balances due on certain products, services, or other items. In some embodiments, merchant device 120 may be implemented as a standalone or networked personal computer (PC), server, smartphone, laptop, wearable computing device, and / or other type of computing device. Although only one merchant device is shown, multiple merchant devices may function similarly.

[0038] Figure 1 The merchant device 120 includes a sales application 122, a database 124, and a network interface component 128. The sales application 122 can correspond to an executable process, program, and / or application with related hardware. In other embodiments, the merchant device 120 can include additional software or different software as needed.

[0039] Sales application 122 can provide and / or process items for sale to client device 110 and / or a user associated with client device 110 (e.g., a payment source including a payment card, digital account, cash, etc.). In some embodiments, sales application 122 is accessible via the Internet and provides sales to client device 110 via network 150. Sales application 122 can also correspond to a checkout application at a physical merchant location, such as the application(s) of a point-of-sale (POS) device used to provide sales at a physical location. After a user / employee associated with merchant device 120 enters one or more items to be purchased and / or enters the item(s) into the transaction for processing, sales application 122 can be used to establish a transaction. After determining the payment amount for the item(s) to be purchased by the user, merchant device 120 can request payment for the transaction. Payment can be made using a digital account, however, merchant device 120 and / or the merchant corresponding to merchant device 120 may have corresponding agreements with the user of client device 110, the service provider of online transaction processor 130, and / or a regulatory service or agency. In this regard, payment may be received from the digital account according to spending limits established by the AI engine of the online transaction processor 130 and / or set via the client device 110. Upon receiving payment from the digital account and / or confirming a digital account transfer, the merchant device 120 may process payment to a merchant associated with the merchant device 120 using a digital payment method.

[0040] Merchant device 120 may also include a database 124, which may include, for example, identifiers associated with sales application 122 and / or other applications, identifiers associated with hardware of merchant device 120, or other suitable identifiers. Database 124 may receive and store data from client device 110, for example, in response to receiving transaction data and / or payment data. Thus, database 124 may also store, use, and / or access digital accounts and / or digital account exchanges, such as those that may include information associated with merchant data 126, which may be used in determining and dynamically adjusting spending limits in a user interface of client device 110.

[0041] The merchant device 120 includes at least one network interface component 128 that is adapted to communicate with the client device 110, the online transaction processor 130, and / or other devices or servers via a network 150. In various embodiments, the network interface component 128 may include a DSL (e.g., digital subscriber line) modem, a PSTN (public switched telephone network) modem, an Ethernet device, a broadband device, a satellite device, and / or various other types of wired and / or wireless network communication devices (including microwave communication devices, radio frequency communication devices, infrared communication devices, Bluetooth communication devices, and near field communication devices).

[0042] The online transaction processor 130 may be maintained by, for example, an online service provider that may provide processes for providing account services and processing payments, as well as establishing spending limits on balances or credit usage of digital accounts associated with spending limits. In this regard, the online transaction processor 130 includes one or more processing applications that may be configured to interact with the client device 110, the merchant device 120, and / or another device / server to facilitate communications and transactions between users. The online transaction processor 130 may be maintained by or include another type of platform or service provider, such as, for example, a platform or service provider such as, for example, a provider of digital accounts in San Jose, California, USA. Although merchant device 120 and online transaction processor 130 are discussed as separate devices and servers, in some embodiments, one or more of the processes described may be provided by other devices or servers, or by the same device or server.

[0043] Figure 1 The online transaction processor 130 includes a transaction processing platform 140, a service application 132, a database 134, and a network interface component 138. The transaction processing platform 140 and the service application 132 may correspond to executable processes, programs, and / or applications with associated hardware. In other embodiments, the online transaction processor 130 may include additional or different modules with specialized hardware and / or software as needed.

[0044] The transaction processing platform 140 may correspond to one or more processes for executing the modules and associated specialized hardware of the online transaction processor 130 to process transactions with the client device 110 and the merchant device 120 for one or more items, which may be based on one or more transaction and spending limits established with the user of the client device 110. In this regard, the transaction processing platform 140 may correspond to specialized hardware and / or software used by a user associated with the client device 110 to establish an account with the transaction processing platform 140 by providing personal and / or financial information to the online transaction processor 130 and selecting authentication credentials. In various embodiments, the financial information may include payment instrument information, such as account / card numbers and information. The account may be used to purchase items and / or transfer funds. The payment account may be accessed and / or used via a browser application and / or a dedicated payment application. However, in other embodiments, the payment account may be generated by another online transaction processor or service provider and linked to the online transaction processor 130 (e.g., via the merchant device 120). The transaction processing platform 140 may be used to set a balance, credit limit, or other spending limits on the use of funds in the digital payment account. The transaction processing platform 140 may process payments and may provide a transaction history for transaction authorizations, approvals, or denials.

[0045] The transaction processing platform 140 may correspond to a product of the online transaction processor 130 and may be used by end users, for example, to perform electronic payments, transfers, and the like using one or more accounts and / or financial instruments. The transaction processing platform 140 may also include or utilize different processors, engines, or models, as needed, for authentication, account setup and maintenance, electronic transaction processing, deposits and / or withdrawals, dispute resolution, and the like. The transaction processing platform 140 may include integration and / or interaction with one or more APIs of electronic card networks or other payment networks to detect, receive, and monitor transaction data for compliance with spending limits and / or the adjustable and dynamic setting of spending limits on one or more balances of a user's digital account. Thus, the transaction processing platform 140 may interact with the network by making one or more API calls to an API of the transaction processing platform 140, which interfaces with the API of the electronic card network. The transaction processing platform 140 may determine transaction data for transactions processed on the network.

[0046] The transaction processing platform 140 may receive transaction data for transactions processed using accounts accessible through the client device 110 and / or the merchant device 120. The transaction processing platform 140 may then determine spending limits imposed on the use of the user's digital account balance, credit line, and / or other available funds. In this regard, the transaction processing platform's AI engine, executed by the spending limit identification process 142, may utilize the user data 146 and the merchant data 126 in conjunction with the limit identification process 144 to calculate spending limits based on the user's budget and / or merchant agreement, and allow the user to configure such limits through an application interface such as the purchasing application 112. For example, based on the credit line determined by the spending limit identification process 142, a spending limit may be established to be equal to and / or below a maximum balance or a maximum extended credit line. Thus, the spending limit may adjust or reduce the available credit line or other balance below the maximum amount (e.g., a spending limit may be $1,000 of a $5,000 limit). Thereafter, the transaction may be detected using API calls with electronic card networks, devices (eg, client device 110 and / or merchant device 120 ), and / or other devices.

[0047] The transaction processing platform 140 can determine whether the transaction complies with (one or more) spending limits. If so, the transaction may be approved or authorized. However, if the transaction does not comply with the spending limits or exceeds the electronic transaction processing limits and / or credit / balance limits, the transaction processing platform 140 can be used to refuse transaction processing or instruct the back-end credit processor and / or merchant device 120 to refuse to process the transaction. In addition, the transaction processing platform 140 can send a message to the client device 110 and / or another device to notify the user that the spending limit has been violated and provide an operation to delete or adjust the spending limit (for example, through an application icon and / or operation). If the user requests deletion or adjustment (and is authenticated in various embodiments), the transaction processing platform 140 can delete or adjust the spending limit. An example of such a configuration is as follows Figures 2A-2C shown.

[0048] In some embodiments, the consumption limit identification process 142 may employ one or more AI engines and / or models (e.g., rule-based, ML, or neural network (NN) models and / or engines) that can be used for intelligent decision-making on consumption limits. These AI engines and / or models may include rule-based engines that can process user data 146 and / or merchant data 126, which can be used to determine consumption limits. In addition, the consumption limit identification process 142 may utilize a machine learning engine or other AI model or engine to determine consumption limits. User data 146 and / or merchant data 126 may be utilized to train and / or use a machine learning engine and / or other rule calculation or AI engine to determine consumption limits. In some embodiments, a machine learning engine may include an AI model, such as an ML or neural network (NN) model. An AI model may generally correspond to any artificial intelligence that performs decisions, such as a rule-based engine, etc. However, AI models may also include subcategories, including ML models and NN models, which use algorithmic relationships to provide intelligent decisions. Generally speaking, NNs may include deep learning models, etc., and may correspond to a subset of ML models that attempt to mimic human thinking by utilizing various algorithms to model data using different neuron graphs, where neurons include nodes that represent data based on the algorithm and can be interconnected with different nodes. ML models may similarly utilize one or more of these mathematical models and generate layers and connection nodes between layers in a manner similar to the neurons of NN models.

[0049] When building an ML model for a machine learning engine, the training data can be used to generate one or more classifiers and provide recommendations, predictions, or other outputs based on these classifications and the ML model. The training data can be used to determine input features for training prediction scores and / or outputs for spending limits based on user data 146 and / or merchant data 126, and to adjust such outputs based on user input to the limit adjustment process 144. For example, the ML model of the machine learning engine can include one or more layers, including an input layer having one or more nodes, a hidden layer, and an output layer, but other layers can also be used. For example, as many hidden layers as needed or appropriate can be used. Each node within a layer is connected to nodes in an adjacent layer, where a set of input values can be used to generate one or more output scores or classifications. In the input layer, each node can correspond to a different attribute or input data type used to train the ML model of the machine learning engine.

[0050] Thereafter, the hidden layer may be trained using ML algorithms, calculations, and / or techniques utilizing these attributes and corresponding weights. For example, each node in the hidden layer generates a representation that may include a mathematical ML calculation (or algorithm) that generates a value based on the input value of the input node. The ML algorithm may assign different weights to each data value received from the input node. The hidden layer nodes may include different algorithms and / or different weights assigned to the input data, and thus may generate other values based on the input values. The values generated by the hidden layer nodes may be used by the output layer nodes to generate one or more output values for the ML models of the machine learning engines that attempt to classify and / or provide outputs for predicted consumption limits. Thus, when predictive analysis and output are performed using the ML models of the machine learning engine, the inputs may provide corresponding outputs based on the classifications trained for the ML models of the machine learning engine.

[0051] The ML model of the machine learning engine can be trained using training data. By providing training data to train the ML model of the machine learning engine, the nodes in the hidden layer can be trained (adjusted) so that the optimal output (e.g., classification) is produced at the output layer based on the training data. By continuously providing different training data sets and penalizing the ML model of the machine learning engine when the output of the ML model of the machine learning engine is incorrect, the ML model of the machine learning engine (specifically, the representation of the nodes in the hidden layer) can be trained (adjusted) to improve its performance in data classification. Adjusting the ML model of the machine learning engine can include adjusting the weights associated with each node in the hidden layer. Therefore, the training data can be used as an input / output data set that allows the ML model of the machine learning engine to classify based on input attributes. The output classification of the ML model trained by the machine learning engine can be the classification used by the consumption limit identification process 142 and / or the limit adjustment process 144 to determine, establish, and / or adjust consumption limits. This can include adjusting the features of such a model, as well as the desired output and decision of the ML model, based on the desired and / or identified data points. In this regard, MMC, credit limit, user balance, etc. can be used as input to the ML model and trained as features for subsequent users.

[0052] The service application 132 may correspond to one or more processes that execute the modules and associated specialized hardware of the online transaction processor 130 to process transactions or provide another service to customers, merchants, and / or other end users and entities of the online transaction processor 130. In this regard, the service application 132 may correspond to specialized hardware and / or software used by the online transaction processor 130 to provide computing services to users, which may include electronic transaction processing and / or other computing services using accounts provided by the online transaction processor 130. In some embodiments, the service application 132 may be used by a user (e.g., a user associated with a client device 110) to establish user and / or payment accounts and digital wallets that can be used to process transactions. In various embodiments, financial information may be stored with the account, such as account / card numbers and information that can enable payments, transfers, withdrawals, and / or deposits. A digital token for the account / wallet may be used to send and process payments (e.g., via one or more interfaces provided by the online transaction processor 130). The digital account may be accessed and / or used through one or more instances of a web browser application and / or specialized software application executed by the client device 110, and the digital account may participate in the computing services provided by the service application 132. The computing services of the service applications 132 may also or instead correspond to messaging, social networking, media publishing or sharing, microblogging, data browsing and searching, online shopping, and other services available through the online transaction processor 130 .

[0053] In various embodiments, service applications 132 may be required in certain embodiments to provide functionality to the online transaction processor 130. For example, the service applications 132 may include security applications for implementing server-side security functionality, programmed client applications for interfacing with appropriate application programming interfaces (APIs) via the network 150, or other types of applications. The service applications 132 may include software programs executable by the processor (including a graphical user interface (GUI)) configured to provide an interface to a user when accessing the online transaction processor 130 via one or more client devices 110, wherein the user or other users may interact with the GUI to more easily view and transmit information. In various embodiments, the service applications 132 may include additional connectivity and / or communication applications that may be used to transmit information via the network 150.

[0054] Additionally, the online transaction processor 130 includes a database 134. The database 134 can store various identifiers associated with the client device 110. The database 134 can also store account data, including payment instruments and authentication credentials, as well as transaction processing history and data on processed transactions. The database 134 can store received data associated with the user, such as transaction data and spending limits for electronic transaction processing. Furthermore, the database 134 can be used to store account 136 data, which can be used to calculate spending limits.

[0055] In various embodiments, the online transaction processor 130 includes at least one network interface component 138 that is adapted to communicate with the client device 110, the merchant device 120, and / or another device / server of the merchant over a network 150. In various embodiments, the network interface component 138 may include a DSL (e.g., digital subscriber line) modem, a PSTN (public switched telephone network) modem, an Ethernet device, a broadband device, a satellite device, and / or various other types of wired and / or wireless network communication devices (including microwave communication devices, radio frequency (RF) communication devices, and infrared (IR) communication devices).

[0056] Network 150 can be implemented as a single network or a combination of multiple networks. For example, in various embodiments, network 150 can include the Internet or one or more intranets, landline networks, wireless networks, and / or other suitable types of networks. Thus, network 150 can correspond to a small-scale communication network (e.g., a private network or a local area network), or can correspond to a larger-scale network (e.g., a wide area network or the Internet) accessible to various components of system 100.

[0057] Figures 2A-2C 200a-200c are examples of methods for establishing and adjusting spending and / or electronic transaction processing limits for a digital account using an online transaction processor, according to an embodiment. When spending limits are set and / or adjusted via an executable application and / or website (e.g., when compared to a reference Figure 1 ), the computing device may display Figures 2A-2C Figures 200a-200c in.

[0058] exist Figure 2A In FIG. 200 a , various interactions, inputs, interface elements, and / or communications are shown to establish a spending limit on the available credit line. For example, in Figure 2AIn interface 2002, the mobile application interface can allow the user to view the spending limit and adjust the payment date for the next month and the use of the spending limit or other monthly authorization limit (e.g., monthly spending or funding authorization limit) by browsing one or more selectable options. In interface 2002, one or more application icons and / or configurable application interactions and inputs can be used to adjust and / or configure the spending limit. This allows the spending limit to be set to a credit line that is equal to or lower than the user's monthly authorization line to better control the user's budget, while allowing a larger credit line to help the user build a better credit score. The user can also request a higher credit line, which can be provided based on the output of the machine learning engine.

[0059] In this regard, interface 2002 includes a next month due selector 2004 (labeled "Next Month Due 2004") and an x-pay loan conversion selector 2006 (labeled "Installment Plan 2006"). Next month due selector 2004 can correspond to the user's available budget, which can be used to immediately pay for the transaction via a sliding adjuster 2008. Next month due selector 2004 can be associated with an overall limit such as the user's available spending budget, account balance, or other budgets that the user can set using the corresponding application and / or corresponding service provider of the user's account. X-pay loan conversion selector 2006 can be used to adjust the available monthly credit limit, which can be expanded via sliding adjuster 2010 based on one or more AI engines (e.g., rule-based and / or ML-based models and / or engines). The user can then use the slide bar and / or configurable application functionality to select between a minimum amount and a maximum amount for the next month due selector 2004 and / or the x-pay loan conversion selector 2006. The user can use the slide adjusters 2008 and 2010 to input the available amount that is then available for use through the corresponding mobile application or other software application and website for the user's corresponding spending limit and availability settings.

[0060] After selecting a spending limit for the next month due selector 2004 and / or the x-pay loan conversion selector 2006 via the slide controls 2008 and 2010, the interface 2002 may display information allowing the user to view a spending limit control panel. Figure 2AIn the interface 2002, a Pay Now option 2012 and a Loan Conversion option 2014 may be displayed, which provide information regarding the establishment of spending limits and / or allow confirmation of spending limits for each of the Next Month Due selector 2004 and / or the x-pay Loan Conversion selector 2006 and their corresponding spending limits. Selecting the Pay Now option 2012 and the Loan Conversion option 2014 allows the user to navigate to other interfaces and / or use the application for corresponding spending limits. For example, other interfaces may be used to request other loan agreements and / or credit extensions, as well as provide the user with information regarding other available balances.

[0061] exist Figure 2B In the interface 2102,2104 and 2106 of Figure 200b, adjustable and configurable slide bar is shown, so that the user configures consumption limit by the application interface.For example, in interface 2102, slide bar 2108 is shown, and this slide bar 2108 comprises both the available budget of the user and the loan conversion availability of the user.This can allow the user to configure and / or set a plurality of different options for consumption limit, and when the user uses or otherwise provides such consumption limit option, these options also can be adjusted.After this, the user can move the slide bar to request to change more user budgets, available funds, and / or extendable credit, or request whether there are more or less user budgets, available funds, and / or extendable credit by the application that provides interface 2102,2104 and / or 2106.

[0062] In interface 2104, a confirmation notification and / or request may be provided to the user to confirm the corresponding spending limit available through the application and / or website for the digital account available to the user. This may include providing confirmation of spending limit 2110 via confirmation option 2112. Confirming spending limit 2110 using confirmation option 2112 may cause interfaces 2102 and / or 2104 to be updated to interface 2106, which includes updated spending limit 2114, which allows the user to process the transaction electronically using the application and / or website. Thereafter, Figure 2C , the user may further configure and / or adjust spending limits 2114 based on other preferences, inputs, and / or processed transactions.

[0063] exist Figure 2C200c, the user can first view the user's monthly authorized limit 2210, which can be based on the available limit or maximum balance, funds, or budget provided to and / or established for the user (e.g., a risk assessment based on information known or available to the user, such as a risk profile or analysis, past payment and repayment history, bank account balances, realized and / or expected payments or wages, or other known available value or currency) and extended credit to the user. The monthly authorized limit 2210 can be used for the amount due next month and the amount to be converted to an x-pay or other installment plan or loan, each of which can be configured by moving, entering user input, and / or sliding interface elements in interface 2202 to display the requested and configured amount due next month and / or the amount to be converted to an installment plan in interface 2204. In interface 2204, an adjusted installment plan 2212 may be shown, wherein a maximum value less than the available credit limit or monthly authorized limit is configured by sliding the interface element to the left to convert the installment plan. Thus, another amount is available from the extended credit limit for additional installment plans or x-pays. Conversely, in interface 2206, next month due interface 2214 is configured by sliding the interface element to the right to adjust the available balance and / or spending limit by applying a portion of the monthly authorized limit to the payment due next month or the next billing cycle / bill date. Thereafter, confirmation of the spending limit can be confirmed in interface 2208 via notification 2216.

[0064] In various embodiments, a user's monthly authorized limit can be reset at the end of a billing or usage cycle and / or at the beginning of the next billing or usage cycle. This can be crucial for imposing new limits on a user. If existing installment plans still require payments, they may be represented as part of the next month's due bar on the left side of the interface at the beginning of the billing cycle. Thus, payments may "disappear" or become unavailable for individual viewing and may be incorporated into the installment plan and the amount due next month. This allows users to focus on paying off bills and making additional payments without overextending their credit or budgeting and going into debt.

[0065] Figure 3 is an exemplary system environment 300 illustrating the interactions between system components for generating and dynamically adjusting application limits to enforce account usage limits, according to an embodiment. Figure 3 The environment 300 includes reference Figure 110 , the client device 110, the merchant device 120, and the online transaction processor 130 discussed above for the system 100. In this regard, the client device 110, the merchant device 120, and the online transaction processor 130 generate and display interfaces for device applications (e.g., the purchasing application 112) based on available and / or established spending limits, and may be used to dynamically configure the presented or displayed interfaces of the device applications.

[0066] Environment 300 includes interactions between client device 110, merchant device 120, and online transaction processor 130, which can be used to configure such spending limits and further update such limits. In environment 300, client device 110 may first interact with online transaction processor 130 during interaction 1 to request, establish, and / or configure a spending limit. This may be done based on a spending limit calculated for the user associated with client device 110. This limit may be based on the user's budget, available balance, income or expected payments to the user, salary, etc., as well as regulatory or set spending limits for users in a particular region, country, etc. During interaction 1, user data of the user may be obtained and / or determined. In interaction 2, online transaction processor 130 may interact with merchant device 120 to determine merchant data, as well as any merchant agreements that may be associated with available funds available to and / or provided to the merchant corresponding to merchant device 120. This merchant data may be used to determine the user's spending limit based on additional merchant data and / or agreements, as well as merchant reliability and / or credit ratings.

[0067] In interaction 3, the client device 110 and the online transaction processor 130 may interact to provide the user with a determined spending limit, which may include a pre-planned budget, an available budget or balance, and / or an extendable budget or balance provided to the user based on one or more AI engines. Such AI engines may include rule-based and / or ML-based engines that configure each balance based on user data and / or merchant data of the user associated with the client device 110 and the merchant associated with the merchant device 120, respectively. A user interface in the application may be configured, updated, and / or output based on the data determined for the determined spending limit in interaction 3. In interaction 4, the user may enter input into the application that may be used to adjust various parameters, features, and / or available limits for the determined spending limit and / or a portion of the spending limit (e.g., an available payment amount, a credit limit, and / or an extendable credit request). For example, one or more interface elements and / or options may be used to select, scroll, slide, or adjust interface options to select available credit.

[0068] In interaction 5, client device 110 interacts with merchant device 120, for example, to process a transaction and / or otherwise engage in the use of a configured spending balance. For example, client device 110 may electronically process the transaction with merchant device 120 based on the configured spending limit and through a browser application, an application on client device 110, or other available website. In response to interaction 5, online transaction processor 130 may interact with client device 110 and merchant device 120 during interactions 6a and 6b to approve and / or confirm the transaction. This may include verifying available user data, user configuration of spending limits, merchant data, merchant agreements, etc. before payment confirmation. Thereafter, in interaction 7, online transaction processor 130 may dynamically adjust available spending limits and / or interface elements and display the availability of the remaining balance or spending limit in the application on client device 110. Furthermore, after the initial provision and / or use of credit, there may be an option to reset and / or adjust the credit. This may be based on updated user and / or merchant data processed by one or more ML engines.

[0069] Figure 4A 4 is a flowchart 400a of an exemplary process for generating application restrictions to enforce account usage restrictions according to an embodiment. Note that one or more steps, processes, and methods described in flowchart 400a may be omitted, performed in a different order, or combined as needed or appropriate.

[0070] At step 402 of flowchart 400a, an interaction between a user and a merchant detected for an application for electronic transaction processing is identified. The interaction may correspond to a user requesting an available balance available to the merchant and / or one or more other merchants. Such a request may be based on the user's available balance (e.g., in a bank account or through other financial accounts or instruments, including regular pay or pay periods) and credit or other limits available to the user.

[0071] At step 404, user data and merchant data are determined. The user data may include user financial data, historical payment and / or repayment data, credit worthiness, etc. The merchant data may include merchant agreements for extendable credit ratings, merchant balances, and / or credit worthiness, etc. The user and merchants associated with such data may access such data from one or more data repositories, computing devices, etc.

[0072] At step 406, the spending limits available to the user are calculated or determined by a computing application (e.g., by using an AI engine). The AI engine may include one or more rule-based and / or ML-based engine models that can provide predictive outputs and determine the user's available balance, upcoming balance, and / or credit limit. Using user data and merchant data, the availability of spending limits can be calculated, which can also include classifying the available data into multiple categories, such as spending limits based on available funds and / or credit funds, and converting funds into a certain amount of credit or deferred payment plan.

[0073] In step 408, the spending limit is transmitted to a user device, such as a computing device and / or mobile device having a computing application. The spending limit can be updated in the computing application so that the user can view one or more interface elements, options, icons, and / or user input preferences for adjusting the spending limit. This can include one or more scrollable bars or user inputs that allow the spending limit to be configured. The transmission of the spending limit can occur before the application is loaded and / or in an active manner so that the user can immediately view the spending limit, and / or the transmission of the spending limit can occur when the computing application is loaded. Therefore, in step 410, the application interface is displayed, allowing the spending limit to be configured in the application. This can be accomplished by the user inputting into the computing application via the user interface element shown for the spending limit, and can allow different parameters and / or balances (e.g., available or monthly balance limits, extendable credit, etc.) to be configured separately.

[0074] Figure 4B 400b is a flowchart of an exemplary process for dynamically adjusting application restrictions to enforce account usage restrictions according to an embodiment. Note that one or more steps, processes, and methods described in flowchart 400b may be omitted, performed in a different order, or combined as needed or appropriate.

[0075] At step 412 of flowchart 400b, a change in user data associated with the user's budget is detected and / or received. For example, the user may utilize a portion of the budget and / or extended credit to make a purchase. This may be accomplished by a computing application that may provide electronic transaction processing services to the user. The change may also be based on other user data, such as a change in available balance, the user's income or other incoming funds, and / or other outgoing funds of the user.

[0076] At step 414, an adjustment to the spending limits available to the user at one or more merchants is determined based on the change. The adjustment can be calculated (e.g., based on an AI engine (e.g., a rule-based or ML-based model engine that can utilize the change and user / merchant data to provide a predictive output)). The adjustment can include otherwise changing the user's available spending limits through the user's user interface. Thus, the adjustment can include one or more configurable settings for the user's spending limits that can automatically adjust the spending limits based on previously available limits.

[0077] At step 416, agreement information between the two entities is accessed based on the adjustment. This agreement information may include one or more merchant or other entity agreements and / or available credit extension requirements for one or more of these entities. This information can be used to determine the availability level of the user's spending limit. At step 418, changes to the spending limit are calculated, for example, using an AI engine that may include one or more rule-based or machine learning-based models. These engines can be used to make intelligent decisions about the spending limits available to users in a dynamic manner. Thus, spending limits can be dynamically adjusted based on changes in user information, agreement information, merchant information, and / or spending patterns and / or user input. At step 420, the user interface of the computing application is adjusted based on the changes in spending limits. The user interface can be dynamically adjusted and / or altered based on the changes in spending limits in a proactive and / or dynamic manner, allowing the user to view the changes in the application in real time and / or upon loading and executing the application. Thus, when the user views the user interface, the user can see the changes in spending limits immediately or in near real time.

[0078] In one embodiment, a system includes: non-volatile memory; and one or more hardware processors coupled to the non-volatile memory, configured to read instructions from the non-volatile memory to cause the system to perform operations, the operations including: detecting an interaction between a user and a merchant using an application on a user device of the user; determining user data of the user and merchant data of the merchant; executing a rule-based engine of the system associated with the application; calculating a spending limit available to the user for the merchant based on the user data and the merchant data and based on the executed rule-based engine; sending the spending limit to the user device of the user via an application programming interface (API) of the application on the user device; automatically updating data of an interface on the user device with the spending limit via the API; and implementing an adjustable option of the system for the spending limit in the interface.

[0079] In other embodiments of the above system, 1) the operation further includes: receiving an electronic transaction processing request for a transaction; determining that the transaction violates a spending limit; and rejecting the electronic transaction processing request via the interface through the API; 2) the operation further includes: sending a notification to the user device, wherein the notification includes an option to adjust the spending limit using an adjustable option and using a maximum amount that is lower than the spending limit; in response to sending the notification, receiving a request to adjust the spending limit using the adjustable option; and adjusting the available spending limit through the application using the API; 3) the option requires authentication of a desired digital account of the user; 4) calculating the spending limit includes pre-calculating multiple states of the application before activating the application on the user device, the multiple states being loaded to the application by sending; 5) setting the spending limit for a time period associated with the use of the maximum credit limit; system, and wherein the spending limit is equal to or lower than the maximum credit limit available to the user for the merchant during the time period; 6) the spending limit also includes a transaction type limit based on one or more merchant category codes (MCCs) of the merchant; 7) before calculating the spending limit, the operation also includes determining a merchant authorized spending agreement with the merchant, wherein the spending limit is also calculated based on the merchant authorized spending agreement; 8) automatic updating includes presenting a dynamic spending limit graphic element as an adjustable option in the interface, which identifies the spending limit that was pre-calculated before being presented to the user on the user device; and / or 10) wherein the operation also includes: flattening the available balance in the interface on the user device; hiding one or more conversion options in the interface; and creating an animation or graphic in the interface for the flattened available balance.

[0080] In another embodiment, a method includes determining, by an online transaction processor, a first spending plan associated with a merchant and a user based at least on a budget of the user; generating, based on the budget of the user, interface data and application restrictions for an application on a user device of the user; implementing a computing platform associated with the online transaction processor; in response to detecting a request by the user to view a transaction with the merchant, utilizing, by the computing platform, an application setting for presentation to the user; and enforcing, by the online transaction processor, the application restrictions based on the setting through the interface data during application interaction by the user in the application.

[0081] In other embodiments of the above method, 1) the method also includes receiving a request to adjust the first consumption plan to a second consumption plan that is higher or lower than the user's budget; and adjusting the first consumption plan based on the second consumption plan; 2) the maximum amount available for the first consumption plan includes a credit limit established for the user based on at least one of a budget or regulatory threshold associated with the merchant; 3) before loading the application on the user device, using interface data to determine and set the first consumption plan; and / or 4) setting the interface data includes adjusting the availability of consumption animation for the first consumption limit using the interface for a purchase interface associated with the merchant.

[0082] In other embodiments, a non-transitory machine-readable medium has machine-readable instructions stored thereon, the machine-readable instructions being executable to cause a machine to perform operations comprising: causing at least one interface element associated with a spending limit on a credit extension for a user to be displayed via an application programming interface (API) of an application on a user device and via a user interface in the application, wherein the credit extension has a maximum credit limit provided to the user and is linked to at least one merchant; utilizing a rule-based computation engine to determine an update to the spending limit for the application; establishing the updated credit extension spending limit with the user in the application via the user interface via the API; and monitoring the application via the API for usage of the updated spending limit.

[0083] In other embodiments of the above-mentioned non-transitory machine-readable medium, 1) the rule-based computing engine also includes at least one machine learning (ML) model, and the at least one ML model is trained to update multiple spending limits used by the application; 2) at least one ML model provides a dynamic version of the updated spending limits based on a set of ML features; 3) the operation also includes detecting usage of at least a portion of the updated spending limits; and further establishing the revised spending limits based on the usage through a user interface; and / or 4) before determining the update, the operation also includes identifying at least one spending agreement with at least one merchant for the credit extension, wherein determining the update is also based on the at least one identified spending agreement.

[0084] Figure 5 is suitable for implementing according to an embodiment Figure 1 5 is a block diagram of a computer system 500 including one or more components. In various embodiments, the communication device may include a personal computing device capable of communicating with a network (e.g., a smartphone, a computing tablet, a personal computer, a laptop, a wearable computing device (e.g., glasses or a watch, a Bluetooth device, a key fob, a badge, etc.)). The service provider may use a network computing device capable of communicating with a network (e.g., a network server). It should be understood that each device used by the user and the service provider can be implemented as the computer system 500 in the following manner.

[0085] Computer system 500 includes a bus 502 or other communication mechanism for transmitting information data, signals, and information between the various components of computer system 500. Components include an input / output (I / O) component 504, which processes user actions (e.g., selecting a key on a keyboard / keypad, selecting one or more buttons, images, or links, and / or moving one or more images) and sends corresponding signals to bus 502. I / O component 504 may also include output components, such as a display 511 and a cursor control device 513 (e.g., a keypad, keyboard, mouse, etc.). An optional audio input / output component 505 may also be included to allow a user to input information using voice by converting audio signals. Audio / visual I / O component 505 can allow a user to hear audio and view images / video, including projections of such images / video. A transceiver or network interface 506 transmits and receives signals between computer system 500 and other devices (e.g., other communication devices, service devices, or service provider servers) via network 150. In one embodiment, transmission is wireless, although other transmission media and methods may also be suitable. One or more processors 512, which may be microcontrollers, digital signal processors (DSPs), or other processing components, process these various signals, such as for display on the computer system 500 or transmission to other devices via the communication link 518. The processor(s) 512 may also control the transmission of information (e.g., cookies or IP addresses) to other devices.

[0086] Components of computer system 500 also include a system memory component 514 (e.g., RAM), a static storage component 516 (e.g., ROM), and / or a disk drive 517. Computer system 500 performs specific operations by executing one or more sequences of instructions contained in system memory component 514 by processor(s) 512 and other components. Logic may be encoded in a computer-readable medium, which refers to any medium that participates in providing instructions to processor(s) 512 for execution. Such media may take various forms, including, but not limited to, non-volatile media, volatile media, and transmission media. In various embodiments, non-volatile media include optical or magnetic disks, volatile media include dynamic memory such as system memory component 514, and transmission media include coaxial cables, copper wire, and fiber optic cables, including the wires that comprise bus 502. In one embodiment, logic is encoded in a non-transitory computer-readable medium. In one example, transmission media may take the form of acoustic or light waves, such as those generated during radio, optical, and infrared data communications.

[0087] Some common forms of computer readable media include floppy disks, diskettes, hard disks, magnetic tape, any other magnetic media, CD-ROMs, any other optical media, punch cards, paper tape, any other physical media with patterns of holes, RAM, PROM, EEPROM, FLASH-EEPROM, any other memory chip or cartridge, or any other medium suitable for reading by a computer.

[0088] In various embodiments of the present disclosure, the computer system 500 can execute a sequence of instructions for implementing the present disclosure. In various other embodiments of the present disclosure, multiple computer systems 500 coupled to a network (e.g., a LAN, WLAN, PTSN, and / or various other wired or wireless networks, including telecommunications, mobile, and cellular telephone networks) via a communication link 518 can coordinate with each other to execute a sequence of instructions for practicing the present disclosure.

[0089] Where applicable, hardware, software, or a combination of hardware and software may be used to implement the various embodiments provided herein. In addition, where applicable, the various hardware components and / or software components described herein may be combined into composite components comprising software, hardware, and / or both, without departing from the spirit of the present disclosure. Where applicable, the various hardware components and / or software components described herein may be separated into subcomponents comprising software, hardware, or both, without departing from the scope of the present disclosure. In addition, where applicable, it may be considered to implement a software component as a hardware component, and vice versa.

[0090] According to the present disclosure, software such as program code and / or data may be stored on one or more computer-readable media. It is also contemplated that the software identified herein may be implemented using one or more general or special-purpose computers and / or computer systems (networked and / or otherwise). Where applicable, the order of the various steps described herein may be changed, combined into composite steps, and / or separated into sub-steps to provide the features described herein.

[0091] The foregoing disclosure is not intended to limit the present disclosure to the precise form disclosed or to the specific field of use. Therefore, various alternative embodiments and / or modifications of the present disclosure are contemplated, whether explicitly described or implicitly provided, as appropriate to the circumstances of the present disclosure. Having described embodiments of the present disclosure, one skilled in the art will recognize that changes in form and detail may be made without departing from the scope of the present disclosure. Therefore, the present disclosure is limited only by the claims.

Claims

1. A system comprising: non-transitory memory; as well as One or more hardware processors coupled to the non-transitory memory and configured to read instructions from the non-transitory memory to cause the system to perform operations comprising: detecting a change in an interface element input by a user through an application of a service provider on a user device of the user; determining that the change is associated with at least one of: user data associated with a user, or an electronic budget established by the user for the application; determining a first spending limit of the user for the merchant; accessing information associated with the merchant and the service provider; using an artificial intelligence (AI) engine, calculating a second spending limit different from the first spending limit based on the change and the information; generating an interface output of a user interface of the application based on the calculated second consumption limit; and Prior to launching the application on the user device of the user, the application is updated using the interface output via an application programming interface (API) of the application.

2. The system according to claim 1, wherein: The operations further include: receiving electronic transaction processing requests for transactions; determining that the transaction violates the calculated second spending limit; and The electronic transaction processing request is rejected via the API.

3. The system according to claim 1, wherein: The operations further include: causing an option to be displayed in the application for adjusting the spending limit and using a maximum amount that is less than the calculated second spending limit; receiving a request to adjust the calculated second spending limit; and The calculated second consumption limit is adjusted available by the application using the API.

4. The system according to claim 3, wherein: The options include a sliding interface button operable to adjust the calculated second spending limit using the interface output via the application.

5. The system according to claim 1, wherein Calculating the second spending limit includes pre-calculating a plurality of states of the application before activating the application on the user device, the plurality of states being loaded into the application via transmission.

6. The system according to claim 1, wherein: Calculating the second spending limit is further based on an expiration of a time period associated with the electronic budget that updates at least a portion of the user data.

7. The system according to claim 1, wherein: The first spending limit and the second spending limit each include a transaction type limit based on one or more merchant category codes (MCCs) of the merchant.

8. The system according to claim 1, wherein: The calculated second spending limit includes an installment payment plan option for the calculated second spending limit, the installment payment plan option being adjustable via one or more interface elements in the application.

9. The system according to claim 8, wherein: The installment payment plan includes a plurality of payment parameters based on a user payment history of the user with the user data, and wherein the application displays a plurality of options for the installment payment plan based on the user payment history.

10. The system according to claim 1, wherein: The updating includes presenting a dynamic consumption limit graphical element in the interface, the dynamic consumption limit graphical element identifying a consumption limit that was pre-calculated prior to presentation on the user device.

11. A method comprising: detecting, by the application, on a user device of a user, usage of a spending limit available to a merchant by the user; determining user data of the user and merchant data of the merchant; using a rules-based engine to calculate a revised spending limit available to the user for the merchant based on the usage, the user data, and the merchant data; transmitting the revised spending limit to the user device via an application programming interface (API) of an application on the user device prior to further use of the spending limit by the application; and Data of an interface on the user device is automatically updated using the revised consumption limit via the API.

12. The method according to claim 11, wherein Automatically updating data includes adjusting a spending animation of the revised spending limit using an interface that utilizes a purchasing interface for an installment plan for one or more merchants.

13. The method according to claim 12, wherein: The consumption animation includes a movable payment button for the installment payment plan, and the user can configure the movable payment button through the interface in the application.

14. The method according to claim 11, wherein The maximum amount available for the revised spending limit includes a credit line established for the user based on one or more of a budget or a regulatory threshold amount associated with the merchant.

15. The method according to claim 11, wherein The revised consumption limit is determined and set by the data before the application is loaded on the user device.

16. A non-transitory machine-readable medium having machine-readable instructions stored thereon, the machine-readable instructions being executable to cause a machine to perform operations comprising: causing a first interface element to be displayed via a user interface in an application on a device of the user through an application programming interface (API) of the application, the first interface element being associated with a first spending limit provided to the user by a service provider based on user data of the user, a merchant agreement with a merchant, and regulatory parameters associated with the first spending limit provided to the user; determining an update to at least one of the user data or the merchant agreement; generating a second spending limit visible in an application tool of the application based on the update; causing, before launching the application on the device, the second spending limit provided to the user to be updated and displayed via the user interface through the API; and The application is monitored via the API for usage of the second consumption limit.

17. The non-transitory machine-readable medium of claim 16, wherein: The determination utilizes a rule-based computation engine.

18. The non-transitory machine-readable medium of claim 17, wherein: The rule-based computation engine includes at least one machine learning (ML) model trained to proactively update a plurality of consumption limits used by the application based on the update.

19. The non-transitory machine-readable medium of claim 16, wherein: The operations further include: detecting usage of at least a portion of the updated consumption limit based on the monitoring; and The second consumption limit is adjusted in the application via the API based on the detection.

20. The non-transitory machine-readable medium of claim 16, wherein: Causing the second spending limit to be updated and displayed includes updating a scrollable interface element configured to automatically change the second spending limit based on user input by the user.

Images