Search…
Show Interface
The PCI Proxy Show API 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.
Even though the interface is served by PCI Proxy, your PCI scope can extend. Therefore it's mandatory to implement it according to PCI DSS user management and password policy.
post
https://api.sandbox.datatrans.com/
upp/services/v1/noshow/init
Init call

Examples

application/json
application/xml
Request
1
curl -X POST https://api.sandbox.datatrans.com/upp/services/v1/noshow/init \
2
-H 'content-type: application/json' \
3
-d '{
4
"merchantId": "1000011011",
5
"aliasCC": "AAABcHxr-sDssdexyrAAAfyXWIgaAF40",
6
"userName": "bond",
7
"userEmail": "[email protected]",
8
"SHASign": "d17ead827458e3532fd868b3b110671586b7e7ee0db106d5ae94e85ca93782ab",
9
"language": "en"
10
}'
Copied!
Request
1
curl -X POST https://api.sandbox.datatrans.com/upp/services/v1/noshow/init \
2
-H 'content-type: application/xml' \
3
-d '<request>
4
<merchantId>1000011011</merchantId>
5
<aliasCC>AAABcHxr-sDssdexyrAAAfyXWIgaAF40</aliasCC>
6
<userName>bond</userName>
7
<userEmail>[email protected]</userEmail>
8
<SHASign>d17ead827458e3532fd868b3b110671586b7e7ee0db106d5ae94e85ca93782ab</SHASign>
9
<language>en</language>
10
</request>'
Copied!
3. Embed the NoShow link from the response into your application
application/json
application/xml
Response
1
{
2
"url": "https://api.sandbox.datatrans.com/upp/noshow?token=2555559e-63d8-4c26-8799-0e9d64601037",
3
"errorCode": 0
4
}
Copied!
Response
1
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
2
<response>
3
<url>https://api.sandbox.datatrans.com/upp/noshow?token=27cfba38-a606-49c0-9f03-c3bc6d580a66</url>
4
<errorCode>0</errorCode>
5
</response>
Copied!
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 and the user may enter a six digits security code in the opened iFrame to retrieve plain text credit card number.
Need more help? Check out our NoShow example script.
In test mode, only test credit cards are allowed!

Reference

PCI Proxy NoShow Endpoint (Sandbox):
Parameter
Description
Example value
merchantId
Your merchant ID
1000011011
aliasCC
Token you received when you collected the credit card
AAABcHxr-SDssdexrAAAfyXWIgaAF40
aliasCVV (optional)
Token you received when you collected the CVV code
ozjc9rJvShqRkDw3lugOnulq
userName (optional)
Unique userID or username if the parameter userEmail is generic
659751 or JamesBond
userEmail
Unique email address of the authorized employee who retrieves the credit card number
SHASign
SHA Hash - Hash converted to hexaDecimalString
SHA.256(salt+merchantId+aliasCC+userEmail)
language (optional)
The language code in which the no-show page should be displayed
en, de, fr, it, es, ru

SHA.256 Security Sign

Generate NoShow-specific SHA.256 Security Sign with salt value, merchantId, aliasCC (token) and userEmail
1
salt = V3hmMm29gD35OVHWDSAYKBIBCRg0znRekNvGbM9d8I4GRgfIcs // Setup in Step 1
2
merchantId = 1100005007 // Your Merchant ID
3
aliasCC = AAABcHxr-sDssdexyrAAAfyXWIgaAF40 // CC token to be de-tokenized
4
userEmail = james.[email protected].com // Email address of NoShow-User
5
6
→ String: V3hmMm29gD35OVHWDSAYKBIBCRg0znRekNvGbM9d8I4GRgfIcs1100005007424242SKMPRI4242 // Concatenate all 4 values
7
james.[email protected].com
8
SHA.256(salt+merchantId+aliasCC+userEmail) // Use SHA.256 Hash Converter
9
→ SHASign: f641a6a3de574bd4b7609320e9a4fb1ed11364f136908822ff6a8e3b6b1bca1f // Security Sign for NoShow.jsp
Copied!
The salt value can be accessed in the PCI Proxy dashboard within the API Keys section.

Optional: Add JavaScript callbacks/hooks

1
// Use the attached Javascript callsbacks/hooks file to see which events are getting emitted to the parent frame.
2
// Bind an event listener to the parent frame to listen for those events:
3
4
function messageReceived(message) {
5
console.log(message.data);
6
}
7
8
if(window.addEventListener)
9
window.addEventListener("message",messageReceived);
10
else
11
if(window.attachEvent)
12
window.attachEvent("message",messageReceived);
13
else
14
console.log("Could not listen.")
15
16
/*
17
Possible event messages:
18
{type: 'error', reason: 'wrong request'} Invalid merchant id, alias or sign
19
{type: 'error', reason: 'service not allowed'} Merchant not configured
20
{type: 'error', reason: 'fraud check 3082'} Declined by fraud check
21
{type: 'error', reason: 'system error'} System error
22
{type: 'error', reason: 'invalid sign'} Invalid sign
23
{type: 'error', reason: 'time expired'} The user did not enter the chaptcha in less than 90 seconds
24
{type: 'error', reason: 'wrong captcha'} The entered captcha was wrong
25
{type: 'error', reason: 'invalid card'} Wrong card number
26
{type: 'error', reason: 'velocity checker'} Declined by velocity checker
27
{type: 'error', reason: 'wrong alias'} Wrong alias
28
{type: 'waiting', reason: 'captcha'} The page is waiting for user input of captcha
29
{type: 'success', reason: 'CC'} The card number was successfully displayed
30
{type: 'success', reason: 'CVV'} The CVV code was successfully displayed
31
*/
Copied!

PCI DSS Compliant User Management

Using our NoShow.jsp script requires you to handle your user management and password policy in a PCI DSS compliant way. 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. Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for their actions. When such accountability is in place, actions taken on critical data and systems are performed, by and can be traced to, known and authorized users and processes.
Shared user logins are not allowed.

Password Policy

The effectiveness of a password is largely determined by the design and implementation of the authentication system—particularly, how frequently password attempts can be made by an attacker, and the security methods to protect user passwords at the point of entry, during transmission, and while in storage. In general, the following minimum password rules have to be observed:
  • Users are required to change their passwords 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.
  • Vendor-supplied defaults will not be allowed.
  • When passwords are generated for the user, the password must be unique to each user and be changed after the first use.
  • 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.