In-App Browser Payment Authorization Without Extra Authentication
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing payment systems require additional authorization requests and authentication steps, such as deep linking and multi-factor authentication, which consume processing power, networking resources, and introduce security risks, while disrupting the user experience during electronic payments.
Innovation Solution
Implementing an in-app browser that allows payments from an application-associated account without additional authorization requests by determining that the payment request originated from within the application, using injected code to facilitate silent authorization, thus bypassing operating system and networking resources typically required for traditional authentication methods.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional authentication methods (deep linking, multi-factor authentication) are used, then security is improved, but processing power consumption increases and user experience is disrupted
Solution Approach 1:
The system performs preliminary authentication when the user initially accesses the application, storing authentication tokens and establishing trusted sessions. This preliminary action eliminates the need for repeated authentication during subsequent payment operations within the same session, reducing processing power consumption while maintaining security.
Solution Approach 2:
The patent introduces an intermediary integration layer that sits between the application and the payment system. This integration uses injected code to establish direct communication channels, allowing the system to verify payment requests without triggering traditional authentication flows. The intermediary handles security verification using pre-established credentials, reducing processing overhead while maintaining reliability.
2Reliability
If traditional authentication methods (deep linking, multi-factor authentication) are used, then security is improved, but user experience is disrupted
Solution Approach 1:
The patent merges the payment authentication process with the existing application flow by injecting code directly into the application's execution environment. This integration allows payment requests to be authenticated within the same user interface and session context, eliminating disruptive redirects to separate authentication screens or applications. The user experience remains continuous and seamless while security verification occurs in the background.
Solution Approach 2:
The system implements self-service authentication where the injected code within the application automatically handles verification of payment requests using pre-established credentials and tokens. The authentication process occurs autonomously without requiring user intervention or awareness, eliminating disruptive authentication steps while maintaining security. The application itself serves its own authentication needs through the integrated verification mechanism.
3Reliability
If additional authorization requests are implemented, then security is improved, but device complexity increases
Solution Approach 1:
The patent extracts the authentication logic from the traditional operating system-level deep linking mechanism and relocates it to injected code within the application environment. This extraction eliminates the need for complex inter-application communication protocols and operating system-level authentication handoffs. The verification process is simplified to direct checks within the application context, reducing system complexity while maintaining security through the use of embedded cryptographic verification.
4Reliability
If traditional authentication flows are used, then security risks are mitigated, but networking resources are consumed
Solution Approach 1:
The system performs preliminary authentication and establishes trusted sessions before payment operations. Authentication tokens and verification credentials are cached locally during the initial application launch. Subsequent payment requests within the same session use these pre-established credentials for verification, eliminating the need for network round-trips to authentication servers and reducing networking resource consumption while maintaining security.
Solution Approach 2:
The injected code acts as an intermediary that establishes direct verification channels within the application environment, bypassing traditional network-based authentication flows. The integration uses local cryptographic verification and embedded credentials to authenticate payment requests without requiring network communication with external authentication services, reducing networking resource consumption while maintaining security through cryptographically secure verification.
Data Source
AI summary
An example process includes causing a website of a merchant to load to an in-app browser within a payment application executing on a user device of a user. The example process further includes presenting, via a user interface of the user device, an interactive element on a checkout page of the website. A determination is made that the interactive element has been selected. The selection generates a payment request for a payment to the merchant from a user account associated with the payment application. The payment request is received via the in-app browser to initiate payment from the user account. The example process further includes determining that the payment request originated from within the payment application and is associated with a stored balance associated with the user account. The user account is accessed, and the payment is caused to be authorized without additional input from the user.