Patent Description:
Websites, such as e-commerce websites, may not be trusted by a user and/or financial institution. Even where a third-party website integrates elements from a trusted service, sensitive account information may be compromised by an insecure connection, a spoofed or faked trusted service, a man-in-the-middle (MitM) attack, and/or the like. In the MitM attack, for example, payment information may be viewed and/or updated by another entity not intended to be involved in a payment transaction. As a result, it may be difficult for entities involved in the payment transaction (e.g., the user, the financial institution, the merchant, and/or the like) to determine whether the data received was viewed or updated by the entity not intended to be involved in the payment transaction.

<CIT> describes a secure iframe and a combination of security elements that are used in rendering a web page of a content provider. <CIT> describes a system and method that provides trusted commerce functionality on an untrusted website. <CIT> describes providing an inline frame and secure cross domain messaging for collecting sensitive payment data regarding access to monies held for an end user. <CIT> describes providing, by a third party, input form fields for sensitive data on a web page provided by an organization. <CIT> describes processing transactions involving sensitive information, such as a credit card number.

According to a first aspect, there is provided a computer-implemented method as defined in appended claim <NUM>. According to a second aspect, there is provided a system as defined in appended claim <NUM>.

Additional advantages and details of the invention are explained in greater detail below with reference to the exemplary embodiments that are illustrated in the accompanying schematic figures, in which:.

For purposes of the description hereinafter, the terms "end," "upper," "lower," "right," "left," "vertical," "horizontal," "top," "bottom," "lateral," "longitudinal," and derivatives thereof shall relate to the embodiments as they are oriented in the drawing figures. However, it is to be understood that the embodiments may assume various alternative variations and step sequences, except where expressly specified to the contrary. It is also to be understood that the specific devices and processes illustrated in the attached drawings, and described in the following specification, are simply exemplary embodiments or aspects of the present disclosure. Hence, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed herein are not to be considered as limiting.

No aspect, component, element, structure, act, step, function, instruction, and/or the like used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more" and "at least one. " Furthermore, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, a combination of related and unrelated items, and/or the like) and may be used interchangeably with "one or more" or "at least one. " Where only one item is intended, the term "one" or similar language is used. Also, as used herein, the terms "has," "have," "having," or the like are intended to be open-ended terms. Further, the phrase "based on" is intended to mean "based at least partially on" unless explicitly stated otherwise.

As used herein, the term "communication" may refer to the reception, receipt, transmission, transfer, provision, and/or the like, of data (e.g., information, signals, messages, instructions, commands, and/or the like). For one unit (e.g., a device, a system, a component of a device or system, combinations thereof and/or the like) to be in communication with another unit means that the one unit is able to directly or indirectly receive information from and/or transmit information to the other unit. This may refer to a direct or indirect connection (e.g., a direct communication connection, an indirect communication connection, and/or the like) that is wired and/or wireless in nature. Additionally, two units may be in communication with each other even though the information transmitted may be modified, processed, relayed, and/or routed between the first and second unit. For example, a first unit may be in communication with a second unit even though the first unit passively receives information and does not actively transmit information to the second unit. As another example, a first unit may be in communication with a second unit if at least one intermediary unit processes information received from the first unit and communicates the processed information to the second unit.

As used herein, the term "computing device" may refer to one or more electronic devices configured to process data. A computing device may, in some examples, include the necessary components to receive, process, and output data, such as a processor, a display, a memory, an input device, a network interface, and/or the like. A computing device may be a mobile device. As an example, a mobile device may include a cellular phone (e.g., a smartphone or standard cellular phone), a portable computer, a wearable device (e.g., watches, glasses, lenses, clothing, and/or the like), a personal digital assistant (PDA), and/or other like devices. A computing device may also be a desktop computer or other form of non-mobile computer.

As used herein, the term "server" may refer to or include one or more computing devices that are operated by or facilitate communication and processing for multiple parties in a network environment, such as the Internet, although it will be appreciated that communication may be facilitated over one or more public or private network environments and that various other arrangements are possible. Further, multiple computing devices (e.g., servers, point-of-sale (POS) devices, mobile devices, etc.) directly or indirectly communicating in the network environment may constitute a "system. " Reference to "a server" or "a processor," as used herein, may refer to a previously-recited server and/or processor that is recited as performing a previous step or function, a different server and/or processor, and/or a combination of servers and/or processors. For example, as used in the specification and the claims, a first server and/or a first processor that is recited as performing a first step or function may refer to the same or different server and/or a processor recited as performing a second step or function.

