Payment Authentication Flow Using Dynamic Card Security Codes

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing e-commerce payment systems require customers to undergo a cumbersome two-factor authentication process for online transactions, particularly with digital or virtual payment cards, leading to abandonment of purchases and economic loss for merchants.

Innovation Solution

A method where a merchant server requests payment parameters, including a dynamic card security code, only after successful user authentication for certain payment instruments, allowing the 3DS authentication to be bypassed if the instrument is of a specific type, and includes a consent mechanism to ensure user agreement, simplifying the transaction process.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If 3DS authentication is performed for all payment instruments, then security is improved, but transaction complexity and time increase

Engineering Contradiction:

ImprovesecurityVSAvoidtransaction complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The patent applies different authentication requirements to different payment instrument types. Digital and virtual payment cards (first type) receive enhanced authentication via dynamic card security code delivery, while physical payment cards (second type) use traditional 3DS authentication. This localized differentiation resolves the contradiction by tailoring security measures to specific instrument characteristics rather than applying uniform complexity to all.

Inventive Principle:

Principle #3Local quality

Solution Approach 2:

The patent introduces dynamic card security codes that change over time or per transaction for digital and virtual payment instruments. This dynamic authentication mechanism adapts security requirements based on the payment instrument type and transaction context, allowing streamlined authentication for certain instruments while maintaining strong security where needed, thus resolving the contradiction between security and complexity.

Inventive Principle:

Principle #15Dynamics

2Reliability

If 3DS authentication is required, then security is improved, but transaction time increases

Engineering Contradiction:

ImprovesecurityVSAvoidtransaction time

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

The patent delivers dynamic card security codes to users in advance or during the payment flow for digital and virtual payment instruments, enabling authentication to be completed more efficiently. This preliminary provision of authentication credentials eliminates the need for separate 3DS authentication steps for these instrument types, reducing transaction time while maintaining security through the dynamic code mechanism.

Inventive Principle:

Principle #10Preliminary action

3Reliability

If dynamic card security code is delivered only after authentication, then security is improved, but ease of operation deteriorates

Engineering Contradiction:

ImprovesecurityVSAvoidease of operation

Core Design Contradiction:

ReliabilityVSEase of operation

Solution Approach 1:

The patent inverts the traditional authentication sequence for digital and virtual payment instruments. Instead of requiring authentication before providing the card security code, the system delivers the dynamic card security code first (through the banking application or communication device), and then uses this code for authentication. This inversion simplifies the user experience by eliminating the need to access the banking application twice, while security is maintained through the dynamic nature of the code and server-side validation.

Inventive Principle:

Principle #13The other way round (Inversion)

Data Source

PatentEP4675539A1Payment system and method for managing a payment transaction

Publication Date: 2026.01.07 THALES DIS FRANCE SA

Figure 1
Figure 2

AI summary

The invention is a method for managing a payment transaction in which a merchant server (10) gets payment parameters (21) specific to a payment instrument (20) which is either of a first type for which a dynamic card security code (55) is delivered to the user only after a successful strong customer authentication of the user, or of a second type for which the dynamic card security code is delivered to the user without a successful strong customer authentication. The merchant server requests a 3DS authentication by sending to an ACS (40), an authentication request (101) comprising a subset of payment parameters. The ACS checks if the payment instrument is of the first type by using the subset and, if so decides to continue the payment transaction without performing the 3DS authentication on the payment instrument and sends back an authentication response (402) reflecting an agreement to pursue the payment transaction.