[Nick Horowitz]

Correction to my initial post after doing some research:

ODBC:

Neither the EFT fields used for ACH processing nor the CreditCardList fields are exposed in the ODBC schema.

Saved Search (Customer):

The CreditCardList fields are exposed in the Saved Search (but there is no flag to indicate which is the primary/default record, so you can’t tell which is primary), and none of the EFT fields are exposed at all. This is strange considering that both EFT and credit card data are actually stored in the same underlying record with a flag to indicate which is which! So there must be a filter that only returns credit card records from that table. We need to remove that filter, or else add some new logical fields which return the EFT-flagged records.

smbXML:

No support for either CreditCardList fields or EFT Fields

WebServices:

Support for CreditCardList fields (the entire CreditCardList is exposed), but none of EFT Fields are exposed.

Conclusion:

These 4 areas need to be fixed so that they are all consistent. For example, my immediate need is to be able to query the CreditCard & EFT Fields via ODBC, and then import updates via smbXML or WebServices.

I am also posting this over on the ACH Processing section under Payment Processing folder.

Case # is 550321 has been submitted. Pls add yourself if you want to vote for any of these fixes.
This is a cached copy. Click here to see the original post.

[btaylor-ns]

RE: EFT Fields Not Exposed in ODBC

We are PCI & CISP compliant, have been externally audited as such, and our certified compliance can be seen on the Visa website at: http://usa.visa.com/download/merchan…_providers.pdf

For regular user roles, you MUST HAVE the View Unencrypted Credit Cards permission to be able to view unmasked CC numbers. The Administrator and Full Access roles also have this permission. This flexibility is required to allow companies that work with 3rd party fulfillment and logistics (3PL) companies to export the numbers with their orders – they are then responsible for transmitting them in a secure fashion to the 3PL.

Note that Administrator and Full Access roles should not be used as “everyday” roles. They should only be used for administering the system, and the logins and passwords associated with these logins should be very closely guarded. In any non-admin role, unless explicitly granted the above permission, you will never see unmasked CC numbers unless you are entering a new card.

Displaying unmasked numbers as an administrative function is not a violation of PCI/CISP requirements. We explicitly and openly discussed this exact use case with our auditors, AmbironTrustWave – a very respected PCI auditor. The ability to see unmasked CC numbers for administrative purposes is clearly called out in our Report on Compliance submitted by AmbironTrustWave to Visa, and was accepted by both AmbironTrustWave and Visa as a valid business function.

The below excerpts are taken directly from the PCI 1.0 standard, with regards to masking Primary Account Number (PAN):

Requirement 3: Protect Stored Cardholder Data

… Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending PAN in unencrypted e-mails …

3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).

Note: This requirement does not apply to employees and other parties with a specific need to see the full PAN; nor does the requirement supersede stricter requirements in place for displays of cardholder data (for example, for point of sale [POS] receipts).

We take our responsibility to protect your customer data very seriously, so I wanted to take a moment to clarify the above post with regards to the security capabilities of our products as they relate to protecting this very sensitive information.

Best regards,

Brian K. Taylor

Systems & Compliance

NetSuite

[Nick Horowitz]

Thanks for the clarification, Brian. I retract my initial statement about not being PCI compliant.

[Author]

Posts