Systems and methods for data automatic updates and synchronization

Abstract

Described are methods and systems for data automatic updates and synchronization. The method comprises: receiving, from an issuer system, a request to change a default POF on an account associated with the user on the merchant system, the issuer system is configured to manage a card that the user selects to use for the merchant system; receiving, from the user, credentials for authenticating the user's account on the merchant system; transmitting, to the merchant system, the credentials to authenticate the user's credentials; receiving, from the merchant system, an indication that the user's credentials for the user's account have been authenticated for the merchant system; and transmitting instructions to the merchant system to change the default POF for the user's account to the card that the user selects to use for the merchant system.

Description

[0001] AttyDktNo.: 66416-702601

[0002] SYSTEMS AND METHODS FOR DATA AUTOMATIC UPDATES AND SYNCHRONIZATION

[0003] CROSS-REFERENCE

[0004] [1] This application claims priority to U.S. Provisional Application No. 63 / 748,630, filed January 23, 2025, U.S. Provisional Application No. 63 / 894,924, filed October 7, 2025, and U.S. Application No. 19 / 237,975, filed June 13, 2025, each which is incorporated herein by reference in its entirety.

[0005] BACKGROUND

[0006] [2] Many merchants and vendors receive payment from their customers using online payments. Credit card or debit card payments may be performed online by providing the required information to authorize payment. Online payments offer ease of use for the customer, as the customer does not need to rely on traditional methods of payments such as visiting a brick-and-mortar store or mailing in a check. Many merchants offer the option of storing payment account information on file so that the customer can make payments easier and quicker the next time. This can be particularly helpful for recurring purchases such as monthly bill payments or frequent and irregular payments such as when shopping online at the merchant store.

[0007] SUMMARY

[0008] [3] Switching the default payment-accounts-on-file (POF) at vendor websites can pose a challenge for consumers, card issuers, and merchants / vendors alike. For consumers, consumers have to manually visit each individual website, log-in, and update the default POF. This can become a tedious and daunting task, as the consumers may have to spend hours upon hours trying to update their cards, and the time consumption may be compounded if the consumers do not have their log-in information readily available for websites that they do not frequently visit. For card issuers such as banks and other financial institutions, it is desirable for card issuers for the consumers to use issuer’s cards as much as possible so that they collect fees from use.

[0009] However, if the consumer has to manually change each default POF, the consumer may not do that or only do it for a subset of merchants that the consumers use, which can lead to lower usage. And finally, merchants want to make sure the consumer has an active POF that they are using, rather than for example a card they don’t use often or at all which may be in danger of being canceled, and a canceled card can lead to delayed payments or even canceled

[0010] subscriptions.AttyDktNo.: 66416-702601

[0011] [4] Accordingly, there is a need for systems and methods for consumers to easily switch cards on file. Provided herein are systems and methods that enable consumers to seamlessly switch their default payment-account-on-file (POF) at multiple merchant websites. A payment account switcher interface can be provided on the website of the card issuer. The payment account switcher interface may provide a list of merchants that are commonly used to the consumer so that the consumer can select which merchants they want to switch the POF. The consumer can log-in to their selected merchants by providing log-in information which may be kept secure. The systems and methods disclosed herein can be adapted or made compatible with a variety of merchants and vendors’ websites.

[0012] [5] In one aspect, disclosed herein is a computer implemented method for securely switching a default payment option on file with a merchant system, comprising: receiving, at a payment account switcher engine backend, encrypted cardholder data from a financial institution, wherein the cardholder data is encrypted using JSON Web Encryption (JWE) with a public key, and wherein a corresponding private key for decrypting the JWE is held exclusively by a secure enclave and is not accessible to the payment account switcher engine backend; transmitting the encrypted cardholder data from the payment account switcher engine backend to the secure enclave without decrypting the cardholder data at the backend; receiving, at the payment account switcher engine backend from the secure enclave, a ciphertext reference corresponding to the cardholder data, where the ciphertext reference is an opaque identifier that cannot be used by the backend to access plaintext cardholder data; receiving, at the payment account switcher engine backend, a user selection indicating a merchant system with which to update a default payment option on file; transmitting, from the payment account switcher engine backend to the secure enclave, a provisioning request comprising the ciphertext reference and a merchant identifier corresponding to the selected merchant system; within the secure enclave, decrypting the ciphertext reference to retrieve the plaintext cardholder data; transmitting, from the secure enclave directly to the merchant system, the plaintext cardholder data via a secure communication channel using mutual transport layer security (TLS) version 1.2 or higher; receiving, at the secure enclave from the merchant system, a provisioning status response indicating whether the cardholder data was successfully stored as the default payment option on file; transmitting, from the secure enclave to the payment account switcher engine backend, the provisioning status response without including the plaintext cardholder data; and transmitting, from the payment account switcher engine backend to a user device, a confirmation interface indicating that the default payment option on file has been updated with the merchant system, the payment account switcher engine backend does not have access to the plaintext cardholder dataAttyDktNo.: 66416-702601

[0013] at any point during the method. The secure enclave is configured such that administrative access via secure shell (SSH) protocol is disabled to prevent extraction of decrypted cardholder data.

[0014] [6] In some embodiments, the encrypted cardholder data is alternatively received through a Payment Card Industry (PCI) compliant proxy service provider, wherein a token representing the cardholder data is received at the payment account switcher engine backend from the PCI compliant proxy service provider, the token is transmitted to the secure enclave, and the secure enclave resolves the token to the plaintext cardholder data by communicating with the PCI compliant proxy service provider through an authenticated application programming interface (API), wherein the plaintext cardholder data obtained from token resolution remains within the secure enclave and is not transmitted to the payment account switcher engine backend.

[0015] [7] In some embodiments, the ciphertext reference is transmitted to a tokenization service provider, one or more aliases representing portions of the cardholder data and billing information are received from the tokenization service provider, and the one or more aliases are used in subsequent provisioning operations with additional merchant systems, wherein the tokenization service provider decrypts the one or more aliases within an isolated secure environment prior to provisioning the cardholder data to the merchant system. In some embodiments, a session identifier is created at a payment service provider system, the session identifier is transmitted to a payment account switcher front end interface, a user interface context within the payment service provider system is initialized using the session identifier, and the session identifier is bound to the ciphertext reference, wherein the session identifier is a server side programmatic session issued to the payment account switcher engine backend and is distinct from merchant issued browser session cookies. In some embodiments, the default payment option on file includes a payment account that is saved on an account associated with the user on the merchant system and used to make purchases by the user.

[0016] [8] In another aspect, disclosed herein is a computer implemented method for securely authenticating a user with a merchant system to enable payment option switching, comprising: determining, by a payment account switcher engine, whether the merchant system supports webview based authentication; responsive to determining that the merchant system supports webview based authentication: rendering, within a sandboxed webview in a payment account switcher front end interface, a native login page provided by the merchant system; receiving, at the sandboxed webview, authentication credentials entered by the user directly into the native login page; transmitting the authentication credentials from the sandboxed webview to the merchant system; receiving, at the sandboxed webview from the merchant system, one or moreAttyDktNo.: 66416-702601

[0017] authentication tokens selected from the group consisting of session cookies, JSON Web Tokens (JWT), and OAuth tokens; performing client side validation of the one or more authentication tokens; streaming the one or more authentication tokens from the sandboxed webview to a payment account switcher engine backend; and performing server side validation of the one or more authentication tokens at the payment account switcher engine backend; responsive to determining that the merchant system does not support webview based authentication: capturing authentication credentials from the user at the payment account switcher front end interface; transmitting the authentication credentials from the payment account switcher front end interface to a secure enclave via an encrypted relay mechanism, wherein the authentication credentials bypass the payment account switcher engine backend; receiving, at the payment account switcher front end interface from the secure enclave, a credential reference that serves as an opaque identifier for the authentication credentials; transmitting the credential reference from the payment account switcher front end interface to the payment account switcher engine backend; transmitting an authentication request from the payment account switcher engine backend to the secure enclave, the authentication request comprising the credential reference and a merchant identifier; within the secure enclave, retrieving the authentication credentials using the credential reference; transmitting the authentication credentials from the secure enclave to the merchant system; receiving, at the secure enclave from the merchant system, an authentication response comprising one or more authentication tokens; and transmitting the authentication response from the secure enclave to the payment account switcher engine backend without including the plaintext authentication credentials; and using the authentication tokens received from the merchant system to authorize a payment option switching operation. The payment account switcher engine backend does not have access to plaintext authentication credentials in authentication flows where credentials are relayed through the secure enclave, and the secure enclave is configured such that administrative access via secure shell (SSH) protocol is disabled.

[0018] [9] In some embodiments, determining whether the merchant system supports webview based authentication comprises querying a merchant configuration database comprising entries indicating authentication methods supported by a plurality of merchant systems and retrieving an authentication method indicator corresponding to the merchant system. In some embodiments, responsive to determining that authentication is being performed on a desktop computing device, the method further comprises establishing a Virtual Network Computing (VNC) connection to a remote session; loading a login page of the merchant system within a browser in the remote session; streaming video of the remote session to the desktop computing device; receiving user interactions with the login page through the VNC connection; capturing authentication tokensAttyDktNo.: 66416-702601

[0019] generated by the merchant system in the remote session; and terminating the VNC connection after authentication is complete, wherein authentication credentials entered by the user remain within the remote session and are not transmitted to the payment account switcher engine backend.

[0020]

[0010] In some embodiments, the server side validation comprises validating a digital signature on the one or more authentication tokens; verifying an expiration timestamp associated with the one or more authentication tokens; detecting whether the one or more authentication tokens have been revoked by the merchant system; and responsive to detecting an expired or revoked token, triggering a re authentication flow. In some embodiments, authentication requests are routed through a Web Application Firewall (WAF), and the method comprises performing, at the WAF, request validation comprising detecting malicious request patterns selected from the group consisting of SQL injection attempts, cross site scripting attempts, command injection attempts, and credential stuffing attempts; and blocking requests identified as malicious before they reach the payment account switcher engine backend.

[0021]

[0011] In some embodiments, rendering the native login page within the sandboxed webview comprises configuring a custom user agent string to ensure compatibility with the merchant system; executing merchant specific scripts to provide a coherent authentication experience; and maintaining session state within the sandboxed webview such that the user authentication experience matches the experience of authenticating directly on the merchant website. In some embodiments, the secure enclave is an isolated computing environment that is architecturally separated from the payment account switcher engine backend and is configured such that the payment account switcher engine backend cannot decrypt or access plaintext values of sensitive data at any point during processing, thereby providing a zero knowledge architecture with respect to sensitive payment and authentication data. In some embodiments, the secure enclave is implemented with hardware based security mechanisms selected from the group consisting of trusted execution environments (TEEs), hardware security modules (HSMs), and secure compute instances provided by cloud infrastructure providers. In some embodiments, the secure enclave generates audit logs that record the occurrence of operations without logging plaintext values of sensitive data, wherein the audit logs are transmitted to a secure logging infrastructure for compliance and auditing purposes while preserving confidentiality of underlying data.

[0022]

[0012] In one aspect, disclosed herein is a computer-implemented method for changing a default POF for a user on a merchant system, comprising: receiving, from an issuer system, a request to change a default POF, wherein the issuer system is configured to manage an account that theAttyDktNo.: 66416-702601

[0023] user selects to use as the default POF; predicting, one or more merchant systems associated with the user and displaying the one or more merchant systems to the user for the user to select to change the default POF; upon receiving a user input indicative of selecting at least one merchant system, receiving, from the user, credentials for authenticating the user’s account on the at least one merchant system and transmitting, to the merchant system, the credentials to authenticate the user’s credentials; receiving, from the at least one merchant system, an indication that the user’s credentials for the user’s account have been authenticated for the at least one merchant system; and transmitting instructions to the at least one merchant system to change the default POF for the user’s account to the account that the user selects to use.

[0024]

[0013] In some embodiments, the default POF includes a payment account that is saved on the account associated with the user on the merchant system and used to make purchases by the user.

[0025]

[0014] In some embodiments, changing the default POF includes changing from a first payment account to a second payment account on the merchant system for future transactions made by the user.

[0026]

[0015] In some embodiments, transmitting instructions to the merchant system to change the default POF comprises transmitting an API call to the one or more endpoints associated with the merchant system to perform the change.

[0027]

[0016] In some embodiments, transmitting the API call comprises transmitting payment account information related to the payment account to the merchant system.

[0028]

[0017] In some embodiments, transmitting instructions to the merchant system to change the default POF includes instantiating a web browser and simulating a direct interaction with the merchant client on the web browser.

[0029]

[0018] In some embodiments, transmitting instructions to the merchant system to change the default POF includes monitoring data traffic to and from the merchant system and simulating manually changing the default POF.

[0030]

[0019] In some embodiments, the payment account information includes information related to a card number, an expiration date, and a verification code.

[0031]

[0020] In some embodiments, the payment account information is contained within a token.

[0032]

[0021] In some embodiments, the method further comprises, after receiving the indication, storing (i) user information including one or more of name, address, or phone number and / or (ii) the payment account information.AttyDktNo.: 66416-702601

[0033]

[0022] In some embodiments, the method further comprises, prior to receiving the request, providing the user, via the issuer system, a payment account switcher interface to enter a set of information related to the account associated with the user.

[0034]

[0023] In some embodiments, the method further comprises providing the user, via the payment account switcher interface, a list of merchants that the user can select.

[0035]

[0024] In some embodiments, the list of merchants is determined based at least in part on popularity of the merchants, relevance determined based at least in part on a characteristic of the user (e.g., age, geographic location, etc.), and / or a list prepared by the issuer system.

[0036]

[0025] In some embodiments, the method further comprises, prior to receiving the request, receiving an indication that the user has the account with a merchant associated with the merchant system.

[0037]

[0026] In some embodiments, the method further comprises transmitting instructions to the issuer system to display an image, text, or other indication that the user has the account with the merchant.

[0038]

[0027] In some embodiments, the method further comprises, prior to receiving the request, providing the issuer system a software development kit (SDK) to customize or create the payment account switcher interface that is shown to the user.

[0039]

[0028] In some embodiments, the method further comprises, prior to receiving the request, when the user is using a mobile device: generating a merchant webview of a login page associated with the merchant, wherein the merchant webview is a custom log-in page associated with the merchant; and transmitting instructions to the issuer system to display the merchant webview to receive log-in information from the user.

[0040]

[0029] In some embodiments, the method further comprises, after transmitting the instructions to display the merchant webview, monitoring the merchant webview for changes in cookies and / or URLs to determine when the merchant is authenticated.

[0041]

[0030] In some embodiments, the method further comprises, during the monitoring, detecting that the user has successfully logged in to the account for the merchant.

[0042]

[0031] In some embodiments, the method further comprises, after generating the merchant webview, transmitting instructions to the issuer system to: generate a log-in page that is overlaid over the merchant webview; receive the credentials of the user via the log-in page; transfer the credentials to the merchant system via the merchant webview; and submit the credentials to the merchant system.AttyDktNo.: 66416-702601

[0043]

[0032] In some embodiments, the method further comprises, after submitting the credentials to the merchant system, monitoring authentication of the credentials and providing any error messages, captchas, one-time password (OTP) requests, etc. to the user.

[0044]

[0033] In some embodiments, the method further comprises, after providing any error messages, captchas, OTP requests, etc. to the user, receiving a response from the user and transmitting the response to the merchant webview.

[0045]

[0034] In some embodiments, authenticating the user’s credentials comprises, when the user is using a desktop or laptop computer: using an HTTP reverse proxy that shows a merchant webpage on to the user on a domain that is different from a merchant domain associated with the merchant; and providing one or more requests received from the user to the merchant domain based on one or more requests on the merchant webpage on the different domain.

[0046]

[0035] In some embodiments, the method further comprises using an HTTP forward proxy between the issuer system and the merchant system to control data that is sent to the merchant system.

[0047]

[0036] In some embodiments, authenticating the user’s credentials comprises, when the user is using a desktop or laptop computer: hosting a remote browser on a processor other than the desktop or laptop computer used by the user, wherein the remote browser has a URL set to a merchant webpage; streaming the merchant webpage to the desktop or laptop computer used by the user for authenticating the credentials.

[0048]

[0037] In some embodiments, the steps of receiving the request, receiving the credentials, transmitting the credentials, receiving the indication, and transmitting the instructions to the merchant system are performed using APIs, webhooks, and / or programming instructions such as Javascript.

[0049]

[0038] In some embodiments, the webhooks are configured to monitor for one or more events including the user access or opening the merchant on the payment account switcher interface, authenticating the user credentials for the merchant system, updating the card on the merchant system, or completion of changing the default POF to the card.

[0050]

[0039] In some embodiments, during receiving the credentials, receiving from the user cookies, an access token, session data, JSON web tokens, etc. through the payment account switcher interface.

[0051]

[0040] In some embodiments, the method further comprises collecting or storing transaction information and / or profile information in a database.AttyDktNo.: 66416-702601

[0052]

[0041] In some embodiments, the merchant system includes an e-commerce system, a ridesharing system, a food delivery system, a travel system, a streaming system, a gaming system, etc.

[0053]

[0042] In some embodiments, the transaction information comprises seller information, pricing information, product information, ridesharing information, driver information, flight information, hotel or lodging information, etc.

[0054]

[0043] In an aspect, a computer-implemented system is provided for managing and updating a default payment-account-on-file (POF) for a user on a merchant system. The system comprises a backend engine configured to transmit a payment context identifier to a payment service provider (PSP) associated with a user account, receive a cryptographically bound payment token upon selection of a payment instrument, and update the merchant’s default payment option on file based on an approved payment context generated upon authorization of the selected payment instrument. The backend engine is further configured to provide confirmation of the update to a frontend application.

[0055]

[0044] In some embodiments, the approved payment context comprises one or more of a payment context identifier, a pointer to a vaulted payment token, a merchant identifier, a user account identifier, an authorization status, or a limited time-to-live (TTL) parameter. In some embodiments, the backend engine transmits the approved payment context to the merchant system through a secure application programming interface (API) call.

[0056]

[0045] In an aspect, a computer-implemented method is provided for securely updating a payment option on file at a merchant system. The method comprises receiving a request to update a default payment option associated with a user account, transmitting a payment context identifier to a payment service provider system, authenticating ownership of a payment instrument, generating a cryptographically signed approved payment context that includes account and merchant bindings, token references, authorization status, and time-to-live parameters, transmitting the approved payment context to the merchant system, and updating the default payment option upon validation of a cryptographic signature.

[0057]

[0046] In some embodiments, the method further comprises vaulting a processor-issued payment token at the merchant system and updating the default payment option using the vaulted token.

[0058]

[0047] In some embodiments, the approved payment context comprises a digitally signed capability object.AttyDktNo.: 66416-702601

[0059]

[0048] In some embodiments, the approved payment context cryptographically binds the payment token to a permitted merchant domain.

[0060]

[0049] In some embodiments, the merchant system stores token references without storing raw payment credentials.

[0061]

[0050] In some embodiments, the approved payment context is reusable across multiple merchant systems subject to domain restrictions embedded within the approved payment context.

[0062]

[0051] In some embodiments, the method further comprises validating cryptographic signatures of approved payment contexts prior to updating default payment options.

[0063]

[0052] In an aspect, a computer-implemented method is provided for subscription management. The method comprises receiving a request to access subscription data for one or more third-party merchants, generating a backend-owned programmatic session identifier, authenticating to each respective third-party merchant using user-associated credentials, retrieving subscription metadata under control of the programmatic session identifier, causing at least a portion of the subscription metadata to be displayed on a graphical user interface, receiving a subscription management instruction via the graphical user interface, and executing a corresponding application programming interface (API) call to effect the subscription management instruction.

[0064]

[0053] In some embodiments, the programmatic session identifier is maintained by the backend component and is not forwarded from a user browser. In some embodiments, the programmatic session identifier represents a scoped authorization binding specifying permitted subscription operations and an expiration policy. In some embodiments, the subscription metadata is retrieved via a merchant API. In some embodiments, the session is a server-side merchant session that is refreshed using token refresh flows without requiring re-authentication by the user.

[0065]

[0054] In some embodiments, credentials associated with a user account are stored in a secure vault. In some cases, the credentials are cryptographically inaccessible to a user device. In some embodiments, the graphical user interface displays an option for one-tap card rebinding or subscription creation using the programmatic session identifier

