System and method for reverse card authentication with single step verification

Abstract

Systems and methods for implementing a single-step processing of a two-step transaction involving an initial amount and a final amount. The proposed systems and methods include built-in logical operations and parameter acquisition schemes for identifying two-step transactions and internal calculations of the final amount based on user-specified logical operations and input parameters. Data values corresponding to the input parameters may be dynamically extracted from the transaction string and / or obtained from one or more applications running on the user device and then processed with specified logical operations to generate a final transaction amount from an initial transaction amount referenced in the transaction request. The final transaction amount may then be validated and a single authentication response transmitted to the payment gateway initiating the request.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims priority to U.S. Patent Application No. 17 / 880,419, filed on August 3, 2022, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates to systems and methods for automatic verification of electronic transactions, and more particularly, to systems and methods for single - step verification of two - step verification transactions. Background Art

[0004] Two - step transaction processing typically involves a transaction associated with an estimated initial payment amount and a final payment amount that is later verified by the user. The processing of such two - step transactions (e.g., a transaction including a gratuity / tip payment portion) typically involves an initial exchange of transaction messages for authentication of the payment source corresponding to the initial transaction amount, and a second exchange of transaction messages for the final amount (e.g., when the user adds a gratuity amount to the initial transaction amount and verifies the final amount with a signature).

[0005] The above - described two - step method for processing transactions is not only cumbersome for both users and service providers due to the need for a second step, but there is also a significant time delay between the initial transaction request and the final verification response. Additionally, the two - step transaction processing scheme imposes a heavier load on the network system and / or traffic by requiring the conveyance of two separate request and / or response messages between the merchant payment gateway and the remote transaction verification server and / or entity. These and other disadvantages exist in existing platforms for the electronic processing of two - step transactions. Summary of the Invention

[0006] One aspect of the present disclosure is directed to a system and process for simplifying the two - step processing of transactions involving an estimated (initial) transaction amount and a final transaction amount by generating a single verification response for the final transaction amount. The final transaction amount is automatically calculated based on a set of user - specified logical operations and input parameters that can be encoded into a financial account profile associated with the primary user account and / or connected to the user's payment card.

[0007] Accordingly, embodiments of the present disclosure are directed to a method for optimizing two-step electronic processing of a transaction involving estimating a transaction amount, the method comprising: identifying, based on transaction string data, a transaction message encoding a merchant identifier associated with a first merchant category, the transaction message corresponding to a request for a first transaction amount; processing the first transaction amount by a transaction processing server with one or more logical operations to calculate a second transaction amount, wherein the one or more logical operations are derived from one or more user-specified tip parameters associated with the merchant identifier; and transmitting, in response to a transaction request message for the first transaction amount, a transaction authorization message for the second amount to a payment gateway associated with the transaction request for the first transaction amount.

[0008] The calculation of the second transaction amount may include: calculating a gratuity amount based on the merchant identifier, the first transaction amount, and one or more user-specified tip parameters associated with the merchant identifier, and increasing the first transaction amount by the calculated gratuity amount. In some examples, the calculation of the gratuity amount and the subsequent generation of the final payment amount may be performed by applying one or more logical operations selected from a set of logical operations associated with the user payment account, wherein the selected logical parameters are pre-determined for a particular identified merchant according to instructions provided in the user financial account associated with the payment card. The instructions may then be retrieved and utilized to modify the transaction processing routine for calculating the gratuity amount and generating a single authentication response for the final payment amount.

[0009] In some embodiments, the set of logical operations may be accessed by the transaction processing routine via one or more application programming interface (API) calls (e.g., for calculating the second transaction amount, which may also be the final transaction amount). One or more logical operations may be specified according to one or more user-specified tip parameters, which may be electronically input via a modified user interface implemented as one or more of a payment application interface stored on the user mobile device or a web interface associated with the user payment account. After the calculation of the final transaction amount based on the provided parameters, a notification message may be transmitted to the user via the modified user interface, prompting the user to confirm the second transaction amount before generating a transaction authorization message approving the second transaction amount.

[0010] According to some embodiments, a first merchant category can correspond to a list of merchant identifiers provided by a user and associated with one or more user-specified tip parameters. The set of parameters provided via a modified user interface can also include a variable for specifying the length of stay of the user at a merchant service location that matches the first merchant category, where the length of stay is determined based on real-time navigation and location data retrieved from one or more navigation-related applications running on the user's mobile device. Then, based on logical instructions and data parameters input and / or approved by the user, the final transaction amount can be increased proportionally to the length of stay at the merchant service location.

[0011] Another aspect of the present disclosure is directed to a system for electronic processing of two-step transactions, the system including a computer hardware device configured to: based on transaction string data, identify a transaction message encoding a merchant identifier associated with a first merchant category (e.g., corresponding to a list of merchant identifiers provided by a user and associated with one or more user-specified tip parameters and input data variables), the corresponding transaction message being associated with a request for a first transaction amount. The system can also be configured to process the first transaction amount with one or more logical operations to calculate a second transaction amount, where the one or more logical operations are derived from one or more user-specified tip parameters associated with the merchant identifier. The system can also be configured to, in response to the transaction message for the first transaction amount, transmit a transaction authorization message for the second amount to a payment gateway associated with the transaction request for the first transaction amount.

