System and method for online payment processing using secure inline frame

Abstract

To provide a system and a method for online payment processing using secure inline frames.SOLUTION: A system / method permits online payments via an HTML document embedded inside another HTML document (e.g., "inline frame" or "iFrame") on a payee's website. Generally, the iFrame permits a payer (e.g., customer, constituent, donor, etc.) to pay for a transaction (e.g., purchase, utilities payment, fine, donation, dues, etc.) on the payee's website without requiring the payee (e.g., merchant, utilities provider, government entity, nonprofit organization, etc.) to handle payer's payment data (e.g., credit card information, bank account information, block chain-based transaction information, etc.). Further, the iFrame permits the payer to pay for a transaction on the payee's website without requiring the payer to leave the payee's website.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present systems and methods relate generally to online payment processing, and more particularly to enabling online payment processing using embedded HTML documents. [Background technology]

[0002] Every day, millions of payments (e.g., payments for purchases from merchants, utility bill payments, etc.) are made online using the Internet, and transaction volume is growing exponentially each year. To process a payment, the payee (e.g., merchant, utility company, etc.) typically receives personal, highly sensitive payment information / data (e.g., payment card information, bank account information, etc.) and transmits that payment data to a payment processor that enables the payment transaction. Generally, each of these transactions is a potential opportunity to steal personal, highly sensitive payment data because the payment data is shared with a third party (e.g., the payee) and a security breach could accidentally expose that payment data.

[0003] To improve the security of the standard transaction process, some payees, instead of passing payment data to a payment processor, direct consumers directly to the payment processor's website to complete the transaction, so that the payee does not process the payment data. However, this distributed transaction is cumbersome and slow from both the consumer and payee's perspectives, as it not only requires the consumer to visit multiple websites but also requires the payee to reconcile multiple pieces of information to ensure the proper payment is made. Furthermore, this distributed transaction reduces the payee's amount of control over some of the provided data (e.g., consumer name, address, etc.).

[0004] Therefore, there is a long-felt unmet need for a system or method that allows online payments from a payee website without the payee having to process the payment data. Summary of the Invention

[0005] Briefly, according to one embodiment, aspects of the present disclosure generally relate to a system and method that uses embedded HTML documents to enable online payment processing from a payee website without the payee processing the payment data.

[0006] In various embodiments, the disclosed iFrame system enables online payments via an HTML document embedded within another HTML document on a destination website (e.g., an inline frame or iFrame, where the embedded HTML document is an iFrame, and the HTML document with the embedded iFrame is referred to as an “iFrame container”), allowing a payer (e.g., a consumer, constituent, donor, etc.) to pay for a transaction (e.g., a purchase, a utility payment, a fine, a donation, a membership fee, etc.) on the destination website without requiring the destination (e.g., a merchant, a utility provider, a government agency, a nonprofit organization, etc.) to process the payer's payment data (e.g., credit card information, bank account information, blockchain-based transaction information, etc.). This disclosure does not limit the types of payment data that can be received and processed using the iFrame system. Generally, the iFrame allows the destination website to receive and accept payment data without displaying the payment data, instead passing the payment data directly to the iFrame system for payment processing. In various embodiments, when a payer is entering payment data into a payee website that contains an iFrame, the payer is generally not directed to another website to do so, and it appears to the payer that the payee is receiving the payment data directly.

[0007] In various embodiments, after payment data is received via the iFrame, the iFrame system generates an eToken (e.g., an encrypted identifier used by the iFrame system and the payee to identify the payment data) corresponding to the payment data and provides it to the payee. The payee generally requests processing of the transaction by providing the eToken along with other relevant transaction data (e.g., transaction price, transaction identifier, etc.) to the iFrame system. Thus, in various embodiments, the iFrame system determines the appropriate payment data corresponding to the transaction data and processes the transaction through the appropriate payment network (e.g., credit card company, bank, miner, etc.).

[0008] Overall, the iFrame system enhances transaction security by preventing the payment recipient from accessing payment data. Additionally, the iFrame system makes transactions more efficient because it eliminates the need for the payer to access a separate website and the payment recipient to go through a complex transaction reconciliation process. Furthermore, the iFrame system allows the payment recipient greater control over the handling of low-sensitivity data provided by the consumer (e.g., name, address, contact details, etc.), including what data to request and how to request the data.

[0009] These and other aspects, features, and advantages of the invention as set forth in one or more claims will become apparent from the following detailed written description of the preferred embodiments and aspects taken in conjunction with the following drawings, although changes and modifications thereto may be effected without departing from the spirit and scope of the novel concepts of the disclosure. [Brief explanation of the drawings]

[0010] The accompanying drawings illustrate one or more embodiments and / or aspects of the present disclosure and, together with the description, serve to explain the principles of the disclosure. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like elements of an embodiment. [Figure 1] 1 shows an exemplary schematic diagram of one embodiment of the disclosed system. [Figure 2] 1 illustrates an exemplary architecture of one embodiment of the disclosed system. [Figure 3] 1 is a flowchart illustrating an exemplary iFrame system process, according to one embodiment of the present disclosure. [Figure 4] 1 is a flowchart illustrating an exemplary eToken generation process, according to one embodiment of the present disclosure. [Figure 5] 1 is a flowchart illustrating an exemplary eToken trading process, according to one embodiment of the present disclosure. [Figure 6] 1 is a flowchart illustrating an exemplary payee system process, according to one embodiment of the present disclosure. [Figure 7] 1 illustrates an exemplary alternative architecture for one embodiment of the disclosed system. DETAILED DESCRIPTION OF THE INVENTION

[0011] To promote an understanding of the principles of the present disclosure, reference will be made to the embodiments illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the present disclosure is thereby intended. Alterations and further modifications of the described or illustrated embodiments, and further applications of the principles of the present disclosure as exemplified herein, are contemplated as would normally occur to one skilled in the art to which the present disclosure pertains. All limitations of scope should be determined as set forth in the claims.

[0012] Whether or not a term is capitalized is not to be construed as determining or limiting the meaning of that term. As used in this specification, capitalized terms have the same meaning as uncapitalized terms, unless the context of use specifically indicates that a more restrictive meaning of the capitalized term is intended. However, the use of capitalization, or lack thereof, in the remainder of this specification is not necessarily intended to be limiting, unless the context clearly indicates that such a limitation is intended.

[0013] overview According to one embodiment, aspects of the present disclosure generally relate to a system and method that uses embedded HTML documents to enable online payment processing from a payee website without the payee processing the payment data.

