In-App Browser Payment Authorization Without Repeated 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's shopping experience.
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 automate the authorization process, thereby reducing the need for deep linking and network authentication.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If additional authorization requests and authentication steps are implemented, then security is improved, but processing power and networking resources are consumed, and user experience is disrupted
Solution Approach 1:
The system performs preliminary authentication when the user initially accesses the application, storing authentication tokens and authorization states. When a payment request is subsequently made within the same application session, the system reuses these pre-established credentials through the in-app browser's integrated authorization mechanism, avoiding the need to re-authenticate and thus conserving processing resources while maintaining security.
2Reliability
If deep linking and network authentication are used, then authorization is achieved, but networking resources are consumed and security risks increase
Solution Approach 1:
The system extracts the authorization functionality from external network authentication flows and deep linking mechanisms, and embeds it directly within the application through the in-app browser. This extraction allows the system to handle authorization requests internally using pre-established credentials, eliminating the need for additional network communication and deep linking operations, thus conserving networking resources while maintaining secure authorization.
3Reliability
If multiple authentication steps are required, then security is enhanced, but user experience is disrupted
Solution Approach 1:
The system merges the payment request flow with the existing application session context. When a user makes a payment request through the in-app browser, the system combines this with the already-established authentication state from the main application, allowing the transaction to proceed without requiring the user to undergo separate authentication steps. This merging maintains security by leveraging the existing authenticated session while providing a seamless, uninterrupted user experience.
4Reliability
If data is exposed to the operating system for authentication, then authorization is achieved, but security risks increase
Solution Approach 1:
The in-app browser acts as an intermediary layer between the payment request system and the operating system's authentication mechanisms. Instead of directly exposing sensitive authentication data to the operating system, the intermediary browser component handles the authorization request using embedded credentials and tokens, mediating the authentication process in a way that achieves necessary authorization while minimizing security risks by avoiding direct data exposure to the OS.
Data Source
AI summary
An example process includes causing a payment application to launch on a user device. Based on an interaction with a first interactive element of a user interface of the payment application, a merchant website loads to an in-app browser within the payment application. Selection of a second interactive element on a checkout page of the website is associated with use of the payment application as a form of payment for a transaction with the merchant. A third interactive element associated with confirmation that the user intends to pay with the payment application from a user account associated with the payment application can be presented. A payment request is received via the in-app browser and it is determined that the request originated from within the payment application and that it is associated with the user account. Payment is authorized without additional input.