As used herein, the term "transaction service provider" may refer to an entity that receives transaction authorization requests from merchants or other entities and provides guarantees of payment, in some cases through an agreement between the transaction service provider and an issuer institution. For example, a transaction service provider may include a payment network such as Visa® or any other entity that processes transactions. The term "transaction processing system" may refer to one or more computing devices operated by or on behalf of a transaction service provider, such as a transaction processing server executing one or more software applications. A transaction processing system may include one or more processors and, in some embodiments, may be operated by or on behalf of a transaction service provider.

As used herein, the term "issuer institution" may refer to one or more entities, such as a bank, that provide accounts to customers for conducting transactions (e.g., payment transactions), such as initiating credit and/or debit payments. For example, an issuer institution may provide an account identifier, such as a primary account number (PAN), to a customer that uniquely identifies one or more accounts associated with that customer. The account identifier may be embodied on a payment device, such as a physical financial instrument, e.g., a payment card, and/or may be electronic and used for electronic payments. The term "issuer system" refers to one or more computing devices operated by or on behalf of an issuer institution, such as a server computer executing one or more software applications. For example, an issuer system may include one or more authorization servers for authorizing a transaction.

As used herein, the term "payment device" may refer to a payment card (e.g., a credit or debit card), a gift card, a smartcard, smart media, a payroll card, a healthcare card, a wristband, a machine-readable medium containing account information, a keychain device or fob, an RFID transponder, a retailer discount or loyalty card, a cellular phone, an electronic wallet mobile application, a PDA, a pager, a security card, a computing device, an access card, a wireless terminal, a transponder, and/or the like. In some embodiments, the payment device may include volatile or non-volatile memory to store information (e.g., an account identifier, a name of the account holder, and/or the like).

As used herein, the term "account identifier" may include one or more PANs, tokens, or other identifiers associated with a customer account. The term "token" may refer to an identifier that is used as a substitute or replacement identifier for an original account identifier, such as a PAN. Account identifiers may be alphanumeric or any combination of characters and/or symbols. Tokens may be associated with a PAN or other original account identifier in one or more data structures (e.g., one or more databases and/or the like) such that they may be used to conduct a transaction without directly using the original account identifier. In some examples, an original account identifier, such as a PAN, may be associated with a plurality of tokens for different individuals or purposes.

As used herein, the term "merchant" may refer to an individual or entity that provides goods and/or services, or access to goods and/or services, to customers based on a transaction, such as a payment transaction. As used herein, the terms "merchant" or "merchant system" may also refer to one or more computer systems operated by or on behalf of a merchant, such as a server computer executing one or more software applications. As used herein, the term "point-of-sale (POS) system," may refer to one or more computing devices and/or peripheral devices used by a merchant to engage in payment transactions with customers, including one or more card readers, near-field communication (NFC) receivers, RFID receivers, and/or other contactless transceivers or receivers, contact-based receivers, payment terminals, computers, servers, input devices, and/or other like devices that can be used to initiate a payment transaction.

As used herein, the term "payment gateway" may refer to an entity and/or a payment processing system operated by or on behalf of such an entity (e.g., a merchant service provider, a payment service provider, a payment facilitator, a payment facilitator that contracts with an acquirer, a payment aggregator, and/or the like), which provides payment services (e.g., transaction service provider payment services, payment processing services, and/or the like) to one or more merchants. The payment services may be associated with the use of portable financial devices managed by a transaction service provider. As used herein, the term "payment gateway system" may refer to one or more computer systems, computer devices, servers, groups of servers, and/or the like operated by or on behalf of a payment gateway.

As used herein, the term "domain" refers to one or more networks or network hosts within the same physical or logical infrastructure. A domain may be identified by a domain name, a network address, and/or the like.

