Providing application notification for calculating application limits
A system with AI-driven dynamic spending limits addresses the challenge of managing digital account limits, enhancing security and compliance by allowing users to set and adjust limits based on user data and merchant agreements, ensuring real-time transaction control.
Patent Information
- Application Number
- JP2025538245
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2022-12-30
- Filing Date
- 2023-12-20
- Publication Date
- 2026-02-03
AI Technical Summary
Users of digital accounts linked to online transaction processors face challenges in managing credit limits and transaction limits due to the inability to view real-time balances and the risk of cyber attacks, phishing schemes, and malware compromising their accounts, necessitating preset and adjustable limits to protect their funds.
Implementing a system that allows users to set and adjust spending limits dynamically through a budgeting tool, using AI engines to calculate limits based on user data, merchant agreements, and regulatory requirements, with real-time monitoring and transaction processing to enforce these limits.
Enables users to manage their digital account spending effectively, reducing exposure to cyber threats and ensuring compliance with regulatory limits, while providing real-time control over credit usage.
Smart Images

Figure 2026503967000001_ABST
Abstract
Description
[Technical Field]
[0001] [CROSS REFERENCE TO RELATED APPLICATIONS] This application claims the benefit of priority to U.S. patent application Ser. No. 18 / 148,956, filed December 30, 2022, and also claims the benefit of priority to U.S. patent application Ser. No. 18 / 148,979, filed December 30, 2022, each of which is incorporated by reference in its entirety.
[0002] [Technical field] FIELD OF THE INVENTION This application relates generally to data processing, and more particularly to providing one or more selectable interface limits or options for providing application limits in computing applications. [Background technology]
[0003] Through device applications and digital accounts, users may utilize online transaction processors to process payments between various entities. Additionally, these online transaction processors may also offer payment options, credit, and / or provision for in-person transaction processing and use at merchant locations. When providing payment options and spending limits through one or more software applications, users may receive a credit limit and / or have access to a credit balance, real funds, or virtual funds linked to their digital account. While users may desire additional credit (e.g., to realize more purchasing power or to increase their credit rating), they may not want to have the full available limit based on personal discretion. Furthermore, because the account is accessed by the user rather than a computing device such as a mobile phone, they may not be able to view the available or statement balance, credit limit, amount of used credit, and / or other available funds on a regular cycle. Therefore, online transaction processors may wish to apply preset and / or adjustable limits to the account. Therefore, with the increasing threat of cyber attacks, phishing schemes, and malware that can compromise user accounts or digital accounts, users and online transaction processors may want to apply preset, adjustable, and / or real-time limits to account usage to reduce the exposure of funds to the account. [Brief explanation of the drawings]
[0004] [Figure 1] FIG. 1 is a block diagram of a networked system suitable for implementing the processes described herein, according to an embodiment. [Figure 2A] FIG. 1 illustrates an exemplary diagram for establishing and adjusting spending and / or electronic transaction processing limits on a digital account at an online transaction processor, according to an embodiment. [Figure 2B] FIG. 1 illustrates an exemplary diagram for establishing and adjusting spending and / or electronic transaction processing limits on a digital account at an online transaction processor, according to an embodiment. [Figure 2C] FIG. 1 illustrates an exemplary diagram for establishing and adjusting spending and / or electronic transaction processing limits on a digital account at an online transaction processor, according to an embodiment. [Figure 3] 1 is an exemplary system environment of interactions between system components for generating and dynamically adjusting application limits for enforcing account usage limits, according to an embodiment. [Figure 4A] 1 is a flowchart of an exemplary process for generating application limits for applying account usage limits, according to an embodiment. [Figure 4B] 1 is a flowchart of an exemplary process for dynamically adjusting application limits for enforcing account usage limits, according to an embodiment. [Figure 5] 2 is a block diagram of a computer system suitable for implementing one or more components in FIG. 1, according to an embodiment.
[0005] The embodiments of the present disclosure and their advantages are best understood by reference to the following detailed description, in which like reference numerals are used to refer to like elements shown in one or more figures, and which are intended to illustrate, not limit, embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION
[0006] A method is provided for utilizing transaction restrictions to enforce account spending limits.A system suitable for implementing the methods of the present disclosure is provided.
[0007] A user may utilize a digital account, payment card, and / or other funding source to process payments via an electronic card or transaction network associated with an end payment processor or other entity on the network. An identifier may be associated with the user's digital account by an online transaction processor, an example of which is a payment service provider (e.g., PayPal®) that may provide electronic transaction processing services to the user through the account and one or more websites and / or applications of the online transaction processor or merchant. A digital account may be established with a credit limit and / or may have a balance or value available in the digital account. The online transaction processor may include integration with the electronic card network to enable data exchange and communication between the two networks. The user and / or the online transaction processor may establish one or more spending or transaction processing limits for the digital account and / or available spending limit and balance, such as a credit limit and / or balance usage, which may include various configurable levels or parameters. For example, a transaction processing limit and / or spending limit may limit the credit available to a digital account to an amount less than the maximum credit amount, such as $3,000 even if the maximum credit limit is $10,000. The online transaction processor may then monitor the digital account and / or digital account usage with the electronic card network to apply spending limits and limit card usage. This data processing may occur at certain time intervals or after periods or cycles, such as weekly, monthly, or other (e.g., after a billing cycle). Furthermore, the user may be able to accept the maximum grantable limit and / or utilize a software application to adjust such limits, such as by limiting or moving the limit to a lower level. Thereafter, when the user utilizes the digital account to process a transaction, the online transaction processor may prevent data processing if the level, threshold, or grantable balance is exceeded.Additionally, the online transaction processor may alert the user if such a configurable balance is exceeded and provide options to remove lower level balances, adjust balances, and / or approve transactions based on available and / or grantable credit.
[0008] In this regard, a user may process a 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. The selection of one or more goods in an in-person transaction at a merchant's physical location or through an online transaction or other digital platform may require a payment instrument from the user for electronic transaction processing. A user may pay for one or more transactions by using a digital wallet or other account linked to an online service provider or other transaction processor (e.g., PayPal®) and by using a digital account (e.g., by presenting a card and swiping card data or entering card details and / or account number). The account and / or corresponding digital account linked to the service provider may be established by providing account details such as a login, password (or other authentication credentials such as biometric, fingerprint, retinal scan, etc.), and other account opening details. The account creation details may include identifying information for establishing an account, such as personal information about the user, business or merchant information about the entity, or other types of identifying information including name, address, and / or other information.
[0009] Users may also be required to provide financial information, including digital account (e.g., credit / debit card) information, bank account information, gift card information, rewards / incentives, and / or financial investments, when processing transactions with merchants and / or other users or entities. Account opening details may also be used to establish account funds and / or value, such as by transferring funds to the account and / or establishing a credit limit and corresponding credit value available for the account and / or card. Online payment providers may offer digital wallet services, which may provide financial services for sending, storing, and receiving money, processing financial instruments, and / or providing transaction history, including tokenization of digital wallet data for transaction processing. Service provider applications and websites, such as PayPal® and other online payment providers, may provide payment and other transaction processing services. Digital accounts linked to users may also correspond to peer-to-peer payment accounts and / or social network accounts, such as those that may be used with peer-to-peer payment and social networking platforms provided by online transaction processors. Additionally, the digital account may be utilized through one or more mobile applications or other software applications for mobile devices.
[0010] To make a payment for a transaction (e.g., a transfer or payment to another user, a merchant, or other entity), a user may provide digital account or funding source information or may log in via authentication information in a software application to an account associated with a service provider. A payment may then be issued to the other party to the transaction, and transaction information may be stored with the digital wallet or account. In this regard, a digital token or other data may authorize and / or authenticate the user to use their digital wallet and / or the payment method with that digital wallet, which may be sent to the other party (e.g., an agent and / or merchant) for payment processing. Data may be stored on one or more storage media, such as a magnetic stripe or EMV chip, associated with the digital account. For example, a POS device and / or card reader may be used to read card data from a merchant device at a merchant location, which may enable the user to make a payment via the payment account and / or digital wallet. In some embodiments, an account and / or digital wallet may be linked to a user's device or application, and a transaction may be authorized by the user, whereupon selection of the account or other data automatically initiates a transaction to purchase goods using the account and / or digital wallet.
[0011] Once a digital account is opened, such as after a credit card and / or debit card is issued, established, and / or linked to the user's digital account, the user receives an available balance that can be used by the user. This may correspond to a real or virtual asset or value and may be a revolving credit line provided to the user. The user may wish to apply restrictions to electronic transaction processing and spending of the available balance, such as a revolving credit line. For example, a user may be provided with a high maximum credit line (e.g., $5,000, $10,000, $30,000), but if the user intends to spend up to that limit, such a high maximum credit line provided will negatively impact the user's budget. In this regard, the user's budget may be limited to only being able to spend $2,000 in credit repayments or balance payments (e.g., payments on the balance of the extended credit) in a revolving credit billing cycle or period, whether one-time or recurring. Thus, a user may establish lower limits that prevent electronic transaction processing using a digital account and / or the digital account.
[0012] In this regard, a user may utilize mobile and / or permanent software applications on a computing device and / or website to receive and / or view one or more spending limits and / or transaction processing limits associated with a digital account and / or digital account credit limit. These interfaces may enable a user to view the maximum spending limit to which they may be granted based on one or more rules, regulations, and / or budgets associated with the user. For example, governmental and / or regulatory laws or rules may set the available limits for the user. Furthermore, the user's budget, income, past repayment data, credit rating, or other user data may set these limits. These limits may also be determined using a rule-based or machine learning (ML)-based artificial intelligence (AI) engine capable of pre-calculating and recalculating such limits based on real-time and / or available user data. Such an AI engine may also use merchant data, merchant agreements, and other data to calculate such limits. Once calculated, the limits may be transmitted to the user's user device so that such data is available and viewable via one or more user interfaces.
[0013] The user may then set a spending limit at and / or below the maximum credit limit granted to them. For example, if the maximum credit limit is $10,000, the user may set the spending limit at any level between $1 and $10,000. The user may set the spending limit at a level corresponding to their budget for a specific or recurring period, and / or a budget may be recommended to the user. The spending limit may correspond to an electronic transaction processing limit that prevents the use of the granted credit or other balance using the digital account when conducting electronic transactions via the application and / or using another payment method. Thus, when the spending limit or other established threshold for credit usage of the granted credit is reached or exceeded, the online transaction processor may block the transaction, such as by denying the transaction and / or instructing the terminal credit processor system and electronic card network to deny the transaction, and prevent the transaction from being processed and the credit limit from being used.
[0014] A user may set various spending limits, such as through a budgeting tool, and / or may set limits on the balance of credit extended or other value through a digital account and / or on electronic transaction processing using a digital account. The budgeting tool may be attached to an overall risk exposure limit, such as a maximum credit limit that may be provided to the user by an online transaction processor. The spending limits available through the budgeting tool may also be configurable and / or calculated using such service provider's engine, and may be static, such as for a monthly spending limit, or dynamic, such as based on a budget available to the user over a period of time. However, the budgeting tool tied to an overall risk exposure limit is separate from the monthly capacity or available funds determined by the online transaction processor's risk management department and risk analysis work. This monthly capacity may be based on the user's risk profile, affordability check constraints, etc., and the constraints may be based on local or regional laws, regulations, and / or compliance requirements.
[0015] For example, a spending limit may be a static amount that prevents a user from exceeding a limit that may be user-settable in a user interface between a minimum and maximum amount available to the user, such as a $2,000 limit. This may not reset after a certain period of time, i.e., may be reset based on the user's income, budget, or other preferences and data. A spending limit may also be a dynamic or variable limit, such as $2,000 per month, and therefore may reset after the time limit and / or may reset based on spending. In addition, other data may be used to set various types of spending limits, for example, based on merchant agreements, merchant category codes (MCCs) and transaction categories, time of day, purchase type, etc. A spending limit may restrict certain types of transaction transactions and / or, if the spending limit is a dynamic or variable limit, the spending limit may be related to a time period, such as a payment cycle and / or billing cycle, and may reset after that period of time. Additionally, spending limits may be specific to one digital account among multiple accounts and / or limits provided to the user. Additionally, spending limits may be tiered and may incrementally grant additional credit or other funds and value, such as when each spending limit is reached over the course of a day or month. Accordingly, a user may utilize one or more user interfaces to set and / or adjust spending limits, such as by using a slidable or scroll bar, an icon, or the like.
[0016] The transaction may then be processed using the digital account, which may generate and process transaction data for the transaction on the digital network. The transaction data may further include information such as one or more items, item cost (e.g., itemization) and / or total cost, transaction time, corresponding merchant or merchant identifier, other users involved in the transaction, transaction location, MCC identifying a particular category for each transaction, and / or other transaction data. An online transaction processor may provide electronic transaction processing services used to process the transaction using the transaction data and / or card data. However, in other embodiments, to receive this data, the online transaction processor may be required to interface with an end-point card processor and / or electronic card or transaction network that transmits, receives, and / or processes transaction data based on associated payment method data, such as a payment card, bank account, etc. In this regard, the online transaction processor may utilize an application programming interface (API) to communicate and integrate with one or more APIs of electronic card networks. This allows an online transaction processor (or online transaction processor) to detect, receive, and process transaction data, for example, by setting and / or applying spending limits to transactions processed on an electronic payment network. The transaction data may then be detected and / or transmitted to the online transaction processor (or online transaction processor) via one or more APIs. This may include receiving and processing the data in real time, such as as transactions occur, to apply spending limits and other electronic transaction processing limits to digital accounts when used for electronic transaction processing on one or more networks.
[0017] When a transaction is requested to be processed and transaction data for that transaction is received by an online transaction processor, the transaction data can then be analyzed to determine whether the transaction complies with or violates the application-established limit for that account. This can be done by receiving corresponding transaction information in reference to a card swipe and / or scan event, or by monitoring incoming communications from electronic card networks, merchants, point-of-sale (POS) devices, etc., and identifying electronic transaction payments requested via a digital account. Additionally, online transaction processors may offer card products that utilize physical payment cards, such as cards with magnetic stripes, EMV chips, NFC or RFID transceivers, etc., to transfer information. This can allow users to unlock future monthly capacities at the point of checkout at a merchant's location, such as a cash register or POS device at a physical store or location. Thus, users can use their physical card to select and / or change the amount to be paid for the next month at the POS device.
[0018] If the transaction complies with the limit, the online transaction processor (or online transaction processor) may approve the transaction or allow the transaction to be approved on the electronic card network (e.g., by not denying the transaction or by not requesting the electronic card network and / or the terminating credit card processing system to deny the transaction). However, if the transaction violates the limit or is otherwise not compliant with the limit (e.g., if the transaction amount causes the digital account balance and / or the digital account to exceed the credit limit), the online transaction processor (or online transaction processor) may deny the transaction by refusing to process the transaction and / or by requesting that the electronic card network and / or the terminating credit card processing system deny or deny the transaction.
[0019] If a transaction exceeds or violates a limit, the online transaction processor may refuse to process the transaction and / or send a message containing a notification or warning to the user's device. The device may include an application with one or more interface options, elements, or graphics, which may include executable options, actions, and / or selectable elements for removing or adjusting the spending limit so that the transaction can be processed. This may include a sliding scale that allows for setting spending limits between different available transaction and / or credit limits. Such limits may be granted based on various merchant agreements and / or regulatory guidelines and may also be set at one or more levels by the service provider's AI engine. The notification or warning may be sent via text message, such as SMS or MMS, or via another messaging system and protocol, such as instant messaging, application push notifications for mobile applications, email, a website chat interface, or the like. The user may also be provided with the option to access the user's digital account to change the spending limits, for example, by authenticating themselves via an application or website and viewing one or more spending limits with selectable interface options and / or interface fields for entering data to adjust the spending limits. The online transaction processor may then update the spending limits and continue to monitor the digital account and / or digital account usage for compliance with the updated spending limits.
[0020] FIG. 1 is a block diagram of a network system 100, according to an embodiment, suitable for implementing the processes described herein. As shown, system 100 may include or implement multiple devices, servers, and / or software components operating to implement various methods according to the described embodiments. Example devices and servers may include appliances, standalone, and enterprise-class servers running an operating system such as the MICROSOFT® OS, UNIX® OS, LINUX® OS, or another suitable device-based and / or server-based operating system. It is understood that the devices and / or servers illustrated in FIG. 1 may be deployed in other manners, and that the operations performed by and / or services provided by such devices and / or servers may be combined or separated in a given embodiment and may be implemented by a greater or lesser number of devices and / or servers than illustrated. One or more devices and / or servers may be operated and / or maintained by the same or different entities.
[0021] System 100 includes a client device 110, a merchant device 120, and an online transaction processor 130 communicating over a network 150. The client device 110 may be used to establish transactions and process payments for transactions using accounts managed by the client device 110. In this regard, once a transaction is processed, transaction data may be provided over a transaction network that may be available over network 150. The client device 110 and the merchant device 120 may be used to set spending limits or other electronic transaction processing limits on the use of the balance, such as a maximum granted credit limit. The online transaction processor 130 may then be used to detect the transaction data and determine whether the transaction data complies with the spending limits.
[0022] Client device 110, merchant device 120, and online transaction processor 130 may each include one or more processors, memory, and other suitable components for executing instructions, such as 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, such as memory or data storage devices within and / or external to the various components of system 100, and / or may be accessible via network 150.
[0023] Client device 110 may be implemented using any suitable hardware and software configured for wired and / or wireless communication with merchant device 120 and / or online transaction processor 130 for processing transactions based on one or more spending limits. Client device 110 may correspond to a user who processes payments and sales via an executable software application. In various embodiments, client device 110 may be implemented as a personal computer (PC), a smartphone, a laptop / tablet computer, a wristwatch with appropriate computer hardware resources, other types of wearable computing devices, and / or other types of computing devices capable of transmitting and / or receiving data. While only one computing device is shown, multiple computing devices may function similarly.
[0024] 1 includes a purchasing application 112, a database 116, and a network interface component 118. The purchasing application 112 may correspond to executable processes, procedures, and / or applications with associated hardware. In other embodiments, the client device 110 may include additional or different modules with specialized hardware and / or software as needed.
[0025] The purchasing application 112 may correspond to one or more processes executing software modules and associated components of the client device 110 to provide functions, services, and other operations for the user over the network 150, which may include accessing and utilizing computational services provided by the online transaction processor 130. In this regard, the purchasing application 112 may correspond to specialized software utilized by a user of the client device 110 that may be used to access websites or applications (e.g., mobile applications, rich internet applications, or resident software applications) that may display one or more user interfaces that enable interaction with the computational services of the online transaction processor 130. In various embodiments, the purchasing application 112 may correspond to a general browser application configured to retrieve, present, and communicate information over the Internet (e.g., utilizing resources on the World Wide Web) or over a private network. For example, the purchasing application 112 may provide a web browser capable of sending and receiving information over the network 150, including retrieving information from websites, presenting that information to the user, and / or communicating information to the website. However, in other embodiments, the purchasing application 112 may include a proprietary application of the online transaction processor 130 or other entity.
[0026] The purchasing application 112 may be associated with account information, user financial information, and / or transaction history. However, in further embodiments, various services may also be provided via the purchasing application 112, including social networking, media posting or sharing, microblogging, data browsing and searching, online shopping, and other services available via the online transaction processor 130. Accordingly, the purchasing application 112 may correspond to different service applications, etc. When utilizing the purchasing application 112 with the online transaction processor 130, the purchasing application 112 may request the processing of an interaction 114, such as a payment request and / or a spending limit request or adjustment with the online transaction processor 130. The interaction 114 may correspond to utilizing the purchasing application 112 to request, establish, and / or adjust a spending limit via one or more application icons, interfaces, and / or interactions with such displayable data. Interaction 114 may also include a payment request for one or more merchants, which may be specific to an individual merchant against a spending limit, or may be against a spending limit available across multiple merchants. Interaction 114 may be used in conjunction with a user's user account, and interaction 114 may have a corresponding user input against a spending limit.
[0027] In various embodiments, client device 110 may include other applications as may be desired in a particular embodiment to provide functionality to client device 110. For example, the other applications may include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network 150, or other types of applications. The other applications may also include email, text, voice, and IM applications that allow a user to send and receive email, calls, texts, and other notifications over network 150. In various embodiments, the other applications may include financial applications, such as banking applications. The other applications may include social networking applications, media viewing, and / or merchant applications.
[0028] The other applications may also include other location applications, such as mapping, compass, and / or GPS applications, that may be used to determine a user's location, and the GPS application may include a specialized GPS receiver that determines location information for client device 110. The other applications may include device interface applications and other display modules that may receive input from a user and / or output information to a user. For example, the other applications may include software programs executable by a processor and including a graphical user interface (GUI) configured to provide an interface to a user. The other applications may therefore use devices of client device 110, such as a display device and other output devices, including speakers, that can display information to a user.
[0029] The client device 110 may further include a database 116 stored in temporary and / or non-transitory memory of the client device 110 that may store various applications and data and that may be utilized during execution of various modules of the client device 110. The database 116 may include appropriate identifiers, such as, for example, 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 that may be communicated when identifying the user / client device 110 to the online transaction processor 130, or other identifiers used for payment / user / device authentication or identification. Additionally, the database 116 may include data used for the interaction 114, such as data that may be provided as a data load to be processed by the online transaction processor 130.
[0030] Client device 110 includes at least one network interface component 118 adapted to communicate with online transaction processor 130 and / or other devices and servers over network 150. In various embodiments, 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, radio frequency, infrared, Bluetooth, and near field communication devices.
[0031] Merchant device 120 may be maintained, for example, by a merchant or other entity that offers products for sale to users. Merchant device 120 may correspond to one or more physical and / or online merchant transactions, sales platforms, point-of-sale (POS) devices, websites, and / or online resources that users may visit to shop for products. For example, merchant device 120 may correspond to one or more POS devices at a physical merchant location for processing transactions, as well as at a website and / or application-accessible digital platform where users may present or be presented with products, services, and other items for sale, where users may browse products, select products for purchase, and participate in electronic transaction transactions. Merchant device 120 may also include other platforms, websites, and resources that may enable users to participate in electronic transaction transactions, such as those associated with payment processors, fund transfers, utility or bill payments, and other payments or purchases that may be used by users, and may request payment for certain products, services, or other goods. In some embodiments, the merchant device 120 may be implemented as a single or networked personal computer (PC), a server, a smartphone, a laptop computer, a wearable computing device, and / or other types of computing devices. Although only one merchant device is shown, multiple merchant devices may function similarly.
[0032] 1 includes a sales application 122, a database 124, and a network interface component 128. The sales application 122 may correspond to executable processes, procedures, and / or applications with associated hardware. In other embodiments, the merchant device 120 may include additional or different software as desired.
[0033] Sales application 122 may offer and / or process items for sale to client device 110 and / or a user associated with client device 110 (e.g., payment sources including payment cards, digital accounts, cash, etc.). In some embodiments, sales application 122 may be accessible via the Internet and may offer sales to client device 110 via network 150. Sales application 122 may also correspond to a checkout application at a physical merchant location, such as a point-of-sale (POS) device application used to offer sales at a physical location. Sales application 122 may be used to establish a transaction once a user / employee associated with merchant device 120 has entered one or more items for purchase and / or entered items into the transaction for processing. Once the payment amount for the items purchased by the user has been determined, merchant device 120 may request payment for the transaction. Payment may be provided using a digital account, and the merchant device 120 and / or the merchant corresponding to the merchant device 120 may have corresponding agreements with the user of the client device 110, the service provider of the online transaction processor 130, and / or a regulatory service or authority. In this regard, payment may be received from the digital account based on spending limits established by the AI engine of the online transaction processor 130 and / or set via the client device 110. After receipt of the payment by the digital account and / or confirmation of the digital account transfer, the merchant device 120 may process the payment to the merchant associated with the merchant device 120 using the digital payment.
[0034] Merchant device 120 may further include sales application 122 and / or database 124, which may include, for example, identifiers associated with 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, such as in response to receiving transaction data and / or payment data. Database 124 may therefore also store, use, and / or access digital accounts and / or digital account transfers, such as may include information associated with merchant data 126, which may be used in determining and dynamically adjusting spending limits at the user interface of client device 110.
[0035] Merchant device 120 includes at least one network interface component 128 adapted to communicate with client device 110, online transaction processor 130, and / or other devices or servers over network 150. In various embodiments, 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 wired and / or wireless network communication devices, including microwave, radio frequency, infrared, Bluetooth, and near field communication devices.
[0036] The online transaction processor 130 may be maintained by a service provider that may provide processing to, for example, provide account services and process payments, as well as establish spending limits or credit limits associated with spending limits for use of the digital account balance. 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 that facilitates communications and transactions between users. The online transaction processor 130 may be maintained by or include another type of platform or service provider, e.g., a transaction processor such as PayPal®, Inc. of San Jose, California, USA. Although the merchant device 120 and the online transaction processor 130 are discussed as separate devices and servers, in some embodiments, one or more of the described processing may be provided by other devices or servers, or the same device or server, rather than separately.
[0037] 1 includes a transaction processing platform 140, a service application 132, a database 134, and a network interface component 138. Transaction processing platform 140 and service application 132 may correspond to executable processes, procedures, and / or applications with associated hardware. In other embodiments, online transaction processor 130 may include additional or different modules with specialized hardware and / or software as needed.
[0038] The transaction processing platform 140 may correspond to one or more processes executing modules of the online transaction processor 130 and associated specialized hardware for processing transactions relating to items for the client device 110 and the merchant device 120 based on one or more transaction and spending limits established on 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 method information, such as account / card number and card 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 established with another online transaction processor or service provider and linked to the online transaction processor 130, such as via the merchant device 120. The transaction processing platform 140 may be used to set balances, credit limits, or other spending limits for the use of funds for digital payment accounts. The transaction processing platform 140 may process payments and may also provide transaction history for transaction authentication, approval, and denial.
[0039] The transaction processing platform 140 may correspond to the online transaction processor 130's products, which may be available to end users, such as making electronic payments, funds transfers, and the like, using one or more accounts and / or financial methods. The transaction processing platform 140 may also include or utilize various processors, engines, or models necessary for authentication, account opening and maintenance, electronic transaction processing, deposits and / or withdrawals, dispute resolution, and the like. The transaction processing platform 140 may include one or more API integrations and / or interactions with electronic card networks or payment networks to detect, receive, and monitor transaction data regarding spending limits and / or compliance with adjustable and dynamic settings for such limits regarding the use of one or more balances on a user's digital account. Thus, the transaction processing platform 140 may interact with the network via one or more API calls to its API, which interfaces with the electronic card network's API. The transaction processing platform 140 may determine transaction data regarding transactions processed on the network.
[0040] Transaction processing platform 140 may receive transaction data regarding transactions processed using accounts accessible via client device 110 and / or merchant device 120. Transaction processing platform 140 may then determine balances, credit limits, and / or spending limits to be set for use of other funds available to the user's digital account. In this regard, the transaction processing platform's AI engine, executed by spending limit determination process 142, may be utilized by limit determination process 144 to calculate spending limits based on budgets and / or merchant agreements using user data 146 and merchant data 126, and the AI engine may enable a user to set such limits via the purchasing application 112 or other application interface. For example, spending limits may be established at or below a maximum balance or maximum granted credit limit based on the credit limit determination by spending limit determination process 142. The spending limit may therefore adjust or reduce the available credit limit or other balance below the maximum amount (e.g., the spending limit may be $1,000 out of a $5,000 limit). The transaction may then be detected using API calls with the electronic card network, the device (e.g., client device 110 and / or merchant device 120) and / or other devices.
[0041] Transaction processing platform 140 may determine whether the transaction complies with the spending limits. If so, the transaction may be authorized or approved. However, if the transaction does not comply with the spending limits, i.e., exceeds the limits for electronic transaction processing and / or credit / balance limits, transaction processing platform 140 may be used to refuse to process the transaction or to instruct the terminating authorization processor and / or merchant device 120 to refuse to process the transaction. Additionally, transaction processing platform 140 may send a message to client device 110 and / or another device to notify the user that the spending limit has been violated, and provide an action to remove or adjust the spending limit, such as via an application icon and / or action. If the user requests removal or adjustment (and in various embodiments the user is authenticated), the spending limit may be removed or adjusted by transaction processing platform 140. Examples of such configurations are illustrated in Figures 2A-2C below.
[0042] In some embodiments, the spending limit determination process 142 may use one or more AI engines and / or models, such as rule-based, machine learning, or neural network (NN) models and / or engines, that may be used for intelligent decision-making of spending limits. These may include rule-based engines that may process user data 146 and / or merchant data 148 that may be used to determine spending limits. Additionally, the spending limit determination process 142 may utilize machine learning engines or other AI models, i.e., engines for determining spending limits. The machine learning engines and / or other rule-calculating or AI engines may be trained and / or used with user data 146 and / or merchant data 126 for determining spending limits. In some embodiments, the 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 makes decisions, such as a rule-based engine or the like. However, AI models also include subcategories, including ML models and NN models, that instead use algorithmic relationships to provide intelligent decision-making. In general, NNs may include deep learning models, among others, and may correspond to a subset of ML models that attempt to mimic human thinking by utilizing a collection of different algorithms to model data through different graphs of neurons, where neurons contain nodes of algorithm-based data representations that may be interconnected at different nodes. ML models may also utilize one or more of these mathematical models and may similarly create layers and nodes connected between layers in a manner similar to the neurons of NN models.
[0043] When building an ML model for a machine learning engine, training data may be used to create one or more classifiers and provide recommendations, predictions, or other outputs based on these classifiers and the ML model. The training data may be used to determine input features for training a prediction score and / or output related to a spending limit based on user data 146 and / or merchant data 126, and to adjust such output based on user input related to the limit adjustment process 144. For example, an ML model for a machine learning engine may include one or more layers, including an input layer with one or more nodes, a hidden layer, and an output layer, although other layers may also be used. For example, as many hidden layers as necessary or appropriate may be used. Each node in a layer is connected to nodes in adjacent layers, where a set of input values may be used to generate one or more output scores or classifications. Within the input layer, each node may correspond to a distinguishable attribute or input data type used to train the ML model for the machine learning engine.
[0044] The hidden layer may then be trained on these attributes and corresponding weights using ML algorithms, calculations, and / or techniques. For example, each of the nodes in the hidden layer generates a representation that may include a mathematical ML calculation (or algorithm) that produces a value based on the input values of the input nodes. The ML algorithm may assign a different weight to each of the data values it receives from the input nodes. The hidden layer nodes may include different weights assigned to different algorithms and / or input data and may therefore produce different values based on the input values. The values produced by the hidden layer nodes may be used by the output layer to produce one or more output values for the ML model for the machine learning engine that attempts to classify and / or provide an output of a predicted spending limit. Thus, when the ML model for the machine learning engine is used to perform predictive analysis and output, the input may provide a corresponding output based on the classification trained for the ML model for the machine learning engine.
[0045] The ML model for the machine learning engine may be trained with training data. By providing training data to train the ML model for the machine learning engine, the nodes in the hidden layer may be trained (tuned) so that optimal outputs (e.g., classifications) are produced in the output layer based on the training data. By continually providing different sets of training data and penalizing the ML model for the machine learning engine when its output is incorrect, the ML model for the machine learning engine (and specifically, the representations of the nodes in the hidden layer) may be trained (tuned) to improve its performance in data classification. Tuning the ML model for the machine learning engine includes adjusting the weights associated with each node in the hidden layer. Thus, the training data may be used as a set of input / output data that enables the ML model for the machine learning engine to perform classifications based on input attributes. The output classifications for the ML model trained for the machine learning engine may be classifications used to determine, establish, and / or adjust spending limits by the spending limit determination process 142 and / or limit adjustment process 144. This may include adjusting the functionality of such models based on requested and / or identified data points and the desired outputs and decisions for the ML model. In this regard, MMC, credit limits, user balances, etc. may be used as inputs to the ML model and may be trained as features for subsequent users.
[0046] The service application 132 may correspond to one or more processes that execute modules and associated specialized hardware of the online transaction processor 130 to process transactions or provide other services to customers, merchants, and / or 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, such as a user associated with the 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 allows for the payment, transfer, withdrawal, and / or deposit of funds. A digital token associated with the account / wallet may be used to send and process payments, for example, via one or more interfaces provided by the online transaction processor 130. The digital account may be accessed and / or used via one or more instances of a web browser application and / or dedicated software application executed by the client device 110 and may participate in the computational services provided by the service application 132. The computational services of the service application 132 may additionally or alternatively correspond to messaging, social networking, media posting or sharing, microblogging, data browsing and searching, online shopping, and other services available via the online transaction processor 130.
[0047] In various embodiments, service applications 132 may be desirable in certain embodiments for providing functionality to online transaction processor 130. For example, service applications 132 may include security applications for performing server-side security functions, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network 150, or security applications for implementing other types of applications. Service applications 132 may include software programs executable by a processor and including a graphical user interface (GUI) configured to provide an interface to a user when accessing online transaction processor 130 via one or more client devices 110, where the user or other users may interact with the GUI to more easily view and communicate information. In various embodiments, service applications 132 may include additional connectivity and / or communication applications, which may be utilized to communicate information over network 150.
[0048] Additionally, the online transaction processor 130 includes a database 134. The database 134 may store various identifiers associated with the client device 110. The database 134 may also store account data, including payment methods, authentication credentials, and transaction processing history and processed transaction data. The database 134 may store received data associated with a user, such as transaction data and spending limits for electronic transaction processing. Furthermore, the database 134 may be used to store data for an account 136, which may be used to calculate spending limits.
[0049] In various embodiments, online transaction processor 130 includes at least one network interface component 138 adapted to communicate with client device 110, merchant device 120, and / or other devices / servers for the merchant over network 150. In various embodiments, 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, radio frequency (RF), and infrared (IR) communication devices.
[0050] Network 150 may be implemented as a single network or a combination of networks. For example, in various embodiments, network 150 may include the Internet or one or more intranets, landline networks, wireless networks, and / or other suitable types of networks. Thus, network 150 may correspond to a small communications network, such as a private or local area network, or a larger network, such as a wide area network or the Internet, accessible by various components of system 100.
[0051] 2A-2C are exemplary diagrams 200a-200c for establishing and adjusting spending and / or electronic transaction processing limits on a digital account using an online transaction processor, according to an embodiment. The diagrams 200a-200c in FIGS. 2A-2C may be displayed by a computing device when setting and / or adjusting spending limits, such as when interacting with the online transaction processor 130 described with reference to the system 100 of FIG. 1 via an executable application and / or website.
[0052] In diagram 200a of FIG. 2A, various interactions, inputs, interface elements, and / or communications are shown for establishing a spending limit at an available credit limit. For example, in interface 2002 of FIG. 2A, a mobile application interface allows a user to view a spending limit and adjust the next month's payment amount as well as spending limit usage or other monthly capabilities (e.g., monthly spending or contribution capabilities) via manipulating one or more selectable options. In interface 2002, the spending limit can be adjusted and / or set using one or more application icons and / or configurable application interactions and inputs. To this end, the spending limit can be set at or below the credit limit to better control the user's budget, while allowing a larger credit limit to assist the user in building a better credit score. The user may also request a higher credit limit, which can be provided based on output from a machine learning engine.
[0053] In this regard, interface 2002 includes a next month's payment amount selector 2004 (identified as "next month's payment amount 2004") and an x-pay credit conversion selector 2006 (identified as "installment plan 2006"). Next month's payment amount selector 2004 may correspond to the user's available budget that can be immediately used to pay for the transaction via a sliding adjuster 2008. Next month's payment amount selector 2004 may be associated with the user's available spending budget, overall limits on account balance, etc., as well as other budgets that can be set by the user, with a corresponding application and / or corresponding service provider for the user's account. X-pay credit conversion selector 2006 may be used to adjust, via a sliding adjuster 2010, the available amount of monthly credit that can be granted based on one or more AI engines, such as rule-based and / or ML-based models and / or engines. The user may then use the slideable bars and / or configurable application features to select between minimum and maximum amounts for the next month's payment amount selector 2004 and / or the setting of the x-pay loan conversion selector 2006. Slideable adjusters 2008 and 2010 may be used by the user to enter input to set the available amount of money that can then be used via corresponding mobile or other software applications and websites in relation to the user's corresponding spending limits and availability.
[0054] After selection of a spending limit for next month's payment selector 2004 and / or x-pay loan conversion selector 2006 via slidable adjusters 2008 and 2010, interface 2002 may display information that enables the user to view a spending limit control panel. For example, in interface 2002 of FIG. 2A , pay now option 2012 and loan conversion option 2014 may be displayed, which provide information about establishing a spending limit and / or allow confirmation of the spending limit for next month's payment selector 2004 and / or x-pay loan conversion selector 2006 and their corresponding spending limit amounts, respectively. Selection of pay now option 2012 and loan conversion option 2014 then enables the user to operate additional interfaces and / or use applications related to the corresponding spending limits. For example, the additional interfaces may be used to request additional loan agreements and / or credit extensions and to provide the user with data regarding additional available balances.
[0055] In interfaces 2102, 2104, and 2106 of diagram 200b in FIG. 2B, adjustable and configurable slideable bars are shown for a user to set a spending limit via an application interface. For example, in interface 2102, a slideable bar 2108 is shown that includes both the user's available budget and the loan conversion availability for the user. This may allow the user to configure and / or set a number of different options for the spending limit, which may also be adjustable as the user utilizes or otherwise provides such options for the spending limit. The user may then move the slideable bar via the application providing interfaces 2102, 2104, and / or 2106 to request that more of the user's budget, available funds, and / or available credit be changed, whether more or less is available.
[0056] In interface 2104, a confirmation notice and / or request may be provided to the user for confirmation of the corresponding spending limit via an application and / or website for the digital account available to the user. This may include providing confirmation of the spending limit amount 2110 via confirmation option 2112. Confirmation of the spending limit amount 2110 using confirmation option 2112 may cause interfaces 2102 and / or 2104 to update interface 2106, including an updated spending limit amount 2114, which allows the user to process transactions electronically using the application and / or website. Thereafter, in FIG. 2C , the user may further set and / or maintain an adjusted spending limit amount 2114 based on additional preferences, inputs, and / or processed transactions.
[0057] 2C , diagram 200c illustrates reductions and / or changes to spending limits in interfaces 2202, 2204, 2206, and 2208. In interface 2202, a user may first view the user's monthly capacity 2210, which may be based on the user's granted and / or established available limit or maximum balance, funds, or budget (e.g., based on a risk assessment from information known and available to the user, such as a risk profile or analysis, past payment and repayment history, bank account balance, realized and / or expected payments or salary, or other known and available amounts or currencies), and the credit available to the user. Monthly capacity 2210 may be used through the next month's payment amount and the amount converted to x-pay or other installment plan or loan, each of which may be set by moving, entering user input, and / or sliding interface elements in interface 2202 to indicate the requested and set next month's payment amount and / or the amount to convert to an installment plan in interface 2204. In interface 2204, an adjusted installment plan 2212 may be shown, where an amount less than the maximum available credit or monthly capacity is set by sliding an interface element to the left to convert the installment plan. Thus, another amount remains available from the granted credit limit for additional installment plans or x-pay. In contrast, to adjust the available balance and / or spending limit by committing a portion of the monthly capacity to the next month's payment amount or the next billing cycle / billing date, an interface for next month's payment amount 2214 is configured using interface 2206 by sliding an interface element to the right. Confirmation of the spending limit amount may then be confirmed in interface 2208 via notification 2216.
[0058] In various embodiments, a user's monthly capacity may be reset at the end of a billing or usage cycle and / or the beginning of the next billing or usage cycle. This may be key in providing a new limit to the user. If existing installment plans still require payments, they may be displayed to the left of the interface at the beginning of the billing cycle as part of the next month's payment due. Payments may therefore "disappear," i.e., no longer be visible separately in the view, and may be combined with the installment plan and the next month's payment amount. This allows the user to focus on paying off bills and making additional payments without excessively utilizing credit or budgeting and incurring debt.
[0059] Figure 3 is an exemplary system environment 300 of interactions between system components for generating and dynamically adjusting application limits to apply account spending limits, according to an embodiment. Environment 300 of Figure 3 includes client device 110, merchant device 120, and online transaction processor 130, as described with reference to system 100 of Figure 1. In this regard, client device 110, merchant device 120, and online transaction processor 130 may be used to generate, display, and configure interfaces that are dynamically rendered or displayed to device applications, such as purchasing application 112, based on available and / or established spending limits.
[0060] Environment 300 includes interactions between client device 110, merchant device 120, and online transaction processor 130 that may be used to set and further update such spending limits. In environment 300, client device 110 may first interact with online transaction processor 130 during interaction 1 to request, establish, and / or set a spending limit. This may be done based on a calculated spending limit for a user associated with client device 110, which may be based on the user's budget, the user's available balance, the user's income or expected payments, the user's salary, etc., as well as regulatory or established spending limits for the user in a particular region, country, etc. During interaction 1, user data for 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, any merchant agreements, etc., that may be associated with available funds that may be provided by and / or to the merchant corresponding to merchant device 120. This merchant data may be used to determine spending limits for users based on additional merchant data and / or agreements and the merchant's trustworthiness and / or credit rating.
[0061] At interaction 3, client device 110 and 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 a budget or balance available to the user based on one or more AI engines. Such AI engines may include rule-based and / or ML-based engines that set each of these balances based on user data and / or merchant data for the user associated with client device 110 and the merchant associated with merchant device 120. A user interface in the application may be configured, updated, and / or output based on the data determined at interaction 3 for the determined spending limit. At interaction 4, the user may enter input into the application, which may be used to adjust various parameters, characteristics, and / or available limits for the determined spending limit and / or portions of the spending limit (e.g., available spending amount, credit amount, and / or request for available credit). For example, one or more interface elements and / or options may be used to select, scroll, slide, or adjust interface options for selecting available credit.
[0062] At interaction 5, client device 110 interacts with merchant device 120 to process a transaction and / or otherwise participate in the use of an established spending balance. For example, client device 110 may participate in electronic transaction processing for a transaction with merchant device 120 via a browser application based on an established spending limit and using an application on client device 110 or another available website, etc. 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 transaction processing. This may include verifying available user data, user spending limit settings, merchant data, merchant agreements, etc., prior to payment confirmation. Thereafter, at interaction 7, online transaction processor 130 may dynamically adjust the available spending limit and / or interface elements and may indicate the remaining balance or availability of the spending limit in the application on client device 110. Additionally, there may be an option to reset and / or adjust credit after the initial presentation and / or use of credit, which may be based on updated user and / or merchant data processed by one or more ML engines.
[0063] 4A is a flowchart 400a of an exemplary process for generating application limits for applying account usage limits, according to an embodiment. One or more steps, processes, and methods described herein with respect to flowchart 400a may be omitted, performed in a different order, or combined as desired or appropriate.
[0064] At step 402 of flowchart 400a, a detected interaction between a user and a merchant is identified for an application used for electronic transaction processing. The interaction may correspond to a user requesting an available balance that can be used at the merchant and / or one or more other merchants. Such a request may be based on a balance available to the user (e.g., in a bank account or via another financial account or method, including a regular paycheck or pay period), as well as on a credit or other limit that may be extended to the user.
[0065] At step 404, user data and merchant data are determined. User data may include user financial data, historical payment and / or repayment data, credit worthiness, etc. Merchant data may include merchant agreements for available credit levels, merchant balances, and / or credit worthiness, etc. Such data may be accessed from one or more data repositories, computing devices, and / or other for the user and merchant associated with such data.
[0066] In step 406, an available spending limit for the user is calculated or determined via the calculation application, such as using an AI engine. The AI engine may include one or more rule-based and / or ML-based models for the engine, which may provide predictive output and determination of available balance, upcoming balance, and / or credit limit that may be available to the user. Using user data and merchant data, such availability of spending limit may be calculated, which may also include sorting available data into categories, such as sorting available and / or credited funds into spending limit amounts and conversion of funds into specific amounts of credit or payment plans to be granted.
[0067] At step 408, the spending limit is transmitted to a user device, such as a computing device and / or a mobile device having a computing application. The spending limit may be updated in the computing application so that the user may view one or more interface elements, options, icons, and / or user input preferences for adjusting the spending limit. This may include one or more scrollable bars or user inputs that allow for setting the spending limit. Transmission of the spending limit may occur prior to and / or ahead of loading the application so that the user may view the spending limit immediately and / or upon loading the computing application. Accordingly, at step 410, an application interface is displayed that allows for setting the spending limit in the application. This may be done via user input into the computing application via user interface elements displayed for the spending limit, and may allow for separate setting of various parameters and / or balances (e.g., available or monthly balance limits, credit that may be granted, etc.).
[0068] 4B is a flowchart 400b of an exemplary process for dynamically adjusting application limits and enforcing account usage limits, according to an embodiment. One or more steps, processes, and methods described herein with respect to flowchart 400b may be omitted, performed in a different order, or combined as desired or appropriate.
[0069] At step 412 of flowchart 400b, changes to user data for a user associated with the user's budget are detected and / or received. For example, the user may make a purchase utilizing a portion of the budget and / or provided credit. This may be done via a computing application that may provide electronic transaction processing services to the user. The changes may also be based on other user data, such as changes in available balance, income, or other credits to and / or other payment withdrawals by the user.
[0070] At step 414, an adjustment to the user's available spending limit at one or more merchants is determined based on the changes. The adjustment may be calculated, such as based on an AI engine (e.g., a rules-based or ML-based model engine that may utilize the changes and user / merchant data to provide a predictive output). The adjustment may alternatively include changing the available spending limit for the user via the user's user interface. Thus, the adjustment may include one or more configurable settings for the user's spending limit that may automatically adjust the spending limit from the previous available limit.
[0071] At step 416, agreement information between the two entities is accessed based on the adjustment. The agreement information may include one or more merchant agreements or other entity agreements and / or requirements for credit available to one or more entities, which may be used to determine the user's level of spending limit availability. At step 418, changes to the spending limit are calculated, such as using an AI engine, which may include one or more rules- or ML-based models. These engines may be used to make intelligent decisions on the dynamic spending limit available to the user. Thus, the spending limit may be dynamically adjusted based on changes to user information, agreement information, merchant information, etc., as well as spending patterns and / or user inputs. At step 420, the user interface of the calculation application is adjusted based on the changes to the spending limit. The user interface may be dynamically adjusted and / or changed based on the changes to the spending limit in a proactive and / or dynamic manner, allowing the user to immediately view the changes in the application in real time and / or as the application loads and runs. Thus, when a user views the user interface, the user sees changes to the spending limit immediately, ie, in real time.
[0072] In one embodiment, the system includes a non-transitory memory and 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, the operations including detecting an interaction between a user and a merchant using an application on the user's user device, determining user data for the user and merchant data for the merchant, executing a system rule-based engine associated with the application, calculating an available spending limit for the user at the merchant based on the user data and the merchant data based on the executed rule-based engine, transmitting the spending limit to the user's user device via an application programming interface (API) of the application on the user device, automatically updating the data with the spending limit to an interface on the user device via the API, and implementing a system-adjustable option for the spending limit in the interface.
[0073] In another embodiment, in the system described above, 1) the operations further include receiving an electronic transaction processing request for the transaction, determining that the transaction violates a spending limit, and rejecting the electronic transaction processing request via the interface via an API; 2) the operations further include sending a notification to the user device including an option to adjust the spending limit by utilizing an adjustable option to utilize less than the maximum spending limit amount; in response to sending the notification, receiving a request to adjust the spending limit via the adjustable option, and adjusting the spending limit available via the application using the API; 3) the options require authentication for a digital account requested by the user; 4) calculating the spending limit includes pre-calculating a plurality of application states to be loaded into the application via said sending prior to launching the application on the user device; and 5) the spending limit is set for a time period associated with usage of a maximum credit amount, and the withdrawal limit is less than or equal to the maximum credit limit available to the user with respect to the merchant during the period; 6) the spending limit further includes a transaction type limit based on one or more merchant category codes (MCCs) for the merchant; 7) prior to calculating the spending limit, the operations further include determining a merchant-approved spending agreement with the merchant, the spending limit being further calculated based on the merchant-approved spending agreement; 8) automatically updating includes rendering a dynamic spending limit graphic element in the interface for the adjustable option, the dynamic spending limit graphic element identifying the pre-calculated spending limit prior to its rendering to the user on the user device; and / or 10) the operations further include smoothing the available balance in the interface on the user device, hiding one or more conversion options in the interface, and generating an animation or graph for the smoothed available balance in the interface.
[0074] In another embodiment, a method includes determining, by an online transaction processor, a first spending plan associated with the merchant and the user based at least on the user's budget; generating interface data and application limits for the application on a user device of the user based on the user's budget; implementing a computing platform of the online transaction processor associated with the application; configuring the interface data for presentation to the user in response to detecting the user using the application via the computing platform viewing a request to process a transaction with the merchant; and applying, by the online transaction processor, the application limits via the interface data based on the configuring during application interaction by the user in the application.
[0075] In other embodiments of the above method, 1) the method further includes receiving a second spending plan requesting adjusting the first spending plan above or below a budget for the user, and adjusting the first spending plan based on the second spending plan; 2) the maximum amount available for the first spending plan includes a credit limit established for the user based on at least one of the budget or a regulatory threshold amount associated with the merchant; 3) the first spending plan is determined and set using interface data prior to loading the application on the user device; and / or 4) setting the interface data includes adjusting spending animation availability for the first spending limit in an interface to a purchasing interface associated with the merchant.
[0076] In a further embodiment, a non-transitory machine-readable medium stores a plurality of machine-readable instructions executable to cause a machine to perform operations, the operations including displaying, via a user interface in an application on a user's device via an application programming interface (API) of the application, at least one interface element associated with a spending limit for a credit extension to a user, the credit extension being linked to at least one merchant and having a maximum credit amount provided to the user; determining updates to the spending limit for the application utilizing a rules-based calculation engine; establishing, via the user interface via the API, an updated spending limit for the credit extension to the user in the application; and monitoring, via the API, the application for usage of the updated spending limit.
[0077] In another embodiment of the above non-transitory machine-readable medium, 1) the rule-based calculation engine further includes at least one machine learning (ML) model trained to update a plurality of spending limits utilized by the application; 2) the at least one ML model provides a dynamic version of the updated spending limit based on the set of ML features; 3) the operations further include detecting usage of at least a portion of the updated spending limit and further establishing, via the user interface, a revised spending limit based on the usage; and 4) prior to determining the update, the operations further include identifying at least one spending agreement with at least one merchant for extending credit, wherein determining the update is further based on the identified at least one spending agreement.
[0078] 5 is a block diagram of a computer system 500 suitable for implementing one or more components in FIG. 1 , according to an embodiment. In various embodiments, the communication device may include a personal computing device (e.g., a smartphone, a computing tablet, a personal computer, a laptop computer, a wearable computing device such as eyeglasses, a watch, a Bluetooth device, a key fob, a badge, etc.) capable of communicating over a network. The service provider may utilize a network computing device (e.g., a network server) capable of communicating over a network. It should be understood that each of these devices utilized by the user and the service provider may be implemented as computer system 500 in the following manner.
[0079] The computer system 500 includes a bus 502 or other communication mechanism for communicating information, data, signals, and information between various components of the computer system 500. Components include an input / output (I / O) component 504 that processes user actions, such as selecting a key from a keypad / keyboard, selecting one or more buttons, images, or links, and / or moving one or more images, and sends corresponding signals to the bus 502. The I / O component 504 may also include a display device 511 and cursor control 513 (e.g., keyboard, keypad, mouse, etc.). An optional audio input / output component 505 may also be included to convert audio signals, thereby allowing a user to input information using their voice. The audio I / O component 505 may enable a user to hear audio. A transceiver or network interface 506 transmits and receives signals over the network 150 between the computer system 500 and other devices, such as other communication devices, service devices, or service provider servers. In one embodiment, transmission is wireless; other transmission media and methods may also be appropriate. One or more processors 512, which may be a microcontroller, digital signal processor (DSP), or other processing component, process these various signals for display on the computer system 500 or for transmission to other devices via a communications link 518. The processor 512 may also control the transmission of information such as cookies or IP addresses to other devices.
[0080] 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 certain operations by processor 512 and other components by executing one or more sequences of instructions contained in system memory component 514. Logic may be encoded in a computer-readable medium, which may refer to any medium that participates in providing instructions to processor 512 for execution. Such media may take a variety of 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 storage devices such as system memory component 514, and transmission media include coaxial cables, copper wire, and fiber optics, 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 wave, optical, and infrared data communications.
[0081] Some common forms of computer readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tape, any other magnetic media, CD-ROMs, any other optical media, punch cards, paper tape, any other physical media with a pattern of holes, RAM, PROM, EEPROM, FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer can read.
[0082] In various embodiments of the present disclosure, execution of the instruction sequences for carrying out the present disclosure may be performed by computer system 500. In various other embodiments of the present disclosure, multiple computer systems 500 connected to a network (e.g., a network including a LAN, WLAN, PTSN, and / or various other wired or wireless telecommunications networks, mobile networks, and cellular networks) by communications links 518 may cooperate with each other to execute the instruction sequences for carrying out the present disclosure.
[0083] Where applicable, various embodiments provided in this disclosure may be implemented using hardware, software, or a combination of hardware and software. Also, where applicable, various hardware and / or software components disclosed herein may be combined into composite components including software, hardware, and / or both without departing from the spirit of the disclosure. Where applicable, various hardware and / or software components disclosed herein may be separated into subcomponents including software, hardware, or both without departing from the spirit of the disclosure. Additionally, where applicable, it is contemplated that software components may be implemented as hardware components, and vice versa.
[0084] In accordance with this 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 specified herein may be implemented using one or more general-purpose or special-purpose computers and / or computer systems, in networked and / or other configurations. Where applicable, the order of the various steps described herein may be changed, combined into multiple steps, and / or separated into substeps to provide the features disclosed herein.
[0085] The foregoing disclosure is not intended to limit the disclosure to the precise form or particular field of use disclosed. Accordingly, various alternative embodiments and / or modifications to the disclosure, whether express or implied herein, are contemplated as possible in light of the present disclosure. With the embodiments of the disclosure so disclosed, those skilled in the art will appreciate that changes in form and detail may be made without departing from the scope of the present disclosure. Accordingly, the present disclosure is limited only by the claims.
Claims
1. 1. A system comprising: non-transient memory, and 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; The operation is Detecting changes to interface elements input by a user via a service provider application on the user's user device; 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 for the user with respect to a merchant; accessing information associated with said merchants and said service providers; calculating, using an artificial intelligence (AI) engine, a second spending limit that is different from the first spending limit based on the changes and the information; generating an interface output of a user interface of the application based on the calculated second spending limit amount; and updating the application with the interface output prior to launching the application on the user device of the user via an application programming interface (API) of the application; Including, system.
2. 2. The system of claim 1, wherein the operation comprises: receiving an electronic transaction processing request for the transaction; determining that the transaction violates the calculated second spending limit; and rejecting the electronic transaction processing request via the API; Further comprising: system.
3. 2. The system of claim 1, wherein the operation comprises: causing the application to display an option to adjust the spending limit to utilize less than the calculated maximum second spending limit; receiving a request to adjust the calculated second spending limit amount; and adjusting the calculated second spending limit amount available via the application using the API; Further comprising: system.
4. 4. The system of claim 3, the options include a slide interface button available to adjust the calculated second spending limit amount via the application using the interface output. system.
5. 10. The system of claim 1, calculating the second spending limit includes pre-calculating a plurality of states of the application to be loaded into the application via the transmitting prior to launching the application on the user device; system.
6. 10. The system of claim 1, Calculating the second spending limit is further based on updating at least a portion of the user data and expiration of a time period associated with the electronic budget. system.
7. 10. The system of claim 1, the first spending limit and the second spending limit each include a transaction type limit based on one or more merchant category codes (MCCs) for the merchant; system.
8. 10. The system of claim 1, the calculated second spending limit includes an installment plan option for the calculated second spending limit that is variable via one or more interface elements in the application; system.
9. 9. The system of claim 8, the installment plan includes a plurality of payment parameters based on a user payment history for the user having the user data, and the application displays a plurality of options for the installment plan based on the user payment history. system.
10. 10. The system of claim 1, the updating includes rendering a dynamic spending limit graphical element in the interface, the dynamic spending limit graphical element identifying the spending limit amount that was pre-calculated prior to the rendering on the user device. system.
11. 1. A method comprising: Detecting utilization of a spending limit available to the user with respect to a merchant via an application on the user's user device; determining user data for the user and merchant data for the merchant; calculating, using a rules-based engine, a revised spending limit available to the user with respect to 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 via the application; and automatically updating data for an interface on the user device via the API with the revised spending limit; Including, method.
12. 12. The method of claim 11, automatically updating the data includes adjusting spending animations for the revised spending limit in the interface to purchasing interfaces available for one or more merchants for installment plans. method.
13. 13. The method of claim 12, the spending animation includes a movable payment button for the installment plan configurable by the user via the interface with the application; method.
14. 12. The method of claim 11, the revised maximum amount available for spending limit includes a credit limit established for the user based on one or both of a budget or a regulatory threshold amount associated with the merchant; method.
15. 12. The method of claim 11, the revised spending limit is determined and set via the data prior to loading of the application on the user device; method.
16. A non-transitory machine-readable medium having stored thereon a plurality of machine-readable instructions executable to cause a machine to perform operations, the operations comprising: displaying, via a user interface in the application on the user's device via an application programming interface (API) of the application, a first interface element associated with the first spending limit granted to the user by a service provider based on user data for the user, a merchant agreement with a merchant, and regulatory parameters associated with the first spending limit granted to the user; determining updates 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; updating and displaying, via the user interface via the API, the second spending limit granted to the user in the application prior to launching the application on the device; and monitoring the application for usage of the second spending limit via the API; Including, Non-transitory machine-readable media.
17. 17. The non-transitory machine-readable medium of claim 16, said determining utilizing a rules-based calculation engine. Non-transitory machine-readable media.
18. 20. The non-transitory machine-readable medium of claim 17, the rules-based calculation engine includes at least one machine learning (ML) model trained to proactively update a plurality of spending limits utilized by the application based on the updates; Non-transitory machine-readable media.
19. 17. The non-transitory machine-readable medium of claim 16, wherein the operation comprises: detecting use of at least a portion of the updated spending limit based on the monitoring; and adjusting the second spending limit in the application via the API based on the detecting; Further comprising: Non-transitory machine-readable media.
20. 17. The non-transitory machine-readable medium of claim 16, updating and displaying the second spending limit includes updating a scrollable interface element configured to automatically change the second spending limit based on user input of the user. Non-transitory machine-readable media.