Manual Credit Card information capture

Next topic

Author	Message
Nigel Hulls	Tuesday 11 March 2008 9:54:09 pm Hi ez-community I'm implementing a basic ezipublish website that has a very small and simple e-commerce facility. Basically I want to add to the default ezi webshop. When a customer clicks confirm order, i would like to capture their credit card details, so that the client can then process them manually. I've looked at ezauthorize, and whilst it's a fantastic solution, my client does max 20 orders per month of small cash amounts, so a merchant bank gateway is not economically feasible. I'm surprised that the default ezi install does not have manual credit card capture as part of the standard webshop. Before I get down and get my hands dirty, i was hoping that someone else out in the community has created this previously and could send me in the right direction. I'm more than willing to do the work to release it back to the community as an extension etc cheers Nigel Hulls www.quiqcorp.com
Bruce Morrison	Tuesday 11 March 2008 11:13:17 pm Hi Nigel Welcome to the ez community! I've done this by creating a custom shop account handler and collecting the CC details along with the billing/delivery addresses etc. A cron job then removes the CC details from the DB once the order has been marked as processed. You might want to get you client to check their merchant account conditions with the bank to ensure they are permitted to take orders from the Internet. I believe it is common in oz for banks to have restrictions on this type of thing. Cheers Bruce My Blog: http://www.stuffandcontent.com/ Follow me on twitter: http://twitter.com/brucemorrison Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish
Heath	Wednesday 12 March 2008 12:56:31 am Hello, eZ Authorize (svn, trunk) happens to provide for encrypted credit card information storage within each order! One could cut out the authorization and only use the information storage features for example ... Cheers, Heath Brookins Consulting \| http://brookinsconsulting.com/ Certified \| http://auth.ez.no/certification/verify/380350 Solutions \| http://projects.ez.no/users/community/brookins_consulting eZpedia community documentation project \| http://ezpedia.org
Nigel Hulls	Wednesday 12 March 2008 3:01:43 pm Cheers for your solution Bruce, that was a path i was looking at. As a short term solution i'm hacking ezauthorize to make it do what i want. I have a major problem in that the client is using ez 4.0 and i need to convert ezauthorize over to php5. Thanks for your replies guys. Nigel Hulls www.quiqcorp.com
Bruce Morrison	Wednesday 12 March 2008 3:37:05 pm Hi Nigel Shop account handlers aren't that difficult to do. Hacking ezauthorise just to add the CC info collection is probably more difficult (given the scope of the extension) than looking at the default shop account handlers in eZ as they will already be ported to php5. Look at kernel/classes/shopaccounthandlers/ezsimpleshopaccounthandler.php kernel/shop/register.php Cheers Bruce My Blog: http://www.stuffandcontent.com/ Follow me on twitter: http://twitter.com/brucemorrison Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish
kracker (the)	Thursday 13 March 2008 12:27:01 am While Bruce suggestion is accurate, it is simpler for the inexperienced, another very serious point to consider is security of your customer information. This subject goes so very much much deeper.. While using the GPG encrypted storage provided with eZ Authorize is as Obi-Wan Kenobi would say ". . . from a certain point of view" more secure than storing this information in plain text form within a user content object / plain text datatype .... Most of the information security professionals and credit card companies point out that if you store sensitive information like credit card information on any public webserver in any form (encrypted or otherwise) you are leaving the information at great risk. These same companies have recommended at great length that the actual storage only occur behind a specially fire walled storage system completely separate from the front end web application/servers. The trouble often surrounds customers. Whether by malicious intentions (yes some business leave customer information insecure and use another separate third party to steal customer information indirectly on their own behalf), ignorance, or greed (not wanting to pay for an industry standard secure solution to be used or developed) ... the results are all to often the same in the egalitarian or fascist realm that is the world of business, customers are at risk when they give out their personal information. Customers often want to store this information in generally insecure ways (even when they don't realize it) because this additional security brings a host of additional cost and requirements in the software solutions they are creating / using / working with. Most payment gateway service providers sell the more secure payment information storage services. Authorize.net for example at additional cost offers such a service which is a vastly more secure storage alternative. Sadly from all the customers I have encountered to date ... care more about reducing their bottom line than securing customer information in a real way. Many disregard the separate storage requirements / recommendations and store credit card information in the databases or filesystems of public web servers. Even eZ Authorize which offers encrypted storage within a single eZ Publish installation ... is not immune to these realities. This may be why it was never packaged and released as a default enabled option. The key concern is that if the public webserver can encrypt and decrypt the information through the application itself, chances are, if a malicious attacker could compromise the server, gain access, it is possible that they could gain access to the information encrypted or otherwise. Which is just a brief tip of the iceberg that is this issue. In the past while the recommendations were strongly against these bad practices. It seemed they were not 'illegal' or directly forbidden. Which in part is why so many normal software developers trying to earn a living have been coerced into creating bad solutions to meet manipulative customer demands. We do need to earn a living and take care of ourselves. Thankfully it seems the industry is starting to change. Looking just now at a glance I find changes brewing. Sadly compliance is not perfect. As long as small business (as a simple example) are willing to do something foolish (for what ever excuse) and their are other people (often developers looking to earn a living at demands of another person) poor results will continue to occur. This is not new and passing laws does not put an end to this cycle. Here are a few related links regarding this avoided subject. http://www.securityfocus.com/news/11496 http://www.darkreading.com/document.asp?doc_id=138838 http://www.pcicomplianceguide.org/ Please do be careful. Think of others before yourself. Treat others as you would wish to be treated. Be responsible. Use wisdom. It is OK to say no to a customer. There are always better ways to earn a living. I've said it before when talking about information/software security. "Remember that humans are insecure creatures so it is no surprise that the systems we continue to create are all to often equally insecure". <i>//kracker</i> Most refuse to accept the truth about .. until it is too late. <i>"...The world can not be free! Because Man does not want it to be!" -- kracker @ 06/07/2007</i> Member since: 2001.07.13 \|\| http://ezpedia.se7enx.com/
Bruce Morrison	Thursday 13 March 2008 1:02:58 am kracker brings up some very valid points, I think the gist of which is that "storing CC details online is not good ". Like all security related issues there is a balance that has to be found between security and practicality. If you do store CC details I'd recommend that: + the client is informed of the risks, + the client contacts their bank to ensure they are Ok with the procedures in place and that they are covered by the bank (won't be held liable) if problems arise (get this in writing), + ensure that access to the CC details only occurs via a SSL connection (actually the entire admin interface is access via SSL to ensure passwords cannot be intercepted) + CC details remain in the system only as long as necessary. Cheers Bruce My Blog: http://www.stuffandcontent.com/ Follow me on twitter: http://twitter.com/brucemorrison Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish
Nigel Hulls	Thursday 13 March 2008 2:57:40 pm Cheers for the info guys. I think in this instance, the client is not automating transaction details via the bank, but simply capturing the card details and manually entering them into an EFTPOS terminal. The key here then is quoting Bruce '+ CC details remain in the system only as long as necessary.' As soon as the order is placed the credit card details are stored in the database. As soon as the details have been inputed into the EFTPOS terminal they are then deleted from the eZ database. I think this solution gives a balance of security vs practicality. Only the orders currently processing are at risk of being hacked / snooped etc thanks Nigel Hulls www.quiqcorp.com
Troy Simmons	Wednesday 19 March 2008 12:30:34 am Hi Nigel, Have a look at this manual gateway solution: http://e-path.com.au. I think you may find it fits exactly what you've been looking for. I do the same as what you describe and e-Path works for me very well. I agree, the PCI DSS stuff is really important now. You can't mess with it. Cheers Troy
Nigel Hulls	Wednesday 19 March 2008 2:57:57 pm thanks for the input Troy. I've managed to get the latest version of eZAuthorise from svn, hack it around quite a bit and it's now up and running. It captures credit card details, performs a mod10 check on them to make sure they are valid, encrypts the data and stores in the database. When viewed the admin has the option of replacing the data to make the Ez db secure. When i get some time i'll update eZauthorise to php5, as I've already done most of it for this project. Nigel Hulls www.quiqcorp.com
Troy Simmons	Friday 25 April 2008 9:27:42 pm Hi Nigel, You want to be careful, from what you have just described you have to be PCI DSS compliant certified. The offocial PCI DSS definition is if your website stores, processes or transmits the PAN (primary account number usually the 16 digit card number) you have to be PCI DSS compliant certified. There's no work around anymore. There are diffierent criterias for PCI compiance, the base one is if your handle between 1 and 20,000 transactions per year. My guess is you would be in that category (like me). If you are not have PCI DSS compliance certification and you get caught, you could have your merchant account cancelled and be subject to fines that are insanely high (try $10,000 as the minimum!!!) I like doing things manually so to cover all bases I went with a PCI DSS approved manual gateway myself. My site doesn't touch cc details so I have no liability at all. That's the safest solution I could find to stay doing things manually but also be PCI compliant. Works extremely well for me. Hope this helps.