The systems, methods, and computer program products described herein provide numerous technical advantages in an electronic payment processing network. For example, e-commerce websites hosted by certain merchants may not be as secure as desired due to the technology available to and provided by the merchants. Embodiments described herein provide for secure payment transactions that avoid the technical security flaws and associated risks of existing payment systems, such as an MitM attack. Embodiments provide for a new protocol and process for rendering a webpage for collecting sensitive information in a manner that avoids the typical flow of data through the primary host server and is also verifiable. Embodiments described herein also provide for efficiencies in an electronic payment processing network, such as reduced bandwidth and reduced usage of computational resources resulting from reducing and/or eliminating communications between systems that may be involved in verifying whether a payment transaction is a valid payment transaction or remedying a fraudulent payment transaction (e.g., a payment transaction that was viewed and/or updated by an entity not intended to be involved in the payment transaction).

<FIG> depicts a system <NUM> for securely transmitting data via a third-party webpage <NUM> according to an embodiment. A user device <NUM> associated with a user is used to access a third-party webpage (e.g., merchant webpage <NUM> or other webpage hosted by an untrusted party) through a network environment <NUM>, such as the Internet. The user device <NUM> executes a browser application that is configured to display the merchant webpage <NUM> based on data received from a merchant web server <NUM> and payment web server <NUM> (or some other trusted server). In operation, configuration data is generated for configuring a plurality of frames (e.g., in-line frames) within a merchant webpage <NUM> displayed via the browser application on the user device <NUM>. The configuration data is generated and transmitted by the payment web server <NUM>. In some embodiments, the configuration data is stored in a database <NUM> in communication with the payment web server <NUM> and is transmitted to merchant web server <NUM> from the payment web server <NUM>.

Still referring to <FIG>, the merchant webpage <NUM> includes webpage data from merchant web server <NUM> that is generated based on the configuration data. The configuration data specifies parameters for embedding frames into the merchant webpage <NUM>, including network information (e.g., Domain Name Server (DNS) data and/or a network address) associated with each frame, the size of each frame, the location of each frame, and/or the like. The configuration data may also specify a network address of one or more scripts located at one or more network locations. Merchant web server <NUM> renders the merchant webpage <NUM> on the user device <NUM> operated by the user. In some embodiments, the network information includes DNS data relating to domains associated with the merchant system or webpage. Using the network information that is provided, it can be ensured that the scripts and frames are only executed and accessed by a trusted merchant domain (e.g., a whitelisted domain corresponding to the merchant web server <NUM>).

With continued reference to <FIG>, the merchant webpage <NUM> is displayed on the user device <NUM> with a plurality of browser frames (not shown in <FIG>). In some embodiments, each frame may be associated with one or more input fields or selectable options, such as one or more text fields, buttons, checkboxes, drop-down menus, selection menus, and/or the like. The content of each frame of the plurality of frames is transmitted from a domain that is separate from the merchant web server <NUM>. In the depicted example, the content of the frames is provided by the payment web server <NUM> which is physically and logically separate from the merchant web server <NUM>. For example, each frame may reference an in-line hyperlink for a webpage hosted by the payment web server <NUM> that includes one or more input fields or selectable options. In this manner, multiple communication connections may be established between the user device <NUM> and the payment web server <NUM> via the multiple frames. The merchant webpage <NUM> and/or frame content may prompt a user of the user device <NUM> to input user information (e.g., account information or other sensitive data) into the one or more input fields and/or selectable options that are presented via the frames. In this manner, sensitive user information may be provided directly to the payment web server <NUM> without being accessible by merchant web server <NUM>.

The configuration data is verified such that an entity is unable to intercept packets and/or spoof the payment web server <NUM>. The configuration data is digitally signed after being generated (e.g., the configuration data or data derived therefrom, such as a hash, may be encrypted with a private key corresponding to a public key of a long-standing public/private key pair). By cryptographically signing the configuration data, the configuration data may represent the state of the system through the entire process and a verifiable delivery of the state to the payment web server <NUM> and/or transaction processing system <NUM>. The elements of the configuration data may also be encrypted using a suitable encryption technique. The corresponding public key may be embedded in a script or other data that is provided to the user device <NUM> from the payment web server <NUM> (e.g., via one or more frames embedded in the merchant webpage <NUM>). In this manner, the browser application executing on the user device <NUM> is enabled to verify the configuration data. For example, the encrypted value (e.g., derived from the configuration data) may be verified by a client-side script executed by the user device <NUM> using the corresponding public key such that the merchant web server <NUM> and/or other entities are unable to fake or spoof the configuration data to fraudulently obtain the sensitive user information. In response to determining that the configuration data is not valid (e.g., that it has been corrupted or altered), the payment web server <NUM> may then display an alert message via one or more of the frames and/or prevent sensitive user information from being inputted.

