MercuryPay P2PE

Document created by chadb on May 10, 2016Last modified by Chris Jennings on Jun 1, 2016
Version 3Show Document
  • View in full screen mode

The MercuryPay processing platform supports several hardware devices designed to encrypt card data at the point of entry, referred to as point-to-point encryption (P2PE).  As a PCI-DSS validated and listed level-one service provider, MercuryPay processing platform is the only end point of the P2PE pathway and uses our decryption/encryption environment to validate, decrypt and process the data. MercuryPay’s cardholder data environment (CDE) is reviewed quarterly under stringent security audits, which include a thorough analysis of our decryption environment.

 

Our supported encryption peripherals are PCI PTS compliant and listed. Our device manufacturers are leaders in both the payment and encryption industries--VeriFone, Infinite Peripherals, IDTech, Ingenico and MagTek. As per PCI encryption security standards, devices are injected by certified third-party key injection facilities (KIF).

Incorporating P2PE encryption starts with selecting an encryption device that best suits your payment applications implementation needs, such as mobile, desktop or cloud.

 

Integrating to Encrypted Devices

MercuryPay’s supported encryption devices provide a cypher-text and key serial number (KSN) output in ASCII HEX format.  Below is a comparison of a card swipe using a Visa Test card in a standard keyboard (KB) emulation reader vs. swiped in an encrypted KB reader. 

     Track1 and Track1 Encrypted Block are in blue (Track1 EncryptedBlock not supported on MercuryPay)

     Track2 and Track2 Encrypted Block is in red (Track2 EncryptedBlock onle supported on MercuryPay)

     EncryptedKey is in green

Example of a Standard keyboard emulation reader:

%B4003000123456781^TEST/MPS^13051010000000000?;4003000123456781=13055025432198712345?

 

Example of a MagTek Encrypted KB Dynamag Output:

%B4003000050006781^TEST/MPS^13050000000000000?;4003000050006781=13050000000000000000?|0600|96F7CCEB8461264BB3CB3F4539163C8C59E87F2B16F1E876C778A3A15CF840422FAFF02FA2E27FD4DBC29B38535069B9|BDEC23AAA899006C36843F14E0F6A6472C8CDF81271764E160B455FC55AA5DD05F2AD04769614A91||61402200|B54A267EAAEB5B9A85212421B09BEA3B6F4AC894DBDE5A246E2780F461E63C6175C92D0F62703CAC551A206D66760744172CF7E14A223605|B01F8C4072210AA|BF6325ABD6A63EE7|9012090B01F8C4000007|F7D7||0000

[Symbol] Note encrypted output will vary per device manufacture.

 

For P2PE encrypted transactions requests, four required data elements must be added on the account level of the XML:

<Account>  
<EncryptedFormat>MagneSafe</EncryptedFormat> 
<AccountSource>Swiped, Manual or Contactless</AccountSource> 
<EncryptedBlock>EncryptedBlock</EncryptedBlock> 
<EncryptedKey>EncryptedKey</EncryptedKey> 
</Account> 

 

 

Element

 

Req

 

Min

 

Max

 

Type

 

Description

 

EncryptedFormat

 

Y

 

1

 

25

 

AN

 

Encryption format: MagneSafe. MagTek’sMagneSafev1.0 specification standards were usedas a basis to design MercuryPay’sdecryption server’s protocols

 

AccountSource

 

Y

 

1

 

25

 

AN

 

Source of encrypted block: Swiped, Keyed, Contactless

 

EncryptedBlock

 

Y

 

72

 

224

 

AN

 

Encrypted Track2or manual entry pseudo card data.Although both track blocks will be returned, only Track2 EncryptedBlockis used.

 

EncryptedKey

 

Y

 

20

 

20

 

AN

 

Derived Unique Keyfrom Secure Card Reader

 

With our encrypted output, developers have access to both non-sensitive card data and encrypted data. Non-sensitive data allows developers to pull information for internal reporting, logs, receipts, etc.

 

Non Sensitive card data will be returned in the clear with either first four or six and last four digits of the card number, cardholder name and expiration date.

  ▪ Track data is masked with  0 or  *.

 

Although encrypted Track 1 and 2 data will be returned, you will always use ONLY Track2 encrypted data when sending the encrypted transaction request to MercuryPay.

 

Encrypted Data Best Practices

  • Never store the EncryptedBlock or EncryptedKey after authorization.

  • In systems that support “Store and Forward” functionality, EncryptedBlock or EncryptedKey information may be stored prior to authorization only.

  • Unless performed on a validated system, developers must code to accept manually entered card data only through the encryption device and not through any native key-entry options; this would result in sending non-encrypted data, and cause the request to fail.

  • Failure to use a supported encryption device for any entry may expose the developer to additional PA-DSS and PCI remediation requiring a validated security assessor audit.

1 person found this helpful

Attachments

    Outcomes