eGATE

[sharon]

We are processing credit cards manually at the moment for our online store and was thinking of applying for eGATE which is run through the ANZ bank, which is where we have our business account. I don't see eGATE as an option under the credit card payment options.
Sharon
www.kitcheninabox.com.au
Flat pack kitchens delivered Australia wide

[fooj]

You have to be VERY careful here. I've been down this exact road and there are some things you need to know to avoid you being illegal under the new PCI DSS.

ANZ's eGate is a real time payment gateway which means you will have to capture the credit card details on you emcart first for you to then enter into ANZ's eGate (assuming you are wanting to do it manually).

The facts are you CAN NOT do this legally under the PCI DSS unless the cart, its URL, its dedicated IP address, its hosting, its network has been certified PCI DSS compliant and you get certification. The costs can be pretty extreme.

Now, I too transact manually into my merchant account but to capture credit cards legally I use http://e-path.com.au. e-Path give you your own completely dedicated gateway system that's under THWATE SSL and also PCI DSS certified. Check them out.

Easy Merchant must have a module for e-Path somewhere as it is a beaut way to safely accept credit cards very cheaply and process manually offline.

Hope this has been a help.

[aschiller]

Thank you fooj for providing me with the opportunity to comment on e-path. We have been aware of e-path for a while now and note some glaring discrepancies between the claims made and reality, specifically:
1) The PCI DSS compliance claim made by e-path appears to be based entirely on the fact that e-path systems pass McAfee Hacker Safe scans. There is for more to PCI DSS compliance, which appears to be conveniently overlooked on the e-path site.
2) Assuming e-path systems were in fact PCI DSS compliant beyond the claims made in point 1, by passing on the credit card data to e-path customers e-path are eliminating all of those benefits because e-path customers have no less onerous compliance requirements because they are still physically handling credit card data. The compliance of their service provider becomes a moot point in that situation. Using the e-path service merchants cannot honestly claim to be Self Assessment Questionnaire Validation Type 1 (https://www.pcisecuritystandards.org/saq/instructions.shtml) which would be a simple 4 page self assessment. Self Assessment Questionnaire Validation Type 5 would apply using e-path, resulting in 32 pages of self assessment requiring significant technical and security knowledge to complete.
3) The e-path service adds no value whatsoever to the manual card processing already provided by ezimerchant, whereby the credit card data is securely passed on to the merchant for subsequent processing. You will no doubt come back and claim PCI DSS compliance, but we pass Hackersafe as well, so the point remains moot.

There will never be an e-path module for ezimerchant. I am very surprised that other cart providers have not seen the e-path service for what it is, nothing more than a manual credit card processing hosted payment page.

The e-path system does have one thing going for it, being the ability to defer processing of the transaction until the merchant is satisfied that it is not fraudulent and that the products are in stock, etc. This benefit has been provided to users of ezimerchant's manual credit card processing facilities for over a decade.

Your post in combination with my points made above does highlight a major shortcoming in the current way of processing credit card transactions online. On one hand, using manual credit card processing, merchants are left with the responsibility of securing credit card data (and onerous PCI DSS type 5 validation that brings). On the other hand, using real-time payment gateways, the transaction occur in real-time, eliminating the flexibility of merchants deciding if and when to process the transactions. To eliminate the shortcomings of both methods, we are releasing a new ezimerchant feature "Deferred real-time processing" next week which will provide the flexibility of manual processing with the security of real-time:
• Credit card details will be securely captured and validated during the checkout. These details will NOT be passed on to the merchant. Merchants do not handle credit card data, hence they qualify for the simple PCI DSS Type 1 validation.
• Merchants will have the ability to capture funds through the ezimerchant order management interface after satisfying themselves that the order is legitimate and they have all the good in stock. The option to capture a different amount in the case of part shipments and changed orders will also be supported.

[fooj]

Thanks for the opportunity to comment in reply.

I certainly don't have the knowledge of you in this area but I am no fool. I did a lot of ground work before deciding on e-Path. This included me speaking to Visa Asia Pacific directly as well as my bank. I've been caught out before so I was a little parnoid.

But based on what I do know I don't think your assessment is 100% correct.

It is true my e-Path gateway is hacker safe but it is also PCI DSS compliant. The two are completely different things according to e-Path. I was given a copy of the PCI compliance certification when my gateway application was approved.

My site doesn't pass on credit card details to e-Path so you may be mixed up there. My site doesn't touch credit card details at all.

The other thing is that it is not a processing payment page. It doesn't process anything on the open internet. I do this offline well away from the perils of the internet.

I like the fact my customers credit card details are never permanently stored online. I know other gateways and shopping carts permanently store credit card details but no matter how safe it is it can always be a target of hackers. According to Visa the majority of fraud happens because secure storage is hacked or compromised.

I think getting credit card details away from the internet is a really big plus and I think my customers don't mind the idea their details will only be processed by little ole me, and not potentially hackable to the whole world.

My bank gave me a SAQ to complete, it was a Type3 SAQ B which wasn't that difficult but I had to establish set processes to follow.

That's about all I can tell you. I don't really mind the manual system where I charge offline because I really like the control you mention. I have been able to identify quite a number of attempted fraud payments so I'm charge back free (touch wood). And its a bit cheaper too.

Visa Asia Pacific and my bank give e-Path the OK so that's good enough for me.

I am worried about your comment about not having an e-Path module. My website guy must have done this himself then.

Thanks

[niko]

Part of the security issue I have is the placement of the creditcard details in the order. The creditcard details are not easily destroyed because of it's location with important data below it, that being the item and freight costs. I would have thought Ezimerchant would have either placed the creditcard info at the bottom of the printout or create a second page with the order number so it can be shreaded. I think this is a critical issue for all.

[aschiller]

Fooj, can we have a look at your website to see e-path in action?

Btw, how did you go about getting yourself PCI compliant given that e-path is sending you the card details forcing higher levels of PCI scrutiny onto you? Reviewing SAQ B it would seem that it would be impossible to comply with requirement 3.3 "Is the PAN masked when displayed". If the PAN was masked when displayed to you, you would not have the data to enter into your terminal.

Don't you think something like ezimerchant deferred realtime (http://www.ezimerchant.com/ezimerchantdeferredrealtime.asp) which gives you all the flexibility of manual off-line processing with none of the security risks a superior solution?

[aschiller]

niko,

It is possible to create custom order reports which don't include the credit card data. With the release of ezimerchant 4.0.87 it is now also possible to easily truncate the credit card number, which you could do before printing the report (after manually processing).

A better approach though would be to use ezimerchant deferred real-time processing (http://www.ezimerchant.com/ezimerchantdeferredrealtime.asp) which would completely eliminate the need to handle credit card data. The order reports would not include any sensitive payment data.