Still referring to <FIG>, once user data and/or other information is inputted into the plurality of frames, the data is transmitted to the payment web server <NUM>. User data may include, for example, account data (e.g., PAN or other account identifier, expiration date, verification code, etc.), name, address, birthdate, and/or any other information that a user may input into the plurality of frames. The data is aggregated and packaged by the browser application on the user device <NUM> before being transmitted. One frame of the plurality of frames coordinates the collection and aggregation of data from each other frame using one or more scripts.

With continued reference to <FIG>, a temporary key is generated by the payment web server <NUM> for use in the transaction. The temporary key is a key from a first public/private key pair that is specific to the transaction. The public key of the key pair is contained within the configuration data and the private key of the key pair may be maintained by the payment web server <NUM>. In this manner, the browser application on the user device <NUM> (e.g., a script executed by the browser) encrypts the user data inputted into the plurality of frames with the public key. In this manner, the user data may only be decrypted by the entity in possession of the private key (e.g., the payment web server <NUM> and/or transaction processing system <NUM>).

Still referring to <FIG>, in embodiments in which the payment web server <NUM> is in possession of the private key, the payment web server <NUM> may decrypt the user data and transmit the decrypted user data to the transaction processing system <NUM>. The transaction processing system <NUM>, after receiving the decrypted user data, may generate a transient token (e.g., a limited use payment token) based on the user data. The transient token (e.g., the transient token itself and/or a reference to the transient token) may then be transmitted to the user device <NUM> via (e.g., through) one or more of the frames on the merchant webpage <NUM> using the connection established between the payment web server <NUM> and the user device <NUM>. The transient token may then be communicated (e.g., passed) from the one or more frames to the merchant web server <NUM> via a script executed by the browser application on the user device <NUM>. Once the merchant web server <NUM> has access to the transient token, the merchant web server <NUM> may generate a transaction request message that includes the transient token.

In some embodiments, the transaction processing system <NUM> may digitally sign the transient token with the private key that was generated as part of the temporary public/private key pair such that the corresponding public key is the public key contained within the configuration data. The transient token, after being digitally signed, may then be verified by the merchant web server <NUM> or other merchant system with the public key that was included in the configuration data. Once the transient token is verified, it can be trusted even after the temporary keys are no longer used.

The transaction request message including the transient token is then transmitted from merchant web server <NUM> or other merchant system to the payment gateway <NUM> and/or transaction processing system <NUM>. The transaction processing system <NUM> may determine user data from the transient token by querying a token management system <NUM>. Once the transaction processing system <NUM> obtains the user data associated with the transient token, the transaction processing system <NUM> generates an authorization request message including the user data and transmits the authorization request message to an issuer system <NUM> for processing.

In some embodiments, and with continued reference to <FIG>, a transaction request may be processed by the payment web server <NUM> and/or transaction processing system <NUM> without use of the database <NUM> storing the configuration data. As a result of cryptographically signing the configuration data with a key of a long-standing key pair (e.g., a second key pair that is used for multiple transactions), the configuration data including the public key of a first key pair (e.g., a temporary key pair generated for the transaction), and the transient token being digitally signed with the private key of the first key pair, the system <NUM>, may operate in a stateless manner. For example, once the configuration data and the transient token are obtained by the transaction processing system <NUM> as part of an authorization request, the transaction may be processed without the need to access the database <NUM>.

<FIG> shows an example in which the system <NUM> is used to conduct payments with a merchant. However, it will be appreciated that embodiments may be implemented to securely transmit data via other third-party webpages. For example, sensitive user data such as healthcare data, financial data, personally identifying data, and/or the like, may be protected using embodiments.

