Online retailers and other organizations that accept sensitive information via the web must balance creating a simple, convenient, intuitive customer experience with maintaining sufficient data protection and compliance practices. An uncompromising solution that accomplishes both is the TokenEx iFrame.
TokenEx’s iFrame enables your organization to tokenize sensitive data directly from your checkout page or other web form. As a result, you can protect sensitive data at the point of acceptance to prevent it from entering your internal systems—all while maintaining the existing look and feel of your website. Here’s a high-level overview of the process.
- You add code, utilizing the TokenEx iFrame Library, to your checkout page or submission form specifying how and where the iFrame should appear.
- TokenEx captures sensitive data from specified fields once the user completes the form.
- TokenEx tokenizes sensitive data and returns a token to your web server for use in internal systems and business processes.
For the technically inclined, this is a fairly simple process. But for those who are unfamiliar with this type of technology—or those who would like to better understand its functionality—let’s take a deeper look at how the iFrame itself works.
Understanding the iFrame
Usually when we’re talking about the iFrame, we’re talking about a web form within a parent page. At its core, a web page is a collection of code rendered by a web browser. The browser reads the code contained within the website and then renders a display with which users interact to navigate the page.
Put simply, the iFrame is an HTML element that displays a web page within a web page. So if you think about an ecommerce checkout page, it contains a web form with several HTML inputs for a credit card number, security code, first name, last name, and other necessary information to complete a transaction. Each of these fields can include an iFrame that enables you to connect your web form to TokenEx and capture the sensitive data entered within it.
Once the iFrame is implemented, any content entered into its fields doesn’t actually traverse the customer’s network. Even though the field appears on the customer’s website, it goes directly to our network environment. Further, it is designed to look like an input field in a form so as to minimally affect the appearance of the existing page—even allowing for custom CSS configurations to determine the appearance of the field itself.
Here’s a mockup taken from our iFrame demo page showing what this might look like from the browser side.
You’ll notice the iFrame demo page has three modes: PCI, PCI w/ CVV, CVV only, and Non-PCI mode. These are fairly straightforward configurations of the iFrame, and they're described in the table below.
|PCI||Render one iFrame for the card number field|
|PCI w/ CVV||Render one iFrame for the card number field and one for the CVV or security code|
|CVV Only||Renders one field for the CVV or security code|
|Non-PCI Mode||Renders field for data other than cardholder data (SSNs, ACH account numbers, etc.)|
By hosting an iFrame in our secure environment, we prevent any information entered into the specified fields from entering our client’s web servers and downstream systems. In effect, by preventing them from ingesting sensitive data, we keep them from introducing risk and scope.
Here’s an example of what’s going on behind the scenes on a web page containing a TokenEx iFrame.
You can see that the iFrame has a TokenEx domain. That’s the key. When you type data into that field, even though it appears as if it’s being entered into the client’s website, it’s not. It’s being typed into TokenEx’s hosted iFrame, which appears within the client’s specified fields.
TokenEx customers can implement as many iFrames as they want, and each is configured independently. This enables you to customize the functionality and appearance of your checkout page to meet your unique needs. Here’s an example of a customer using the TokenEx iFrame on its checkout page.
Notice how the iFrame appears in the same style as the rest of the checkout page. This is because the iFrame itself is customizable. We enable you to transmit information from the TokenEx iFrame to your parent page and communicate in real-time, which allows you to implement the iFrame without modifying the look, feel, or functionality of the parent page.
This customization also includes the ability to transmit JSON data. This allows TokenEx to tell the page what card type is being entered and whether it’s a valid number so it can then respond with dynamic visual cues and triggers for the user.
For example, here’s what it might look like to enter an invalid card number, which appears in red.
Once a user has entered its information into the various iFrame fields, it can submit the form, which results in a call to tokenize. After the user submits the data by clicking the HTML button within the iFrame, an event listener will trigger a call to tokenize to generate a token for the data that was entered into the iFrame.
Once the data is tokenized, the customer will receive a response. The below response from "Iframe Tokenize" shows the first six and last four digits of the PAN, the token, a reference number, a hash to confirm the tokenized value, and then the card type.
At this point, the transaction is complete and the sensitive data included within it is secure. It’s that simple.
Protect Sensitive Data Before it Enters Your Environment
Rather than redirecting every element on your checkout page to TokenEx to create a separate hosted payment page, you can use HTML iFrame code to capture data from your website without modifying its look and feel. All sensitive data captured by the iFrame is tokenized before it reaches your environment, minimizing scope and maximizing security.
Additionally, the TokenEx Cloud Data Protection Platform can help preserve the utility of customer data, simplify internal processes and systems, and support crucial business operations—such as the ability to work with multiple processors, gateways, and other PSPs.