Mobile OTP Authentication for Card Not Present Transactions

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Card not present transactions face challenges in authentication due to dependency on telecom networks, leading to delays and failures, especially in areas with poor connectivity, resulting in increased fraud and security concerns for both merchants and cardholders.

Innovation Solution

A computer-implemented method using a mobile-One Time Password (m-OTP) generated by a cardholder's device, which is input into a merchant system and processed through a directory server for authentication and authorization, reducing network dependency and enhancing transaction security.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If telecom network dependent authentication methods are used, then authentication can be performed through network communication, but transaction delays and failures occur in areas with poor network connectivity

Engineering Contradiction:
Improveauthentication reliabilityVSAvoidtransaction time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The m-OTP is generated locally on the cardholder's mobile device before the transaction occurs, rather than being retrieved through network communication during the transaction. This preliminary generation of authentication credentials eliminates network dependency and prevents transaction delays in areas with poor connectivity.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The mobile device acts as an intermediary that stores and provides the m-OTP locally, mediating between the cardholder and the authentication system without requiring real-time network communication. This intermediary approach ensures authentication can proceed even when network connectivity is unavailable.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If telecom network dependent authentication methods are used, then authentication can be performed remotely, but network failures lead to increased fraud and security concerns

Engineering Contradiction:
Improveremote transaction capabilityVSAvoidtransaction security
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The m-OTP is generated and stored on the mobile device before the transaction takes place, ensuring that authentication credentials are available independently of network status. This preliminary action maintains remote transaction capability while eliminating security vulnerabilities associated with network-dependent authentication.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The mobile device performs self-service by generating and storing the m-OTP locally without requiring continuous network communication or external authentication services during the transaction. This self-service approach enhances both adaptability for remote transactions and reliability for transaction security.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS12159279B2Mobile-OTP based authorisation of transactions
Publication Date: 2024.12.03 VISA INTERNATIONAL SERVICE ASSOCIATION
  • US12159279B2 patent drawing
  • US12159279B2 patent drawing
  • US12159279B2 patent drawing

AI summary

Embodiments of the present disclosure relate to methods and systems for authenticating and authorizing mobile-One Time Password (m-OTP) based transactions. 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 comprising the m-OTP and a unique identifier indicating that the transaction message comprises the m-OTP. Is submitted to a directory server (106) which sends the transaction message to an issuer system (107) for authentication and authorization. The issuer system (107) generates a response message comprising a result of 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).