Stored-Card-Information
When using the expression “stored-card-information,” we mean a system that allows you to obtain complete card information from a customer just once and to store it so you can use it at will to run transactions in the future. More particularly, we mean a system that stores the information in an encrypted online (and PCI-compliant) vault. This vault denies any direct access to the information. Access is only allowed via a “token” provided, and even then, information is passed solely to allow transaction completion and is never exposed to outside eyes or outside software. Because this system uses a token to access the information in a transaction securely, the process is sometimes called “tokenization.”
There are presently two contexts in ServiceDesk where you may create and attach tokens.
You may collect and attach a token to any QuickEntryTemplate (QET). Once a token is connected to a QET, you may run a transaction against that token whenever the respective QET client is the paying party on a job.
You may collect and attach a token to any regular customer via a JobRecord set up for that customer.
Token use as connected to QETs:
Creating a tokenized link from a QET
Press (Shift+F1) to open the QET editing interface.
Select the QET of interest.
Click 'Edit.'
Click the button to create an invitation to the entity represented in the QET.
Choose whether to send the invitation via email or text message.
Provide an email address or mobile telephone number.
Edit the pre-filled text if desired, then send the message.
When the customer clicks on the link, the recipient will see a web interface like this:
Viewing a tokenized link from a QET.
After sending an invitation to create a token to the customer, the button indicates you can check to see if your customer completed the token-creation process. Click on the button in the QET edit interface seen below (note the color change in the button):
If your customer still needs to create a token, ServiceDesk will display a dialog that informs the user that the customer still needs to complete the token creation.
If your customer has created a token, ServiceDesk will display a dialog that informs the user that the customer has completed the token creation. The interface will change to look like this:
Float your mouse pointer over the button, and you'll see non-sensitive info regarding the stored card:
When processing a bankcard transaction connected with a JobRecord that has this QET client setup as the paying party, your Virtual Terminal fills in like this:
As expected, you can run the charge against the stored/secure information without anyone ever having access to its sensitive data. Also, please note you may float your mouse pointer over the text for a ToolTip that informs of the non-sensitive data in the stored card:
Before running a transaction, verify that it will indeed be against the card that you expect it to be against.
Token use as connected to regular customers via a JobRecord
Creating a tokenized link from a JobRecord
Open a JobRecord (F7).
Right-click on its 'Enter funds Rcvd' button.
Select option 'I' from the dialog that presents a list of funds-related alternate options. (Highlighting is added to emphasize the selection of current interest.)
Click the button to create an invitation to the entity represented in the JobRecord.
Choose whether to send the invitation via email or text message.
Edit the pre-filled text if desired, then send the message.
You may select the option above to create an invitation, which works very much like in the QET situation . . . except here the system will look in the JobRecord for email or text message send-to targets and offer to auto-insert those for you.
Viewing a tokenized link from a JobRecord
An important matter to understand is how the system associates other JobRecords for the same customer with the JobRecord that was used to send an invitation and create a token. The answer is when looking for an applicable token from any JobRecord:
ServiceDesk looks in your entire database for every JobRecord in which there are at least two matches on the name, street address, telephone number, and/or email address fields.
It then looks for a token that applies to any of those JobRecords.
If a token is found, it offers it for use on the current JobRecord. In this way, you may collect a token once on a particular JobRecord, and use it (so long as the customer consents, of course) on all subsequent jobs for the same customer.
Open a JobRecord (F7).
Right-click on its 'Enter funds Rcvd' button.
Click on option 'C' to verify a token has been created by the customer:
The above steps will bring up a dialog that tells you if a token exists for the customer.
If a token exists, it will be offered in the Virtual Terminal when running a charge on any job where the same party is set as the payer (i.e., very much the same as in the QET scenario). In other words, the system will find the token and offer it as a basis for running a charge in the Virtual Terminal.
Replacing or removing stored card information
Resending an invitation to create a token from a QET
Press (Shift+F1) to open the QET editing interface.
Select the QET of interest.
Select the top option.
This will require the MasterPassword to complete.