Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

mrbyte

Pioneers
  • Posts

    10
  • Joined

  • Last visited

Everything posted by mrbyte

  1. Guess it depends on the ability of the person. I'd like a free template that's close to what I'm after, then I can change it around to what I'd like it to be.
  2. You are most welcome ;-) I can see how one would think that 3.2.2 would overrule 3.2, but I believe it's actually subject to 3.2. It's only the PA-DSS that is specific in each point that it's after authorization. I've never advocated storing sensitive information beyond authorization, ever. Quite right. One must do their own research. I talked to my provider yesterday, and while I didn't make it a point blank question, I did mention it in passing, and there was no outburst of "you CAN'T do that!!!!" However, I also found out that I was incorrect in my estimate of what a gateway will cost. So, personally, I will be getting one if my site passes 5 orders a month. (I had set my "trigger" at 10 per month before.) My provider didn't seem to think this was a bad thing.
  3. Now flip over to the PA-DSS which adds a bit of clarification to PCI-DSS 3.2.2: 1.1.2 AFTER AUTHORIZATION (emphasis mine) do not store the card verification value or code (three or four-digit blah blah) Aligns with PCI-DSS Requirement 3.2.2 (emphasis theirs...)
  4. I've said before that a gateway is really the better way to do it, but it's been lost in the noise. I quoted 3.2 above. That's straight off the PDF file from the PCI committee/council/whatever's website, and you can get it here: https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf
  5. You're right, no matter how hard I try to fix you, you're still stupid, Dunweb. I have the PCI spec in front of me, and 3.2 in it's entirety says: 3.2 Do not store sensitive data after authorization, even if encrypted. Sensitive data includes the data as cited in following Requirements 3.2.1 through 3.2.3 Now, do I need to continue, or are we all following along. Good. Note the note that says sensitive data may be stored if there is a business justification and it is stored securely? Is it because you make so much money misinterpreting the standards? Or is it really just an inability to read, comprehend and understand basic English and how outlines and such work? Either way, you are a profiteering blowhard. As far as "Turning me in" go ahead. Good luck with that... Cheers
  6. I'm not using the correct terminology, CVV, CVV2, CV2... Whatever the 3-digit "magic number" on the back is called. PCI 2, section 3.2 specifically says it can be saved long enough to process and get authorization, and then must be deleted. It further states that it can still be saved, in a safe and secure manner if there is a valid business case to be made for doing so.
  7. Which could happen even with paper records from phone/mail orders. If someone were to use a manual module and NOT delete the CV2 info after use, that itself is a PCI violation, clear as day. So, while I agree with you about the consequences of a breach, I still do not believe that PCI or the law prohibit manual processing of credit cards. According to the PCI DSS requirement 3.2, the storage of sensitive authentication data after authorization is strictly prohibited. "After authorization" is the critical bit here. And I maintain that mangling the number as I described above, and using SSL and other encryption when receiving the email off of the email server used for the store's domain, by which I mean the email is not sent anywhere outside the host, covers the encryption requirements of PCI for data transmission. Someone makes the purchase, admin get's the info, processes the transaction and deletes the sensitive info. Compliance preserved. I'm talking a limited amount of processing here, say under 10 transactions a month. At that level, it's more than pennies to be saved. Beyond that, yeah, just the possibility of fraud or erroneous data entry alone should be enough for a responsible store owner to get a gateway. My main objection is the misleading tone taken by others when this question is even asked. It *is* misleading to say that manually processing cards is illegal, and I've proven it. But I will also say that processing a large amount of transactions manually is insane, opens you to fraud, errors and shouldn't be done.
  8. The silence is deafening. Now, to address the whole CV2 number problem, what I did in ZenCart's manual credit card module was to mangle the CV2 info. This is then emailed to the admin email address. Nothing in the email makes mention of the obfuscation of the CV2 number. I know the number is mangled, and I alone know what to do to unmangle it. After the CV2 number is mangled and emailed, it is not retained anywhere. Others wrote the module, I just added the mangle code. Anyone looking at the code would know as well how to unmangle the number, however this is only to stop/delay someone that's managed to gain access to the admin and email of a given store. Anyone that installed this module would be informed as part of the install process. I agree that a gateway is the best way, regardless of what my stance on PCI is. However, I also think that for a startup, that doesn't (yet) wish to pay the $20-50 monthly fees for a gateway, and already has a card-not-present enabled terminal, a manual option would be nice.
  9. From what I found, reading past the definitions is that the CPA governs GOVERNMENT entities. The other stuff you quoted, obviously without reading, require reasonable safeguards to prevent breeches, require encryption for transmission of data, and set forth the responsibility in the event of a breech. Again, nothing that prohibits the use of a manual card entry system. So, while I'm partially incorrect in stating that PCI isn't law, you're also incorrect to state that manual entry is illegal. You may not "claim" to be the PCI police, but you act like it. As far as my qualifications, I haven't seen YOUR credentials, but I'm just a guy that's sick of the loudest mouth winning. Nothing you have quoted really does anything for your case; most of the material actually proves mine. Cheers.
  10. I realize I'm new here, and all, but really, I feel I must protest a particular point. PCI DSS is **NOT** a LAW, it is a standard. Every time you bluster about the "illegality" of manually processing cards I cringe. Visa and other issuers are not government agencies. They are businesses. At worst, violation of PCI standards is a breach of contract, a civil matter, and the "fines" involved are from Visa/MC/etc, not your local state/provincial governments. Furthermore, they are for *breeches* and not for solely being non-compliant, as I understand. Finally, the PCI standards prohibit the *storage* of track data and CVV numbers. A PCI compliant manual processing solution *is* possible, but the way you carry on about the "illegal" nature of manually processing credit cards, folks seem to assume the loudest mouth is the wisest, or more likely, they just would rather not get involved in a urination contest with you over it. Misuse of credit card information *is* illegal, but misuse would be, for example, taking the captured information and fraudulently using that to make charges.Misuse is *not* taking the information and using this information from your own customer to process a sale they have agreed to in the first place. When I take orders over the phone I need the CVV to process. I don't store the number. When a customer emails me the information, I delete the email after I have processed it. While the email route may not be "compliant" it's not "illegal" and I curtail my risk of a breech by deleting the information after I've processed the order. Please, stop trying to the the PCI "police." If you still feel that PCI is a law, please post for me the federal or provincial statutes (for Canada) or the U.S. equivalent. Cheers.
×
×
  • Create New...