Description:FIELD
[0001] Various embodiments of the disclosure relate generally to validation of payment modes. More specifically, various embodiments of the disclosure relate to methods and systems for validation of payment modes to avail services.
BACKGROUND
[0002] Advancement of technology has led to large-scale digitization that include subscription-based services. To avail such subscription-based services, merchants onboard payment modes associated with various users. The merchants deduct a subscription amount associated with a service from a payment mode after a defined time period. Merchants offering such subscription-based services gauge the credibility of a user to make a payment for the subscription amount via the payment mode after the defined time period based on a current status of the payment mode at the time of offering the service. The current status of the payment mode indicates whether the payment mode is valid or invalid. If the current status indicates that the payment mode is valid, the payment mode may be onboarded by the merchants for providing the subscription-based service to the user. However, at the end of the defined time period, the current status of the payment mode may indicate that the payment mode is invalid thereby resulting in the transactions at the end of the defined time period being declined. Thus, merchants relying solely on the current status of the payment mode at the time of onboarding the payment mode experience a failure of transactions at the end of the defined time period. In addition, unsuccessful payment transactions cause processing overhead in payment transaction networks.
[0003] In light of the foregoing, there exists a need for a technical and reliable solution that overcomes the abovementioned problems and validates payment modes to avail services.
SUMMARY
[0004] Methods and systems for validating payment modes to avail services are provided substantially as shown in and described in connection with, at least one of the figures, as set forth more completely in the claims.
[0005] In an embodiment of the present disclosure, a method to validate a payment mode for availing services is provided. The method includes receiving by a processor associated with a server, from a merchant device of a merchant, an account status inquiry (ASI) transaction request prior to onboarding a target payment mode of a user for a service. The ASI transaction request includes an identifier of the target payment mode, an amount to be charged to the target payment mode in a future payment transaction for the service, and a time period to perform the future payment transaction. The method further includes computing by the processor for a plurality of features, a first plurality of feature values of the target payment mode based on historical transaction data of the target payment mode. The plurality of features are correlated with a payment behavior trend of the target payment mode and a plurality of payment modes. The method further includes providing by the processor, the amount, the time period, and the first plurality of feature values as an input to a trained artificial intelligence model associated with the server. The method further includes receiving by the processor, as an output of the trained artificial intelligence model, a success score of the future payment transaction when performed within the time period to charge the amount to the target payment mode. The trained artificial intelligence model generates the success score based on a comparison of the first plurality of feature values with a second plurality of feature values of the plurality of payment modes. The method further includes communicating by the processor to the merchant device, an ASI transaction response that includes the success score of the future payment transaction. The target payment mode is onboarded or declined for the service based on the success score indicated by the ASI transaction response.
[0006] In another embodiment of the present disclosure, a server to validate a payment mode for availing services is provided. The server includes a memory that is configured to store a trained artificial intelligence model, and a processor. The processor is configured to receive an account status inquiry (ASI) transaction request prior to onboarding a target payment mode of a user for a service from a merchant device of a merchant. The ASI transaction request includes an identifier of the target payment mode, an amount to be charged to the target payment mode in a future payment transaction for the service, and a time period to perform the future payment transaction. The processor is further configured to compute a first plurality of feature values of the target payment mode for a plurality of features, based on historical transaction data of the target payment mode. The plurality of features are correlated with a payment behavior trend of the target payment mode and a plurality of payment modes. Further, the processor is configured to provide the amount, the time period, and the first plurality of feature values as an input to the trained artificial intelligence model. The processor is further configured to receive a success score of the future payment transaction when performed within the time period to charge the amount to the target payment mode as an output of the trained artificial intelligence model. The trained artificial intelligence model generates the success score based on a comparison of the first plurality of feature values with a second plurality of feature values of the plurality of payment modes. The processor is further configured to communicate an ASI transaction response that includes the success score of the future payment transaction to the merchant device. The target payment mode is onboarded or declined for the service based on the success score indicated by the ASI transaction response.
[0007] In some embodiments, the method includes comparing the first plurality of feature values with the second plurality of feature values, identifying a plurality of similar payment modes from the plurality of payment modes based on the comparison of the first plurality of feature values with the second plurality of feature values, analyzing the plurality of similar payment modes based on the amount and the time period associated with the future payment transaction, and generating a success trend based on the analysis. The aforementioned steps are performed by the trained artificial intelligence model. The success score is generated based on the success trend.
[0008] In some embodiments, the success score varies with a variation in the amount and the time period associated with the future payment transaction.
[0009] In some embodiments, the method includes generating by the processor, the plurality of features based on historical transaction data of the plurality of payment modes. The plurality of features include at least one of a plurality of amounts of a plurality of transactions in a time duration, a number of approved transactions in the time duration, a number of declined transactions in the time duration, a number of approved transactions after latest non-sufficient fund (NSF) transaction, a number of declined transactions after latest NSF transaction, and a time duration between consecutive NSF transactions.
[00010] In some embodiments, the method includes generating by the processor, the plurality of features based on historical transaction data of the plurality of payment modes. The plurality of features include at least one of a number of approved transactions with similar type of merchants, a number of declined transactions with the similar type of merchants, a number of approved transactions for a plurality of amount ranges, and a number of declined transactions for the plurality of amount ranges.
[00011] In some embodiments, the method includes training, by the processor, a first artificial intelligence model based on historical transaction data of the plurality of payment modes, to obtain the trained artificial intelligence model.
[00012] In some embodiments, the method includes storing, by the processor, historical transaction data of the plurality of payment modes, the historical transaction data of the target payment mode, the plurality of features, the first plurality of feature values, and the second plurality of feature values in a memory associated with the server.
[00013] In some embodiments, the target payment mode is a payment card.
[00014] In some embodiments, the target payment mode is one of a digital wallet and a unified payment interface (UPI).
BRIEF DESCRIPTION OF THE DRAWINGS
[00015] FIG. 1 is a block diagram that illustrates a system environment for facilitating validation of payment modes to avail services, in accordance with an exemplary embodiment of the present disclosure;
[00016] FIG. 2 is a block diagram that illustrates a payment network server of the system environment of FIG. 1, in accordance with an exemplary embodiment of the present disclosure;
[00017] FIG. 3A is a block diagram that illustrates training of a first artificial intelligence model of the system environment of FIG. 1, in accordance with an exemplary embodiment of the present disclosure;
[00018] FIG. 3B is a block diagram that illustrates implementation of a trained artificial intelligence model obtained after training the first artificial intelligence model of FIG. 3A, in accordance with an exemplary embodiment of the present disclosure;
[00019] FIG. 4 represents a process flow diagram that illustrates facilitation of validation of a target payment mode of the system environment of FIG. 1, in accordance with an exemplary embodiment of the present disclosure;
[00020] FIG. 5 is a block diagram that illustrates a system architecture of a computer system, in accordance with an exemplary embodiment of the present disclosure;
[00021] FIGS. 6A-6B, collectively, represent a flowchart that illustrates a method for validating the target payment mode for availing services by the payment network server of FIG. 2, in accordance with an exemplary embodiment of the present disclosure;
[00022] FIG. 7 represents a flowchart that illustrates a method for determining a success score using the trained artificial intelligence model of FIG. 3B, in accordance with an embodiment of the present disclosure; and
[00023] FIG. 8 represents a high-level flowchart that illustrates a method to validate a payment mode for availing services by the payment network server of FIG. 2, in accordance with an embodiment of the present disclosure.
DETAILED DESCRIPTION
[00024] The present disclosure is best understood with reference to the detailed figures and description set forth herein. Various embodiments are discussed below with reference to the figures. However, those skilled in the art will readily appreciate that the detailed descriptions given herein with respect to the figures are simply for explanatory purposes as the methods and systems may extend beyond the described embodiments. In one example, the teachings presented and the needs of a particular application may yield multiple alternate and suitable approaches to implement the functionality of any detail described herein. Therefore, any approach may extend beyond the particular implementation choices in the following embodiments that are described and shown.
[00025] References to “an embodiment”, “another embodiment”, “yet another embodiment”, “one example”, “another example”, “yet another example”, “for example”, and so on, indicate that the embodiment(s) or example(s) so described may include a particular feature, structure, characteristic, property, element, or limitation, but that not every embodiment or example necessarily includes that particular feature, structure, characteristic, property, element or limitation. Furthermore, repeated use of the phrase “in an embodiment” does not necessarily refer to the same embodiment.
OVERVIEW
[00026] Conventionally, a merchant providing services requests an account status inquiry (ASI) of an account associated with a payment mode to learn a status of the payment mode. The merchant receives a response for the ASI transaction request. The response indicates whether the payment mode is valid or invalid. If the response indicates that the payment mode is valid, the merchant onboards the payment mode to offer the service. Some merchants may deduct the amount from the payment mode after a defined time period that is determined by the merchant. As a result, when the merchant onboards the payment mode for a service based on the current status of the payment mode, a payment transaction requested by the merchant at the end of the defined time period may be declined if the status of the payment mode at the end of the time period may turn invalid. Thus, the merchant is unable to deduct the cost for providing the service to the user. Further, declined payment transactions cause processing overhead in payment transaction networks.
[00027] Various embodiments of the present disclosure provide a method and a system to resolve the aforementioned problem and validate a payment mode for availing services. The system includes a server (e.g., a payment network server) that receives an account status inquiry (ASI) transaction request from a merchant device of the merchant prior to onboarding a payment mode for a service. The ASI transaction request includes an identifier of the payment mode, an amount to be charged to the payment mode in a future payment transaction for the service, and a time period to perform the future payment transaction. Further, the server determines a likelihood of a successful future payment transaction based on a payment trend behavior of the payment mode and payment behaviors of a plurality of similar payment modes. The likelihood of a successful payment transaction is referred to as “the success score.” The success score is communicated to the merchant as a response to the ASI transaction request.
[00028] Thus, based on an amount and a time period of the future payment transaction that are specified by the merchant, the method and system of the present disclosure facilitate validation of the payment mode for the future payment transaction. The merchant receives an ASI transaction response that includes the success score which indicates a likelihood of the future payment transaction. The merchant may onboard or decline the payment mode based on the success score. As the payment modes with low success scores may be declined by the merchant, financial losses to the merchant are prevented and processing overhead in the payment transaction network is reduced.
TERMS DESCRIPTION (in addition to plain and dictionary meaning)
[00029] Account status inquiry (ASI) request refers to an inquiry regarding the status of an account associated with a payment mode such as a payment card, a unified payment interface (UPI), or a digital wallet. Conventionally, a response to an ASI specifies whether a payment mode is valid or invalid. Merchants request an ASI of a payment mode prior to onboarding the payment mode for a service. The ASI transaction request includes an identifier of a payment mode, an amount to be charged to the payment mode in a future payment transaction for a service, and a time period to perform the future payment transaction.
[00030] Server is a physical or cloud data processing system on which a server program runs. A server may be implemented in hardware or software, or a combination thereof. In one embodiment, the server is implemented as a computer program that is executed on programmable computers, such as personal computers, laptops, or a network of computer systems. The server may correspond to a merchant server, a payment gateway server, a digital wallet server, an acquirer server, a payment network server, or an issuer server.
[00031] Merchant is an entity that offers various products and/or services in exchange of payments. The merchant may establish a merchant account with a financial institution, such as a bank (hereinafter “acquirer bank”) to accept the payments from several users.
[00032] Issuer is a financial institution, such as a bank, where accounts of several users are established and maintained. The issuer ensures payment for approved transactions in accordance with various payment network regulations and local legislation.
[00033] Payment networks act as intermediate entities between acquirer banks and issuer banks to authenticate and fund transactions. In an embodiment, payment card associations are the payment networks. Examples of various payment card associations include MasterCard®, American Express®, VISA®, Discover®, Diners Club®, and the like. In another embodiment, third-party digital payment service providers are the payment networks. Examples of various third-party digital payment service providers include PAYPAL®, APPLE PAY®, Google Pay®, PhonePe®, and the like. Payment networks settle transactions between various acquirer banks and issuer banks.
[00034] Plurality of features for a payment mode is correlated with a payment behavior trend of the payment mode. The plurality of features may include at least one of a plurality of amounts of a plurality of transactions in a time duration, a number of approved transactions in the time duration, a number of declined transactions in the time duration, a number of approved transactions after latest non-sufficient fund (NSF) transaction, a number of declined transactions after latest NSF transaction, and a time duration between consecutive NSF transactions. The plurality of features may also include at least one of a number of approved transactions with a similar type of merchants, a number of declined transactions with the similar type of merchants, a number of approved transactions for a plurality of amount ranges, and a number of declined transactions for the plurality of amount ranges.
[00035] Artificial intelligence model refers to a model that creates and trains machine learning algorithms that emulate logical decision-making based on available data. The artificial intelligence model is trained using historical transaction data of payment modes to generate a likelihood of successful future payment transactions. Examples of the artificial intelligence model may include, but are not limited to, linear regression model, deep neural networks, decision trees, support vector machines, or the like.
[00036] Time period for the future payment transaction indicates a duration during which a merchant requests for the payment for providing a service to a user.
[00037] Success score indicates a likelihood of a successful future payment transaction for the given amount and time period. The value of the success score indicates whether the likelihood of a successful payment transaction is high or low. When the likelihood of the successful payment transaction is high, the merchant may onboard the payment mode for a service. Further, when the likelihood of the successful payment transaction is low, the merchant may decline the payment mode for the service.
[00038] Payment mode is utilized by an account holder to make payments from an associated account. Examples of the payment mode may include, but are not limited to, a payment card, a digital wallet, a unified payment interface (UPI), or the like.
[00039] Historical transaction data refers to transaction data of a payment mode stored over a period of time in a memory or database. Historical transaction data of a plurality of payment modes are used to train the artificial intelligence model to generate a success score for a future payment transaction using a payment mode.
[00040] ASI transaction response refers to a response generated for the ASI transaction request. The ASI transaction response includes at least the success score for the future payment transaction. The ASI transaction response may further include an alternate time and/or an alternate amount for the future payment transaction.
[00041] FIG. 1 is a block diagram that illustrates a system environment 100 for facilitating validation of payment modes to avail services, in accordance with an exemplary embodiment of the present disclosure. The system environment 100 includes a user 102, a payment mode 104, a user device 106, a merchant device 108, an acquirer server 110, a payment network server 112, an issuer server 114, a communication network 116, and a merchant 118.
[00042] The user 102 is an account holder of a first payment account maintained at a financial institution, such as an issuer. Examples of the first payment account may include a savings account, a current account, a debit account, a credit account, a digital wallet account, or the like. The user 102 owns a payment mode 104 that is linked to the first payment account. The payment mode 104 owned by the user 102 is hereinafter referred to as “the target payment mode 104.” In an embodiment, the user 102 may utilize the target payment mode 104 at the merchant device 108 to avail a service from the merchant 118. In another embodiment, the user 102 may utilize the target payment mode 104 via the user device 106, i.e., by entering details of the target payment mode 104 in an application or a webpage associated with the merchant 118, that is rendered on the user device 106, to avail the service from the merchant 118. Examples of the service may include, but are not limited to digital subscription-based service, purchase of a product, or the like. In an embodiment, the merchant 118 is a human being who provides a service to the user 102. In another embodiment, the merchant 118 is a business establishment that provides a service to the user 102. Examples of the business establishment may include business services, book stores, retail stores, restaurants, general merchandise, computer software stores, or the like. In a scenario, the user 102 may visit the business establishment, i.e., a physical shopping center, to avail a service such as purchasing an electronic device from the physical shopping center. The physical shopping center may be a computer software store. The user 102 may utilize the target payment mode 104 at the merchant device 108 that is present in the physical shopping center to purchase the electronic device. In another example, the user 102 may utilize the user device 106 to perform online shopping for the electronic device. An online shopping service application associated with the business establishment, may be installed on the user device 106 to render a user interface for providing an online shopping platform to the user 102. The user 102 may thus purchase the electronic device from the online shopping platform. Further, the user 102 may utilize the target payment mode 104 to perform payment for the purchase of the electronic device.
[00043] The target payment mode 104 is associated with the first payment account of the user 102. The target payment mode 104 is a medium that facilitates the user 102 to access the first payment account maintained at the financial institution. The target payment mode 104 is issued to the user 102 by the financial institution. The target payment mode 104 is associated with an identifier that serves as an identification of the target payment mode 104. The identifier may thus be a numeric value, an alphanumeric value, or an alphabetic value. The target payment mode 104 may be used by the user 102 to make payments for availing services. In an embodiment, the target payment mode 104 is a payment card. Further, the payment card may be either a physical payment card or a virtual payment card. Examples of the payment card include, but are not limited to, a credit card, a debit card, a prepaid card, a gift card, a rewards card, a loyalty points card, a frequent flyer miles card, or the like. When the target payment mode 104 is a physical payment card, the target payment mode 104 stores target payment mode details in a memory element (not shown) associated with the target payment mode 104. Further, when the payment card is a virtual payment card, the details of the virtual payment card may be stored electronically in a memory (not shown) of the user device 106. The target payment mode details may include at least one of an identifier of the target payment mode 104, a bank identification number associated with the target payment mode 104, an expiry date of the target payment mode 104, a card verification value of the target payment mode 104, a name of the user 102 that is associated with the target payment mode 104, a personal identification number (PIN), a password, or the like. In another embodiment, the target payment mode 104 is one of a digital wallet and a unified payment interface (UPI) that may be provided by a third-party digital payment service provider by way of a service application installed on the user device 106. When the target payment mode 104 is UPI, UPI details are stored in a memory associated with the service application that provides UPI as the target payment mode 104. The UPI details may include a UPI identifier, a PIN or a password, or the like. When the target payment mode 104 is a digital wallet, digital wallet details are stored in a memory associated with the service application that provides the digital wallet as the target payment mode 104. The digital wallet details may include a digital wallet identifier, a PIN or a password, or the like. For the sake of simplicity of the ongoing description, it is assumed that the target payment mode 104 is a payment card.
[00044] The user device 106 is a computing device of the user 102. Examples of the user device 106 may include, but are not limited to, a mobile phone, a computer, a laptop, a smartphone, a tablet, and a phablet. The user device 106 may be utilized by the user 102 for performing various payments. The user device 106 includes an input mechanism that allows the user 102 to input the target payment mode details in a service application or a webpage rendered on the user device 106, to avail the service. The input mechanism may include a touchscreen, a touch-sensitive display screen, a clickable button, a touch-sensitive button, a digital camera, or the like. In a scenario, the payment mode 104 is a payment card and the user 102 may utilize the user device 106 for performing online shopping of a service by way of the online shopping service application installed on the user device 106 or a webpage rendered on the user device 106. To perform a payment for the online shopping service, the user 102 may input by way of the input mechanism, the identifier associated with the target payment mode 104 in the service application or the webpage rendered on the user device 106. In such a scenario, the user device 106 may further receive authentication information associated with the target payment mode 104 such as a one-time password (OTP) or a PIN for approval of the transaction on the user device 106.
[00045] The user device 106 is further configured to execute or run a payment service application 120 to facilitate transactions. The payment service application 120 may be maintained by an issuer of the target payment mode 104 or a third-party digital payment service provider associated with the target payment mode 104. The payment service application 120 is downloaded and installed on the user device 106 by the user 102. The payment service application 120 may be configured to store login details such as a username and a password of the user 102. In a scenario, the user 102 may use the user device 106 to scan an optical code that may be presented on the merchant device 108 for performing a payment for a service availed at an entity associated with the merchant 118. In such a scenario, the payment may be performed by way of the payment service application 120. In another scenario, when the user 102 accesses a webpage or the online shopping service application associated with the merchant 118 for availing a service, the user 102 may input the identifier of the digital wallet or UPI on the webpage or the online shopping service application and perform the payment associated with the service by way of the payment service application 120.
[00046] The user device 106 is further configured to receive, from the issuer server 114, various transaction messages related to the transactions (such as payments) performed by way of the target payment mode 104. The user device 106 is further configured to present received transaction messages to the user 102. The received transaction messages indicate details of the transactions performed by the user 102 by way of the target payment mode 104. The details of the transactions may include indication of success or failure of the transaction, an amount associated with the transaction, and a mode of payment (such as payment card identifier, UPI identifier, or digital wallet identifier) for the transaction.
[00047] The merchant device 108 may include suitable logic, circuitry, interface, and/or code, executable by the circuitry, for facilitating validation of the target payment mode 104. The merchant device 108 is operated by the merchant 118. In one example, the merchant device 108 may be a Point-of-Sale (POS) device that is associated with the merchant 118. The merchant device 108 communicates with the target payment mode 104 in a contactless manner or by way of a contact established therebetween. In an exemplary scenario, when the target payment mode 104 is the physical payment card, the target payment mode 104 may be swiped on the merchant device 108 or tapped on the merchant device 108 for performing a payment for the service provided by the merchant 118 to the user 102. In another exemplary scenario, the details of the target payment mode 104 may be input to the merchant device 108 for availing the service from the merchant 118. In yet another exemplary scenario, the merchant device 108 may display an optical code. Further, the user 102 scans the optical code displayed on the merchant device 108 by way of the payment service application 120 installed on the user device 106 to avail the service from the merchant 118. The merchant device 108 further receives the target payment mode details from the user device 106. In an example, when the user 102 is performing online shopping by way of the user device 106, the target payment mode details entered on the user device 106 are received by the merchant device 108 via the communication network 116.
[00048] The merchant device 108 may be configured to transmit an account status inquiry (ASI) transaction request to the acquirer server 110 prior to onboarding the target payment mode 104 for the service. The ASI transaction request includes the identifier of the target payment mode 104, an amount to be charged to the target payment mode 104 in a future payment transaction for the service, and a time period to perform the future payment transaction. In an exemplary scenario, the user 102 visits the merchant 118 for purchasing a refrigerator. The merchant 118 is a consumer electronic merchant. The merchant 118 informs the user 102 of an installment payment option for purchasing the refrigerator. The user 102 decides to purchase the refrigerator on the installment payment option. Further, the merchant 118 utilizes the merchant device 108 to transmit the account status inquiry (ASI) transaction request to the acquirer server 110 prior to onboarding the target payment mode 104 for the installment payment option. The merchant 118 transmits the ASI transaction request to understand the likelihood of successful future payment transactions for the installments using the target payment mode 104. In another exemplary scenario, the user 102 inputs the target payment mode details to an over the top (OTT) service application installed on the user device 106 for availing OTT service from the merchant 118. The OTT service is associated with a subscription amount to be paid after a subscription period. The merchant device 108 receives the target payment mode details from the user device 106 and transmits the ASI transaction request to the acquirer server 110 prior to onboarding the target payment mode 104 for providing the OTT service. The ASI transaction request includes the identifier of the target payment mode 104, the subscription amount to be charged to the target payment mode 104 for the OTT service, and the time period to perform the future payment transaction for the OTT service. Further, the merchant device 108 receives a response for the ASI transaction request from the acquirer server 110. Examples of the merchant device 108 may include, but are not limited to, a Point-of-Purchase (POP) device, a Point-of-Interaction (POI) device, a cloud-based server, or the like.
[00049] The acquirer server 110 is a server arrangement which includes suitable logic, circuitry, interface, and/or code, executable by the circuitry, for processing transactions initiated by the merchant device 108. The transaction requests using the target payment mode 104 that are initiated at the merchant device 108 are received by the acquirer server 110. The acquirer server 110 is operated by an acquirer associated with the merchant device 108. The acquirer may be a financial institution. Thus, a payment account of the merchant 118 (i.e., a “second payment account”) is maintained at the acquirer. Based on the received transaction request, the acquirer server 110 further communicates with at least one of the payment network server 112 and the issuer server 114 for processing the transactions initiated at the merchant device 108. In an embodiment, the acquirer server 110 receives the ASI transaction request from the merchant device 108. The acquirer server 110 identifies the payment network server 112 associated with the target payment mode 104 and communicates with the payment network server 112 for processing the ASI transaction request. Based on the ASI transaction request, the acquirer server 110 receives an ASI transaction response from the payment network server 112. The acquirer server 110 transmits the ASI transaction response to the merchant device 108.
[00050] The issuer server 114 is a server arrangement which includes suitable logic, circuitry, interface, and/or code, executable by the circuitry, for processing various transactions. The issuer server 114 is operated by an issuer of the target payment mode 104. The issuer is a financial institution that manages one or more payment accounts of various users, e.g., the user 102. The issuer maintains a plurality of payment accounts. The plurality of payment accounts include the first payment account of the user 102. Details of the plurality of payment accounts established with the issuer are stored as account profiles. Each account profile may include payment transaction history of a corresponding user, details of one or more payment modes issued to the corresponding user, or the like. The issuer server 114 is configured to receive various transaction requests for processing transactions. A received transaction request may include details of a corresponding payment transaction such as a transaction amount, a timestamp of the payment transaction, details of a payment mode used for initiating the payment transaction, or the like.
[00051] When the target payment mode 104 is one of a payment card and UPI, the issuer server 114 may approve or decline the transaction based on payment transaction details and a balance amount in the first payment account. The payment transaction details may include the transaction amount, an identifier of the target payment mode 104, an account number of a payment account of the user 102, a name of an account holder i.e., the user 102, and the like. When the target payment mode 104 is the digital wallet, the issuer server 114 authenticates the target payment mode 104 based on the digital wallet details and approves or declines the transaction based on the payment transaction details and the balance amount in the first payment account. The issuer server 114 further credits, debits, or modifies the plurality of payment accounts of the users based on the approval of payment transactions.
[00052] In one embodiment, the issuer server 114 may be configured to receive the ASI transaction request from the payment network server 112 when the target payment mode 104 is a payment card. The issuer server 114 determines a current status of the target payment mode 104 upon receiving the ASI transaction request from the payment network server 112. The current status indicates that the target payment mode 104 is one of valid or invalid. In an exemplary scenario, the issuer server 114 checks if the target payment mode 104 in listed in a list of canceled, past due, or stolen payment modes. If the target payment mode 104 is listed in the list of canceled, past due, or stolen payment modes, the issuer server 114 determines that the current status of the target payment mode 104 is invalid. In another scenario, the issuer server 114 may check for a balance amount in the first payment account of the user 102. If the balance amount in the first payment account is below the minimum account balance, the issuer server 114 determines that the current status of the target payment mode 104 is invalid. In yet another scenario, the issuer server 114 may determine that the current status of the target payment mode 104 is valid. The current status of the target payment mode 104 is valid when the target payment mode 104 is not listed in the list of canceled, past due, or stolen payment modes and the first payment account maintained at the issuer has a minimum account balance. Further, the issuer server 114 transmits the determined current status of the target payment mode 104 to the payment network server 112. In an alternate embodiment, the issuer server 114 may be configured to receive the ASI transaction request from the acquirer server 110 when the target payment mode 104 is a digital wallet. Examples of the acquirer server 110 and the issuer server 114 may include, but are not limited to, computers, laptops, mini-computers, mainframe computers, any non-transient and tangible machines that may execute a machine-readable code, cloud-based servers, distributed server networks, a network of computer systems, or a combination thereof.
[00053] The payment network server 112 may include suitable logic, circuitry, interfaces, and/or code, executable by the circuitry that may be configured to perform one or more operations for validation of the payment modes. Examples of the one or more operations include, but are not limited to, determining a success score of a future payment transaction, maintaining transaction history of the payment modes across different merchants, or the like. The success score indicates a likelihood of a successful future payment transaction. Further, the payment network server 112 is operated by a payment card association, a third-party digital payment service provider, or the like. The payment network server 112 represents an intermediate entity between the issuer server 114 and the acquirer server 110 for processing the transactions. Examples of the payment network server 112 may include, but are not limited to, computers, laptops, mini-computers, mainframe computers, any non-transient and tangible machines that may execute a machine-readable code, cloud-based servers, distributed server networks, a network of computer systems, or a combination thereof.
[00054] The payment network server 112 receives the ASI transaction request from the merchant device 108 of the merchant 118 via the acquirer server 110, prior to onboarding the target payment mode 104 for the service. The payment network server 112 is configured to receive the target payment mode details by way of the ASI transaction request. In an embodiment, when the target payment mode 104 is a payment card, the payment network server 112 authenticates the target payment mode 104 based on the target payment mode details. When the payment network server 112 determines that the received target payment mode details match the target payment mode details that are stored in a memory (shown in FIG. 2), the payment network server 112 transmits the ASI transaction request to the issuer server 114. When the payment network server 112 determines that the target payment mode details do not match the target payment mode details that are stored in the memory 204, the payment network server 112 declines the ASI transaction request. In another embodiment, when the target payment mode 104 is UPI, the payment network server 112 authenticates the target payment mode 104 based on the UPI details. When the payment network server 112 determines that the UPI details match the UPI details that are stored in the memory 204, the payment network server 112 transmits the ASI transaction request to the issuer server 114. When the payment network server 112 determines that the UPI details do not match the UPI details that are stored in the memory (shown in FIG. 2), the payment network server 112 declines the ASI transaction request. In an embodiment, the payment network server 112 may further determine if the target payment mode 104 is listed in a list of canceled, past due, or stolen payment modes. If the target payment mode 104 is listed in the list of canceled, past due, or stolen payment modes, the payment network server 112 determines that the current status of the target payment mode 104 is invalid.
[00055] The payment network server 112 extracts historical transaction data of the target payment mode 104 from the memory (shown in FIG. 2) associated with the payment network server 112 based on the identifier of the target payment mode 104. The historical transaction data of the target payment mode 104 may include successful payment transactions, declined payment transactions, ASI transaction requests, and the like. The payment network server 112 is configured to train/re-train an artificial intelligence model 122 for determination of the likelihood of successful future payment transaction based on the historical transaction data of the target payment mode 104. The artificial intelligence model 122 is referred to as the “first artificial intelligence model 122” before training. Further, the artificial intelligence model 122 is referred to as the “trained artificial intelligence model 122” after training the first artificial intelligence model 122. Thus, the trained artificial intelligence model 122 is obtained after training the first artificial intelligence model 122.
[00056] The payment network server 112 receives the current status of the target payment mode 104 from the issuer server 114. When the current status of the target payment mode 104 indicates that the target payment mode 104 is valid, the payment network server 112 determines the success score for the future payment transaction. Further, the payment network server 112 notifies the merchant 118 regarding the likelihood of the future payment transaction associated with the ASI transaction request by way of the ASI transaction response. The payment network server 112 communicates the ASI transaction response that includes the success score that indicates the likelihood of the successful future payment transaction to the merchant device 108 via the acquirer server 110. When the current status of the target payment mode 104 indicates that the target payment mode 104 is invalid, the payment network server 112 communicates the ASI transaction response that includes the current status of the target payment mode 104 to the merchant device 108.
[00057] In an embodiment, the payment network server 112 may determine whether the merchant 118 is fraudulent after receiving the ASI transaction request from the merchant device 108. In a scenario, the payment network server 112 may maintain a list of fraudulent merchants based on past fraudulent behaviors of merchants. Further, the payment network server 112 may check if the merchant 118 is listed in the list of fraudulent merchants to verify the merchant 118. In another scenario, the payment network server 112 may provide a verification message associated with the verification of the merchant 118 to the user device 106.The verification message may include a name of the merchant 118 and transaction details associated with the ASI transaction request. Further, the user 102 may communicate a user response for the verification message via the user device 106 to the payment network server 112. The user response may indicate whether the user 102 provides an approval for the transaction with the merchant 118. The payment network server 112 declines the ASI transaction request when the payment network server 112 determines that the merchant 118 is fraudulent or the user 102 has declined the transaction with the merchant 118 based on the verification message. Thus, when the merchant 118 is fraudulent, the merchant device 108 does not receive the success score for the future payment transaction in the ASI transaction response from the payment network server 112. Operations of the payment network server 112 are explained in detail in conjunction with FIG. 2.
[00058] The communication network 116 facilitates communication between the user device 106, the merchant device 108, the acquirer server 110, the payment network server 112, and/or the issuer server 114. Examples of the communication network 116 include, but are not limited to, a Wi-Fi network, a light fidelity (Li-Fi) network, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a satellite network, the Internet, a fiber optic network, a coaxial cable network, an infrared (IR) network, a radio frequency (RF) network, and combinations thereof. Various entities in the system environment 100 may connect to the communication network 116 in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), Long Term Evolution (LTE) communication protocols, or any combination thereof.
[00059] In operation, the user 102 provides the target payment mode details to the merchant device 108 for availing a service from the merchant 118. In one embodiment, the user 102 may input the target payment mode details to the user device 106 for availing the service from the merchant 118. In another embodiment, the merchant 118 may input the target payment mode details to the merchant device 108. For the sake of ongoing explanation, it is assumed that the user 102 inputs the target payment mode details in the user device 106. In an example, the user 102 may input the target payment mode details in an online shopping service application on the user device 106 for availing an OTT service. Thus, the online shopping service application is an OTT service application. A user interface rendered on the user device 106 by the online shopping service application may facilitate the user 102 for inputting the target payment mode details. The target payment mode details input in the user device 106 is received by the merchant device 108 associated with the online shopping service application. In the example, the user interface rendered on the user device 106 by the OTT service application may facilitate the user 102 for inputting the target payment mode details. The target payment mode details input to the user device 106 are received by the merchant device 108 associated with the OTT service application. Based on the received target payment mode details, the merchant device 108 generates the ASI transaction request prior to onboarding the target payment mode 104 for the service. The ASI transaction request includes the identifier of the target payment mode 104, the amount to be charged for the service for the future payment transaction, and the time period for performing the future payment transaction. In the example, the subscription period for the availing the OTT service is two months (say April and May 2023) and a subscription amount of 200$ is offered to the user 102 on March 01, 2023. Thus, the amount that is charged to the user 102 for the future payment transaction is 200$ and the time period for performing the future payment transaction is 9 AM to 9 PM on the last day of May 2023 (i.e., May 31, 2023).
[00060] The merchant device 108 transmits the ASI transaction request to the acquirer server 110. The acquirer server 110 transmits the ASI transaction request to the payment network server 112. The payment network server 112 authenticates the target payment mode 104 based on the ASI transaction request. Further, the payment network server 112 transmits the ASI transaction request to the issuer server 114 based on the authentication. The issuer server 114 determines the current status of the target payment mode 104 upon receiving the ASI transaction request. The current status of the target payment mode 104 indicates whether the target payment mode 104 is valid or invalid. The issuer server 114 determines that the current status of the target payment mode 104 is invalid when the target payment mode 104 is listed in the list of canceled, past due, or stolen payment modes and/or balance amount in the first payment account is below the minimum account balance. The issuer server 114 determines that the current status of the target payment mode 104 is valid when the target payment mode 104 is not listed in the list of canceled, past due, or stolen payment modes and the balance amount in the first payment account is not below the minimum account balance. Further, the issuer server 114 transmits the current status of the target payment mode 104 to the payment network server 112.
[00061] When the payment network server 112 identifies that the target payment mode 104 is valid based on the current status, the payment network server 112 determines the success score for the future payment transaction by utilizing the trained artificial intelligence model 122. The success score indicates the likelihood of the future payment transaction being successful. In other words, the success score indicates a probability of the user 102 being able to perform a successful future payment transaction using the target payment mode 104. In an example, the success score may be a value between 0 and 1, where 1 indicates highest probability of the future payment transaction being successful and 0 indicates lowest probability of the future payment transaction being successful. The payment network server 112 communicates the ASI transaction response that includes the determined success score for the future payment transaction to the merchant device 108 via the acquirer server 110. The success score may be displayed on the merchant device 108 as an indication to the merchant 118 whether the user 102 may be able to perform successful future payment transaction using the target payment mode 104.
[00062] The merchant 118 may decide to onboard the target payment mode 104 for providing the service based on the success score. In the example, the merchant 118 may decide to onboard the target payment mode 104 for providing the OTT service based on the success score. The merchant 118 onboards the target payment mode 104 for the service based on the success score being above a first threshold value. In an example, the first threshold value is 0.7. If the success score is above the first threshold value, say 0.9, the user 102 is able to avail the OTT service after the merchant 118 onboards the target payment mode 104 for the OTT service. When the success score is below the first threshold value, say 0.6, the merchant 118 may decline the target payment mode 104 for the OTT service. When the merchant 118 onboards the target payment mode 104 for the service, the amount for the future payment transaction is deducted during the time duration mentioned in the ASI transaction request.
[00063] The payment network server 112 may further be configured to determine at least one of an alternate time period and an alternate amount for the future payment transaction based on the success score being lower than the first threshold value. The alternate time period and the alternate amount have more likelihood of a successful future payment transaction as compared to the time duration mentioned in the ASI transaction request. The alternate time period and the alternate amount are determined by way of the trained artificial intelligence model 122 as explained in FIG. 2. In one embodiment, the payment network server 112 communicates the ASI transaction response that includes the alternate time period and the success score associated with the alternate time period to the merchant device 108. In another embodiment, the payment network server 112 communicates the ASI transaction response that includes the alternate amount and the success score associated with the alternate amount to the merchant device 108.
[00064] The user 102 may be required to use a payment mode other than the target payment mode 104 to avail the service when the merchant 118 declines the target payment mode 104 based on the success score. Further, the merchant device 108 may transmit an ASI transaction request for another payment mode of the user 102 to receive the ASI transaction response. The payment network server 112 may determine a success score for the future payment transaction using the other payment mode similar to determination of the success score for the future payment transaction using the target payment mode 104. It will be understood by a person skilled in the art that the user 102 may avail a plurality of services from the merchant 118 at the same time or different time instances for future payment transactions. In addition, the user 102 may avail a plurality of services from various merchants for future payment transactions.
[00065] FIG. 2 is a block diagram that illustrates the payment network server 112, in accordance with an exemplary embodiment of the present disclosure. The payment network server 112 includes a processor 202, a memory 204, and a network interface 206.
[00066] The processor 202 includes suitable logic, circuitry, interfaces, and/or code for performing various operations to facilitate validation of the target payment mode 104. The operations performed by the processor 202 include training the first artificial intelligence model 122, determining the success score of the future payment transaction when performed within the time period to charge the amount to the target payment mode 104, and the like. Examples of the processor 202 may include, but are not limited to, an application-specific integrated circuit (ASIC) processor, a reduced instruction set computer (RISC) processor, a complex instruction set computer (CISC) processor, a field programmable gate array (FPGA), a central processing unit (CPU), or the like.
[00067] The payment network server 112 facilitates transactions for a plurality of payment modes. Each payment mode of the plurality of payment modes may be issued by a corresponding issuer that may be similar or different to the issuer that issues the target payment mode 104. Further, each payment mode of the plurality of payment modes may be functionally similar to the target payment mode 104 and associated with a corresponding payment account maintained by the issuer. In addition, each of the plurality of payment modes may be owned by a corresponding user. In an exemplary scenario, one user may own more than one payment mode of the plurality of payment modes. Each user thus utilizes a corresponding payment mode to perform a specific transaction. In an embodiment, the plurality of payment modes includes the target payment mode 104. The payment network server 112 records the transactions associated with each of the plurality of payment modes and stores the recorded transactions as historical transaction data 208 of the plurality of payment modes in the memory 204. The transactions recorded by the payment network server 112 may include approved transactions, declined transactions, ASI transaction requests, and the like. In an example, the payment network server 112 is Mastercard®.
[00068] The processor 202 is configured to generate a plurality of features based on the historical transaction data 208 stored in the memory 204. The historical transaction data 208 may include data associated with each transaction that have been performed in the past by way of the plurality of payment modes. The historical transaction data 208 may further include an amount associated with each transaction, merchant data associated with each transaction, the time of each transaction, and the like. The merchant data may include details of the merchant, a type of service offered by the merchant, or the like. In an example, a first transaction is performed by way of the target payment mode 104. The first transaction may be availing an OTT service from a service provider, i.e., the merchant 118 that offers the service. Thus, the amount associated with the first transaction is 150$, the details of the merchant may be a name of the entity offering the service such as Netflix®, the type of service is OTT service, and the time of transaction is 9 PM on December 10, 2018.
[00069] The plurality of features may include at least one of a plurality of amounts of a plurality of transactions in a time duration, a number of approved transactions in the time duration, a number of declined transactions in the time duration, a number of approved transactions after latest non-sufficient fund (NSF) transaction, a number of declined transactions after latest NSF transaction, and a time duration between consecutive NSF transactions. The plurality of amounts of a plurality of transactions in a time duration refers to an amount of money transacted for each transaction occurring in the time duration. The plurality of payment modes may include a first payment mode, a second payment mode, a third payment mode, a fourth payment mode, and so on up to an nth payment mode. In an example, the number of transactions occurring in February 2022 by way of the first payment mode are three and the amount associated with each such transaction is 50$, 60$, and 100$. Thus, the plurality of amounts are 50$, 60$, and 100$ and the plurality of transactions are three. The number of approved transactions in the time duration refers to a number of successful payment transactions in a given time period. In an example, the user 102 performs five transactions in January 2023 of which three transactions are approved. Thus, the number of approved transactions are three. The transactions may be approved based on the maintenance of a balance amount in a payment account associated with a payment mode utilized for the transaction. A number of declined transactions in the time duration indicates the number of transactions that are declined by an issuer associated with a payment mode that is utilized for performing the transaction. A number of approved transactions after latest NSF transaction and a number of declined transactions after latest NSF transaction indicates approval and decline of transactions that occur instantly after a non-sufficient fund-based transaction, i.e., the transactions that are declined due to insufficient amount in the corresponding payment account. In an example, one transaction is approved after the latest NSF transaction and three transactions are declined after the latest NSF transaction. In the example, a time duration between two consecutive NSF transactions may be thirty five days.
[00070] The transactions may be declined by an issuer server (such as the issuer server 114) based on at least one of NSF in a corresponding payment account associated with a payment mode, a corresponding payment mode being reported as stolen or lost, and the like. In an example, the transaction amount is 500$ and the amount in the corresponding payment account is 300$. Thus, the transaction is declined due to NSF in the corresponding payment account. The transactions may be declined by the payment network server 112 based on incorrect payment mode details such as incorrect target payment mode details. In an example, the transaction is declined as the payment mode details such as an expiry date of the payment mode provided by a user is incorrect.
[00071] The plurality of features may further include at least one of a number of approved transactions with a similar type of merchants, a number of declined transactions with the similar type of merchants, a number of approved transactions for a plurality of amount ranges, and a number of declined transactions for the plurality of amount ranges. In an embodiment, merchants providing similar type of services are considered as similar type of merchants. In an example, merchants providing OTT service are considered as similar type of merchants, merchants associated with grocery stores are considered as similar type of merchants, merchants providing internet services are considered as similar type of merchants, or the like. In another embodiment, merchants providing service in a specific amount range are considered as the similar type of merchants. In an exemplary scenario, the merchants who provide services in an amount range of 300$-500$ are considered as the similar type of merchants, the merchants who provide services in an amount range of 1000$-1500$ are considered as similar type of merchants, or the like. In an example, a number of approved transactions for similar type of merchants, i.e., for merchants providing internet services is ten, in a time duration of six months. In another example, the user 102 performs ten different transactions by way of the target payment mode 104 with ten different merchants and each such transaction is approved by the issuer. In another example, the number of declined transactions for similar type of merchants such as the merchants providing internet services is three in a time duration of six months.
[00072] A number of approved transactions for a plurality of amount ranges indicates the number of transactions which a user such as the user 102 performs by way of a payment mode such as the target payment mode 104 and that are approved by the issuer server such as the issuer server 114. The plurality of amount ranges in the plurality of features may include a first amount range, a second amount range, a third amount range, and so on up to an nth amount range. In an example, the first amount range is from 100$-500$, the second amount range is from 600$-1000$, and the third amount range is from 1100$-2000$. The issuer server such as the issuer server 114 may approve such transactions as the amount associated with each transaction is maintained in the payment account of the user 102.
[00073] A number of declined transactions for a plurality of amount ranges indicates the number of transactions which a user such as the user 102 performs by way of a payment mode such as the target payment mode 104 and that are declined by the issuer server such as the issuer server 114 for various amount ranges. In an example, the number of declined transactions in the first amount range of 10000$-50000$ is five in a time duration of two months and the number of declined transactions in the second amount range of 600000$-100000$ is two transactions in a time duration of three months.
[00074] Although it is described that the plurality of features include at least one of the plurality of amounts of a plurality of transactions in the time duration, the number of approved transactions in the time duration, the number of declined transactions in the time duration, the number of approved transactions after latest non-sufficient fund (NSF) transaction, the number of declined transactions after latest NSF transaction, the time duration between consecutive NSF transactions, the number of approved transactions with the similar type of merchants, the number of declined transactions with the similar type of merchants, the number of approved transactions for the plurality of amount ranges, and the number of declined transactions for the plurality of amount ranges, the scope of the present disclosure is not limited to it. In another embodiment, the plurality of features may include at least one of the plurality of amounts of a plurality of transactions in the time duration, the number of approved transactions in the time duration, the number of declined transactions in the time duration, the number of approved transactions after latest non-sufficient fund (NSF) transaction, the number of declined transactions after latest NSF transaction, and the time duration between consecutive NSF transactions. In yet another embodiment, the plurality of features may include at least one of the number of approved transactions with the similar type of merchants, the number of declined transactions with the similar type of merchants, the number of approved transactions for the plurality of amount ranges, and the number of declined transactions for the plurality of amount ranges.
[00075] The processor 202 computes a first plurality of feature values for the plurality of features based on the historical transaction data 208 of the plurality of payment modes. The first plurality of feature values include a first set of feature values, a second set of feature values, a third set of feature values, and so on up to an nth set of feature values. The first set of feature values is associated with the first payment mode, the second set of feature values is associated with the second payment mode, the third set of feature values is associated with the third payment mode, and so on. In an embodiment, the target payment mode 104 is the first payment mode and the first set of feature values is associated with the target payment mode 104. In an example, the first set of feature values of the first payment mode indicates that fifty transactions are performed in eight months, forty of the fifty transactions are approved, and ten of the fifty transactions are declined. Further, seven transactions are approved after latest NSF transaction, five transactions are declined after latest NSF transaction, and two months is the time duration between consecutive NSF transactions. The processor 202 stores the first plurality of feature values in the memory 204.
[00076] The processor 202 is configured to train the first artificial intelligence model 122 based on the historical transaction data 208 and the first plurality of feature values to determine the success score for the future payment transaction. The training of the first artificial intelligence model 122 is explained in detail in conjunction with FIG. 3A.
[00077] The processor 202 is further configured to extract the identifier of the target payment mode 104 upon receiving the ASI transaction request from the merchant device 108. Based on the extracted identifier, the processor 202 identifies the target payment mode 104 and computes a second plurality of feature values of the target payment mode 104 for the plurality of features based on the historical transaction data 208 of the target payment mode 104. In an example, the first artificial intelligence model 122 is trained on March 01, 2022 and the ASI transaction request associated with the target payment mode 104 is received on June 01, 2022. The second plurality of feature values may thus be based on the first set of feature values in addition to another set of feature values (similar to the first set of feature values) that are associated with transactions occurring by way of the target payment mode 104 from March 02, 2022 and May 31, 2022. In an example, the second plurality of feature values indicate that ninety transactions amounting to 90000$ are performed in a time duration of twenty-four months (i.e., from May 31 2020 to May 31, 2022), seventy of the ninety transactions are approved transactions, and twenty of the ninety transactions are declined transactions. In addition, eight transactions are approved after latest NSF transaction, six transactions are declined after latest NSF transaction, and thirty days is the time duration between consecutive NSF transactions. Further, the processor 202 extracts the amount associated with the future payment transaction and the time period for performing the future payment transaction from the ASI transaction request. In an example, the amount associated with the future payment transaction is 200$ and the time period to perform the future payment transaction is August 28, 2022 to August 31, 2022 for the ASI transaction request received on June 01, 2022.
[00078] The processor 202 provides the computed second plurality of feature values and the extracted amount and time period as an input to the trained artificial intelligence model 122. Further, the trained artificial intelligence model 122 generates the success score for the future payment transaction when performed within the time period to charge the amount to the target payment mode 104 based on the comparison of the second plurality of feature values with the first plurality of feature values. In an exemplary scenario, the success score is 0.9 out of 1 for the payment of 200$ during August 28, 2022 to August 31, 2022 where 1 is the highest probability of the future payment transaction being successful.
[00079] The processor 202 receives the success score of the future payment transaction from the trained artificial intelligence model 122. Further, the processor 202 communicates the ASI transaction response that includes at least the success score of the future payment transaction to the merchant device 108. Based on the received ASI transaction response, the merchant 118 onboards or declines the target payment mode 104 for the service. The merchant 118 may onboard the target payment mode 104 for the service when the success score is above the first threshold value.
[00080] In an embodiment, the trained artificial intelligence model 122 may output an alternate time period for the future payment transaction. The trained artificial intelligence model 122 determines that the alternate time period has more likelihood of successful future payment transaction. The alternate time period is determined based on successful payment transactions of payment modes similar to the target payment mode 104. The trained artificial intelligence model 122 thus determines that if the future payment transaction is performed in the alternate time period, the likelihood of successful future payment transaction is high. In an exemplary scenario, the time period for the future payment transaction specified in the ASI transaction request is August 28, 2022 to August 31, 2022. In such a scenario, the success score determined by the trained artificial intelligence model 122 is 0.6 out of 1. Further, the trained artificial intelligence model 122 may determine that the success score is 0.8 when the future payment transaction is performed between August 23, 2022 to August 25, 2022. The processor 202 communicates the ASI transaction response that includes the alternate time period and the success score associated with the alternate time period to the merchant device 108. The merchant 118 may consider the alternate time period mentioned in the ASI transaction response for the future payment transaction.
[00081] In another embodiment, the trained artificial intelligence model 122 may output an alternate amount for the future payment transaction. The alternate amount has more likelihood of successful future payment transaction. In an exemplary scenario, the amount for the future payment transaction specified in the ASI transaction request is 200$. In such a scenario, the success score determined by the trained artificial intelligence model 122 is 0.6 out of 1. Further, the trained artificial intelligence model 122 may determine that the success score is 0.8 when the amount associated with the future payment transaction is 150$. The processor 202 thus communicates the ASI transaction response that includes the alternate amount and the success score associated with the alternate amount to the merchant device 108. In an exemplary scenario, the ASI transaction response indicates that the alternate amount of 150$ has the success score of 0.8 for the future payment transaction. The merchant 118 may consider the alternate amount mentioned in the ASI transaction response and alter the service accordingly. Implementation of the trained artificial intelligence model 122 is explained in detail in conjunction with FIG. 3B.
[00082] The memory 204 may include suitable logic, circuitry, and/or interfaces for storing data that is required by one or more components of the processor 202 for executing a set of instructions to facilitate validation of the target payment mode 104. The memory 204 may be further configured to store the historical transaction data 208 of the plurality of payment modes and the trained artificial intelligence model 122. Examples of the memory 204 may include a random-access memory (RAM), a read-only memory (ROM), a removable storage drive, a hard disk drive (HDD), a flash memory, a solid-state memory, and the like. It will be apparent to a person skilled in the art that the scope of the disclosure is not limited to realizing the memory 204 in the payment network server 112, as described herein. In another embodiment, the memory 204 may be realized in form of a database server or a cloud storage working in conjunction with the payment network server 112, without departing from the scope of the disclosure.
[00083] The network interface 206 may include suitable logic, circuitry, interfaces, and/or code, executable by the circuitry, to transmit and receive data over the communication network 116 using one or more communication network protocols. The network interface 206 may receive and communicate messages and data from the user device 106, the merchant device 108, the acquirer server 110, and/or the issuer server 114. Examples of the network interface 206 may include, but are not limited to, an antenna, a radio frequency transceiver, a wireless transceiver, a Bluetooth transceiver, an ethernet port, or any other device configured to transmit and receive data.
[00084] Although it is described that the success score is determined by the payment network server 112, the scope of the present disclosure is not limited to it. In various other embodiments, a memory associated with the issuer server 114 may store the trained artificial intelligence model 122 and a processor associated with the issuer server 114 may determine the success score for the future payment transaction, without deviating from the scope of the present disclosure.
[00085] FIG. 3A represents a block diagram 300A that illustrates training of the first artificial intelligence model 122, in accordance with an exemplary embodiment of the present disclosure.
[00086] The processor 202 may be configured to input the historical transaction data 208 of the plurality of payment modes and the first plurality of feature values of the plurality of payment modes to the first artificial intelligence model 122. The historical transaction data 208 may include, for each of the plurality of payment modes, successful payment transactions, declined payment transactions, ASI transaction requests, merchant details associated with the transactions, time associated with the transactions, and the like. The first plurality of feature values of the plurality of payment modes is referred to as “the first plurality of feature values 302”. The first plurality of feature values 302 include the first set of feature values. In an example, the first set of feature values indicates that fifty transactions that correspond to 50000$ have occurred in a time duration of eight months of which forty transactions are approved and ten transactions are declined. Further, out of the forty transactions that are approved, seven transactions are approved after the latest NSF transaction and five of the ten transactions are declined after the latest NSF transaction. In addition, the time duration between consecutive NSF transactions is forty-five days.
[00087] The first artificial intelligence model 122 learns weights and biases for each historical transaction of each of the plurality of payment modes. The first artificial intelligence model 122 learns the weights and biases for each historical transaction of each of the plurality of payment modes based on an amount, a time associated with the historical transaction, a type of merchant, and a status of corresponding historical transaction. In an exemplary scenario, the amount associated with a historical transaction is 80$ and the time at which the transaction occurs is 6:30 PM on June 15, 2018. The first artificial intelligence model 122 learns to determine the success score for a future payment transaction based on the learnt weights and biases. The success score refers to a likelihood of the successful future payment transaction. The success score is referred to as “the success score 304”. During the training, the first artificial intelligence model 122 learns payment behavior trend of each payment mode of the plurality of payment modes. In an example, the payment behavior trend of the first payment mode may indicate that maximum transactions are performed during the first day to the tenth day of each month. In another example, the payment behavior trend of the second payment mode may indicate that transactions are declined during the twenty-fifth day to the twenty-ninth day of a month. The trained artificial intelligence model 122 is stored in the memory 204.
[00088] FIG. 3B represents a block diagram 300B that illustrates implementation of the trained artificial intelligence model 122 obtained after training the first artificial intelligence model 122, in accordance with an exemplary embodiment of the present disclosure. During the implementation of the trained artificial intelligence model 122, the processor 202 inputs the amount 306 associated with the future payment transaction, the time period 308 associated with the future payment transaction, and the second plurality of feature values 310 of the target payment mode 104 to the trained artificial intelligence model 122.
[00089] The trained artificial intelligence model 122 compares the second plurality of feature values 310 with the first plurality of feature values 302 and generates a similarity score for each of the plurality of features. A similarity score varies between 0 and 1 such that 0 indicates no similarity and 1 indicates complete similarity. As a result, the similarity score is generated for each of the plurality of features for each of the plurality of payment modes. A feature value of the second plurality of feature values 310 is considered similar to a feature value of the first plurality of feature values 302 based on the similarity score being above a second threshold value. In an example, the second threshold value is 0.7 and the feature value for the number of approved transactions in a time duration of twenty months is eighty-five in the second set of features of the second payment mode. Further, the feature value for the number of approved transactions in a time duration of twenty months is seventy-nine in the second plurality of feature values 310 of the target payment mode 104. Thus, the generated similarity score for the feature is 0.8. A feature of the plurality of features that has a similarity score greater than the second threshold value is a similar feature. Further, the trained artificial intelligence model 122 identifies a plurality of similar payment modes based on the similarity scores. A payment mode of the plurality of payment modes is considered as a similar payment mode when a number of similar features of the corresponding payment mode is greater than a third threshold value. In a scenario, the third threshold value is three, the second payment mode has four similar features, the third payment mode has two similar features, and the fourth payment mode has five similar features with the target payment mode 104. In such a scenario, the plurality of similar payment modes identified by the trained artificial intelligence model 122 includes the second payment mode and the fourth payment mode.
[00090] The trained artificial intelligence model 122 further analyzes the plurality of similar payment modes based on the amount 306 and the time period 308 associated with the future payment transaction to generate a success trend. The success trend is generated for each of the plurality of similar payment modes. The success trend of each of the plurality of similar payment modes represents successful and failed payment transactions. In an exemplary scenario, the amount 306 associated with the future payment transaction is 150$, and the time period 308 to perform the future payment transaction is January 25, 2023 to January 29, 2023 for the ASI transaction request transmitted on January 02, 2023 by the merchant device 108. In such a scenario, the success trend generated by the trained artificial intelligence model 122 may represent the approved transactions, the failed transactions, the ASI transaction requests associated with the successful and failed transactions of the similar payment modes for transactions in a range of 100$-200$ during January 25 to January 29 of past three years (such as the years 2020-2022). Further, the trained artificial intelligence model 122 generates the success score 304 for the future payment transaction when performed within the time period 308 to charge the amount 306 to the target payment mode 104 based on the success trend. In an example, the success score 304 generated by the trained artificial intelligence model 122 is 0.8 which implies that the likelihood of a successful future payment transaction of 150$ during January 25, 2023 to January 29, 2023 is 0.8 out of one, where one is the highest possibility of a successful future payment transaction. In another example, the success score 304 generated by the trained artificial intelligence model 122 is 70% which implies that the likelihood of successful future payment transaction of 150$ during January 25, 2023 to January 29, 2023 is 70% out of 100%, where 100% is the highest possibility of successful future payment transaction.
[00091] The success score 304 determined by the trained artificial intelligence model 122 varies with a variation in the amount 306 and the time period 308. In an exemplary scenario, when the amount 306 is 300$, the success score 304 for the future payment transaction is 0.9 out of 1 and when the amount 306 is 800$, the success score 304 for the future payment transaction is 0.4 out of 1. In another exemplary scenario, when the time period 308 is fifteen days from the day of receiving the ASI transaction request, the success score 304 for the future payment transaction is 0.9 out of 1 and when the time period 308 is twenty-five days from the day of receiving the ASI transaction request, the success score 304 for the future payment transaction is 0.5 out of 1.
[00092] FIG. 4 represents a process flow diagram 400 that illustrates facilitation of the validation of the target payment mode 104, in accordance with an exemplary embodiment of the present disclosure. The merchant device 108 transmits the ASI transaction request to the acquirer server 110 prior to onboarding the target payment mode 104 for the service (as shown by arrow 402). In an embodiment, the merchant 118 may input the target payment mode details of the target payment mode 104 associated with the user 102 into the merchant device 108 prior to onboarding the target payment mode 104 for a service. In another embodiment, the user 102 may input the target payment mode details into the online shopping service application on the user device 106 while performing online shopping on the user device 106. The ASI transaction request includes the identifier of the target payment mode 104, the amount 306 to be charged to the target payment mode 104 in the future payment transaction for the service, and the time period 308 to perform the future payment transaction.
[00093] The acquirer server 110 receives the ASI transaction request from the merchant device 108 and in turn, identifies the payment network server 112 associated with the target payment mode 104. The acquirer server 110 then transmits the received ASI transaction request to the identified payment network server 112 (as shown by arrow 404). The payment network server 112 receives the ASI transaction request, performs a check to authenticate the target payment mode 104 based on the details of the target payment mode 104 in the ASI transaction request, identifies the issuer associated with the target payment mode 104, and transmits the received ASI transaction request to the issuer server 114 (as shown by arrow 406) associated with the identified issuer.
[00094] The issuer server 114 receives the ASI transaction request from the payment network server 112. The issuer server 114 performs a current status check. During the current status check (as shown by arrow 408), the issuer server 114 checks whether the identifier of the target payment mode 104 is listed in a list of canceled, past due, or stolen payment modes. Further, the issuer server 114 checks if the first payment account has a minimum account balance. Thus, the issuer server 114 determines the current status of the target payment mode 104. The current status may indicate the target payment mode 104 as valid or invalid. The current status of the target payment mode 104 is valid when the identifier of the target payment mode 104 is not listed in the list of canceled, past due, or stolen payment modes and the first payment account has the minimum account balance. The current status of the target payment mode 104 is invalid when the identifier of the target payment mode 104 is listed in the list of canceled, past due, or stolen payment modes and/or the first payment account does not have the minimum account balance. Further, the issuer server 114 transmits the current status of the target payment mode 104 to the payment network server 112 (as shown by arrow 410).
[00095] The payment network server 112 receives the current status of the target payment mode 104 from the issuer server 114. When the current status indicates that the target payment mode 104 is valid, the payment network server 112 determines the success score 304 for the future payment transaction (as shown by arrow 412). The processor 202 extracts the identifier of the target payment mode 104 from the ASI transaction request and computes the second plurality of feature values 310 for the plurality of features based on the historical transaction data 208 of the target payment mode 104 stored in the memory 204. Further, the processor 202 extracts the amount 306 for the future payment transaction and the time period 308 of the future payment transaction from the ASI transaction request. The processor 202 provides the amount 306, the time period 308, and the second plurality of feature values 310 as the input to the trained artificial intelligence model 122. The trained artificial intelligence model 122 determines the success score 304 for the future payment transaction based on the input. The processor 202 receives the success score 304 from the trained artificial intelligence model 122. The payment network server 112 thus transmits the ASI transaction response that indicates the success score 304 to the acquirer server 110 (as shown by arrow 414).
[00096] When the current status indicates that the target payment mode 104 is invalid, the payment network server 112 transmits the ASI transaction response that indicates that the target payment mode 104 is invalid to the acquirer server 110 (as shown by arrow 416). The acquirer server 110 transmits the ASI transaction response to the merchant device 108 (as shown by arrow 414). The merchant 118 onboards or declines the target payment mode 104 for the service based on the ASI transaction response.
[00097] FIG. 5 is a block diagram that illustrates a system architecture of a computer system 500, in accordance with an embodiment of the present disclosure. An embodiment of present disclosure, or portions thereof, may be implemented as computer readable code on the computer system 500. In one example, the user device 106, the merchant device 108, the acquirer server 110, the payment network server 112, and the issuer server 114 may be implemented as the computer system 500. Hardware, software, or any combination thereof may embody modules and components used to implement the methods of FIGS. 6A-6B, 7, and 8.
[00098] The computer system 500 includes a CPU 502 that may be a special-purpose or a general-purpose processing device. The CPU 502 may be a single processor, multiple processors, or combinations thereof. The CPU 502 may have one or more processor cores. In one example, the CPU 502 is an octa-core processor. Further, the CPU 502 may be connected to a communication infrastructure 504, such as a bus, message queue, multi-core message-passing scheme, and the like. The computer system 500 may further include a main memory 506 and a secondary memory 508. Examples of the main memory 506 may include RAM, ROM, and the like. The secondary memory 508 may include a hard disk drive or a removable storage drive, such as a floppy disk drive, a magnetic tape drive, a compact disc, an optical disk drive, a flash memory, and the like.
[00099] The computer system 500 further includes an input/output (I/O) interface 510 and a communication interface 512. The I/O interface 510 includes various input and output devices that are configured to communicate with the CPU 502. Examples of the input devices may include a keyboard, a mouse, a joystick, a touchscreen, a microphone, and the like. Examples of the output devices may include a display screen, a speaker, headphones, and the like. The communication interface 512 may be configured to allow data to be transferred between the computer system 500 and various devices that are communicatively coupled to the computer system 500. Examples of the communication interface 512 may include a modem, a network interface, i.e., an Ethernet card, a communication port, and the like. Data transferred via the communication interface 512 may correspond to signals, such as electronic, electromagnetic, optical, or other signals as will be apparent to a person skilled in the art.
[000100] FIGS. 6A-6B, collectively, represent a flowchart 600 that illustrates a method for validating the payment mode for availing services, in accordance with an exemplary embodiment of the present disclosure. For the sake of clarity, the service offered by the merchant 118 is discussed.
[000101] With reference to FIG. 6A, at step 602, the historical transaction data 208 of the plurality of payment modes is stored in the memory 204 by the processor 202. At step 604, the plurality of features based on the historical transaction data 208 of the plurality of payment modes are generated by the processor 202. Further, the first plurality of feature values 302 of the plurality of payment modes based on the historical transaction data 208 are computed by the processor 202. At step 606, the first artificial intelligence model 122 is trained based on the historical transaction data 208 of the plurality of payment modes and the first plurality of feature values 302 to obtain the trained artificial intelligence model 122, by the processor 202.
[000102] At step 608, the ASI request is received by the processor 202, from the merchant device 108 of the merchant 118 via the communication network 116. The ASI transaction request includes the identifier of the target payment mode 104, the amount 306 to be charged to the target payment mode 104 in a future payment transaction for the service, and the time period 308 to perform the future payment transaction.
[000103] Now referring to FIG. 6B, at step 610, the second plurality of feature values 310 for plurality of features of the target payment mode 104 that are based on the ASI transaction request and the historical transaction data 208 of the plurality of payment modes are computed by the processor 202. At step 612, the amount 306, the time period 308, and the second plurality of feature values 310 are provided as the input to the trained artificial intelligence model 122, by the processor 202.
[000104] At step 614, the success score 304 of the future payment transaction is provided as the output by the trained artificial intelligence model 122 which is received by the processor 202. The success score 304 of the future payment transaction associated with the time period 308 and the amount 306 related to the target payment mode 104 is provided as the output by trained artificial intelligence model 122. The success score 304 is determined by the trained artificial intelligence model 122 based on the comparison of the second plurality of feature values 310 with the first plurality of feature values 302.
[000105] At step 616, the ASI transaction response that includes at least the success score 304 of the future payment transaction is communicated by the processor 202 to the merchant device 108. Further, the target payment mode 104 is onboarded or declined for the service based on the success score 304.
[000106] FIG. 7 represents a flowchart 700 that illustrates a method for determining the success score 304 using the trained artificial intelligence model 122, in accordance with an embodiment of the present disclosure. At step 702, the second plurality of feature values 310 of the target payment mode 104 are compared with the first plurality of feature values 302 of the plurality of payment modes, by the trained artificial intelligence model 122.
[000107] At step 704, the plurality of similar payment modes are identified, based on the comparison of the second plurality of feature values 310 of the target payment mode 104 with the first plurality of feature values 302 of the plurality of payment modes by the trained artificial intelligence model 122.
[000108] At step 706, the plurality of similar payment modes which are based on the amount 306 and the time period 308 associated with the future payment transaction are analyzed by the trained artificial intelligence model 122. At step 708, the success trend is generated by the trained artificial intelligence model 122, based on the analysis and the success trend. At step 710, the success score 304 for the future payment transaction is determined by the trained artificial intelligence model 122 based on the success trend. In an embodiment, when the payment network server 112 determines that the success score is below the first threshold value, the payment network server 112 determines at least one of the alternate time period and the alternate amount for the future payment transaction. The success score associated with the alternate time period and the alternate amount is greater than the success score 304. In another embodiment, the merchant 118 may provide at least one of an alternate time period and alternate amount for the future payment transaction when the success score 304 is less than the first threshold value. Further, the payment network server 112 determines the success score for the future payment transaction for the alternate time period and the alternate time provided by the merchant 118 by way of the merchant device 108.
[000109] FIG. 8 represents a high-level flowchart 800 that illustrates a method to validate a payment mode for availing services, in accordance with an embodiment of the present disclosure. At step 802, the ASI transaction request is received by the processor 202 associated with the payment network server 112, from the merchant device 108. The ASI transaction request includes the identifier of the target payment mode 104, the amount 306 to be charged to the target payment mode 104 in the future payment transaction for the service, and the time period 308 to perform the future payment transaction. At step 804, the second plurality of feature values 310 of the target payment mode 104 for the plurality of features are computed by the processor 202.
[000110] At step 806, the amount 306, the time period 308, and the second plurality of feature values 310 are provided as the input to the trained artificial intelligence model 122 associated with the payment network server 112, by the processor 202.
[000111] At step 808, the success score 304 determined by the trained artificial intelligence model 122 is received by the processor 202. At step 810, the ASI transaction response is communicated by the processor 202, to the merchant device 108. The ASI transaction response includes the success score 304. Further, based on the received ASI transaction response, the merchant 118 may onboard or decline the target payment mode 104 for the service.
[000112] Embodiments in the disclosure enable the payment network server 112 for validating the target payment mode 104 for a future payment transaction. The embodiments in the disclosure facilitate validation of the target payment mode 104 for the future payment transaction based on the amount 306 for the transaction, the time period 308 to perform the transaction, and the historical transaction data 208 of the target payment mode 104. The merchant 118 may onboard or decline the target payment mode 104 based on the success score 304. The success score 304 facilitates the merchant 118 to take a decision of providing the service to the user 102 by onboarding the target payment mode 104 for the service. As a result, when the target payment mode 104 has a low success score for the future payment transaction, the merchant 118 may choose to decline the target payment mode 104 for the service. Thus, financial losses to the merchant 118 are prevented due to a failure of the future payment transaction. Further, overhead in the payment network server 112 is reduced as the merchant 118 declines the payment modes with low success score for future payment transactions. The ASI transaction response may include additional information to supplement the merchant 118 for making an informed decision to engage in a transaction with the user 102. In an example, the additional information may include an alternate time period compared to the time period 308 specified by the merchant 118 for the future payment transaction. The alternate time period has higher chances of a successful future payment transaction compared to the time period 308 specified by the merchant 118. As a result, the merchant 118 may onboard the target payment mode 104 for the service with the future payment transaction scheduled in the alternate time period. In another example, the additional information includes an alternate amount as compared to the amount 306 specified by the merchant 118 for the future payment transaction. The alternate amount has higher chances of a successful future payment transaction compared to the amount 306 specified by the merchant 118. Based on the alternate amount, the merchant 118 may provide an alternate service to the user 102.
[000113] In the claims, the words ‘comprising’, ‘including’ and ‘having’ do not exclude the presence of other elements or steps then those listed in a claim. The terms “a” or “an,” as used herein, are defined as one or more than one. Unless stated otherwise, terms such as “first” and “second” are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements. The fact that certain measures are recited in mutually different claims does not indicate that a combination of these measures cannot be used to advantage.
[000114] Techniques consistent with the present disclosure provide, among other features, systems and methods for validating current and future validity and value of payment modes. While various embodiments of the present disclosure have been illustrated and described, it will be clear that the present disclosure is not limited to these embodiments only. Numerous modifications, changes, variations, substitutions, and equivalents will be apparent to those skilled in the art, without departing from the spirit and scope of the present disclosure, as described in the claims.
, Claims:We Claim:
1. A method to validate a payment mode for availing services, the method comprising:
receiving, by a processor (202) associated with a server (112), from a merchant device (108) of a merchant, an account status inquiry (ASI) transaction request prior to onboarding a target payment mode of a user for a service, wherein the ASI transaction request comprises an identifier of the target payment mode, an amount to be charged to the target payment mode in a future payment transaction for the service, and a time period to perform the future payment transaction;
computing, by the processor (202), for a plurality of features, a first plurality of feature values of the target payment mode based on historical transaction data of the target payment mode, wherein the plurality of features are correlated with a payment behavior trend of the target payment mode and a plurality of payment modes;
providing, by the processor (202), the amount, the time period, and the first plurality of feature values as an input to a trained artificial intelligence model (122) associated with the server (112);
receiving, by the processor (202), as an output of the trained artificial intelligence model (122), a success score of the future payment transaction when performed within the time period to charge the amount to the target payment mode, wherein the trained artificial intelligence model (122) generates the success score based on a comparison of the first plurality of feature values with a second plurality of feature values of the plurality of payment modes; and
communicating, by the processor (202) to the merchant device (108), an ASI transaction response that includes the success score of the future payment transaction, wherein the target payment mode is onboarded or declined for the service based on the success score indicated by the ASI transaction response.

