Accept credit cards online and process offline - e-Path module update

[HappyPappy]

Hi all,

 

For those who are using e-Path (http://e-path.com.au) to accept credit cards online and process offline, there is a new oscommerce payment module avalable now.

 

The new module includes a curreny code parameter (called "cur") which allows you to enter the country code of the currency your merchant facility will be charging credit cards in.

 

It is being distributed free by e-Path so contact them with your gateway ID and they will send it to you. Install is pretty easy. You uninstall the old one through your Admin then upload the two new modules (they overwrite the old ones) then install via Admin.

 

Happy sales everyone.

[Guest]

Ofcourse, you can only use that payment module if your site is PCI DSS compliant. So check first.

 

 

 

Chris

[Peper]

Currently we are looking into something like this.

Our existing payment gateway flags every transaction above $500

Customer needs to pass verification which could take 3 days, order abandoned

Customer purchase at some other store

[HappyPappy]

Ofcourse, you can only use that payment module if your site is PCI DSS compliant. So check first.

 

Hi Chris,

 

No, that's not right.

 

One of the advantages of e-Path is your site doesn't need to be PCI DSS compliant because it does not transmit, store or process credit card data. Your site doesn't even touch credit card data.

 

No need for PCI DSS compliant on your website. So that's a hassle you don't have to worry about.

 

But yeh, you will be handling credit card data so you need to handle it in a PCI compliant manner, exactly the same as you do when receving credit card details from a faxed order with payment, somone quoting you their credit card details over the phone on a phone order or via mail postal order or even if someone was to hand you their credit card in a face to face sale.

 

Thanks

[MrPhil]

I read a bit in the site you linked to, and it leaves me puzzled as to what's going on. Apparently, the customer enters their credit card information (including CVV2?) onto the e-Path site. Then, offline, you (the merchant) are sent the credit card information to verify against the order, and enter into your system (POS etc.) in the normal "face to face" manner. Is that correct? If so, you are still in possession of the full credit card number (presumably including CVV) at some point. Even if it's in an email (encrypted, I hope), I would think that PCI-DSS would still apply, as far as security measures go. e-Path says they don't hold on to the number after sending it to you, so let's assume that's true (let's not discuss what happens if the email is lost or corrupted). Now, does this use of your in-store POS credit card system meet with the approval of your bank/merchant account? Because it's not truly face-to-face, they're likely to charge higher fees to offset the higher fraud rate of online transactions where you can't see the actual card. There are just too many things here that raise red flags for me, and the breathless prose of the e-Path pages is heavy on hype and light on details. Also, who pays for this service? Are ads shown to your customer, or do the banks kick back something? They make a big point of saying how absolutely FREE FREE FREE this thing is, but someone has to pay for it somewhere...

Edited June 22, 2013 by MrPhil

[♥toyicebear]

Its not free, merchants pay a yearly fee starting at 275 AUD. When they say "free" they mean free as in no transaction fees. The merchant just pay the yearly fee and thats it.

[HappyPappy]

Hi Mr Phil,

 

I am no authority on it, but I have used it for five years now and I've set up many of my own clients with e-Path. I think it is a brillant system. Anyway, I'll have a stab at answering you.

 

Think of you using a fax machine to receive orders with credit card details on the order form. Same thing with e-Path except e-Path is on the net connecterd to your oscommerce cart and a fax machine is not PCI compliant but e-Path is.

 

I read a bit in the site you linked to, and it leaves me puzzled as to what's going on. Apparently, the customer enters their credit card information (including CVV2?) onto the e-Path site.

 

Every gateway merchant gets their own gateway system located on e-Path's PCI compliant server (hense no need for PCI compliance on my website). My customers give a payment authorisation on my gateway page. e-Path don't capture the CVV by default but if your merchant facility provider requires the CVV to be entered and approves a MOTO merchant having the CVV in their posession momentarily so they can enter it when they enter the card details to charge the card, then e-Path will capture the CVV.

 

But you must provide written proof directly from your bank that they have approved this for e-Path to do it. PCI regulations on CVV are very tough, the CVV must not exist in any way after payment authorisation has been processed on a card. You can't store it, keep it, record it or do anything with CVV once the payment authorisation has been completed. But pre authorisation it is OK to store it (but must be very secure of course). All real time online credit card payment processing gateways offering a "pre-authorisation" option will store the CVV until the merchant decides to go ahead with the transaction. PCI allowes them do this because it is before the card is charged.

 

I have a MOTO system (virtual terminal) from my bank that does not require the CVV. Most of my own clients have the same with the exception of two who have MOTO approved EFTPOS terminals and three have the new MOTO approved Smatphone merchant facility app. If your merchant facility is approved for card-not-present transactions (MOTO) then it will (should) process the charge without needing the CVV.

 