[0012] The system and / or the computer hardware device can be configured to calculate the second transaction amount by calculating a gratuity amount based on the merchant identifier, the first transaction amount, and one or more user-specified tip parameters associated with the merchant identifier, and increasing the first transaction amount by the calculated gratuity amount. In some examples, the one or more logical operations derived from one or more user-specified tip parameters can be selected from a set of user-specified tip parameters and input data variables associated with the user's payment account. The computer hardware device can be configured to access the set of logical operations via one or more application programming interface (API) calls to calculate the second transaction amount.

[0013] The system can also include a modified user interface to capture one or more user-specified tip parameters and input data variables, the modified user interface being implemented as one or more of a payment application interface stored on the user's mobile device or a web interface associated with the user's payment account. In some embodiments, the computer hardware device can also be configured to transmit a notification message via the modified user interface to prompt the user to confirm the second transaction amount.

[0014] In some embodiments, the system may also be configured to determine a dwell time of a user at a merchant service location that matches a first merchant category, the dwell time being determined based on real-time navigation and location data retrieved from one or more navigation-related applications running on the user's mobile device. The calculated gratuity amount and subsequent second and / or final transaction amount may then be automatically increased in proportion to the dwell time at the merchant service location.

[0015] One aspect of the present disclosure is directed to a non-transitory computer-accessible medium that includes instructions executable by a computer hardware device, wherein, when the instructions are executed, the computer hardware device is configured to perform a program that includes: identifying, based on transaction string data, a transaction message that encodes a merchant identifier associated with a first merchant category, the transaction message corresponding to a request for a first transaction amount; processing the first transaction amount with one or more logical operations by a transaction processing server to calculate a second transaction amount, wherein the one or more logical operations are derived from one or more user-specified tip parameters associated with the merchant identifier; and transmitting, in response to a transaction request message for the first transaction amount, a transaction authorization message for the second amount to a payment gateway associated with the transaction request for the first transaction amount. In some embodiments, the calculation of the second transaction amount may include: calculating a gratuity amount based on the merchant identifier, the first transaction amount, and one or more user-specified tip parameters associated with the merchant identifier, and increasing the first transaction amount by the calculated gratuity amount. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The various embodiments of the present disclosure, as well as other objects and advantages, may be best understood by reference to the following description taken in conjunction with the accompanying drawings.

[0017] FIG. 1 is an exemplary implementation of an existing scheme for electronic processing of a two-step transaction, which involves two separate network requests and / or response messages for completing the transaction processing.

[0018] Figure 2 is an exemplary operational block diagram showing the general operational flow involved in the electronic processing of a two-step transaction with a single request and response message according to some embodiments of the present disclosure.

[0019] Figure 3 is an exemplary block diagram showing the construction of a merchant-specific set of logical operations with input parameter values for dynamic and static acquisition for modifying an initial transaction amount according to some embodiments of the present disclosure.

[0020] Figure 4 is a block diagram showing a process related to extracting a merchant identifier from a transaction string and obtaining data values corresponding to input parameters of a merchant-specific logical expression specified by a user according to some embodiments of the present disclosure.

[0021] Figure 5 It is a flowchart of an exemplary automated single-step processing solution based on user-specified logical operations and data parameters according to some embodiments of the present disclosure.

[0022] Figure 6 It is an illustration of an exemplary implementation of a single-step transaction processing system based on built-in tip calculation logic according to some embodiments of the present disclosure, characterized by an added security layer involving authentication using a contactless card.

[0023] Figure 7 It is a block diagram illustration of an embodiment involving a portable payment gateway device and a user mobile device according to some embodiments of the present disclosure, for directly initiating a transaction request with a final amount via authentication using a contactless card.

[0024] Figure 8 It is an illustration of an exemplary block diagram of an exemplary system according to some embodiments of the present disclosure. Detailed Description

[0025] The following description of the embodiments provides non-limiting representative examples with reference numerals to specifically describe the features and teachings of different aspects of the present invention. The described embodiments should be considered capable of being implemented separately from other embodiments in the description of the embodiments or in a combined manner. A person of ordinary skill in the art reading the description of the embodiments should be able to learn and understand different described aspects of the present invention. The description of the embodiments should contribute to the understanding of the present invention to such an extent that other embodiments not specifically covered but within the knowledge of a person skilled in the art after reading the description of the embodiments will be understood to be consistent with the application of the present invention.

[0026] FIG. 1 illustrates some key drawbacks of an existing solution for two-step transaction processing, which typically includes two separate communication sessions, for example, consisting of communication session 101 associated with transaction request-response transmissions 102 and 103 for an initial transaction amount and communication session 104 associated with transaction request-response transmissions 105 and 106 for a reference final transaction amount.

[0027] Therefore, traditional processing solutions for two-step transactions have two main drawbacks. One drawback of existing implementations relates to the network traffic generated by the need for two separate communication flows and / or sessions (such as communication sessions 101 and 104). The latter involves the first set of request and response transmissions for the initial transaction amount (e.g., 102, 103), and the former involves the second set of request and response transmissions for the final transaction amount (e.g., 105, 106). Additionally, the issuance of the final transaction verification response (106) typically involves a time delay (107) because communication session 104 is established at a later time after the information exchange on communication session 101 is completed.

