The NAB Velocity Tokenization Value-Added Service (VAS) reduces the complexity, time, and costs associated with protecting cardholder account data in their local database. For credit card transactions, tokenization can reduce the PCI-DSS compliance burden for merchants by eliminating the need to store cardholder account data in the merchant’s local payment processing environment.
When a merchant sends a tokenization-enabled transaction authorization request, consumer account data is inserted into the authorization request message and sent to the Managed Commerce Services Platform. The Platform encrypts and securely stores the consumer account data and assigns a unique “token” that acts as a pointer to the consumer account data. This process is referred to as tokenization. The token is then returned to the requesting application in the transaction response message where it can be stored locally with other “non-sensitive” consumer data (such as name, card expiration date, etc) for use in subsequent transaction requests. The application simply sends the token in lieu of sensitive consumer account data with transaction requests that require this data. The Platform verifies the token, retrieves the consumer account data from the database, and sends the transaction request and all consumer account data associated with the token to the destination service provider for processing.
Note: CWS transactions are always assigned a token regardless of whether tokenization has been enabled for the merchant Service Key. However, the token is only returned to the merchant application when tokenization is enabled.
The Tokenization Service is supported by all Commerce Web Services (CWS) commerce solutions. CWS transaction data is stored for the merchant in the Managed Commerce Services Platform transaction database and does not need to be stored locally. For this reason, the application only needs to provide the consumer account data on the initial transaction, and does not need to retain it locally thereafter. As a result, these applications are not subject to PA-DSS requirements. However, there are business cases where the CWS application may wish to store transaction data locally, or may simply wish to store the consumer account data in their application for later use.
An example of such a use case would be a payment-enabled website where users can create and manage accounts with a variety of payment options available to them. This provides the user with a convenient way of purchasing new products or services without having to re-enter their information. In these cases, the creation and storage of a token is a great way to provide saved account consumer functionality without the increase in liability or cost associated with protecting the actual consumer account data.
All payment applications designed to capture, process, store, or transmit credit card data are required to comply with payment card industry security standards established by the PCI Security Standards Council. The Payment Card Industry – Data Security Standard (PCI-DSS) addresses the technical and operational system components included in, or connected to, consumer account data by establishing a comprehensive set of requirements for security management, policies, procedures, network architecture, software design, and other critical protective measures. This comprehensive standard is intended to help organizations proactively protect consumer account data.
According to PCI-DSS Requirement 3 (Protect Stored Cardholder Data), merchants must protect stored consumer account data by means of hashing, truncation, tokenization, or strong encryption. Failure to protect this sensitive data poses a significant security and compliance risk to merchants.
It is important to note that the Payment Application – Data Security Standard (PA-DSS) applies specifically to payment applications that store, process, or transmit consumer account data and are sold, distributed, or licensed to third-party entities. In-house application development by merchants or service providers that are not sold, distributed, or licensed to entities outside the company are not subject to PA-DSS requirements, but must still be secured in accordance with PCI-DSS.
Important! The Tokenization Service never completely eliminates PCI-DSS compliance obligations for software companies and their merchants.
Tokenization runs as a hosted service on the Managed Commerce Services Platform. Therefore, the merchant’s service configuration ultimately determines whether they can take advantage of tokenization.
When tokenization is supported by the merchant application, the service configuration returned to the application in the response to the GetServiceInformation request tells the application that tokens will be returned in the response messages for all initial transaction requests. The application can then store the token for later transaction processing requests.
Important! Tokens returned by the Tokenization Service are only valid for the services/serviceIds you are transacting against, and are not re-usable across services/serviceIds.
This token can also be used for new authorization messages in saved account use cases where tokens are stored with customer account records, such as those typical of recurring payments.
A typical credit authorization workflow for a CWS POS application supporting the Tokenization Service is illustrated below:
Figure 1: Tokenization Workflow
Additional development may be necessary to support saved account use cases, such as support for recurring payments where the application stores consumer account data within a customer’s account profile. In such use cases, the application simply sends a new authorization request message, such as those initiated by a returning customer, or when performing a recurring payment. With tokenization, all consumer account data associated with the customer is replaced by the secure token.
By their very nature, recurring payments and related use cases are for new transactions that use the Authorize and AuthorizeAndCapture operations. In these cases, tokenization allows the merchant application to store and send only the token rather than sending consumer account data.
Note: Tokens cannot be used for online PIN Debit transactions.
To support saved account payments using tokenization, software companies simply need to provide functionality that allows the application to store and retrieve tokens from the customer’s account profile stored in the local application database. Additionally, each token needs to be unique for each customer credit card. This allows the customer to store multiple credit cards within their account, providing the customer with multiple payment options.
For more information about the development of applications supporting saved account use cases, refer to Saved Accounts.
To implement saved account functionality, software companies must provide user interface elements such as a “Save Credit Card” option that allows the merchant (or customer) to save credit card information in their account profile, as well as a “Select a Credit Card” option that allows the user to select a specific credit card they wish to use for new transactions. These user interface controls are common methods of allowing customers to store credit card data in their account profile.
An example of a tokenization implementation for a saved account use case supporting “card not present” transactions is described below:
AVS and billing data may be stored and should be set on subsequent transactions.
In addition to recurring payments, other saved account use cases include:
Tokenization reduces the complexity, time, and costs associated with protecting cardholder account data in their local database. For credit card transactions, tokenization can reduce the PCI-DSS compliance burden for merchants by eliminating the need to store cardholder account data in the merchant’s local payment processing environment.
Integration to the NAB Velocity Tokenization Value-Added Service (VAS) requires a Commerce Web Services payment solution.
Updated: June 5, 2017