CVV does NOT guarantee anything. If a crim gets a credit card they can simply flip it over and quote the CVV anyway. Useless security measure in my opinion.

 

Then, offline, you (the merchant) are sent the credit card information to verify against the order, and enter into your system (POS etc.) in the normal "face to face" manner. Is that correct? If so, you are still in possession of the full credit card number (presumably including CVV) at some point. Even if it's in an email (encrypted, I hope),

 

No. Credit card details are not sent or emailed to me. This would be an insane risk. Once someone has paid I get an email alerting me. I log in to my e-Path admin area and print out the cc details. Their admin areas only works with SSL. Try to go to it via http and you get nothing. When I close my admin area all the cc details are errased from the e-Path sever. They don't permanently store any of that data.

 

So, I end up with a hard copy of the customers credit card details in exactly the same way as I would if I received a faxed order wth cc details, or if I wrote down the cc details from a phone order, received a postal mail order with cc details or if someone handed me their card.

 

When my bank suipplied me with my MOTO virtual terminal merchant facility they gave me a booklet on what I had to do to ensure cc details are safe and secure when in my posession in accordance with PCI regulations, which includes shredding them once I have charged the card. It is all about being PCI compliant offline too.

 

I would think that PCI-DSS would still apply, as far as security measures go. e-Path says they don't hold on to the number after sending it to you, so let's assume that's true (let's not discuss what happens if the email is lost or corrupted). Now, does this use of your in-store POS credit card system meet with the approval of your bank/merchant account? Because it's not truly face-to-face, they're likely to charge higher fees to offset the higher fraud rate of online transactions where you can't see the actual card.

 

Yes, PCI sure does apply both online and offline. You can't escape it but in all honesty it is not hard to be compliant. My e-Path gateway is already compliant (so I don't have any worry there) and I'm doing exactly what my bank has told me to be compliant when receving MOTO payments.

 

The risk is actually far reduced because I have prevented the credit card details from being anonymously processed online without me knowing. I have removed the credit card details from the internet as well and they don't even exist after I have processed the charge.

 

Prior to using e-Path I was falling victim to fraud about three to five times per month and I really HATED it that everything was being done on the internet and costing me a fortune. Since switching to e-Path I can see the fraud attempts clearly and I simply delete them. I have been fraud free for five years. I can not tell you how darn good that is.

 

I have had my merchant facility rates reduced twice now. I started on about 2% (I think from memory) but I'm down now to 1.1%. This is because I am NOT exposed to any risks of credit cards being transacted online. I am in control of what I charge and I have not recorded a single fraud on my account for five years.

 

There are just too many things here that raise red flags for me, and the breathless prose of the e-Path pages is heavy on hype and light on details. Also, who pays for this service? Are ads shown to your customer, or do the banks kick back something? They make a big point of saying how absolutely FREE FREE FREE this thing is, but someone has to pay for it somewhere...

 

It costs me $275.00 per year for e-Path. But then I can accept any number of credit card payment authorisations free. I can accept 50 in a year or 5,000 in a year and there is no cost to any of them. There are no transaction fees or charges because e-Path is not processing anything.

 

I guess one way to look at it is if you buy a fax machine, there is a cost, but then you can receive any number of orders with credit card payments through your fax machine totally free. You pay for your phone but when someone pays you by credit card over the phone there is no cost to that. You then charge the credit cards in to your merchant facility, either your ETPOS terminal or virtual terminal which I am paying for anyway.

 

I don't want to sound like I'm promoting them, but the truth is it is very secure and low cost way to do things as long as you don't mind manually entering cards to charge them. I still do very roughly about 20 to 30 transactions per week, not a lot so it doesn't worry me but I would not recommend e-Path if you are doing big numbers of transactions. It would just be too much.

 

I have found they have a demo oscommerce cart you can have a play with to see how it works: http://thefruitboxshop.com then go to the demo carts page.

 

On the negative side they are very tough on applications. You have to prove you have a merchant facility approved by the merchant facility provider for MOTO (card not present) transactions and you have to commit to shred all details once you charge the card. I guess this is not too bad considering my bank tells me exactly the same thing.

 

I don't know if this has answered your questions, but that's how it works for me anyway.

 

Cheers

Edited June 22, 2013 by HappyPappy

[MrPhil]

