System and method for online payment processing using secure inline frames

Abstract

This system and method provides online payment processing using a secure inline frame. [Solution] The system and method enable online payments via an HTML document embedded in another HTML document (such as an "inline frame" or "iFrame") on the recipient's website. Generally, iFrames enable payers (e.g., consumers, members, providers, etc.) to make payments for transactions (purchases, utility payments, fines, donations, membership fees, etc.) on the recipient's website without requiring the recipient (e.g., merchants, utilities, government agencies, non-profit organizations, etc.) to process the payer's payment data (e.g., credit card information, bank account information, blockchain-based transaction information, etc.). Furthermore, iFrames enable payments for transactions on the recipient's website without the payer leaving the recipient's website.

Description

Technical Field

[0001] The present system and method generally relate to online payment processing, and more particularly to enabling online payment processing using embedded HTML documents.

Background Art

[0002] Every day, millions of payments (such as payments for purchases from merchants, payments for utility bills, etc.) are made online using the Internet, and the transaction volume is increasing exponentially every year. To process payments, payees (such as merchants, utility providers, etc.) typically receive highly confidential payment information / data of individuals (such as payment card information, bank account information, etc.), and transmit that payment data to a payment processor capable of handling payment transactions. Generally, since the payment data is shared with third parties (such as payees) and there is a possibility that the payment data may be accidentally disclosed due to a security breach, each of these transactions may present an opportunity to steal highly confidential payment data of individuals.

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

[0004] Therefore, there has been a long-standing unsolved need for a system or method that enables online payments from a payee website without the payee processing the payment data.

Summary of the Invention

[0005] In short, according to one embodiment, aspects of the present disclosure generally relate to a system and method for enabling online payment processing from a payee's website without the payee having to process the payment data, using an embedded HTML document.