[0028] Figure 2 An exemplary operational overview (200) of single-step transaction processing according to an embodiment of the proposed solution is shown. The single-step transaction processing solution (200) includes near-instantaneous verification of a two-step transaction request on a single communication session (e.g., session 201) established between a transaction initiation entity and a transaction verification entity. An exemplary embodiment of the single-step transaction processing solution (200) may include operations such as parsing a set of incoming transaction request strings (202) to identify the Merchant Category Code (MCC) encoded therein, represented by operation block (204). As shown by the transaction data path (208), the identified transaction strings (extracted from the incoming transaction strings) associated with the target MCC and / or target merchant identifier may be redirected to a built-in logic processing module (210) for calculation of the final transaction amount associated with the transaction request. Transactions not identified with the target conditions may be directly sent to the verification process (as shown by transaction flow 206).

[0029] Return reference Figure 2, module 210 can receive a set of input parameters (e.g., P1, P2, and P3) defined by the user via a modified user interface (213). The modified user interface (213) can also be configured to communicate one or more data values statically input by the user and / or dynamically obtained from one or more internal and / or external sources. The one or more data values can be associated with one or more corresponding input parameters specified in a tip calculation logic expression. The one or more input parameters can also include a set of logical operators for representing a merchant-specific tip calculation logic expression as a function of one or more input parameters provided by the user. The one or more input parameter values can also correspond to information retrieved from an incoming transaction string and / or one or more applications running on the user's mobile device (e.g., the user computing device and / or mobile device 214) and / or a corresponding application server. Then, the final transaction amount can be calculated by module 210 based on preprocessing the initial transaction amount (extracted from the transaction string) with a corresponding merchant-specific tip calculation logic expression. After calculating the final transaction amount, a transaction verification response (212) of the final transaction amount can be transmitted back to the transaction initiating entity (e.g., the merchant server). As discussed above, the above information exchange can be carried out on a single communication session 201, which can be established on a public network.

[0030] The modified user interface (213) can be implemented as part of one or more (modified) mobile applications stored on the user's mobile device (214) and / or a web interface (216) of the user's online account. As described above, the modified user interface (213) serves as an interface for the user to represent a tip calculation formula as a function of one or more input parameters. The input parameters can be associated with one or more static coefficients and / or variable data, which can be collected internally and / or externally (e.g., data values corresponding to one or more electronically recorded and tracked user activities).

[0031] Some non-limiting examples of internally collected data can include data from applications running on the user's mobile device (such as a Global Positioning System (GPS)-based navigation application), and browser plugins that may be installed on a browser application and stored on the user device to track the user's browsing patterns. Non-limiting examples of externally collected data can include transaction information provided or retrieved by one or more financial account servers linked to one or more financial instruments associated with the user. Refer to Figure 3 and Figure 4 , which further illustrates and describes the construction and operation of a merchant-specific logic expression for automatically calculating the final transaction amount.

[0032] Figure 3 An exemplary system implementation (300) is shown for facilitating the construction (e.g., 310) of a merchant - specific logical expression that is a function of a set of user - specified parameters (e.g., P1, P2). The set of user - specified parameters can be input via a modified user interface (213) and, according to example 300, is implemented via a mobile application stored on the user's mobile device and / or computing device (214). Thus, Figure 3 Regarding an exemplary system (300) for implementing built - in tip - calculation logic to streamline two - step transaction processing - in this regard, the exemplary embodiment (300) shows the construction of a merchant - specific logical expression (e.g., logical expression 310 specific to merchant ID1) as a function of one or more user - specified parameters (e.g., ID1, P1, P2). Execution of the logical expression (310) may first require obtaining the corresponding data values associated with the input parameters specified in the merchant - specific logical expression.

[0033] Referring Figure 3 , the user can provide one or more inputs corresponding to a set of parameters and / or parameter coefficients via the modified interface (213) implemented on the mobile device (214) to construct the exemplary merchant - specific logical expression (310). For example, the parameter ID1 provided by the user can correspond to merchant identification information (e.g., merchant name) for identifying one or more (two - step) transactions that match a specific merchant identifier (e.g., ID1) from a set of candidate transactions - and for identifying the corresponding logical expression for pre - processing one or more two - step transactions that match the merchant identifier ID1. As an example and referring Figure 2 , the set of candidate transactions can correspond to a transaction flow (208) that is filtered by a processing block (204) from a plurality of incoming transaction requests (202) and redirected to a processing module (210) for alternative processing using the built - in tip - calculation logic.

