This guide provides integration guidance associated with the Velocity Point-to-Point Encryption (P2PE) Value-Added Service (VAS) supported by the Managed Commerce Services Platform. The Velocity P2PE VAS is a merchant “opt-in” service that enables support for P2PE transaction workflows supported by a service within existing Commerce Web Services (CWS) transaction processing workflows.
This guide is intended to provide software company developers with an overview of the Velocity Point-to-Point Encryption (P2PE) VAS and some important development considerations associated with the development of Commerce Web Services (CWS) applications that leverage this service.
The following prerequisites are required to leverage the Velocity P2PE VAS on the Managed Commerce Services Platform:
The following resources provide additional information that can be referenced as supplemental material to this online guide:
According to some industry sources the breach liability for a merchant handling cardholder data is between $180 to $1000 per cardholder number transmitted and stored. For merchants who store several years’ worth of data this can translate to a potential liability of $150,000 to $600 Million. For many of these companies the cost of being PCI compliant while storing and handling sensitive card data can range from $50,000 to $2 Million. To combat this problem merchants need a multi-faceted approach to handling credit cards transactions that includes a Point-to-Point Encryption solution.
NAB Velocity offers their Point-to-Point Encryption (P2PE) solution as a Value Added Service (VAS) as part of the NAB Velocity Managed Commerce Services Platform.
Point-to-Point Encryption (P2PE) is a solution that encrypts cardholder data at the magnetic read head of a secure card reader device before being transmitted to the application for processing. This protects the track data from the entry point of a merchant’s point-of-sale (POS) to a point of secure decryption outside of the merchant’s environment, effectively removing card data from the merchants environment. The goal of P2PE is to directly address the risk of interception associated with cardholder data in motion by providing secure data transmission along the path of a transaction and thusly lowering the PCI compliance burden for both software companies and merchants.
The Velocity P2PE VAS component architecture is illustrated below:
Figure 1: Component Architecture
The Velocity P2PE VAS production architecture communicates directly with the Velocity Web Service for all card data decryption.
The Velocity P2PE VAS component architecture and associated production environment workflow is illustrated below:
Figure 2: Production Architecture and Workflow
During the Velocity P2PE transaction workflow, destination service providers are completely unaware that P2PE has taken place, and therefore, can be implemented seamlessly with any NAB Velocity payment service provider.
Note: The encrypted card data sent to the Velocity Service is discarded and is never stored with the transaction.
The Velocity P2PE VAS Sandbox architecture communicates with a Velocity Web Service “test host” that stores magnetic fingerprint values for white-listed cards used to simulate production card data decryption and optional card scoring during testing/certification.
The NAB Velocity Sandbox environment uses a special Velocity P2PE VAS Sandbox Adaptor that routes requests to a Velocity Web Service “test host” that is used to simulate card data decryption processing. Like the production Velocity Web Service, the Velocity test host stores decryption keys associated with all enabled Secure Card Reader devices.
The Velocity P2PE VAS component architecture and associated Sandbox environment workflow is illustrated below:
Figure 3: Sandbox Architecture and Workflow
Refer to Integration Guidelines for specific Velocity integration requirements, the Sandbox environment.
Integration to the Velocity P2PE VAS requires a Velocity P2PE VAS-enabled workflowId that must be passed with each Commerce Web Services (CWS) transaction request. This workflowId is returned to the application in the response to the GetServiceInformation call during the Preparing the Application to Transact process of a CWS integration.
Optionally only for Secure Card Reader Authenticator (SCRA) devices, a ScoreThreshold value can be passed with each transaction request to trigger card authentication.
One of the key features of the MagTek® MagneSafe™ security architecture is MagnePrint® card authentication, which is used to identify counterfeit credit cards, debit cards, gift cards, and other cards at the point of swipe. MagnePrint makes it possible for card issuers to uniquely identify each physical card they produce by analyzing its magnetic “fingerprint”. By storing this fingerprint, merchants are able to perform a fingerprint reference check during card swipe to determine if the card is counterfeit, and should therefore be declined.
MagnePrint® card authentication, or card scoring, is performed based on the presence of the CWS BankcardTransactionData.ScoreThreshold parameter in each transaction authorization request.
Note: Velocity recommends that software companies use a default ScoreThreshold of 0.4. Negative scores typically fall between -0.1 and 0.3 (peaking at ~0.1), while positive scores typically fall between 0.7 and 0.95 (peaking at ~0.9).
Figure 4: MagnePrint Card Scoring based on Threshold Value
Note: If no ScoreThreshold value is passed in the transaction authorization request, card scoring processing is ignored and the transaction workflow continues as normal.
Refer to the following Integration Guidelines sections for specific Velocity integration requirements, trigger values, and response codes.
Updated: June 2, 2017