2. The method as claimed in claim 1, comprising:
comparing, by the trained artificial intelligence model (122), the first plurality of feature values with the second plurality of feature values;
identifying, by the trained artificial intelligence model (122), a plurality of similar payment modes from the plurality of payment modes based on the comparison of the first plurality of feature values with the second plurality of feature values;
analyzing, by the trained artificial intelligence model (122), the plurality of similar payment modes based on the amount and the time period associated with the future payment transaction; and
generating, by the trained artificial intelligence model (122), a success trend based on the analysis, wherein the success score is generated based on the success trend.

3. The method as claimed in claim 1, wherein the success score varies with a variation in the amount and the time period associated with the future payment transaction.

4. The method as claimed in claim 1, comprising:
generating, by the processor (202), the plurality of features based on historical transaction data of the plurality of payment modes, wherein the plurality of features include at least one of a plurality of amounts of a plurality of transactions in a time duration, a number of approved transactions in the time duration, a number of declined transactions in the time duration, a number of approved transactions after latest non-sufficient fund (NSF) transaction, a number of declined transactions after latest NSF transaction, and a time duration between consecutive NSF transactions.

5. The method as claimed in claim 1, comprising:
generating, by the processor (202), the plurality of features based on historical transaction data of the plurality of payment modes, wherein the plurality of features include at least one of a number of approved transactions with a similar type of merchants, a number of declined transactions with the similar type of merchants, a number of approved transactions for a plurality of amount ranges, and a number of declined transactions for the plurality of amount ranges.