[0066]

[0055] Non-transitory computer-readable media comprising executable instructions that, when executed, cause at least one computer processor to perform any of the methods discussed herein.

[0067]

[0056] A computer system comprising a memory storing computer-readable instructions and at least one processor configured to execute the computer-readable instructions that are configured to perform any of the methods discussed herein.AttyDktNo.: 66416-702601

[0068] BRIEF DESCRIPTION OF THE DRAWINGS

[0069]

[0057] A better understanding of the features and advantages of the present disclosure will be obtained by reference to the following detailed description that sets forth illustrative embodiments and the accompanying drawings of which:

[0070]

[0058] FIG. 1A and FIG. IB shows an example of a system for implementing card switching in accordance with some embodiments; FIG. 1C shows an example of account updater component.

[0071]

[0059] FIG. 2 shows an example of a process flow for switching cards using the payment account switcher interface, in accordance with some embodiments.

[0072]

[0060] FIGs. 3, 4, 5, and 6 show example screenshots of a user interface of the payment account switcher interface on a mobile device, in accordance with some embodiments.

[0073]

[0061] FIGs. 7, 8, 9, and 10 show example screenshots of a user interface of the payment account switcher interface on a computer, in accordance with some embodiments.

[0074]

[0062] FIG. 11 shows an example of a computer system that is programmed or otherwise configured to implement card switching, in accordance with some embodiments.

[0075]

[0063] FIG. 12 shows an example screenshot of a dashboard for monitoring default payment accounts, in accordance with some embodiments.

[0076]

[0064] FIG. 13 shows the mass switching component implemented in the backend in communication with a credential management system for a mass switching feature.

[0077]

[0065] FIG. 14 shows an example of a webview displaying an option for a user to log into a credential management account or a single sign-on (SSO)account.

[0078]

[0066] FIG. 15 shows an example of user interface for subscription management.

[0079]

[0067] FIG. 16 shows an example of SKU-level transaction data.

[0080]

[0068] FIG. 17 shows an example of webview or GUI of a transaction link module.

[0081]

[0069] FIG. 18 shows an example of using transaction link module to automate user cashback rewards, ensuring faster processing and eliminating manual receipt uploads for users.

[0082]

[0070] FIGs. 19-21 show examples of a one-click agentic shopping feature provided by the system herein.

[0083]

[0071] FIG. 22 shows an example of a process flow for connecting cardholders or users of payment account to any selected marchant applications using a payment account switcher front end and back end, in accordance with some embodiments.AttyDktNo.: 66416-702601

[0084]

[0072] FIGs. 23A-23C show example screenshots of a graphical user interface of the payment account switcher interface on a mobile device for selecting a merchant, authenticating the merchant account, and providing the payment context to the merchant, in accordance with some embodiments.

[0085]

[0073] FIG. 24 illustrates an example network architecture using the secure enclave system.

[0086]

[0074] FIG. 25 shows an example flow of encrypted cardholder data through the secure enclave system.

[0087] DETAILED DESCRIPTION

[0088]

[0075] While various embodiments have been shown and described herein, it will be obvious to those skilled in the art that such embodiments are provided by way of example only. Numerous variations, changes, and substitutions may occur to those skilled in the art without departing from the present disclosure. It should be understood that various alternatives to the embodiments described herein may be employed.

[0089]

[0076] Whenever the term “at least,” “greater than,” or “greater than or equal to” precedes the first numerical value in a series of two or more numerical values, the term “at least,” “greater than” or “greater than or equal to” applies to each of the numerical values in that series of numerical values. For example, greater than or equal to 1, 2, or 3 is equivalent to greater than or equal to 1, greater than or equal to 2, or greater than or equal to 3.

[0090]

[0077] Whenever the term “no more than,” “less than,” or “less than or equal to” precedes the first numerical value in a series of two or more numerical values, the term “no more than,” “less than,” or “less than or equal to” applies to each of the numerical values in that series of numerical values. For example, less than or equal to 3, 2, or 1 is equivalent to less than or equal to 3, less than or equal to 2, or less than or equal to 1.

[0091]

[0078] The term “real time” or “real-time,” as used interchangeably herein, generally refers to an event (e.g., an operation, a process, a method, a technique, a computation, a calculation, an analysis, a visualization, an optimization, etc.) that is performed using recently obtained (e.g., collected or received) data. In some cases, a real time event may be performed almost immediately or within a short enough time span, such as within at least 0.0001 millisecond (ms), 0.0005 ms, 0.001 ms, 0.005 ms, 0.01 ms, 0.05 ms, 0.1 ms, 0.5 ms, 1 ms, 5 ms, 0.01 seconds, 0.05 seconds, 0.1 seconds, 0.5 seconds, 1 second, or more. In some cases, a real time event may be performed almost immediately or within a short enough time span, such as within at most 1AttyDktNo.: 66416-702601

[0092] second, 0.5 seconds, 0.1 seconds, 0.05 seconds, 0.01 seconds, 5 ms, 1 ms, 0.5 ms, 0.1 ms, 0.05 ms, 0.01 ms, 0.005 ms, 0.001 ms, 0.0005 ms, 0.0001 ms, or less.

[0093] System

[0094]

[0079] FIG. 1A shows an example of an architecture of a system 100 for implementing a payment account switcher, in accordance with some embodiments. A payment account switcher as described herein is capable of or configured to change or switch the default POF on a merchant or vendor system. In some embodiments, the system 100 includes an issuer system 110, a payment account switcher engine 120, and a plurality of merchant systems 131, 132, 133, 134, and 135 (collectively called merchant system 130). The payment account switcher engine 120 may communicate with a payment account switcher database 125 that may securely store data that is provided to the payment account switcher engine 120. The issuer system 110 may include a payment account switcher interface 115 that permits a user to interact with and provide inputs to change the default POF. The different components, systems, and subsystems within the system 100 may communicate with one another via any wired or wireless communications means.

[0095]

[0080] The issuer system 110 may include any financial institution (e.g., bank, credit union) that can issue a card (e.g., credit card or debit card) or host / manage a consumer financial account (e.g., checking account, savings account, etc.). In some embodiments, the default POF includes a payment account that is saved on the account associated with the user on the merchant system and used to make purchases by the user. The issuer system 110 may include a banking environment whereby one or more cards may be issued for a user. Various payment account information may be viewable or accessible by the user in the issuer system 110 using a user interface such as a graphical user interface (GUI) that includes the payment account switcher interface 115. For example, the user may be able to view information related to recent transactions such as payee information, transaction amounts, transaction dates, etc. Further, various user information may be viewable and / or modified by the user using the user interface. For example, the user may modify any autopay options, modify the billing and / or mailing address for the payment account, etc.

[0096]

[0081] While this disclosure generally discusses payment accounts and changing the default POF in the merchant system with respect to a card such as a credit card or a debit card for ease of description, embodiments are not limited thereto, and other types of payment methods may be used. For example, the default payment method on the merchant system may include a checking account or a savings account in a financial institution such as a bank or credit union, a cashAttyDktNo.: 66416-702601

[0097] account associated with a trading account, gift cards, a digital payments solution such as Venmo® or PayPal®, and others. Information that is relevant to the type of payment account may be used.

[0098]

[0082] The issuer system 110 can be configured to perform or implement one or more methods for issuing a new credit card for the user. For example, the issuer system 110 can be configured to receive an application from the user for a new credit card, and the issuer system 110 can be configured to approve the user for the new credit card based at least in part on the user’s credit history, credit score, etc. When the card is issued and available for use, the issuer system 110 can be configured to provide access to payment account information using the issuer system 110. The user may now use the new card on merchant systems 130 and use the payment account switcher described herein.

[0099]

[0083] In some embodiments, the payment account switcher interface 115 may be dynamically generated and populated for the user. In some embodiments, the payment account switcher interface 115 may show one or more merchants that the user can connect to. In some embodiments, the user may use the payment account switcher interface 115 to select which merchants for which the user selects to switch the default POF on the respective merchant system 130.

[0100]

[0084] The payment account switcher engine 120 may include one or more processors that are connected together to perform the steps of the process described herein. In some embodiments, the payment account switcher engine 120 may comprise a backend server or logic for the system 100. The payment account switcher engine 120 may be deployed in a cloud computing environment. The payment account switcher engine 120 may include an authorization module 122 and a switching module 124. The authorization module 122 may be configured to authorize a new user to the payment account switcher ecosystem and authorizing the user for the merchants that are enabled on the merchant systems 131-135.

[0101]

[0085] The merchant system 130 may include any e-commerce business that accepts credit or debit card payments online. The e-commerce business may include online stores of retailers such as clothing or grocery stores, online or network service providers such as phone companies, Internet service providers, etc., home service providers such as pest control and cleaning services, etc., websites with paid subscriptions such as streaming services, news websites, etc., other financial institutions such as banks, brokerages, etc., and many others. The types of businesses that use the merchant system 130 is not limited to those described herein but can include any business with that can accept payment online is included. In this disclosure, anyAttyDktNo.: 66416-702601

[0102] business that can accept online payment may be considered a merchant for ease of reference. Although five merchant systems 131-135 are shown, embodiments are not limited thereto, and fewer or more merchant systems may be connected to and accessible by the payment account switcher engine 120. In some embodiments, the merchant systems 130 may interface with the payment account switcher engine 120 via a website, a progressive web app, a mobile app, etc.

[0103]

[0086] In some embodiments, data other than payment account information may be collected and / or stored from merchant systems and / or issuer systems including transaction information and profile information for various types of merchants and merchant systems. For example, the merchant system 130 may be for an e-commerce, ridesharing, food delivery, travel, streaming, gaming, etc. For example, for an e-commerce website, the data may pertain to product information for an e-commerce system, where the data may include seller information (e.g., name, URL of seller website), price of the product (e.g., discounted price, fees, fees per item), product ID, product name, product description, name of retailer and / or platform of listing, barcode information, shipment information such as how long shipment took, etc. In some embodiments, the data may pertain to rides that are ordered on a ridesharing system, where the data may include ride type, pick-up date and location, drop-off date and location, distance, vehicle information, driver information, price, etc. In some embodiments, the data may pertain to flight information for an airline system, where the data includes airline name, plane type, departure date and location, arrival date and location, seat number, seat type, any connecting flight information, etc. In some embodiments, the data may pertain to hotel or lodging reservation information for a hotel or lodging system, where the data includes hotel reservation information, hotel name, hotel brand, hotel location, room type, check-in date and time, checkout date and time, number of guests, contact information, etc. In some embodiments, the data may pertain to vehicle rentals for a vehicle rental system, where the data includes vehicle details (e.g., make, model, license plate, etc.), vehicle pick-up date and location, drop-off date and location, add-on services such as insurance, etc.

[0104]

[0087] In some embodiments, the data may pertain to subscription services for a subscription system, where the data includes service provider name, URL, subscription tier, subscription start date, renewal date, price, etc. In some embodiments, payment information on various merchant systems may be tracked, including type of card, mobile payment service (e.g., Google Pay, Apple Pay), gift payment account information, merchant ID, brand information, billing address, price, taxes, fees, shipping, tips, miscellaneous charges, sub-total cost (before tax and tip), total cost, currency, date of transaction, merchant ID, shipping address, etc. The collected information may be stored in the payment account switcher database 125. As shown in FIG. IB, the systemAttyDktNo.: 66416-702601

[0105] 100 may comprise a subscription manager 123. Unlike conventional methods where subscription information is inferred through transactions, the subscription manager 123 of the system herein may retrieve subscription data directly from the merchant via direct API integration without relying on user transaction data to ensure 100% accuracy of the subscription information. For instance, conventional systems may attempt to identify subscriptions by analyzing historical card transactions, recurring charge patterns, merchant descriptors, and statement narratives, which inherently introduces classification errors, latency, and missing-state conditions. The subscription manager 123 herein may establish authenticated API connections to participating merchant systems to retrieve authoritative subscription records directly from merchant billing engines and entitlement systems.

[0106]

[0088] In some cases, the subscription manager 123 may provide rich subscription data (e.g., tier, billing cycle, exp. date, payment method) through the direct API integration. The direct API integration also beneficially allows for instant subscription cancellation, update and other subscription management. In some embodiments, the subscription manager 123 establishes and maintains secure API integrations with merchant subscription platforms (e.g., billing, entitlement, and account management services) using tokens, short-lived programmatic session credentials, and / or mutually authenticated TLS channels. These integrations allow the subscription manager to retrieve normalized subscription objects that include, for example, subscription identifiers, product SKU identifiers, tier and entitlement metadata, billing cycle definitions, billing anchors, renewal cadence, proration logic, and trial status, pricing components, taxes, discounts, coupons, and promotional entitlements, next charge dates, remaining billing periods, and expiration conditions, payment instrument bindings, including card identifiers, network tokens, and vault references, cancellation policies, pause / resume eligibility, and upgrade / downgrade rules or other metadata. Because the data is obtained directly from merchant subscription ledgers rather than inferred from transactions, the subscription manager provides an authoritative subscription state and eliminates reconciliation delays caused by delayed clearing, missing descriptors, or partial transaction histories.

[0107]

[0089] As illustrated in FIG. 15, the subscription manager 123 may provide GUIs displaying subscription insights such as monthly recurring spend, calendar view, amount paid vs. remaining, future funds needs and the like. The subscription GUI may display categorized spend with spend organized by merchant and category, budget goals and alerts organized by category. The GUI may map all subscriptions by identifying subscriptions from internal spend, external (e.g., via Plaid), or manually added subscriptions with all popular merchants supported. The GUI may also allow users to manage or update their subscriptions via direct API integrationAttyDktNo.: 66416-702601

[0108] (e.g., cancel or take a break, up / downgrade plans, make a one-time payment, change billing date, and the like). The GUI may allow users to change or update their card to external subscriptions on one tap. The GUI may further allow users to create a new account by identifying sign up offers and creating an account in one tap. In some cases, when a user accesses the subscription manager GUI, the backend creates or refreshes a session identifier using a dedicated session creation or session extend endpoint. This session identifier can be used to authorize the backend to query and modify subscription objects at merchant systems. This authentication process can be same as described elsewhere herein. For example, the session identifier references this merchant session and controls all subsequent API calls. Upon establishing a valid session, the subscription manager 123 may retrieve authoritative subscription metadata directly from merchant subscription APIs by attaching the session identifier and scoped access tokens to each API call. Because the session is server-side and persistent, the system may maintain real-time subscription bindings and continuously refresh subscription state without requiring user interaction or browser cookie reuse.

[0109]

[0090] The subscription manager 123 may retrieve subscription data from merchants, process the subscription data to display insights on a GUI for a customer and allow the customer to manage their subscription as well as changing card for the subscription. In some cases, the subscription data may include, for example, name, tier name, status (e.g., active), billing cycle, price, descriptive details, start / expiration date, next renewal date, whether subscription can be canceled / upgraded / paid / free, type of payment method, or payment method. Such rich subscription data may be used by customer to manage subscription (e.g., cancel subscription, upgrade / downgrade / modify subscription plan). In some cases, the subscription data may also be provided to card issuer system or third-party for them to improve their products / marketing.

[0110]

[0091] In some embodiments the Subscription Manager and Transaction Link Module obtain direct subscription metadata via merchant APIs and provide embedded, near-real-time

[0111] SKU-level feeds to authorized partners via the persistent connection controlled by the Connection Manager. Because the engine can refresh session bindings (for example via the Session Manager’s extend / refresh flows) and maintains scoped tokens, it can perform one-click account creation or instant card swaps for subscription services using pre-filled, consented data stored in secure vaults. Direct API integration supplies higher-accuracy subscription state and reduced reconciliation latency compared to heuristics based on transaction sampling. In some embodiments, the subscription manager 123 functions as a subscription control plane that continuously refreshes subscription state using persistent connections and session bindings managed by the Session Manager. Short-lived scoped tokens are refreshed via session-extendAttyDktNo.: 66416-702601

[0112] and token-refresh flows, allowing the engine to maintain active control channels to merchant systems while preserving security boundaries. In some cases, subscription management actions initiated from the GUI — such as cancellation, pause / resume, tier upgrade or downgrade, onetime payments, or instant card swaps — may be cryptographically authorized by the session identifier. A modification request may be evaluated by the session manager to verify the session is active, the request falls within the permitted operation scope, or the user has previously granted consent for that action. By the session manager maintaining active server-side sessions and vaulted consented identity and payment tokens, the subscription manager beneficially allows for one-tap subscription creation, card rebinding, subscription modification, cancelation and instant plan migration without prompting the user for re-authentication. The subscription manager may refresh session bindings as needed using secure token refresh flows, allowing uninterrupted subscription lifecycle control.

[0113]

[0092] The subscription manager 123 may be a unified subscription intelligence layer that normalizes subscription objects from multiple merchant APIs into a unified subscription graph that correlates internal issuer-side transaction streams, external aggregation feeds, manually entered subscriptions and / or merchant-native API records. This correlation allows the system to construct a canonical subscription registry for each user that resolves duplicates, identifies orphaned subscriptions, detects shadow subscriptions not visible in transaction feeds, and flags unused or dormant subscriptions.

[0114]

[0093] In some embodiments, profile information may include a snapshot of the user’s account or profile on the merchant system, the user’s searches and autocompletions of the searches, user history on the merchant system (e.g., watched items, read items, bought items, viewed items, etc.), user contact information, billing and security settings, notifications and reminders settings (e.g., subscribed channels, notifications for new movies or shows, etc.), user generated lists (e.g., watch lists, shopping lists, wish lists, etc.), current cart content, whether the user is associated with a larger organization (e.g., employee account of a company account), etc.

[0115]

[0094] The payment account switcher engine 125 may be connected to and communicate with a payment account switcher database 125. The payment account switcher database 125 may store any and all data that is transferred through the payment account switcher engine 120. For example, the payment account switcher database 125 may include different types of data such as users’ log-in credentials for merchants, credit payment account information, debit payment account information, and bank information. In some embodiments, the credentials may include cookies, headers related to authentication of the user session, session data, any other informationAttyDktNo.: 66416-702601

[0116] that can be used to authenticate a user, etc. Credential and / or financial information may be tokenized, masked, or encrypted before being stored in the payment account switcher database 125. The data may include usage data such as whether the user is using a mobile device, such as a smartphone or a tablet, or a desktop computer. The data may include demographic data of the users such as age, sex / gender, marital status, household structure, income, wealth, education, geographic location, religion, and / or others. The data may include the different merchants with which each user has an account. The data may include the different merchants with which the user has showed interest.

[0117]

[0095] The data collected and stored in the payment account switcher engine 125 may be used as a training dataset for training one or more machine learning algorithms. The machine learning algorithms may be used to predict, for example, the different merchants that a user of a certain demographic may use. Then the payment account switcher interface 115 may present the predicted list of merchants that the user can select to switch their default POF. As an example, the machine learning algorithm trained model may generate a list of merchants taking as input the user’s geolocation, age, or other demographic information and output a personalized list of merchants that the user is likely to have accounts with. In some cases, the list of merchants may be ranked based on popularity of the merchants, relevance determined based at least in part on a characteristic of the user (e.g., age, geographic location, etc.). In some cases, performance of the model (e.g., prediction accuracy) may be improved by using the user’s inputs as feedback to improve the model. For example, the difference between the model predicted list of merchants and the user’s selected merchants may be used to further train the model.

[0118]

[0096] In some embodiments, a machine learning algorithm may be trained to predict what type of user will utilize the payment account switcher. For example, depending on the demographic of the user, the machine learning algorithm may predict that certain people of a certain age would more likely use the payment account switcher than someone of a different age. Then, a bank or a financial institution that has a higher population of a certain demographic (e.g., more customers with a certain age range) may implement the payment account switcher into their issuer system 110.

[0119]

[0097] In some embodiments, the payment account switcher engine 120 may include an authorization module 122 and a card switching module 124. The authorization module 122 may be used to authenticate the user’s identity as described here. The card switching module 124 may be used to perform the operations for switching the default POF on the merchant system 130. Although two modules are shown and described herein, the payment account switcher engineAttyDktNo.: 66416-702601

[0120] 120 may include more modules or each of the described modules may include sub-modules that perform various operations within the scope of this disclosure.