[0014] In various embodiments, the disclosed iFrame system enables online payments via an HTML document embedded within another HTML document on a recipient website (e.g., an inline frame or iFrame, where the embedded HTML document is an iFrame, and the HTML document with the embedded iFrame is referred to as an “iFrame container”), allowing a payer (e.g., a consumer, constituent, donor, etc.) to pay for a transaction (e.g., a purchase, a utility payment, a fine, a donation, a membership fee, etc.) on the recipient website without requiring the payee (e.g., a merchant, a utility provider, a government agency, a nonprofit organization, etc.) to process the payer's payment data (e.g., credit card information, bank account information, blockchain-based transaction information, etc.). This disclosure does not limit the types of payment data that can be received and processed using the iFrame system. Generally, the iFrame allows the recipient website to receive and accept payment data without displaying the payment data, instead passing the payment data directly to the iFrame system for payment processing. In various embodiments, when a payer is entering payment data into a payee website that contains an iFrame, the payer is generally not directed to another website to do so, and it appears to the payer that the payee is receiving the payment data directly.

[0015] In various embodiments, after payment data is received via the iFrame, the iFrame system generates an eToken (e.g., an encrypted identifier used by the iFrame system and the payee to identify the payment data) corresponding to the payment data and provides it to the payee. The payee generally requests processing of the transaction by providing the eToken along with other relevant transaction data (e.g., transaction price, transaction identifier, consumer name, consumer address, etc.) to the iFrame system. Thus, in various embodiments, the iFrame system determines the appropriate payment data corresponding to the transaction data and processes the transaction through the appropriate payment network (e.g., credit card company, bank, miner, etc.).

[0016] Overall, the iFrame system enhances transaction security by preventing the recipient from accessing payment data. (This separation limits actions originating from a semi-trusted browser environment and can be limited to validation, encryption, and temporary storage.) For example, using an iFrame transforms retrieval of payment data from a moderately trusted process, where payment data is encrypted and stored only temporarily, into a trusted process. This is because the generated eToken is only valuable / useful in combination with the recipient's API key (e.g., a unique identifier corresponding to the recipient). Therefore, hackers cannot manipulate transparent redirects to authenticate using an iFrame (with or without access to the API key). Furthermore, the iFrame system makes transactions more efficient because the payer does not need to access a separate website and the recipient does not need to perform a complex transaction reconciliation process. Furthermore, the iFrame system allows the recipient to have more control over the processing of low-sensitivity data provided by the consumer (e.g., name, address, contact details, etc.), including which data to request and how to request that data.

[0017] Illustrative Embodiments Referring now to the drawings, for purposes of illustration and description of the basic processes and components of the disclosed systems and methods, reference is made to FIG. 1 , which illustrates an exemplary schematic 1000 of one embodiment of the iFrame system 300. It will be understood and appreciated that the exemplary schematic 1000 illustrated in FIG. 1 represents only a particular approach or embodiment of the present system, and that other aspects may be used in accordance with various embodiments of the present system. Generally, by way of example and not limitation, the schematic 1000 is illustrated in FIG. 1 using a series of numbered steps, designated as steps "1" through "5," which are annotated with circles.

[0018] In various embodiments, the iFrame system 300 enables online payments via an HTML document embedded within another HTML document on a payee website 602 (e.g., an inline frame or iFrame) so that a payer 102 (e.g., a consumer, constituent, donor, etc.) can pay for a transaction (purchase, utility payment, fine, donation, membership dues, etc.) on the payee website 602 without requiring the payee 600 (e.g., a merchant, utility provider, government agency, nonprofit organization, etc.) to process the payer's 102 payment data (e.g., credit card information, bank account information, blockchain-based transaction information, etc.). Generally, the iFrame allows the payee website 602 to receive and accept payment data without displaying the payment data, instead passing the payment data directly to the iFrame system 300 for payment processing. In various embodiments, when the payer 102 is entering payment data on a website 602 that deploys the disclosed systems and methods, the payer 102 is generally not directed to another website to do so, and it appears to the payer 102 that the payee 600 is receiving the payment data directly. A more detailed example is useful to further explain payment processing via the iFrame system 300.

[0019] In a specific, non-limiting example, a merchant 600 that sells items (e.g., pet supplies, clothing, kitchen appliances, etc.) directly to consumers over the Internet 104 may deploy its website 602 to accept payments via the iFrame system 300, as further disclosed herein. Continuing with this example, generally, after the merchant's consumer 102 has determined the items they wish to purchase, added them to their online shopping cart, and is ready to complete their order and pay, the consumer 102 is directed to a payment page on the merchant website 602.

[0020] In various embodiments, the payment page displays an iFrame or embedded HTML document (generated by the iFrame system 300) that allows the consumer 102 to enter payment data directly into the iFrame system 300 via the merchant website 602. Generally, the iFrame (using a JavaScript SDK) allows for user interface customization to display current and / or custom fonts, styles, languages, and layouts (all consistent with those used by the payment destination website 602, so that the iFrame does not appear differently from the rest of the payment destination website 602). Thus, in step 1 of the payment page, in various embodiments, the consumer 102 is prompted to enter payment data in the provided space in the iFrame depending on the selected payment method, and other relevant / required, less sensitive payment data (e.g., consumer name, contact information, etc.) is collected by the merchant website 602 outside the iFrame. For example, the consumer 102 may enter their credit card number, expiration date, and card verification value. The payment data is generally provided by the iFrame on the merchant website 602 directly to the iFrame controller 400 of the iFrame system 300 for generation of an eToken. In various embodiments, the eToken includes an encrypted identifier used by the iFrame system 300 and the merchant website 602 to identify the provided payment data. In various embodiments, as the consumer enters the payment data, the payment data is automatically and in real time provided to the iFrame controller 400 for eToken generation. In an alternative embodiment, the payment data is provided to the iFrame controller only when the consumer 102 affirmatively confirms doing so (e.g., by clicking the "Pay Now" button as in step 3).After the eToken is generated, in step 2, in various embodiments, the eToken is returned to the merchant website 602, where the merchant 600 may associate it with other data for the current transaction and future processing.