[0034] Returning to the reference Figure 3, the parameter (P1) provided by the user can correspond to a variable representing the basic cost or the initial transaction amount. The value associated with the parameter (P1) (e.g., P1 (data value) corresponding to the initial transaction amount) can be extracted from the identified two-step transaction string at the time of transaction processing (e.g., through parsing and matching operations performed by a module and / or process 204 that can run as part of an application 218 stored on the user's mobile device (214)). The user can provide additional parameters based on a specific merchant. For example, in the exemplary embodiment 300, the user provides a second parameter (P2) to represent the length of time spent at a service location corresponding to merchant ID1. The value associated with the parameter P2 (e.g., P2 (data value)) can be retrieved from one or more applications stored on the user's mobile device (214) and / or the corresponding application server. For example, navigation and location data from a GPS application running on the user device (214) can be used to determine the dwell time at a service location corresponding to the merchant identifier (ID1). According to some embodiments, the GPS application data can also be used to verify an incoming transaction request by matching the merchant identifier (ID1) specified by the user with the GPS location data to verify that the user location corresponds to a known merchant service location of merchant ID1.

[0035] The user can also provide a set of logical operators for connecting the input parameters into a logical expression. For example, the parameter 306 represented by a triangle symbol corresponds to a set of logical operators that are used to connect the parameters (P1) and (P2) associated with merchant ID1 into a merchant-specific logical expression (310), as shown in the embedded block diagram (312). Then, the merchant-specific logical expression (310) provided as a function of the basic cost or initial transaction amount (P1) and the dwell time (P2) can be stored, for example, as different data objects on the transaction authentication server (340) and / or a database (130) communicatively coupled to the server (340).

[0036] Referring to Figure 3 the exemplary embodiment 300 shown, the user can also input one or more constant coefficients or scaling factors (e.g., SF1 and SF2) to variably weight one or more parameter values when determining the result of the merchant-specific logical expression. For example, an exemplary merchant-specific logical expression (310) for modifying the transaction amount in an incoming transaction request associated with merchant identifier (ID1) involves adding 15% of the basic cost specified by SF1 (0.15*P1) to 5 times the dwell time specified by SF2 (5*P2), where the dwell time is specified, for example, in hours. Thus, referring to Figure 3, the logical expression 310 increases the tip amount (calculated as 15% of the base cost (e.g., 0.15*P1)) proportionally to the stay time at the merchant service location (e.g., an additional $5.00 for each hour spent at the merchant (ID1) service location).

[0037] By entering various permutations of logical operators and the values of constant coefficients and scaling factors (SF), the user can modify the operation of the tip calculation process. For example, if the user intends to increase the tip amount (calculated as 15% of the base cost (e.g., 0.15*P1)) by $5.00 for each additional hour (after the first hour) spent at the merchant (ID1) service location, the merchant-specific logical operation can be specified as (0.15*P1)+(5*(P2 - 1)). The parameters entered by the user and the scaling factors, as well as the parameter values extracted from the transaction string and / or retrieved from one or more applications that track the user's activities, can be communicated from the user mobile device and / or computing device (214) to the transaction authentication server (340) over the network data path (308). The network data path (308) can extend over the public network 127 and further direct notification and user prompt messages from the transaction authentication server (340) back to the user mobile device and / or computing device (214).

[0038] Incorporating the proposed solution for generating a built-in custom tip calculation function into the transaction processing flow can streamline the transaction processes for both the merchant and the user side (e.g., immediately facilitating two-step transaction processing via a single communication session, as Figure 2 shown, and further as Figure 4 , Figure 6 and Figure 7 shown), while optimizing the network communication and traffic associated with such a two-step transaction processing platform, as will be further described with reference to Figure 4 .

[0039] Regarding the optimization of the above-mentioned network communication and / or traffic load, Figure 4 an exemplary system implementation (400) is shown, which involves applying a custom logical expression (e.g., constructed as shown in Figure 3 ) to the identified two-step transaction request (e.g., the first network transmission 402) to generate a single verification response (the second network transmission 412) that references the final transaction amount almost instantaneously (e.g., without the delay 107 shown in Figure 1) - thereby improving the time duration and network load associated with such transaction processing operations.

[0040] Example 400 illustrates an implementation of a modified scheme for processing two-step transactions using built-in logic calculation modules and / or processes (such as module 210), which can operate by, for example, using a data set (403) that includes records of merchant-specific logic tip calculation expressions (such as logic expression / formula 310). Merchant-specific records including corresponding tip calculation expressions can be stored as different data objects in the data set (403).

[0041] In an exemplary embodiment (400), the merchant-specific logic expressions stored in the data set (403) can correspond to various combinations of logical operators, represented as various geometric shapes expressed as a function of a set of input parameters (e.g., P1, P2, etc.), and matched to a specific merchant identifier (e.g., ID1, ID2, etc.). The input parameters specified by the various logical expressions can be associated with static inputs and / or dynamically obtained data values.

[0042] Returning to the operations associated with the exemplary system 400, a transaction request message (402) associated with an initial transaction amount can be received by a transaction authentication server (340) that stores the data set (403). A process (e.g., process 404) running on the transaction authentication server 340 can be configured to parse and inspect an incoming transaction string (such as transaction request message 402) to identify a transaction associated with a target attribute and redirect the identified transaction (406) to match a corresponding merchant-specific logic tip calculation expression stored in the data set 403. The target attribute can correspond to an MCC and / or a merchant identifier that matches one or more merchant categories and / or service locations associated with, for example, a tip-based transaction. One or more merchant categories and / or service locations can also be specified by a user, an automated process (e.g., Figure 2 the process 204 shown in), and / or a combination of user inputs and operations associated with an automated process (e.g., process 204).

[0043] As described above, the identification of a two-step transaction can include matching a merchant identifier extracted from a transaction string to a merchant ID associated with one or more tip calculation logic expressions stored in, for example, the data set (403). In some embodiments, the process of identifying the target attribute representing a two-step transaction can be applied to a set of transactions (filtered from multiple incoming transaction requests (202)) that are identified as corresponding to one of one or more candidate MCCs (e.g., as Figure 2 represented by the transaction data path 208 in)

[0044] After identifying the corresponding tip calculation logic expression, one or more API calls can be issued to retrieve one or more data values corresponding to the input parameters of the identified merchant-specific expression. The one or more input data values can include data extracted from the transaction string (e.g., the initial transaction amount), data obtained via prompted user input at runtime, data associated with the operation of one or more applications running on the user mobile device and / or computing device (110) and / or the corresponding application server, and any data pre-specified as relevant to calculating the final transaction amount using the identified merchant-specific logic expression. The final transaction amount can be calculated by executing the corresponding merchant-specific logic expression, and a transaction verification response (412) for the calculated final transaction amount can be transmitted to the transaction originating merchant server (120). According to some embodiments, user confirmation input prompted at runtime may be required to verify the calculated final transaction amount.

[0045] Figure 5 An exemplary flowchart (500) of an automated single-step processing scheme for a two-step transaction based on a user-defined built-in tip calculation process is shown. Referring to the exemplary process flow (500), steps 502 and 504 correspond to collecting, parsing, and filtering the incoming transaction string to identify a transaction request associated with the two-step process (e.g., based on extracting a merchant category code (MCC) and / or any other merchant identification information from the parsed transaction string). According to one embodiment, the identification of a two-step transaction can be based on matching the MCC extracted from the transaction string with a list of target MCCs to identify a match, as shown in step 506. If no match is identified, the transaction is processed and a verification or rejection response corresponding to the specified transaction amount is returned (step 508). If a transaction request matching the target MCC is identified at step 506, the merchant identifier is extracted or derived from the corresponding transaction string and compared with a list of merchant identifiers associated with the logical tip calculation expression (step 510). If no match is identified at step 510, the transaction is processed based on a two-step verification scheme that involves transmitting an authentication response associated with the initial transaction amount (step 511), and at a later time, when a transaction request with a final transaction amount with user verification (e.g., including a gratuity amount added to the initial transaction amount with a valid user signature) is received, sending an authentication response for the final transaction amount back to the transaction originating merchant (step 512).

[0046] According to some embodiments, at step (513), a notification message can be generated and displayed on the user mobile device as a user prompt to create a merchant-specific tip calculation logic expression for the transaction originating merchant associated with steps 511 and 512.

[0047] If a match is identified at step (510) between the extracted merchant identifier and the list of merchant identifiers stored and associated with the logical tip calculation expression, then at step 515, the corresponding tip calculation logical expression along with the corresponding input parameter values (identified and retrieved from various sources at step 514) can be used to calculate the final transaction amount and / or gratuity amount (to be added to the initial transaction amount), and at step 516, a transaction verification response for the calculated final transaction amount can be transmitted back to the requesting payment gateway (e.g., the transaction originating merchant).

[0048] Figure 6 An embodiment of the proposed system / method for streamlining the processing of two-step transactions, aided by a contactless card (110), is shown. The contactless card 110 can be used in a specific configuration with other components of the system, such as Figure 6 shown, to provide an additional layer of security in the operation of the proposed system and method. The contactless card can include an integrated processor (111) and a memory (112). The integrated memory (112) can store one or more applets (113), which can be communicatively coupled to one or more applications (e.g., application 218) running on a user mobile device and / or a computing device (214) and / or one or more applications stored on a corresponding application server. The card integrated memory (112) can also store an application transaction counter (114) to track the correct sequence of operations associated with transactions made using the contactless card. The contactless card (110) can also include a Near Field Communication (NFC) interface (115) to facilitate NFC communication with a reader (e.g., reader 220). The encrypted authentication data (605) securely stored on the contactless card (110) and read via the reader (220) can then be transmitted to a transaction authentication server (340) to authenticate the user confirmation response regarding the calculated final transaction amount.

[0049] In exemplary embodiment 600, multiple incoming transaction requests (202) from one or more remote sources (collectively referred to as merchant payment gateways (120) in example 600) are parsed and processed to identify one or more two-step transaction requests (406), which are then redirected for processing using corresponding merchant-specific logical expressions (e.g., stored as data objects in data set 403) to calculate a final transaction amount. Based on the calculated final transaction amount, a single verification response for each identified two-step transaction request can be transmitted back to each corresponding merchant server (e.g., the merchant that initiated the initial transaction request for the two-step transaction), as shown by transaction response (212) in example 600. In some embodiments, the generation of the verification response for the calculated final transaction amount may be subject to a confirmation signal from the user. In exemplary embodiment 600, the user confirmation signal associated with two-factor strong authentication can be provided via encrypted authentication information (605) securely stored on a contactless card (110) and read by the user computing device and / or mobile device (214) via NFC link 606. In this regard, when the user is prompted for authentication input on the mobile device (214), the user can bring the contactless card within the NFC range of the mobile device reader (220) to initiate an NFC transmission of the encrypted authentication data (605). The encrypted user authentication data (605) can then be transmitted to the transaction authentication server (340) for verification, as shown in the exemplary illustration in Figure 6 as shown. Then, the authentication signal (e.g., associated with the encrypted authentication data 605) can be used as two-factor strong user authentication based on the presence of the confirmed user mobile device (214) and the contactless card (110) associated with the user.

[0050] In some embodiments, the communication between the transaction authentication server (340) and the user mobile device 214 (e.g., corresponding to the exchange of notification and / or user prompt request messages and confirmation and / or authentication response messages between the authentication server and the mobile device) can occur over a network data session (308), which can also be used for, e.g., the communication of user input information (608), encrypted user authentication data (605), and system-provided input parameter data values associated with the implementation and execution of the merchant-specific logical tip calculation expression.

[0051] Figure 7An exemplary embodiment involving a scenario is shown, by which an initial transaction request (702) can be directly transmitted from a portable merchant computing device (704) (e.g., a portable Point of Sale (POS) device operated by a service person and brought within the transmission proximity of a user mobile device) to a user mobile device (214) running a corresponding application (e.g., authentication application 718). In the exemplary embodiment (700), this is illustrated by a transmission path 135 between the merchant POS computing device (704) and the user mobile device (214) running the corresponding application (718). Then, an initial transaction request including transaction-related data (such as an initial payment amount) can be displayed to the user on the interface of the corresponding application that can be presented on the user device (214). The communication can be carried out on a direct short-range communication channel (135) using a Bluetooth Low Energy (BLE) link, a Wi-Fi link, and / or any other short-range communication protocol that can be established between the portable (merchant) computing device (704) and the user mobile device (214). Then, the user can select an appropriate merchant-specific logical expression to calculate the final transaction amount and / or the gratuity amount to be added to the initial transaction amount, which can then be displayed to the user on the interface of the user mobile device (214). In some embodiments, the user can also forego applying the preset logical expression to calculate the final transaction amount and directly specify on the application interface the gratuity amount and / or the final transaction amount to be transmitted to the authentication server for verification. However, since in the described embodiments, the calculation of the final amount may not be performed at the backend based on predefined logical expression records securely stored on the server, the verification step may require a strong authentication signal from the user before being accepted. NFC-transmissible user authentication data (605) stored on a contactless card (110) and read by a reader 220 of the user mobile device (214) can be used to provide such a strong authentication signal for authenticating the user payment request and generating a single verification response for the modified amount directly entered by the user.

[0052] Thus, according to some embodiments of the present disclosure, an initial transaction request (702) can be directly transmitted from a portable POS device (704) communicatively coupled to a merchant payment gateway (140) via short-range communication (135) to a user computing device and / or mobile device (214) for processing by an application (718) running on the user device. After receiving the initial transaction request (702), with reference to the initial transaction amount, the user can directly enter the final transaction amount and / or the gratuity amount to be added to the initial transaction amount on an application interface presented on the mobile device display. A transaction verification request message (706) including the transaction amount entered by the end user and one or more user authentication inputs can then be transmitted to an authentication server (140) for processing. The one or more user authentication inputs can correspond to one or more user identification data records securely stored on a contactless card (110) and read from the contactless card via an encrypted NFC transmission (605). After verifying the encrypted user authentication information, the transaction authentication server can transmit a transaction verification response (708) for the final transaction amount to the merchant payment gateway (140).

[0053] In some cases, a two-step transaction request can be received from a new merchant location (e.g., no existing pre-tip logic entry associated with the merchant identifier extracted from the transaction string). In such cases, some embodiments of the proposed system and process can generate a suggested gratuity amount prompt for the user based on an analysis of predefined and / or real-time input tip amounts associated with multiple other system users. Based on the analysis of this data, the average, minimum, and / or maximum tip amounts for a particular merchant can be provided to the user - based on the information provided, the user can directly enter a different tip amount on the application interface, and / or create or update a merchant-specific logic expression (e.g., the average tip amount and / or the average tip amount calculated proportionally based on the stay time and the initial transaction amount).

[0054] Figure 8 A block diagram of an exemplary embodiment of a system according to the present disclosure is shown. For example, an exemplary program according to the present disclosure described herein can be executed by a processing device and / or computing device (e.g., a computer hardware device) 805. Such a processing device and / or computing device 805 can be, for example, all or a part of a computer and / or a processor 810, or include, but are not limited to, a computer and / or a processor 810 (which can include, for example, one or more microprocessors), and use instructions stored on a computer-accessible medium (e.g., RAM, ROM, a hard drive, or other storage device).

[0055] As Figure 8As shown, for example, a computer-accessible medium 815 (e.g., a storage device such as a hard disk, floppy disk, memory stick, CD-ROM, RAM, ROM, etc. or a collection thereof as described above herein) (e.g., communicating with a processing device 805) can be provided. The computer-accessible medium 815 can contain executable instructions 820 thereon. Additionally or alternatively, a storage device 825 and the computer-accessible medium 815 can be provided separately, and the computer-accessible medium 815 can provide instructions to the processing device 805 to configure the processing device to execute certain exemplary programs, procedures, and methods, e.g., as described above herein.

[0056] In addition, the exemplary processing device 805 can be equipped with or include input and / or output ports 835, which can include, for example, a wired network, a wireless network, the Internet, an intranet, data collection probes, sensors, etc. As Figure 8 shown, the exemplary processing device 805 can communicate with an exemplary display device 830, which, according to certain exemplary embodiments of the present disclosure, can be a touch screen configured to input information to the processing device in addition to outputting information from the processing device. Additionally, the exemplary display device 830 and / or the storage device 825 can be used to display and / or store data in a user-accessible format and / or a user-readable format.

[0057] According to some embodiments, one or more data analysis and machine learning routines can be applied to supplement the calculation of the processed user information as described above. This can be supplemented by using various prediction models, such as a prediction model that can utilize a Bidirectional Encoder Representations from Transformer (BERT) model. The BERT model utilizes multiple layers of so-called "attention mechanisms" to process text data and make predictions. These attention mechanisms effectively allow the BERT model to learn and assign greater importance to the words in the text input that are more important when making any inference being attempted.

[0058] Exemplary systems, methods, and computer-accessible media can utilize various neural networks, such as a convolutional neural network (CNN) or a recurrent neural network (RNN), to generate exemplary models. A CNN can include one or more convolutional layers (e.g., typically having a subsampling step) and is then followed by one or more fully connected layers, just like a standard multi-layer neural network. A CNN can utilize local connections and can have tied weights, followed by some form of pooling, which can produce translation-invariant features.

[0059] An RNN is a type of artificial neural network where the connections between nodes form a directed graph along a sequence. This helps to determine the temporal dynamic behavior of a time series. Different from feedforward neural networks, RNNs can use their internal states (e.g., memories) to process input sequences. RNNs generally can refer to two major categories of networks with a similar general structure, one of which is finite impulse and the other is infinite impulse. Both categories of networks exhibit temporal dynamic behavior. A finite impulse recurrent network can be or can include a directed acyclic graph, which can be unfolded and replaced by a strict feedforward neural network, while an infinite impulse recurrent network can be or can include a directed cyclic graph that may not be unfolded. Both the finite impulse recurrent network and the infinite impulse recurrent network can have additional storage states, and the storage can be under the direct control of the neural network. The storage can also be replaced by another network or graph, which can include time delays or can have feedback loops. Such a controlled state can be called a gated state or gated memory and can be part of long short-term memory networks (LSTMs) and gated recurrent units.

[0060] An RNN can be similar to a network of neuron-like nodes organized into successive "layers", with each node in a given layer having a directed connection (e.g., a (unidirectional) connection) to every other node in the next successive layer. Each node (e.g., neuron) can have a time-varying real-valued activation. Each connection (e.g., synapse) can have a modifiable real-valued weight. The nodes can be (i) input nodes (e.g., receiving data from outside the network), (ii) output nodes (e.g., producing results), or (iii) hidden nodes (e.g., which can modify data on its way from input to output). An RNN can accept an input vector x and give an output vector y. However, the output vector is based not only on the just-provided input but also on the entire input history provided in the past.

[0061] For supervised learning in a discrete-time setting, a sequence of real-valued input vectors can arrive at the input nodes one vector at a time. At any given time step, each non-input unit can compute its current activation (e.g., outcome) as a non-linear function of the weighted sum of the activations of all units connected to it. At some time steps, a supervisor-given target activation can be provided for some output units. For example, if the input sequence is a speech signal corresponding to a spoken number, the final target output at the end of the sequence can be a label classifying that number. In a reinforcement learning setting, no teacher provides a target signal. Instead, a fitness function or a reward function can be used to evaluate the RNN performance, which can affect its input stream through output units connected to actuators that may affect the environment. Each sequence can produce an error, which is the sum of the deviations of all target signals from the corresponding activations computed by the network. For a training set of a large number of sequences, the total error can be the sum of the errors of all individual sequences.

[0062] The models described herein can be trained on one or more training data sets, each of which can include one or more types of data. In some examples, a training data set can include data previously collected from multiple system users. The previously collected user data can correspond to user transaction activities analyzed in conjunction with, for example, navigation data from a user's mobile device. In other examples, a training data set can include continuously collected data based on the current operation of an instant system and continuously collected data from the operation of other systems (e.g., real-time tracking data of electronic transactions and data from a user's GPS application). In some examples, a training data set can include expected data for an instant system and / or other systems, such as expected future travel patterns and purchase behavior patterns, current scheduled workloads, and planned future workloads. In other examples, a training data set can include previous predictions for an instant system and other types of systems, and can also include result data indicating the accuracy of the previous predictions. According to these examples, the prediction models described herein can be trained before use, and this training can be continued with updated data sets reflecting additional information.

