Payment System Push Model Inversion for Transaction Security
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional payment systems rely on a 'pull' model where consumers provide identifying information to merchants, leading to issues like unverified authorizations, incorrect postings, and transactions against insufficient funds, resulting in losses and risks for both payers and payees.
Innovation Solution
The Check22 system introduces a 'push' model where payers create electronic substitute checks, managing transactions from their own accounts, reducing risks through real-time risk management and authorization control, and eliminating the need for merchants to access payer account information.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Extent of automation
If traditional pull model is used where merchants access payer account information, then automated transaction processing is enabled, but security risks and unauthorized transactions increase
Solution Approach 1:
The patent inverts the traditional payment authorization model by shifting control from the merchant (pull model) to the payer (push model). Instead of the merchant initiating transactions by accessing the payer's account information, the payer actively initiates transactions by pushing authorized payment instructions. This inversion fundamentally resolves the security contradiction by eliminating merchant access to payer account information while maintaining automated processing through the payer's initiated transactions.
Solution Approach 2:
The patent extracts sensitive account information from the merchant's access scope and places it exclusively under the payer's control. By removing the merchant's ability to access or store the payer's account credentials, the system eliminates the security vulnerability while preserving transaction functionality through the payer's direct initiation of payments.
2Ease of operation
If merchant stores and uses payer account information for transactions, then transaction convenience is improved, but risks of incorrect postings and insufficient funds transactions increase
Solution Approach 1:
The patent inverts the transaction initiation responsibility from merchant to payer. The payer directly initiates transactions with explicit authorization, ensuring that only verified and intended transactions are processed. This eliminates the merchant's role in accessing account information, thereby preventing incorrect postings and insufficient funds transactions while maintaining convenience through the payer's direct control.
Solution Approach 2:
The system implements feedback mechanisms where the payer receives confirmation and control over each transaction before it is executed. The payer's explicit authorization acts as a feedback loop that verifies transaction intent, ensuring accuracy and preventing erroneous transactions while maintaining ease of operation through streamlined payer-initiated processes.
3Productivity
If payer provides identifying information to merchant, then payment processing is simplified, but exposure to fraud and unauthorized access increases
Solution Approach 1:
The patent extracts sensitive identifying information from the transaction flow between payer and merchant. Instead of the payer providing account information to the merchant, the system uses the payer's direct initiation of transactions with embedded authorization. This extraction of sensitive data from the merchant's scope eliminates fraud risk while preserving payment processing efficiency through the payer's direct control.
Solution Approach 2:
The system introduces an intermediary mechanism where the payer's direct transaction initiation serves as the mediator between the payer's account and the merchant. This intermediary process eliminates the need for the payer to share identifying information with the merchant, reducing fraud risk while maintaining efficient payment processing through the structured authorization flow.
Data Source
AI summary
A payment system having a payer module and a requester module functionally coupled over a network and managed by an administration module that produces electronic substitute checks in response to instructions from the payer module. The payment system includes a risk management module that performs a risk management operation before the system produces an electronic substitute check.