Dual-Token Payment Processing Security
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing electronic payment systems are vulnerable to security risks due to the exposure of sensitive transaction data during transmission and processing, as card-related information is accessed by multiple parties and can be intercepted or compromised.
Innovation Solution
A method and system that generates and uses two tokens - a device PAN (DPAN) for the cardholder's device and a proxy PAN (PPAN) for the merchant terminal, requiring both parties' involvement for transactions, with the server validating the PPAN before submitting the transaction authorization request to the card issuing bank, thereby enhancing security by locking payment credentials to specific devices and preventing misuse.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If sensitive card data is transmitted during electronic payment processing, then payment transactions can be completed, but security risks increase due to potential interception and compromise of card information
Solution Approach 1:
The patent extracts sensitive card data from the transaction flow by introducing tokens (DPAN and PPAN) that replace actual card information. The primary account number is replaced with a device PAN, which is further replaced with a proxy PAN during merchant processing, effectively removing sensitive data from the transmission path while maintaining transaction functionality.
Solution Approach 2:
The patent introduces tokenization intermediaries (DPAN and PPAN) that mediate between the cardholder and merchant systems. These tokens act as secure intermediaries that enable transaction processing without exposing actual card data, with the server acting as the intermediary authority that generates and validates tokens.
2Adaptability or versatility
If card data is accessed by multiple parties for transaction processing, then payment functionality is enabled, but the risk of data theft and compromise increases
Solution Approach 1:
The patent removes sensitive card data from the multi-party transaction environment by replacing it with tokens. The DPAN replaces the PAN at the cardholder device, and the PPAN replaces the DPAN during merchant processing, ensuring that actual card data never leaves the secure server environment.
Solution Approach 2:
The patent applies different token types at different locations in the transaction flow: DPAN is used locally at the cardholder device, while PPAN is used locally at the merchant terminal. Each token is optimized for its specific location, with DPAN being device-specific and PPAN being terminal-specific, reducing exposure risks at each stage.
3Reliability
If tokens are generated and validated through multiple parties, then security is enhanced, but transaction processing complexity increases
Solution Approach 1:
The patent segments the tokenization process into distinct phases: first generating DPAN from PAN at the cardholder device, then generating PPAN from DPAN at the merchant terminal. This segmentation allows each party to handle only the token generation and validation relevant to their role, reducing overall system complexity while maintaining security.
Solution Approach 2:
The patent performs preliminary token generation actions: the DPAN is generated in advance and stored securely on the cardholder device, and the server prepares for PPAN generation based on the DPAN. This preliminary action reduces real-time processing complexity during the actual transaction.
Data Source
AI summary
A method is provided for processing an electronic payment. The method comprises (a) receiving, by a server, a first electronic request for a first token from a cardholder's device, the server being in communication with a database storing payment credentials for one or more payment cards associated with the cardholder; (b) generating the first token using an identity of the cardholder's device and transmitting the first token to the device; (c) receiving a second electronic request for processing the transaction from a merchant terminal, said second request comprising the first token and a merchant terminal identifier; (d) generating a second token using the first token and the merchant terminal identifier and transmitting the second token to the merchant terminal; (e) receiving a third token and a transaction authorization request from a merchant acquiring bank; (f) validating the third token using the second token; and (g) upon the validation operation (f) being successful, submitting the transaction authorization request to a card issuing bank.