JP6546249B2 - Method and system for executing a transaction request using a communication channel - Google Patents

Description

This application claims the priority of Indian Non-provisional application specification filed on January 11, 2017, the complete disclosure of which in its entirety is hereby incorporated by reference. It is incorporated.

  The present application relates generally to the field of secure information transactions. Although not specific, in particular, the present invention provides systems and methods for securely executing transaction requests using a communication channel such as SMS or email.

  In a corporate environment, various scenarios exist when a request is generated. This request may be communicated by various modes of communication such as email, messages, websites, servers, calls, etc. These requests may contain a large amount of critical and important information. In some cases, these pieces of information require prompt and timely attention. Also, much sensitive data is also communicated, so the information communicated through these channels must be secure. Requests are generated in the system either proactively or reactively by the user. These requests need to be accompanied by a trusted stakeholder such as a high-level or manager before being accompanied.

  In such cases, current practice involves trusted stakeholders accessing their desktops or laptops, logging into the system, going to the web location or path where the request is delivered, taking action on the request . However, there are various scenarios in which the desktop is not accessible to high-ranking persons. This results in delays from trusted stakeholders in following requests. In case of emergency, it is required that the system / framework be able to provide the user with the ability to take action from other channels besides desktop / laptop.

  Generally, the information is available in a graphical system, but the user needs to search the records to accompany the request for action. Although existing communication via email or SMS is supported, channels are used passively when they are not viable. Furthermore, data security can be compromised across these channels. There is also a need for portable applications that can be easily carried on smartphones. Building portable applications for smartphones and tablets requires additional effort and can be complicated based on the current design of the ERP. In existing systems, even if the user already has information communicated via other channels, the user still has to go through a redundant number of steps to take action.

  The following presents a simplified summary of some embodiments of the present disclosure in order to provide a basic understanding of the embodiments. This summary is not a detailed summary of the embodiments. It is not intended to identify key / critical elements of the embodiments or to delineate the scope of the embodiments. Its sole purpose is to present some embodiments in a simplified form as a prelude to the more detailed description that is presented below.

  In view of the foregoing, one embodiment herein provides a system for executing transaction requests using a communication channel. The system comprises a memory, a transaction engine, a database and a processor. The transaction engine sends a transaction request. The transaction request includes a transaction request ID, a transaction type, a user ID, an organization ID, a short code, a reply capture ID code (RCID code) and a message. The database stores transaction requests. The processor further includes a short code verification module, an RCID code check module, an RCID code verification module, a user verification module, a fetch module, a calling module, and an execution module. The short code verification module checks the validity of the short code in the transaction request. The RCID code check module checks the presence of the RCID code in the transaction request. The RCID code verification module checks the validity of the RCID code in the transaction request if the RCID code is present. The user verification module checks the validity of the user using the user ID. The fetch module fetches a message from a transaction request. The calling module calls a solution specific API for processing the transaction by passing the fetched message from the transaction request. The execution module executes the transaction and sends a success-failure response to the user indicating the transaction request status.

  Another embodiment provides a method of executing a transaction request using a communication channel. Initially, transaction requests are accepted from the transaction engine. The transaction request includes a transaction request ID, a transaction type, a user ID, an organization ID, a short code, a reply capture ID code (RCID code) and a message. In the next step, the validity of the short code in the transaction request is checked. If the short code is not valid, an error message is sent. If not, in the next step, the presence of the RCID code is checked in the transaction request. In the next step, if the RCID code is present, the validity of the RCID code is checked in the transaction request. If the RCID code is not valid, an error message is sent. If this is not the case, in the next step, the validity of the user is checked using the user ID. If the user is not valid, an error message is sent. In the next step, messages are fetched from the transaction request. In the next step, passing the fetched message from the transaction request invokes a solution specific API for processing the transaction. Finally, a transaction is performed and a success-failure response indicating the transaction request status is sent to the user.

  In yet another embodiment, the non-transitory computer readable medium stores instructions that, when executed by a processor on a system, cause the processor to perform a method of executing a transaction request using the communication channel. Initially, a transaction request is accepted from the transaction engine. The transaction request includes a transaction request ID, a transaction type, a user ID, an organization ID, a short code, a reply capture ID code (RCID code) and a message. In the next step, the validity of the short code in the transaction request is checked. If the short code is not valid, an error message is sent. Otherwise, in the next step, the presence of the RCID code is checked in the transaction request. In the next step, if the RCID code is present, the validity of the RCID code in the transaction request is checked. If the RCID code is not valid, an error message is sent. If this is not the case, in the next step, the validity of the user is checked using the user ID. If the user is not valid, an error message is sent. In the next step, messages are fetched from the transaction request. In the next step, passing the fetched message from the transaction request invokes a solution specific API for processing the transaction. Finally, a transaction is performed and a success-failure response indicating the transaction request status is sent to the user.

  It is understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the claimed invention.

  Embodiments of the present invention will be better understood from the following detailed description with reference to the drawings.

