Tokenization can be defined as “the process of substituting a sensitive data element with a non-sensitive equivalent, referred to as a token that has no extrinsic or exploitable meaning or value”[7]. Tokenization is not a new or purely technical term as it has origins dating back thousands of years. During the course of time when someone has had the need to protect a currency or a valuable item during a transaction, they have used tokenization by switching it with a less-valuable item. A good example of tokenization happening today is the use of casino chips where real money are switched for a token.
When dealing with Credit Cards in a business environment there is a constant threat of cyber-attacks that has made business extremely susceptible to exploitation. Losing a SAP Business One database that contains Credit Card information is the worst case scenario for many businesses as this can ultimately lead to having your customers Credit Card information exploited by criminals. Tokenization as utilized by major payment gateways digitally converts sensitive data to a token that has no value outside a specific gateway system. When a gateway provides a tokenization service, the gateway system must be secured and validated using security best practices applicable to sensitive Credit Card data protection, secure storage, audit, authentication and authorization. This is all handled by the gateway lowering the security requirements for businesses that uses the tokenization service. For this reason, tokenization provides excellent security to data that is stored in a system.
Tokenization vs Encryption
A common misconception is that tokenization and encryption are essentially the same. In fact, tokenization and encryption are very different in how they protect data.
Encryption is the process of taking data and encrypting it into an unreadable format. While encryption does provide a substantial layer of protection against unauthorized viewing of data, the data needs to be decryptable so that it can be returned to the original format. This is indeed the case with solutions that encrypt Credit Card data in the database as they need to be able to reverse the encryption and extract the Credit Card number when processing transactions. If you have the correct key, you are able to decrypt the data and reveal the Credit Card numbers. This weakness has led hackers to develop sophisticated programs that have ultimately succeeded in untangling encrypted data previously considered unbreakable.
Tokenization instead replaces sensitive payment data with a token that cannot be mathematically reversed back to the original data.
How does iPayment use tokenization?
When gateway tokenization is utilized in combination with B1 iPayment, it provides substantial protection to customers and businesses alike. Should a data breach occur the database would only be yielding unusable tokens to hackers. The tokens cannot be reversed to the actual Credit Card number and is as such useless for the fraudsters.
The result of this process is that only a token generated by the gateway is stored in the SAP Business One database but not the actual primary account number. This leads to increased security as no one is able to obtain the primary account number after it has been submitted to the gateway. iPayment uses the token to keep track of the transaction and handle authorization, settlement and refunds.
A token is unique for a gateway and an account and as an example a token from Authorize.NET cannot be used with Trust Payments (Secure Trading)/CyberSource or even a different account at the same gateway. This renders the token entirely useless for anyone who is able to obtain it as it cannot be reversed to the actual Credit Card number and the token is linked to the account at the gateway.
Question and answers for tokenization
Does iPayment store Credit Card data in the database?
a. Yes and no. It stores the token that represents the primary account number but not the primary account number itself. The following are stored by iPayment:
i. The token that represents the primary account number. As explained above this cannot be reversed to the actual Credit Card number.
ii. Expiry data of the Credit Card
iii. Credit Card type
iv. A masked version of the primary account number provided by the gateway. This cannot be unmasked and you cannot get access to the full primary account number. iPayment cannot unmask the primary account number and it will show like on a paper receipt from a store - XXXX0027.
v. The information on the Credit Card like Firstname, Lastname, city, country etc. for fraud checking.
b. iPayment does NOT store the following:
i. Security Code (CVV, CAV2, CVC2, CVV2, CID)
ii. Primary account number
2. How/where are the Credit Card data stored?
a. The token and the connected data is stored in a User Defined Table in the database ([@BOY_E0_CREDITCAEX]). You as a customer should maintain strict security rules and use best practice for storing sensitive data as following the guidelines by the PCI-DSS scope. Tokenization does not remove the requirement but it help prevent leaking primary account number if a breach happens.
3. How long do the tokens last
a. Until the deleted from the system or the Credit Card expires.
4. Is there a way that the customer can enter their Credit Card info without an employee seeing the info?
a. If you use Trust Payments (Secure Trading) as the gateway then yes. With Trust Payments (Secure Trading) as the gateway we have the option to send out a link created by Trust Payments (Secure Trading) that allows the customer to enter the Credit Card information in a secure environment provided by Trust Payments (Secure Trading). After entering the Credit Card information the token will be connected to the Business Partner in SAP where the link was generated from and can then be used to process payments without any employee or iPayment having access to the full Credit Card data.
We do not have this option for the other gateways as Trust Payments (Secure Trading) are the only one to offer this solution right now.