Tag Info

New answers tagged

0

Visa Europe document that includes good diagrams for all the common PCI e-commerce implementation approaches and PCI implications. "Understanding the SAQs for PCI DSS v3.0" Describes the differences between SAQ A and SAQ A - EP


0

The previous respondent has done a good job of answering your question. However, here is some additional insight. a) Gazzang is no longer going to be selling or supporting their zTrustee solution starting next year 2015 (the support ends in June or July). So all Gazzang customers are looking for other solutions. b) You should also take a look at PCI DSS ...


1

The ideal solution always avoids storing card data in electronic form. I know that many payment processors have functionality now that lets you store cards with them in customer profiles. Then when you need to charge the card you can just pull up the customer and enter in the amount through the management interface the processor provides. I'm not super ...


1

Caveat: IANAQSA, and this is more guesswork than usual. Using the logic I used in this answer, the answer would seem to be no, as you're not "involved in payment card processing". However, in your comment to @bobince's answer you state that your client "is saying we must be PCI-DSS compliant. Can they claim such?" Well, if they're subject to PCI DSS, then ...


2

The requirement to comply with PCI-DSS is contractual, typically in the agreement between a merchant who wants to accept card payments and their acquiring bank, or between a merchant and a provider of payment services. If you haven't signed an agreement with anyone agreeing to maintain PCI compliance, you have no requirement to abide by it.


0

The aim of PCI DSS (Payment Card Industry Data Security Standard) is to prevent against credit card fraud via its exposure. Since you said that: ...our system was set up such that you enter the credit card number that you will be paying the bill for. For sure if your clients need to enter their credi card numbers, this increases the exposure to ...


2

If you're asking whether a generic email provider such as gmail has PCI compliance issues because of what it's users may do, then no. Consider the DSSv3 definition: PCI DSS applies to all entities involved in payment card processing—including merchants, processors, financial institutions, and service providers, as well as all other entities that ...


2

My advice to you is, rip off the band-aid and go modern. It's hard to judge without knowing more about your situation (who's collecting the CHD? What environment? In an office? On the phone? On the street?). But the easiest way to make it all go away is to go for mobile-device based swipies that will encrypt before the info hits your device and send it ...


1

The mobile application cannot currently be validated or considered a compliant payment application. Guidance on security and compliance in mobile applications has been issued by the SSC here: https://www.pcisecuritystandards.org/documents/Mobile_Payment_Security_Guidelines_Merchants_v1.pdf As your environment is receiving and transmitting cardholder data, ...


1

I agree with Mike Scott that SAQ-C should be ample in your case. SAQ-C does require you to be scanned by an ASV. Do mind that you don't store any cardholder data at any point. It's important to verify that you: clear logs prevent crashdumps containing cardholder data For mobile applications you should ensure to use non-serializable datatypes. This ...


2

If you're sure you never store the payment details, not even in things like swap files or core dumps, then I think SAQ-C will be sufficient. I think it's almost certain that you'll need to change some of your processes to complete the SAQ successfully; you won't just be able to fill it in and say that you're done.


-4

Payment Card Industry Data Security Standard -> Yes, it is wrong! You can maybe check what is wrong with the handshake on the Qually SSL Labs server test: https://www.ssllabs.com/ssltest/ If it was any service, they could offer it without SSL and tell you to use it, but here it is just crazy to even suggest it. +what Xander said.


33

Yes, this is wrong, and here is why. As you mentioned, PCI-DSS requires that communication containing sensitive data be handled over a secure channel. As a part of this process, certificate validation ensures that the certificate in question is in good order and belongs to the party that you intend to talk to. If you do not validate the certificate, the ...


1

I see no problem with it from a compliance perspective. The traditional way is to use asterisks (*) or hashes (#) to block out the digits, but zeros should be fine too. The point is that you're meant to not display (i.e. hide) the real digits. My only concern is that it could be confusing to a user that looked at the number, as it's ambiguous (from one data ...



Top 50 recent answers are included