Show

PCI Proxy enables you to see the original credit card number of a stored credit card. Basically, it is a web interface that can convert a token back into its original credit card number.

Consider a business that needs this ability: You are a travel technology company providing hotels with software to manage their reservations. Authorized hotel employees need to retrieve single credit cards from reservations to book a no-show fee with their POS terminal if a guest does not show up.

Note: Even though the interface is served by PCI Proxy, your PCI scope can extend.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<response>
  <url>https://api.sandbox.datatrans.com/upp/noshow?token=27cfba38-a606-49c0-9f03-c3bc6d580a66</url>
  <errorCode>0</errorCode>
</response>

Examples

Request
curl -X POST https://api.sandbox.datatrans.com/upp/services/v1/noshow/init \
  -H 'content-type: application/xml' \
  -d '<request>
        <merchantId>1000011011</merchantId>
        <aliasCC>424242SKMPRI4242</aliasCC>
        <userName>bond</userName>
        <userEmail>james.bond@yourcompany.com</userEmail>
        <SHASign>d17ead827458e3532fd868b3b110671586b7e7ee0db106d5ae94e85ca93782ab</SHASign>
        <language>en</language>
     </request>'

Request
curl -X POST https://api.sandbox.datatrans.com/upp/services/v1/noshow/init \
  -H 'content-type: application/json' \
  -d '{
    "merchantId": "1000011011",
    "aliasCC": "70119122433810042",
    "userName": "bond",
    "userEmail": "email@example.com",
    "SHASign": "d17ead827458e3532fd868b3b110671586b7e7ee0db106d5ae94e85ca93782ab",
    "language": "en",
   }'

3. Embed NoShow link from the response into your application

Response
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<response>
  <url>https://api.sandbox.datatrans.com/upp/noshow?token=27cfba38-a606-49c0-9f03-c3bc6d580a66</url>
  <errorCode>0</errorCode>
</response>

Response
{
    "url": "https://api.sandbox.datatrans.com/upp/noshow?token=2555559e-63d8-4c26-8799-0e9d64601037",
    "errorCode": 0
}

4. Once the user clicks on the link an email will be sent to userEmail where the new device must be authorized either by clicking on the provided link or by entering the activation code manually.

5. Subsequently the new device has been authorized the user and may enter a four digit security code in the opened iFrame to retrieve plain text credit card number.

Need more help? Check out our NoShow example script.

6. Ensure PCI-compliant user management​

Reference

SHA.256 Security Sign

Generate NoShow-specific SHA.256 Security Sign with salt value, merchantId, aliasCC (token) and userEmail

salt        = V3hmMm29gD35OVHWDSAYKBIBCRg0znRekNvGbM9d8I4GRgfIcs                       // Setup in Step 1
merchantId  = 1100005007                                                               // Your Merchant ID
aliasCC     = 424242SKMPRI4242                                                         // CC token to be de-tokenized
userEmail   = james.bond@yourcompany.com                                               // Email address of NoShow-User
​
→ String: V3hmMm29gD35OVHWDSAYKBIBCRg0znRekNvGbM9d8I4GRgfIcs1100005007424242SKMPRI4242 // Concatenate all 4 values
          james.bond@yourcompany.com 
SHA.256(salt+merchantId+aliasCC+userEmail)                                             // Use SHA.256 Hash Converter
→ SHASign: f641a6a3de574bd4b7609320e9a4fb1ed11364f136908822ff6a8e3b6b1bca1f            // Security Sign for NoShow.jsp

The „salt“ value has to be generated in the Datatrans web administration tool (https://admin.sandbox.datatrans.com) under “UPP Administration” -> “Security” -> “Other Services”.

Example: NoShow sign calculation​

Optional: Add JavaScript callbacks/hooks

// Use attached Javascript callsbacks/hooks file to see which events are getting emitted to the parent frame.
// Bind an event listener to the parent frame to listen for those events:
​
function messageReceived(message) {
  console.log(message.data);
}
​
if(window.addEventListener)
  window.addEventListener("message",messageReceived);
else
if(window.attachEvent)
  window.attachEvent("message",messageReceived);
else
  console.log("Could not listen.")
​
/*
    Possible event messages:
    {type: 'error',     reason: 'wrong request'}        Invalid merchant id, alias or sign
    {type: 'error',     reason: 'service not allowed'}  Merchant not configured
    {type: 'error',     reason: 'fraud check 3082'}     Declined by fraud check
    {type: 'error',     reason: 'system error'}         System error
    {type: 'error',     reason: 'invalid sign'}         Invalid sign
    {type: 'error',     reason: 'time expired'}         The user did not enter the chaptcha in less than 90 seconds
    {type: 'error',     reason: 'wrong captcha'}        The entered captcha was wrong
    {type: 'error',     reason: 'invalid card'}         Wrong card number
    {type: 'error',     reason: 'velocity checker'}     Declined by velocity checker
    {type: 'error',     reason: 'wrong alias'}          Wrong alias
    {type: 'waiting',   reason: 'captcha'}              The page is waiting for user input of captcha
    {type: 'success',   reason: 'CC'}                   The card number was successfully displayed
    {type: 'success',   reason: 'CVV'}                  The CVV code was successfully displayed
*/

PCI DSS Compliant User Management

Using our NoShow.jsp script requires you to handle your user management in a PCI DSS compliant way. PCI DSS requires certain user and password policies. Below you will find a comprehensive overview for a PCI DSS compliant user management. For a more detailed version on PCI DSS user management please see the official PCI DSS documents (Requirement 8) PCI DSS - Requirements and Security Assessment Procedures.

Unique User IDs

Every single user having access to the No-Show.jsp needs to have a unique user login to be clearly identified. Shared user logins are not allowed.

Password Policy

In general, the following password rules have to be observed:

• Passwords must be changed at least every 90 days.

• The password must have a minimum length of 7 characters.

• The password must contain upper and lower case letters, numbers and at least one special character.

• When changing the password none of the last four passwords can be used.

• After 6 failed login attempts a user account is locked. It can only be unlocked by the administrator.

• After 15 minutes of inactivity, the password must be entered to reactivate the terminal / session.

• The maximum session time after which the user must log in again must not exceed 200 minutes.

Great job: You have successfully integrated PCI Proxy!

You have securely retrieved a stored credit card without ever touching your servers. Your systems never record, transmit or store real credit card data, only the token. Thus, you are out of PCI scope.

Enjoy PCI compliance in a risk-free environment. Keep in mind that you can use stored data as often as you need it.

Questions?

Don't hesitate to talk to us via email, phone, or Slack. We love to help you with the integration or other questions around PCI compliance or the PCI Proxy.

Phone: +41 44 256 81 91 Email: support@pci-proxy.com​