Value-Added Service Provider Guidelines: Velocity Point-to-Point Encryption (P2PE)

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 the Velocity Point-to-Point Encryption (P2PE) Value-Added Service (VAS) as part of the NAB Velocity Managed Commerce Services Platform.

Point-to-Point Encryption (P2PE) 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.

Supported Features

  • Support for all certified payment service providers supported by the managed Commerce Services Platform (Chase Orbital Retail Processing solution not available due to inability to accept/handle Track 2 data).
  • Workflow-based enablement.
  • Triple DES encryption and DUKPT key management provides a comprehensive solution protecting data while at rest and in motion.

Integration Requirements

  • Requires Commerce Web Services (CWS) application certification 2.0.17 (and above).
  • Support for Bankcard Processing (BCP) transactions only (ECK and SVA service classes are currently not supported).
  • Software companies and their merchants are required to use Velocity-compatible Secure Card Reader Authenticators (SCRA) devices.

Velocity P2PE VAS Component Architecture

The Velocity P2PE VAS component architecture is illustrated below:

Figure 1: Component Architecture

Production Architecture

The Velocity P2PE VAS production architecture communicates directly with the Velocity Web Service for all card data decryption.

  • Production Architecture and Workflow

Sandbox Architecture

The Velocity P2PE VAS Sandbox architecture communicates with a Velocity Web Service "test host" that stores magnetic fingerprint values for test cards. These test cards are used to simulate production card data decryption and optional card scoring during testing/certification. In addition, NAB Velocity provides a Sandbox environment for integration, testing, and certification purposes.

  • Sandbox Architecture and Workflow

Production Architecture and Workflow

The Velocity P2PE VAS component architecture and associated production environment workflow is illustrated below:

Figure 2: Production Architecture and Workflow

  1. The merchant swipes a consumer’s card through a supported Secure Card Reader Authenticator (SCRA) device at the point-of-sale (POS). Cardholder data is encrypted on the device at the time of swipe and transmitted to the POS application.
  2. The POS application submits the transaction to the Managed Commerce Services Platform via the Commerce Web Services (CWS) Transaction Processing Service (TPS) endpoint that contains a workflowId indicating the enablement of the Velocity P2PE VAS.
  3. TPS passes the authorization request to the Transaction Broker (TB). TB accesses the workflow process set for instructions on processing the transaction against the Velocity P2PE Service based on the CWS workflowId passed in the request.
  4. TB transmits secure card data to the Velocity P2PE VAS Adaptor.
  5. The Velocity P2PE VAS Adaptor transmits secure card data to the Velocity Decryption Server.
  6. Velocity Decryption Server decrypts the secure card data (full track data as present on the swipe) and returns a positive response to the Velocity P2PE VAS Adaptor.
  7. The Velocity P2PE VAS Adaptor routes the transaction request, along with the decrypted card data from the Velocity P2PE Service, to the appropriate destination service provider via the Service Provider Adaptor Add-Ins.
    • From this point forward, the transaction is processed in the same manner as any CWS transaction. The service provider processes the authorization request and returns a response to the requesting application via the Transaction Processing Service.
    • In implementations where the merchant’s Service Key also supports the NAB Velocity Tokenization Value-Added Service, the generated cardholder data token will also be returned to the application.

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 Decryption Server is discarded and is never stored with the transaction.


Sandbox Architecture and Workflow

The NAB Velocity Sandbox environment supports Velocity emulation and connectivity to the Velocity Decryption Server "test host" for testing. Like the production Velocity Web Service, the Velocity Decryption Server test host stores decryption keys associated with all Secure Card Reader devices.

The Velocity P2PE VAS component architecture and associated Sandbox environment workflow is illustrated below:

Figure 3: Sandbox Architecture and Workflow

  1. The merchant swipes a consumer’s card through a supported Secure Card Reader Authenticator (SCRA) device at the point-of-sale (POS). Cardholder data is encrypted on the device at the time of swipe and transmitted to the POS application.
  2. The POS application submits the transaction to the Managed Commerce Services Platform via the Commerce Web Services (CWS) Transaction Processing Service (TPS) endpoint that includes a Velocity Decryption Server workflowId.
  3. TPS passes the authorization request to the Transaction Broker (TB). TB accesses the workflow process set for instructions on processing the transaction.

If the provided workflowId directs the application to the Velocity Decryption Server test host:

  1. TB transmits the secure card data to the Velocity P2PE VAS Test Host Adaptor.
  2. The Velocity P2PE VAS Test Host Adaptor transmits the secure card data to the Velocity Decryption Server test host.
  3. Velocity Decryption Server decrypts the secure card data (full track data as present on the swipe) and returns a positive response to the Velocity P2PE VAS Test Host Adaptor.
  4. The Sandbox environment processes the trigger values contained in the decrypted card data and returns the appropriate response codes to the application.
  5. Important! Using the Velocity test host requires test cards and a test card reader.

If the provided workflowId directs the application to the Velocity Decryption Server test host:

  1. When using the NAB Velocity Sandbox environment, the workflow is always successful. The developer can use any test card for testing purposes. In this workflow, the encrypted block is exchanged locally for a decrypted whitelist Sandbox test card, and the ScoreThreshold is always successfully met. This process enables the developer to use the Velocity reader to experience all the potential service provider response conditions that are possible while performing full application testing and certification. Using this mode, specific Sandbox trigger values have been reserved for simulating Velocity error conditions, in addition to all service provider response conditions.
  2. The Sandbox environment processes the trigger values contained in the decrypted card data and returns the appropriate response codes to the application.

