The best option is to pass the unique credit card number to Kount so these orders can be linked to other orders across the Kount network of customers as well as across your own orders. Credit card data should be passed to Kount after being tokenized by Kount's hashing algorithm, called KHASH. This payment token can be used to link the payment information with other orders across the Kount network. If you can get a unique payment token returned from your payment gateway, you can pass that into the SDK with the PENC=KHASH or MASK, depending on your development language.
- KHASH is your only choice for the PENC (Payment Encryption) value when using .NET or Java (PENC=KHASH), unless you know how to build a custom method for PENC=MASK.
- If using PERL or PHP, then the PENC can be KHASH or MASK.
- When using KHASH, the BIN is extracted from the PTOK value, but the last 4 digits must be passed independently from the BIN# or token in the LAST4 field - the LAST4 is lost during KHASH.
Or, if your customers enter their credit card number directly on your company website, you could scrape this card information and pass it to Kount – you would be PCI Level 1 compliant since the value is passed directly through the SDK and immediately encrypted. If you bypass the SDK, you could do a direct HTTPS post using key valued pairs. Raw credit card information should never be sent to Kount.
If you do not receive a unique payment token for every credit card number, the next best option is to pass BIN + 4 to Kount. This is valuable because we get the card’s issuing country, which merchants can write rules around to catch fraud.
Note: BIN data only populates for VISA and Mastercard brands.
If there is no unique payment data, such as the raw credit card, then there is NO credit carding linking across the Kount network of orders nor across your company’s own orders. If the credit card information is not available for tokenizing you can send the payment type as none (PYTP=NONE). When you pass a PTYP = NONE, we’ll still be able to get linkages between orders using device data, so it’s not absolutely essential, just helpful to have since it gives you an additional data point to evaluate.
Note: If you pass a PTYP=NONE, then the PTOK must be empty. This cannot be updated with Mode U or X.
Refer to the Technical Specifications Guide for more information about RIS Payment Types and encryption options.