[0021] Generally, after receiving the eToken in step 2 and after the consumer provides a positive confirmation in step 3, the merchant website 602 transmits transaction data (e.g., the eToken, transaction price, transaction identifier, etc.) to the eToken transaction processor 500 in the iFrame system 300 for payment processing in step 4. The eToken transaction processor 500 then receives the payment data and, in one embodiment, processes the payment through an appropriate payment network 106 (e.g., a credit card company, bank, miner, etc.). Generally, the eToken transaction processor 500 provides the result of the payment processing to the merchant website 602 for subsequent action. For example, if the payment is confirmed, the merchant 600 may provide an order confirmation page to the merchant website 602 and ship the ordered items to the consumer 102 in step 5. However, if the payment is not confirmed, the merchant 600 may display a transaction void page on the merchant website 602 to allow the consumer 102 to provide new payment data or request processing of the transaction again. Thus, the iFrame system 300 enables online payments on a merchant website 602 through the use of an iFrame, which allows payments directly on the merchant website 602 without the merchant 600 having visibility to the payment data of the transaction.

[0022] Referring now to FIG. 2, an example architecture 2000 of one embodiment of the disclosed iFrame system 300 is shown. In various embodiments, the example iFrame system 300 is operatively connected to one or more payee systems 600 and one or more payment networks 106 via a network 104. Generally, the network 104 can be any connection capable of transferring data between two or more computer systems (e.g., a secure or non-secure connection, Bluetooth, a wireless or wired local area network (LAN), a cell network, the Internet, etc.). As shown in FIG. 2, each network 104 may be a separate network for the multiple communications shown, or the network 104 may be a single network through which all communications are routed. In various embodiments, the network 104 enables secure communications using encryption or other methods.

[0023] In general, the iFrame system 300 may be any computing device (e.g., desktop computer, laptop, server, tablet, etc.), combination of computing devices, software, hardware, or a combination of software and hardware capable of performing the functions disclosed herein, details of which are described in conjunction with the description of FIGS. 1 and 3. The exemplary iFrame system 300, in various embodiments, includes an iFrame controller 400, one or more system databases 202, and an eToken transaction processor 500. In one embodiment, the iFrame controller 400 executes the eToken generation process (details of which are described in conjunction with the description of FIG. 4), communicates with the payee website 602 and the system database 202, and may be any computing device (e.g., desktop computer, laptop, server, tablet, etc.), combination of computing devices, software, hardware, or a combination of software and hardware capable of performing the functions disclosed herein. In one embodiment, the eToken transaction processor 500 may be any computing device (e.g., desktop computer, laptop, server, tablet, etc.), combination of computing devices, software, hardware, or a combination of software and hardware capable of executing the eToken processing process (details of which are described in conjunction with the description of FIG. 5), communicating with one or more payee servers 604 and the system database 202, and performing the functions disclosed herein. In various embodiments, the system database 202 may be any computing device (e.g., desktop computer, laptop, server, tablet, etc.), combination of computing devices, software, hardware, combination of software and hardware, database (e.g., stored in the cloud or on premise and structured as relational), or combination of databases capable of performing the functions disclosed herein.

[0024] In various embodiments, the exemplary payee system 600 includes a payee website 602 and one or more payee servers 604. Generally, the exemplary payee system 600 is operatively connected to the exemplary iFrame system 300 and one or more consumer systems 102 via the network 104. Generally, the exemplary payee system 600 may be any computing device (e.g., desktop computer, laptop, server, tablet, etc.), combination of computing devices, software, hardware, or a combination of software and hardware capable of performing the functions disclosed herein, the details of which are described in conjunction with the description of FIGS. 1 and 6. In one embodiment, the payee website 602 is a website, mobile application, webpage, collection of webpages, or other hardware / software (or a combination thereof) capable of performing the functions disclosed herein. In one embodiment, the payee server 604 may be any computing device (e.g., desktop computer, laptop, server, tablet, etc.), combination of computing devices, software, hardware, or a combination of software and hardware that hosts the payee website 602, communicates with the eToken transaction processor 500, and is capable of performing the functions disclosed herein.

[0025] Generally, the payee website 602 may be coded to generate an iFrame container that receives the iFrame from the iFrame system 300. For example, the payee website 602 may include a JavaScript SDK that manages communication between the payee website 602 (e.g., an HTML page) and the iFrame (e.g., another HTML page). Generally, the SDK enables the generation of eTokens (e.g., as part of process 4000). Additionally, in at least one embodiment, the SDK enables the transmission of masked data. In one embodiment, the SDK automatically embeds the iFrame on the payee website 602. When the payer's internet browser on the consumer system 102 detects that the iFrame has been loaded from a different domain than the payee website 602 (e.g., associated with the iFrame system 300), in various embodiments, the browser generally applies a mechanism that restricts communication to a specific set of custom commands, significantly increasing the security applied to the payee website 602. The JavaScript SDK generally provides developer-friendly functionality for hiding complex command messages. According to one or more embodiments, the SDK passes the encrypted eToken to the payee.

[0026] The consumer system 102, in one embodiment, is any device (e.g., desktop computer, laptop computer, tablet computer, smartphone, smartwatch, etc.) that allows a consumer to interact with and conduct transactions on the payee website 602 and that is capable of performing the functions disclosed herein. As will be apparent to one skilled in the art, the present disclosure does not limit the type of consumer system 102 that may be used as described herein.

[0027] Generally, the payment network 106 settles financial transactions, is typically operated by a financial institution (e.g., a bank, a credit card company, etc.), and may be any computing device (e.g., a desktop computer, a laptop, a server, a tablet, etc.), combination of computing devices, software, hardware, or a combination of software and hardware capable of performing the functions disclosed herein. As will be apparent to one skilled in the art, the present disclosure does not limit the type of payment network 106 that may be used as described herein.

[0028] Referring now to Figure 3, a flowchart of an exemplary iFrame system process 3000 is shown, according to one embodiment of the present disclosure. As will be appreciated by those skilled in the art, the steps and processes shown in Figure 3 (and all other flowcharts and sequence diagrams shown and described herein) can be performed simultaneously and sequentially, are typically asynchronous and independent, and are not necessarily performed in the order shown. Generally, the exemplary iFrame system process 3000 is a process by which the iFrame system 300 receives and processes payment data as part of an online transaction initiated through the payment destination website 602.

