Obtaining a credit card's bin number

**Situation: **A credit card transaction fraud prevention is asking for the first six numbers of a customer's credit card information to interact with their API to determine a fraud score.

**Problem: **I cannot obtain or ascertain the credit card number as the number isn't responding to any attempt of being captured. For example, in orders.php there is the following line:

    // Sanitize cc-num if present, using maximum 10 chars, with middle chars stripped out with XX    if (strlen($this->info['cc_number']) > 10) {
      $cEnd = substr($this->info['cc_number'], -4);
      $cOffset = strlen($this->info['cc_number']) -4;
      $cStart = substr($this->info['cc_number'], 0, ($cOffset > 4 ? 4 : (int)$cOffset));
      $this->info['cc_number'] = str_pad($cStart, 6, 'X') . $cEnd;
    };

Now when I try to say catch the first six numbers of $this->info['cc_number'] from orders.php, I get a blank result. Even when I try to capture the whole 'cc_number' and its still blank.

**Questions: **

1. What part of the ZenCart CORE code (if any) actually uses that field (aka $order->info['cc_number']) and what part passes information to it?
2. If not the ZenCart code, do the individual credit card modules choose to send the data back to be stored in ZenCart's DB? (For example, I noticed that the Quickbooks Module sends back only the last 4 numbers to be added to the table, however the default AuthorizeNet and Linkpoint modules makes no update to the fields cc_number and etc.) Is this deliberate by design?
3. Reading the PCI-DSS guideline (specifically Guidance Notes 3.4 and PCI-DSS Requirement 3.3), I can see that it is okay to store only the last four and first six numbers in such a way that the full card number CANNOT be recreated. (Truncation of the number is okay.) (Quote from the PCI-DSS Requirement: "The intent of truncation is that only a portion (not to exceed the first six and last four digits) of the PAN is stored.") So may I modify the coding to accomplish this? (Assuming that I do not modify the code beyond the point to where it violates these rules.)
   Full PCI-DSS from here: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf

It depends where and when you're doing the inquiry, and whether the payment module you're using even collects any card digits at all. For example, if your payment module is processing cards on the gateway's website ('offsite processing') then your store will never know ANY of the digits of the card.
If however your module collects the number and transmits it for processing, then that payment module's before_process() method will have access to the card digits during the time it does the processing, and may pass it back to the $order object's info['cc_number'] array element.

If it's coming up blank, then I'm guessing your payment module never sets it ... probably because it never knows about it.

DrByte:

It depends where and when you're doing the inquiry, and whether the payment module you're using even collects any card digits at all. For example, if your payment module is processing cards on the gateway's website ('offsite processing') then your store will never know ANY of the digits of the card.
If however your module collects the number and transmits it for processing, then that payment module's before_process() method will have access to the card digits during the time it does the processing, and may pass it back to the $order object's info['cc_number'] array element.

If it's coming up blank, then I'm guessing your payment module never sets it ... probably because it never knows about it.

Or in my hasteful case I didn't realize I was looking at lines of "moneyorder" modules which do not use any of the CC's. Essentially I figured it out and I ended up mashing up my code a bit. (Learned a bit about the QBMS module in the process.) This just means that I can't make a "one-shot, fits all" solution and will likely just end up skipping this bit when its ready for distribution.