[0121]

[0098] In some embodiments, the interconnection between the payment account switcher engine 120 (and the authorization module 122, switching module 124, monitoring module 126, and transaction link module 128, for example) may be automated to access the merchant systems. In some embodiments, the interconnection may replace the net stack of several different environments with a single easily modified and maintained one for consistency and stability. In some embodiments, the interconnection may normalize outgoing traffic making it indistinguishable from traffic from regular users (by deploying stealth and proxy routing). In some embodiments, the interconnection may centralize any egress to allow the payment account switcher engine 120 to monitor, store and analyze any and all outgoing traffic. In some embodiments, the interconnection may automatically strip sensitive information from said traffic when stored without compromising on the details that matter for debugging integrations.

[0122] Initialization of a New User

[0123]

[0099] In some embodiments, the method further comprises, prior to receiving the request to change the default POF, providing the user, via the issuer system, a payment account switcher interface to enter a set of information related to the account associated with the user. This information may be provided to the payment account switcher engine (e.g., the authorization module) to initialize a new user for the payment account switcher. Once an indication that a new user account is to be created, the payment account switcher engine may generate a new user account for the user.

[0124]

[0100] In some embodiments, the method further comprises, prior to receiving the request to change the default POF, providing the issuer system a software development kit (SDK) to customize or create the payment account switcher interface that is shown to the user. In some embodiments, developers for the issuer system may use the SDK to initialize a card issuer interface that would be hosted on the issuer system and the issuer’s application or webpage. In some embodiments, the SDK may include one or more commands that may enable the payment account switcher interface to work seamlessly with the payment account switcher engine.

[0125]

[0101] In some embodiments, the method further comprises providing the user, via the payment account switcher interface, a list of merchants that the user can select 2203. In some embodiments, the list of merchants is determined based at least in part on popularity of the merchants, relevance determined based at least in part on a characteristic of the user (e.g., age,AttyDktNo.: 66416-702601

[0126] geographic location, etc.), and / or a list prepared by the issuer system 2201. In some embodiments, the user may provide a list of merchants that the user has an account for.

[0127]

[0102] In some embodiments, the method further comprises, prior to receiving the request to change the default POF, receiving an indication that the user has the account with a merchant associated with the merchant system. In some embodiments, the method further comprises transmitting instructions to the issuer system to display an image, text, or other indication that the user has the account with the merchant.

[0128] Authentication of a User

[0129]

[0103] In some embodiments, one or more methods may be used to authenticate a user to access the merchant system. The authentication may be performed before the card switching is performed. A plurality of methods may be deployed by the authorization module 122 to authorize the user’s identity for the merchant system. Although certain methods are described with respect to authorizing the users, embodiments are not limited thereto and the described methods may be modified within the scope of the disclosure.

[0130]

[0104] In some embodiments, in each of the methods of authorization the user’s identity, any received input (e.g., log-in information, credential information, other data) may be received and stored within the user’s device, the issuer system, and / or the payment account switcher engine or database. In some embodiments, the input may be stored so that the payment account switcher engine may automatically log-in the user the next time the user wants to switch the default POF.

[0131]

[0105] In some embodiments, the method may include receiving, from the user, credentials for authenticating the user’s account on the merchant system. In some embodiments, after the user has selected the merchant, the user may input the user’s credentials onto the payment account switcher interface 115. The user’s credentials may be provided via a log-in ID and password combination, single sign-on (SSO), or face identification options. In some embodiments, a user agent can be used for enabling the SSO feature. Depending on embodiments, the user may also include multi-factor authentication (MFA) for logging into the merchant system for added security. In some embodiments, the method may include transmitting, to the merchant system, the credentials to authenticate the user’s credentials.

[0132] Authorizing for mobile device using merchant webview

[0133]

[0106] In some embodiments, when the user is using a mobile device or a computer, the method further comprises, prior to receiving the request to change the default POF, generating a merchant webview of a login page associated with the merchant. In some embodiments, theAttyDktNo.: 66416-702601

[0134] webview may include the merchant’s web page that is shown directly within the payment account switcher interface, and the merchant webview may be similar to or the same as the login page of the merchant’s webpage that would be displayed on the web browser. In some embodiments, the merchant webview may be generated by the payment account switcher interface. In some embodiments, the merchant webview is a custom log-in page associated with the merchant. In some embodiments, the method may further comprise transmitting instructions to the issuer system to display the merchant webview to receive log-in information from the user. Afterward, the user may provide the user’s credentials for the merchant system via one of several methods, e.g., merchant user ID / password, SSO, face ID, etc. In some embodiments, the issuer system 110 may communicate with the merchant system using one or more cookies, session tokens, etc. which can be serialized and transmitted via the payment account switcher engine 120.

[0135]

[0107] In some embodiments, the method further comprises, after transmitting the instructions to display the merchant webview, monitoring the merchant webview for changes in cookies and / or uniform resource locators (URLs) to determine when the user is authenticated. In some embodiments, the payment account switcher engine may include instructions (e.g., via Javascript) into the webview to detect the log-in. In some embodiments, the method further comprises, during the monitoring, detecting that the user has successfully logged in to the account for the merchant. In some embodiments, the payment account switcher engine may detect that that the credentials provided by the user was successful in logging into the merchant system. After the authentication is completed, the payment account switcher engine may provide cookies, code headers, and other information from the webview to the database.

[0136] Authorizing for mobile device using overlaid log-in page

[0137]

[0108] In some embodiments, when the user is using a mobile device or a computer, the method comprises, prior to receiving the request to change the default POF, generating a merchant webview of a log-in page associated with the merchant, wherein the merchant webview is a custom log-in page associated with the merchant. In some embodiments, the method further comprises, after generating the merchant webview, transmitting instructions to the issuer system to: generate a log-in page or screen that is overlaid over the merchant webview. In some embodiments, the log-in page may include a custom log-in screen that is generated by the payment account switcher engine, and the payment account switcher engine may receive the information from the payment account switcher interface and communicate with the merchant system. In some embodiments, the merchant webpage may be running in the background (e.g.,AttyDktNo.: 66416-702601

[0138] not presented to the user) and be in communication with the payment account switcher engine. Any credentials that are provided to the log-in page may be provided to the payment account switcher database to store the user credentials for future authorization.

[0139]

[0109] In some embodiments, the method further comprises transmitting instructions to the issuer system to receive the credentials of the user via the log-in page, transfer the credentials to the merchant system via the merchant webview, and submit the credentials to the merchant system. In some embodiments, the merchant system may return a notification that the log-in attempt was successful if the user’s credentials are valid. In some embodiments, the merchant system may return a notification that the log-in attempt was unsuccessful if the user’s credentials are invalid. In some embodiments, when there is an error in logging into the merchant webpage using the credentials provided by the user, the payment account switcher engine may detect from the merchant webpage running in the background (via cookies, URL, webhooks, etc.) that the log-in attempt was not successful. In some embodiments, the user may be notified via the payment account switcher interface (e.g., on the login page) that the log-in attempt was unsuccessful.

[0140] [HO] In some embodiments, the method further comprises, after submitting the credentials to the merchant system, monitoring authentication of the credentials and providing any error messages, captchas, one-time password (OTP) requests, etc. to the user via the payment account switcher interface. In some embodiments, the method further comprises, after providing any error messages, captchas, OTP requests, etc. to the user, receiving a response from the user and transmitting the response to the merchant webview. Accordingly, if the merchant system has deployed additional security measures, the payment account switcher engine can provide the additional user input to the merchant system for a successful log-in.

[0141] Authorizing for computer using reverse proxy

[0142] [Hl] In some embodiments, when the user is using a desktop or laptop computer, authenticating the user’s credentials comprises: using a hypertext transfer protocol (HTTP) reverse proxy that shows a merchant webpage to the user on a domain that is different from a merchant domain associated with the merchant; and providing one or more requests received from the user to the merchant domain based on one or more requests on the merchant webpage on the different domain. In some embodiments, the reverse proxy server may be included in the payment account switcher engine. In some embodiments, a reverse proxy server may be situation or disposed adjacent to the merchant webpage and can intercept incoming requests from the issuer system and / or the payment account switcher engine. The reverse proxy may provide theAttyDktNo.: 66416-702601

[0143] data and / or instructions to the merchant webpage, which can then return results to the reverse proxy that may be transmitted back to the issuer system and / or the payment account switcher engine. In some embodiments, the reverse proxy may have the look and feel of the merchant system’s log-in page and be able to enable communication between the issuer system and the merchant system (via cookies, session tokens, etc.). In some embodiments, the reverse proxy may provide the information to the payment account switcher engine and provide any communicated information and / or data to the payment account switcher database.

[0144]

[0112] In some embodiments, the domain on which the merchant webpage is shown may be a domain that is reserved by the payment account switcher engine. The domain reserved by the payment account switcher engine may also be referred to as “payment account switcher domain.” In some embodiments, even though the domain is different from the one being used by the merchant system, the merchant webpage shown may be the same or similar to the merchant webpage that would be displayed if on the domain of the merchant system. In some embodiments, any information that is provided to the merchant webpage on the payment account switcher domain may be provided to the merchant webpage on the merchant domain. And any responses by the merchant webpage on the merchant domain may be transferred and shown on the merchant webpage of the payment account switcher domain. In some embodiments, the system may monitor any changes in the cookies or URLs of the merchant webpage, or responses to authentication related endpoints on the merchant domain to determine whether the user’s credentials were successfully or unsuccessfully authenticated by the merchant system.

[0145]

[0113] In some embodiments, the method further comprises using an HTTP forward proxy between the issuer system and the merchant system to control data that is sent to the merchant system. In some embodiments, the payment account switcher engine may provide any data that is provided to the payment account switcher interface to the payment account switcher database. In some embodiments, the provided data may be useful for future updates to the payment account switcher engine and in improving the quality of the log-in experience for the user.

[0146] Authorizing for computer using remote browser

[0147]

[0114] In some embodiments, authenticating the user’s credentials comprises, when the user is using a desktop or laptop computer: hosting a remote browser on a processor other than the desktop or laptop computer used by the user, wherein the remote browser has a URL set to a merchant webpage. In some embodiments, the remote browser may be run on a container in a virtual computer or server that is different from the device or computer that the user is using. In some embodiments, the user may provide the log-in information so that the merchant systemAttyDktNo.: 66416-702601

[0148] may authenticate the user’s identity. In some embodiments, the method further comprises streaming the merchant webpage to the desktop or laptop computer used by the user for authenticating the credentials. In some embodiments, the payment account switcher interface may show the user the merchant webpage via a window that shows the remote browser running on the virtual or remote server. Accordingly, even though the user is able to see a web browser with the merchant URL, the browser may be running on a virtual or remote server that is being hosted by a payment account switcher engine. Accordingly, the payment account switcher engine may monitor the data that is being provided by the user.

[0149] Switching the Default Payment-Account-On-File

[0150]

[0115] In some embodiments, the system 100 may be used to implement a computer-implemented method for changing a default POF for a user on a merchant system. The method may include receiving, from an issuer system (e.g., issuer system 110), a request to change the default POF on an account associated with the user on the merchant system (e.g., merchant system 130), wherein the issuer system is configured to manage a card that the user selects to use for the merchant system. In some embodiments, the request may be made via a payment account switcher interface (e.g., payment account switcher interface 115) that is presented to the user on a website or application of the issuer system. The payment account switcher interface may provide a list of merchants that the user may select. The user’s selection may indicate that the user selects to change the default POF for the selected merchant.

[0151]

[0116] In some embodiments, the methods described herein may be performed using application programming interface (API), webhooks, and / or other instructions via, e.g., Javascript. For example, one or more interactions among the issuer system, the payment account switcher interface, the payment account switcher engine, the payment account switcher database, and the merchant systems 130 may be performed using one or more programming instructions. In some embodiments, the webhooks are configured to monitor for one or more events including the user access or opening the merchant on the payment account switcher interface, authenticating the user credentials for the merchant system, updating the card on the merchant system, or completion of changing the default POF to the card. In some embodiments, the method may further comprise, during receiving the credentials, receiving from the user cookies, an access token, session data, JSON web tokens, etc. through the payment account switcher interface.

[0152]

[0117] FIG. 2 shows a workflow diagram of the process of switching the default POF, in accordance with some embodiments. The workflow diagram shows the user, the payment account switcher engine, the issuer system, and the merchant system. Although certain entitiesAttyDktNo.: 66416-702601

[0153] and steps are shown, embodiments are not limited thereto, and additional entities and / or steps may be added or some entities and / or steps may be removed from the workflow diagram.

[0154]

[0118] In some embodiments, the process may begin with the user being authenticated within the issuer system. In some embodiments, the user may log into the issuer system’s application or webpage. In some embodiments, when the user logs in successfully to the issuer system, the user may be able to view the user’s account(s) that the user has with that particular issuer. In some embodiments, the user may select a credit card or account.

[0155]

[0119] In some embodiments, after the user has selected the credit card or account, the issuer system may create a user account or a session (202). In some embodiments, the issuer system may create a user account for the user if the user has not used the payment account switcher interface before. After the user account is created, the issuer system may create a session and a corresponding session ID for the session. In some embodiments, the session may include any instance when the user logs into the user’s account on the issuer system’s user interface. In some embodiments, if the user ID already exists (e.g., when the user has used the card switch before), the issuer system may create a new session and the corresponding session ID. After the user account (and user ID) and / or the session (and session ID) have been created, an indication may be sent to the payment account switcher engine that a new user account and / or a new session have been created. In some embodiments, the user ID and / or the session ID may be provided to payment account switcher engine.

[0156]

[0120] The process may continue with a user indicating that the user selects to change the default POF by clicking on an option (e.g., a tile) on the user interface (203). Upon receipt of the user’s indication by the payment account switcher engine, the payment account switcher engine request the session ID from the issuer system (204), if the payment account switcher engine does not already have the session ID. The session ID may be used to initialize the payment account switcher interface within the user interface of the issuer system (206).

[0157]

[0121] After the user interface has been created, the user may identify or select one or more wallets and / or merchants on which wallet system or merchant system the user selects to change the default POF. After the user selects the one or more wallets or merchants, a merchant system log-in page may be opened and displayed (208). In some embodiments, the user may have previously provided the appropriate credentials to the payment account switcher engine which had been stored (e.g., in the payment account switcher database or the user’s device). In this case, the log-in screen may not be shown or the user’s credentials may already be prepopulated in the appropriate fields so that the user may click submit to submit their credentials.AttyDktNo.: 66416-702601

[0158]

[0122] The process may continue with the user’s identity being authenticated with the merchant by providing those credentials to the merchant system (212). In some embodiments, the merchant system may authenticate the user’s identity and provide a signal or a notification that the authorization has been successful to the payment account switcher engine (214). In some embodiments, if the provided credentials are incorrect, the merchant system may provide a signal or notification indicating that the credentials did not work. Once the payment account switcher engine receives the signal or notification, the user may be notified via the payment account switcher interface (216). In some embodiments, the receiving, from the merchant system, an indication that the user’s credentials for the user’s account have been authenticated for the merchant system. If the user’s identity is authenticated, the process will continue with updating the default POF within the merchant system. However, if the user’s identity is not authenticated, the user may be directed to the log-in screen for the merchant system again, and the user may be provided the option to enter the correct credentials, and the steps of 212-216 may be repeated until the user provides the correct credentials.

[0159]

[0123] In some embodiments, the process may further comprise transmitting instructions to the merchant system to change the default POF for the user’s account to the card that the user selects to use for the merchant system. In some embodiments, changing the default POF includes changing from a first card to a second card on the merchant system for future transactions made by the user. In some embodiments, transmitting instructions to the merchant system to change the default POF comprises transmitting an API call to the one or more endpoints associated with the merchant system to perform the change. In some embodiments, transmitting the API call comprises transmitting payment account information related to the payment account to the merchant system. In some embodiments, the payment account information includes a card number, an expiration date, and a verification code (e.g., CVV). In some embodiments, a billing zip code, a card holder’s name, and other required information may be provided.

[0160]

[0124] In some embodiments, the payment account information is contained within a token. In some embodiments, the account information may be tokenized before being transmitted to and from the issuer system. For example, the payment account information may be converted to a string of characters which may include a token. In some embodiments, the merchant system that receives the token may correlate the token with data within the payment account switcher engine and / or payment account switcher database.

[0161]

[0125] The process may continue by automatically initiating the switching or updating the default POF (218). The payment account switcher engine may receive the user’s paymentAttyDktNo.: 66416-702601

[0162] account information from the issuer system, since the user has already authenticated their identity within the issuer system. In some embodiments, the issuer system may provide, to the payment account switcher engine, account information including the card / account holder’s name, card or account number, expiration date (if any), the card verification value (CVV) (if any), and / or billing address including zip code. The payment account switcher engine may then provide the information to the merchant system. The process may continue with the merchant system updating the default POF to the received new card or account. In some cases, the process may be initiated by a user logging into an account or a place that stores all passwords associated with a user, and once log in, the user may be allowed to switch the default POF on all or selected merchant accounts.

[0163]

[0126] In some embodiments, changing or switching the default POF in the merchant system may be performed via one of a plurality of methods. For example, the payment account switcher engine can implement an API provided by the merchant system. In some embodiments, the payment account switcher engine may submit the payment account information directly to the merchant system via the API endpoints that are provided, maintained, and documented by the merchant system.

[0164]

[0127] In some embodiments, transmitting instructions to the merchant system to change the default POF includes instantiating a web browser and simulating a direct interaction with the merchant client on the web browser. In some embodiments, switching the default POF may be performed by the payment account switcher engine by instantiating a browser and simulating a direct interaction with the merchant client. In some embodiments, the interaction may be performed via a user interface and browser automation tools to fill and submit forms on the merchant websites by querying the, e.g., HTML DOM and populating the form fields. In some embodiments, a form submission to submit the form fields may be triggered via a simulated mouse click.

[0165]

[0128] In some embodiments, transmitting instructions to the merchant system to change the default POF includes monitoring data traffic to and from the merchant system and simulating manually changing the default POF. In some embodiments, switching the default POF may be performed emulating the manual steps that a user would perform to log into the merchant system. In some embodiments, the payment account switcher engine can simulate the traffic that the merchant system would have made while switching a card manually. In some embodiments, the payment account switcher engine may emulate the steps via API provided by the merchant system and automate user interactions with the merchant system. In some embodiments, theAttyDktNo.: 66416-702601

[0166] payment account switcher engine may perform this switching if, for example, switching via the API endpoints or the browser simulation is not available.

[0167]

[0129] In some embodiments, the traffic can be simulated via a web browser as discussed above or an app client that is running the payment account switcher engine or at least connected to the engine. This method may differ from the original "browser method" in the way that in some embodiments, these browsers are served to the end user through a visual and interactive stream, offering real time feedback and control, and hosted in secure contexts and / or containers. An isolated (process separated) browser contexts and / or secure containers (OS / host isolation) that are hosted on isolated servers (separation from user network) may be deployed. This adds a security benefit as the containers / contexts are isolated from the user environment and network. In some embodiments, a remote browser can be a security benefit as it is isolated from the user environment and network, and requests to and from the merchant are only made through secure servers. In some embodiments, even though third party software may be used for orchestration of container deployment, some or all containers may be instantiated and orchestrated through the payment account switcher engine 120 and the images that run on them may be run by the payment account switcher engine 120 (and since they are open source there is no issue auditing them), and the hardware the orchestration software runs on may be performed by the organization that runs the payment account switcher engine 120. Furthermore, in some embodiments, customers may be served unique, secure, and isolated containers, which are destroyed and never shared among other customers. Any point of vulnerability in security may need to go through multiple layers of virtualization and multiple hardware nodes. Accordingly, the browsers may be safe to use for the payment account switching.

[0168]

[0130] In some embodiments, a distinction between using a web browser and an app client may lie in what is generating the request that gets sent over the network.

[0169]

[0131] However, when the app method is used, a merchant may not be able to distinguish whether a browser or an app is accessing its system. In some embodiments, the payment account switcher engine may obtain and use the data for accessing a merchant system and generate requests that are sent to the merchant system, whereas the web browser method may include an intermediate layer of a browser that is actually the software in charge of making and transmitting these requests which may be fed the user information.

[0170]

