Patent Application
20240046241
The present disclosure relates to systems and methods for automated verification of electronic transactions, and more specifically to systems and methods for single-step verification of two-step verification transactions.
Two-step transactions processing generally involves transactions associated with an estimated initial payment amount and a final payment amount to be validated at a later time by a user. The processing of such two-step transactions (e.g., transactions including a gratuity/tip payment component) generally involve 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 a final amount (e.g., when a user adds a gratuity amount to the initial transaction amount, and validates the final amount with a signature.)
The aforementioned two-step approach for processing transactions, is not only cumbersome for users and service providers by requiring a second step, but also involves a significant time delay between an initial transaction request, and a final validation response. In addition, the two-step transaction processing scheme imposes a heavier load on network systems and/or traffic, by requiring two separate request and/or response messages to be communicated between a merchant payment gateway and a remote transaction validating server and/or entity. These and other shortcoming exist in existing platforms for electronic processing of two-step transactions.
One aspect of the present disclosure is directed to a system and process for streamlining two-step processing of transactions involving an estimated (initial) and a final transaction amount, by generating a single validation response for the final transaction amount. The final transaction amount being automatically computed based on a set of user-specified logical operations and input parameters that may be coded into a finanacial account profile associated with a primary user account and/or connected to a user payment card.
Accordingly, embodiments of the present disclosure are directed to a method for optimizing two-step electronic processing of transactions involving an estimated 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, by a transaction processing server, the first transaction amount with one or more logical operations to compute a second transaction amount, wherein the one or more logical operations are derived from one or more user-specified tipping parameters associated with the merchant identifier; and transmitting, in response to the 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.
The computation of the second transaction amount may comprises: calculating a gratuity amount based on, the merchant identifier, the first transaction amount and the one or more user-specified tipping parameters associated with the merchant identifier, and increasing the first transaction amount by the gratuity amount calculated. In some examples, the calculation of a gratuity amount and subsequent generation of the final payment amount may be conducted by application of one or more logical operations selected from a set of logical operations associated a user payment account, wherein the selected logical parameters are predetermined for a particular identified merchant in accordance to instructions provided in a user financial account associated with the payment card. The instructions may then be retrieved and utilized to modify the transaction processing routine for the computation of the gratuity amount and generation of a single authentication response for the final payment amount.
In some embodiments the set of logical operations may be accessible to the transaction processing routine a process (e.g., for the purpose of computing the second, and possibly the final, transaction amount) via one or more Application Programming Interface (API) calls. The one or more logical operations may be specified in accordance to one or more user-specified tipping parameters that may be inputted electronically via a modified user interface, the modified user interface being 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. Upon completing the computation of the final transaction amount based on 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, prior to generating the transaction authorization message approving the second transaction amount.
In accordance to some embodiments, the first merchant category may correspond to a user-provided listing of merchant identifiers associated with one or more user-specified tipping parameters. The set of parameters provided via the modified user interface, may further comprise a variable for specifying a length of stay, for a user, at a service location of a merchant matching the first merchant category, the length of stay being determined based on real-time navigation and location data retrieved from one or more navigation-related applications running on a mobile device of the user. The final transaction amount may then be increased in proportion to the length of stay at the service location of the merchant in accordance to logical instructions and data parameters inputted and/or approved by the user.
Another aspect of the present disclosure is directed to a system for electronic processing of two-step transactions, the system comprising: a computer hardware arrangement configure to: identify, based on transaction string data, a transaction message encoding a merchant identifier associated with a first merchant category (e.g., corresponding to a user-provided listing of merchant identifiers associated with one or more user-specified tipping parameters and input data variables), the corresponding transaction message being associated with a request for a first transaction amount. The system may be further configured to process the first transaction amount with one or more logical operations to compute a second transaction amount, wherein the one or more logical operations are derived from one or more user-specified tipping parameters associated with the merchant identifier. The system may be further configured to transmit, in response to the transaction message for the first transaction amount, the transaction authorization message for the second amount, to a payment gateway associated with the transaction request for the first transaction amount.
The system and/or computer hardware arrangement may be configured to compute the second transaction amount by calculating a gratuity amount based on, the merchant identifier, the first transaction amount and the one or more user-specified tipping parameters associated with the merchant identifier, and increase the first transaction amount by the gratuity amount calculated. In some examples, the one or more logical operations, derived from one or more user-specified tipping parameters maybe selected from a set of user-specified tipping parameters and input data variables associated a user payment account. The computer hardware arrangement may be configured to access the set of logical operations to compute the second transaction amount, via one or more Application Programming Interface (API) calls.
The system may further comprise a modified user interface to capture one or more user-specified tipping parameters and input data variables, the modified user interface being 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. In some embodiments, the computer hardware arrangement may be further configured to transmit a notification message, via the modified user interface, to prompt for a user confirmation of the second transaction amount.
In some embodiments, the system may be further configured to determine a length of stay, for a user, at a service location of a merchant matching the first merchant category, the length of stay being determined based on real-time navigation and location data retrieved from one or more navigation-related applications running on a mobile device of the user. The computed gratuity amount and the subsequent second and/or final transaction amount may then be automatically increased in proportion to the length of stay at the service location of the merchant.
One aspect of the present disclosure is directed to a non-transitory computer-accessible medium comprising instructions for execution by a computer hardware arrangement, wherein, upon execution of the instructions the computer hardware arrange is configured to perform procedures 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, by a transaction processing server, the first transaction amount with one or more logical operations to compute a second transaction amount, wherein the one or more logical operations are derived from one or more user-specified tipping parameters associated with the merchant identifier, and transmitting, in response to the 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 computation of the second transaction amount may comprises: calculating a gratuity amount based on, the merchant identifier, the first transaction amount and the one or more user-specified tipping parameters associated with the merchant identifier, and increasing the first transaction amount by the gratuity amount calculated.
Various embodiments of the present disclosure, together with further objects and advantages, may best be understood by reference to the following description taken in conjunction with the accompanying drawings.
The following description of embodiments provides non-limiting representative examples referencing numerals to particularly describe features and teachings of different aspects of the invention. The embodiments described should be recognized as capable of implementation separately, or in combination, with other embodiments from the description of the embodiments. A person of ordinary skill in the art reviewing the description of embodiments should be able to learn and understand the different described aspects of the invention. The description of embodiments should facilitate understanding of the invention to such an extent that other implementations, not specifically covered but within the knowledge of a person of skill in the art having read the description of embodiments, would be understood to be consistent with an application of the invention.
As such, conventional processing schemes, for two-step transactions, suffer from two main deficiencies. One drawback of the exiting implementation involves the amount of network traffic generated by requiring two separate communication streams and/or sessions, such as communication sessions 101 and 104. The latter involves a fist set of request and response transmissions (e.g., 102, 103) for an initial transaction amount, and the former involves a second set of request and response transmissions (e.g., 105, 106) for a final transaction amount. Moreover, the issuance of a final transaction validation response (106) generally involves a time delay (107) as the communication session 104 is established at a later time following the completion of information exchange across communication session 101.
Referring back to
The modified user interface (213) may be implemented as part of one or more (modified) mobile applicatin stored on a user mobile device (214), and/or a web interface (216) of a user online account. As described above, the modified user interface (213) serves as an interface for a user to express a tip-computing formula as a function of one or more input parameters. The input parameters may be associated with one or more static coefficients and/or variable data, that may be internally and/or externally collected (e.g., data values corresponding to one or more electronically recorded and tracked user activities).
Some non-limiting examples of internally collected data may include data from applications running on user mobile device such as a Global Positioning System (GPS) based navigation application, and browser plugins that may be installed on a browser application, stored on user device, for tracking user's browsing patterns. Non-limiting examples of externally collected data may include transactional information provided by or retrieved from one or more financial account servers linked to one or more financial instruments associated with the user. The construction and operation of merchant-specific logical expression for automated computation of a final transaction amount is further illustrated and described with reference to
With reference to
Referring back to
A user may also provide a set of logical operators for connecting the inputted parameters into a logical expression. For example, parameter 306, denoted by a triangle symbol, corresponds to set of logical operators used to connect parameters (P1) and (P2), in association with merchant ID1, into the merchant-specific logical expression (310), as illustrated by the embedded block diagram (312). The merchant-specific logical expression (310) provided as a function of the base cost or initial transaction amount (P1) and the length stay (P2) may then be stored, for example, as a distinct data object on the transaction authentication server (340) and/or a database (130) communicatively coupled to the server (340).
With reference to exemplary implementation 300 illustrated in
By inputting various arrangement of logical operators and values of constants coefficients and scaling factors (SF) a user may modify the operations of the tip-computation process. For example, if the user intend to increases 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 may be specified as (0.15*P1)+(5*(P2−1)). The user-inputted parameters and scaling factors, as well as parameter values extracted from a transaction string and/or retrieved from one or more applications tracking user activity, may be communicated from the user mobile and/or computing device (214) to the transaction authentication server (340), across a network data path (308). The network data path (308) may extend across public network 127 and further direct notifications and user prompt messages from the transaction authentication server (340) back to the user mobile and/or computing device (214).
The incorporation of the proposed solution for generating built-in customized tip-calculating functionality into the transaction processing flow can streamline the transaction process on both the merchant and the user end (e.g., facilitating two-step transaction processing instantly via a single communication session, as illustrated in
With regards to the aforementioned optimization of network communication and/or traffic load,
Embodiment 400 illustrates an implementation of a modified scheme for processing two-step transactions using a built-in logical computation module and/or process, such as module 210, that may operate by, for example, using the dataset (403) comprising records of merchant-specific logical tip-computation expressions, such as logical expression/formula 310. Merchant-specific records including the corresponding tip-computation expressions may be stored as distinct data objects within the dataset (403).
In the exemplary embodiment (400) merchant-specific logical expressions, stored in the dataset (403), may correspond to various combination of logical operators, represented as various geometric shapes expressed as a function of set of input parameters (e.g., P1, P2, etc.) and matched with a specific merchant identifier (e.g., ID1, ID2, etc.). The input parameters specified with various logical expressions may be associated with statically inputted and/or dynamically acquired data values.
Referring back to the operation associated with the exemplary system 400, a transaction request message (402), associated with an initial transaction amount, may be received by the transaction authentication server (340), storing the dataset (403). A process running on transaction authentication server 340 (e.g., process 404) may be configured to parse and inspect incoming transaction strings (such as transaction request message 402), to identify transactions associated with a target attribute, and redirect the identified transaction (406) to be matched with a corresponding merchant-specific logical tip-computation expression stored in dataset 403. The target attribute may correspond to an MCC and/or a merchant identifier matching one or more merchant categories and/or service locations associated, for example, with tip-based transactions. The one or more merchant categories and/or service locations may also be specified by the user, an automated process (e.g., process 204 illustrated in
As described above, identification of a two-step transaction may comprise matching a merchant identifier, extracted from a transaction string, to a merchant ID associated with one or more tip-computation logical expressions stored, for example, in the dataset (403). In some embodiments, a process of identifying a target attribute, representative of a two-step transaction, may be applied to a set of transactions (filtered from a plurality of incoming transaction requests (202)) identified as corresponding to one of one or more candidate MCCs (e.g., as represented by transaction data path 208 in
Upon identification of a corresponding tip-computation logical expression, one or more API calls, for retrieving one or more data values corresponding to the input parameters of the identified merchant-specific expression, may be issued. The one or more input data values may comprise data extracted from a transactions string (e.g., initial transaction amount), data acquired via a prompted user input at run time, data associated with operation of one or more applications running on the user mobile and/or computing device (110), and/or a corresponding application server, as well as any data pre-specified as relevant to the calculation of a final transaction amount using an identified merchant-specific logical expression. A final transaction amount may be computed by executing the corresponding merchant-specific logical expression and a transaction validation response (412) for the computed final transaction amount may be transmitted to the transaction-initiating merchant server (120). In accordance to some embodiments, a user confirmation input, prompted at run time, may be required for validating a computed final transaction amount.
According to some embodiments, at step (513) a notification message may be generated and displayed, on the user mobile device, as a user-prompt to create a merchant-specific tip-computation logical expression for the transaction-initiating merchant associated with steps 511 and 512.
If a match, between the extracted merchant identifier and a stored listing of merchant identifiers associated with a logical tip-computation expression is, identified at step (510), the corresponding tip-computation logical expression along with the corresponding input parameter values (identified and retrieved from various sources at step 514) may be used to compute a final transaction amount and/or a gratuity amount (to be added to the initial transaction amount) at step 515, and a transaction validation response for the computed final transaction amount may be transmitted back to the requesting payment gateway (e.g., the transaction-initiating merchant), at step 516.
In the exemplary embodiment 600 a plurality of incoming transaction requests (202) from one or more remote sources (collectively represented as merchant payment gateway (120) in the example 600) are parsed and processed to identify one or more two-step transaction requests (406) which are then redirected for processing with a corresponding merchant-specific logical expression (e.g., stored as a data object in dataset 403) to compute a final transaction amount. Based on the computed final transaction amount, a single validation response, for each of the identified two-step transaction requests, may be transmitted back to each corresponding merchant server (e.g., merchants initiating an initial transaction requests for a two-step transaction), as illustrated by the transaction response (212) in the example 600. In some embodiments, generation of a validation response for a computed final transaction amount may be subject to a confirmation signal from a user. In the exemplary embodiment 600 a user confirmation signal associated with a two-factor strong authentication, may be provided via encrypted authentications information (605) securely stored on the contactless card (110) and read, by the user computing and/or mobile device (214), via the NFC link 606. In this regard, a user, upon being prompted on the mobile device (214) for an authentication input, may bring the contactless card within the NFC range of the mobile device reader (220) to initiate the NFC transmission of encrypted authentication data (605). The encrypted user authentication data (605) may then be transmitted to the transaction authentication server (340) for validation, as shown by the exemplary illustration in
In some embodiments, communications between transaction authentication server (340) and user mobile device 214 (e.g., corresponding to exchange of notification and/or user-prompt request message and confirmation and/or authentication response messages between the authentication server and the mobile device) may occur across the network data session (308) that may also be used, for example, for communication of user-inputted information (608), encrypted user authentication data (605) and system-provided input parameter data values associated with the implementation and execution of merchant-specific logical tip-computation expressions.
As such, in accordance to some embodiments of the present disclosure, the initial transaction request (702) may be directly transmitted, from a portable POS device (704) communicatively coupled with merchant payment gateway (140), to a user computing and/or mobile device (214), via short range communication (135), to be processed by an application (718) running on the user device. Upon receiving the initial transaction request (702), referencing an initial transaction amount, the user may directly input, onto an application interface rendered on the mobile device display, a final transaction amount and/or a gratuity amount to be added to the initial transaction amount. A transaction validation request message (706) comprising the final user-inputted transaction amount, and the one or more user authentication inputs, may then be transmitted to the authentication server (140) for processing. The one or more user authentication inputs may correspond to one or more user identification data records, securely stored on the contactless card (110), and read via an encrypted NFC transmission (605) from the contactless card. Upon verifying the encrypted user authentication information, the transaction authentication server may transmits a transaction validation response (708) for the final transaction amount, to the merchant payment gateway (140).
In some cases, a two-step transaction request may 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 may generate prompted gratuity amount suggestions to the user based on an analysis of pre-defined and/or real-time inputted tip amounts associated with a plurality of other system users. Based on an analysis of this data, an average, minimum and/or maximum tip amount for a particular merchant may be provided to the user—Based on the provided information, the user may enter a different tip amount directly onto the application interface, and/or create or updated a merchant-specific logical expression (e.g., average tip amount, and/or average tip amount scaled by the length of stay and the initial transaction amount.)
As shown in
Further, the exemplary processing arrangement 805 can be provided with or include an input and/or output ports 835, which can include, for example a wired network, a wireless network, the internet, an intranet, a data collection probe, a sensor, etc. As shown in
According to some embodiments, one or more data analytics and machine learning routines may be applied to supplement the computation of the processed user information as described above. This may be supplemented by a use of various prediction models such as ones that can utilize a Bidirectional Encoder Representations from Transformers (BERT) models. BERT models utilize use multiple layers of so called “attention mechanisms” to process textual data and make predictions. These attention mechanisms effectively allow the BERT model to learn and assign more importance to words from the text input that are more important in making whatever inference is trying to be made.
The exemplary system, method and computer-accessible medium can utilize various neural networks, such as convolutional neural networks (CNNs) or recurrent neural networks (RNNs), to generate the exemplary models. A CNN can include one or more convolutional layers (e.g., often with a subsampling step) and then followed by one or more fully connected layers as in a standard multilayer neural network. CNNs can utilize local connections and can have tied weights followed by some form of pooling which can result in translation invariant features.
A RNN is a class of artificial neural network where connections between nodes form a directed graph along a sequence. This facilitates the determination of temporal dynamic behavior for a time sequence. Unlike feedforward neural networks, RNNs can use their internal state (e.g., memory) to process sequences of inputs. A RNN can generally refer to two broad classes of networks with a similar general structure, where one is finite impulse and the other is infinite impulse. Both classes of networks exhibit temporal dynamic behavior. A finite impulse recurrent network can be, or can include, a directed acyclic graph that can be unrolled and replaced with a strictly feedforward neural network, while an infinite impulse recurrent network can be, or can include, a directed cyclic graph that may not be unrolled. Both finite impulse and infinite impulse recurrent networks can have additional stored state, 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 incorporate time delays or can have feedback loops. Such controlled states can be referred to as gated state or gated memory and can be part of long short-term memory networks (LSTMs) and gated recurrent units.
RNNs can be similar to a network of neuron-like nodes organized into successive “layers,” each node in a given layer being connected with a directed e.g., (one-way) 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. Nodes can either be (i) input nodes (e.g., receiving data from outside the network), (ii) output nodes (e.g., yielding results), or (iii) hidden nodes (e.g., that can modify the data en route from input to output). RNNs can accept an input vector x and give an output vector y. However, the output vectors are based not only by the input just provided in, but also on the entire history of inputs that have been provided in the past.
For supervised learning in discrete time settings, sequences 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., result) as a nonlinear function of the weighted sum of the activations of all units that connect to it. Supervisor-given target activations can be supplied for some output units at certain time steps. For example, if the input sequence is a speech signal corresponding to a spoken digit, the final target output at the end of the sequence can be a label classifying the digit. In reinforcement learning settings, no teacher provides target signals. Instead, a fitness function, or reward function, can be used to evaluate the RNNs performance, which can influence its input stream through output units connected to actuators that can affect the environment. Each sequence can produce an error as the sum of the deviations of all target signals from the corresponding activations computed by the network. For a training set of numerous sequences, the total error can be the sum of the errors of all individual sequences.
The models described herein may be trained on one or more training datasets, each of which may comprise one or more types of data. In some examples, the training datasets may comprise previously collected data from a plurality of system users. Previously collected user data may correspond to a user transactional activity analyzed in conjunction, for example, with navigation data from a user mobile device. In other examples, the training datasets may comprise continuously-collected data based on the current operation of the instant system and continuously-collected data from the operation of other systems (e.g., real-time tracking of electronic transaction data and the data from a user's GPS application.) In some examples, the training dataset may include anticipated data, such as the anticipated future travel pattern and purchasing action pattern, currently scheduled workloads, and planned future workloads, for the instant system and/or other systems. In other examples, the training datasets can include previous predictions for the instant system and other types of system and may further include results data indicative of the accuracy of the previous predictions. In accordance with these examples, the predictive models described herein may be training prior to use and the training may continue with updated data sets that reflect additional information.
The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations can be made without departing from its spirit and scope, as may be apparent. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated herein, may be apparent from the foregoing representative descriptions. Such modifications and variations are intended to fall within the scope of the appended representative claims. The present disclosure is to be limited only by the terms of the appended representative claims, along with the full scope of equivalents to which such representative claims are entitled. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting.
It is further noted that the systems and methods described herein may be tangibly embodied in one of more physical media, such as, but not limited to, a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a hard drive, read only memory (ROM), random access memory (RAM), as well as other physical media capable of data storage. For example, data storage may include random access memory (RAM) and read only memory (ROM), which may be configured to access and store data and information and computer program instructions. Data storage may also include storage media or other suitable type of memory (e.g., such as, for example, 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 cartridges, flash drives, any type of tangible and non-transitory storage medium), where the files that comprise an operating system, application programs including, for example, web browser application, email application and/or other applications, and data files may be stored. The data storage of the network-enabled computer systems may include electronic information, files, and documents stored in various ways, including, for example, a flat file, indexed file, hierarchical database, relational database, such as a database created and maintained with software from, for example, Oracle® Corporation, Microsoft® Excel file, Microsoft® Access file, a solid state storage device, which may include a flash array, a hybrid array, or a server-side product, enterprise storage, which may include online or cloud storage, or any other storage mechanism. Moreover, the figures illustrate various components (e.g., servers, computers, processors, etc.) separately. The 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 also may be made.
In the preceding specification, various embodiments have been described with references to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded as an illustrative rather than restrictive sense.