[0063] The present disclosure is not limited to the specific embodiments described in this application, which are intended to illustrate various aspects. Many modifications and variations are apparent without departing from its spirit and scope. Functional equivalent methods and apparatuses within the scope of the present disclosure can be apparent from the foregoing representative description in addition to the methods and apparatuses enumerated herein. Such modifications and variations are intended to fall within the scope of the appended representative claims. The present disclosure is limited only by the terms of the appended representative claims and the full scope of the equivalents thereof. It should also be understood that the terms used herein are for the purpose of describing specific embodiments only and are not intended to be limiting.

[0064] It should also be noted that the systems and methods described herein can be tangibly embodied in one or more physical media, such as but not limited to compact discs (CDs), digital versatile discs (DVDs), floppy disks, hard disks, read only memories (ROMs), random access memories (RAMs), and other physical media capable of storing data. For example, a data storage device may include a random access memory (RAM) and a read only memory (ROM), which may be configured to access and store data and information as well as computer program instructions. The data storage device may also include a storage medium or other suitable type of memory (e.g., RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, floppy disks, hard disks, removable cartridge tapes, flash drives, any type of tangible and non-transitory storage medium), in which files including an operating system, application programs (including, for example, a web browser application, an email application, and / or other application programs), and data files may be stored. The data storage of a network-enabled computer system may include electronic information, files, and documents stored in various ways, including, for example, flat files, indexed files, hierarchical databases, relational databases (such as databases created and maintained with software from, for example, ), files, files, solid state storage devices (which may include flash arrays, hybrid arrays, or server-side products), enterprise storage (which may include online or cloud storage), or any other storage mechanism. Additionally, the figures respectively illustrate various components (e.g., servers, computers, processors, etc.). Functions described as being performed at various components may be performed at other components, and the various components may be combined or separated. Other modifications may also be made.

