For several years now, I have been working in the area of developing software to support ecommerce; specifically in the area of supporting electronic transactions, and risk management.
On Tue, Oct 7, 2014 at 7:59 AM, Mauricio Tavares <[email protected]> wrote: > On Mon, Oct 6, 2014 at 11:52 PM, Tom Running <[email protected]> > wrote: > > I have questions which regarding PCI compliance. > > > Rule 0: PCI compliance is designed by banks to protect banks > while keeping government regulations away. As far as the merchant is > concerned, it is like riding a motorcycle: when bad things happen, no > matter who is wrong you always lose. > That may be, but some processing banks will not give an account to a merchant that is not PCI compliant. Note, this usually means a security audit, including penetration testing, on a regular basis; among other things. > > > 0. > > Would someone able to shed some light on how the credit card logic work? > > > Which part? > > > 1. > > Does it contact the credit card authorize gateway for a small authorize > > amount and > > void if success. Then captured the final CC amount at the order picking > > and shipping manifest process? > > > No, that is a dumb way to do things. Authorize for the full amount, and use a fraud detection service.Submit the authorization to the bank, and asyncronously submit the requisite data to the fraud prevention service. If the fraud service detects a potential issue, then void any successful authorization (no need for action if the authorization fails), You will have results from both within 5 to 6 seconds. If the intent is a regular sale, then proceed with a capture if the fraud service does not detect a problem and the authorization succeeds. If either fails, then return the appropriate error message to the end user. In fact, some gateways have no authorization service, but rather implement their sales in precisely this way, except that they process the automatic capture days afterward rather than immediately (I do not see the sense of such a delay, but that is the way some do it). But, if the intent is just a sale, and you do not want to use a fraud detection service, then just process the sale as you were advised. > Besides costing you a transaction, making a small payment ($1) > is deprecated. If the sale is right now (buying cat food at the > store), you can just make the sale. If customer does not have money, > sale is denied and reason is given by processor. But, you can always > do a hold. If customer has no money, hold will fail. If there is > money, hold is created. When sale actually takes place (say online > site and you are about to ship), convert hold into sale. Unused holds > expire within a week. > > Now, there seems to be a gas company that will not convert the hold > into a sale even after sale is made or cancelled. I do not think that > follows the rules. > > Use a return instead of a void since a return removes hold immediately > while void won't. Customer will prefer return. Refund is a different, > post-settle, bag of cats. > > > 2. > > Does it keep or store the customer Credit Card information on the OFBIZ > > server? > > Credit card information such as: > > PAN, expiration, CVV... > > > AFAIK, it shouldn't, but I may be wrong. The software I worked > with would be put between, say, OFBiz and payment processors. It can > keep customer credit card info, but since it is PCI compliant by > itself -- if you lose the admin password or the db key (need both to > access DB), you are better off settling remaining transactions and > starting over -- the merchant exposure is reduced. So all OFBiz has to > do is send payment info and do something based on reply; it should not > need to keep PCI data. > > A PCI compliant merchant is not allowed to store credit card information unless they use a PCI compliant vault (probably what the software you worked with did, but there is more to it that just software - a properly designed vault requires a whole separate subnet, and a whole series of security protocols to ensure only authorized machines can talk to it). > > > > 3. > > If it stored credit card information on the server, does it encrypted > > before written to the database? > > > If it does, it better. Once again, I can't see the reason why it > would. When you use something like the software the place I worked at > sells, paypal, google wallet, paymentech, and the other usual portal > suspects, they store the card data in their servers. Ok, our software > would store in *your* server because we are not a portal, but it likes > to keep its database encrypted in a paranoid way (we have no backdoor > if you loose your admin pw). In fact, when "experts" were talking > earlier this year about the important of 2048 bit encrypted, my boss > laughed and said "er, we have offered 2048 bit encryption for more > than 10 years now." > > Which leads to: the connections between each device/program that makes > the chain going from credit card to payment processor better be > encrypted. > > Yes, if you must store such data, ensure it is encrypted, but be careful of the algorithm used, and make sure you fully investigate how to create, manage and use a vault so that such sensitive data is stored ONLY in a properly designed and implemented vault. For most merchants I have seen, it is more cost effective to buy vault services than it is to try to make your own. As an aside, I would not be pleased with your software storing such data on my server, and had I been involved in it, I would have insisted on using the processing bank's services designed for that purpose. If the processing bank does not provide such services, then I'd either find a different one or I'd find a gateway that deals with it and that does provide such services. The liability involved means that in most cases, it is not worth the cost of doing it yourself. > > 4. > > If it store the CC information on the server but doesn't encrypted. > > Does anyone has done this before? > > > > Thank you. > > Tom > Only a raving lunatic would even consider storing such sensitive data in clear text. Do not do it! If you do, you open yourself up to a whole new level of pain and risk. In all the time I have been working in this industry, I have never even considered storing such sensitive data on my servers. The only use case where it makes some sense is in the realm of recurring billing (e.g. monthly subscriptions to services), and for that it is infinitely better to rely on the processing bank's vault and API for the recurring billing rather than building your own. Cheers Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D.