Referring now to <FIG>, a system <NUM> is illustrated for securely transmitting data via a third-party webpage <NUM> according to an embodiment. In this example, the third-party webpage <NUM> is hosted by a third-party server <NUM> that may not be trusted by the user. A trusted server <NUM> transmits configuration data from a database <NUM> to the third-party server <NUM> over the network <NUM> or some other communication path to enable the third-party server <NUM> to render the third-party webpage <NUM> on the user device <NUM>. The third-party webpage <NUM> includes a plurality of frames pointing to the trusted server <NUM> and populated with web content from the trusted server <NUM>, as configured based on the configuration data. As described in connection with <FIG>, the configuration data is digitally signed by the trusted server <NUM> such that it can be verified.

Referring now to <FIG>, shown is a system <NUM> for transmitting data via a third-party webpage <NUM> according to an embodiment. The system <NUM> may include a user device <NUM>, a merchant web server <NUM>, a payment web server <NUM>, a database <NUM>, and a server computer <NUM>. In some embodiments or aspects, the user device <NUM> may be the same as or similar to the user device <NUM>, the merchant web server <NUM> may be the same as or similar to the merchant web server <NUM>, the payment web server <NUM> may be the same as or similar to the payment web server <NUM>, and/or the database <NUM> may be the same as or similar to the database <NUM>.

The user device <NUM> is configured to render the merchant webpage <NUM>, for example, using a web browser application based on data received from the merchant web server <NUM> (e.g., including configuration data as described herein, web content, and/or the like). The merchant webpage <NUM> is rendered with one or more frames 303a, 303b, 303c included therein. For example, the merchant webpage <NUM> may include frames 303a, 303b, and 303c that display web content provided by the payment web server <NUM> and/or some other server (e.g., such as server <NUM>). The frames may be outlined with a border or may seamlessly appear on the webpage <NUM>. To display the merchant webpage <NUM>, the merchant web server <NUM> communicates with the payment web server <NUM> (e.g., in some examples including an Application Programming Interface (API) server associated with the payment web server <NUM>). The merchant web server <NUM> may, for example, provide domain information (e.g., such as DNS information, domain name system addresses, URLs, and/or the like) associated with the merchant webpage <NUM> (e.g., a checkout page).

The payment web server <NUM> or associated system (e.g., an API server or some other server associated with the payment web server <NUM>) then communicates cryptographically signed data (e.g., such as encrypted JSON Web Token (JWT) data) including configuration data specific to the merchant and merchant webpage <NUM>. The configuration data is cryptographically signed with a private key of a long-living (e.g., used for numerous transactions) public/private key pair. The private key may be stored in a hardware security module (HSM) <NUM> associated with the transaction processing system. The configuration data includes a public key of a temporary public/private key pair (e.g., generated and used for a single transaction) and DNS information. The configuration data may also include webpage content and/or style data (e.g., fonts, images, etc.), endpoint configurations (e.g., one or more specific URLs associated with the payment web server <NUM>), and content specific to the transaction context (e.g., 3D-Secure order data).

In response to the merchant web server <NUM> receiving the configuration data from the payment web server <NUM>, the merchant web server <NUM> renders the merchant webpage <NUM> (e.g., a checkout page) on the user device <NUM>. The merchant webpage may include a reference to a Software Development Kit (SDK) <NUM> or other software tools stored, for example, by server computer <NUM> (e.g., as a JavaScript file). The payment web server <NUM> and SDK <NUM> may be protected by Subresource Integrity (SRI), as an example. The browser executed by the user device <NUM> interprets the web content to display the merchant webpage <NUM> and passes execution control to the payment web server <NUM>. The payment web server <NUM> then uses the public key of the long-standing public/private key pair (the private key of which is stored in the HSM <NUM>) to validate the signed configuration data (e.g., ensuring that it was not tampered with, replaced, and/or the like). The payment web server <NUM> then, in response to validating the configuration data, renders the frames 303a, 303b, 303c with content from the payment web server <NUM>. The frame 303c, for example, may be served with a Content Security Policy (CSP) that permits the browser to display the content of the frame 303c only if it is a whitelisted domain specified by the merchant.