OK, so it still costs you an annual fee, which may be not too bad unless you've got a very low volume. The manual steps would probably be too much for a high volume online retailer. The credit card number is still handed to you, so presumably you have to jump through some hoops, but can avoid full PCI-DSS compliance since it's not online and handled by your site. The big thing is that your bank (merchant account) approves of it, so they can't accuse you of trying to pull a fast one on them. I suppose that if you already have a credit card system at your brick and mortar store, that this could be useful, especially if you use the offline processing as a chance to check out the order details for anything suspicious.

 

Is e-Path's service permitted in countries other than Australia? Is it used in the US at all? If you don't have a brick and mortar store (or any non-online presence such as mail/telephone/fax order), do banks permit you to get a POS system to handle (only) web orders? At what point (sales volume) does this become worthwhile, as opposed to using a third party payment system such as PayPal, or a full-blown payment gateway + merchant account? It's an interesting concept. Thanks for the details.

[Bob Terveuren]

Hi

I can only give you our data from 4 years ago when we ceased handling MOTO payments for a particular site - at that point we had a UK MOTO with Llyods (aka FirstData) and the monthly cost on that was UKP £25.00 minimum (So roughly AUD $40.00 p/m = $480 p/a) You paid the min fee regardless of sales and it would rise if your monthly sales exceeded the min amount they set but there was a sliding % scale so you could, most months, get a fee of around 1.5% o/a dependign on sales) - we were selling limited quantities of pricey items so actual sales were not huge though.

 

Online sales we handled via osCommerce with either bank transfer or 'ring up and pay by CC' where we'd take the 'customer not present' card details, enter them in the MOTO terminal and then zap the paper trail. We had no brick & mortar front end but did setup as a PLC/LLC/PTY LtD

 

So that setup would sit well with PCI/DSS as does this one. We had sites with cheaper items/higher turnover and they went via PayPal.

 

However manual card inputting is labour intensive and if you are trying to turnover gazzillion sales per month then it's not for you as the man hours to input payments would be exhausting (plus customers [like me] want to pay online NOW and know that the 99p item is en route asap)

 

The banks will hire you a MOTO terminal to use but you do have to pay up front and commit to a rental term (two years min we had) at that £25 a month so, unless you go through a limited company, you are personally liable for the min rental fee and they're not likely to hire you one if you are not a limited company so now factor in the fees for setting up the company.

 

This would possibly exclude small startups.

 

So I guess I am saying that you have to do the maths on each store that you have and then do that each month/quarter to see what the best option may be - for a startup PayPal type payments are maybe best (zero outlay but higher %) but once you are selling then look further afield - there's a heck of a lot competition out there now for payment processing and a lot of banks are starting to try and cut out the middle man and offer their own payments systems.

For the proven site there is the ability to show them your sales data and negotiate a decent % rate on sites but you also have to weigh up the costs involved if you start to go down the PCI/DSS compliance route and accept online payments directly on your site.

 

My 2p worth is that for most sites then some sort of PCI/DSS complaint (tokenised!) type payment system is ideal, low volume but high costs should look at ePath type setups. Everybody should also consider off-site payment handling (redirect) as that seriosly reduces any PCI/DSS impact

[e-Path]

Hello Mr Phil and Bob,

 

I see "HappyPappy" has gone in to quite a lot of detail about our service, which all reads correctly from what I can see.

 

I would like to answer some of your further comments/questions if I may.

 

Firstly, you both are spot on about the disadvantages of having to manually enter credit cards in to your merchant facility yourself. We do not recommend our service if you are doing reasonable numbers of transactions per day. Pay Pal or a third party automated online payment processing gateway system would be the best choice here.

 

But for those who don't mind manually charging credit cards in to their existing merchant facilities that they are already paying for anyway, our solution is a good one, espeicaly now since the previously inbuilt Oscommerce cc cpature option is not permitted.

 

Yes, we are available world-wide. We have more customers in the U.S, Canada and the UK than we do here in Australia. The recent update of our Oscommerce module, which I see Happy Pappy has posted about, is primarily to avoid having to hard code in different currencies.

 

Just like a fax machine, telephone or mail postal order, which are all approved methods to communicate an order with credit card details directly from cardholder to the business owner, e-Path knows no borders. We do the same thing as those methods, deliver the credit ard payment authorisation directly from the cardholder to the business owner for them to process the charge offline in to their existing merchant facilities.

 

However, we differ from those methods in that the fax machine, telephone and mail postal order methods are not PCI compliant, whereas with e-Path credit card data is handled via a PCI compliant system.

 

When receiving credit card details via fax machine, telephone, mail postal order, in person (cardholder hands you their card) and via e-Path, you are required to handle that data in a PCI compliant manner. I guess I'm not telling you anything new here but need to mention it all the same.

 

Best regards

 

Peter