[0065] In the foregoing specification, various embodiments have been described with reference to the accompanying drawings. However, it will be apparent that various modifications and changes can be made thereto, and additional embodiments can be implemented, without departing from the broader scope of the invention as set forth in the following claims. Accordingly, the specification and drawings are to be regarded as illustrative rather than restrictive.

Claims

1. A method for optimizing two-step electronic processing of a transaction involving an initial transaction amount and a final transaction amount, the method comprises: Based on transaction string data, identifying a transaction message encoding a merchant identifier associated with a first merchant category, the transaction message corresponding to a request for a first transaction amount; Processing the first transaction amount by a transaction processing server with one or more logical operations to calculate a second transaction amount, wherein the one or more logical operations are derived from one or more user-specified tip parameters associated with the merchant identifier; and In response to a transaction request message for the first transaction amount, transmitting a transaction verification response for the second amount to a payment gateway associated with the transaction request for the first transaction amount.

2. The method according to claim 1, wherein, The calculation of the second transaction amount includes: calculating a gratuity amount based on the merchant identifier, the first transaction amount, and one or more user-specified tip parameters associated with the merchant identifier, and increasing the first transaction amount by the calculated gratuity amount.

3. The method according to claim 1, wherein, The one or more logical operations are selected from a set of logical operations associated with a user payment account.