With continued reference to <FIG>, the content of the frame 303c may be served from the payment web server <NUM> and/or an associated API server, in which case the domain of the merchant web server <NUM> is known and HTTP CSP headers may be generated. In other embodiments, the content of the frame 303c may be served from the other server <NUM> (e.g., as part of a Content Delivery Network (CDN)), in which case the server <NUM> is provisioned with public key corresponding to the private key of the long-standing public/private key pair (the private key of which is stored in the HSM <NUM>) to validate the configuration data. The other server <NUM> may reflect back the domain names from the configuration data in CSP headers.

During the loading of frame 303c, data may be retrieved from the payment web server <NUM> or other server <NUM> that includes the public key corresponding to the private key of the long-standing public/private key pair (the private key of which is stored in the HSM <NUM>). The digital signature guarantees that all parameters can be trusted without any further communication with the payment web server <NUM>. In response to rendering the content of frame 303c and/or validating the configuration data, the frame 303c establishes communication with other frame(s) (e.g., at least 303b) being hosted by the payment web server <NUM> via the user device <NUM> such that the data never passes through the merchant web server <NUM>. The digitally signed configuration data, including domain information, are used to restrict communication to other frame(s) 303a and/or the merchant webpage <NUM> to prevent any other frame, such as a malicious frame, to receive or transmit any data during the transaction. Moreover, the configuration data may restrict communication between frames 303b, 303c to predefined messages that cannot be used to extract information from the frames 303b, 303c.

Once a user has input data through the frames 303a, 303b, 303c, a script executed within frame 303c aggregates the input by receiving the user data from each frame and collecting it. Frame 303c then uses the public key of the temporary public/private key pair (e.g., generated for the transaction) to generate encrypted data that includes, for example, the user's payment information, such as an account identifier and the like. The encrypted data is then be communicated from the user device <NUM> to the payment web server <NUM> without passing through the merchant web server <NUM>. In response to receiving the encrypted data, the payment web server <NUM> processes it (e.g., decrypts the data), obtains and/or generates a transient token (e.g., a payment token for a one-time or limited use), and communicates the transient token to the merchant web server <NUM> by first communicating the token to the merchant webpage <NUM> on the user device <NUM> (e.g., via frame 303c which passes the token to the merchant webpage <NUM> via the user's web browser), in response to which the merchant webpage <NUM> communicates the token to the merchant web server <NUM> to be used for the payment. The merchant webpage <NUM> may cryptographically sign the payment token with the private key of the temporary public/private key pair (e.g., generated for the transaction) before communicating the token to the merchant web server <NUM>. The merchant web server <NUM>, in response to receiving the signed token, may then utilize the corresponding public key embedded in the configuration data to validate the signed token. The result of this process is that the merchant possesses the valid token that is cryptographically verifiable and both the merchant and the payment web server are able to detect any fraudulent activity by interference through the encryption and digital signature validations.

Referring now to <FIG>, illustrated are sequence and schematic diagrams of a system <NUM> and method for securely transmitting data via a webpage according to embodiments. The system <NUM> includes a user device <NUM>, a merchant web server <NUM>, and a payment web server <NUM>. In some embodiments or aspects, the user device <NUM> may be the same as or similar to the user device <NUM>, the merchant web server <NUM> may be the same as or similar to the merchant web server <NUM>, and/or the payment web server <NUM> may be the same as or similar to the payment web server <NUM>.

At step <NUM>, the payment web server <NUM> may receive a request for configuration data from the merchant web server <NUM>. For example, the payment web server <NUM> may receive a request for configuration data from the merchant web server <NUM> based on the merchant web server <NUM> receiving a request for a merchant webpage from the user device <NUM>. The configuration data is associated with configuring a web browser to display a merchant webpage including one or more frames. In some embodiments, the merchant webpage (e.g., a merchant webpage associated with a merchant and/or hosted by the merchant web server <NUM>) may be associated with a checkout process involved in an online payment transaction involving the user associated with the user device <NUM> and the merchant associated with the merchant web server <NUM>. However, as explained herein, the systems and methods described herein may be used in various other contexts.

