Authorization of mobile OTP based transactions

Abstract

Embodiments of the present disclosure relate to methods and systems for authenticating and authorizing a mobile one-time password (m-OTP) based transaction. A cardholder (101) can generate the m-OTP in an issuer mobile application (301) and enter in a checkout page for completing the transaction. Once the m-OTP is entered, a merchant system (104) generates a transaction message that includes the m-OTP and a unique identifier indicating that the transaction message includes the m-OTP. Submitted to a directory server (106), the directory server sends the transaction message to an issuer system (107) for authentication and authorization. The issuer system (107) generates a response message that includes a result of the authentication and authorization of the transaction message. The directory server (106) routes the response message to the merchant system (104) via the acquirer system (105).

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Application No. 16 / 502,117, filed July 3, 2019, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to electronic transactions, and more specifically to transactions authorized using mobile one-time passwords (mOTPs). Background Technology

[0004] During payment transactions using payment cards (such as credit cards, debit cards, or stored-value cards), it is important to verify the cardholder's ownership of the account to avoid various problems, such as unauthorized use. Payer authentication is the method of verifying the cardholder's ownership of the account. After authenticating the cardholder, authorizing the transactions made by the cardholder is also important.

[0005] Transactions where a consumer payment device is presented to a merchant or accessed by a point-of-sale terminal are called “cardpresent” transactions because the payment device is in the same physical location as the merchant or terminal.

[0006] In addition to card transactions, consumers can also initiate transactions where the payment device and the merchant or terminal are not in the same physical location, but the relevant data is actually provided to the merchant via a communication network (this is called a "card notpresent" transaction). For example, a consumer can initiate a cardless transaction involving the purchase of products or services by providing payment data from a remote location to a merchant via a network such as the Internet. This type of transaction is typically initiated using a computing device such as a personal computer or laptop computer. Card not present transactions can also be initiated or executed using mobile payment devices such as mobile phones, in which case communication with the merchant or data processing system may occur via cellular or wireless networks. Therefore, the payment information for the transaction can be provided using payment devices and point-of-sale terminals, or it can be provided to the merchant using remotely located payment devices and other methods.

[0007] One method for verifying a cardholder's ownership of an account during a card transaction involves a merchant representative taking the cardholder's card, swiping it at a payment card terminal to verify account status and credit availability, and then checking if the signature on the back of the card matches the purchaser's signature. This signature comparison provides authentication of account ownership. If the merchant follows specific guidelines for this type of transaction, they receive a payment guarantee on the authorized amount minus discounts and fees.

[0008] On the other hand, "cardless" transactions, such as those occurring online via mobile devices, email, or telephone, involve payments without guarantees to merchants. Online transactions include, for example, transactions conducted via the Internet. The lack of guarantees stems primarily from the fact that the payer is not authenticated in such non-face-to-face transactions, allowing numerous risks to accompany "cardless" transactions. These risks include, for example, refunds for payments made to online merchants, fraud against both merchants and cardholders, increased fees for handling irregularities by banks, and growing perceptions that purchasing goods and services online or via mobile devices is unsafe, which may deter some consumers from online shopping. Other examples of these risks include unauthorized use of stolen account information to purchase goods and services online, forged card numbers for fraudulent online purchases, and the extraction of plaintext account information from web traffic.

[0009] For example, existing technologies used to authenticate a cardholder's identification of a card for cardless transactions, such as static PINs, one-time PINs (OTPs), or ATM PINs, require telecommunications network support. Therefore, transactions are often rejected and / or timed out due to network delays or malfunctions. This is especially true when transactions cannot be completed in mountainous areas or locations with poor network connectivity.

[0010] Therefore, a secure and efficient method is needed to authenticate cardless transactions that is not easily affected by delays or failures in telecommunications networks.

[0011] The information disclosed in this Background section of this disclosure is intended only to enhance the understanding of the general background of this disclosure and should not be construed as an admission that this information constitutes prior art known to those skilled in the art or any form of implication. Summary of the Invention

[0012] In some non-limiting embodiments or aspects, a computer-implemented method for authorizing transactions is proposed. The method includes receiving transaction messages, such as Payment Authentication Request (PAReq) messages, from an acquiring system via a directory server for authenticating and authorizing the transaction. The transaction message includes a mobile one-time PIN (m-OTP). In some non-limiting embodiments or aspects, the m-OTP is generated by a cardholder using an issuing mobile application configured in the cardholder's device. In some non-limiting embodiments or aspects, the m-OTP is entered by the cardholder into a merchant system. The merchant system generates a transaction message including the m-OTP and provides the transaction message to the acquiring system for authentication and authorization. The method also includes sending the transaction message to the issuing system for authentication and authorization. Subsequently, a response message is received from the issuing system, the response message including the result of the authorization and authentication. The method also includes providing the response message to the merchant system via the acquiring system.

[0013] In some non-limiting embodiments or aspects, a directory server is proposed. The directory server is configured to facilitate authorization transactions. The directory server includes one or more processors and one or more computer-readable media communicatively coupled to said one or more processors. The one or more processors are configured to receive a transaction message including a mobile one-time PIN (m-OTP) from an acquiring system. In some non-limiting embodiments or aspects, the m-OTP is generated by a cardholder using an issuing mobile application configured in the cardholder's device. In some non-limiting embodiments or aspects, the m-OTP is entered by the cardholder into a merchant system. The merchant system generates a transaction message including the m-OTP and provides the transaction message to the acquiring system for authentication and authorization. The directory server is also configured to send the transaction message to the issuing system for authentication and authorization. Thereafter, the directory server is further configured to receive a response message from the issuing system, the response message including the result of the authorization and authentication. Furthermore, the directory server is also configured to provide the response message to the merchant system via the acquiring system.

[0014] In some non-limiting embodiments or aspects, a computer-implemented method for authorizing transactions is proposed. The method is performed by a merchant system. The method includes receiving a mobile one-time PIN (m-OTP) as input for initiating a transaction. The m-OTP is generated by a cardholder using an issuer application configured in the cardholder's device. The method also includes generating a transaction message including the m-OTP and a unique identifier indicating that the transaction message includes the m-OTP. The transaction message differs from other types of transaction messages that do not include the m-OTP. The method further includes providing the transaction message including the m-OTP to an acquiring system. The acquiring system includes an authorization request in the transaction message. Furthermore, the acquiring system sends the transaction message to a directory server configured to send the transaction message to the issuing system for authentication and authorization. The issuing system generates a response message based on the authentication and authorization and sends it to the directory server. The directory server sends the response message to the merchant system via the acquiring system. The method also includes receiving the response message and appropriately instructing the cardholder.

