Buy Support
Incidents |
If you can't find your answer
in the FREE PUBLIC QDeveloper Forum, require URGENT Priority Support, or you need to send us
private or confidential information: |
Click Here
|
If you can't
login and post questions or you are having trouble viewing forum posts:
Click Here
|
Callback
Support |
If you live in USA, UK, Canada, Australia or New
Zealand, you can leave us details on your question and request us to call you back and discuss
them with you personally (charges apply). |
Click Here
|
Buy Support
Incidents |
If you can't find your answer
in the FREE PUBLIC QDeveloper Forum, require URGENT Priority Support, or you need to send us
private or confidential information: |
Click Here
|
|
v8 Upgrade resulting in encrypted Credit Card Numbers |
Author |
Message |
|
Posted : 2008-06-14 06:12:27 |
We recently upgraded to QuickBooks Enterprise Edition v8 and were a licensed user of QODBC with full read/write access for v7. Upon upgrade we changed to the free read only QODBC v8 driver and are now unable to retrieve Credit Card numbers unencrypted.
I've checked the Applications Preferences settings in QB to ensure the interface still has access to sensitive information (i.e., SSNs and Credit Card Information...). Everything appears to be set up properly.
Do we have to go back to the Read/Write version fo the Driver or could I have overlooked something? Everything worked fine in version 7. Any assistance or advice would be appreciated.
Thanks,
ME... |
|
|
|
Tom |
|
Group | : Administrator |
Posts | : 5510 |
Joined | : 2006-02-17 |
|
Profile |
|
Posted : 2008-06-16 08:00:41 |
The change occured in QuickBooks 2008, it doesn't have anything to do with QODBC v7 or v8. See: CreditCardInfoCreditCardNumber returns ******1234 but didn't always for more info.
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.
|
|
|
|
|