At step <NUM>, payment web server <NUM> generates configuration data. The payment web server <NUM> generates configuration data based on the request for configuration data from the merchant web server <NUM>. In some embodiments, the payment web server <NUM> may generate the configuration data based on the merchant web server <NUM>, where the merchant web server <NUM> is a web server associated with a merchant from among a plurality of merchants served by the payment web server <NUM>. Generating the configuration data includes a public key of a temporary public/private key pair generated for a payment transaction that involves the merchant web server <NUM> and the user device <NUM>. In some embodiments or aspects, the public key may be associated with the user device <NUM>.

At step <NUM>, a payment web server <NUM> digitally signs the configuration data using a private key of a long-standing public/private key pair associated with the payment web server <NUM> (e.g., where the private key is a cryptographic key known only to the payment web server <NUM>).

At step <NUM> in <FIG>, the payment web server <NUM> transmits the configuration data to the merchant web server <NUM> based on the merchant web server <NUM> receiving the request for the configuration data. Additionally, or alternatively, the payment web server <NUM> transmits the configuration data to the merchant web server <NUM> based on the payment web server <NUM> generating the configuration data.

At step <NUM> in <FIG>, the merchant web server <NUM> transmits data configured to cause the user device <NUM> to render a merchant webpage through a web browser application or a separate network-enabled application. For example, the merchant web server <NUM> may transmit data configured to cause the user device <NUM> to render a merchant webpage on a display of the user device <NUM> based on the merchant web server <NUM> receiving the configuration data from the payment web server <NUM>.

At step <NUM> in <FIG>, the user device <NUM> verifies the configuration data based on a public key corresponding to the private key of the long-standing public/private key pair associated with the payment web server <NUM>. In some embodiments, the user device <NUM> may verify the configuration data based on the user device <NUM> requesting the public key associated with the payment web server <NUM> from the payment web server <NUM>.

At step <NUM> in <FIG>, the user device <NUM> displays a merchant webpage including a plurality of frames. The user device <NUM> renders a merchant webpage including a plurality of frames based on data received from the merchant web server <NUM>. The plurality of frames include content hosted by one or more domains that are independent of a domain associated with a merchant that provides the main merchant webpage. In some embodiments, the user device <NUM> may receive a public key from the payment web server <NUM> through one of the frames to enable the user device <NUM> to validate the configuration data used to render the page.

At step <NUM> in <FIG>, the user device <NUM> receives encrypted data from a master frame 403c. In some embodiments, the user device <NUM> receives input corresponding to one or more frames associated with the master frame 403c (e.g., one or more frames different from the master frame 403c) and the one or more frames associated with the master frame 403c transmits data associated with the input to the master frame 403c. In this way, data may be aggregated from multiple frames within the frame 403c before being transmitted by the user device <NUM>. It will be appreciated that the frames 403c, 403b, 403a, may also provide non-aggregated data directly to the user device <NUM>.

At step <NUM> in <FIG>, the user device <NUM> transmits the encrypted data associated with input corresponding to one or more frames associated with the master frame to a payment web server <NUM>. For example, the user device <NUM> may transmit the data associated with input corresponding to one or more frames associated with master frame 403c to the payment web server <NUM> via the master frame 403c.

In some embodiments, the payment web server <NUM> may receive a transaction request from the merchant web server <NUM> including the transient token generated based on the token management system receiving data (e.g., data received from the user device <NUM> by the payment web server <NUM>). In some embodiments, the payment web server <NUM> may obtain the data associated with the user device <NUM> from the token management system and the payment web server <NUM> may generate an authorization request based on the data associated with the user device <NUM>. In some embodiments, the token management system may delete the data after an authorization response (e.g., authorizing, not authorizing, and/or the like) is received based on the authorization request.

