Overview
CardConnect's Hosted iFrame Tokenizer solution captures code (HTML, JavaScript, and Java) associated with a CardSecure token value of a credit number within an iFrame. Per the Payment Card Industry (PCI) Data Security Standards, a merchant's PCI compliance requirements are reduced when encasing token functionality in an iFrame and hosting that iFrame with CardSecure.
The instructions in this article provide one possible approach to housing the client-side code responsible for generating payment authorization tokens by calling the Hosted iFrame Tokenizer. Its intent is to illustrate the concept of calling the hosted iFrame. Provided the requirement that all token generation related client-side code is embedded within an iFrame is met and that the iFrame is hosted by CardConnect, you may elect to alter your implementation as you wish.
About CardConnect Tokens
CardConnect tokens never expire.
Payment card tokens are generally 16-digit numeric tokens with the following characteristics:
- The token begins with a 9.
- The second and third digits of a token represent the first and second digits of the card.
- The last 4 digits of the token represent the last 4 digits of the card.
Tokenizer Page Sample URL (with LUHN Validation)
https://fts.cardconnect.com:6443/itoke/outer-page-validation.html
See more on this type of validation here.
Tokenizer Page Sample URL (without LUHN Validation)
https://fts.cardconnect.com:6443/itoke/outer-page.html
iFrame Tokenizer Sample Page
The iFrame Tokenizer field example below shows how this field may be incorporated onto a web page to securely accept entry of a credit card number and tokenize it. The field is coded to turn red for a number that does not pass the Luhn check. Once you tab off the field, the listener and page bring up a message box showing you the tokenized value.
This code could be leveraged on a page that collects additional information needed to process the payment (name, expiration, CVV, and any other information needed for your business need) and process the payment using CardConnect API calls for Authorization, Capture, etc
Implementing the Hosted iFrame
Submitting a token as part of a payment authorization is the responsibility of web page implementers. This section outlines how to place the client-side web service call made via JavaScript and Hosted iFrame within an iFrame. The instructions also detail the process of passing values between the primary payment page and the embedded iFrame. The following examples have been taken from the reference implementation listed above.
For web pages that may be accessed from a mobile device, add the "tokenizewheninactive" & "inactivityto" optional parameters.
- On the primary payment page, place a hidden input field to store the token after it is generated within the iframe.
Hidden Input on the Primary Page to Hold the Generated Token
<form name="tokenform" id="tokenform">
...
<input type="hidden" name="token"/>
...
</form>
- Attach a listener to detect when token generation is complete and assign the value to the input field above.
Primary Payment Page Event Listener
<script language="JavaScript">
window.addEventListener('message', function(event) {
var token = JSON.parse(event.data);
var mytoken = document.getElementById('mytoken');
mytoken.value = token.message;
}, false);
</script>
- Where the clear text credit card number is entered, place a reference to the embedded iframe page; styling the iframe element on the primary payment page as needed.
Primary Payment Page Reference to iFrame
<form name="order" method="POST">
...
<iframe id="tokenFrame" name="tokenFrame" src="itoke/ajax-tokenizer.html" frameborder="0" scrolling="no"/>
...
</form>
- Putting it all together: the following HTML snippet shows key elements of the primary payment page.
Primary Payment Page Key Elements
<html>
...
<head>
...
<script language="JavaScript">
window.addEventListener('message', function(event) {
var token = JSON.parse(event.data);
var mytoken = document.getElementById('mytoken');
mytoken.value = token.message;
}, false);
</script>
...
</head>
<body>
<form name="tokenform" id="tokenform">
<iframe id="tokenFrame" name="tokenFrame" src="itoke/ajax-tokenizer.html" frameborder="0" scrolling="no"/>
...
<input type="hidden" name="token"/>
...
</form>
</body>
</html>
iFrame Location
In the above example, the src value for the iFrame is "itoke/ajax-tokenizer.html".
In an actual implementation, the src value must also include the full production URL, including a port number if it exists.
Example
<iframe id="tokenFrame" name="tokenFrame" src="https://fts.cardconnect.com:6443/itoke/ajax-tokenizer.html" frameborder="0" scrolling="no"/>
Optional Parameters
The following parameters can be appended to the URL.
If your web page might be accessed from a mobile device, you should add the tokenizewheninactive and inactivityto parameters.
| Parameter Name |
Default Value |
Description |
| placeholder | none | A string value to be used as placeholder text for the input field of the tokenizer, specified using the HTML input field's placeholder attribute. This feature is not supported on versions of Internet Explorer older than IE 10.
Note the following restrictions when including a placeholder string:
- The string must be URL-encoded.
- Only the following characters are supported:
- letters
- numbers
- spaces
- periods (.)
- number signs (#)
- The maximum string length is 30 characters.
|
| invalidinputevent |
false |
If true, a 'message' event will be sent to the parent page when itoke determines that the card number is invalid (for example, if it fails the luhn check). The 'data' property in the event will contain an empty string and a 'validationError' property will contain a description of the validation failure. An example of how this event can be used is available in 'outer-page-validation.html' |
| tokenizewheninactive |
false |
Validation & tokenization for manual input is normally performed when an onBlur event occurs on the input field (e.g. when the user clicks/tabs to the next field in the form). If 'tokenizewheninactive' is set to true, validation & tokenization will be performed once the input field stops receiving input from the user. This inactivity duration is configurable through the 'inactivityto' parameter. Note that the onBlur event will not be used at all if 'tokenizewheninactive' is set to true and that 'inactivityto' is also used to determine when a swipe has completed.
This parameter is intended to be used in mobile implementations |
| inactivityto |
500 |
Controls how long (in milliseconds) the page will wait after an onInput event before considering input complete. Applies to both 'tokenizewheninactive' mode and to swipes with a USB device. |
| swiperate |
0.2 |
'swiperate' defines a threshold for determining whether input is coming from a swipe on a USB device or a user typing on a keyboard. The default value of 0.2 represents .2 characters per millisecond, or 200 characters per second. The default should only be reduced if swipes are not being recognized correctly by itoke. |
| enhancedresponse |
false |
If true, the following additional parameters will be included in the JSON response after a tokenization attempt:
- token - the token if tokenization was successful, otherwise an empty string
- errorCode - 1) the error code from CardSecure on tokenization failure, 2) a custom iFrame Tokenizer error code, or 3) '0' if no error occurred
- errorMessage - the error message from CardSecure on tokenization failure, otherwise an empty string
|
| autofocus |
false |
If true, itoke input field will be focused when the page loads |
| swipeonly |
false |
If true, any input that has an input rate less than the swiperate
threshold will be cleared out. Set this to true if itoke is only being
used with USBKB devices and manual input is not permitted. |
| tokenpropname |
message |
Controls the name of the token property in the json message that is sent to the parent page. Alphanumeric only. |
| formatinput |
false |
Styles the card number to be separated every four numbers so the number is easily read as the user types into the field |
| unique |
false |
If true, itoke will instruct CardSecure to generate a unique token for each tokenization of a given card number |
iFrame Styling
Styling can be accomplished by passing CSS parameters in your iframe src attribute:
To pass straight CSS in the src attribute of the iFrame:
<iframe id="tokenframe" name="tokenframe" src="ajax-tokenizer.html?css=input{border:2px solid orange;}"
frameborder="0" scrolling="no" width="200" height="30"></iframe>
It is a best practice to URL encode the CSS property string to ensure that the characters and values in the string are handled correctly. If you use any properties that include a percent sign (%), you must URL encode those values to ensure that the percent sign is not ignored.
Whitelisted CSS Properties
Any of the following whitelisted CSS properties can be used when passing a CSS string using the CSS parameter.
If you include any CSS properties that are not whitelisted, those properties will be stripped out before rendering the page.
-moz-border-radius
-moz-border-radius-bottomleft
-moz-border-radius-bottomright
-moz-border-radius-topleft
-moz-border-radius-topright
-moz-box-shadow
-moz-outline
-moz-outline-color
-moz-outline-style
-moz-outline-width
-o-text-overflow
-webkit-border-bottom-left-radius
-webkit-border-bottom-right-radius
-webkit-border-radius
-webkit-border-radius-bottom-left
-webkit-border-radius-bottom-right
-webkit-border-radius-top-left
-webkit-border-radius-top-right
-webkit-border-top-left-radius
-webkit-border-top-right-radius
-webkit-box-shadow
azimuth
background
background-attachment
background-color
background-image
background-position
background-repeat
border
border-bottom
border-bottom-color
border-bottom-left-radius
border-bottom-right-radius
border-bottom-style
border-bottom-width
border-collapse
border-color
border-left
border-left-color
border-left-style
border-left-width
border-radius
border-right
border-right-color
border-right-style
border-right-width
border-spacing
border-style
border-top
border-top-color
border-top-left-radius
border-top-right-radius
border-top-style
border-top-width
border-width
box-shadow
caption-side
color
cue
cue-after
cue-before
direction
elevation
empty-cells
font
font-family
font-size
font-stretch
font-style
font-variant
font-weight
height
letter-spacing
line-height
list-style
list-style-image
list-style-position
list-style-type
margin
margin-bottom
margin-left
margin-right
margin-top
max-height
max-width
min-height
min-width
outline
outline-color
outline-style
outline-width
padding
padding-bottom
padding-left
padding-right
padding-top
pause
pause-after
pause-before
pitch
pitch-range
quotes
richness
speak
speak-header
speak-numeral
speak-punctuation
speech-rate
stress
table-layout
text-align
text-decoration
text-indent
text-overflow
text-shadow
text-transform
text-wrap
unicode-bidi
vertical-align
voice-family
volume
white-space
width
word-spacing
word-wrap
box-sizing
LUHN/Mod 10 Validation
An error class can be implemented within css parameters that will make users aware if a credit card number input does not pass LUHN/Mod 10 Validation. This could be helpful in preventing incorrect entry of card numbers and the submission of invalid tokens.
Example: https://fts.cardconnect.com:6443/itoke/ajax-tokenizer.html?css=%2Eerror{color:%20red;}
Device Compatibility
Certain payment environments may be suited for use of an MSR/SRED device alongside a payment page making use of the Hosted iFrame Tokenizer. In these cases, the iFrame Tokenizer can recognize and tokenize data input from a USB connected device.
The ability for users to swipe cards or manually key enter card numbers into encrypted devices rather than directly into their keyboard provides additional reduction of PCI scope for certain environments.
In order to fully comply with PCI standards, only devices that have been provided by CardConnect and have the appropriate encryption scheme should be used with this solution.
Supported Devices
- IDTECH SREDkey USB Swipe/Keyboard Emulation Card Reader
- IDTECH SecuRed USB Swipe Card Reader
- MagTek Dynamag USB Swipe Card Reader
ACH/eCheck Tokenization
The Hosted iFrame Tokenizer can accept entry of electronic check or ACH details in order to retrieve a token that can then be submitted within an ACH Authorization.
When using the iFrame Tokenizer to tokenize ACH account data, you must input the routing and account numbers in a single string, separated by a forward slash (/), in the format RoutingNumber/AccountNumber.
Example: 123456789/1234123412341234
Examples
Web Implementation
Mobile Implementation