4. The method according to claim 3, wherein, The set of logical operations can be accessed by a process associated with the calculation of the second transaction amount via one or more application programming interfaces (APIs) calls.

5. The method according to claim 1, wherein, The one or more user-specified tip parameters are electronically input via a modified user interface implemented as one or more of a payment application interface stored on a user mobile device or a web interface associated with a user payment account.

6. The method according to claim 5, further comprising transmitting a notification message via the modified user interface to prompt the user to confirm the second transaction amount before generating a transaction verification response for the second transaction amount.

7. The method according to claim 1, wherein, The first merchant category corresponds to a list of merchant identifiers provided by the user and associated with one or more user-specified tip parameters.

8. The method according to claim 1, further comprising determining the user's stay time at a merchant service location matching the first merchant category, the stay time being determined based on real-time navigation and location data retrieved from one or more navigation-related applications running on the user's mobile device.

9. The method according to claim 8, further comprising increasing the second transaction amount in proportion to the stay time at the merchant service location.

10. A system for two-step transaction electronic processing, the system comprises: A computer hardware device configured to: Based on transaction string data, identify a transaction message encoding a merchant identifier associated with a first merchant category, the transaction message corresponding to a request for a first transaction amount; Process the first transaction amount with one or more logical operations to calculate a second transaction amount, wherein the one or more logical operations are derived from one or more user-specified tip parameters associated with the merchant identifier; and In response to a transaction message for the first transaction amount, transmit a transaction verification message for the second transaction amount to a payment gateway associated with a transaction request for the first transaction amount.