Referring now to <FIG>, illustrated is a diagram of example components of a device <NUM> according to embodiments. The device <NUM> (e.g., one or more components of the device <NUM>) may correspond to the user device <NUM>, the merchant web server <NUM>, the payment web server <NUM>, the transaction processing system <NUM>, the issuer system <NUM>, the payment gateway <NUM>, the database <NUM>, and/or the token management system <NUM>. In some embodiments or aspects, the device <NUM> (e.g., one or more components of the device <NUM>) may correspond to the third-party server <NUM>, the trusted server <NUM>, the user device <NUM>, the merchant web server <NUM>, the payment web server <NUM>, the database <NUM>, and/or the server computer <NUM>. In some embodiments or aspects, the device <NUM> (e.g., one or more components of the device <NUM>) may correspond to the user device <NUM>, the merchant web server <NUM>, and/or the payment web server <NUM>.

In some embodiments, such systems or devices may include at least one device <NUM> and/or at least one component of the device <NUM>. The number and arrangement of components illustrated are provided as an example. In some embodiments, the device <NUM> may include additional components, fewer components, different components, or differently arranged components than those illustrated in <FIG>. Additionally, or alternatively, a set of components (e.g., one or more components) of the device <NUM> may perform one or more functions described as being performed by another set of components of the device <NUM>.

As illustrated in <FIG>, the device <NUM> may include a bus <NUM>, a processor <NUM>, memory <NUM>, a storage component <NUM>, an input component <NUM>, an output component <NUM>, and a communication interface <NUM>. The bus <NUM> may include a component that permits communication among the components of the device <NUM>. In some embodiments, the processor <NUM> may be implemented in hardware, firmware, or a combination of hardware and software. For example, the processor <NUM> may include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), etc.), a microprocessor, a digital signal processor (DSP), and/or any processing component (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.) that can be programmed to perform a function. Memory <NUM> may include random access memory (RAM), read only memory (ROM), and/or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, optical memory, etc.) that stores information and/or instructions for use by the processor <NUM>.

With continued reference to <FIG>, the storage component <NUM> may store information and/or software related to the operation and use of the device <NUM>. For example, the storage component <NUM> may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, etc.) and/or another type of computer-readable medium. The input component <NUM> may include a component that permits the device <NUM> to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, etc.). Additionally, or alternatively, the input component <NUM> may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.). The output component <NUM> may include a component that provides output information from the device <NUM> (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.). The communication interface <NUM> may include a transceiver-like component (e.g., a transceiver, a separate receiver and transmitter, etc.) that enables the device <NUM> to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface <NUM> may permit the device <NUM> to receive information from another device and/or provide information to another device. For example, the communication interface <NUM> may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi® interface, a cellular network interface, and/or the like.

Claim 1:
A computer-implemented method for securely receiving data via a third-party webpage (<NUM>), comprising:
generating (<NUM>), with a payment web server (<NUM>), configuration data in response to a request (<NUM>) from a merchant web server (<NUM>), the configuration data comprising a public key of a first key pair;
digitally signing (<NUM>), with the payment web server (<NUM>), the configuration data based on a private key of a second key pair;
transmitting (<NUM>), by the payment web server (<NUM>), the digitally signed configuration data to the merchant web server (<NUM>);
in response to the merchant web server (<NUM>) receiving the configuration data from the payment web server (<NUM>), transmitting, by the merchant web server (<NUM>), data comprising the configuration data to a user device (<NUM>), wherein the data is configured to cause the user device (<NUM>) to render a webpage (<NUM>) through a web browser application executed by the user device (<NUM>), the webpage including a master frame (303c) and at least one other frame (303a, 303b), wherein the frames (303a-303c) load content from a domain (<NUM>) that is independent from a domain (<NUM>) that hosts the webpage (<NUM>);
verifying (<NUM>), with the user device (<NUM>), the digitally signed configuration data based on a public key of the second key pair;
rendering, by a browser executed by the user device (<NUM>), the webpage (<NUM>);
establishing communication between the master frame (303c) and the one other frame (303a, 303b) in response to rendering the master frame (303c) and/or verifying the digitally signed configuration data, wherein the digitally signed configuration data restricts communication of the master frame (303c) to the at least one other frame (303a, 303b) and the merchant webpage (<NUM>);
aggregating, by the master frame (303c), data input by a user from each frame (303a-303c);
encrypting, by the master frame (303c), the data input by the user using the public key of the first key pair to generate encrypted data; and
receiving (<NUM>), from the master frame (303c) at the payment web server (<NUM>), the encrypted data.