Important! Velocity response codes will only be present in the transaction record when an error or decline condition is returned from the Velocity P2PE Service. At all other times, payment service provider response data will be delivered in the response and persisted in the transaction record.


Velocity P2PE VAS Implementation

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.

Setting the ScoreThreshold Value

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, orcard scoring, is performed based on the presence of the CWSBankcardTransactionData.ScoreThresholdparameter in each transaction authorization request.

  • ScoreThreshold Present: Encrypted card data is decrypted and card scoring is performed based on theScoreThresholdvalue passed in the transaction request.
  • ScoreThreshold Null: Encrypted card data is decrypted, but no card scoring is performed.

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
Source:http://www.magtek.com/V2/products/magnesafe/index.asp

Card Scoring Logic

  • Positive Result: If the Velocity Web Service returns a positive score greater than the specified ScoreThreshold value, the transaction workflow continues and the Velocity P2PE VAS returns the appropriate Velocity and in the transaction response message.
  • Negative Result: If the Velocity Web Service returns a negative score less than the specified ScoreThreshold value, the transaction workflow stops and the Velocity P2PE VAS returns the appropriate Velocity and in the transaction response message.

Note: If noScoreThresholdvalue is passed in the transaction authorization request, card scoring processing is ignored and the transaction workflow continues as normal.


Velocity P2PE VAS Requirements

Service Overview

Velocity Point-to-Point Encryption (P2PE) Value-Added Service (VAS) provides a comprehensive security solution that protects card data throughout the entire Commerce Web Services (CWS) transaction lifecycle. The VAS integrates directly to the service to decrypt card data that was encrypted during initial swipe at the point-of-sale using a Secure Card Reader Authenticator (SCRA) device.

Bankcard Processing (BCP) Support Credit, PIN Debit
Supported Industries Retail and Restaurant
Certification Testing Trigger Values and Response Codes

Prerequisites

Integration to the Velocity P2PE VAS requires a CWS payment solution and a Secure Card Reader Authenticator (SCRA) device.

Requirements

Credit Processing Supported CWS Transaction Processing operations:
  • Authorize
  • AuthorizeAndCapture
  • ReturnUnlinked
Only Track 2 data is supported, and is therefore, required.
PIN Debit Processing Supported CWS Transaction Processing operations:
  • AuthorizeAndCapture
  • ReturnUnlinked
  • Undo
 
Required Data Elements
CWS Data Element Common Device Swipe Field Name Velocity Field Name Description
ApplicationData.EncryptionType Enumeration set in application data. Value does not come from the device. EncryptionBlockType Encryption Type Enumeration:
  • IPADV1Compatible
  • MagneSafeV4V5Compatible
MerchantProfile.MerchantData.Name Value does not come from the device. RegisteredBy Merchant Name: An alpha numeric entry between 1 and 20 characters long.
BankcardTenderData.CardSecurityData.IdentificationInformation "MagnePrint data", "MagnePrint Data (hex)" EncMP Encrypted MagnePrint® Information returned by the MagneSafe™ device when card is swiped.
BankcardTenderData.CardSecurityData.CVData Always set to "Null". Value does not come from the device.    
BankcardTenderData.CardSecurityData.CVDataProvided Enumeration set to CVDataProvided.NotSet. Value does not come from the device.    
BankcardTransactionData.EntryMode Enumeration set to EntryMode.Track2DataFromMSR. Value does not come from the device.    
TransactionData.Reference Value does not come from the device. CustTranID An alpha-numeric transaction ID between 1 and 16 characters long.

Note: Reference must be unique. Refer to specific Payment Service Provider Guidelines (where applicable) for additional information.
TransactionTenderData.EncryptionKeyIdd "DUKPT serial number/counter", "DUKPT Key Serial Number" KSN 20-character string returned by device when card is swiped.
TransactionTenderData.SecurePaymentAccountData "Track 2 encrypted data", "Track 2 Encrypted" EncTrack2 Encrypted Track 2 data returned by device when card is swiped. Track 2 data is supported at this time.
TransactionTenderData.SwipeStatus "MagnePrint Status" MPStatus MagnePrint Status of Card Swipe. This is an alpha numeric string, returned by MagneSafe device when card is swiped.
Optional Data Elements
ApplicationData.DeviceSerialNumber Value does not come from the device. Device Serial Number The MagTek device serial number.

Additional Resources

Magensa Compliance Reduction http://www.magtek.com/documentation/public/99800063-2.03.pdf
Magensa Web Demo http://www.magensa.net/demo/demo2.aspx
Note
: Secure Card Reader Authenticator (SCRA) device must be attached. Requires 32-bit Internet Explorer. Test card(s) are required.
MagTek Secure Card Readers http://www.magtek.com/V2/products/secure-card-reader-authenticators/index.asp
Note: In order to test against the Magensa test host via the NAB Velocity Sandbox environment, the device must be injected with a Magensa test host key (ANSI key KSID 90100100).
MagTek Programming Tools http://www.magtek.com/support/software/programming_tools
MagTek USB Swipe and Insert Reader Demo http://www.magtek.com/support/software/demo_programs/usb_swipe_insert.asp

Comments