Thank you for all the comments and ideas. Is there a document that would address and confirm my concern and questions regarding the local credit card storage?
1. I have a need to store credit card # on local server to accommodate some business requirements. This will enable ONE CLICK order using the existing credit card on file. Similar to what Amazon shopping cart offered. Another option I am thinking of is offering customer ability to store and select different credit card at the check out. Perhaps, there are a better way to achieve the above requirements without store the credit card i# locally. Any suggestion? 2. Would Ofbiz enable the credit card to process multiple (concurrent) transaction at the same time? Tradition, credit card systems often only allowed to process one transaction at a time. And if a locked happened or something similar occurred than the whole credit card incapable of processing any subsequent transaction. Thanks, Tom On Tue, Oct 7, 2014 at 8:43 AM, Ted Byers <r.ted.by...@gmail.com> wrote: > 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 <raubvo...@gmail.com> > wrote: > > > On Mon, Oct 6, 2014 at 11:52 PM, Tom Running <runningt...@gmail.com> > > 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. >