FIG. 1 illustrates a block diagram of a system for executing transaction requests using a communication channel in accordance with some embodiments of the present disclosure. FIG. 2 shows a schematic diagram of a system for executing transaction requests using SMS and email according to some embodiments of the present disclosure. FIG. 2 shows a schematic diagram of a system for executing transaction requests using SMS and email according to some embodiments of the present disclosure. FIG. 2 shows a schematic diagram of a system for executing transaction requests using SMS and email according to some embodiments of the present disclosure. FIG. 3 is a flowchart illustrating steps involved in executing a transaction request using a communication channel, according to some embodiments of the present disclosure.

  Embodiments of the present specification and its various features and advantageous details are described more fully with reference to the non-limiting embodiments set forth in the accompanying drawings and described in the following detailed description. . The examples used herein are merely to facilitate an understanding of the manner in which the embodiments herein are practiced and further enabled to enable one skilled in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

  Referring now to the drawings, and in particular to FIG. 1, like reference characters indicate corresponding features consistently throughout the drawings, and preferred embodiments are illustrated, which preferred embodiments are illustrative of the following exemplary systems and And / or described in the context of the method.

  According to some embodiments of the present disclosure, a system 100 for performing transaction requests using communications is illustrated in the block diagram of FIG. The present disclosure provides a proactive / reactive smart response processing system / framework that offers the user the possibility to take action from any channel other than the desktop. The system also handles authentication by generating a unique key and incorporating it as part of the response, thereby ensuring that the action was taken from a trusted source. The framework has a mapping by integrating solutions to business logic, which is invoked based on the provided responses.

  System 100 includes a transaction engine 102, a baseline 104, a memory 106, and a processor 108 in communication with the memory 106 as shown in the block diagram of FIG. Memory 106 is configured to store a plurality of algorithms. Processor 108 further includes a plurality of modules for performing various functions. The plurality of modules access a plurality of algorithms stored in the memory 106 to perform various functions. A plurality of modules execute the RCID code generator 110, the short code verification module 112, the RCID code check module 114, the RCID code verification module 116, the user verification module 118, the fetch module 120, the calling module 122, and the execution. And a module 124.

  According to some embodiments of the present disclosure, transaction engine 102 is configured to generate a transaction request. Transaction engine 102 is typically controlled by the user. Transaction requests can be generated proactively or reactively. In one embodiment, the transaction request comprises a transaction request ID, transaction type, user ID, organization ID, short code, reply capture ID code (reply capture ID code (RCID code)) and a message. The short code and reply capture ID code (RCID code) are an essential part of the transaction request. However, it should be understood that the remaining components of the transaction request can be customized according to the user's request. These transaction requests are stored in the database 104. Transaction requests may also be fetched on demand.

  The RCID code is a unique alphanumeric eight-digit character code. The RCID code is a unique and arbitrary alphanumeric string. The RCID code is generated by the RCID code generator 110. The RCID code is stored in the database 104 along with other transaction details such as transaction type, transaction ID, user ID, organization ID, solution ID etc. Once the RCID code is generated, the database 104 is queried to check the uniqueness of the RCID code and is further embedded in the notification sent for the transaction. The RCID code expires after its consumption.

  The short code is a unique code that is put into the database 104 upon integration with the solution for the business logic to be implemented when the action is taken in a transaction request. The short code is fetched from the table embedded in the notification as the subject.

  According to some embodiments of the present disclosure, when a transaction request is generated, the short code verification module 112 checks the validity of the short code present in the transaction request. If the short code is not valid, the processor 108 sends an error report back to the user. In the embodiment, in the short code, '**' is added at the beginning when transmitting the communication. Thus, the short code validation module 112 looks for '**' in the subject, and the post '**' is taken as part of the short code. Examples of short codes may be WF for workflow, HD for help desk, etc.

  According to some embodiments of the present disclosure, if the short code is valid, the RCID code check module 114 checks the presence of the RCID code in the transaction request. If the RCID code does not exist, an error report is sent back to the user. If the RCID code is present, the RCID code check module 114 checks the presence and validity of the RCID code. It should be appreciated that in another embodiment, if the RCID code is not present, the transaction request is a proactive request, otherwise it is assumed to be a reactive request.

  The RCID code verification module 116 first queries the RCID code table to check if the RCID code is present in the RCID code table. The RCID code table is a table consisting of all the RCID codes generated most recently. Whenever an action is taken, the RCID code is consumed or within 15 days the RCID code is consumed. Thus, upon fetching the RCID code, the table is queried to check if the RCID code is present. If there is, processing proceeds, otherwise an error report is sent to the user notifying that the RCID code is not valid. According to some embodiments of the present disclosure, if the RCID code is not present in the transaction, the user is enabled to ensure that the transaction came from a trusted person to whom the message was actually sent. Is performed by the user activation module 118 (in the case of a reactive request). Thus, the user ID stored at the time of RCID code generation is queried to fetch the communication ID tagged to the user. The communication ID may be an email ID or a mobile number depending on the communication type. The communication ID from which the response has been accepted is checked. If both communication IDs are identical, the transaction message is considered to be trustworthy, otherwise an error report is sent to the user.

  According to some embodiments of the present disclosure, there is no RCID code for proactive transaction requests, as described above, and thus RCID verification module 116 is not required in the case of proactive transaction requests. . In such case, the user verification module 118 checks if the communication ID is registered in the system and ensures that the transaction request is from an authenticated user. If registered, this transaction request is further processed to take action, otherwise a user friendly message is sent to the end user and the communication ID has not been registered in the system. means.

  According to some embodiments of the present disclosure, system 100 further includes a fetch module 120, a call module 122, and an execution module. The fetch module 120 fetches an action item from the transaction request when all the conditions are met, that is, the transaction request has a valid RCID code, a valid short code, and the user is a valid user. The invocation module 122 is configured to invoke a solution specific API to process the transaction by passing the fetched message from the transaction request. The execution module 124 is then configured to execute the transaction. The short code is interrogated in a table and the business logic class mapped to this code is fetched and executed as an input in the message xml. Depending on the final status of the transaction request, the execution module 124 is also configured to send a success or failure response to the user, indicating the transaction request status.

  According to some embodiments of the present disclosure, transaction requests are processed via a centralized ERP solution API stack 138, as shown in FIG. Many ERP systems use various interfaces to communicate and interact with end users. Each module of the system is designed with the management of the information in mind and systematically presents each module to take appropriate action for the user. Conventionally, this information is presented in a graphical interface using a web or client based application. This is important for users who are authenticated and authorized with a password to take action on a given request. The present invention helps to realize a portability and user friendly approach to interact with the system. This allows end users to configure the experience, and the multi-tenant architecture allows the same commercial implementation to be implemented across different organizations.

  In operation, a flowchart 200 is shown in FIG. 2 that shows the steps involved in performing a transaction request using a communication channel. Initially, at step 202, a transaction request is received from transaction engine 102. The transaction request may be a proactive request or a reactive request. The transaction request includes a transaction request ID, a transaction type, a user ID, an organization ID, a short code, a reply capture ID code (RCID code) and a message.

  At step 204, the validity of the short code in the transaction request is checked by the short code verification module 112 residing in the processor 108. At step 206, if the short code is not valid, an error message is sent to the user and at step 208 the presence of the RCID code in the transaction request is checked by the RCID code check module 114. At step 210, if the RCID code is present, the validity of the RCID code in the transaction request is checked by the RCID code verification module 116. At step 206, an error message is sent indicating that the RCID code is not valid. At step 212, the user verification module 118 checks the validity of the user using the user ID. At step 206, an error message is sent indicating that the user is not valid.

  At the next step 214, when all the checks are complete, the message from the transaction request is fetched by the fetch module 120 for further processing. At step 216, the solution specific API is called to process the transaction by passing the fetched message from the transaction request. Finally, at step 218, the transaction is executed and sends a success-failure response to the user indicating the transaction request status.

  According to some embodiments of the present disclosure, system 100 is integrated with SMS (Short Message Service) by mobile phone as a channel and e-mail by Internet, whereby it takes time to perform portability and actions. Provide no environment. However, it should be understood that other communication facilities, such as voice calls, online messaging services, etc., are also well within the scope of the present disclosure.

  According to some embodiments of the present disclosure, system 100 may be integrated into email as a communication channel, as shown in the schematic of FIG. In this case, the transaction is made in the form of e-mail / e-mail ID. The request may be reactive or proactive. In the case of a proactive request, the user responds to email / mail receipt. Email from the user arrives at the email reply capture mailbox 126. Mailboxes are polled every 15 minutes using an email parser 128. The e-mail parser 128 is a java (registered trademark) -based scheduler, and checks whether there are unprocessed e-mails in the mailbox. If an unhandled email is found, the email is chosen to be processed. Similarly, in the case of a proactive request, the email is initiated by the user and sent to the email reply capture mailbox 126. Mail is chosen by the java based scheduler to process. In the next step, the email reply capture core processing framework 130 or email processor 130 reads the email and looks for a short code in the subject. It should be understood that the email processor 130 is identical to the processor 108 described in the embodiment of FIG. The short code (e.g., WF for workflow, HD for help desk) is preceded by '**' when sending the communication. Thus, the email processor 130 looks for '**' in the subject, and the post '**' is taken as part of the short code.

  In the next step, when the short code is checked, the validity for the short code is checked by doing a lookup in the table for the short code. If a valid entry for the short code exists in the database 104 and the class exists for the short code, the email processor 130 is advanced for further processing, otherwise it fails. A message is sent to the end user indicating that the short code sent in the mail is not valid.

  In the next step, the mail is processed to fetch the RCID code from the mail. The entire mail is read and look for the RCID code. As the RCID code, “Reply Capture Id” is added, followed by an RCID code such as “KgOAP dB4”. The email processor 130 looks for the string "Reply Capture Id:" and any character post, which is taken as the RCID code. If there is no RCID code, the email is considered for proactive use and is taken for further processing. If the RCID code is fetched from mail, a verification is made to ensure that the RCID code is valid. This is done by a first query of the table to check if the RCID code is present in the table. Whenever an action is taken, the RCID code is consumed, or the RCID code is consumed within 15 days, so the table is queried to check if the RCID code is present. If the RCID code is present, processing proceeds, otherwise, a message is sent to the user meaning that the RCID code is not valid.

  In addition, if the RCID code is present in the table, further validation is done to ensure that the email response has come from the trusted person to the person to whom the email was actually sent. For this reason, the user Id stored in the table at the time of RCID code generation is inquired to fetch the email Id tagged to this user, and the email Id for which the response is accepted is checked. If the email Ids are identical, the user is considered as a trusted user, otherwise a failure message is sent to the end user. In the case of proactive use, there is no RCID code and hence no RCID code verification check. In such a case, it is checked that the mail Id is registered in the email reply capture core processing framework 126 to ensure that the mail came from an authenticated user. If registered, this email is processed to take further action, otherwise the end user is a user friendly message which means that the email Id to take action is not registered Send to

  In the next step, the caption or action item is fetched from the mail if all the verifications described above are successful. This is the first line of the mail text. The first line of mail body is processed and taken as caption, xml is prepared by caption, RCID code. The short code is queried in a table, the business logic class mapped to this short code is fetched, and executed with the message xml as input. The entire business logic is executed, and based on the action taken, success and failure responses are sent back to the user, meaning the status of the action. Finally, when the action is taken, the mail is deleted from the mailbox and the RCID code is also deleted from the database 104.

  According to another embodiment of the present disclosure, system 100 may also be integrated with Short Messaging Service (SMS) as a communication channel as shown in the schematic of FIG. In this case, the transaction is made in the form of an SMS using the mobile number. As mentioned above, SMS transaction requests may be reactive or proactive requests. In the case of a reactive request, the user responds to the accepted SMS by sending a response to the Virtual Mobile Number (VMN) described in the communication accepted by the user. The response from the user is fetched and translated into response XML with details being login ID, password, mobile number, VMN number, organization ID and response text message. XML is passed as input to the SMS Reply Capture Core Processing Framework 132 or service class exposed by the SMS processor 132. The SMS Reply capture core processing framework 132 is identical to the processor 108 described in the embodiment of FIG. In the case of a proactive request, the SMS is initiated by the user and sent to the VMN number. The SMS from the user is fetched and translated into response XML with details being login ID, password, mobile number, VMN number, organization ID and response text message. XML is passed as an input to the service class exposed by the SMS Reply Capture Core Processing Framework 132.

  In the next step, once the XML is accepted by the service class, the XML is parsed using an SMS parser, and the data in xml is stored in a java based data collection object. In addition, the login ID / password is checked to ensure that the response / message for processing comes from a trusted source. If the login ID and password do not match, an error message is sent to the user.

  In the next step, when the login ID / password matches, the table is queried with details like the mobile number to ensure that the reply comes from the authenticated user. If the mobile number is registered in the table, the message is moved for further processing, otherwise an error is returned and sent to the user. The organization ID mapped to this mobile number is also fetched for further processing. Furthermore, if the mobile number is validated to be a registered valid number, the VMN number present in the response is checked as configured for the organization. Thus, the database 104 is queried to check the mapping of VMN numbers and organization IDs fetched from mobile numbers. If the VMN number mapping can not be found, an error is updated to the database during SRC processing.

  In the next step, once verified, the SMS Reply Capture Core Processing Framework 132 reads the SMS and looks for the short code in the message body. The short code (eg, WF for workflow, HD for help desk) is fetched by the SMS reply capture core processing framework 132. The notification is sent to the user, but the format of the response expected from the end user is also mentioned. Hence, the SMS's first keyword is fetched as a short code and taken for further processing.

  In the next step, when the short code is checked, the validity for the short code is checked by performing a lookup in the short code table. If a valid entry exists in the short code database 104 and the class exists for the short code, then the SMS Reply capture core processing framework 132 proceeds with further processing, otherwise it A failure message is sent to the end user indicating that the short code sent to the mail is not valid. Along with the short code, there is a mapping maintained in a table for whether the short code is a case of proactive or reactive use. This flag is fetched for short code.

  In the next step, if the request is a proactive request, the organization ID and user ID are extracted from the mobile number, and the input xml is all captured, such as organization ID, user ID, short code etc. Generated in detail. In the case of a reactive request, the SMS is processed to fetch the RCID code. If the RCID code is present in the table, further processing is done, otherwise a failure message is sent to the user. If the RCID code is fetched from the SMS, verification is done to ensure that the RCID code is valid. This is done by first querying the table to check if the RCID is present in the table. Whenever an action is taken, the RCID code is consumed, or the RCID code is consumed within 15 days, so upon fetching the RCID, the table is queried to check if the RCID is present. If yes, processing proceeds, otherwise, a message is sent to the user, meaning that the RCID code is not valid.

  In the next step, if the RCID code is present in the table, further verification is done to ensure that the response comes from the trusted person who actually sent the mail. For this reason, the user Id stored in the table at the time of RCID code generation is inquired to fetch the mobile number tagged to this user, and the mobile number for which the response is accepted is checked. If both numbers are identical, the mail is considered as a trusted mail and processed, otherwise a failure message is sent to the user. In the case of a proactive request, there is no RCID code and hence no RCID code verification check. In such cases, it is checked that the mobile number is registered with the SMS Reply Capture Core Processing Framework 132 to ensure that the SMS is coming from an authenticated user. If registered, the SMS is further processed to take an action, otherwise a user-friendly message is sent to the end user meaning that the mobile number is not registered to take an action Be done. Finally, the captions (actions) are fetched from the mail if all the verifications described above are successful. Captions are fetched and xml is prepared with captions, RCID code etc. The short code is queried in a table, and the business logic class mapped to this short code is fetched and executed as an input in the message xml. The entire business logic is executed, and based on the action taken, success and failure responses are sent back to the user, meaning the status of the action.

  The detailed description set forth describes the subject matter herein in order to enable those skilled in the art to make and use the embodiments. The scope of the subject embodiments is defined by the claims, and may include other modifications that occur to those skilled in the art. Such other changes include if they have similar elements that do not differ from the wording of the claims, or if they contain equivalent elements that do not differ substantially from the wording of the claims. Are intended to be included within the scope of the appended claims. Thus, embodiments provide systems and methods for securely executing transactions using a communication channel.

  However, the scope of protection is extended to such programs, in addition to computer readable means having a message therein, such non-transitory computer readable storage means being a server or mobile device or any suitable programmable It should be understood to include program code means for implementing one or more steps of the method when the program is run on the device. The hardware device can be any type of device that can be programmed, including, for example, any type of computer such as a server or a personal computer, or any combination thereof. This device may also include, for example, hardware means, such as an application specific integrated circuit (ASIC), field programmable gate array (FPGA), or a combination of hardware means and software means, such as ASIC and FPGA, or at least one. Also included are means, which may also be at least one memory, comprising two microprocessors and software modules therein. That is, these means can include both hardware means and software means. The method embodiments described herein can also be implemented in hardware and software. The device may also include software means. Alternatively, the implementation may be implemented on different hardware devices, for example using multiple CPUs.

  Embodiments herein can include hardware and software components. Embodiments implemented as software include, but are not limited to, firmware, resident software, microcode, etc. The functions performed by the various modules described herein may be implemented in other modules or in combinations of other modules. For the purpose of this description, a computer usable medium or computer readable medium comprises, stores, communicates, conveys or transports a program for use by or in connection with an instruction execution system, apparatus or device. It can be any device that can do that.

  The medium may be an electronic, magnetic, optical, electromagnetic, infrared or semiconductor system (or apparatus or device) or a propagation medium. Examples of computer readable media include semiconductor or solid state memory, magnetic tape, removable computer diskettes, random access memory (RAM), read only memory (ROM), rigid magnetic disks and optical disks. Current examples of optical disks include compact disk read only memory (CD-ROM), compact disk read / write (CD-R / W) and DVD.

  A data processing system suitable for storing and / or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory component provides temporary storage of local memory, mass storage and at least some program code utilized during actual execution of the program code to retrieve code from mass storage during execution. It can include cache memory to reduce the number of times it has to do.

  Input / output (I / O) devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system directly or through intervening I / O controllers. A network adapter may also be coupled to the system to allow the data processing system to couple to other data processing systems, remote printers, or storage devices through intervening private or public networks. Modems, cable modems and Ethernet cards are just a few of the currently available types of network adapters.

  A representative hardware environment for practicing the embodiments may include the hardware configuration of an information processing / computer system according to the embodiments herein. The system herein includes at least one processor or central processing unit (CPU). The CPU is interconnected via a system bus to various devices such as random access memory (RAM), read only memory (ROM) and input / output (I / O) adapters. The I / O adapter can be connected to peripherals such as disk units and tape drives or other program storage devices readable by the system. The system can read instructions according to the invention on a program storage device and execute the methodology of the embodiments herein according to these instructions.

  The system further includes a user interface adapter that connects the bus to other user interface devices such as a keyboard, mouse, speaker, microphone and / or touch screen device (not shown) to collect user input. Further, the communication adapter connects the bus to the data processing network, and the display adapter connects the bus to a display device, which may be implemented as an output device such as, for example, a monitor, a printer, or a transmitter. The foregoing description has been presented with reference to various embodiments. Those skilled in the art to which this application relates will appreciate that changes and modifications in the described structure and method of operation may be practiced without significant deviation from the principles, spirit and scope. The present disclosure and examples are considered as exemplary only, and the true scope and spirit of the disclosed embodiments are intended to be indicated by the following claims.