[0015] The foregoing overview is merely illustrative and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments, and features described above, other aspects, embodiments, and features will become apparent from the accompanying drawings and the following detailed description. Attached Figure Description

[0016] Example embodiments of this disclosure are shown in the accompanying drawings by way of example rather than limitation, and similar reference numerals refer to similar elements, and in the drawings:

[0017] Figure 1Exemplary platforms for executing transactions are shown according to some non-limiting embodiments or aspects of this disclosure;

[0018] Figure 2 This illustration shows an exemplary core system architecture for m-OTM-based authentication and authorization, based on some non-limiting embodiments or aspects of this disclosure;

[0019] Figure 3A and 3B Exemplary publisher mobile applications for generating m-OTPs are shown according to some non-limiting embodiments or aspects of this disclosure;

[0020] Figure 4A and 4B This illustration shows an exemplary merchant checkout page providing m-OTP according to some non-limiting embodiments or aspects of this disclosure;

[0021] Figure 5 This is a flowchart describing a merchant system-facilitated payment authorization based on m-OTP according to some non-limiting embodiments or aspects of this disclosure;

[0022] Figure 6 This is a flowchart describing an m-OTP-based payment authorization facilitated by a directory server according to some non-limiting embodiments or aspects of this disclosure;

[0023] Figure 7A An exemplary table showing a format comprising a Payer Authentication Request (PAReq) message according to some non-limiting embodiments or aspects of this disclosure is provided.

[0024] Figures 7B-7E An exemplary table is shown, comprising data fields associated with a first, second, third, and fourth position of an MTI identifier, according to some non-limiting embodiments or aspects of this disclosure;

[0025] Figure 8A Exemplary streams of m-OTP-based messages not transmitted via 3D orbit during a payment transaction are shown according to some non-limiting embodiments or aspects of this disclosure;

[0026] Figure 8B This illustrates an exemplary stream of m-OTP-based messages transmitted via a 3D track during a payment transaction, according to some non-limiting embodiments or aspects of this disclosure; and

[0027] Figure 9 A block diagram is shown of an exemplary computer system (900) for implementing embodiments consistent with this disclosure.

[0028] Those skilled in the art will understand that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the subject matter of this invention. Similarly, it should be understood that any flowchart, diagram, state transition diagram, pseudocode, etc., represents various processes that can be represented substantially in a computer-readable medium and executed by a computer or processor, whether or not such a computer or processor is explicitly shown. Although each figure shows a particular embodiment for the purpose of illustrating clear examples, other embodiments may omit, add, reorder, and / or modify any elements shown in the figures. Detailed Implementation

[0029] In this document, the term "exemplary" is used herein to mean "serving as an example, illustration, or description." Any embodiment or implementation of the subject matter of the invention described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

[0030] While this disclosure allows for various modifications and alternatives, specific embodiments of this disclosure have been illustrated in the drawings by way of example and will be described in detail below. However, it should be understood that this disclosure is not intended to be limited to the forms disclosed, but rather, it is intended to cover all modifications, equivalents, and alternatives that fall within the scope of this disclosure.

[0031] The term "comprises" or any other variations thereof is intended to cover non-exclusive inclusion, such that an arrangement, apparatus, or method that includes a list of components or steps includes not only those components or steps but also other components or steps not expressly listed or inherent to such arrangement, apparatus, or method. In other words, without further constraints, one or more elements in a system or apparatus following "comprises…a" do not exclude the presence of other elements or additional elements in the system or apparatus.

[0032] Typically, a transaction is completed when the cardholder is authenticated and the transaction is authorized by the issuing system (issuing bank or trusted third-party system). Usually, two request messages are generated, such as a Payment Authentication Request (PAReq) message and a Payment Authorization Request message. The merchant system generates the PAReq message, and the acquiring system generates the Payment Authorization Request message. First, the issuing system processes the PAReq to authenticate the cardholder. During authentication, the issuing system generates an OTP. The OTP is typically sent to the cardholder's registered mobile phone number and / or registered email address. The cardholder then enters the OTP into the merchant's checkout page. The OTP received from the cardholder is compared with the generated OTP to authenticate the cardholder. After successful authentication, a Payment Authorization Request message is generated, which is also provided to the issuing system. During authorization, the transaction is verified based on many factors, including account balance, transaction security, and such details. When two separate messages are generated for authentication and authorization, the transaction takes longer to complete. Furthermore, the processing complexity increases because two separate messages must be processed. Additionally, such transactions are prone to failure due to reliance on the cardholder's telecommunications network.

[0033] Embodiments of this disclosure relate to methods and systems for authenticating and authorizing transactions based on mobile one-time PINs (m-OTPs). A cardholder can generate an m-OTP in an issuer's mobile application installed on their device. The generated m-OTP is entered into a merchant checkout page accessible to the cardholder to complete the transaction. Once the m-OTP is entered, the merchant system generates a transaction message including the m-OTP and a unique identifier indicating that the transaction message includes the m-OTP. The transaction message includes a payment authentication request (PAReq). The acquiring system includes the payment authorization request in the transaction message and sends it to a directory server. The directory server sends the transaction message including the PAReq and the payment authorization request to the issuer system for authentication and authorization. The issuer system generates a payment authentication response (PARes) message including the result of the authentication and authorization of the transaction message. The directory server receives the PARes message and sends it to the merchant system via the acquiring system.

[0034] Figure 1 An overview of the platform (100) used to execute the transaction is described. The platform (100) is provided as a service to participating issuers, account holders, and merchants. An implementation scheme of the platform (100) related to online payment transactions is described. The description of online payment transactions covers payment transactions and specific message flows. This disclosure relates to online transactions with security features such as two-factor authentication (OTP) used for authenticating cardholders. The entire specification is described in light of online transactions. However, this disclosure is not limited to online transactions and can be applied to any type of transaction that provides, for example, two-factor authentication (OTP).

[0035] The platform (100) is designed to authenticate and authorize cardholder (101) account ownership during transactions where one party cannot actually verify the identity of the other party claiming to be the owner of a particular account. For example, the platform (100) can be used for various transactions when a trusted party (typically the issuing system) (107) authenticates the identity of a cardholder (101) for the benefit of a third party. It is well known that trusted parties typically bear legal responsibility for authenticating cardholders (101) to third parties.