[0006] In various embodiments, the disclosed iFrame system enables online payments via an HTML document embedded within another HTML document on a payee website (e.g., an inline frame or iFrame, the embedded HTML document is an iFrame, and the HTML document in which the iFrame is embedded is referred to as an "iFrame container"), allowing payers (e.g., consumers, members, providers, etc.) to pay for transactions on a payee website (purchases, utility payments, fines, donations, membership fees, etc.) without requiring the payee (e.g., merchants, utilities, government agencies, non-profit organizations, 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 payee website to receive and accept payment data without displaying the payment data, and instead passes the payment data directly to the iFrame system for payment processing. In various embodiments, when a payer is entering payment data on a recipient website that includes an iFrame, the payer is generally not redirected to another website to do so, and it appears to the payer that the recipient 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 to the iFrame system along with other relevant transaction data (e.g., transaction price, transaction identifier, etc.). Thus, in various embodiments, the iFrame system determines the appropriate payment data corresponding to the transaction data and processes the transaction via the appropriate payment network (e.g., a credit card company, bank, miner, etc.).

[0008] In general, iFrame systems enhance transaction security by preventing the payee from accessing payment data. Furthermore, iFrame systems make transactions more efficient because the payer does not need to access another website and the payee does not need to perform complex transaction adjustment processes. In addition, iFrame systems allow the payee to have more granular control over how they handle less sensitive data provided by consumers (such as name, address, and contact information), meaning they can control what data they request and how they request it.

[0009] These and other aspects, features, and advantages of the invention described in one or more claims will become apparent from the following detailed description of preferred embodiments and aspects taken in connection with the following drawings, but changes and modifications thereto may be implemented without departing from the spirit and scope of the novel concept of the disclosure. [Brief explanation of the drawing]

[0010] The accompanying drawings illustrate one or more embodiments and / or aspects of the present disclosure and, together with the specification, serve to illustrate the principles of the present disclosure. Wherever possible, the same reference numerals are used throughout the drawings to refer to the same or similar elements of the embodiments. [Figure 1] An illustrative schematic diagram of one embodiment of the disclosed system is shown. [Figure 2] An exemplary architecture of one embodiment of the disclosed system is shown. [Figure 3] This is a flowchart illustrating an exemplary iFrame system process according to one embodiment of the present disclosure. [Figure 4] This flowchart shows an exemplary eToken generation process according to one embodiment of the present disclosure. [Figure 5] This is a flowchart illustrating an exemplary eToken trading process according to one embodiment of the present disclosure. [Figure 6] This is a flowchart illustrating an exemplary payment recipient system process according to one embodiment of the present disclosure. [Figure 7] An exemplary alternative architecture of one embodiment of the disclosed system is shown. [Modes for carrying out the invention]

[0011] To facilitate understanding of the principles of this disclosure, embodiments shown in the drawings will be used for reference and described in specific language. Nevertheless, it will be understood that no limitation of the scope of this disclosure is intended therein. Modifications and further alterations of the embodiments described or illustrated, and further applications of the principles of this disclosure illustrated in the specification, are intended to be as would be done by those skilled in the art to whom this disclosure relates. All limitations of scope should be determined as described in accordance with the claims.

[0012] Whether a term is capitalized or not is not considered a determination or limitation of the meaning of the term. As used in this specification, a term capitalized has the same meaning as a term not capitalized unless the context of use specifically indicates that a more restrictive meaning of the capitalized term is intended. However, the use or absence of capitalization in the remainder of this specification is not necessarily intended to be restrictive unless the context explicitly indicates that such restriction is intended.

[0013] overview According to one embodiment, aspects of the present disclosure generally relate to a system and method for enabling online payment processing from a payee's website without the payee having to process the payment data, using an embedded HTML document.

[0014] In various embodiments, the disclosed iFrame system enables online payments via an HTML document embedded within another HTML document on a payee website (e.g., an inline frame or iFrame, the embedded HTML document is an iFrame, and the HTML document in which the iFrame is embedded is referred to as an "iFrame container"), allowing payers (e.g., consumers, members, providers, etc.) to pay for transactions on a payee website (purchases, utility payments, fines, donations, membership fees, etc.) without requiring the payee (e.g., merchants, utilities, government agencies, nonprofit organizations, 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 payee website to receive and accept payment data without displaying the payment data, and instead passes the payment data directly to the iFrame system for payment processing. In various embodiments, when a payer is entering payment data on a recipient website that includes an iFrame, the payer is generally not redirected to another website to do so, and it appears to the payer that the recipient 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 to the iFrame system along with other relevant transaction data (e.g., transaction price, transaction identifier, consumer name, consumer address, etc.). 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., a credit card company, bank, miner, etc.).

[0016] Generally, iFrame systems enhance transaction security by preventing the payee from accessing payment data (this isolation restricts actions originating from a semi-trusted browser environment, potentially limiting them to verification, encryption, and temporary storage). For example, using an iFrame transforms the retrieval of payment data from a semi-trusted process where payment data is encrypted and stored only temporarily to a trusted process. This is because the generated eToken is only valuable / useful when combined with the payee's API key (e.g., a unique identifier corresponding to the payee). Therefore, hackers cannot manipulate transparent redirects to authorize (with or without access to the API key) using an iFrame. Furthermore, iFrame systems make transactions more efficient because the payer does not need to access another website and the payee does not need to perform complex transaction adjustment processes. In addition, iFrame systems allow payees to have more granular control over how they handle less sensitive data provided by consumers (e.g., name, address, contact information), that is, they can control what data they request and how they request it.

[0017] Exemplary Embodiments Referring here to the drawings, Figure 1 shows an exemplary schematic diagram 1000 of one embodiment of the iFrame system 300 for the purpose of illustrating and describing the basic processes and components of the disclosed system and method. To be understood and recognized, the exemplary schematic diagram 1000 shown in Figure 1 represents only a particular approach or embodiment of the System, and other aspects are used according to various embodiments of the System. Generally, as an example rather than an limitation, the schematic diagram 1000 is shown in Figure 1 using a series of numbered steps indicated as steps "1" through "5", these steps 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), allowing payers 102 (e.g., consumers, members, providers, etc.) to pay for transactions on the payee website 602 (purchases, utility payments, fines, donations, membership fees, etc.) without requiring the payee 600 (e.g., merchants, utilities, government agencies, non-profit organizations, etc.) to process the payer's 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, and instead passes the payment data directly to the iFrame system 300 for payment processing. In various embodiments, when payer 102 is entering payment data into website 602 deploying the disclosed system and method, payer 102 is generally not redirected to another website to do so, and payer 102 appears to the payee 600 to be receiving the payment data directly. A more detailed example is useful for further illustrating payment processing via iFrame system 300.