Claims (10)

A method of executing a transaction request using a communication channel, said method comprising
Generating a transaction request by a transaction engine, wherein the transaction request is at least one of a proactive transaction request and a reactive transaction request, and in the case of the reactive transaction request, the user is Responding to an email or short message service (SMS) accepted from the transaction engine via the communication channel to execute a reactive transaction request, wherein the user responds to the proactive transaction request by the communication channel Send an email or SMS through the transaction engine by communicating via The pro starts generating active transaction request, wherein the communication channel includes an e-mail channel or SMS channel, said transaction request, user identification depending on the type of the transaction request (ID), short code, reply captured by the A step including an ID code (RCID code ) ;
Checking the validity of the short code in the transaction request, sending an error message if the short code is not valid;
Checking the presence of the RCID code in the transaction request;
Checking the validity of the RCID code in the transaction request if the RCID code is present, sending the error message if the RCID code is not valid;
When the said transaction request is the proactive transaction request or the reactive transaction request, a step of checking the validity of the user by Rukoto using the user ID, the wherein when the user is not valid, Sending the error message,
The first line of the body of the email containing one or more action items by an email parser, or the SMS is fetched by an SMS parser and verified from the first line of the body of the email or Step of preparing xml from SMS
Calling a solution specific API for processing the transaction by querying the database table for the short code from the transaction request to fetch a business logic class mapped to the short code ;
How and transmitting a failure response to the user, which is a processor implemented comprising - the business logic class and using the xml execute the transaction success showing a transaction request status. The method according to claim 1, wherein the proactive transaction request is processed as verifying the authenticity of the user based on the respective email or SMS . The further example Bei the step of polling the at least one message box containing the transaction request received from the transaction engine, the message box is mailbox, to the reactive transaction request, the mailbox, the mail The email is polled at predetermined time intervals through the email parser to check for pending emails in the box, and if there are pending emails, the email is processed for processing In the case of the proactive transaction request, the email is selected by the user and sent to an email reply capture mailbox, and the email is processed by the scheduler for processing. Te chosen method of claim 1. The method of claim 1, further comprising: deleting the transaction request from the one or more message boxes and deleting a corresponding RCID after execution of the transaction request .   The method of claim 1, wherein the transaction is processed via a centralized ERP system. A system for executing transaction requests using a communication channel, comprising:
With memory
Generates a transaction request by the transaction engine, said transaction request is at least one of proactive transaction request and reactive transaction request, wherein in the case of reactive transaction request, the user, the reactive In response to the email or short message service (SMS) accepted from the transaction engine via the communication channel to execute a transaction request, the user responds to the proactive transaction request via the communication channel By transmitting email or SMS via the transaction engine by communicating Starts generating active transaction request, wherein the communication channel includes an e-mail channel or SMS channel, the transaction request, the user identification depending on the type of transaction request (ID), short code, the reply capture the ID code (RCID code) seen including, receives a response from the user when the transaction request is said reactive transaction request, and the transaction engine,
A database storing the transaction request;
A processor coupled to the memory;
The memory is
A short code verification module for checking the validity of the short code in the transaction request;
An RCID code check module that checks the presence of the RCID code in the transaction request;
An RCID code verification module that checks the validity of the RCID code in the transaction request if the RCID code is present;
A user who checks the validity of the user using the user ID when the transaction request is the proactive transaction request or the reactive transaction request, and sends an error message when the user is not valid A verification module,
The first line of the body of the email containing one or more action items by an email parser, or the SMS is fetched by an SMS parser and verified from the first line of the body of the email or With fetch module to prepare xml from SMS ,
A calling module that invokes a solution specific API for processing a transaction by querying the database table for the short code from the transaction request to fetch a business logic class mapped with the short code ;
An execution module that executes the transaction using the business logic class and the xml and sends a success-failure response indicating the transaction request status to the user;
system. 7. The system of claim 6 , wherein the RCID code is an eight character alphabet string. 7. The system of claim 6 , wherein the RCID code is configured to be revoked after completion of the transaction. An email reply capture mailbox for accepting the email as the response from the user in response to the reactive transaction request, or for accepting the email as a notification for the start of the proactive transaction request; E-mail polled for a predetermined period of time to check for e-mail presence, and if there are outstanding e-mails in the e-mail reply capture mailbox, select e-mails to process outstanding e-mails further comprising: a parser, wherein the processing the e-mail, by the processor includes reading the e-mail in order to check the presence of the short code in the subject line of the e-mail for processing, billing The system according to 6. A non-transitory computer readable medium storing instructions that, when executed by a processor on a system, cause the processor to perform a method of executing a transaction request using a communication channel,
Generating a transaction request by a transaction engine, wherein the transaction request is at least one of a proactive transaction request and a reactive transaction request, and in the case of the reactive transaction request, the user is Responding to an email or short message service (SMS) accepted from the transaction engine via the communication channel to execute a reactive transaction request, wherein the user responds to the proactive transaction request by the communication channel Send an email or SMS through the transaction engine by communicating via The pro starts generating active transaction request, wherein the communication channel includes an e-mail channel or SMS channel, said transaction request, user identification depending on the type of the transaction request (ID), short code, reply captured by the A step including an ID code (RCID code ) ;
Checking the validity of the short code in the transaction request, sending an error message if the short code is not valid;
Checking the presence of the RCID code in the transaction request;
Checking the validity of the RCID code in the transaction request if the RCID code is present, sending the error message if the RCID code is not valid;
Checking the validity of the user using the user ID when the transaction request is the proactive transaction request or the reactive transaction request, and the error is not valid if the user is not valid Send a message, and
The first line of the body of the email containing one or more action items by an email parser, or the SMS is fetched by an SMS parser and verified from the first line of the body of the email or Step of preparing xml from SMS
By querying the short code from the transaction request in a database table to fetch the business logic classes the short code and a map, a step of invoking a solution specific API for processing transactions,
Executing the transaction using the business logic class and the xml and sending a success-failure response to the user indicating a transaction request status.

Images