[0036] In an online purchase, the transaction process begins when the cardholder (101) enters the details of the card (102) on the merchant checkout page located in the computing unit (103). The merchant system (104) receives the details of the card (102) and generates a transaction message for authenticating the cardholder (101). The merchant system (104) routes the transaction message to the directory server (106) via the acquiring system (105). The directory server (106) sends the transaction message to the issuing system (107) for authenticating the cardholder (101). The issuing system (107) verifies the details of the card (102) and maps it to the cardholder's (101) account. In addition, the issuing system (107) generates an OTP, which is typically provided to the cardholder (101) via a registered mobile device (via SMS) and a registered email address (via the Internet) through a telecommunications network. Upon receiving the OTP, the cardholder (101) enters the OTP into the merchant checkout page. The merchant system (104) sends the OTP to the issuer system (107) via the directory server (106) for verification. The issuer system (107) further verifies the OTP and authenticates the cardholder (101). Upon successful authentication, the acquiring system (105) generates a payment authorization request message including transaction-related information for the issuer system (107) to authorize the transaction. The issuer system (107) verifies the information present in the payment authorization request message and authorizes the transaction. Confirmation of successful authorization is provided by the issuer system (107). This confirmation is provided by the merchant system (104) to the cardholder (101).

[0037] Figure 2 Some non-limiting embodiments or aspects of the core system architecture (200) of the platform (100) are shown. The core system architecture (200) includes three domains: a trusted party domain, an interoperability domain, and a third-party or requesting party domain. The trusted party domain and the third-party domain define the functional areas within which components are wholly or at least partially controlled by the trusted party or the third party, respectively. The interoperability domain defines the functional areas within which components can be utilized by the trusted party, third parties, and other parties such as service organizations.

[0038] The trusted party domain comprises components primarily controlled by a trusted party. An example of a trusted party is a financial institution, known as an issuing bank, that issues payment cards to consumers. Specifically, the issuer or card issuer personalizes new cards received from card providers and then issues these cards to its customers. Personalization can also be performed by the card provider or a personalization bureau. Besides financial institutions, the issuer can be any suitable issuing entity, such as a telecommunications network operator, service association, merchant, or other organization, or even an agent acting on behalf of the issuer.

[0039] The third-party or requesting party domain includes components primarily controlled by the third party and / or the requesting party. A third party can be any party requesting authentication of an account holder's identity. For example, a third party could be a merchant wishing to authenticate the identity of someone claiming to be the card account owner. A third party could be an acquiring party, which is a financial institution that registers merchants in payment schemes and manages their accounts. The acquiring party also routes information from online merchants to telecommunications networks. In other embodiments, merchants may route information directly to telecommunications networks.

[0040] The interoperability domain can be supported by the Internet and includes components for use by both trusted parties and third parties.

[0041] In this disclosure, the trusted domain is also referred to hereinafter as the issuer system (107). The issuer system (107) includes an issuer cardholder module (201), a registration server (202), an access control server (ACS) (203), and an account holder file (204). Other components are included within the issuer system (107), depending on the specific use case in which the system is used. For example, in a payment transaction, each of the domains contains additional components to authenticate the identity of the cardholder (101) in relation to the payment transaction.

[0042] In some non-limiting embodiments or aspects, the registration server (202) is a computer that manages cardholder registration to the issuer's system (107) by presenting (e.g., via a web interface) a series of questions that will be answered by the account holder and verified by a trusted party. Figure 2 As shown, the issuer system (107) operates the registration server (202). However, in some non-limiting embodiments or aspects, for example... The service organization can operate the registration server (202) on behalf of the issuer system (107). The issuer system (107) can use a networked interactive "identity authentication service" provided by an external entity to help verify the identity of the account holder during the registration process.

[0043] In some non-limiting embodiments or aspects, the ACS (203) is a computer having a database of account holders registered for the account authentication service. The ACS (203) includes account and password information for each account holder. During an account authentication transaction, the ACS (203) provides a digitally signed receipt to the authentication requester, controls access to the issuer's system (107), and verifies the account holder's participation in the authentication service. In one or more embodiments, the card issuer or, for example... The service organization can operate the ACS (203) for the trusted party (also known as the acquiring system (105)). Although the account authentication service does not require any additional cardholder software, optional account holder software and hardware can be deployed. Additional account holder software can support additional authentication technologies such as digital certificates, integrated circuit cards (e.g., chip cards), and chip card readers.

[0044] The account holder file (204) is a database managed by the trusted party that stores information related to account holders successfully registered with the issuer system (107). The issuer cardholder module (201) is controlled by the trusted party and includes information about account holders. This information relates to account information, services used by the cardholder (101), etc. Some information within the issuer cardholder module (201) can be used to register account holders in the issuer system (107).

[0045] The acquiring system (105) requests authentication of the account holder. In some non-limiting embodiments or aspects, the merchant system (104) manages merchant plug-in software (205) that facilitates the authentication protocol. The merchant plug-in software (205) is a software module integrated into the merchant's (104) website. The merchant plug-in software (205) is programmed or configured to generate transaction messages with m-OTP. Furthermore, the merchant plug-in software (205) may include a PAReq message in the transaction message. The acquiring plug-in software (206) manages the acquiring system (105). In some non-limiting embodiments or aspects, if the merchant plug-in software (205) has not yet included a PAReq message in the transaction message, the acquiring plug-in software (206) receives the transaction message from the merchant plug-in software (205) and includes the PAReq message. Additionally, the acquiring plug-in software (206) also includes a payment authorization request message in the transaction message. The acquiring plug-in software (206) then sends the transaction message to the interoperability domain for authentication and authorization.

[0046] In some non-limiting embodiments or aspects, the interoperability domain includes a directory server (106). The directory server may be Internet-enabled and includes components for use by both the issuer system (107) and the acquirer system (105). The directory server (106) is configured to route authentication and / or authorization requests from the acquirer system (105) to a specific ACS, such as ACS (203). The directory server (106) is operated by a card scheme manager or a service organization such as Visa. The interoperability domain may also be supported by a network other than the Internet.