6. The method as claimed in claim 1, comprising:
training, by the processor (202), a first artificial intelligence model (122) based on historical transaction data of the plurality of payment modes, to obtain the trained artificial intelligence model (122).

7. The method as claimed in claim 6, comprising:
storing, by the processor (202), historical transaction data of the plurality of payment modes, the historical transaction data of the target payment mode, the plurality of features, the first plurality of feature values, and the second plurality of feature values in a memory (204) associated with the server (112).

8. The method as claimed in claim 1, wherein the target payment mode is a payment card.

9. The method as claimed in claim 1, wherein the target payment mode is one of a digital wallet and a unified payment interface (UPI).

10. A server (112) to validate a payment mode for availing services, the server (112) comprising:
a memory (204) configured to store a trained artificial intelligence model (122); and
a processor (202) configured to:
receive an account status inquiry (ASI) transaction request prior to onboarding a target payment mode of a user for a service from a merchant device (108) of a merchant, wherein the ASI transaction request comprises an identifier of the target payment mode, an amount to be charged to the target payment mode in a future payment transaction for the service, and a time period to perform the future payment transaction;
compute, for a plurality of features, a first plurality of feature values of the target payment mode based on historical transaction data of the target payment mode, wherein the plurality of features is correlated with a payment behavior trend of the target payment mode and a plurality of payment modes;
provide the amount, the time period, and the first plurality of feature values as an input to the trained artificial intelligence model (122);
receive a success score of the future payment transaction when performed within the time period to charge the amount to the target payment mode as an output of the trained artificial intelligence model (122), wherein the trained artificial intelligence model (122) generates the success score based on a comparison of the first plurality of feature values with a second plurality of feature values of the plurality of payment modes; and
communicate an ASI transaction response that includes at least the success score of the future payment transaction to the merchant device (108), wherein the target payment mode (104) is onboarded or declined for the service based on the success score indicated by the ASI transaction response.