CreditCardInfoCreditCardNumber returns ******1234 but didn't always |
Author |
Message |
JonB |
|
Group | : Members |
Posts | : 5 |
Joined | : 2008-01-30 |
|
Profile |
|
Posted : 2008-04-13 07:04:39 |
This used to work and I have no idea why it now blinds all reads of the CreditCardInfoCreditCardNumber field in the Customer table.
I had used QODBC previously to transfer an entire QB 2006 Canadian company into a new QB USA 2008 file. At that time, I had no problem reading the actual credit card number from an MS Access application using an ADO connection. Now when trying to read from the QB USA 2008 company I either get NULLS in this field or the information is blinded with the asterix characters as in the subject above (the same thing happens using te supplied VB Demo application). This depends on what optimizer flags im am using (VERIFY, NOOPTIMIZE, etc.) I haven't found a combination yet that gets me the whole credit card number.
Before you ask why I need this it's because we do our own credit card billing through the Authorze.net gateway and I don't want to have to maintain a separate store of CC information for security reasons.
What happened?
We are running: (USA Versions) QuickBooks Premier Edition 2008 Release R5P QODBC 8.00.00.242
Thanks.
|
|
|
|
Tom |
|
Group | : Administrator |
Posts | : 5510 |
Joined | : 2006-02-17 |
|
Profile |
|
Posted : 2008-04-13 14:33:55 |
Basically Intuit will not let us optimize Credit Card information in QODBC. So to extract it you must run the query directly against QuickBooks using the unoptimized or calldirect tag like this:
SELECT Name, PreferredPaymentMethodRefFullName, CreditCardInfoCreditCardNumber FROM Customer unoptimized where PreferredPaymentMethodRefFullName is not null
|
|
|
|
JonB |
|
Group | : Members |
Posts | : 5 |
Joined | : 2008-01-30 |
|
Profile |
|
Posted : 2008-04-14 02:56:27 |
I just noticed that I didn't say this in my original post: I have tried every optimizer flag (inclufing unoptimized/calldirect) as well as turning off the optimizer completely with the same result:
I
Yes, I have confirmed that the actual credit card data in the QuickBooks file contains the real numbers. |
|
|
|
Tom |
|
Group | : Administrator |
Posts | : 5510 |
Joined | : 2006-02-17 |
|
Profile |
|
Posted : 2008-04-14 19:55:55 |
Sorry, but I'm able to see the Credit Card information exactly the same as I typed it into QuickBooks 2007 Premier USA Edition:
Try typing in a new customer credit card number in and see what QODBC sees. |
|
|
|
JonB |
|
Group | : Members |
Posts | : 5 |
Joined | : 2008-01-30 |
|
Profile |
|
Posted : 2008-04-14 23:20:10 |
I created a new customer in my existing QB company file. It returned the same "xxxxxxxxxxxx1234" result.
I then created an entirely new Quickbooks company (using all default settings). I then added the customer, cretaed a new Machine Data Source (using the default settings), allowed QODBC full access (which was the only option), connected using the VB Demo application and ran the query. Same result:
I believe that I have checked every security setting in both QB and in QODBC to make sure access to personal data is turned on. Is there any way to see what's coming through the QB API to see if it's QB returning the incorrect result? I've turned on Detailed Tracing but after re-running my query the file is empty.
Also, you said you tested it with QB 2007 is it possible that this is a new "feature" of QB 2008 to prevent people from "competing" with Intuit's integrated credit card service? |
|
|
|
Tom |
|
Group | : Administrator |
Posts | : 5510 |
Joined | : 2006-02-17 |
|
Profile |
|
Posted : 2008-04-15 18:16:33 |
Sorry, but Intuit no longer allows the full credit card number to be seen using QuickBooks 2008 USA Edition and the qbXML SDK v7.0. The API is changing the Credit Card to "xxxxxxxxxxxx1234", not QODBC.
As discussed in Intuit's qbXML SDK 7.0 release notes and the IDN newsletter, QuickBooks 2008 and Enterprise 8.0 will NOT return unmasked credit card data to SDK applications. This is required by the payment card industry (PCI) review of QuickBooks for compliance with Payment Application Best Practices (PABP). To do otherwise would require all SDK applications to be audited for compliance with PABP which was obviously not an option. |
|
|
|