[0029] In various embodiments, the exemplary iFrame system process 3000 begins at step 301, where the iFrame system 300 receives a request via an iFrame on a payee website 602 to generate an eToken corresponding to one or more payment data (e.g., credit card number, routing number, expiration date, Social Security number, Bitcoin address, etc.). In one embodiment, the exemplary iFrame system process 3000 begins when the iFrame system 300 generates / creates the iFrame that generates the request. (In various embodiments, the iFrame includes a first HTML document linked to the iFrame system 300 / hosted by the iFrame system 602 and embedded in a second HTML document (also known as an iFrame container) located on the payee website; in this structure, the payee website 602 does not have access / visibility to the data processed by the first HTML document (typically, payment data). In various embodiments, the SDK supports a configuration option to automatically generate an iFrame on the payee website 602 styled to the payee's preferences. Generally, the request to generate an eToken is generated automatically when payment data is entered into the iFrame (or via the SDK if the iFrame detects the same entry), or when the payer 102 provides positive confirmation to do so (e.g., clicking a "Pay Now" button). In one embodiment, the request may include the payment data. In one embodiment, the iFrame may provide the payment data to the iFrame controller 400 separately from the request. Thus, to generate an eToken, in various embodiments, the iFrame system 300 initiates an eToken generation process 4000 via the iFrame controller 400, further details of which are described in conjunction with the description of FIG. 4.

[0030] Once the eToken is generated (as part of process 4000), in one embodiment, the iFrame system 300 sends the eToken to the payee system 600 (e.g., the eToken is passed from the iFrame system 300 over the network 104 to a first HTML document on the payee website 602, which passes the eToken to the iFrame container, where it is picked up by the JavaScript SDK) if it is associated with the particular transaction involved (e.g., using a callback function in the SDK to pass the eToken to the payee server 604). In various embodiments, the iFrame system 300 receives a request to process payment for the transaction in step 305. Generally, the request to process payment includes transaction data corresponding to the transaction (e.g., amount charged, eToken, transaction identifier, consumer name, consumer contact information, etc.). Thus, to process the transaction, in various embodiments, the iFrame system 300 initiates an eToken transaction process 5000 using the eToken transaction processor 500, the details of which are described in conjunction with the description of FIG. 5.

[0031] Generally, in step 307, after the transaction is processed (as part of process 5000), the iFrame system 300 sends the results of the transaction processing (e.g., confirmation, denial, request for additional information, etc.) to the payee system 600 for appropriate action, and the exemplary iFrame system process 3000 then ends.

[0032] 4, a flowchart illustrating an exemplary eToken generation process 4000 according to one embodiment of the present disclosure is shown. Generally, the eToken generation process 4000 is a process by which the iFrame controller 400 generates an eToken that represents / corresponds to payment data entered by the payer 102. As will be apparent to one skilled in the art, the present disclosure does not limit the type of payment data accepted by the iFrame system 300 (e.g., credit card, debit card, bank account, cryptocurrency, etc.). Generally, the eToken is an identifier used by the iFrame system 300 and the payee system 600 to identify the payment data of the payer 102. In one embodiment, the eToken is encrypted or otherwise obfuscated by an encryption algorithm (e.g., RSA, AES, etc.), a secure hash algorithm (e.g., SHA-256, etc.), or other system / method to prevent unauthorized third parties from accessing / using the data represented by the eToken.

[0033] In various embodiments, an exemplary eToken generation process 4000 begins at step 401, where the iFrame controller 400 receives payment data from an iFrame on the payee website 602. In one embodiment, the iFrame validates the payment data (e.g., ensuring it meets certain formatting criteria such as proper credit card number length, credit check value, routing number, proper date format, etc., has all necessary payment data, is from a live payer 102 and not a bot, etc.) before sending it to the iFrame system 300.

[0034] Generally, in step 403, the iFrame controller 400 performs additional security checks on the received payment data (e.g., the payment data was received in an expected format, the payment data was signed with an appropriate signature, etc.) to ensure that correct payment data was received and that the received payment data was not the result of a malicious attack (e.g., a third party masquerading as an iFrame to infiltrate the iFrame system 300).

[0035] If the payment data passes the additional security checks, in one embodiment, the iFrame controller 400 encrypts the payment data (e.g., using an encryption algorithm, a secure hash algorithm, etc.) and stores the encrypted payment data in the system database 202. Further, in step 407, in various embodiments, the iFrame controller 400 generates an eToken corresponding to the payment data and associates the eToken with the encrypted payment data (and other data, such as the identifier of the payee 600) and stores it in the system database 202, after which the example eToken generation process 400 ends. However, if the payment data does not pass the additional security checks, in various embodiments, the iFrame controller 400 takes appropriate action in step 409 (e.g., sending an error message, notifying appropriate security personnel, monitoring the payment data, etc.), after which the example eToken generation process 400 ends.

[0036] 5, a flowchart of an exemplary eToken transaction process 5000 is shown, in accordance with one embodiment of the present disclosure. Generally, the eToken transaction process 5000 is a process by which the eToken transaction processor 500 processes a transaction requested by a payer 102.

[0037] In various embodiments, an exemplary eToken transaction process 5000 begins at step 501, where the eToken transaction processor 500 receives transaction data from one or more payee servers 604. Generally, at step 503, the eToken transaction processor 500 validates the transaction data (e.g., eToken, payee, etc.) to ensure that correct transaction data has been received and that the received transaction data is not the result of a malicious attack (e.g., a third party impersonating the payee 600 to process a fake payment, etc.). In one embodiment, if the transaction data (and in particular the eToken) is not received within a specific time frame (e.g., 1 minute, 3 minutes, 5 minutes, 10 minutes, etc.) beginning after generating the eToken (e.g., at step 407), the eToken transaction processor does not validate the transaction data.

[0038] If the transaction data is verified, in one embodiment, the eToken transaction processor 500 retrieves payment data corresponding to the eToken in the transaction data from the system database 202 (e.g., in one embodiment, the eToken must first be decrypted to determine if it is the appropriate eToken), and processes the transaction via the appropriate payment network 106 according to other information in the transaction data. Further, in step 507, in various embodiments, the eToken transaction processor 500 compiles multiple transaction results (e.g., payment confirmation, payment denial, etc.) for transmission to the payee system 600, after which the exemplary eToken transaction process 500 ends.

[0039] However, if the transaction data cannot be verified, the eToken transaction processor 500, in various embodiments, takes appropriate action in step 509 (e.g., sending an error message, notifying appropriate security personnel, logging the error, etc.), after which the exemplary eToken transaction process 500 ends. In one embodiment, in step 509, an error message in an iFrame is displayed to the payer with the erroneous data fields blanked / highlighted and the remaining correct data fields masked (e.g., fully or partially hidden) so that the payer can re-enter the erroneous data. In one embodiment, the error fields are populated from the appropriate eToken and one or more masked data objects (sent via the JavaScript SDK). If the payer does not change the data in the data fields, the eToken and one or more masked data objects remain unchanged. However, if the payer changes any of the data in the data fields (e.g., the error field, the masked field, etc.), the new data is used to generate a new eToken and / or masked data object.

[0040] 6, a flowchart of an example payee system process 6000 is shown in accordance with one embodiment of the present disclosure. Generally, the example payee system process 6000 is a process by which a payee system 600 enables online payments to a payee 600 as part of an online transaction initiated through a payee website 602.

[0041] In various embodiments, the exemplary payee system process 6000 begins at step 601, where the payee website 602 displays a payment page including an iFrame. Generally, the payer 102 enters payment data into the iFrame using a computing device, and in step 603, if verified, the payee 600 receives an eToken generated by the iFrame system 300 corresponding to the entered payment data for use in the transaction. If the payee 600 does not receive the eToken in step 603, in one embodiment, the payee 600 may be configured to send an error message to the payer 102 or request additional information from the payer 102.

[0042] Generally, in step 605, one or more payee servers 604 associate an eToken with a particular transaction so that the payee 600 can identify the appropriate payment data to the iFrame system 300. In one embodiment, in step 607, one or more payee servers 604 receive a request from the payer 102 to process payment for the transaction. Accordingly, in step 609, in various embodiments, the one or more payee servers 604 gather the appropriate transaction data and send a request to the iFrame system 300 to process payment for the transaction.

[0043] In various embodiments, the one or more payee servers 604 receive the results of the transaction processing in step 611. In one embodiment, in step 613, the one or more payee servers 604 display the results of the transaction processing on the payee website 602 (e.g., an order confirmation if the payment was successful, a request for additional information or a denial of the transaction if the payment was not successful, etc.), after which the example payee system process 6000 ends.

[0044] Referring now to Figure 7, an exemplary alternative architecture 7000 of one embodiment of the disclosed iFrame system 300 is shown. In general, the exemplary alternative architecture 7000 is the same as the exemplary architecture 2000 (shown in Figure 2), and except as noted below, the description of Figure 2 (as well as Figures 3-6) is also applicable to Figure 7. In various embodiments, the exemplary iFrame system 300 is operably connected to one or more payee systems 600 and one or more payment gateways 700 via the network 104 to execute the iFrame system process 3000.

[0045] Generally, the iFrame system 300 includes an iFrame controller 400, one or more system databases 202, and an eToken decryption processor / service 502. In one embodiment, the eToken decryption processor 502 may be any computing device (e.g., desktop computer, laptop, server, tablet, etc.), combination of computing devices, software, hardware, or a combination of software and hardware capable of decrypting multiple eTokens (in one embodiment, as part of the eToken transaction process 5000), communicating with one or more payee servers 604, the system database 202, and one or more gateway servers 702, and performing the functions disclosed herein.

[0046] In various embodiments, the payment gateway 700 is a third-party system that processes multiple payments (e.g., multiple credit card payments, direct payments, etc.) and / or communicates with systems (e.g., iFrame system 300, payee system 600, etc.) for the payment network 106. Generally, the payment gateway 700 includes one or more gateway servers 702. In one embodiment, the payment gateway 700 communicates with the payment network 106, the iFrame system 300, and the payee system 600. In various embodiments, the payment gateway 700 and one or more gateway servers 702 may be any computing device (e.g., desktop computer, laptop, server, tablet, etc.), combination of computing devices, software, hardware, or a combination of software and hardware capable of performing the functions disclosed herein. In one embodiment, the payment network 106 includes the payment gateway 700, which interfaces with multiple systems (e.g., iFrame system 300, payee system 600, etc.) external to the payment network 106.

[0047] Continuing with the embodiment shown in FIG. 7, the system database 202 holds the encrypted cardholder data (e.g., received from the iFrame controller 400). In various embodiments, the payee server 604 sends an eToken to one or more gateway servers 702 (e.g., in step 609 of the payee system process 6000, with additional non-sensitive transaction data, such as the consumer's name, address, etc., in at least one embodiment). In these embodiments, the one or more gateway servers 702 then send the eToken to the eToken decryption processor 502, which validates the eToken (e.g., by decrypting the eToken, verifying that it is a valid eToken, verifying that it was received within a valid timeframe, etc.), retrieves (or otherwise receives), and decrypts the cardholder data from the system database 202, and sends it back to the one or more gateway servers 702. As will be appreciated, once the one or more gateway servers 702 receive the unencrypted cardholder data, the payment gateway 700 may process the cardholder data via the payment network 106 (e.g., in steps 503-509 of the eToken transaction process 5000) and report the results of the processing to the payee server 604.

[0048] From the above, it should be understood that various aspects of the processes described herein are software processes executing on computer systems forming portions of the system. Accordingly, it will be appreciated that the various embodiments of the systems described herein are generally embodied as specially configured computers including various computer hardware components, and in many cases possess significant additional features over prior or known computers, processes, and the like, as described in further detail herein. Embodiments within the scope of the present disclosure also include computer-readable media for carrying or having computer-executable instructions or data structures. Such computer-readable media may be any available media that can be accessed by a computer or downloadable via a communications network. By way of example, and not limitation, such computer-readable media may include RAM, ROM, flash memory, EEPROM, CD-ROM, DVD or other optical disk storage, magnetic disk storage, solid state drives (SSDs), other data storage devices, any type of removable non-volatile memory such as secure digital (SD), flash memory, memory sticks, or any other medium that can be used to transfer or store computer program code in the form of computer-executable instructions or data structures and that can be accessed by a computer.

[0049] When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a computer-readable medium. Thus, such a connection is properly called and considered to be a computer-readable medium. Combinations of the above should also be included within the scope of computer-readable media. Computer-executable instructions include, for example, instructions and data that cause a computer to perform a certain function or group of functions.

[0050] Those skilled in the art will appreciate the features and aspects of suitable computing environments in which aspects of the present disclosure may be implemented. Although not required, some embodiments of the claimed system may be described in the context of computer-executable instructions, such as program modules or engines, executed by computers in networked environments, as described above. Such program modules are often reflected and illustrated by flowcharts, sequence diagrams, illustrative screen displays, and other techniques used by those skilled in the art to communicate how to create and use such computer program modules. Generally, program modules include routines, programs, functions, objects, components, data structures, and application programming interface (API) calls to other computers, whether local or remote, that perform particular tasks within a computer or implement particular defined data types. The computer-executable instructions, associated data structures and / or schema, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding operations for enabling the functions described in such steps.

[0051] Those skilled in the art will also appreciate that the claimed and / or described systems and methods may be implemented in networked computing environments having many types of computer system configurations, including personal computers, smartphones, tablets, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, networked PCs, minicomputers, mainframe computers, etc. Embodiments of the claimed system (and / or method) are implemented in a distributed computing environment where tasks are performed by local and remote processing devices that are linked through a communications network (by hardwired links, wireless links, or a combination of hardwired and wireless links). In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

[0052] An exemplary system for embodying various aspects of the operations not described includes a computing device including a processing unit, a system memory, and a system bus coupling various system components including the system memory to the processing unit. A computer typically includes one or more data storage devices for reading and writing data. The data storage devices provide non-volatile storage of computer-executable instructions, data structures, program modules, and other data for the computer.

[0053] Computer program code embodying the functionality described herein typically includes one or more program modules stored on a data storage device. This program code typically includes an operating system, one or more application programs, other program modules, and program data, as known to those skilled in the art. A user can enter commands and information into the computer via a keyboard, touch screen, pointing device, scripts containing computer program code written in a scripting language, or other input devices (not shown), such as a microphone. These and other input devices are often connected to the processing unit via known electrical, optical, or wireless connections.

[0054] The computers affecting many aspects of the described processes typically operate in a networked environment using logical connections to one or more remote computers or data sources, as described further below. The remote computer may be another personal computer, a server, a router, a network PC, a peer device, or other common network node, and typically includes many or all of the elements described above with respect to the main computer system in which the system is embodied. Logical connections between multiple computers include, but are not limited to, local area networks (LANs), wide area networks (WANs), virtual networks (WANs or LANs), and wireless LANs (WLANs), which are shown herein by way of example only. Such networking environments are commonplace in office-wide or enterprise-wide computer networks, intranets, and the Internet.

[0055] When used in a LAN or WLAN networking environment, a computer system embodying aspects of the system is connected to the local network through a network interface or adapter. When used in a WAN or WLAN networking environment, the computer may include a modem, wireless link, or other mechanism for establishing communications over a wide area network, such as the Internet. In a networked environment, program modules depicted relative to the computer, or portions thereof, may be stored in a remote data storage device. It will be appreciated that the network connections described or shown are exemplary and that other mechanisms for establishing communications over the wide area network or the Internet may be used.

[0056] Alternative Aspects Various aspects of the present system and method will now be described. Those skilled in the art will understand that any of the following aspects may incorporate or include other aspects described below or features described herein. Therefore, the following aspects should be understood to include any combination of aspects and should not be limited to the combinations presented below. For example, the second aspect includes the computer system of the first aspect, but may also include features of the 26th aspect, the first aspect, or the 100th aspect.

[0057] According to a first aspect, a system includes an iFrame controller that performs the following operations: creating an iFrame at a merchant website hosted on a server; receiving payment data from the iFrame corresponding to a transaction at the merchant website; encrypting and storing the received payment data; generating an eToken corresponding to the encrypted payment data; and transmitting the eToken to a server, which transmits the eToken to a payment gateway server; and an eToken decryption processor that performs the following operations: receiving the eToken from the payment gateway server; authenticating the eToken to determine corresponding encrypted payment data; decrypting the encrypted payment data; and transmitting the decrypted payment data to the payment gateway server for processing the transaction.

[0058] In the system or method of the first aspect or any other aspect according to the second aspect, the iFrame includes a first HTML document embedded within a second HTML document. In the system or method of the first aspect or any other aspect according to a third aspect, the received payment data includes at least one of a credit card number, a credit card expiration date, a credit card verification value, a bank account routing number, a debit card number, a debit card expiration date, or a PIN number.

[0059] In the system or method of the third aspect or any other aspect according to the fourth aspect, the payment data is not accessible by the merchant website or server.

[0060] According to the fifth aspect, in the system or method of the first aspect or any other aspect, the payment gateway server and the iFrame controller are managed separately from the server.

[0061] In the system or method of the first aspect or any other aspect according to the sixth aspect, the iFrame controller encrypts the eToken before sending it to the server.

[0062] According to the seventh aspect, in the system or method of the sixth aspect or any other aspect, the eToken decryption processor decrypts the eToken before authenticating the eToken.

[0063] In the system or method of the first aspect or any other aspect according to the eighth aspect, the iFrame includes one or more fonts or text styles that match fonts or text styles on the merchant website.

[0064] In the system or method of the eighth aspect or any other aspect according to the ninth aspect, the iFrame controller is configured to substantially automatically match fonts or text styles on the merchant website based on user input for creating the iFrame.

[0065] In the system or method of the first aspect or any other aspect according to the tenth aspect, the iFrame controller creates the iFrame based at least in part on input from an iFrame builder user interface that allows the merchant to input multiple iFrame parameters.

[0066] In the system or method of the tenth aspect or any other aspect according to an eleventh aspect, the iFrame builder user interface includes a command that enables a merchant to match at least one of fonts and text styles on a merchant website.

[0067] A method according to a twelfth aspect comprises creating an iFrame at a merchant website hosted on a server; receiving payment data from the iFrame corresponding to a transaction at the merchant website; encrypting the received payment data; storing the encrypted payment data; generating an eToken corresponding to the encrypted payment data; transmitting the eToken to a server, which transmits the eToken to a payment gateway server; transmitting the eToken to the server; receiving the eToken from the payment gateway server; authenticating the eToken to determine corresponding encrypted payment data; decrypting the encrypted payment data; and transmitting the decrypted payment data to the payment gateway server for processing the transaction.

[0068] According to a thirteenth aspect, in the system or method of the twelfth aspect or any other aspect, the iFrame includes a first HTML document embedded within a second HTML document.

[0069] In the system or method of the twelfth aspect or any other aspect according to the fourteenth aspect, the received payment data includes at least one of a credit card number, a credit card expiration date, a credit card verification value, a bank account routing number, a debit card number, a debit card expiration date, or a PIN number.

[0070] In the system or method of the twelfth aspect or any other aspect according to the fifteenth aspect, the payment data is not accessible by the merchant website or server.

[0071] According to the sixteenth aspect, in the system or method of the twelfth aspect or any other aspect, the payment gateway server is managed separately from the server. The system or method of the twelfth aspect or any other aspect according to the seventeenth aspect, further comprising encrypting the eToken before transmitting the eToken to the server.

[0072] A system or method of the twelfth aspect or any other aspect according to an eighteenth aspect, further comprising decrypting the eToken before authenticating the eToken. A system according to a nineteenth aspect includes a website hosted on a server, the website including an iFrame that receives payment data corresponding to a transaction on the website and is generated by an iFrame controller; and a server that performs the following operations: receiving an eToken corresponding to the received payment data from the iFrame controller; generating transaction data corresponding to the transaction and including the eToken and the non-confidential payment data; transmitting the transaction data to a payment gateway server for processing the transaction; and receiving at least one processing result from the payment gateway server.

[0073] In the system or method of the 19th aspect or any other aspect according to the 20th aspect, the payment gateway server transmits the eToken to an eToken decoding processor operably connected to the iFrame controller, and the database stores the received payment data.

[0074] In the system or method of the twentieth aspect or any other aspect according to the twenty-first aspect, in response to transmitting the eToken to the eToken decryption processor, the payment gateway server receives the received payment data.

[0075] In the system or method of the nineteenth aspect or any other aspect according to the twenty-second aspect, the iFrame includes a first HTML document embedded within a second HTML document.

[0076] In the system or method of the 19th aspect or any other aspect according to the 23rd aspect, the received payment data includes at least one of a credit card number, a credit card expiration date, a credit card verification value, a bank account routing number, a debit card number, a debit card expiration date, or a PIN number.

[0077] In the system or method of the twenty-third aspect or any other aspect according to the twenty-fourth aspect, the payment data is not accessible by the website or server. In the system or method of the twenty-fourth aspect or any other aspect according to the twenty-fifth aspect, the non-confidential payment data includes at least one of a transaction identifier, a transaction price, and contact information.

[0078] According to a twenty-sixth aspect, in the system or method of the twenty-fifth aspect or any other aspect, the payment gateway server is managed separately from the server. A method according to a twenty-seventh aspect comprises hosting a website including an iFrame, the iFrame receiving payment data corresponding to a transaction on the website; receiving an eToken corresponding to the received payment data; generating transaction data corresponding to the transaction and including the eToken and the non-confidential payment data; transmitting the transaction data to process the transaction; and receiving at least one processing result.

[0079] In the system or method of the twenty-seventh aspect or any other aspect according to the twenty-eighth aspect, the iFrame includes a first HTML document embedded within a second HTML document.

[0080] In the system or method of the twenty-eighth aspect or any other aspect according to the twenty-ninth aspect, the received payment data includes at least one of a credit card number, a credit card expiration date, a credit card verification value, a bank account routing number, a debit card number, a debit card expiration date, or a PIN number.

[0081] In the system or method of the twenty-ninth aspect or any other aspect according to the thirtieth aspect, the payment data is not accessible by the website. In the system or method of the thirtieth aspect or any other aspect according to the thirty-first aspect, the non-confidential payment data includes at least one of a transaction identifier, a transaction price, and contact information.

[0082] A system according to a thirty-second aspect includes an iFrame controller that creates an iFrame at a merchant website hosted on a server, receives payment data from the iFrame corresponding to a transaction at the merchant website, generates an eToken corresponding to the received payment data, and sends the eToken to the server; and an eToken transaction processor that receives transaction data from the server that corresponds to the transaction and includes an eToken and non-sensitive payment data, authenticates the eToken to determine the corresponding received payment data, and processes the transaction based on the received transaction data using the received payment data.

[0083] In the system or method of the thirty-second aspect or any other aspect according to the thirty-third aspect, the iFrame includes a first HTML document embedded within a second HTML document.

[0084] In the system or method of the thirty-second aspect or any other aspect according to the thirty-fourth aspect, the received payment data includes at least one of a credit card number, a credit card expiration date, a credit card verification value, a bank account routing number, a debit card number, a debit card expiration date, or a PIN number.

[0085] In the system or method of the thirty-fourth aspect or any other aspect according to the thirty-fifth aspect, the payment data is not accessible by the merchant website or server.

[0086] In the system or method of the thirty-second aspect or any other aspect according to the thirty-sixth aspect, the non-confidential payment data includes at least one of a transaction identifier, a transaction price, and contact information.

[0087] In the system or method of the thirty-second aspect or any other aspect according to the thirty-seventh aspect, the iFrame controller encrypts the eToken before sending it to the server.

[0088] In the system or method of the thirty-seventh aspect or any other aspect according to the thirty-eighth aspect, the eToken transaction processor decrypts the eToken before authenticating the eToken.

[0089] In the system or method of the thirty-second aspect or any other aspect according to the thirty-ninth aspect, the eToken transaction processor transmits at least a portion of the payment data and transaction data to a payment network to process the transaction.

[0090] A method according to a fortieth aspect comprises creating an iFrame at a merchant website hosted on a server; receiving payment data from the iFrame corresponding to a transaction at the merchant website; generating an eToken corresponding to the received payment data; transmitting the eToken to the server; receiving transaction data from the server corresponding to the transaction and including the eToken and non-sensitive payment data; authenticating the eToken to determine the corresponding received payment data; and processing the transaction based on the received transaction data using the received payment data.

[0091] In the system or method of the fortieth aspect or any other aspect according to the forty-first aspect, the iFrame includes a first HTML document embedded within a second HTML document.

[0092] In the system or method of the fortieth aspect or any other aspect according to the forty-second aspect, the received payment data includes at least one of a credit card number, a credit card expiration date, a credit card verification value, a bank account routing number, a debit card number, a debit card expiration date, or a PIN number.

[0093] In the system or method of the forty-second aspect or any other aspect according to the forty-third aspect, the payment data is not accessible by the merchant website or server.

[0094] In the system or method of the fortieth aspect or any other aspect according to the forty-fourth aspect, the non-confidential payment data includes at least one of a transaction identifier, a transaction price, and contact information.

[0095] The system or method of the fortieth aspect or any other aspect according to the forty-fifth aspect, further comprising encrypting the eToken before transmitting the eToken to the server.

[0096] A system or method of the forty-fifth aspect or any other aspect according to a forty-sixth aspect, further comprising decrypting the eToken before authenticating the eToken. In the system or method of the 40th aspect or any other aspect according to the 47th aspect, processing the transaction further includes transmitting at least a portion of the payment data and transaction data to a payment network to process the transaction.

[0097] A system according to a forty-eighth aspect includes a website hosted on a server, the website including an iFrame that receives payment data corresponding to a transaction on the website and is generated by an iFrame controller; and a server that performs the following operations: receiving an eToken corresponding to the payment data received from the iFrame controller; generating transaction data corresponding to the transaction and including the eToken and non-confidential payment data; transmitting the transaction data to an eToken transaction processor for processing the transaction; and receiving at least one processing result from the eToken transaction processor.

[0098] According to a forty-ninth aspect, in the system or method of the forty-eighth aspect or any other aspect, the iFrame includes a first HTML document embedded within a second HTML document.

[0099] In the system or method of the 48th aspect or any other aspect according to the 50th aspect, the received payment data includes at least one of a credit card number, a credit card expiration date, a credit card verification value, a bank account routing number, a debit card number, a debit card expiration date, or a PIN number.

[0100] In the system or method of the 50th aspect or any other aspect according to the 51st aspect, the payment data is not accessible by the website or server. In the system or method of the 48th aspect or any other aspect according to the 52nd aspect, the non-confidential payment data includes at least one of a transaction identifier, a transaction price, and contact information.

[0101] conclusion While various aspects have been described in connection with preferred embodiments, additional aspects, features, and methods of the claimed system will be readily discernible by those skilled in the art from the description herein. Numerous embodiments and adaptations of the disclosed and claimed system, as well as numerous variations, modifications, and equivalent arrangements and methods, other than those described herein, will be apparent from, or reasonably suggested by, this disclosure and its foregoing description without departing from the content or scope of the claims. Furthermore, any sequence and / or temporal order of the steps of the various processes described and claimed herein is believed to be the best possible mode for carrying out the claimed system. While the steps of the various processes may be shown and described as being in a preferred sequence or temporal order, it should also be understood that the steps of such processes are not limited to being performed in a particular sequence or order unless specifically indicated to achieve a particular intended result. In many cases, the steps of such processes may be performed in various different sequences and orders and still fall within the scope of the claimed system. Furthermore, some steps may be performed simultaneously, during the same time period, or synchronized with other steps.

[0102] The embodiments have been selected and described to explain the principles of the claimed system and its practical application, so as to enable those skilled in the art to use the system and various embodiments, and various modifications are suitable for the particular use intended. Alternative embodiments will be apparent to those skilled in the art to which the system pertains without departing from the spirit and scope of the claimed system. Accordingly, the scope of the claimed system is defined by the appended claims, rather than the above description and the exemplary embodiments described therein.

Claims

1. 1. A system comprising: An iFrame controller, receiving payment data from the iFrame corresponding to a transaction at a merchant website hosted on the server; verifying that the payment data was signed with a trusted signature to ensure that a third party is not impersonating the iFrame; encrypting and storing the received payment data; receiving a request to generate an eToken corresponding to the payment data, the request to generate the eToken being received separately from the payment data; generating the eToken corresponding to the payment data in response to the request; the iFrame controller transmitting the eToken to the server, which transmits the eToken to a payment gateway server; 1. An eToken processor comprising: receiving the eToken after transmitting the eToken to the server; authenticating the received eToken to determine the payment data to which the eToken corresponds; decrypting said encrypted payment data; and the eToken processor, in response to receiving the eToken, transmitting the decrypted payment data to the payment gateway server for processing the transaction.

2. The system of claim 1 , wherein the iFrame comprises a first HTML document embedded within a second HTML document.

3. The system of claim 1 , wherein the received payment data includes at least one of a credit card number, a credit card expiration date, a credit card verification value, a bank account routing number, a debit card number, a debit card expiration date, or a PIN number.

4. The system of claim 3 , wherein the payment data is not accessible by the merchant website or the server.

5. The system of claim 1 , wherein the payment gateway server and the iFrame controller are managed separately from the server.

6. The system of claim 1 , wherein the iFrame controller encrypts the eToken before transmitting the eToken to the server.

7. The system of claim 6 , wherein the eToken processor decrypts the received eToken before authenticating the received eToken.

8. The system of claim 1 , wherein the iFrame includes one or more fonts or text styles that match fonts or text styles on the merchant website.

9. The system of claim 8 , wherein the iFrame controller is configured to substantially automatically match fonts or text styles on the merchant website based on user input for creating the iFrame.

10. The system of claim 1 , wherein the iFrame controller creates the iFrame based at least in part on input from an iFrame builder user interface that allows a merchant to input multiple iFrame parameters.

11. The system of claim 10 , wherein the iFrame builder user interface includes a command that enables the merchant to match at least one of fonts and text styles on the merchant website.

12. further comprising the merchant website hosted on the server, the merchant website including an iFrame; The server receiving the eToken corresponding to the payment data from the iFrame Controller; generating transaction data corresponding to the transaction and including the eToken and non-confidential payment data; transmitting the transaction data to the payment gateway server for processing the transaction; 10. The system of claim 1, further comprising: receiving at least one processing result from the payment gateway server.

13. 13. The system of claim 12, wherein the payment gateway server transmits the eToken to the eToken processor, and a database stores received payment data.

14. 14. The system of claim 13, wherein in response to transmitting the eToken to the eToken processor, the payment gateway server receives the received payment data.

15. The system of claim 12 , wherein the non-sensitive payment data includes at least one of a transaction identifier, a transaction price, and contact information.

16. 1. A method comprising: receiving payment data from the iFrame corresponding to a transaction at a merchant website hosted on the server; verifying that the payment data was signed with a trusted signature to ensure that a third party is not impersonating the iFrame; storing said payment data in an encrypted form; receiving a request to generate an eToken corresponding to the payment data, the request to generate the eToken being received separately from the payment data; generating the eToken corresponding to the payment data in response to receiving the request; sending the eToken to the server, which sends the eToken to a payment gateway server; receiving the eToken after said sending of the eToken to the server; authenticating the received eToken to determine the payment data to which the eToken corresponds; decrypting said encrypted payment data; in response to receiving the eToken, transmitting the decrypted payment data to the payment gateway server for processing the transaction.

17. 17. The method of claim 16, wherein the iFrame comprises a first HTML document embedded within a second HTML document.

18. 17. The method of claim 16, wherein the received payment data includes at least one of a credit card number, a credit card expiration date, a credit card verification value, a bank account routing number, a debit card number, a debit card expiration date, or a PIN number.

19. 20. The method of claim 18, wherein the payment data is not accessible by the merchant website or the server.

20. 17. The method of claim 16, wherein the payment gateway server is managed separately from the server.

21. 17. The method of claim 16, further comprising encrypting the eToken before transmitting the eToken to the server.

22. 22. The method of claim 21, further comprising decrypting the received eToken before authenticating the received eToken.

Images