[0132] In some embodiments, a core difference may lie in how the traffic is synthesized in this case. Whether using a web browser or an app, data traffic may still be generated and transmitted. In some embodiments, a POST request containing JSON to an API endpoint using standardAttyDktNo.: 66416-702601

[0171] REST API can be used. However, in some embodiments, an RPC (remote procedure call like gRPC, Apache Thrift) can be used as well which may not be an HTTP request per se.

[0172] Furthermore, a POST with content type “application / x-www-form-urlencoded” can be sent which is how a browser would send the contents of a HTML form. However, that HTTP request is still a HTTP request, and can be generated by things other than a browser so long the content within it is encoded properly (e.g., url-encoded). Despite it still being a HTTP request though, this is likely not an API in the REST API sense but it's still traffic and thus can still be simulated. A similar method can be used for HTTP requests but with a content-type “multipart / form-data.”

[0173]

[0133] In some embodiments, the payment account information may be securely stored in the payment account switcher database or a different secure vault hosted by a vault provider. In some embodiments, the vault provider may be responsible for storing the payment account information securely and forwarding the payment account information in a tokenized manner to the payment account switcher engine. In some embodiments, the payment account information may be transmitted from the issuer system to the payment account switcher engine and / or the merchant system via a JSON Web Encryption (JWE) encrypted payload.

[0174]

[0134] In some embodiments, the merchant system may accept the payment account information directly. For example, the payment account information may get decrypted and sent directly to the merchant system, and no third party (e.g., payment processor) is party to the transaction.

[0175]

[0135] In some embodiments, the merchant system may indirectly accept the payment account information, for example, via a payment processor. For example, the card instrument gets decrypted and sent to the payment processor of choice from the merchant system. Then, the payment processor may return a tokenized representation of the payment instrument which the merchant system expects to receive via the merchant APIs. In some embodiments, the payment account switcher engine may use the payment processor’s APIs to provide the payment account information.

[0176]

[0136] In some embodiments, the system may be used to update the user’s payment account information in more than one merchant system at a time. For example, if the user has provided access to a plurality of user’s merchant accounts, the system may be used to access and change all or a subset of all of the payment account information in the user’s account in the merchant systems. The user may be provided the option to switch the payment account for all of the users’ accounts or a list of accounts where the user can select to change.

[0177]

[0137] After the default POF has been updated, a notification may be sent to the payment account switcher engine (220), and the user may be notified via the payment account switcherAttyDktNo.: 66416-702601

[0178] interface (222). In some embodiments, additional notifications may be sent to the user via email, text, phone call, mail, etc. Accordingly, the updated (or new) card that is now on file with the merchant system may be used to perform transactions with the merchant.

[0179]

[0138] In some embodiments, the user may use the system to automatically update the user’s payment account information on the merchant system. For example, if the user’s credit card on file is stolen, damaged, or lost, the issuer system via the engine may provide any updated information such as a new card number, expiration date, CVV number, etc. to the merchant system so that the user may seamlessly continue to access the products or services provided by the merchant system. Furthermore, the system may automatically update any user information such as address changes or name changes.

[0180]

[0139] In some embodiments, the payment account switcher engine may operate as a middleware layer that connects a user of a payment account to one or more merchant systems. This enables the user to initiate a new transaction or to modify payment information during an ongoing transaction with the merchant system in a seamless manner. The payment account switcher engine operates as a privacy-first, security-hardened middleware layer that intermediates between a user’s payment instrument (for example an instrument managed by an issuer, wallet provider, licensed money transmitter, bank application, or payment service provider (PSP)) and one or more merchant systems. The payment account may be provided by any digital payments solution, a licensed money transmitter, a wallet provider, a bank application or a payment service provider (PSP). It should be noted that though PSP is described in the following application, the methods herein are not limited to the PSP system and can be applied to any other applications. The workflow may allow the user to add a new payment instrument or switch the default payment option on file (POF) for the merchant system simply by authenticating with the merchant account, without requiring the user to re-enter or resubmit sensitive payment credentials. Unlike conventional account-update systems that require repeated manual credential entry or propagate sensitive PAN / CVV values across multiple merchant endpoints, the disclosed switcher engine provides session-bound tokenized payment contexts, activity-gated session extension, cryptographically signed authorization attestations, and merchant-specific execution orchestration, forming a secure intermediary computation layer that improves privacy, reliability, and network efficiency. The engine maintains encrypted session artifacts including session identifiers, access token references, refresh token identifiers, operation nonces, and device fingerprints in AES-256 encrypted session records protected by HSM / KMS-managed keys, and cryptographically binds these records to user intent using issuer-signed or PSP-signed attestations. These bindings prevent replay, substitution, and unattended sessionAttyDktNo.: 66416-702601

[0181] abuse. This architecture produces concrete technical improvements, including elimination of repeated full re-authentication flows, reduction of failed recurring transactions, minimization of sensitive credential propagation, reduction of network chatter by replacing credential re-entry with session-bound context reuse, and improved auditability via deterministic job orchestration and signed context payloads.

[0182]

[0140] In some embodiments, the payment account switcher engine may comprise a front end or a user-facing software layer configured for collecting user intent, displaying merchant lists and connection health, proxying merchant challenge interactions (for example OTP or CAPTCHA), and signaling user activity to the backend so that persistent sessions may be refreshed only while the user is active. In some cases, the front end may be deployed as one or more of: (a) a native mobile SDK (iOS, Android) embeddable into an issuer or PSP application, (b) a web SDK delivered as a sandboxed script or ifirame, (c) an embedded webview component that renders merchant login surfaces, (d) a standalone issuer web page and various other forms. As described elsewhere herein, the front end may comprise a UI / UX module that renders ranked merchant lists and per-merchant capability metadata to reduce decision latency. The front end may comprise a session client / activity detector that emits onEvent callbacks (for example sdk active true / false and last activity timestamps) used by the backend session manager to decide whether to attempt session-extend operations. The SDK establishes a hardware- and OS-enforced trust boundary around merchant authentication flows while preventing leakage of credentials into logs, caches, or unauthorized third-party scripts. These features improve security and system reliability by reducing keystroke-level credential exposure, preventing cross-merchant cookie leakage, gating background session extension strictly to periods of observed user activity, and preventing unattended credential refresh.

[0183]

[0141] In some embodiments, the payment account switcher engine may comprise a backend implemented as a set of modular services (for example microservices). The backend components may comprise a session manager that enforces activity-gated session extension and expiry, a persistent link controller for long-lived merchant connections, a tokenization and vault adapter for secure token storage and resolution, a merchant connector layer including API adapters, web automation, and app-traffic emulation, browser container orchestration for ephemeral browser sandboxes, an idempotency and job orchestrator for deterministic retries and audit trails, an audit ledger for signed event recording, and HSMZKMS integration for hardware-anchored secret custody. These modules cooperate to perform deterministic merchant-specific execution plans, replacing brittle one-off scraping approaches with formally orchestrated update workflows.AttyDktNo.: 66416-702601

[0184]

[0142] FIG. 22 shows an example workflow diagram of the process of setting or switching the default POF with one or more selected merchant systems, in accordance with some embodiments. The workflow diagram shows the user, the payment account switcher engine, the payment service provider system, and the merchant system. In some cases, the payment account switcher engine may include both a front-end (e.g., user-facing graphical interface, API client) and a back-end (e.g., secure services, databases, tokenization modules). Although FIG. 22 illustrates a specific configuration, embodiments are not limited thereto; additional entities, interfaces, and / or steps may be added, or some removed, depending on implementation.

[0185]

[0143] The process may begin with an initialization flow 2200, as shown in FIG. 22. This initialization is structurally similar to the processes described in FIG. 2, except that the issuer system is replaced by a PSP system. In some cases, the process is triggered through a graphical interface provided by the payment account switcher engine front end. This interface may be available via a standalone application, a software development kit (SDK) embedded within the PSP system’s mobile or web application, or through an integrated API connection with the PSP. FIG. 23 A illustrates an exemplary GUI for the user to select one or more merchants for switching or setting up a POF through the PSP system.

[0186]

[0144] In some cases, the initialization flow begins with the payment account switcher engine backend receiving a request from the PSP system for a merchant list (2201). The request may be transmitted via an API call (e.g., HTTPS RESTful request secured with OAuth2.0 or mutual TLS or any other suitable authentication / authorization mechanism). In response, the switcher engine backend generates and transmits a merchant list (2202). The merchant list may be dynamically generated using predictive algorithms, such as a machine learning model trained on user demographic attributes (e.g., age, geolocation, spending categories) and historical merchant linkage data. For example, a collaborative filtering model may identify merchants that users with similar profiles are likely to have accounts with, and a ranking algorithm may order results by popularity, transaction frequency, or relevance. The list may be cached locally on the user device or stored in a cloud-hosted database accessible by the switcher engine backend. As shown in GUI views 2300 and 2301, the merchant list may be displayed to the user (2203) for selection. If a merchant is added, the interface may provide visual indicators such as a highlighted tile 2309 or a pop-up confirmation 2302.

[0187]

[0145] The process may continue with a user indicating that the user selects to change the default POF by clicking on an option (e.g., a tile) on the user interface. Upon receipt of the user’s indication by the payment account switcher engine, the payment account switcher engineAttyDktNo.: 66416-702601

[0188] backend may request a session ID from the PSP system (2206). If a session already exists, the existing session ID may be reused. The session ID serves as a secure identifier to initialize a context within the PSP’s user interface (2207). The merchant identifier and session ID are passed to the payment account switcher front end, which presents a login or authentication interface for the selected merchant. The session ID may be used to initialize the payment account switcher interface within the user interface of the PSP system (2207).

[0189]

[0146] A session identifier uniquely represents an authenticated session context for the user and merchant interaction. Sessions may be initiated via a dedicated session creation API such as POST / session / create, which returns a session identifier that is initially valid for a limited duration (e.g., 30 minutes) and securely bound to an external user identifier and specified product type, such as card switcher in the context of card switching operations. The session identifier is used to initialize the session context in the PSP user interface (2207) and is passed to the switcher front end along with the merchant identifier. The session identifier may be stored in secure ephemeral storage within the front end and used as a token for authenticating subsequent session operations.

[0190]

[0147] These mechanisms allow the front end to render a login or authentication interface that is bound to the specific session identifier and merchant context, preventing session fixation or unauthorized reuse. Unlike other methods or systems that may reuse merchant-issued browser session cookies belonging to the user, the session identifiers herein may be server-side programmatic sessions issued to the backend engine and not browser cookies issued to the user’s webview. Unlike conventional methods relying on the user’s browser to log in to the merchant, and an SDK forwarding tokens, the session ID may be managed entirely by the engine or the backend and initialized within the sandboxed webview for front-end flows. This unique authentication process beneficially allows the front end to render a login or authentication interface that is bound to the specific session identifier and merchant context, preventing session fixation or unauthorized reuse.

[0191]

[0148] The session ID and the user selected merchant (e.g., merchant identifier) may be transmitted to the payment account switcher front end to complete the initialization flow. The payment account switcher front end may provide a user interface for the user to authenticate with the merchant system. The authentication flow or login flow 2208 can be similar to those described in FIG. 2. For example, the front end renders a merchant login page within a webview (2209). The merchant webview may be generated using standardized API integrationAttyDktNo.: 66416-702601

[0192] mechanisms. For example, the authentication can be performed using the webview and session cookies or token as described elsewhere herein.

[0193]

[0149] In some cases, authentication may be performed through a combination of cookies, API tokens, or session tokens that the merchant system issues upon successful authentication. In some embodiments, the webview uses session cookies or tokens provided by the merchant system to manage the authenticated session state within the browser context. The switcher engine itself manages only the session identifier and does not store or log the user’s raw credentials, thereby preserving privacy. The cookies and tokens received from the merchant system during authentication are confined to the front-end webview sandbox, isolated from backend storage and only retained for the duration of the authenticated session. The backend maintains the session ID, while the front-end webview uses it to initialize the session context for the user interface. This structure reduces credential exposure by preventing raw passwords or other highly sensitive data from propagating to the switcher backend.

[0194]

[0150] In some embodiments, successful login creates or refreshes a session within the PSP system (2205), and the PSP system may establish a new user account or bind the session ID to an existing user ID. The switcher engine’s session manager persistently stores encrypted session objects and performs conditional session extension based on observed user activity, thereby avoiding indefinite or unattended sessions. Each session object may contain fields such as session id, merchant id, a reference to an access token, expiration metadata, an sdk active activity flag, and a last activity timestamp. Background workers evaluate session expiration and extend sessions only when the session is nearing expiry and the sdk active flag reflects recent user interaction. Session extension is performed by invoking an authenticated session extension endpoint, such as POST / session / extend, with the session identifier as input. This endpoint call uses HTTP basic authentication with a base64-encoded client identifier and secret to authorize the session extend operation. Upon a successful response, the session duration is extended for an incremental period (e.g., another 30 minutes) while the session remains active in the front end. Secrets used for these calls are retrieved transiently from a hardware security module (HSM) or cloud key management service (KMS), and are rotated and purged immediately after use to reduce the risk of leakage. The conditional session refresh model prevents zombie sessions that never expire, reduces redundant re-authentication prompts, and ensures that refresh operations occur only when there is explicit front-end activity, which improve over systems that either never refresh sessions or refresh them unattended.AttyDktNo.: 66416-702601

[0195]

[0151] In some cases, strong authentication methods (e.g., multi-factor authentication, biometric verification) may be employed to ensure compliance with Know-Your-Customer (KYC) and Payment Card Industry Data Security Standards (PCI DSS). Once the session is validated, the PSP system notifies the switcher engine, which continues the workflow. In some embodiments, after the user has selected the credit card or account, the PSP system may create a user account or a session (2205). In some embodiments, the PSP system may create a user account for the user if the user has not used the payment account switcher interface before. After the user account is created, the PSP system may create a session and a corresponding session ID for the session. In some embodiments, the session may include any instance when the user logs into the user’s account on the PSP system’s user interface. In some embodiments, if the user ID already exists (e.g., when the user has used the card switch before), the PSP system may create a new session and the corresponding session ID. After the user account (and user ID) and / or the session (and session ID) have been created, an indication may be sent to the payment account switcher engine that a new user account and / or a new session have been created. In some embodiments, the user ID and / or the session ID may be provided to payment account switcher engine.

[0196]

[0152] The process may continue with the user’s identity being authenticated with the merchant by providing those credentials to the merchant system (2210) through the login flow and / or login method (2208, 2303-2305) as shown in FIGs. 22 and 23B. In some embodiments, the merchant system may authenticate the user’s identity and provide a signal or a notification that the authorization has been successful to the payment account switcher engine (2305). In some cases, the signal and / or notification that the authorization has been successful may be provided by the merchant system to the payment account switcher engine backend 2211. In some cases, in response to the signal and / or notification that the authorization has been successful the payment account switcher engine backend may provide an authentication indicator (e.g., a webhook) to the PSP system 2212. In some embodiments, if the provided credentials are incorrect, the merchant system may provide a signal or notification indicating that the credentials did not work. Once the payment account switcher engine receives the signal or notification, the user may be notified via the payment account switcher interface 2306. In some embodiments, the payment account switcher engine backend may receive, from the merchant system, an indication that the user’s credentials for the user’s account have been authenticated for the merchant system 2211. If the user’s identity is authenticated, the process may continue with updating the default POF within the merchant system. However, if the user’s identity is not authenticated, the user may be directed to the log-in screen for the merchant system again, and the user may be provided the option to enter the correct credentials, and the steps of (2209-2212) may be repeated until theAttyDktNo.: 66416-702601

[0197] user provides the correct credentials. This ensures that no payment information update proceeds until identity verification is completed. By managing session tokens and cookies at the front-end and isolating credential handling within the sandboxed webview or SDK, the system provides a tangible technical benefit of reduced credential exposure and enhanced privacy compared to conventional systems that store or transmit user credentials across multiple backend services. Unlike conventional token-based session forwarding, which relies on forwarding merchant-issued browser cookies, the authentication method herein allows the backend to manage authentication on behalf of the user, creating server-side programmatic sessions rather than reusing the user’s browser session.

[0198]

[0153] In some embodiments, the process may further comprise transmitting instructions to the merchant system to change the default POF for the user’s account to the card that the user selects to use for the merchant system via the payment context approval flow and / or method 2213 as shown in FIGs. 22 and 23C. In some embodiments, the process may comprise a payment context approval flow 2213. The payment account switcher engine backend may create a payment context 2214 and transmit the payment context to the merchant system. The payment context approval flow 2213 enables the creation and secure transmission of a payment context 2214, which is a cryptographically protected temporary object that encapsulates metadata describing the payment instrument, associated user account, merchant identifier, authorization status, and validity constraints such as a time-to-live (TTL) parameter. The payment context is structured to allow the merchant system to update the default POF without exposing sensitive cardholder data, such as the primary account number (PAN) or card verification value (CVV). In some embodiments, the payment context may be generated by a payment processor, such as Braintree or a similar processor, using authenticated API credentials. Mutual authentication between the merchant system and the payment processor ensures that only authorized merchants can request, receive, or validate a payment context. .

[0199]

[0154] The payment account switcher engine backend may generate cryptographically signed payment contexts that encapsulate payment method metadata without revealing PAN / CVV values. These contexts may include merchant domain binding, user account binding, authorization status, TTL and replay constraints, and references to one-time processor tokens. Contexts are digitally signed and validated by merchants prior to updating POFs, preventing replay, substitution, or unauthorized modification. Sensitive account data never traverses merchant systems. Merchants receive only constrained cryptographic capability tokens, and token reuse is cryptographically prevented, n this disclosure, a payment service provider (PSP) system refers to a platform or intermediary that facilitates the authorization, tokenization,AttyDktNo.: 66416-702601

[0200] vaulting, and transmission of payment credentials between the user’s payment account and merchant systems. This is distinct from an issuer system, which is the financial institution or bank that issues the user’s underlying payment instrument. A payment instrument refers to any method by which a user can access funds or execute payments, including but not limited to credit cards, debit cards, bank accounts, digital wallets, prepaid cards, virtual cards, or other electronic payment mechanisms. The PSP abstracts and intermediates sensitive operations, enabling the switcher engine to create a temporary, securely bound payment context while the underlying issuer retains custody of the user’s actual payment credentials. The payment context may further include cryptographically signed bindings linking the payment instrument to the merchant, user account, and permissible transaction types, thereby preventing unauthorized reuse or replay of the context.

[0201]

[0155] In some cases, the payment account switcher engine backend may send a payment context ID to the PSP 2215 The backend then sends a payment context ID to the PSP (2215). The PSP may optionally authenticate the user again or verify ownership of the payment method before presenting a graphical user interface (GUI) (2216, 2307) for selecting a payment instrument. Once a payment instrument is selected, the PSP confirms authorization, and the merchant system obtains a payment token (e.g., a one-time-use nonce) from the payment processor. The token may be cryptographically bound to the merchant, the user account, and a limited time-to-live (TTL), ensuring that the token expires after a defined interval and cannot be reused fraudulently. By relying on tokenization, sensitive data such as the primary account number (PAN) or card verification value (CVV) is never exposed to the merchant. Instead, the merchant system may vault the token for recurring transactions or securely exchange it with the processor as needed. In some embodiments, the account information may be fully tokenized before transmission. Tokens are mapped internally to the underlying payment details stored securely in the switcher engine’s or processor’s vault. Only authorized systems, operating within the defined trust boundaries, can resolve tokens back to actual payment credentials. This ensures that neither the merchant nor any intermediary system outside the PSP and processor infrastructure gains visibility into raw cardholder data.

[0202]

[0156] In some embodiments, the payment account information is contained within a token. In some embodiments, the account information may be tokenized before being transmitted to and from the issuer system and / or the PSP system. For example, the payment account information may be converted to a string of characters which may include a token. In some embodiments, the merchant system that receives the token may correlate the token with data within the payment account switcher engine and / or payment account switcher database.AttyDktNo.: 66416-702601

[0203]