[0019] In certain non-limiting examples, a merchant 600 that sells items (e.g., pet supplies, clothing, kitchenware, etc.) directly to consumers on the Internet 104 may deploy its website 602 to accept payments via an iFrame system 300, as further disclosed herein. Generally, continuing this example, after a consumer 102 of the merchant has decided on the items they wish to purchase, added them to their online shopping cart, and is ready to complete their order and make a payment, the consumer 102 is directed to the payment page of 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 directly enter payment data into the iFrame system 300 via the merchant website 602. Generally, the iFrame (using the JavaScript SDK) allows for customization of the user interface to display current and / or custom fonts, styles, languages, and layouts (which all match those used on the receiving website 602, so that the iFrame does not appear different from the rest of the receiving website 602). Thus, in the payment page, in step 1, in various embodiments, the consumer 102 is instructed to enter payment data into the provided space of the iFrame depending on the selected payment method, while other relevant / necessary low-confidentiality 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 supplied directly to the iFrame controller 400 of the iFrame system 300 for eToken generation via an iFrame on the merchant website 602. In various embodiments, the eToken includes an encrypted identifier used by the iFrame system 300 and the merchant website 602 to identify the supplied payment data. In various embodiments, when a consumer enters payment data, the payment data is provided to the iFrame controller 400 automatically and in real time for eToken generation. In an alternative embodiment, the payment data is supplied to the iFrame controller only when the consumer 102 affirms doing so (for example, 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, and 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 gives an affirmative confirmation in step 3, for payment processing in step 4, the merchant website 602 sends transaction data (e.g., eToken, transaction price, transaction identifier, etc.) to the eToken transaction processor 500 within the iFrame system 300. Thus, the eToken transaction processor 500 receives the payment data and, in one embodiment, processes the payment through an appropriate payment network 106 (e.g., 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 actions. For example, if the payment is confirmed, the merchant 600 may, in step 5, provide an order confirmation page to the merchant website 602 and ship the ordered items to the consumer 102. However, if the payment is not confirmed, the merchant 600 displays a transaction invalid page on the merchant website 602 to enable the consumer 102 to provide new payment data or request the processing of the transaction again. Thus, the iFrame system 300 enables online payment on the merchant website 602 through the use of an iFrame that directly authorizes payment on the merchant website 602 without the merchant 600 viewing the payment data for that transaction.

[0022] Referring next to Figure 2, an exemplary architecture 2000 of one embodiment of the disclosed iFrame system 300 is shown. In various embodiments, the exemplary iFrame system 300 is operably connected to one or more payment destination 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., secure or insecure connection, Bluetooth, wireless or wired local area network (LAN), cell network, internet, etc.). As shown in Figure 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 capable of performing the functions disclosed herein (e.g., a desktop computer, laptop, server, tablet, etc.), a combination of multiple computing devices, software, hardware, or a combination of software and hardware, the details of which will be described in connection with the description of Figures 1 and 3. An 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 performs an eToken generation process (the details of which will be described in connection with the description of Figure 4), communicates with the payment destination website 602 and the system databases 202, and may be any computing device capable of performing the functions disclosed herein (e.g., a desktop computer, laptop, server, tablet, etc.), a combination of multiple computing devices, software, hardware, or a combination of software and hardware. In one embodiment, the eToken transaction processor 500 executes an eToken processing process (details of which are described in relation to the description of Figure 5), communicates with one or more payee servers 604 and a system database 202, and may be any computing device (e.g., a desktop computer, laptop, server, tablet, etc.), a combination of multiple computing devices, software, hardware, or a combination of software and hardware capable of performing the functions disclosed herein. In various embodiments, the system database 202 may be any computing device (e.g., a desktop computer, laptop, server, tablet, etc.), a combination of multiple computing devices, software, hardware, a combination of software and hardware, a database (e.g., stored in the cloud or on-premises and structured as relational), or a combination of multiple databases capable of performing the functions disclosed herein.

[0024] In various embodiments, an 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 can be any computing device (e.g., desktop computer, laptop, server, tablet, etc.), a combination of multiple 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 connection with the descriptions of FIGS. 1 and 6. In one embodiment, the payee website 602 can be a website, mobile application, web page, collection of multiple web pages, or other hardware / software (or combination thereof) capable of performing the functions disclosed herein. In one embodiment, the payee server 604 hosts the payee website 602, communicates with the eToken transaction processor 500, and can be any computing device (e.g., desktop computer, laptop, server, tablet, etc.), a combination of multiple computing devices, software, hardware, or a combination of software and hardware capable of performing the functions disclosed herein.

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

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

[0027] In general, a payment network 106 settles financial transactions and 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.), a combination of computing devices, software, hardware, or a combination of software and hardware, that is capable of performing the functions disclosed herein. As will be apparent to those skilled in the art, this disclosure does not limit the types of payment networks 106 used as described herein.

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

[0029] In various embodiments, the exemplary iFrame system process 3000 starts in step 301, and the iFrame system 300 receives a request via an iFrame on the recipient 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 starts when the iFrame system 300 generates / creates an iFrame to generate the request (in various embodiments, the iFrame contains a first HTML document linked to / hosted by the iFrame system 602 and embedded in a second HTML document (also known as an iFrame container) placed on the recipient website, in which case the recipient website 602 does not have access to / visibility to the data processed by the first HTML document (typically payment data)). In various embodiments, the SDK supports configuration options to automatically generate an iFrame styled to the recipient's preferences on the recipient website 602. Generally, a 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 gives a positive confirmation to do so (e.g., by clicking the "Pay Now" button). In one embodiment, the request may include payment data. In one embodiment, the iFrame may supply payment data to the iFrame controller 400 separately from the request. Thus, in various embodiments, to generate an eToken, the iFrame system 300 initiates an eToken generation process 4000 via the iFrame controller 400, further details of which are described in relation to the description in Figure 4.