11. The system according to claim 10, wherein, The computer hardware device is configured to calculate a gratuity amount based on the merchant identifier, the first transaction amount, and one or more user-specified tip parameters associated with the merchant identifier, thereby calculating the second transaction amount and increasing the first transaction amount by the calculated gratuity amount.

12. The system according to claim 10, wherein, The one or more logical operations are selected from a set of logical operations associated with a user payment account.

13. The system according to claim 12, wherein, The computer hardware device is configured to access the set of logical operations via one or more application programming interface (API) calls to calculate the second transaction amount.

14. The system according to claim 10, further comprising a modified user interface for retrieving one or more user-specified tip parameters, the modified user interface being implemented as one or more of a payment application interface stored on a user mobile device and a web interface associated with a user payment account.

15. The system according to claim 14, wherein, The computer hardware device is further configured to transmit a notification message via the modified user interface to prompt the user to confirm the second transaction amount.

16. The system according to claim 10, wherein, The first merchant category corresponds to a list of merchant identifiers provided by the user and associated with one or more user-specified tip parameters.

17. The system according to claim 10, wherein, The computer hardware device is further configured to determine the dwell time of the user at a merchant service location matching the first merchant category, the dwell time being determined based on real-time navigation and location data retrieved from one or more navigation-related applications running on the user's mobile device.

18. The system according to claim 17, wherein, The computer hardware device is further configured to calculate the second transaction amount proportionally based on the dwell time at the merchant service location.

19. A non-transitory computer-accessible medium comprising instructions for execution by a computer hardware device, wherein, When executing the instructions, the computer hardware device is configured to execute a program including the following: Based on transaction string data, identify a transaction message encoding a merchant identifier associated with a first merchant category, the transaction message corresponding to a request for a first transaction amount; The transaction processing server processes the first transaction amount with one or more logical operations to calculate a second transaction amount, wherein the one or more logical operations are derived from one or more user-specified tip parameters associated with the merchant identifier; and In response to a transaction request message for the first transaction amount, a transaction verification message for the second amount is transmitted to a payment gateway associated with the transaction request for the first transaction amount.

20. The non-transitory computer-accessible medium according to claim 19, wherein the calculation of the second transaction amount includes: calculating a gratuity amount based on the merchant identifier, the first transaction amount, and one or more user-specified tip parameters associated with the merchant identifier, and increasing the first transaction amount by the calculated gratuity amount.

Images