[0157] In some embodiments, the PSP generates an approved payment context once the user has successfully selected and authorized a payment instrument. The approved payment context may comprise structured metadata that binds together the user account identifier, the merchant identifier, the selected payment instrument, and an authorization status. In some cases, the approved payment context also encapsulates a reference to the cryptographically bound payment token (e.g., a one-time-use nonce), along with associated constraints such as validity period, permitted merchant domains, and transaction type restrictions. In some embodiments, the approved payment context may be transmitted from the engine backend 2217 to the merchant system as a digitally signed object or tokenized payload, such that only the PSP or processor can generate valid instances. This prevents replay attacks or unauthorized substitution of payment credentials. The merchant system may store the approved payment context alongside the vaulted payment token and use it for reconciliation, audit, or future POF switching events across multiple merchants.

[0204]

[0158] Referring again to FIG. 22, once the user selects a payment instrument and the PSP confirms authorization, the payment account switcher engine backend receives an indication of approval and generates or retrieves an approved payment context (2217). The approved payment context may include a payment context identifier, a pointer to a vaulted payment token generated by the payment processor, a merchant identifier or merchant domain restriction, a user account identifier within the PSP system, an authorization status, a time-to-live (TTL) parameter specifying the validity duration of the context, and one or more digital signatures or cryptographic attestations ensuring that the context was generated by an authorized PSP or processor. The payment account switcher engine backend backend does not rely on an out-of-band approval flag or confirmation message to be informed that the payment context is approved. Instead, approval is embedded into the cryptographic structure of the payment context itself.

[0205]

[0159] At step 2217, the approved payment context is transmitted to the merchant system from the engine backend through a secure API call. The approved payment context may be added as default to wallet by the merchant system. The merchant system stores the approved payment context in association with the user’s merchant account. Merchants may validate the signed payment context and vault the provided payment token 2217. In some cases, only token references are stored, producing a secure delegated credential update that improves over conventional browser scraping or manual update methods by providing cryptographic verification, auditable execution, deterministic replay protection, and processor-verified credential binding.AttyDktNo.: 66416-702601

[0206]

[0160] The merchant system validates the approved payment context, verifies its digital signature or cryptographic binding, and uses it to update the default payment option on file (POF) for the user’s account. The merchant system may further vault the associated payment token obtained from the payment processor, ensuring that the actual PAN or CVV values are never exposed to merchant servers.

[0207]

[0161] In some cases, upon successful update of the default POF, the merchant system transmits a success indication, such as a webhook, signed API response, or callback, to the payment account switcher engine and the engine may transmit the success indicator to the PSP system 2218. The payment account switcher engine then provides a corresponding success GUI view to the user, confirming that the selected payment instrument has been set as the default for the merchant. In some embodiments, the same approved payment context may be reused across multiple merchants in a batch switching flow, subject to the TTL and domain restrictions embedded within the context.

[0208]

[0162] The switcher engine functions as a proxy on behalf of the end user, managing the orchestration between the PSP and the merchant systems. For example, as described above, the engine may establish a secure API session with the PSP, request a payment context ID, and then coordinate the flow of authorization and token issuance with the payment processor. The flow is seamless with the engine performing the cryptographic exchanges, credential mapping, and webhook / API callbacks, while presenting the user only with the GUI interactions (e.g., selecting or confirming the payment method). In this way, the engine abstracts away the complexity of connecting the PSP and merchant systems, while still enforcing security, TTL limits, and token binding.

[0209]

[0163] In some embodiments, the system may be used as a card monitor for the merchant or the issuer by using, e.g., the monitoring module 126. For example, the monitoring module 126 may keep track of what cards are being used by users across the merchant system and provide insight to the merchant and / or the issuer. The issuer or merchant may be notified if there is a new card (that is not issued by the issuer) that is increasing in popularity over a certain time period or what the issuer’s card is ranked in terms of how much the card is saved as the default POF. In some embodiments, the issuer may gain insight into which cards are being used for which merchants or which types of merchants (e.g., food delivery services, streaming services, online shopping websites, etc.). In some embodiments, the information may include competitive insights such as the most popular credit cards that are being used or what other issuers are the biggest threats. Then the issuer may use this information to make changes to existing cards (e.g., provideAttyDktNo.: 66416-702601

[0210] better / different benefits) or issue a new card. In some embodiments, the issuer or merchant may be able to model behavior patterns in users and predict which cards will be used more than others. In some embodiments, the issuer or merchant may be notified when a card is no longer the default POF and then begin a campaign to “win back” the user to change back the default POF.

[0211]

[0164] In some embodiments, a dashboard may be provided for the monitoring module 126 as shown in FIG. 12. For example, the dashboard may provide how many or what percentage of users are still using the issuer’s card as the default POF as well as how much increase there has been over a period of time (e.g., how much change in percentage there has been in the last month). In some embodiments, the dashboard may also provide how many or what percentage of cards have been removed and what percentage change in removal there has been in a period of time (e.g., how much change in percentage there has been in the last month). In some embodiments, the dashboard may provide how many new cards have been added as the default POF over a period of time as well as how much change in percentage there has been in a period of time.

[0212]

[0165] In some embodiments, the dashboard may provide competitive insight information. For example, the competitive insight information may include what percentage of default POFs are issued by which issuers. In some embodiments, the dashboard may also be able to provide recent trends, such as which card has gained popularity over a period of time, or which card has fallen out of favor over a period of time.

[0213]

[0166] In some embodiments, the dashboard may also provide competition by merchant information related to which cards are being used for which merchants. For example, the dashboard may show which cards are the most popular with which merchant.

[0214]

[0167] In some embodiments, the dashboard may also provide information on the likelihood of the issuer’s card being removed as the default POF. The likelihood may be determined based on analyzed trends, cards in the market, new cards being introduced, changed card benefits, etc. The issuers may use this information to change certain benefits of the cards they are issuing or begin campaigns to retain their customers.

[0215]

[0168] In some embodiments, the system may be able to provide information to the merchants using a transaction link module 128. The transaction link module 128 may provide insight to the merchant that the merchant can then use to retain and / or win back customers. For example, the merchant may be provided SKU-level information on transactions. The SKU-level information may include what items are being bought from which merchants at what price. The SKU-levelAttyDktNo.: 66416-702601

[0216] information may also include buyer information such as age, sex, location, etc. FIG. 16 shows an example of SKU-level transaction data.

[0217]

[0169] In some embodiments, users may be able to access transaction data using the transaction link module 128. For example, if the user bought an item at a merchant, and if the user has provided access to the user’s account information for the merchant system to the payment account switch engine, the user may be able to view information related to all of the products and services they are paying for or subscribed to. In some embodiments, the transaction link module 128 may redirect the user to a direct website link including the transaction information. For example, the user may see a vague transaction description when the user logs into the issuer system for which the user’s card was used to make the transaction. The transaction history may simply show vague information such as the merchant’s name and order number. Typically, a user would have to log into the merchant system and look at the transaction history to find what item was purchased and correlate the transaction from the merchant system to the transaction in the issuer system. This can also be confusing because the transaction may not post immediately or take a few days to settle in the issuer system. However, in some embodiments, by using the, the user may be able to see exactly correlate the two transactions by clicking a link on the issuer system’s transaction history or a similar interface on the issuer system (e.g., a link displaying a transaction in the transaction history on the payment account switcher interface 115). If the user has provided access to the engine to access the user’s account in the merchant system, clicking the link can for example open up the order details of the exact transaction that was made in the user account.

[0218]

[0170] As shown in FIG. IB, the transaction link module 128 may provide item-level transaction data with an embedded approach to merchant account connectivity. Merchants, card issuers, and / or any other entities utilizing the transaction link (e.g., reward provider, etc.) may access the hyper-rich, item-level transaction data on the customers. The data link for the transaction data and other data in the Card Updater (account updater), Subscription Manager, Card Monitor, and Transaction Link may be provided via a persistent connection 150. The persistent connection 150 maintains a connection with the merchant after the initial authentication 151. A merchant or financial institutional may be provided option to turn off the persistent connection. FIG. 1C shows an example of account updater component. The account updater component may allow users to initiate an action such as upon lost, damaged, or had card stolen, moving to a new address or any other change in the cardholder information (e.g., demographic information change). Upon detecting a change of the account (e.g., a user canceled / suspended a card, changed account holder information via an interface (UI) of a card issuer system), the accountAttyDktNo.: 66416-702601

[0219] updater component may automatically update all the payment method associated with the account and / or the account information linked to the merchant systems. This beneficially allows for an automatic account update even after a payment method is added to a merchant system.

[0220]

[0171] In some embodiments, the transaction data and / or the persistent connection in the transaction link module may be provided via the merchant’s various API endpoints (e.g., pull / push connection depending on the merchant and endpoint). The transaction data may be retrieved on varying cadences and at the explicit request of the customer at a point in time. For example, the system or transaction link module makes a request to a given merchant’s API with the API headers and request body required for that endpoint, receives large amounts of transaction data and parses the above information from the API responses. The data retrieval can be performed on a cadence and ad-hoc at the customer’s request. In some embodiments the Connection Manager or Persistent Link Controller of the payment account switcher engine maintains and supervises long-lived transports used to deliver near-real-time transaction events and SKU streams. Examples of supported transports may include TLS-protected Web Sockets (wss: / / ) with periodic ping / pong keepalives, Server-Sent Events (SSE), and long-lived webhook subscriptions with mutual TLS or signed webhook verification. The Connection Manager may associate each transport with scoped authorization artifacts (for example an OAuth access token, payment context id, or merchant-scoped bearer token) and metadata describing permitted payloads and cadence. The persistent link or channels beneficially reduce polling overhead and supply low-latency, high-fidelity item-level transaction data while respecting merchant rate constraints, providing a significant efficiency and freshness advantage compared to periodic polling approaches.

[0221]

[0172] In some embodiments, the system or transaction link module may be capable of retrieving transaction data based on limited user information. For example, transaction data and / or rich transaction data can be retrieved based only on user name, phone number or email address. In some cases, the transaction link module may implement a method comprising i) detection process for efficiently detecting account existence (e.g., based on merchant response type and / or response time), ii) authentication process for seamlessly login and processing merchant responses, iii) establishing a secure session for further data retrieval. The method may be implemented via a security process to ensure the data exchange are encrypted and compliant with regulations.

[0222]

[0173] A detection process may be utilized in the authentication, the transaction link, and various other features of the system. The detection process may comprise: i) receiving limitedAttyDktNo.: 66416-702601

[0223] user information (e.g., a customer phone number or email address) from a third-party (e.g., card issuer, etc.), ii) initiating login attempt by logging in to the merchant’s system using the provided information (e.g., email address along with a placeholder password), iii) parsing merchant response. If no user is found, the system may confirm that the account does not exist. If the password is incorrect, the system may confirm the account exists but requires valid credentials. Next, the system may implement an authentication process. The authentication process may comprise: i) initiating login with credentials (e.g., If the account exists, the transaction link module attempts to log in using client-provided credentials (phone / email and password)), ii) analyzing merchant responses. For example, if the password is correct, authentication is successful and the system may establish a secure session. If the password is incorrect, the system may prompt the customer for entering a correct password. In some cases, additional verification may be required (e.g., OTP, CAPTCHA) prior to establishing the session. If additional verification is required, the system man handling the additional verification by facilitating OTP workflows, CAPTCHA challenges, or other verifications, that may or may not involve the user interaction. Once authentication process is completed, the system establishes a secure session to interact with the user’s account. The secure session may allow for further data retrieval and data exchange encrypted and compliant with regulations.

[0224]

[0174] The transaction link module may allow users or merchant system / users (e.g., merchants, card issuers, any permitted third-party, etc.) to retrieve item / Stock Keeping Unit (SKU)-level purchase information for various use cases such as personal financial management, loyalty, expense management, fraud prevention, chargebacks, and targeted offers. FIG. 17 shows an example of webview or GUI of the transaction link module. The GUI may be provided to an individual user such as a consumer user. As described above, the initial sign-in or authentication may be used to maintain a persistent connection for retrieving the hyper-rich, item-level transaction data. In some instances, network session management techniques may be employed to ensure that the user (e.g., consumer) does not have to repeatedly authenticate within one session. For example, session cookies or tokens may be utilized to store user login information on the user device. The cookies or tokens may be securely communicated between the user device and a cloud instance or backend of the system to verify the user's identity, thereby maintaining a persistent authenticated state for the duration of the network session.

[0225]

[0175] In some embodiments, a user may be provided offers from merchants that the user can then take advantage of by clicking on one link. For example, the user may be presented an offer in the interface 115 to create an account with a new merchant. If the user likes the offer and desires, the user may click the link, and then engine (e.g., account creator 125 in FIG. IB) mayAttyDktNo.: 66416-702601

[0226] automatically create an account with the merchant system and add a card in the issuer system as the default POF for the merchant. In some embodiments, the user may have provided information to the engine 120 or interface 115 beforehand to input the user's information for signing up on any new merchant websites. Accordingly, the user may be able to very easily and quickly take advantage of an offer by the merchant while the merchant gains a new user. The account creator 125 may be capable of automatically setting up merchant accounts for new users or cardholders, ensuring immediate usability.

[0227]

[0176] FIG. 18 shows another example of using transaction link module to automate user cashback rewards, ensuring faster processing and eliminating manual receipt uploads for users. Conventional rewards such as cash-back program may require customers to manually upload receipts to claim cash-back rewards, which a time-consuming process that can create friction and limited reward opportunities. The transaction link module herein beneficially provides a seamless solution that allows customers to earn cash-back rewards at eligible merchants without the hassle of manual uploads.

[0228]

[0177] As shown in the example, a third-party system (e.g., cash-back rewards service system, retailer system, etc.) integrated with the transaction link module herein may improve the process of ingesting customer receipt data and, in turn, enhancing the cash-back rewards experience. With the transaction link module, the third-party system’s customers can securely link their merchant accounts 1801, 1803, enabling the third-party system (e.g., cash-rewards system) to instantly access rich, reliable transaction data, including itemized purchase information for both online and in-store purchases as described above. By leveraging itemized transaction data, the third-party system can automatically identify eligible purchases, ensuring customers receive cash back within a shortened period of time (e.g., 24 hours) — completely eliminating the need for manual receipt uploads. The transaction link integration provides the automated cash-back rewards by capturing every eligible purchase with improved accuracy and reliability.

[0229]

[0178] Agentic one-click shopping

[0230]

[0179] In some embodiments, the system herein may act in an agentic manner to search and recommend items based on data retrieved from merchant systems. For example, the system herein may call the merchant’s search API to pull back the products that the user is interested in buying. A user may be provided a chat-like user interface (UI) to explore products and make purchase. The system herein may leverage any existing Al agents, Al model, machine learning (ML) model or large language model (LLM) to extract the purchase intent and generate a list of product recommendations based on the user intent. The system may call the merchant systemAttyDktNo.: 66416-702601

[0231] API for buy to complete the actual purchasing process. The user may be required to be authenticated into the merchant system for the system herein to seamlessly buy the product. This allows the user to complete the buying process within their own merchant account particularly when the merchant systems require a user to login (e.g., no guest checkout). In some embodiments, the transaction link module may allow for agentic one-click shopping / purchasing capability. The system herein may act in an agentic manner to search and recommend items based on the item-level transaction data provided by the transaction link module. For instance, a user may, via chat-like text-based interactions, to purchase product via a single click. A user may be provided a chat-like user interface (UI) to explore products and make purchase. The system herein may leverage any existing Al agents, Al model, machine learning (ML) model or large language model (LLM) to extract the purchase intent and generate a list of product recommendations based on the transaction data provided by the transaction link herein. An artificial intelligence (Al) agent can interact with its environment, collect data, and use the data to perform self-determined tasks to meet predetermined goals. An Al agent may comprise memory (“states”) and context management. Al agent's "state" refers to its current internal representation of the environment, including relevant information about its current situation, goals, and past interactions, essentially acting as the agent’s "memory" that allows it to make informed decisions based on context. The state is typically stored in a structured format within the agent's memory system, which can include different levels such as short-term and long-term memory. Short-term memory stores temporary information needed for immediate decisionmaking, such as the last few user inputs in a conversation while long-term memory stores information that needs to be retained for a longer period, such as general knowledge or learned patterns. For example, Al agents may use context window to store a limited amount of recent conversation history, acting as a form of short-term memory. In some cases, the transaction data provided by the transaction link module herein may provide the long-term memory and the conversation history may provide the short-term memory.

[0232]

[0180] The one-click agentic shopping feature may comprise an intelligent product discovery with seamless transactional execution through direct API integrations. FIGs. 19-20 show an example of the one-click agentic shopping feature provided by the system herein. In the example, a user may submit, via a chat UI 2000, inquiries or requests 2001 (e.g., I would like to buy some cheap headphones). Upon receiving the user input, the system may employ the Al agent to query the merchant’s search API to find, return, and display relevant products to users based on the user’s input and preferences. The user preferences may be based on the transaction link data as described above. In some cases, the Al agent or the Al model may programmaticallyAttyDktNo.: 66416-702601

[0233] discover and query public (but undocumented) merchant search APIs to fetch relevant products 2003 based on user intent and preferences.

[0234]

[0181] In some cases, the system herein may comprise an execution layer to generate inputs (e.g., structured prompt) for the agents or inputs for searching, selecting and executing the relevant merchant search APIs. For instance, these merchant APIs may not be scraped or reverse-engineered via browser sessions — they are legitimate, direct API endpoints. An undocumented merchant API may refer to an API (Application Programming Interface) provided by a merchant (e.g., Walmart, Amazon, Kroger) that is not publicly documented or has no formal developer documentation, SDKs, or onboarding process. The system herein may make server-to-server requests without browser emulation or scraping. This beneficially ensures direct, fast, and structured access to product data or user actions and avoid slow, brittle scraping or Ul-based automation.

[0235]

[0182] In some cases, as shown in the UI, the recommended products 2003 may be displayed with a one-click ‘buy’ option 2005. The system herein may display, for each recommended product, a one-click ‘buy’ option 2005 for a user to quickly and easily confirming the product to purchase. Once the user selects or affirms a product they’d like to purchase, the system may ask the user to confirm 2007 and the upon the user confirmation the selection of the product 2009, the user may be prompted to authenticate into their merchant account — if they haven’t already done so, via the system login features as described elsewhere herein. For example, as shown in FIG. 19, the same secure authentication process as described elsewhere herein may prompt the user to connect to the merchant 1901, authenticate with the merchant 1903 such as via the merchant webview for login 1905 and successfully connect to the merchant account 1907. As described above, the authentication process is user-permissioned and managed entirely within the system SDK.

[0236]

[0183] After authentication, the system may call the merchant’s native “buy” API or checkout API to complete the purchase on behalf of the user. For instance, the system may supply the user default payment information, shipping address, contact information adapting to the merchant API parameters. The system may also add the payment method in the user authentication flow if needed. The system may make a direct API call to the merchant, instead of an emulated session or agent-based interaction. Without involving emulation or synthetic session, the direct APIbased purchase beneficially ensures speed, reliability, and compliance The merchant system handles fulfillment, order confirmation, and payment directly, as they would in a standard user session. The system may then display the confirmation and details of the purchase to the user.AttyDktNo.: 66416-702601

[0237]

[0184] FIG. 21 shows another example of one-click agentic shopping. As shown in the example, a user input 2101 may indicate the intent to purchase a product that was purchased in the past but in different size 2105. The system may process the transaction link data and make the recommendation 2103, 2107 along with the one-click purchase button.

[0238]

[0185] Another aspect is a computer system comprising a memory storing computer-readable instructions and at least one processor configured to execute the computer-readable instructions that are configured to perform the method of any of the aforementioned embodiments.

[0239] Another aspect is a non-transitory computer-readable storage media comprising executable instructions that, when executed by at least one processor, are configured to perform the method of any of the aforementioned embodiments.

[0240] User Interfaces

[0241]

[0186] FIGs.3, 4, 5, and 6 show example screenshots of a user interface of the payment account switcher (i.e., card switcher) interface on a mobile device, in accordance with some embodiments. As discussed elsewhere herein, the mobile device may include a smartphone, a tablet, a PDA, or any other electronic device that is not a computer. Although various example screenshots have been shown, embodiments are not limited to the example screenshots shown in FIGs. 3-6, and the user interface may vary depending on embodiments.

[0242]