[0030] Once an eToken is generated (as part of process 4000), in step 303, in one embodiment, the iFrame system 300 sends the eToken to the payee system 600 if it is associated with a specific transaction in question (for example, by passing the eToken to the payee server 604 using the SDK's callback function) (for example, the eToken is passed from the iFrame system 300 to a first HTML document on the payee website 602 via network 104, the first HTML document passes the eToken to the iFrame container, and the eToken is picked up by the JavaScript SDK). In various embodiments, the iFrame system 300 receives a request to process the payment for a transaction in step 305. Generally, a request to process a payment includes transaction data corresponding to the transaction (such as the invoice amount, eToken, transaction identifier, consumer name, and consumer contact information). Thus, in order to process the transaction, in various embodiments, the iFrame system 300 starts an eToken transaction process 5000 using an eToken transaction processor 500, the details of which are described in relation to the description in Figure 5.

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

[0032] Referring next to Figure 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 the process by which the iFrame controller 400 generates an eToken representing / corresponding to payment data entered by the payer 102. As will be apparent to those skilled in the art, the present disclosure does not limit the types of payment data accepted by the iFrame system 300 (e.g., credit cards, debit cards, bank accounts, 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 another system / method, so that an unauthorized third party cannot access / use the data represented by the eToken.

[0033] In various embodiments, the exemplary eToken generation process 4000 begins in step 401, in which the iFrame controller 400 receives payment data from an iFrame on the recipient website 602. In one embodiment, the iFrame validates the payment data before sending it to the iFrame system 300 (for example, ensuring that it meets certain formatting criteria such as the correct length of the credit card number, credit matching value, routing number, and correct date format, ensuring that it has all the necessary payment data, and ensuring that it is from a real payer 102 and not a bot).

[0034] In general, in step 403, the iFrame controller 400 performs additional security checks on the received payment data (e.g., the payment data is received in the expected format, the payment data is signed with a proper signature) to ensure that the correct payment data has been received and that the received payment data is not from a malicious attack (e.g., a third party impersonating an iFrame to gain access to 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. Furthermore, in step 407, in various embodiments, the iFrame controller 400 generates an eToken corresponding to the payment data, 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 exemplary eToken generation process 400 terminates. 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 the appropriate security personnel, monitoring the payment data, etc.), after which the exemplary eToken generation process 400 terminates.

[0036] Referring next to Figure 5, a flowchart of an exemplary eToken transaction process 5000 according to one embodiment of the present disclosure is shown. Generally, the eToken transaction process 5000 is the process by which the eToken transaction processor 500 processes a transaction requested by the payer 102.

[0037] In various embodiments, the exemplary eToken transaction process 5000 begins in step 501, in which the eToken transaction processor 500 receives transaction data from one or more payee servers 604. Generally, in step 503, the eToken transaction processor 500 verifies the transaction data (e.g., eToken, payee, etc.) to confirm that the correct transaction data has been received and that the received transaction data is not a result of a malicious attack (e.g., a third party impersonating the payee 600 and processing a fraudulent 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.) that begins after the eToken is generated (e.g., in step 407), the eToken transaction processor does not verify 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 (for example, in one embodiment, it is necessary to first decrypt the eToken to determine if it is a valid eToken), and processes the transaction via the appropriate payment network 106 according to other information in the transaction data. Furthermore, in step 507, in various embodiments, the eToken transaction processor 500 compiles a set of transaction results (e.g., payment confirmation, payment rejection, etc.) for transmission to the payment destination system 600, and then the exemplary eToken transaction process 500 terminates.

[0039] However, if the transaction data cannot be verified, the eToken transaction processor 500 takes appropriate action in step 509 (e.g., sending an error message, notifying the appropriate security officer, logging the error, etc.) in various embodiments, after which the exemplary eToken transaction process 500 terminates. In one embodiment, in step 509, an error message in an iFrame is displayed to the payer, blanking / highlighting the error data field and masking the remaining correct data fields (e.g., completely or partially hidden) so that the payer can re-enter the error data. In one embodiment, the error field is taken from the appropriate eToken and one or more masked data objects (sent via the JavaScript SDK). If the payer does not modify the data in the data field, the eToken and one or more masked data objects remain unchanged. However, if the payer modifies any of the data in the data field (e.g., the error field, the masked field, etc.), the new data is used to generate a new eToken and / or masked data objects.

[0040] Referring next to Figure 6, a flowchart of an exemplary payee system process 6000 according to one embodiment of the present disclosure is shown. Generally, the exemplary payee system process 6000 is a process that enables the payee system 600 to make online payments to payee 600 as part of an online transaction initiated through the payee website 602.

[0041] In various embodiments, an exemplary payee system process 6000 begins with step 601, in which 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 validated, 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 an eToken in step 603, in one embodiment, the payee 600 may be configured to send an error message to the payer 102 or to request additional information from the payer 102.

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

[0043] In various embodiments, one or more payee servers 604 receive the result of the transaction processing in step 611. In one embodiment, in step 613, one or more payee servers 604 display the result of the transaction processing on the payee website 602 (e.g., order confirmation if payment is successful, request for additional information or rejection of the transaction if payment is unsuccessful), and the exemplary payee system process 6000 then terminates.

[0044] Referring now to Figure 7, an exemplary alternative architecture 7000 of one embodiment of the disclosed iFrame system 300 is shown. Generally, the exemplary alternative architecture 7000 is the same as the exemplary architecture 2000 (shown in Figure 2), and unless otherwise stated, the description of Figure 2 (and Figures 3-6) is also applicable to Figure 7. In various embodiments, the exemplary iFrame system 300 is operably connected via a network 104 to one or more payment destination systems 600 and one or more payment gateways 700 to run 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 decrypts a plurality of eTokens (in one embodiment, as part of an eToken transaction process 5000), communicates with one or more payee servers 604, the system databases 202, and one or more gateway servers 702, and may be any computing device (e.g., a desktop computer, laptop, server, tablet, etc.), a combination of multiple computing devices, software, hardware, or a combination of software and hardware capable of performing the functions disclosed herein.

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

[0047] Continuing with the embodiment shown in Figure 7, the system database 202 holds 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-confidential transaction data, such as the consumer's name and address, in at least one embodiment). In these embodiments, one or more gateway servers 702 then send the eToken to an eToken decryption processor 502, where the eToken is verified (e.g., decrypting the eToken, verifying that it is a valid eToken, verifying that the eToken was received within a valid time frame, etc.), the encrypted cardholder data is retrieved from the system database 202 (or otherwise received), the cardholder data is decrypted and sent back to one or more gateway servers 702. As understood, when one or more gateway servers 702 receive unencrypted cardholder data, the payment gateway 700 may process the cardholder data via the payment network 106 (for example, in steps 503-509 of the eToken transaction process 5000) and report the results of the processing to the recipient server 604.

[0048] From the above, it should be understood that the various aspects of the processes described herein are multiple software processes running on multiple computer systems that form multiple parts of a system. Accordingly, it will be understood that the various embodiments of the systems described herein generally embody a specially configured computer including various computer hardware components and often have important additional features compared to conventional or known computers, processes, etc., as will be described in more detail herein. Embodiments within the scope of this disclosure also include a computer-readable medium for carrying or having multiple computer-executable instructions or multiple data structures. Such a computer-readable medium may be any available medium that is accessible by a computer or downloadable via a communication network. For example, but not limited to, such computer-readable media may include any type of removable non-volatile memory such as RAM, ROM, flash memory, EEPROM, CD-ROM, DVD, or other optical disk storage devices, magnetic disk storage devices, solid state drives (SSDs), other data storage devices, secure digital (SD), flash memory, memory sticks, or any other media accessible by a computer that can be used to transfer or store computer program code in the form of computer-executable instructions or data structures.

[0049] When information is transferred to or provided to a computer via a network or another communication connection (wired, wireless, or a combination of wired and wireless), the computer appropriately recognizes that connection as computer-readable medium. Therefore, such a connection is appropriately called and considered computer-readable medium. The aforementioned combinations should also be included within the scope of computer-readable medium. Computer-executable instructions include, for example, instructions and data that cause a computer to perform a specific function or a group of functions.

[0050] Those skilled in the art will understand the characteristics and aspects of suitable computing environments in which aspects of this disclosure may be implemented. While not essential, some embodiments of the systems described in the claims may be described in the context of computer executable instructions, such as program modules or engines, executed by computers in a networked environment, as previously described. 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, such as local or remote computers, that perform specific tasks within the computer or implement specific defined data types. Computer executable instructions, associated data structures and / or schemas, and program modules illustrate multiple examples of program code for performing steps of the methods disclosed herein. Specific sequences of such executable instructions or associated data structures illustrate multiple examples of corresponding actions to enable the functionality described in such steps.

[0051] Those skilled in the art will also understand that the systems and methods described and / or described in the claims may be implemented in network 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, and mainframe computers. Embodiments of the systems (and / or methods) described in the claims are implemented in a distributed computing environment in which multiple tasks are performed by local and remote processing devices linked over a communication network (by hardwired, wireless link, or a combination of hardwired and wireless link). In a distributed computing environment, multiple program modules may be located in both local and remote memory storage devices.

[0052] Exemplary systems for embodying various aspects of operation not described include computing devices including processing units, system memory, and a system bus that connects various system components, including system memory, to the processing units. A computer typically includes one or more data storage devices for reading and writing data. The data storage devices provide non-volatile storage for instructions, data structures, program modules, and other data for the computer that can be executed by the computer.

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

[0054] The computers influencing many aspects of the processes described typically operate in a networked environment using logical connections to one or more remote computers or data sources, which are further described below. Remote computers can be other personal computers, servers, routers, network PCs, peer devices, or other common network nodes, and typically include 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 as examples in this specification. Such network environments are common in office-wide or enterprise-wide computer networks, intranets, and the internet.

[0055] When used in a LAN or WLAN network environment, the computer system embodying the system configuration is connected to the local network via a network interface or adapter. When used in a WAN or WLAN network environment, the computer may include other mechanisms for establishing communication over a wide area network such as a modem, wireless link, or the Internet. In a networked environment, the program modules or parts thereof shown in relation to the computer may be stored in remote data storage. The network connections described or illustrated are illustrative, and it should be understood that other mechanisms for establishing communication over a wide area network or the Internet may be used.

[0056] Alternative modes Next, various embodiments of the system and method will be described. It will be understood by those skilled in the art that any of the following embodiments may incorporate and include features of other embodiments described below or features described herein. Accordingly, the following embodiments should be understood to include any combination of embodiments and not to be limited to the combinations presented below. For example, the second embodiment includes the computer system of the first embodiment, but may also include features of the 26th embodiment, the first embodiment, or the 100th embodiment.

[0057] A system according to the first embodiment includes an iFrame controller which performs the following actions: creating an iFrame on a merchant website hosted on a server; receiving payment data corresponding to a transaction on the merchant website from the iFrame; encrypting and storing the received payment data; generating an eToken corresponding to the encrypted payment data; and sending the eToken to a server, wherein the server sends the eToken to a payment gateway server and sends the eToken to a server; and an eToken decryption processor which performs the following actions: receiving an eToken from a payment gateway server; authenticating the eToken and determining the corresponding encrypted payment data; decrypting the encrypted payment data; and sending the decrypted payment data to the payment gateway server for processing the transaction.

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

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

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

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

[0062] In a system or method according to the sixth aspect or any other aspect, as described in the seventh aspect, the eToken decryption processor decrypts the eToken before authenticating it.

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

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

[0065] In a system or method according to the first aspect or any other aspect, as described in the tenth aspect, the iFrame controller creates an iFrame at least in part on input from an iFrame Builder user interface that enables a merchant to input multiple iFrame parameters.

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

[0067] A method according to the 12th aspect is a method comprising: creating an iFrame on a merchant website hosted on a server; receiving payment data corresponding to a transaction on the merchant website from the iFrame; encrypting the received payment data; storing the encrypted payment data; generating an eToken corresponding to the encrypted payment data; and sending the eToken to a server, wherein the server sends the eToken to a payment gateway server; sends the eToken to a server; receives an eToken from a payment gateway server; authenticates the eToken to determine the corresponding encrypted payment data; decrypts the encrypted payment data; and sends the decrypted payment data to the payment gateway server for processing the transaction.

[0068] In a system or method according to the 12th aspect or any other aspect, as described in the 13th aspect, the iFrame includes a first HTML document embedded within a second HTML document.

[0069] In a system or method according to the 12th aspect or any other aspect, as described in the 14th aspect, the received payment data includes at least one of the following: credit card number, credit card expiration date, credit card verification value, bank account routing number, debit card number, debit card expiration date, or PIN number.

[0070] In a system or method according to the 12th aspect or any other aspect, as described in the 15th aspect, payment data is not accessible by the merchant website or server.

[0071] In a system or method according to the 12th aspect or any other aspect, as described in the 16th aspect, the payment gateway server is managed separately from the server. A system or method in the 12th aspect or any other aspect, according to the 17th aspect, further comprises encrypting the eToken before sending it to the server.

[0072] A system or method in the 12th aspect or any other aspect, according to the 18th aspect, further comprises decrypting the eToken before authenticating the eToken. A system according to the 19th aspect comprises a website hosted on a server, the website including an iFrame, the iFrame receiving payment data corresponding to transactions on the website and generated by an iFrame controller; and a server performing the following: receiving an eToken corresponding to the payment data received from the iFrame controller; generating transaction data corresponding to the transaction and including an eToken and non-confidential payment data; sending 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 a system or method according to the 20th aspect, the 19th aspect, or any other aspect, the payment gateway server sends an eToken to an eToken decryption processor operably connected to the iFrame controller, and the database stores the received payment data.

[0074] In a system or method according to the 20th aspect or any other aspect, as described in the 21st aspect, in response to sending an eToken to an eToken decryption processor, the payment gateway server receives the received payment data.

[0075] In a system or method according to the 19th aspect or any other aspect, as described in the 22nd aspect, the iFrame includes a first HTML document embedded within a second HTML document.

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

[0077] In a system or method according to the 23rd aspect or any other aspect, as described in the 24th aspect, payment data is not accessible by the website or server. In a system or method according to the 24th aspect or any other aspect, as described in the 25th aspect, the non-confidential payment data includes at least one of the following: a transaction identifier, a transaction price, and contact information.

[0078] In a system or method according to the 25th aspect or any other aspect, as described in the 26th aspect, the payment gateway server is managed separately from the server. A method according to the 27th aspect is hosting a website including an iFrame, the iFrame comprising: receiving payment data corresponding to a transaction on the website; receiving an eToken corresponding to the received payment data; generating transaction data corresponding to a transaction and including an eToken and non-confidential payment data; transmitting the transaction data to process the transaction; and receiving at least one processing result.

[0079] In a system or method according to the 27th aspect or any other aspect, as described in the 28th aspect, the iFrame includes a first HTML document embedded within a second HTML document.

[0080] In a system or method according to the 28th aspect or any other aspect, as described in the 29th aspect, the received payment data includes at least one of the following: credit card number, credit card expiration date, credit card verification value, bank account routing number, debit card number, debit card expiration date, or PIN number.

[0081] In a system or method according to the 30th aspect, the 29th aspect, or any other aspect, payment data is not accessible by the website. In a system or method according to the 30th aspect or any other aspect, in accordance with the 31st aspect, the non-confidential payment data includes at least one of the following: a transaction identifier, a transaction price, and contact information.

[0082] A system according to the 32nd aspect includes an iFrame controller which performs the following: creating an iFrame on a merchant website hosted on a server; receiving payment data corresponding to a transaction on the merchant website from the iFrame; generating an eToken corresponding to the received payment data; and sending the eToken to the server; and an eToken transaction processor which performs the following: receiving transaction data from the server which includes an eToken and non-confidential payment data corresponding to a transaction; 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.

[0083] In a system or method according to the 32nd aspect or any other aspect, as described in the 33rd aspect, the iFrame includes a first HTML document embedded within a second HTML document.

[0084] In a system or method according to the 32nd aspect or any other aspect, as described in the 34th aspect, the received payment data includes at least one of the following: credit card number, credit card expiration date, credit card verification value, bank account routing number, debit card number, debit card expiration date, or PIN number.

[0085] In a system or method according to the 34th aspect or any other aspect, as described in the 35th aspect, payment data is not accessible by the merchant website or server.

[0086] In a system or method according to the 32nd aspect or any other aspect, in accordance with the 36th aspect, non-confidential payment data includes at least one of a transaction identifier, a transaction price, and contact information.

[0087] In a system or method according to the 32nd aspect or any other aspect, as described in the 37th aspect, the iFrame controller encrypts the eToken before sending it to the server.

[0088] In a system or method according to the 37th aspect or any other aspect, as described in the 38th aspect, the eToken transaction processor decrypts the eToken before authenticating it.

[0089] In a system or method according to the 32nd aspect or any other aspect, as described in the 39th aspect, the eToken transaction processor transmits payment data and at least a portion of transaction data to the payment network in order to process the transaction.

[0090] A method according to the 40th aspect comprises: creating an iFrame on a merchant website hosted on a server; receiving payment data corresponding to a transaction on the merchant website from the iFrame; generating an eToken corresponding to the received payment data; sending the eToken to the server; receiving transaction data from the server that corresponds to the transaction and includes an eToken and non-confidential payment data; authenticating the eToken to determine the corresponding received payment data; and processing the transaction using the received payment data based on the received transaction data.

[0091] In a system or method according to the 40th aspect or any other aspect, as described in the 41st aspect, the iFrame includes a first HTML document embedded within a second HTML document.

[0092] In a system or method according to the 40th aspect or any other aspect, as described in the 42nd aspect, the received payment data includes at least one of the following: credit card number, credit card expiration date, credit card verification value, bank account routing number, debit card number, debit card expiration date, or PIN number.

[0093] In a system or method according to the 43rd aspect, the 42nd aspect, or any other aspect, payment data is not accessible by the merchant website or server.

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

[0095] A system or method in the 40th aspect or any other aspect, according to the 45th aspect, further comprises encrypting the eToken before sending it to the server.

[0096] A system or method in the 45th aspect or any other aspect, according to the 46th aspect, further comprises decrypting the eToken before authenticating the eToken. Processing a transaction in a system or method according to the 47th aspect, the 40th aspect, or any other aspect, further includes transmitting payment data and at least a portion of transaction data to a payment network in order to process the transaction.

[0097] A system according to the 48th aspect comprises a website hosted on a server, the website including an iFrame, the iFrame receiving payment data corresponding to transactions on the website and generated by an iFrame controller; and a server performing the following: receiving an eToken corresponding to the payment data received from the iFrame controller; generating transaction data corresponding to the transaction and including an eToken and non-confidential payment data; sending the transaction data to an eToken transaction processor to process the transaction; and receiving at least one processing result from the eToken transaction processor.

[0098] In a system or method according to the 48th aspect or any other aspect, as described in the 49th aspect, the iFrame includes a first HTML document embedded within a second HTML document.

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

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

[0101] conclusion While various embodiments have been described in relation to preferred embodiments, additional embodiments, features, and methods of the system described in the claims will be readily identifiable to those skilled in the art from the description herein. Many embodiments and adaptations of the system described in the claims, as well as many variations, modifications, and equivalent configurations and methods, will be apparent from this disclosure and its preceding description, or reasonably suggested by this disclosure and its description, without departing from the content or scope of the claims. Furthermore, any sequence and / or temporal order of multiple steps of various processes described herein and described in the claims is considered to be the best possible mode for performing the system described in the claims. While multiple steps of various processes may be shown and described as a preferred sequence or temporal order, it should be understood that such multiple steps of a process are not limited to being performed in a specific sequence or order unless there is such specific instruction to achieve a particular intended result. Often, multiple steps of such a process can be performed in various different sequences and orders, but still within the scope of the system described in the claims. Furthermore, some steps may be performed simultaneously, in the same period, or in sync with other steps.

[0102] To enable those skilled in the art to use the system and various embodiments, embodiments have been selected and described to illustrate the principles of the claimed system and their practical applications, and various modifications are suitable for the specific intended use. Alternative embodiments will be apparent to those skilled in the art to which the system belongs without departing from the spirit and scope of the claimed system. Therefore, the scope of the claimed system is defined by the appended claims, rather than by the above description and the exemplary embodiments described herein.

Claims

1. It is a system, iFrame controller, Receiving payment data from iFrame corresponding to transactions on merchant websites hosted on the server, To verify the aforementioned payment data, The received payment data is encrypted and stored, Receiving a request to generate an eToken corresponding to the payment data, wherein the request to generate the eToken is received separately from the payment data, and receiving the request. In response to the aforementioned request, generate the eToken corresponding to the payment data, The iFrame controller is configured to perform the following actions: send the eToken so that the server can use the eToken to request payment; It is an eToken processor, Following the iFrame controller transmitting the eToken, it receives the eToken, Authenticating the received eToken and determining the payment data corresponding to the eToken, Decrypting the encrypted payment data, A system comprising: an eToken processor configured to transmit the decrypted payment data in response to an eToken received, so that the payment network can use the decrypted payment data to process a request from the server for the payment;

2. The system according to claim 1, wherein the iFrame includes a first HTML document embedded within a second HTML document.

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

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

5. The system according to claim 1, wherein the iFrame controller is configured to encrypt the eToken before transmitting it.

6. The system according to claim 5, wherein the eToken processor is configured to decrypt the received eToken before authenticating the received eToken.

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

8. The system according to claim 1, wherein the eToken processor is configured to receive the eToken from the payment gateway.

9. The system according to claim 8, wherein the eToken processor is configured to transmit the decrypted payment data to the payment gateway server in response to the received eToken.

10. The merchant website is hosted on the server, and the merchant website further comprises the merchant website including iFrame, and the server is Receiving the eToken corresponding to the payment data from the iFrame controller, To generate transaction data corresponding to the aforementioned transaction and including the eToken and non-confidential payment data, To process the aforementioned transaction, the transaction data is transmitted to the payment gateway server, The system according to claim 1, configured to receive at least one processing result from the payment gateway server.

11. The system according to claim 10, wherein the payment gateway server is configured to transmit the eToken to the eToken processor.

12. The system according to claim 11, wherein the eToken processor is configured to transmit the decrypted payment data to the payment gateway server in response to the received eToken.

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

14. It is a method, Receiving payment data from iFrame corresponding to transactions on merchant websites hosted on the server, To verify the aforementioned payment data, The received payment data is encrypted and stored, Receiving a request to generate an eToken corresponding to the payment data, wherein the request to generate the eToken is received separately from the payment data, and receiving the request. In response to the aforementioned request, generate the eToken corresponding to the payment data, Sending the eToken so that the server can use it to request payment, Following the transmission of the aforementioned eToken, the recipient receives the aforementioned eToken. Authenticating the received eToken and determining the payment data corresponding to the eToken, Decrypting the encrypted payment data, A method comprising transmitting the decrypted payment data in response to a received eToken so that the payment network can use the decrypted payment data to process a request from the server for the payment.

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

16. The method according to claim 15, wherein the payment data is not accessible by the merchant website or the server.

17. The method according to claim 14, wherein receiving the eToken includes receiving the eToken from a payment gateway.

18. The method according to claim 17, wherein transmitting the decrypted data includes transmitting the decrypted data to the payment gateway server in response to receiving the eToken.

Images