[0047] In some non-limiting embodiments or aspects, the authentication process is applicable to scenarios where a cardholder (101) shops online, adds items to a "shopping cart," proceeds to the online merchant's checkout page, and completes the online merchant's checkout form. The authentication process can occur after the cardholder (101) decides to purchase the desired product or service, for example, after the cardholder (101) clicks the "buy" button. The authentication process can also begin at various other times during the cardholder's (101) payment transaction. The authentication process is primarily conducted transparently with respect to the cardholder (101) by utilizing software at several points integrated into the payment network. The directory server (106) verifies the participation of the cardholder (101) and the cardholder's financial institution using an authentication service. A window is then created in which the cardholder (101) can confirm their identity by entering an m-OTP generated in the cardholder's (101) device. In some non-limiting embodiments or aspects, the m-OTP can be generated in the issuer's mobile application ( Figure 2 (Not shown in the image). In some non-limiting embodiments or aspects, any application associated with the issuing system (107) may generate an m-OTP on behalf of the issuing financial institution. The m-OTP and transaction details are sent to the issuing system (107) in a transaction message. Since the m-OTP does not require network support, unlike conventional systems, PAReq messages and payment authorization request messages may be included in the transaction message. If the cardholder's (101) identity is confirmed, payment information and the cardholder's (101) authentication notification are sent back to the merchant system (104). The merchant system (104) then processes the payment transaction. For example, the merchant system (104) may send an order confirmation message to the cardholder's browser.

[0048] Figure 3A and 3BAn issuer mobile application (301) for generating m-OTPs is shown. As shown, the issuer mobile application (301) can be an application for generating m-OTPs. In some non-limiting embodiments or aspects, the issuer mobile application (301) can be a dedicated application for generating m-OTPs, or it can be integrated with an issuer bank application and can provide an interface for generating m-OTPs. In some non-limiting embodiments or aspects, m-OTPs are time-based (time synchronization) OTPs. In some embodiments, m-OTPs can also be referred to as time-one-time passwords (t-OTPs). In some non-limiting embodiments or aspects, t-OTPs use an OTP algorithm based on hash-based message authentication codes (HMAC). HMAC is an algorithm that uses hashing techniques for encoding. In m-OTPs, the current time is hashed to generate the m-OTP. In some non-limiting embodiments or aspects, m-OTPs also include time data. For a given moment, a unique algorithm can be used to generate the m-OTP. When an m-OTP is provided for authentication, the same algorithm (generated by the cardholder (101)) can be used at the authentication end (in this case, the issuing system (107)) to generate the m-OTP based on the time data in the m-OTP generated by the cardholder (101). If two m-OTPs (one generated by the cardholder (101) and the other generated by the issuing system (107)) match, the cardholder (101) is successfully authenticated. An advantage of m-OTPs compared to other OTPSs is that m-OTPs can be generated offline. Figure 3A The first application page is shown, in which the issuer's mobile application (301) can provide options for generating an m-OTP. As shown, a button can be provided on the user interface (UI) of the cardholder's device (103). The button can be a physical button or a touch-sensitive button.

[0049] Figure 3BA second application page displaying the generated m-OTP is shown. In some non-limiting embodiments or aspects, the issuer mobile application (301) may implement an HMAC-based OTP algorithm. In some non-limiting embodiments or aspects, the only algorithm implemented in the issuer mobile application (301) is implemented in the issuer system (107). When the cardholder (101) clicks a button, the issuer mobile application (301) generates the m-OTP and displays it on the UI of the cardholder device (103). In some non-limiting embodiments or aspects, the m-OTP is a numeric PIN (e.g., "148261"). In some non-limiting embodiments or aspects, the m-OTP may also be an alphanumeric PIN (e.g., "Pass123"). In some non-limiting embodiments or aspects, the m-OTP may also include special characters (e.g., "!", "@", "%", etc.). In some non-limiting embodiments or aspects, the m-OTP may have 4-8 numbers and / or characters. In some non-limiting embodiments or aspects, the number of numbers and / or characters in the m-OTP may be based on standards followed by the issuing system (107). In some non-limiting embodiments or aspects, the m-OTP is copied to the clipboard after generation. The copied m-OTP may be pasted into an appropriate authentication form.

[0050] Figure 4A and 4B This illustrates a merchant checkout page providing m-OTP according to some non-limiting embodiments or aspects of this disclosure. Figure 4A An example merchant checkout page showing the requested card and cardholder details. Figure 4A and 4B The illustrations in this document should not be interpreted as limitations. The illustrations are merely examples, and... Figure 4A and 4B The aspects described herein can be applied to any checkout page. As shown, the checkout page includes transaction details containing the amount and date. In some non-limiting embodiments or aspects, the checkout page may also include merchant details and other necessary details about the transaction. In some non-limiting embodiments or aspects, merchant plug-in software (205) is associated with the checkout page. Figure 4A As shown, the first form (401) requests the cardholder (101) to enter details such as the cardholder's (101) name, card number, expiration date, security code, and authentication type. When the cardholder (101) enters the card number, the merchant plug-in software (205) can identify the interoperability service provider associated with the card (e.g., After entering the card details and the details associated with the cardholder (101), the checkout page provides an option to select the authentication type. Existing checkout pages offer authentication types including OTP and static password (3D secure password). According to this disclosure, the merchant checkout page offers an additional authentication type including m-OTP. When the cardholder (101) selects the m-OTP option as the authentication type, the checkout page is navigated to a second form (402), as... Figure 4B As shown.

[0051] like Figure 4B As shown, the second form (402) receives the m-OTP. The cardholder (101) can generate the m-OTP, such as... Figure 3A and 3B As shown. In some non-limiting embodiments or aspects, if the m-OTP is generated using the issuer's mobile application (301) and the m-OTP is copied to the clipboard, the cardholder (101) can paste the m-OTP. Alternatively, the cardholder (101) can manually type the m-OTP in a field of the second form (402). After the cardholder (101) enters the m-OTP, the submit button submits the m-OTP to the merchant plug-in software (205).

[0052] The following method describes the steps performed by the merchant system (104). Figure 5 This is a flowchart describing an m-OTP-based payment authorization facilitated by the merchant system (104) according to some non-limiting embodiments or aspects of this disclosure.

[0053] like Figure 5 As shown, the method (500) may include one or more steps. The method (500) may be described in the overall context of computer-executable instructions. Typically, computer-executable instructions may include routines, programs, objects, components, data structures, procedures, modules, and functions that perform a particular function or implement a particular abstract data type.

[0054] The order in which the methods (500) are described is not intended to be limiting, and the methods can be implemented by combining any number of the described method blocks in any order. Furthermore, individual blocks can be removed from the methods without departing from the scope of the subject matter described herein. Moreover, the methods can be implemented in any suitable hardware, software, firmware, or a combination thereof.

[0055] In step (501), the merchant system (104) receives the m-OTP from the second form (402) of the merchant checkout page. Along with the m-OTP, the merchant system (104) also receives the card details and cardholder (101) details entered in the first form (401).

[0056] In step (502), the merchant system (104) generates a transaction message including m-OTP. In some non-limiting embodiments or aspects, the transaction message is generated according to the ISO 8583 standard. ISO 8583 defines the transaction message structure. Reference is now made to... Figure 7A This shows an example of the ISO 8583 message format. For example... Figure 7A As shown, transaction messages generated according to ISO 8583 may include a Message Type Identifier (MTI), a primary bitmap, a secondary bitmap, and data elements. The MTI is a four-digit numeric field describing each message category and function. There are few versions of the ISO 8583 standard: ISO 8583:1987, ISO 8583:1993, and ISO 8583:2003. The first digit of the four-digit number indicates the version of ISO 8583. This is in... Figure 7B As shown in the figure, when the first digit of the four-digit number is 0, the version is ISO 8583:1987. Similarly, when the first digit of the four-digit number is 1, the version is ISO 8583:1993, and when the first digit of the four-digit number is 2, the version is ISO 8583:2003.

[0057] Figure 7C This shows the field associated with the second digit of the MTI. As shown in the figure, the second digit can take values ​​from 0 to 9. Figure 7C As can be seen, for values ​​0 and 9, the MTI field is retained for ISO. Similarly, Figure 7D This shows the field associated with the third digit of the MTI. For example... Figure 7D As can be seen, for values ​​8 and 9, the MTI field is reserved for ISO.

[0058] In some non-limiting embodiments or aspects, the merchant system (104) may include a unique identifier in the transaction message to indicate the presence of m-OTP in the transaction message. In some non-limiting embodiments or aspects, the second digit of the four-digit number may indicate the presence of m-OTP in the transaction message. For example, a value of 0 in the second digit may be defined as indicating m-OTP. In another instance, a value of 9 in the second digit may be defined as indicating m-OTP.

[0059] In some non-limiting embodiments or aspects, the third digit of the four-digit number may indicate the presence of an m-OTP in the transaction message. For example, a value of 8 in the third digit may be defined as indicating an m-OTP. In another instance, a value of 9 in the third digit may be defined as indicating an m-OTP.

[0060] In some non-limiting embodiments or aspects, a field is defined for all values ​​of the fourth digit. Therefore, it may be impossible to identify m-OTP using the fourth digit. Figure 7E This shows the field associated with the fourth digit of the MTI.

[0061] In some non-limiting embodiments or aspects, the unique identifier is an MTI four-digit code.

[0062] In some non-limiting embodiments or aspects, a bitmap is a field indicating which data elements may or may not be present in a transaction message. The transaction message includes at least one bitmap, called a primary bitmap, which indicates which of data elements 1 to 64 are present. A secondary bitmap may also be present as data element 1, and the secondary bitmap indicates which of data elements 65 to 128 are present. Furthermore, a third bitmap may be used to indicate the presence or absence of fields 129 to 192. In some non-limiting embodiments or aspects, the m-OTP may be contained in the first 1-64 bits of a data element, or in bits 65 to 128 of a data element. Therefore, the primary and secondary bitmaps can be updated to indicate the m-OTP in the transaction message. The value of the bitmap indicates whether the m-OTP is present in bits 1-64 or in bits 65-128.

[0063] A data element is all the fields containing transaction information. ISO 8583:1997 contains up to 128 data elements (a message will have up to 2 bitmap fields). Later versions contain up to 192 data elements (a message will have up to 3 bitmap fields). Each field (data element) has a specific meaning and format. In some non-limiting embodiments or aspects, the data element may also include m-OTP. For example, data fields 46, 47, 48, 55-63, and 105-119 may be used. In some non-limiting embodiments or aspects, field 128 is used for message authentication codes in conventional systems. According to this disclosure, field 128 can be used for m-OTP.

[0064] In some non-limiting embodiments or aspects, the merchant system (104) may include a PAReq message in the transaction message. In some non-limiting embodiments or aspects, the merchant system may not include a PAReq message in the transaction message.

[0065] Return to reference Figure 5In step (503), the merchant system (104) provides the transaction message generated in step (502) to the acquiring system (105). In some non-limiting embodiments or aspects, if the merchant system has already included a PAReq message in the transaction message, the acquiring system (105) further includes a payment authorization request message in the transaction message. The acquiring system (105) submits the transaction message, including the PAReq message and the payment authorization request message, to the directory server (106). The directory server (106) is configured to send the transaction message to the ACS (203) for authentication and authorization. The ACS (203) receives the transaction message and initially verifies the m-OTP. In some non-limiting embodiments or aspects, the ACS (203) determines that the transaction message must be authenticated using the m-OTP based on the value in the MTI field. Furthermore, the ACS (203) identifies the m-OTP using a bitmap value in the transaction message. Thereafter, the ACS (203) retrieves the m-OTP for authentication. When verifying the m-OTP, the ACS (203) generates the m-OTP locally in the issuer system (107) using the time data included in the transaction message. The algorithm used by the ACS (203) to generate the m-OTP should be the same as the algorithm used by the issuer mobile application (301). If the generated m-OTP matches the received m-OTP, the transaction message is successfully authenticated. If the generated m-OTP does not match the locally generated m-OTP, authentication fails. After successful authentication, the ACS (203) retrieves the transaction details from the transaction message and authorizes the transaction. In some non-limiting embodiments or aspects, the transaction information includes at least one of the following: the cardholder's primary account number, processing code, transaction amount, transaction date and time, acquiring system identifier, currency code, issuer system identifier, and authentication mode, which includes the m-OTP, a one-time password (OTP) generated by the issuer system, a static password, and biometric pattern information. Authorization can be performed as performed in existing systems. Thereafter, the ACS (203) generates a Payment Authentication Response (PARes) message based on authentication and authorization. Fields in PARes can be based on successful authentication and authorization.

[0066] In some non-limiting embodiments or aspects, the directory server (106) is able to identify m-OTP, retrieve m-OTP, and provide m-OTP along with transaction messages to the ACS (203).

[0067] In some non-limiting embodiments or aspects, the PARes message is provided to a directory server (106), which routes the PARes message to the acquiring system (105). The acquiring system (105) then sends the PARes message to the merchant system (104).

[0068] In step (504), the merchant system (104) receives the PARes message from the acquiring system (105) and presents the appropriate message to the cardholder (101) on the merchant checkout page.

[0069] Now for reference Figure 6 The following method describes the steps performed by the directory server (106). Figure 6 This is a flowchart describing an m-OTP-based payment authorization facilitated by a directory server (106) according to some non-limiting embodiments or aspects of this disclosure.

[0070] like Figure 6 As shown, method 600 may include one or more steps. Method 600 may be described within the overall context of computer-executable instructions. Typically, computer-executable instructions may include routines, programs, objects, components, data structures, procedures, modules, and functions that perform a particular function or implement a particular abstract data type.

[0071] The order in which method 600 is described is not intended to be limiting, and the method can be implemented by combining any number of the described method blocks in any order. Furthermore, individual blocks can be removed from the method without departing from the scope of the subject matter described herein. Moreover, the method can be implemented in any suitable hardware, software, firmware, or a combination thereof.

[0072] After the merchant system (104) has generated a transaction message including m-OTP and assumes that steps (501)-(503) have been performed (until the transaction message is provided to the acquiring system (105)), the following steps are performed.

[0073] In step 601, the directory server (106) receives a transaction message including m-OTP from the acquiring system (105). In some non-limiting embodiments or aspects, the directory server (106) is able to distinguish transaction messages including m-OTP from other types of transaction messages that do not include m-OTP using identifiers present in the transaction message. In some non-limiting embodiments or aspects, the received transaction message includes only a PAReq message. In some non-limiting embodiments or aspects, the transaction message includes a PAReq message and a payment authorization request message.

[0074] In step 602, the directory server (106) sends the transaction message to the ACS (203) of the issuer system (107) for authentication and authorization, depending on the presence of the PAReq message and the payment authorization message. In some non-limiting embodiments or aspects, the directory server (106) is able to retrieve m-OTP and time data from the transaction message and provide the m-OTP and time data to the ACS (203) for authentication. After successful authentication, the directory server (106) can send a transaction message including transaction details to the ACS (203) for authorization. In some non-limiting embodiments or aspects, the directory server (106) can send the transaction message to the ACS (203) without retrieving the m-OTP. The ACS (203) can retrieve the m-OTP, authenticate, and authorize the transaction. After authentication and authorization, the ACS (203) generates a... Figure 5 The PARes message explained in step (503) is provided to the directory server (106).

[0075] In some non-limiting embodiments or aspects, to ensure seamless authentication, the directory server (106) may authenticate the transaction. For the directory server (106) to perform authentication, the cardholder's device (103) should be configured with an interoperability domain mobile application capable of generating m-OTPs. After authenticating the m-OTP, the directory server (106) may send the transaction message to the ACS (203) for authorization.

[0076] In step 603, the directory server (106) receives the PARes message from the ACS (203). In some non-limiting embodiments or aspects, the directory server (106) stores the PARes results in a local ledger. Storing the PARes results in the local ledger can be used to determine the success rate of m-OTP-based transaction messages.

[0077] In step 604, the directory server (106) provides the PARes message to the merchant system (104) via the acquiring system (105). The merchant system (104) can then provide the result of the PARes message to the cardholder (101) on the merchant checkout page.

[0078] Figure 8AThe diagram illustrates a stream of m-OTP-based messages not transmitted via a 3D track during a payment transaction, according to some non-limiting embodiments or aspects of this disclosure. As shown, the merchant system (104) generates a transaction message including the m-OTP. The merchant system (104) further includes a PAReq message in the transaction message and sends the transaction message including the PAReq message to the acquiring system (105). The acquiring system (105) receives the transaction message including the m-OTP and PAReq messages and appends a payment authorization request message to the transaction message. Furthermore, the acquiring system (105) sends the transaction message including the PAReq message and the payment authorization request message to a directory server (106). The directory server (106) routes the transaction message including the PAReq message and the payment authorization request message to the issuing system (107).

[0079] In some non-limiting embodiments or aspects, the issuer system (107) authenticates the transaction message and authorizes the transaction message based on the authentication result. Based on the authorization result, the issuer system (107) generates a PARes message that includes the authentication and authorization results. The PARes message is provided to a directory server (106), which then routes the PARes message to the acquiring system (105). Furthermore, the acquiring system (105) sends the PARes message to a merchant system (104), which displays an appropriate message on the merchant checkout page based on the authentication and authorization results attached to the PARes message.

[0080] In some non-limiting embodiments or aspects, this m-OTB-based transaction technology reduces one message in the platform (100). Therefore, it reduces the processing of additional messages and reduces time. The complexity of managing transactions is reduced for all entities (merchant system (104), acquiring system (105), directory server (106), and issuing system (107)).

[0081] Figure 8B The diagram illustrates a stream of m-OTP-based messages transmitted via a 3D track during a payment transaction, according to some non-limiting embodiments or aspects of this disclosure. As shown, the merchant system (104) generates a transaction message including the m-OTP. The merchant system (104) further includes a PAReq message in the transaction message and sends the transaction message including the PAReq message to the acquiring system (105). The acquiring system (105) receives the transaction message including both the m-OTP and PAReq messages. Furthermore, the acquiring system (105) sends the transaction message including the PAReq message to a directory server (106). The directory server (106) routes the transaction message including the PAReq message to the issuing system (107).

[0082] In some non-limiting embodiments or aspects, the issuing system (107) authenticates the transaction message. Based on the authentication result, the issuing system (107) generates a password indicating the authentication result. In some non-limiting embodiments or aspects, the issuing system (107) retains the transaction message. The password message is provided to a directory server (106), which then routes the password to the merchant system (104) via the acquiring system (105). If authentication fails, the merchant system (104) displays an appropriate message on the merchant checkout page. If authentication succeeds, the merchant system (104) generates a payment authorization request message. Furthermore, the payment authorization request message, along with the password, is provided to the acquiring system (105). The acquiring system (105) routes the payment authorization request message, along with the password, to the issuing system (107) via the directory server (106). Upon receiving the payment authorization request message along with the password, the issuing system (107) authorizes the transaction based on the transaction details retained by the issuing system (107). In addition, the issuing system (107) generates a payment authorization response message that includes the authorization result. The payment authorization request message is transmitted to the merchant system (104) via the directory server (106) and the acquiring system (105). The merchant system (104) then displays an appropriate message on the merchant checkout page based on the authorization result.

[0083] In some non-limiting embodiments or aspects, m-OTP-based transactions increase security because the OTP is not shared with the cardholder over the telecommunications network (101). Furthermore, since m-OTP is independent of the telecommunications network, failures caused by faults in the telecommunications network will not affect the transaction. Additionally, transaction completion time is reduced because the m-OTP can be generated by the cardholder (101) rather than provided by the issuing system (107).

[0084] Figure 9 A block diagram of an exemplary computer system (900) for implementing embodiments consistent with this disclosure is shown. In some non-limiting embodiments or aspects, the computer system (900) is used to implement methods for authorizing transactions in a platform (100). The computer system (900) may include a central processing unit (“CPU” or “processor”) (902). The processor (902) may include at least one data processor for executing program components for dynamic resource allocation at runtime. The processor (902) may include dedicated processing units, such as an integrated system (bus) controller, a memory management control unit, a floating-point unit, a graphics processing unit, a digital signal processing unit, etc.

[0085] The processor (902) may be configured to communicate with one or more I / O devices (not shown) via an input / output (I / O) interface (901). The I / O interface (901) may employ communication protocols / methods such as, but not limited to, audio, analog, digital, mono, RCA, stereo, IEEE-1394, serial bus, Universal Serial Bus (USB), infrared, PS / 2, BNC, coaxial, component, composite, digital video interface (DVI), high-definition multimedia interface (HDMI), RF antenna, S-Video, VGA, IEEE 802.n / b / g / n / x, Bluetooth, cellular (e.g., Code Division Multiple Access (CDMA), High Speed ​​Packet Access (HSPA+), Global System for Mobile Communications (GSM), Long Term Evolution (LTE)). )wait.