[0187] Referring to FIG. 3, a dashboard (or a home screen) of the user interface is shown, in accordance with some embodiments. In some embodiments, the user interface may be part of the user interface for a website or an app that is provided by the issuer system. In some embodiments, the dashboard may show the card (e.g., last four digits of the card number) or account number that the user is currently viewing. In some embodiments, the dashboard may include a tile 302 that the user may select, including a tile for the user to add a card to the wallets and merchants for quick and secure payments. In some embodiments, the dashboard may include a first screen for the payment account switcher interface. In some embodiments, the user may select the tile to begin the process of switching the default POF.

[0243]

[0188] Referring to FIG. 4, a next screen is shown, in accordance with some embodiments. In a first workflow, after the user selects the tile to change the default POF, the user may be directed to a screen where the user has the ability to select which wallets or merchants that the user selects to change the default POF for. In some embodiments, only one of the lists of wallets or the list of merchants may be shown. In some embodiments, the user may select one or more wallets including Apple Pay and PayPal, indicating that the user selects to use the selected card when making purchases with Apple Pay or PayPal. In some embodiments, the user may alsoAttyDktNo.: 66416-702601

[0244] select one or more merchants that have been prepopulated, including Netflix, Amazon, and Amazon Music, indicating that the user selects to use the selected card when making purchases or paying for subscription on any of the selected merchants. In some embodiments, the user may be displayed a merchant view of the login page discussed elsewhere herein.

[0245]

[0189] Referring to FIG. 5, a next screen is shown, in accordance with some embodiments. In some embodiments, once the user selects a wallet or merchant to change the default POF, the user may be shown a screen that asks the user for their log-in information, such as user ID and password. In some embodiments, the user may use SSO or Face ID, or any similar methods of logging into accounts.

[0246]

[0190] Referring to FIG. 6, a next screen is shown, in accordance with some embodiments. After the authentication process has been completed, the user may be shown a confirmation page that indicates that the default POF has been successfully switched to the selected card.

[0247]

[0191] FIGs. 7, 8, 9, and 10 show examples of a user interface of the payment account switcher interface on a computer, in accordance with some embodiments. In some embodiments, the computer may include a desktop or laptop computer. Although various example screenshots have been shown, embodiments are not limited to the example screenshots shown in FIGs. 7-10, and the user interface may vary depending on embodiments.

[0248]

[0192] Referring to FIG. 7, a dashboard (or a home screen) of the user interface is shown, in accordance with some embodiments. In some embodiments, the user interface may be part of the user interface for a website or an app that is provided by the issuer system. In some embodiments, the dashboard may show the card (e.g., last four digits of the card number) or account number that the user is currently viewing. In some embodiments, the dashboard may include a tile 702 that the user may select, including a tile for the user to add the selected card to the user’s wallets and merchants for quick and secure payments. In some embodiments, the dashboard may include a first screen for the payment account switcher interface. In some embodiments, the user may select the tile to begin the process of switching the default POF.

[0249]

[0193] Referring to FIG. 8, a next screen is shown, in accordance with some embodiments. In a first workflow, after the user selects the tile to change the default POF, the user may be directed to a screen where the user has the ability to select which wallets or merchants that the user selects to change the default POF for. In some embodiments, only one of the lists of wallets or the list of merchants may be shown. In some embodiments, the user may select one or more wallets including Apple Pay and PayPal, indicating that the user selects to use the selected card when making purchases with Apple Pay or PayPal. In some embodiments, the user may alsoAttyDktNo.: 66416-702601

[0250] select one or more merchants that have been prepopulated, including Netflix, Amazon, and Amazon Music, indicating that the user selects to use the selected card when making purchases or paying for subscription on any of the selected merchants.

[0251]

[0194] Referring to FIG. 9, a next screen is shown, in accordance with some embodiments. In some embodiments, once the user selects a wallet or merchant to change the default POF, the user may be shown a screen that asks the user for their log-in information, such as user ID and password. As shown in FIG. 9, the log-in screen may be overlaid over the background screen of FIG. 8. In some embodiments, the user may be displayed a merchant view of the login page discussed elsewhere herein. In some embodiments, the user may use SSO or Face ID, or any similar methods of logging into accounts.

[0252]

[0195] Referring to FIG. 10, a next screen is shown, in accordance with some embodiments. After the authentication process has been completed, the user may be shown a confirmation page that indicates that the default POF has been successfully switched to the selected card.

[0253] Mass switcher

[0254]

[0196] As described above, the payment account switcher interface may provide a list of merchants that are commonly used to the consumer so that the consumer can select which merchants they want to switch the POF. The user may choose a merchant from the list and the user can log-in to their selected merchants by providing log-in information which may be kept secure. As described above, the log-in page may be a page generated by the system herein and appear to be similar to the log-in page of the merchant. The login page may be a page generated by the switcher engine and may visually resemble the merchant’s native login page while optionally displaying system-specific indicators or instructions to ensure the user is aware of the authentication context. In some cases, the system may generate the log-in page with modified visual elements. For example, the log-in page may display instruction or indication that the user is providing the credential to the system or display the merchant icon while removing unnecessary information to not confuse the user.

[0255]

[0197] In some embodiments, the system herein may further provide mass switcher feature that a user may choose a plurality of merchants to change the default POF without entering the credentials for each merchant manually. FIG. 13 shows the mass switching component implemented in the backend 1310 in communication with a credential management system 1320 for the mass switching feature. In alternative cases, mass switch may be performed without exchanging passwords (e.g., browser extension-based).AttyDktNo.: 66416-702601

[0256]

[0198] In some embodiments, the system may further provide a mass switching feature that enables the user to select multiple merchants to change the default POF without manually entering credentials for each merchant. In this mass switching flow, the backend system may communicate with a credential management system such as a password manager, single sign-on (SSO) account, or other credential vaults to retrieve stored login credentials. The credential management system may include a password manager page and a credential API, which can provide encrypted credentials and associated metadata. For example, a browser extension may leverage the Credential Management API to securely retrieve usernames and passwords without exposing raw credentials to the backend or merchant systems. As shown in the example, the credential management system 1320 may be a credential keychain, a single sign-on (SSO) account or any other credential managers (e.g., browser extension, API, etc.) that stores all the usernames, passwords associated with a user or allows a user to access different accounts, websites by a single set of credential. As shown in the example, the credential management system 1320 may comprise a password manager page 1321 and a credential API 1323. For instance, a browser extension utilizes the Credential Management API to allow websites to securely store and retrieve user login credentials such as usernames and passwords.

[0257]

[0199] In some embodiments, the mass switching component in the backend 1310 may comprise a mass authentication module 1311 and a module 1313 for detecting merchants. In an example of process of mass switching, a user may first log in to a credential management account (e.g., passwords.google.com) through a web-view provided by the backend system or the SDK as described elsewhere herein (e.g., system 100). For example, the user may be prompted to manually input a password to log into a credential management account provided by the credential manager 1320 via a web-view generated by the backend 1310. FIG. 14 shows an example of a web-view displaying an option for a user to log into a credential management account or a SSO account 1401. In some cases, the web-view may also display a list of personalized merchants that the user may choose to switch the POF as described above.

[0258]

[0200] Upon user authentication to the credential management account through a secure webview or SDK-provided interface, the mass authentication module of the backend may retrieve session tokens, cookies, and redirect URLs from the credential management system. These artifacts are used to programmatically access and decrypt stored credentials while maintaining end-to-end encryption and ensuring that sensitive data such as passwords are only decrypted in memory. Referring back to FIG. 13, upon receiving the credential to log into the credential management account, the mass authentication component 1311 may access the password page 1321 using the session data. If the login is successful, the SDK 1321 sends the user's accountAttyDktNo.: 66416-702601

[0259] cookies (e.g., Google cookies) and final redirect URL to backend system 1310. The backend system or the mass authentication component 1311 may proceed to access the URL (e.g., passwords.google.com) to extract the passwords’ decryption key. Next, the backend system may request encrypted password from the credential API 1323. The mass authentication component may extract and decrypt the (encrypted) passwords using the decryption key. The component for detecting merchants 1313 may then process the decrypted passwords and associated merchants accounts to extract the merchants (i.e., identified or detected merchants). In some embodiments, after successful authentication to a credential management system or SSO vault, the backend mass authentication module receives a set of session artifacts including encrypted cookie jars, vault access tokens, account identifiers, and redirect metadata. These artifacts are treated as opaque authentication handles and are not interpreted as plaintext credentials. The backend stores only encrypted references to such artifacts in an HSM / KMS-protected session store, and does not persist raw usernames, passwords, or decrypted secrets. Decryption keys, when required, may be fetched transiently into volatile memory and purged immediately after use.

[0260]

[0201] Instead of requiring repeated manual login to discover accounts, the system leverages encrypted cookies, vault metadata, and session tokens to programmatically identify merchant accounts associated with the user. Detected accounts are validated using token introspection endpoints or deterministic fingerprinting, without ever exposing the underlying passwords or PAN / CVV values. This approach not only improves user convenience — enabling batch switching of default payment instruments across multiple merchants — but also enhances security and privacy by minimizing sensitive data exposure and reducing unnecessary authentication network traffic. In some cases, the system or engine may comprise a detected-accounts module configured to process the retrieved artifacts to identify merchant accounts using a multi-stage merchant resolution pipeline. In a first stage, the module parses structured vault metadata returned by the credential management system or detected-accounts API, including service identifiers, domain names, login endpoint URLs, and last-used timestamps. Each detected account object may include fields such as provider id, service domain, redirect uri, login hint, account label, and detection timestamp. The module normalizes these fields into canonical merchant keys by applying domain normalization, public suffix list resolution, and URL canonicalization to collapse variant hostnames and subdomains into unique merchant identifiers. In a second stage, the detected-accounts module performs deterministic merchant fingerprinting. For each candidate merchant domain, the module computes a merchant fingerprint derived from a tuple comprising normalized domain, known authentication endpoint paths, cookie namespace patterns, and supported authentication methods (e.g., OAuth, form-post, token-based). TheseAttyDktNo.: 66416-702601

[0261] fingerprints are matched against a merchant capability registry maintained by the switcher engine backend. The registry stores per-merchant capability metadata including supported authentication flows, POF update modalities, anti-automation constraints, and tokenization compatibility. A successful fingerprint match confirms that a detected account corresponds to a supported merchant and identifies the optimal update modality for that merchant. In a third stage, the detected-accounts module performs token-based validation. For merchants that expose lightweight authenticated introspection endpoints, the module issues a non-mutating authenticated probe using the retrieved access token or session cookie to validate that the token corresponds to an active account without retrieving account profile data. For example, the module may issue an HTTPS GET request to a merchant introspection or session-status endpoint and validate the HTTP status code, CSRF token presence, and session scope flags. The response is reduced to a boolean validity signal and minimal metadata, such as account_active=true and merchant_id=xyz, thereby confirming account existence while preserving privacy. The detected-accounts module then aggregates validated merchant accounts into a detected-accounts set associated with the session identifier. Each detected account record may include a merchant identifier, a reference to the session artifact used for validation, a detection confidence score, a last verified timestamp, and supported update modalities. The systems herein may not store plaintext credentials, PAN values, or personal profile data without user permission. The detected-accounts set is persisted as encrypted references and is auditable through an

[0262] append-only ledger of detection events.

[0263]

[0202] The detected-accounts set is transmitted to the front-end SDK, which renders a list of detected merchant accounts for user confirmation. Each merchant entry may include a merchant name, logo, domain, and a confidence indicator, and may expose selection controls for batch switching. User selections are cryptographically bound to the detected-accounts set and session identifier, ensuring that only user-approved merchants are processed in subsequent batch POF update workflows. Upon extracting the merchants, as shown in FIG. 14, a web-view provided by the backend system may be updated or modified to display the detected or identified merchants accounts 1411 along with a list of the detected merchants 1413 with options for the user to select to switch the POF. For example, the user may toggle to sei ect / de- select the merchants accounts for the mass switch of the POF. In some cases, after submitting the credentials to the selected merchant systems, the method may comprise monitoring authentication of the credentials and providing any error messages, captchas, one-time password (OTP) requests, etc. to the user as described elsewhere herein.AttyDktNo.: 66416-702601

[0264]

[0203] Such mass switching feature beneficially allows users to login to a S SO or credential management account and subsequently switch the POF across multiple merchants in a seamless manner using the store credentials in the SSO. As described above, upon a single loin to the SSO account, the system herein may automatically extract merchants for which the users have credentials stored thereon. Unlike conventional authentication methods that rely on capturing or reusing merchant credentials entered by the user, such as through an embedded login interface or a third-party redirect, which exposes raw credentials and requires repeated manual entry for each merchant account, the payment account switcher engine and system described herein improve upon these methods by employing token- and cookie-based authentication with strong session management. Instead of obtaining user credentials in plaintext, the system retrieves ephemeral authentication tokens, session cookies, and cryptographically bound session artifacts from credential management systems, SSO providers, or PSP vaults. These tokens are used to authenticate the user to multiple merchants programmatically while maintaining privacy. For instance, each session is associated with a unique session identifier, which is cryptographically bound to the user’s intent and to specific merchants, ensuring that authentication flows are deterministic, auditable, and cannot be replayed or reused maliciously.

[0265]

[0204] Secure-enclave handling of card data and credentials

[0266]

[0205] In some embodiments, plaintext-sensitive data (for example, primary account numbers (PAN), CVV, and plaintext user credentials) are never available to the payment account switcher engine outside of a verifiably isolated execution environment. The present disclosure provides an architecture that any plaintext-sensitive material (PAN, CVV, plaintext passwords) is sent encrypted (JWE) and is decrypted only inside a remote secure enclave that the backend or switcher engine cannot access. In some cases, the system or switcher engine may not have private key and therefore cannot decrypt or view raw card data or passwords. FIG. 24 illustrates an example network architecture 2400 using the secure enclave system, and FIG. 25 shows an example flow of encrypted cardholder data through the secure enclave system. In some embodiments, the payment account switcher engine employs a secure enclave architecture to ensure that sensitive cardholder data and user credentials are never accessible to the switcher engine's primary backend systems. The secure enclave 2401 comprises an isolated computing environment that is architecturally separated from the main backend infrastructure and is configured such that the switcher engine cannot decrypt or access the plaintext values of sensitive data at any point during processing. Unlike conventional systems where credentials may pass through multiple backend services, the secure enclave architecture herein ensures thatAttyDktNo.: 66416-702601

[0267] the switcher engine backend not access decryption keys, thereby providing a zero-knowledge architecture with respect to sensitive payment and authentication data.

[0268]

[0206] As shown in FIG. 24 and FIG. 25, when a financial institution 2421 (customer bank or issuer system) transmits cardholder data 2422 to the payment account switcher system, the cardholder data is encrypted using JSON Web Encryption (JWE) format 2423. The JWE encryption is performed using a public key infrastructure where the secure enclave holds the corresponding private key, but the switcher engine backend does not possess or have access to the private key necessary for decryption. The encrypted JWE payload containing the cardholder data is received by the backend, which cannot decrypt the JWE due to the absence of the private key. Instead, the backend transmits the encrypted JWE to the secure enclave 2401, which possesses the private key within its isolated environment. The secure enclave 2401 decrypts the JWE and returns a ciphertext reference to the backend. This ciphertext reference serves as an opaque token or handle that the backend can use to instruct the secure enclave to perform operations involving the decrypted cardholder data, without the backend ever gaining access to the plaintext data itself. In some embodiments, the ciphertext may be generated using symmetric encryption within the secure enclave, where the symmetric key is maintained exclusively within the enclave and is never exposed to external systems.

[0269]

[0207] In some embodiments, the cardholder data may be transmitted through a Payment Card Industry (PCI) compliant proxy service provider that performs tokenization on behalf of the issuer or financial institution. A PCI proxy is a specialized intermediary service that is certified to handle sensitive payment card data in compliance with the Payment Card Industry Data Security Standard (PCI DSS). The PCI proxy acts as a secure gateway that receives cardholder data from the financial institution, tokenizes the data by replacing sensitive elements such as the primary account number (PAN) and card verification value (CVV) with non-sensitive token values, and transmits these tokens to downstream systems that do not require PCI DSS compliance. By interposing a PCI compliant proxy between the card issuer and the payment account switcher engine, the system architecture beneficially reduces the compliance burden on the switcher engine backend, as the backend never receives or processes cardholder data in its original sensitive form.

[0270]

[0208] In this flow, the financial institution sends the cardholder data through the PCI proxy, which generates a token representing the cardholder data. The token is a cryptographically generated identifier that can be used to reference the underlying cardholder data without revealing the actual card number or security codes. The token is then transmitted to the switcherAttyDktNo.: 66416-702601

[0271] engine backend. The backend, upon receiving the token, forwards the token to the secure enclave. The secure enclave is configured to communicate with the PCI proxy provider to decrypt or resolve the token back to the actual cardholder data within the enclave's isolated environment. This token resolution process occurs exclusively within the secure enclave through authenticated API calls to the PCI proxy provider's detokenization service. The decrypted cardholder data remains within the secure enclave and is never exposed to the switcher engine backend. The secure enclave then generates a ciphertext or internal reference that the backend can use for subsequent operations.

[0272]

[0209] The system architecture beneficially supports both direct JSON Web Encryption (JWE) encryption and PCI proxy tokenization, provides flexibility for different issuer integration models while maintaining the zero knowledge guarantee for the switcher engine backend. This architecture allows financial institutions to choose the integration method that best aligns with their existing security infrastructure and compliance frameworks. Institutions with mature public key infrastructure can leverage JWE encryption, while institutions that already use PCI proxy services can continue using their established tokenization workflows. By supporting multiple paths for credential transmission, the system increases its addressable market and reduces integration friction, as issuers do not need to adopt new security mechanisms to participate in the payment account switching ecosystem. This architecture maintains consistent security properties across both paths, ensuring that regardless of which method is used, the switcher engine backend never gains access to plaintext cardholder data. The use of PCI proxy tokenization specifically reduces the compliance scope and audit requirements for the switcher engine operator, as systems that handle only tokens rather than actual card data are subject to reduced PCI DSS requirements. Such architecture provides multiple security mechanisms including tokenization at the PCI proxy, encryption in transit, secure enclave isolation, and access controls at each system boundary. This multi layered approach ensures that even if one security control were to fail, additional controls would prevent unauthorized access to sensitive data.

[0273]

[0210] The secure enclave may be configured as an operationally isolated environment with specific architectural characteristics that prevent unauthorized access to sensitive data. In some embodiments, the secure enclave is implemented such that administrative access via secure shell (SSH) or similar remote access protocols is disabled or strictly prohibited. This configuration ensures that even authorized administrators or engineers of the switcher engine cannot access the secure enclave's internal state or retrieve decrypted credentials or cardholder data. In some embodiments, the secure enclave may generate audit logs or operational logs that record the occurrence of operations (e.g., decryption requests, merchant API calls) without logging theAttyDktNo.: 66416-702601

[0274] plaintext values of sensitive data. The logs may be transmitted to a secure logging infrastructure for compliance and auditing purposes while preserving the confidentiality of the underlying data. The secure enclave may be characterized as a "black box" architecture, meaning that the internal processing and decrypted data within the enclave are not observable or accessible from outside the enclave. The secure enclave is "secure by nature" in that its isolation is enforced at multiple levels, including cryptographic key isolation, network segmentation, process isolation, and potentially hardware-based security mechanisms such as trusted execution environments (TEEs), hardware security modules (HSMs), or secure compute instances provided by cloud infrastructure providers. This multi-layered security architecture provides technical improvements over conventional credential handling systems by ensuring that credential exposure risk is confined to a minimal, auditable, and cryptographically isolated environment.

[0275]

[0211] Referring back to FIG. 24, the secure enclave 2401 interacts with merchant systems 2441 and payment processors on behalf of the switcher engine backend. When the switcher engine backend needs to provision cardholder data to a merchant system or to a payment processor (such as Braintree, Stripe, or Adyen), the backend 2425 transmits a request to the secure enclave 2401 along with the ciphertext reference (or token reference) 2427 obtained in earlier steps. The request instructs the secure enclave to perform a specific operation, such as "provision this card to merchant X" or "update payment method with processor Y." Within the secure enclave 2401, the ciphertext reference is decrypted to retrieve the actual cardholder data. The secure enclave then executes the requested operation by transmitting the decrypted cardholder data to the designated merchant system or payment processor 2441 via a secure API call (e.g., using mutual TLS version 1.2 or higher). The merchant system or payment processor 2441 receives the cardholder data directly from the secure enclave and processes it accordingly (e.g., by vaulting the card or creating a payment token). The merchant or processor then returns a status response indicating success or failure of the provisioning operation. The secure enclave receives this status response and forwards it back to the switcher engine backend. Such architecture beneficially allows the switcher engine backend to receive only the status information (e.g., success, failure, error codes) and never receives the plaintext cardholder data. This architecture ensures that the backend can orchestrate the overall workflow and present status updates to the user, while the sensitive data handling is confined exclusively to the secure enclave.

[0276]

[0212] In some embodiments, the secure enclave may be configured for handling sensitive data in compliance with regulatory standards such as PCI DSS, GDPR, and HIPAA. The secure enclave provides cryptographically isolated compute environments where sensitive data can beAttyDktNo.: 66416-702601

[0277] decrypted, processed, and used to make API calls to external systems, while ensuring that the data is never exposed to the systems that orchestrate the workflow.

[0278]

[0213] As shown in FIG. 24, the system architecture further includes integration with a secure data repository 2403 for additional tokenization and secure storage capabilities. As an example, the secure data repository 2403 may store cardholder data in a PCI DSS-compliant environment and issues tokens or aliases that can be used in place of actual card numbers. When cardholder data 2402 is transmitted from the secure data repository 2403 (e.g., VGS Vault) to the secure enclave 2401, the data may be transmitted in tokenized form or as an encrypted payload. The secure enclave 2401 is configured to interact with the VGS provider's API 2411 to resolve tokens 2413 back to actual cardholder data within the enclave's secure processing environment. In some embodiments, the switcher engine backend may optionally store tokens returned from the secure data repository, and these tokens can be transmitted to the secure enclave for subsequent merchant provisioning operations. The secure data repository 2403 may also receive authenticated webhooks 2424 from the backend 2425 to confirm successful operations or to synchronize state across systems.

[0279]

[0214] As shown in FIG. 24, the system architecture may comprise a Web Application Firewall (WAF) component 2405 that sits between the client-side SDK 2451 and the secure backend services (e.g., App Layer) within the VPC (Virtual Private Cloud) 2407. The WAF 2405 receives both the JWE-encrypted cardholder data 2413 and session data 2453 from the client-side SDK 2451. The WAF 2405 performs security functions including request validation, rate limiting, bot detection, and filtering of malicious requests before forwarding legitimate requests to the backend e.g., App Layer 2408. The WAF provides an additional layer of security against attacks such as SQL injection, cross-site scripting (XSS), distributed denial-of-service (DDoS), and credential stuffing attempts. The WAF may be configured with rules specific to the payment account switching context, such as validating that JWE payloads conform to expected schemas, verifying digital signatures on webhooks from financial institutions, and enforcing geographic or IP -based access controls. The App Layer 2408, which comprises the primary backend services of the payment account switcher engine, is deployed within a Virtual Private Cloud (VPC) environment 2407. The VPC includes a perimeter firewall 2409 that enforces network-level access controls, restricting inbound and outbound traffic to authorized sources and destinations. The perimeter firewall 2409 ensures that the App Layer 2408 can communicate with the secure enclave (e.g., Evervault) 2401, the VGS Vault 2403, and merchant systems 2441, while preventing unauthorized external access to backend services. In some embodiments, the VPC may be configured with private subnets, network address translation (NAT) gateways, and VPNAttyDktNo.: 66416-702601

[0280] or direct interconnect links to partner systems (e.g., financial institutions, payment processors) to provide secure, low-latency data transmission channels.

[0281]

[0215] FIG. 25 illustrates a detailed sequence diagram showing the flow of cardholder data through the system, including interactions with the financial institution 2509, secure enclave 2503 (e.g., Evervault), tokenization service 2505 (e.g., VGS (Very Good Security)), and merchant system 2507. In Path A, as shown in the upper portion of FIG. 25, the financial institution 2509 encrypts the cardholder data and sends a JWE-encrypted payload to the backend 2501 via a webhook or API call. The backend 2501 receives the encrypted JWE but may not decrypt it. The backend sends the JWE to a designated card endpoint within the secure enclave (e.g., Evervault) 2503. The secure enclave 2503 decrypts the JWE using its private key and returns a ciphertext reference along with personally identifiable information (PII) or billing information that may be used for display or reconciliation purposes. The ciphertext returned from the secure enclave is an encrypted representation that the backend stores but may not decrypt. This ciphertext serves as a secure handle for subsequent operations.

[0282]

[0216] In Path B, as shown in the lower portion of FIG. 25, the backend 2501 sends the cardholder data (which may be represented as a ciphertext or tokenized form) to a tokenization service 2505 e.g., VGS (Very Good Security). The tokenization service may be a data security platform that provides tokenization and secure data storage. For example, the backend sends the card data to VGS, and VGS returns aliases (tokens) and Pll / billing information to the backend. The backend can then use these VGS aliases in subsequent operations. When provisioning the card to a merchant, the backend initiates a card provisioning request by sending the VGS aliases or the secure enclave 2503 ciphertext to the respective service.

[0283]

[0217] As illustrated in FIG. 25, Path A continues with the secure enclave 2503 decrypting the ciphertext to retrieve the actual cardholder data within its isolated environment. The decrypted card data is then used by the secure enclave to make an API call to the merchant system to provision the card. The merchant system 2507 receives the cardholder data, processes it (e.g., vaults the card, creates a payment token), and returns a status response to the secure enclave. The secure enclave forwards the status response back to the backend 2501. Similarly, in Path B, the VGS service decrypts the VGS alias to retrieve the cardholder data, provisions the card with the merchant system, receives the status response from the merchant, and forwards the status back to the backend.

[0284]

[0218] In both paths, the backend may receive the status update from the secure enclave or VGS service and then returning the final status to the financial institution. The methods and systemsAttyDktNo.: 66416-702601

[0285] herein beneficially allow the backend to perform operations without accessing to the decrypted cardholder data. The decryption and use of plaintext cardholder data occur exclusively within the secure enclave or the secure tokenization service (VGS), both of which are architecturally isolated from the backend. This multi-path architecture provides technical benefits including PCI DSS compliance, reduced liability for the switcher engine operator, minimized attack surface for credential theft, and cryptographic assurance that sensitive data is handled only within certified secure environments.

[0286]

[0219] Credential Relay and Enclave-Based Authentication

[0287]

[0220] In some embodiments, the secure enclave architecture is also employed for managing user authentication credentials when interacting with merchant systems. In some cases of authentication flows, the payment account switcher engine displays the merchant's native login page within a webview, allowing the user to authenticate directly with the merchant system using the merchant's own authentication interface. In these flows, the switcher engine front end may receive session cookies, JSON Web Tokens (JWT), or other authentication tokens from the merchant system as part of the standard browser-based authentication process. These authentication tokens are used to maintain the user's authenticated session within the webview and are not transmitted to or stored by the switcher engine backend in plaintext form.

[0288]

[0221] In alternative cases of authentication flows, the merchant system may not support embedded webview authentication, or technical constraints may require the collection of username and password credentials. In such cases, the payment account switcher engine employs a credential relay architecture in which user credentials are transmitted directly from the frontend interface to the secure enclave without passing through the switcher engine backend. The frontend captures the username and password entered by the user and transmits the credentials to the secure enclave via an encrypted relay mechanism. The secure enclave receives the credentials and returns a credential reference or handle to the frontend and / or backend. This credential reference is an opaque identifier that can be used to instruct the secure enclave to perform authentication with the merchant system on behalf of the user, without the frontend or backend ever having access to the plaintext credentials after the initial relay. The secure enclave, upon receiving an authentication request along with the credential reference, decrypts or retrieves the stored credentials within its isolated environment and uses them to authenticate with the merchant system via the merchant's API or login endpoint. The merchant system responds with authentication tokens, session cookies, or an authentication status. The secure enclave then forwards the authentication response (excluding plaintext credentials) back to the switcherAttyDktNo.: 66416-702601

[0289] engine backend, which can use the session tokens or authentication status to continue the workflow. This credential relay and enclave-based authentication architecture provides a technical benefit of ensuring that user passwords never reside in the switcher engine's primary backend infrastructure, thereby reducing the risk of credential exposure in the event of a backend compromise.

[0290]

[0222] As illustrated in FIG. 24, the system architecture may comprise both client-side and server-side validation of authentication sessions 2431. In some authentication flows where the merchant's native webview is used, authentication cookies, session tokens, and JWTs obtained from the merchant system may be initially validated on the client side (within the SDK or frontend application running on the user's device). This client-side validation allows the frontend to determine whether the user's session is still active and whether additional authentication steps are required. In some embodiments, the system architecture has been enhanced to additionally stream authentication cookies and session tokens from the client-side SDK to the switcher engine backend, where server-side validation is performed. The backend receives the cookies or tokens and validates them against the merchant system's authentication endpoints or against cached session state. Server-side validation provides additional security benefits by allowing the backend to detect expired sessions, revoked tokens, or potentially compromised credentials, and to trigger re-authentication flows as needed. The dual validation approach — combining clientside responsiveness with server-side security checks — improves over conventional single-point validation systems by providing defense-in-depth and reducing the risk of session hijacking or token replay attacks.

[0291]

[0223] In some embodiments, particularly for desktop-based implementations, the payment account switcher engine may employ an alternative authentication mechanism using Virtual Network Computing (VNC) video streaming. In this flow, instead of rendering a merchant webview or collecting credentials, the system establishes a VNC connection to a remote session where the merchant's website is loaded and displayed. The user interacts with the merchant's login page through the VNC video stream, entering credentials and completing authentication steps as if they were directly accessing the merchant's website. The VNC-based approach provides technical benefits for desktop environments where webview embedding may be restricted or where enhanced security isolation is desired. The VNC session is ephemeral and is terminated immediately after authentication is complete, with only the resulting session tokens or authentication status being captured and forwarded to the switcher engine backend. This approach ensures that credentials are entered in an isolated environment and are not transmitted through or stored by the switcher engine's infrastructure.AttyDktNo.: 66416-702601

[0292]

[0224] The system architecture shown in FIG. 24 may include bidirectional authentication session flow between the backend and the client-side SDK. When a user initiates a payment account switching operation, the backend creates or retrieves a session identifier that is transmitted to the SDK. The SDK uses this session identifier to initialize the user interface and to authenticate subsequent API calls to the backend. The session identifier may be a cryptographically signed token (e.g., JWT) that contains user context information such as user ID, session expiration time, and granted permissions. The backend validates the session identifier on each API call to ensure that the request originates from an authorized session and has not been tampered with or replayed by an attacker. This session management approach integrates with the broader secure enclave architecture by ensuring that session tokens are validated before sensitive operations (e.g., transmitting ciphertext references to the secure enclave) are permitted.

[0293]

[0225] The secure enclave architecture and multi-component security infrastructure described herein provide numerous technical benefits and improvements over conventional payment account management systems. The zero knowledge architecture ensures that the primary backend systems of the payment account switcher engine never have access to plaintext cardholder data or user credentials, thereby dramatically reducing the attack surface and potential impact of a backend compromise. This architectural principle represents a fundamental departure from conventional systems where backend services typically have access to sensitive data during processing, storage, or transmission operations. The use of isolated secure enclaves with hardware or cryptographic enforcement mechanisms provides improved security against insider threats and sophisticated attacks. By confining all sensitive data operations to cryptographically isolated environments that cannot be accessed even by authorized system administrators, the architecture eliminates entire classes of vulnerabilities that arise from privileged access abuse or credential theft. The secure enclave isolation is enforced at multiple levels including process isolation, memory encryption, cryptographic key separation, and network segmentation, ensuring that compromise of any single component does not expose the sensitive data processed within the enclave. The support of JSON Web Encryption (JWE) encryption and Payment Card Industry (PCI) proxy tokenization allows the system to integrate with diverse financial institution and payment processor infrastructures while maintaining consistent security guarantees. This flexibility enables financial institutions to leverage their existing security investments and compliance frameworks, whether they have established public key infrastructure for direct encryption or existing relationships with PCI compliant tokenization service providers. The ability to support multiple integration paths without compromising security properties reduces barriers to adoption and accelerates deployment across heterogeneous banking environments.AttyDktNo.: 66416-702601

[0294]

[0226] The credential relay and enclave based authentication architecture ensures that even in cases where passwords must be collected, they are never stored or processed by the main backend infrastructure. User credentials captured by the frontend interface are transmitted directly to the secure enclave via encrypted relay mechanisms, and the backend receives only opaque credential references that can be used to trigger authentication operations within the enclave. This architectural pattern provides protection against credential harvesting attacks targeting backend databases or API endpoints, as attackers who compromise backend systems gain no access to plaintext passwords or authentication secrets. The support for multiple authentication methods tailored to different merchant system capabilities represents a significant technical advancement that enables universal merchant coverage while maintaining security and user experience standards. The system architecture supports native merchant webview authentication for the majority of merchant integrations, allowing users to authenticate using the merchant's own login interface with support for single sign on, biometric authentication, multi factor authentication, and other modem authentication methods. This native webview approach ensures compatibility with diverse merchant authentication systems without requiring the switcher engine to implement merchant specific authentication logic. For merchant systems that do not support embedded webview authentication or that require credential based authentication, the system provides secure credential relay through the isolated enclave, ensuring that credentials are handled securely even in non standard authentication scenarios. For desktop environments where webview embedding may face technical or security constraints, the system provides an innovative Virtual Network Computing (VNC) based authentication flow that allows users to interact with merchant login pages through a video stream of an isolated browser session. This multi method authentication capability ensures that the payment account switcher engine can successfully authenticate users across the full spectrum of merchant systems encountered in practice, from modem web applications with advanced authentication frameworks to legacy systems with traditional username and password authentication, without compromising security or requiring manual intervention for each merchant integration.

[0295] Machine Learning

[0296]

[0227] As used herein, the terms “artificial intelligence,” “artificial intelligence techniques,” “artificial intelligence operation,” and “artificial intelligence algorithm” generally refer to any system or computational procedure that may take one or more actions to enhance or maximize a chance of achieving a goal. The term “artificial intelligence” may include “generative modeling,” “machine learning” (ML), or “reinforcement learning” (RL).Atty Dkt No.: 66416-702601

[0297]

[0228] As used herein, the terms “machine learning,” “machine learning techniques,” “machine learning operation,” and “machine learning model” generally refer to any system or analytical or statistical procedure that may progressively improve computer performance of a task. In some cases, machine learning may generally involve identifying and recognizing patterns in existing data in order to facilitate making predictions for subsequent data. Machine learning may include a machine learning model (which may include, for example, a machine learning algorithm). Machine learning, whether analytical or statistical in nature, may provide deductive or abductive inference based on real or simulated data. The machine learning model may be a trained model. Machine learning (ML) may comprise one or more supervised, semi-supervised, self-supervised, or unsupervised machine learning techniques. For example, an ML model may be a trained model that is trained through supervised learning (e.g., various parameters are determined as weights or scaling factors). ML may comprise one or more of regression analysis, regularization, classification, dimensionality reduction, ensemble learning, meta learning, association rule learning, cluster analysis, anomaly detection, deep learning, or ultra-deep learning. ML may comprise, but is not limited to: k-means, k-means clustering, k-nearest neighbors, learning vector quantization, linear regression, non-linear regression, least squares regression, partial least squares regression, logistic regression, stepwise regression, multivariate adaptive regression splines, ridge regression, principal component regression, least absolute shrinkage and selection operation, least angle regression, canonical correlation analysis, factor analysis, independent component analysis, linear discriminant analysis, multidimensional scaling, non-negative matrix factorization, principal components analysis, principal coordinates analysis, projection pursuit, Sammon mapping, t-distributed stochastic neighbor embedding, AdaBoosting, boosting, gradient boosting, bootstrap aggregation, ensemble averaging, decision trees, conditional decision trees, boosted decision trees, gradient boosted decision trees, random forests, stacked generalization, Bayesian networks, Bayesian belief networks, naive Bayes, Gaussian naive Bayes, multinomial naive Bayes, hidden Markov models, hierarchical hidden Markov models, support vector machines, encoders, decoders, auto-encoders, stacked auto-encoders, perceptrons, multi-layer perceptrons, artificial neural networks, feedforward neural networks, convolutional neural networks, recurrent neural networks, long short-term memory, deep belief networks, deep Boltzmann machines, deep convolutional neural networks, deep recurrent neural networks, or generative adversarial networks.

[0298]

[0229] Training the machine learning model may include, in some cases, selecting one or more untrained data models to train using a training data set. The selected untrained data models may include any type of untrained machine learning models for supervised, semi-supervised, selfAttyDktNo.: 66416-702601

[0299] supervised, or unsupervised machine learning. The selected untrained data models be specified based upon input (e.g., user input) specifying relevant parameters to use as predicted variables or other variables to use as potential explanatory variables. For example, the selected untrained data models may be specified to generate an output (e.g., a prediction) based upon the input.

[0300] Conditions for training the machine learning model from the selected untrained data models may likewise be selected, such as limits on the machine learning model complexity or limits on the machine learning model refinement past a certain point. The machine learning model may be trained (e.g., via a computer system such as a server) using the training data set. In some cases, a first subset of the training data set may be selected to train the machine learning model. The selected untrained data models may then be trained on the first subset of training data set using appropriate machine learning techniques, based upon the type of machine learning model selected and any conditions specified for training the machine learning model. In some cases, due to the processing power requirements of training the machine learning model, the selected untrained data models may be trained using additional computing resources (e.g., cloud computing resources). Such training may continue, in some cases, until at least one aspect of the machine learning model is validated and meets selection criteria to be used as a predictive model.

[0301]

[0230] In some cases, one or more aspects of the machine learning model may be validated using a second subset of the training data set (e.g., distinct from the first subset of the training data set) to determine accuracy and robustness of the machine learning model. Such validation may include applying the machine learning model to the second subset of the training data set to make predictions derived from the second subset of the training data. The machine learning model may then be evaluated to determine whether performance is sufficient based upon the derived predictions. The sufficiency criteria applied to the machine learning model may vary depending upon the size of the training data set available for training, the performance of previous iterations of trained models, or user-specified performance requirements. If the machine learning model does not achieve sufficient performance, additional training may be performed. Additional training may include refinement of the machine learning model or retraining on a different first subset of the training dataset, after which the new machine learning model may again be validated and assessed. When the machine learning model has achieved sufficient performance, in some cases, the machine learning may be stored for present or future use. The machine learning model may be stored as sets of parameter values or weights for analysis of further input (e.g., further relevant parameters to use as further predicted variables, further explanatory variables, further user interaction data, etc.), which may also include analysis logicAttyDktNo.: 66416-702601

[0302] or indications of model validity in some instances. In some cases, a plurality of machine learning models may be stored for generating predictions under different sets of input data conditions. In some embodiments, the machine learning model may be stored in a database (e.g., associated with server). As an example of training a model for generating the list of merchants that are commonly used to the consumer so that the consumer can select which merchants they want to switch the POF, a dataset (e.g., purchase data, category labels, merchants, etc.) may be tokenized to match the model, then backpropagation is used to compute gradients of a loss function (e.g., CrossEntropyLoss) with respect to the model's parameters, and then update the parameters to reduce the loss. In some cases, algorithms such as gradient checkpointing and mixed precision training (e.g., fp 16 / bfl 6) may be employed to manage memory usage. In some cases, the method may employe Low-Rank Adaptation (LoRA) and PEFT (Parameter Efficient Fine-Tuning) methods to backpropagate through fewer parameters.

[0303]

[0231] In some embodiments, the machine learning may be based on a large language model (LLM). An LLM is a type of Al model designed to understand generate human language. These models are built using deep learning techniques, such as transformers, which enable them to capture complex language patterns and relationships. LLMs are trained on massive amounts of text data, such as books, articles, websites, and more, to learn grammar, syntax, semantics, and even some level of common-sense reasoning. They can generate coherent and contextually relevant text, making them highly versatile for a wide range of language processing tasks.

[0304] (a) Computer systems

[0305]