[0086] Using the I / O interface (901), the computer system (900) can communicate with one or more I / O devices. For example, input devices (910) can be antennas, keyboards, mice, joysticks, (infrared) remote controls, cameras, card readers, fax machines, dongles, biometric readers, microphones, touchscreens, touchpads, trackballs, styluses, scanners, storage devices, transceivers, video devices / sources, etc. Output devices (911) can be printers, fax machines, video displays (e.g., cathode ray tube (CRT), liquid crystal displays (LCD), light-emitting diodes (LEDs), plasma displays, plasma display panels (PDP), organic light-emitting diode displays (OLEDs), etc.), audio speakers, etc.

[0087] In some embodiments, the computer system (900) is connected to a service provider via a communication network (909). The processor (902) may be configured to communicate with the communication network (909) via a network interface (903). The network interface (903) may communicate with the communication network (909). The network interface (903) may employ connectivity protocols, including but not limited to direct connection, Ethernet (e.g., twisted pair 10 / 100 / 1000Base T), Transmission Control Protocol / Internet Protocol (TCP / IP), Token Ring, IEEE 802.11a / b / g / n / x, etc. The communication network (909) may include, but is not limited to, direct interconnect, e-commerce networks, peer-to-peer (P2P) networks, local area networks (LANs), wide area networks (WANs), wireless networks (e.g., using Wireless Application Protocol), the Internet, Wi-Fi, etc. Using the network interface (903) and the communication network (909), the computer system (900) may communicate with one or more service providers.