[0232] The present disclosure provides computer systems that are programmed to implement methods of the disclosure. FIG. 11 shows a computer system that is programmed or otherwise configured to enable a user to switch the default POF at a merchant system. The computer system 1101 can regulate various aspects of the present disclosure, for example, for communications and logic among the issuer system, the payment account switcher engine, and / or the merchant system. The computer system 1101 can be an electronic device of a user or a computer system that is remotely located with respect to the electronic device.

[0306]

[0233] The computer system 1101 includes a central processing unit (CPU, also “processor” and “computer processor” herein) 1105, which can be a single core or multi core processor, or a plurality of processors for parallel processing. The computer system 1101 also includes memory or memory location 1110 (e.g., random-access memory, read-only memory, flash memory), electronic storage unit 1115 (e.g., hard disk), communication interface 1120 (e.g., network adapter) for communicating with one or more other systems, and peripheral devices 1125, suchAttyDktNo.: 66416-702601

[0307] as cache, other memory, data storage and / or electronic display adapters. The memory 1110, storage unit 1115, interface 1120 and peripheral devices 1125 are in communication with the CPU 1105 through a communication bus (solid lines), such as a motherboard. The storage unit 1115 can be a data storage unit (or data repository) for storing data. The computer system 1101 can be operatively coupled to a computer network (“network”) 1130 with the aid of the communication interface 1120. The network 1130 can be the Internet, an internet and / or extranet, or an intranet and / or extranet that is in communication with the Internet. The network 1130 in some cases is a telecommunication and / or data network. The network 1130 can include one or more computer servers, which can enable distributed computing, such as cloud computing. The network 1130, in some cases with the aid of the computer system 1101, can implement a peer-to-peer network, which may enable devices coupled to the computer system 1101 to behave as a client or a server.

[0308]

[0234] The CPU 1105 can execute a sequence of machine-readable instructions, which can be embodied in a program or software. The instructions may be stored in a memory location, such as the memory 1110. The instructions can be directed to the CPU 1105, which can subsequently program or otherwise configure the CPU 1105 to implement methods of the present disclosure. Examples of operations performed by the CPU 1105 can include fetch, decode, execute, and writeback.

[0309]

[0235] The CPU 1105 can be part of a circuit, such as an integrated circuit. One or more other components of the system 1101 can be included in the circuit. In some cases, the circuit is an application specific integrated circuit (ASIC).

[0310]

[0236] The storage unit 1115 can store files, such as drivers, libraries, and saved programs. The storage unit 1115 can store user data, e.g., user preferences and user programs. The computer system 1101 in some cases can include one or more additional data storage units that are external to the computer system 1101, such as located on a remote server that is in communication with the computer system 1101 through an intranet or the Internet.

[0311]

[0237] The computer system 1101 can communicate with one or more remote computer systems through the network 1130. For instance, the computer system 1101 can communicate with a remote computer system of a user (e.g., a mobile device). Examples of remote computer systems include personal computers (e.g., portable PC), slate or tablet PC’s (e.g., Apple® iPad, Samsung® Galaxy Tab), telephones, smart phones (e.g., Apple® iPhone, Android-enabled device, Blackberry®), or personal digital assistants. The user can access the computer system 1101 via the network 1130.AttyDktNo.: 66416-702601

[0312]

[0238] Methods as described herein can be implemented by way of machine (e.g., computer processor) executable code stored on an electronic storage location of the computer system 1101, such as, for example, on the memory 1110 or electronic storage unit 1115. The machine executable or machine-readable code can be provided in the form of software. During use, the code can be executed by the processor 1105. In some embodiments, the code can be retrieved from the storage unit 1115 and stored on the memory 1110 for ready access by the processor 1105. In some embodiments, the electronic storage unit 1115 can be precluded, and machineexecutable instructions are stored on memory 1110.

[0313]

[0239] The code can be pre-compiled and configured for use with a machine having a processer adapted to execute the code or can be compiled during runtime. The code can be supplied in a programming language that can be selected to enable the code to execute in a pre-compiled or as-compiled fashion.

[0314]

[0240] Aspects of the systems and methods provided herein, such as the computer system 1101, can be embodied in programming. Various aspects of the technology may be thought of as “products” or “articles of manufacture” typically in the form of machine (or processor) executable code and / or associated data that is carried on or embodied in a type of machine readable medium. Machine-executable code can be stored on an electronic storage unit, such as memory (e.g., read-only memory, random-access memory, flash memory) or a hard disk.

[0315] “Storage” type media can include any or all of the tangible memory of the computers, processors or the like, or associated modules thereof, such as various semiconductor memories, tape drives, disk drives and the like, which may provide non-transitory storage at any time for the software programming. All or portions of the software may at times be communicated through the Internet or various other telecommunication networks. Such communications, for example, may enable loading of the software from one computer or processor into another, for example, from a management server or host computer into the computer platform of an application server. Thus, another type of media that may bear the software elements includes optical, electrical, and electromagnetic waves, such as used across physical interfaces between local devices, through wired and optical landline networks and over various air-links. The physical elements that carry such waves, such as wired or wireless links, optical links, or the like, also may be considered as media bearing the software. As used herein, unless restricted to non-transitory, tangible “storage” media, terms such as computer or machine “readable medium” refer to any medium that participates in providing instructions to a processor for execution.AttyDktNo.: 66416-702601

[0316]

[0241] Hence, a machine readable medium, such as computer-executable code, may take many forms, including but not limited to, a tangible storage medium, a carrier wave medium or physical transmission medium. Non-volatile storage media include, for example, optical or magnetic disks, such as any of the storage devices in any computer(s) or the like, such as may be used to implement the databases, etc., shown in the drawings. Volatile storage media include dynamic memory, such as main memory of such a computer platform. Tangible transmission media include coaxial cables; copper wire and fiber optics, including the wires that comprise a bus within a computer system. Carrier-wave transmission media may take the form of electric or electromagnetic signals, or acoustic or light waves such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media therefore include for example: a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD or DVD-ROM, any other optical medium, punch cards paper tape, any other physical storage medium with patterns of holes, a RAM, a ROM, a PROM and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave transporting data or instructions, cables or links transporting such a carrier wave, or any other medium from which a computer may read programming code and / or data. Many of these forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to a processor for execution.

[0317]

[0242] The computer system 1101 can include or be in communication with an electronic display 1135 that comprises a user interface (UI) 1140 for providing, for example, a dashboard. Examples of UI’s include, without limitation, a graphical user interface (GUI) and web-based user interface.

[0318]

[0243] Methods and systems of the present disclosure can be implemented by way of one or more algorithms. An algorithm can be implemented by way of software upon execution by the central processing unit 1105.

[0319] Computer program

[0320]

[0244] In some embodiments, the platforms, systems, media, and methods disclosed herein include at least one computer program, or use of the same. A computer program includes a sequence of instructions, executable by one or more processor(s) of the computing device’s CPU, written to perform a specified task. Computer readable instructions may be implemented as program modules, such as functions, objects, Application Programming Interfaces (APIs), computing data structures, and the like, which perform particular tasks or implement particularAttyDktNo.: 66416-702601

[0321] abstract data types. In light of the disclosure provided herein, those of skill in the art will recognize that a computer program may be written in various versions of various languages.

[0322]

[0245] The functionality of the computer readable instructions may be combined or distributed as desired in various environments. In some embodiments, a computer program comprises one sequence of instructions. In some embodiments, a computer program comprises a plurality of sequences of instructions. In some embodiments, a computer program is provided from one location. In other embodiments, a computer program is provided from a plurality of locations. In various embodiments, a computer program includes one or more software modules. In various embodiments, a computer program includes, in part or in whole, one or more web applications, one or more mobile applications, one or more standalone applications, one or more web browser plug-ins, extensions, add-ins, or add-ons, or combinations thereof.

[0323] Web application

[0324]

[0246] In some embodiments, a computer program includes a web application. In light of the disclosure provided herein, those of skill in the art will recognize that a web application, in various embodiments, utilizes one or more software frameworks and one or more database systems. In some embodiments, a web application is created upon a software framework such as Microsoft .NET or Ruby on Rails (RoR). In some embodiments, a web application utilizes one or more database systems including, by way of non-limiting examples, relational, non-relational, object oriented, associative, XML, and document-oriented database systems. In further embodiments, suitable relational database systems include, by way of non-limiting examples, Microsoft SQL Server, mySQL, and Oracle. Those of skill in the art will also recognize that a web application, in various embodiments, is written in one or more versions of one or more languages. A web application may be written in one or more markup languages, presentation definition languages, client-side scripting languages, server-side coding languages, database query languages, or combinations thereof. In some embodiments, a web application is written to some extent in a markup language such as Hypertext Markup Language (HTML), Extensible Hypertext Markup Language (XHTML), or extensible Markup Language (XML). In some embodiments, a web application is written to some extent in a presentation definition language such as Cascading Style Sheets (CSS). In some embodiments, a web application is written to some extent in a client-side scripting language such as Asynchronous JavaScript and XML (AJAX), Flash ActionScript, JavaScript, or Silverlight. In some embodiments, a web application is written to some extent in a server-side coding language such as Active Server Pages (ASP), ColdFusion, Perl, Java, JavaServer Pages (JSP), Hypertext Preprocessor (PHP), Python, Ruby,AttyDktNo.: 66416-702601

[0325] Tel, Smalltalk, WebDNA, or Groovy. In some embodiments, a web application is written to some extent in a database query language such as Structured Query Language (SQL). In some embodiments, a web application integrates enterprise server products such as IBM Lotus Domino. In some embodiments, a web application includes a media player element. In various further embodiments, a media player element utilizes one or more of many suitable multimedia technologies including, by way of non-limiting examples, Adobe Flash, HTML 5, Apple QuickTime, Microsoft Silverlight, Java, and Unity.

[0326] Mobile application

[0327]

[0247] In some embodiments, a computer program includes a mobile application provided to a mobile computing device. In some embodiments, the mobile application is provided to a mobile computing device at the time it is manufactured. In other embodiments, the mobile application is provided to a mobile computing device via the computer network described herein.

[0328]

[0248] In view of the disclosure provided herein, a mobile application is created by techniques known to those of skill in the art using hardware, languages, and development environments known to the art. Those of skill in the art will recognize that mobile applications are written in several languages. Suitable programming languages include, by way of non-limiting examples, C, C++, C#, Objective-C, Java, JavaScript, Pascal, Object Pascal, Python, Ruby, VB.NET, WML, and XHTML / HTML with or without CSS, or combinations thereof.

[0329]

[0249] Suitable mobile application development environments are available from several sources. Commercially available development environments include, by way of non-limiting examples, AirplaySDK, alcheMo, Appcelerator, Celsius, Bedrock, Flash Lite, .NET Compact Framework, Rhomobile, and WorkLight Mobile Platform. Other development environments are available without cost including, by way of non-limiting examples, Lazarus, MobiFlex, MoSync, and Phonegap. Also, mobile device manufacturers distribute software developer kits including, by way of non-limiting examples, iPhone and iPad (iOS) SDK, Android SDK, BlackBerry SDK, BREW SDK, Palm OS SDK, Symbian SDK, webOS SDK, and Windows Mobile SDK.

[0330] Standalone application

[0331]

[0250] In some embodiments, a computer program includes a standalone application, which is a program that is run as an independent computer process, not an add-on to an existing process, e.g., not a plug-in. Those of skill in the art will recognize that standalone applications are often compiled. A compiler is a computer program(s) that transforms source code written in a programming language into binary object code such as assembly language or machine code. Suitable compiled programming languages include, by way of non-limiting examples, C, C++,AttyDktNo.: 66416-702601

[0332] Objective-C, COBOL, Delphi, Eiffel, Java, Lisp, Visual Basic, and VB .NET, or combinations thereof. Compilation is often performed, at least in part, to create an executable program. In some embodiments, a computer program includes one or more executable complied applications.

[0333] Software modules

[0334]

[0251] In some embodiments, the platforms, systems, media, and methods disclosed herein include software, server, and / or database modules, or use of the same. In view of the disclosure provided herein, software modules are created by techniques known to those of skill in the art using machines, software, and languages known to the art. The software modules disclosed herein are implemented in a multitude of ways. In various embodiments, a software module comprises a file, a section of code, a programming object, a programming structure, a distributed computing resource, a cloud computing resource, or combinations thereof. In further various embodiments, a software module comprises a plurality of files, a plurality of sections of code, a plurality of programming objects, a plurality of programming structures, a plurality of distributed computing resources, a plurality of cloud computing resources, or combinations thereof. In various embodiments, the one or more software modules comprise, by way of non-limiting examples, a web application, a mobile application, a standalone application, and a distributed or cloud computing application. In some embodiments, software modules are in one computer program or application. In other embodiments, software modules are in more than one computer program or application. In some embodiments, software modules are hosted on one machine. In other embodiments, software modules are hosted on more than one machine. In further embodiments, software modules are hosted on a distributed computing platform such as a cloud computing platform. In some embodiments, software modules are hosted on one or more machines in one location. In other embodiments, software modules are hosted on one or more machines in more than one location.

[0335] Databases

[0336]

[0252] In some embodiments, the platforms, systems, media, and methods disclosed herein include one or more databases, or use of the same. In view of the disclosure provided herein, those of skill in the art will recognize that many databases are suitable for storage and retrieval of, by way of examples, image, cell state, protocol, and culture condition information. In various embodiments, suitable databases include, by way of non-limiting examples, relational databases, non-relational databases, object-oriented databases, object databases, entity-relationship model databases, associative databases, XML databases, document-oriented databases, and graph databases. Further non-limiting examples include SQL, PostgreSQL, MySQL, Oracle, DB2,AttyDktNo.: 66416-702601

[0337] Sybase, and MongoDB. In some embodiments, a database is Internet-based. In further embodiments, a database is web-based. In still further embodiments, a database is cloud computing-based. In a particular embodiment, a database is a distributed database. In other embodiments, a database is based at least in part on one or more local computer storage devices.

[0338]

[0253] While preferred embodiments of the present disclosure have been shown and described herein, it will be obvious to those skilled in the art that such embodiments are provided by way of example only. It is not intended that the present disclosure be limited by the specific examples provided within the specification. While the embodiments of the present disclosure have been described with reference to the aforementioned specification, the descriptions and illustrations of the embodiments herein are not meant to be construed in a limiting sense. Numerous variations, changes, and substitutions will now occur to those skilled in the art without departing from the embodiments of the present disclosure. Furthermore, it shall be understood that all aspects of the present disclosure are not limited to the specific depictions, configurations or relative proportions set forth herein which depend upon a variety of conditions and variables. It should be understood that various alternatives to the embodiments of the present disclosure described herein may be employed in practicing the embodiments of the present disclosure. It is therefore contemplated that the present disclosure shall also cover any such alternatives, modifications, variations, or equivalents. It is intended that the following claims define the scope of the invention(s) and that methods and structures within the scope of these claims and their equivalents be covered thereby.

Claims

AttyDktNo.: 66416-702601CLAIMS WHAT IS CLAIMED IS:

1. A computer-implemented system for managing and updating a default payment-account- on-file (POF) for a user on a merchant system, comprising:a backend engine configured to:(a) transmit a payment context identifier to a payment service provider (PSP), wherein the PSP is configured to provide one or more payment instruments associated with a user account with the PSP;(b) in response to the user selecting a payment instrument, obtain from a payment processor a payment token that is cryptographically bound to at least the merchant, the user account with the PSP, or a limited time-to-live (TTL); and(c) update the merchant’s default payment option on file based on an approved payment context generated upon authorization of the selected payment instrument, and provide a confirmation of the update to a frontend application.

2. The system of claim 1, wherein the approved payment context comprises at least one of the payment context identifier, a pointer to the vaulted payment token, a merchant identifier, the user account identifier, an authorization status, and the limited time-to-live (TTL).

3. The system of claim 1, wherein the backend engine is further configured to transmit the approved payment context to the merchant system through a secure API call.

4. A computer-implemented method for securely updating a payment option on file at a merchant system, comprising:(a) receiving, by a backend, a request to update a default payment option associated with a user account at a merchant;(b) transmitting, by the backend, a payment context identifier to a payment service provider system;(c) authenticating, by the payment service provider system, ownership of a payment instrument associated with the user account;(d) generating, by the payment service provider system, a cryptographically signed approved payment context comprising a user account binding, a merchant domain binding, a reference to a processor-issued payment token, an authorization status, a time-to-liveAttyDktNo.: 66416-702601parameter, or one or more cryptographic signatures that attest to authorization of the payment instrument;(e) transmitting, by the backend, the approved payment context to the merchant system;(f) updating the default payment option on file upon validating the cryptographic signature of the approved payment context.

5. The computer-implemented method of claim 4, further comprising vaulting, by the merchant system, the processor-issued payment token and updating the default payment option on file using the vaulted processor-issued payment token.

6. The method of claim 4, wherein the approved payment context is a digitally signed capability object.

7. The method of claim 4, wherein the approved payment context cryptographically binds the payment token to a permitted merchant domain.

8. The method of claim 4, wherein the merchant system stores token references without storing raw payment credentials.

9. The method of claim 4, wherein the approved payment context is reusable across multiple merchant systems subject to domain restrictions embedded within the approved payment context.

10. The method of claim 4, further comprising, validating, by the merchant system, the cryptographic signatures of approved payment contexts and update default payment options using the processor-issued payment token.

11. A computer-implemented method for subscription management, comprising:(a) receiving, at a backend component, a request associated with a user to access subscription data for one or more third-party merchants;(b) generating a programmatic session identifier that is owned by the backend component;(c) authenticating, by the backend component, to each respective third-party merchant using a credential associated with a user account with the respective third-party merchant, and establishing a session that is bound to the programmatic session identifier;(d) retrieving, under a control of the programmatic session identifier, a subscription metadata comprising a subscription tier, a billing cycle, a renewal date, or a payment method;(e) causing at least a portion of the subscription metadata to be displayed on a graphical user interface;AttyDktNo.: 66416-702601(f) receiving, via the graphical user interface, a subscription management instruction comprising at least one of canceling, pausing, upgrading, downgrading, creating a subscription or rebinding a payment card for a subscription; and(g) executing, by the backend component and through the session, a corresponding application programming interface (API) call to effect the subscription management instruction.

12. The method of claim 11, wherein the programmatic session identifier is maintained by the backend component and is not forwarded from a browser of the user.

13. The method of claim 11, wherein the programmatic session identifier represents a scoped authorization binding that specifies permitted subscription operations and an expiration policy.

14. The method of claim 11, wherein the subscription metadata is retrieved via a merchant API.

15. The method of claim 11, wherein the session is a server-side merchant session and the backend component is configured to refresh the server-side merchant session using token refresh flows without requiring re-authentication by the user.

16. The method of claim 11, wherein the credential associated with a user account is stored in a secure vault.

17. The method of claim 16, wherein the credential is cryptographically inaccessible to a user device.

18. The method of claim 11, wherein the graphical user interface displays an option for one- tap card rebinding or subscription creation using the programmatic session identifier.

19. A computer implemented method for securely switching a default payment option on file with a merchant system, the method comprising:receiving, at a backend, encrypted cardholder data from a financial institution, wherein the cardholder data is encrypted with a public key, and wherein a corresponding private key for decrypting the encrypted cardholder data is held by a secure enclave and is not accessible to the payment account switcher engine backend;transmitting the encrypted cardholder data from the backend to the secure enclave without decrypting the cardholder data at the backend;receiving, at the backend from the secure enclave, a reference corresponding to the cardholder data, wherein the reference is an opaque identifier that cannot be used by the backend to access plaintext cardholder data;AttyDktNo.: 66416-702601receiving, at the backend, a user selection indicating a merchant system with which to update a default payment option on file; andtransmitting, from the secure enclave to the merchant system, a plaintext cardholder data via a secure communication channel, wherein the plaintext cardholder data is retrieved by decrypting the reference within the secure enclave.

20. The computer implemented method of claim 19, further comprising receiving, at the secure enclave from the merchant system, a provisioning status response indicating whether the cardholder data was successfully stored as the default payment option on file.

21. The computer implemented method of claim 20, further comprising transmitting, from the secure enclave to the backend, the provisioning status response without including the plaintext cardholder data.

22. The computer implemented method of claim 21, further comprising transmitting, from the backend to a user device, a confirmation interface indicating that the default payment option on file has been updated with the merchant system.

23. The computer implemented method of claim 19, wherein the backend does not have access to the plaintext cardholder data.

Images