[0088] In some embodiments, the processor (902) may be configured to connect to the memory (905) via a storage interface (904) (e.g., Figure 9 (RAM, ROM, etc., not shown) communication. The storage interface (904) can be connected to a memory (905), including but not limited to memory drives, removable optical disc drives, etc., wherein the memory uses a connection protocol such as Serial Advanced Technology Attachment (SATA), Integrated Electronic Drive (IDE), IEEE-1394, Universal Serial Bus (USB), Fibre Channel, Small Computer System Interface (SCSI), etc. The memory drive may also include drums, disk drives, magneto-optical drives, optical disc drives, redundant arrays of independent optical discs (RAID), solid-state storage devices, solid-state drives, etc.

[0089] The memory (905) may store a collection of program or database components, including but not limited to a user interface (906), an operating system (907), a network server (908), etc. In some embodiments, the computer system (900) may store user / application data, such as the data, variables, records, etc., described in this disclosure. Such a database may be implemented as a fault-tolerant, relational, scalable, and secure database, such as Oracle or Sybase.

[0090] An operating system (907) facilitates the resource management and operation of a computer system (900). Examples of operating systems include, but are not limited to, Apple Macintosh OS X, Unix, Unix-like system distributions (e.g., Berkeley Software Distribution (BSD), FreeBSD, NetBSD, OpenBSD, etc.), Linux distributions (e.g., Red Hat, Ubuntu, Kubuntu, etc.), IBM OS, iOS / 2, Microsoft Windows (XP, Vista / 7 / 8, 10, etc.), Apple iOS, Google Android, Blackberry OS, etc.

[0091] In some embodiments, the computer system (900) may implement a web browser (908) stored program component. The web browser (908) may be a hypertext viewing application, such as Microsoft Internet Explorer, Google Chrome, Mozilla Firefox, Apple Safari, etc. Secure web browsing may be provided using Hypertext Transfer Secure (HTTPS), Secure Sockets Layer (SSL), Transport Layer Security (TLS), etc. The web browser (908) may utilize facilities such as AJAX, DHTML, Adobe Flash, JavaScript, Java, Application Programming Interface (API), etc. In some embodiments, the computer system (900) may implement a mail server stored program component. The mail server may be an Internet mail server, such as Microsoft Exchange, etc. The mail server may utilize facilities such as ASP, ActiveX, ANSI C++ / C#, Microsoft .NET, CGI scripts, Java, JavaScript, PERL, PHP, Python, WebObjects, etc. The mail server may utilize communication protocols such as Internet Message Access Protocol (IMAP), Message Application Programming Interface (MAPI), Microsoft Exchange, Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), etc. In some embodiments, the computer system (900) may implement an email client storage program component. The email client may be an email viewing application, such as Apple Mail, Microsoft Entourage, Microsoft Outlook, Mozilla Thunderbird, etc.

[0092] In some non-limiting embodiments or aspects, the computer system (900) is a directory server that provides services for facilitating transactions between merchants and issuer systems associated with the acquiring system. In some non-limiting embodiments or aspects, the computer system (900) is connected to entities including merchants, acquiring systems, and issuer systems.

[0093] Unless otherwise expressly specified, the terms “embodiment,” “one or more embodiments,” “some embodiments,” “some non-limiting embodiments or aspects,” and “an embodiment” mean “one or more (but not all) embodiments of this disclosure,” unless otherwise expressly stated.

[0094] Unless otherwise expressly specified, the terms “including / comprising,” “having,” and variations thereof mean “including but not limited to.”

[0095] Unless otherwise expressly specified, the list of items does not imply that any or all items are mutually exclusive. Unless otherwise expressly specified, the terms "a / an" and "the" mean "one or more".

[0096] The description of embodiments having several components communicating with each other does not imply that all of these components are required. Rather, various optional components are described to illustrate various possible, non-limiting embodiments or aspects of this disclosure.

[0097] When a single device or article is described herein, it will be apparent that more than one device / article (whether or not they cooperate) may be used in place of the single device / article. Similarly, when more than one device or article (whether or not they cooperate) is described herein, it will be readily apparent that a single device / article may be used in place of more than one device or article, or that a different number of devices / articles may be used in place of the number of devices or programs shown. The functionality and / or features of a device may alternatively be embodied by one or more other devices not explicitly described as having such functionality / features. Therefore, other embodiments or aspects of this disclosure need not include the device itself.

[0098] Figure 5 , Figure 6 The operations illustrated show certain events occurring in a particular order. In alternative embodiments, some operations may be performed, modified, or removed in a different order. Furthermore, steps may be added to the logic described above, and these steps still conform to the described embodiments. Additionally, the operations described herein may be performed sequentially, or some operations may be processed in parallel. However, operations may be performed by a single processing unit or distributed processing units.

[0099] Finally, the language used in this specification has been chosen primarily for readability and edibility purposes, and not for defining or limiting the subject matter of the invention. Therefore, it is intended that the scope of this disclosure be not limited to this specific embodiment, but rather to any claims relating to applications based on this disclosure. Thus, the disclosure of embodiments or aspects of this disclosure is intended to be illustrative and not to limit the scope of the disclosure as set forth in the appended claims.

[0100] While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The aspects and embodiments disclosed herein are for illustrative purposes and are not intended to be limiting, wherein the true scope and spirit are indicated by the appended claims.

Claims

1. A computer-implemented method, comprising: Without using a network connection, a mobile one-time password m-OTP is generated using a mobile application configured on the cardholder's device, the m-OTP being generated based on at least one algorithm; The directory server receives a transaction message from the acquiring system, which includes transaction information for authorization, wherein the transaction message includes at least the m-OTP, wherein the m-OTP is submitted to the merchant system, and wherein the merchant system provides the transaction message to the acquiring system for completing the transaction; The directory server sends the transaction message to the issuing system for authorization, wherein the transaction message is authorized after the issuing system retrieves the m-OTP from the transaction message for authentication of the cardholder associated with the issuing system, wherein the issuing system authenticates the cardholder by matching the m-OTP generated by the mobile application with a second m-OTP generated by the issuing system using the at least one algorithm; The directory server receives a response message from the issuer system, including the authorization result of the transaction message, based on the authentication result of the m-OTP. as well as The directory server provides the response message to the merchant system via the acquiring system.

2. The method of claim 1, wherein the transaction message includes an identifier, wherein the identifier indicates that the transaction message includes m-OTP and is used by the directory server to distinguish it from other types of transaction messages that do not include m-OTP.

3. The method of claim 2, wherein the identifier is inserted into one of the message type identifier MTI, bitmap, or data element of the transaction message.

4. The method according to claim 1, wherein the m-OTP is a time-based cryptography.

5. The method of claim 1, wherein the transaction message is formatted according to the ISO 8583 standard.

6. The method according to claim 1, wherein the transaction information includes at least one of the following: the cardholder's primary account, processing code, transaction amount, transaction date and time, acquiring system identifier, currency code, issuing system identifier, and authentication mode, wherein the authentication mode includes the second m-OTP, static password, and biometric pattern information generated by the issuing system.

7. The method of claim 1, wherein the response message is generated based on authenticating the m-OTP and authorizing the transaction message.

8. The method of claim 1, wherein the response message is generated based on authenticating the m-OTP.

9. The method of claim 8, wherein the transaction message includes a payer authentication request PAReq message.

10. A directory server for authorizing transactions, the server comprising: One or more processors; as well as One or more computer-readable media communicatively coupled to said one or more processors storing instructions, said instructions causing the processor, when executed, to: Without using a network connection, a mobile one-time password m-OTP is generated using a mobile application configured in the cardholder's device, the m-OTP being generated based on at least one algorithm; a transaction message including transaction information for authorization is received from the acquiring system, wherein the transaction message includes at least the m-OTP, wherein the m-OTP is submitted to the merchant system, wherein the merchant system provides the transaction message to the acquiring system for completing the transaction; The transaction message is sent to the issuing system for authorization, wherein the transaction message is authorized after the issuing system retrieves the m-OTP from the transaction message for authentication of the cardholder associated with the issuing system, wherein the issuing system authenticates the cardholder by matching the m-OTP generated by the mobile application with a second m-OTP generated by the issuing system using the at least one algorithm; Based on the authentication result of the m-OTP, a response message including the authorization result of the transaction message is received from the issuing system; and The acquiring system provides the response message to the merchant system.

11. The directory server of claim 10, wherein the one or more processors are configured to use an identifier in the transaction message to distinguish a transaction message including the m-OTP from other types of transaction messages that do not include the m-OTP, wherein the m-OTP is a time-based cipher, and wherein the transaction message conforms to the ISO 8583 standard.

12. The directory server of claim 10, wherein the one or more processors are configured to send the transaction messages formatted according to ISO 8583 to the issuing system.

13. The directory server of claim 11, wherein the one or more processors receive the transaction message including the identifier of one of the Insert Message Type Identifier (MTI), a bitmap, or a data element.

14. The directory server of claim 10, wherein the one or more processors receive the response message generated based on authenticating the m-OTP and authorizing the transaction message.

15. The directory server of claim 10, wherein the one or more processors receive the response message generated based on authenticating the m-OTP.

16. The directory server of claim 15, wherein the transaction message includes a payer authentication request (PAReq) message.

17. A computer-implemented method for authorizing transactions, comprising: The merchant system receives a mobile one-time password (m-OTP) as input to initiate a transaction, wherein the m-OTP is generated by an issuer mobile application configured in the cardholder's device without using a network connection, and the m-OTP is generated based on at least one algorithm. The merchant system generates a transaction message that includes an identifier and the m-OTP, wherein the identifier indicates that the transaction message includes the m-OTP and is different from other types of transaction messages that do not include the m-OTP; The merchant system provides the transaction message, including the m-OTP, to the acquiring system, wherein the acquiring system includes an authorization request in the transaction message and provides the transaction message to a directory server, which sends the authorization request message to the issuing system for authenticating the cardholder associated with the issuing system and authorizing the transaction message, wherein the issuing system authenticates the cardholder by matching the m-OTP generated by the mobile application with a second m-OTP generated by the issuing system using the at least one algorithm, including a response message of the authorization result generated by the issuing system; as well as The merchant system receives the response message from the directory server via the acquiring system.

18. The method of claim 17, wherein the transaction message is formatted according to the ISO 8583 standard, and wherein the transaction message includes a payer authentication request (PAReq) message.

19. The method of claim 17, wherein the identifier is inserted into one of a message type identifier (MTI), a bitmap, or a data element of the transaction message format.

20. The method of claim 17, wherein the m-OTP is a time-based cryptography.

Images