EKM Powershop goes crazy!

[Cathy]

I'm sure lots of people on here may be affected by this.

After 5pm today we received an email from EKM informing us that our payment method would no longer be supported from 1pm on Tuesday.

Our payment method is secure receipt of credit card details to be input into a PDQ machine. I would have thought this could be the option of choice for many sellers.

OK, I think, I have the weekend to look at the alternatives. Not impressed at the short notice but hey ho.

Segue to 7:11pm and I receive a further email to say that actually they've decided to remove the opiton at 7pm Friday!

Now, that is seriously taking the piss.

I'm sure I can't be the only website manager who was looking forward to a little Friday chillout time. But sadly this was not to be.

The situation escalated quite rapidly from there. No support telephone available, no live chat support available and then blocked out of our account totally til we can speak to them ie at 9:15am tomorrow (assuming we can get through, which seems highly unlikely)

Check out their forums. Like to post. No, not possible. Register, avtivate the email but still not allowed to post.

EKM are pretending that they only found out about PCI compliance this afternoon at 3:30pm. That is simply unbelievable.

Choose to use this platform for your ecommerce venture with extreme caution.

[cmcp]

I was under the impression EKM were ordered by VISA to implement these changes.

As you may be aware all online shops and ecommerce merchants need to be fully PCI compliant and we have recently discovered several merchants who have very weak passwords and also are keeping records of credit card data on their shop after processing it. This is illegal as per PCI compliance rules (https://www.pcisecuritystandards.org/) and Visa and Mastercard have begun to fine such companies.

As the data processor and ecommerce solution ekmPowershop needs to help all our customers be PCI compliant and so we are no longer allowing customers to store credit card data on ekmPowershop.

This means if you are using our ekmSecureCheckout to take orders and then manually process them using your own PDQ machine or Virtual Terminal you are breaking the PCI compliance rules and Visa and Mastercard have the power to fine you up to $100,000.

Because this has recently been brought to our attention we have had no choice but to enforce these changes as soon as possible therefore the following changes will occur…

* Immediately any customer who is using ekmSecureCheckout and another payment gateway service will have ekmSecureCheckout disabled. Customers can then continue to use your existing payment gateway.

* Customers who just have ekmSecureCheckout will have to switch to an alternative payment gateway before Tuesday at 1:00pm. As it will be disabled then. If you already have a merchant account you can quickly setup a online payment gateway with SagePay (if you use the promotional code "ekm33101" you will get 3 months free unlimited processing) for more details see www.sagepay.co.uk (http://www.sagepay.co.uk/).

If you do not have a merchant account one of the quickest way to get processing automatically online is to use PayPal Classic at www.paypal.co.uk/ekm (http://www.paypal.co.uk/ekm) or Google Checkout at https://checkout.google.com (https://checkout.google.com/) .

All old credit card information stored within ekmPowershop’s shop database will be deleted automatically after this date.

We are very sorry for any problems this may cause however this is out of our control and failure to comply will result in you getting very large fines and even being forced to cease trading by your credit card acquirer.

[AntonyChesworth]

This is a decision we have been forced to make because of various customers failure to comply with the PCI standards. Some of these customers (who cannot be named) are facing very large fines (£20,000+).

If you continue to not comply with PCI you too could face fines of anything between £10,000 up to £80,000. Basically putting most shops out of business.

So in an attempt to protect our shop owners from such fines we are removing the ability to do anything that could cause you to fail these guidelines and working on some other solutions to the problems.

I would advise all ecommerce merchants (regardless of platform) to check over the PCI documentation and check you are being secure because if your storing card details online you may have problems.

[Wayne-SAF]

This is a decision we have been forced to make because of various customers failure to comply with the PCI standards. Some of these customers (who cannot be named) are facing very large fines (£20,000+).

If you continue to not comply with PCI you too could face fines of anything between £10,000 up to £80,000. Basically putting most shops out of business.

So in an attempt to protect our shop owners from such fines we are removing the ability to do anything that could cause you to fail these guidelines and working on some other solutions to the problems.

I would advise all ecommerce merchants (regardless of platform) to check over the PCI documentation and check you are being secure because if your storing card details online you may have problems.Antony. You are one of the largest providers in the UK for ecommerce shops. Why has this not been picked up before?

I now have to post a message on my homepage explaining why customers cannot pay using their credit cards, and why this facilty has been disabled without notice.

I can see it now - "For the time being we can only accept Paypal and Google Checkout. We have had to temporary remove our credit card facility due to security issues with our shop provider. We were given one hours notice on a Friday afternoon before this option was removed."

"if you have suffered credit card fraud, it wasn't our fault. Honest! Please come back and shop again soon!!"

It doesn't look very good does it.

[Flying Hippy]

Hi there,

I was under the impression and still am that under the Data Protection Act. It is the people that sell the hosting that are liable for the data being stored on their server whand it is their responsabilty to have 2 servers with clients stored details a few miles apart.

If your using a payment gateway this data will be held by the 3rd party so you should not be in contact with this just the delivery address of the person.

[sockpuppet]

For those who are interested, there are plenty of alternatives to ekm that manage to offer this facility without any problems (some larger and some smaller than ekm) and are fully PCI compliant. If any of ekm's merchants are being hit with fines I would take a look at the ekm website where it rather confusingly states that they are PCI compliant when it turns out they are not and see if you have any legal recourse against them:

ekmpowershop.com/overview_features.asp
ekmpowershop.com/overview_features_pcidss.asp

I am sure that the pages will be available via Google cache / other source if (when) Anthony takes the false claims down.

Anthony seems to be trying to blame his merchants when I suspect that it is his system that is not PCI compliant. If it was just a few merchants then why take the facility off everyone?

[AntonyChesworth]

There is alot of confusion about PCI compliance as this thread demonstrates. Firstly it is upto the Merchant to be PCI compliant not any 3rd parties... for example if you choose to print out your username and password details it isnt HP for making the printer at fault but you as the merchant for doing it.

Likewise if you choose to upload to your hosting provider a text file full of card details its you at fault not your hosting provider.

In our case we have found a few merchants who have been storing card details after authorisation (which is disallowed) so we are working to ensure all our customers are compliant to avoid them getting fines.

If you have any questions or queries about this I would advise speaking to your bank and/or a PCI QAS registered company.

[IridiumCorp]

The June 1st deadline was to deal with changes that affected all Visa types. Basically unless your Merchant account is setup for recurring transactions any repeat billing may decline if you submit it as an ecommerce transaction without CV2.

The deadline was published last summer sometime. However in defense of EKM they would not be on the mailing list to receive such notifications as they would not be a card scheme member. So unless they stumbled upon the information they would have had no way of knowing about it. I am guessing last week they stumbled upon the information.

A couple further points here actually. First is that the deadline for ALL merchants to be PCI compliant is actually Oct 1 2009. However if you are a service provider, be it hosting, ecom payment etc if you find an operational hole that is not PCI compliant and merchants are exposed you must take immediate remedial action. Iridium in the past has had to shut down processing on a couple of Merchants, mostly because they were getting hit with large amounts of fraud, but still it was done in the end to protect them.

OP you have stated you were using card details that were captured online and emailed or downloaded that would then be keyed into physical terminal. This has long been against the rules, were talking something like 5 years.

I know it is being a bit harsh but it is actually the Merchant that must know the card industry rules and make sure you are following them. Most service providers will help and give guidance but it is ultimatly the merchant who must put in the work to learn them and apply approriate business pactices to ensure your safe.

Hope this helps.

[Flying Hippy]

One of the first thing any IT company or any person in a position that looks at peoples address should have Data Protection Training. But this is very rare.

3rd Party that look at the Data will have to been DPA trained and stick to the rules for all staff. i.e google or paypal same for payment gateways.

Lots of companies make mistakes when they hire external staff that have no training in DPA and the companies themselves do not Know they have to do this.

[awebapart.com]

Our payment method is secure receipt of credit card details to be input into a PDQ machine. I would have thought this could be the option of choice for many sellers.

OP you have stated you were using card details that were captured online and emailed or downloaded that would then be keyed into physical terminal. This has long been against the rules, were talking something like 5 years.

Very good point! Shop owners cannot simply take credit card details online and manually enter them into some other system designed for other usage, e.g. telephone or mail order cardholder not present (http://www.ukbusinessforums.co.uk/forums/showthread.php?p=784396).

[sockpuppet]

There is alot of confusion about PCI compliance as this thread demonstrates. Firstly it is upto the Merchant to be PCI compliant not any 3rd parties... for example if you choose to print out your username and password details it isnt HP for making the printer at fault but you as the merchant for doing it.

Likewise if you choose to upload to your hosting provider a text file full of card details its you at fault not your hosting provider.

In our case we have found a few merchants who have been storing card details after authorisation (which is disallowed) so we are working to ensure all our customers are compliant to avoid them getting fines.

If you have any questions or queries about this I would advise speaking to your bank and/or a PCI QAS registered company.

Anthony I think you missed the point I would only blame HP if they had sold me a "PCI DSS Compliant" printer (I know theres no such thing), you seem to be saying there is no such thing as a "PCI DSS Compliant" online store even though that is the claim you have on your site.

Also many other providers sell this exact thing, one example is volusion who have it stamped all over their site and they are a much larger provider than you.

I can understand why people are confused, you are not helping, what does it mean when you say ekmpowershop is "PCI DSS Compliant" can you explain? Do you understand PCI DSS Compliance? If so what does this claim mean?

[IridiumCorp]

There is alot of confusion about PCI compliance as this thread demonstrates.


Yeah there is a shocking amount of confusion. I wrote a blog recently on PCI confusion & myths. Seriously most level 3 & level 4 merchants can get it done in an afternoon. It is actually an exercise we recommend all merchants go through sooner rather than later.

Take 5 minutes and have a read : http://internetpaymentgateway.blogspot.com/

[Wayne-SAF]

I am a EKm user, up until the last couple of weeks on the whole a happy user, but after this weekend, far less of a happy user!!

This is a snippet of what I posted on EKM's own forum this morning.

EKM are are no where near blamless on this. It's their system that has lead to this, and what sits uncomfortable with me, is them blaming their customers, when they don't really make it clear enough, in my opinion, that cards data should not be sorted.

I for one deleted the card details to second the order is complete. It's always sat uneasy with me that EKM users have full access to card date on screen. Even bank staff don't have access to this information.

And it still worries me that this text "For security purposes recommend you delete the credit card number once processed." is displayed on the order page.

They are recommending its removed, when as we found out it is compulsery/the law to remove it. Surely this text should have been updated to "Please delete the customrs card information as soon as the order is processed. This is a requirement by law." or words to that effect, but it appears to me EKM are still not on top of things. It is not something that needs to be on a list to be done, it should have been done before the EKM checkout was reinstated on Saturday afternoon.

Although I hope not (for my sake if nothing else), I just think EKM could be leaving themseleves wide open on this, and by passing the buck to the customers who haven't been deleting card details, while still leaving misleading text on the site. I think if challenged, they could still find themselves in deep water over this issue, and that could be bad news for everyone who uses EKM.

So while people on the EKM forum are commenting on how well they handled this, I would agree the people on the end of the phone were excellent (I've already praised Ian who I dealt with in cutomer service), I don't think we should be patting EKM as a whole on the back yet, asthis whole issue should not have arisen, and I for one don't think its over yet.

[sockpuppet]

Wayne,

I just read the ekm forum (well some of them theres over 30 pages of the stuff) and I am not knocking ekm in general (but have you tried posting a link to this thread on the ekm "closed" forum I bet it will get deleted).

My point was just how unfair it seemed to sell someone a "PCI DSS Compliant" system and then blame the user when they get a massive fine for not being "PCI DSS Compliant", and then to top it off remove the functionality from all your users at such short notice - for what reason? is there a problem with the system or not?

As a merchant I would have thought a good way to protect myself against these fines was to go shopping for a "PCI DSS Compliant" piece of software (why doesnt the software simply delete the credit card details once the order has been processed?)

Are they taking any of the responsibility or just blaming users?

[openmind]

The very fact that the card data is stored by the software in the first place and that users even have the option to store card details is pretty worrying.

There is absolutely no reason whatsoever for any eCommerce software to store the raw card information with the exception of the cross reference returned by the gateway to enable repeat billing.

If a user wants to take off line credit card payments, although I could not think of a reason why, then just display a telephone number for people to call and make payment over the phone. The merchant can then use a virtual terminal to complete the transaction. Nothing needs to be stored then.

[DesignsOnline]

It just invites trouble storing this kind of data, and to think that there are still some "Ecommerce" websites out there that email the credit card data to the admin when orders are placed. Makes you cringe...

[Cathy]

What we do or don't do or did do on EKM Powershop is now moot as Anthony decided to cancel our account on Saturday afternoon, seemingly because we had posted complaints about EKM's actions on Friday night, on the internet.

We had asked for a 302 redirect to one of our other sites but instead our site was deleted.

For anyone thinking of using EKM Powershop I suggest you read their Terms and Conditions very closely and consider why they feel the need to say this about their own services (from their Terms and Conditions)

DISCLAIMER
Ekm Systems will not be responsible for any damages your business may suffer, Ekm Systems makes no warranties of any kind, expressed or implied for services we provide.
Ekm Systems disclaims any warrantor merchantability or fitness for a particular purpose. The includes loss of data resulting from delays, non-deliveries, wrong delivery, and any and all service interruptions caused by Ekm Systems and its employees.

You would also want to take especial note of this part too

Ekm Systems reserves the right to cancel the service at any time.

And unlike a non-hosted solution when they do that (as they have proved they will) you lose everything, your site, the work you have put into it, your hosting, potentially your domain.

I will point out that for us, the loss of our EKM shop is more of the nature of a minor inconvenience as it was a minor income stream for us but for many others it could be quite different.

[nigelburke]

I became an EKM customer some time ago, but never set up my shop as I've never had time to develop small retail sales.

My intention was to take card data through EKM, whizz it through my Streamline POS terminal and delete the data online. I now learn through this thread that that's been illegal for 5 years!

But if EKM sold me the service of taking card details through their system, what exactly did they think people were going to do with the card details? Just admire them? What were they selling?

I would like someone to unpick the references to 'storing' details. I see the difference in good faith between deleting details after processing and failing to do so. But detials are actually being stored online, are they not, before processing, and during processing. Has EKM's storage of the details ever been legal?

I have to say I liked the EKM people I dealt with, but this is a cluster*uck.

Nigel

[openmind]

Has EKM's storage of the details ever been legal?

Legal/illegal is a defined expression. Extremely foolish and breaching guidelines laid down by Visa and Mastercard would be better ;)

The hoops that gateways like SagePay et al have to go through to in order to process recurring transactions are numerous and exacting. Allowing customers to store card details in a databse, encrypted or not, and then rely on good faith that they delete them is naive and foolish.

Make your own mind up whose fault it is :)

[ICEY]

I'd like to see added security measures that means that different users have different levels of security. I have never felt comfortable with the fact that my web designer has access to my orders and that my staff processing orders have access to the design elements as they could accidently do untold damage. If nothing else these last few days have confirmed that a priority has to be ensuring that there are different user levels for the administration panel. This is something I have requested numerous times both by email, on the ekm forum (before I was banned this weekend) and by phone.

[IridiumCorp]

My intention was to take card data through EKM, whizz it through my Streamline POS terminal and delete the data online. I now learn through this thread that that's been illegal for 5 years!


Illegal is against the law. Card schemes are not the law although they sure try to be :). Its just an operational breach.

We come across this type of thing all the time actually. Companies who have been doing things in a certain way, or have older software systems often are in breach of PCI regulations and have no clue that they are.

It is what you do after you find out you are not operating properly that is important.

I would make sure you do the following if you already have not.

1. Contact your acquiring bank and inform them that you have just become aware that your current trading practices are not PCI compliant.
2. Ask them to issue you an Internet Merchant ID urgently.
3. Inform them that once it is issued you will complete a level 3 PCI compliance and submit as soon as is possible.
4. Make sure you ask them to add this information on the notes section of your account so there is a record of situation.

What this will do is until you can get yourself compliant is it will give you a bit of top cover in the event that your bank and or Card Scheme becomes aware of a breach. You can now fall back and say you are aware of the situation but are awaiting the bank to help you rectify it.

Hope this helps.

[nigelburke]

Thankyou, I am grateful for your contributions on this thread. I shall be studying the PCI briefing you linked to earlier, and in future seeking an online payment acceptance mechanism that shields me entirely from sensitive card data, sending me only that fact that a customer has paid, and the delivery and invoice address.

Next job is to cancel my EKM account....


Nigel

[openmind]

in future seeking an online payment acceptance mechanism that shields me entirely from sensitive card data, sending me only that fact that a customer has paid, and the delivery and invoice address.

You mean like this one (http://www.openmindcommerce.co.uk) ;)

[jolew]

Openmind, i've just noticed the shops on your page are the same as the fullphlat design ones? Are you one of the same? Cool designs btw, love the Full Phlat stuff...

[openmind]

Openmind, i've just noticed the shops on your page are the same as the fullphlat design ones? Are you one of the same? Cool designs btw, love the Full Phlat stuff...

Not quite. Fullphat and I work together on a lot of projects simply as they know the software backwards and produce excellent designs :)

We are two separate businesses though...

[openmind]

OK I'm going to put my neck on the line here and make the following offer to any EKM store owner.

If you are considering changing to an alternative software provider I am willing to offer a 20% discount on our license fees and design services plus import as much data as possible from your current store.

If anyone wishes to take up this offer I will need clear tangible evidence that you are an EKM store owner. For more information or to claim the discount voucher, please contact me through our support help desk (http://www.openmindcommerce.co.uk/support/index.php?_m=tickets&_a=submit)

I don't normally do this with competitors but on this occasion I personally feel the situation is quite shocking and a lot of people have been let down for a variety of reasons hence the offer of support...

[cmcp]

cha ching

[openmind]

cha ching
OK I'll be even more honest than I normally am :)

Yes the discount will generate business for ourselves but the difference here is that we have an ethos that we don't operate at the expense/actions of our customers, we operate at the expense of our own actions....

[cmcp]

I should've had a wee stick out tongue big grin smiley at the end of that btw :D :p

[awebapart.com]

in future seeking an online payment acceptance mechanism that shields me entirely from sensitive card data, sending me only that fact that a customer has paid, and the delivery and invoice address.
... as in any ecommerce solution that sends the user off-site to a trusted established payment processor who has invested six or several figure sums of money in getting their infrastructure secure, something I've been advocating for most small businesses for quite some time, e.g.

SSL on a website with an onsite payment facility does not mean a site or data is secure (http://www.ukbusinessforums.co.uk/forums/showthread.php?t=46188&page=3)

Payment onsite or offsite? (http://www.ukbusinessforums.co.uk/forums/showthread.php?p=539517)

Is onsite processing really better? (http://www.ukbusinessforums.co.uk/forums/showthread.php?p=278283)

How to establish trust in ecommerce (http://www.ukbusinessforums.co.uk/forums/showthread.php?p=483290)

IMO, onsite credit card processing in any shape or form for most small businesses, is a can of worms, one I would rather avoid, and one I recommend my clients to avoid.

[IridiumCorp]

Awebapart,


since they are more likely to make a payment on the paypal (or Worldpay) site which they know and trust, rather than on fred bloggs online shop website, which they do not know and do not trust, even if it has an SSL padlock


We see on average a 30% increase in closed sales when merchants move from a hosted payment system to in-line(ie on-site) processing. This is not opinion but hard data. The issue is not around security the issue is that interaction with a hosted payment form system is controlled by the consumers browser and is not a server to server call. As we all know there are loads of browser types and who knows how many setting variations.

The reasons people will see an increase in sales is are :

1. Warning message on jumping to a secure site with words to the effect of "You are about to jump to a secure page. All data will be encrypted......". For us in the industry we know what this a good thing. For little old ganny purchasing for the first time they run a mile.

2. Browser issues. Because the jump in and out to the payment system is controlled by the consumers browser local settings on their system may interfere with the jump.

3. Who am i paying syndrome - When the consumer looks up and sees a new URL they may ask "Well if things go wrong who am I actually paying here and who do I speak with if things do go wrong."

There are tonnes of other reasons but across the board when a merchant comes of a hosted solution to an in-line solution they complete more transactions.

[cmcp]

Am I right in saying Protx used to offer a seamless service which stayed on your static IP but pinged the Protx server behind the scenes?

Do Sagepay still offer this service?

[openmind]

Am I right in saying Protx used to offer a seamless service which stayed on your static IP but pinged the Protx server behind the scenes?

Do Sagepay still offer this service?
They offer an inline solution and an off site processing page. However most of our merchants prefer and use the inline solution for the exact reasons Sean has posted above...

[awebapart.com]

We see on average a 30% increase in closed sales when merchants move from a hosted payment system to in-line(ie on-site) processing. This is not opinion but hard data.
It is fine to talk about advantages but talking about advantages only without talking about disadvantages is probably what got some of these shop owners in the situation they are currently in, and IMO the potential disadvantages seriously outweigh the advantages for most small businesses considering onsite processing.

There may be the advantages of onsite processing for some sites, but it's rosy statements like these which make the £ signs in some shop owner's eyes light up, and sets them on the path of onsite processing without fully understanding the responsibilities, consequences, disadvantages, and cans of worms associated with that approach too. The worrying issues raised in this thread are just one example of the can of worms onsite processing introduces, becoming a target for hackers is another one, being the subject of a fraud enquiry is another (fraudsters get a user's card details by some means, not necessarily the shop owner's site, the card's bank asks the user which sites have you entered your card details in to, shop owners with offsite processing have little to worry about in this case), additional costs in 'securing' your site is another issue, etc

The issue is not around security the issue is that interaction with a hosted payment form system is controlled by the consumers browser and is not a server to server call.
The issue in this thread is about what happens to the credit card details after they are posted to a website owner's onsite credit card processing page, and these issues are the same whether the processing is done realtime or handled later, either way as a consumer you don't know happens after you submit, either way as a shop owner you are opening yourself up to potential problems (as well as advantages too). In this particular case, where details were stored for later manual entry into a terminal (which most likely wasn't allowed by the terminal provider anyway), it is not clear whether some server-to-server call was made from the website to the payment gateway to verify the card without performing a transaction at the time of customer submission (but that's not really the issue).

[IridiumCorp]

It is fine to talk about advantages but talking about advantages only without talking about disadvantages is probably what got some of these shop owners in the situation they are currently in.


You are of course absolutely right in that businesses are responsible for the business processes they use to trade.


The issue in this thread is about what happens to the credit card details after they are posted to a website owner's onsite credit card processing page, and these issues are the same whether the processing is done realtime or handled later, either way as a consumer you don't know happens after you submit. In this particular case, where details where stored for later manual entry into a terminal (which most likely wasn't allowed by the terminal provider anyway), it is not clear whether some server-to-server call was made from the website to the payment gateway to verify the card without performing a transaction at the time of customer submission.


I actually feel a bit sorry for EKM on this one. Before you guys flame please read on.

Up to a couple of years ago one of the UK acquiring banks was still marketing physical terminals to internet only merchants. Internet Merchants should never ONLY have a physical terminal. So companies like EKM build a payment capture system to work with these merchants. Acquiring bank stops doing this but merchants continue on not having a clue. That is of course until something like this happens then a bunch of people caught up in something they should not have been allowed to do in the first place.

In-Line processing is absolutely fine and safe. There are potential gotchas out there but equally there are gotchas for the hosted method, namely man in the middle attacks.

All business is about balancing risk against potential gain. Both methods have pros and cons and could be debated forever and a day.

I would say from experience it tends to be the bigger merchants that get it wrong more so than smaller merchants. Smaller merchants will tend to use something like UKBF when they have questions and more often than not get some pretty good advise. Bigger companies ask Tim in IT if their security is up to scratch. Tim may or may not know what he is doing and could quite easily expose his company to compromise.

I think it's time I write a blog on this topic :).

Awebapart - always good to debate these things. I will expect a scathing comment on my "Pros for in-line processing" blog when I get it done :D

[mattlast005]

Tiger Commerce sympathise with the stress EKM customers have recently suffered as a result of the recent headlines concerning their provider’s inability to offer PCI Compliance for manual credit card payments. As such, we at Tiger are willing to offer a free-license period to any converting EKM customers over the next 2 week period. All that we ask is you phone the main sales number on 0844 770 6877 and we will discuss what sort of promotional period we can extend to your business.

PLEASE NOTE: We don’t offer taking manual credit card payments as part of our service due to the complex compliance issues that surround this – we leave the PSP experts to this so we can concentrate on the ecommerce part.

[sockpuppet]

OK I'm going to put my neck on the line here and make the following offer to any EKM store owner.

If you are considering changing to an alternative software provider I am willing to offer a 20% discount on our license fees and design services plus import as much data as possible from your current store.

If anyone wishes to take up this offer I will need clear tangible evidence that you are an EKM store owner. For more information or to claim the discount voucher, please contact me through our support help desk

I don't normally do this with competitors but on this occasion I personally feel the situation is quite shocking and a lot of people have been let down for a variety of reasons hence the offer of support...

good luck to you...

on a seperate note I have a great business idea, a surefire winner, I am going to set up an ekm shop selling Kool-Aid to all the ekm forum members there sure is a high demand for it over there ;)

...no seriously if my supplier had screwed up as big as that and tried to blame me (the customer) for it the last thing they would be getting would be a pat on the back... although it looks like if anybody strays from the ekm line Anthony Chesworth pops up and deletes your store for you... how professional. Dont any of their store owners wonder how ekm didnt know what PCI compliance was until last Friday... being the UKs biggest and all...

Of course I am only joking...

[awebapart.com]

The reasons people will see an increase in sales is are :

1. Warning message on jumping to a secure site with words to the effect of "You are about to jump to a secure page. All data will be encrypted......". For us in the industry we know what this a good thing. For little old ganny purchasing for the first time they run a mile.
I really do not think you can use that as a valid reason for saying onsite processing is better than offsite processing, because on the increasingly rare occasion when a user's browser is configured for that to happen, similar warning messages will pop up for onsite processing too.

It took me a while to recreate this warning, and I eventually managed to do so by restoring IE6 SP3 to its default setting. The message did appear for offsite processing, but similar messages also appeared for onsite processing. In fact going to amazon and making an onsite processing purchase with IE6 SP3 in its default state, the warnings you get are:

1. Form post warnings when you add to basket:

When you send information to the Internet, it might be possible for others to see that information. Do you want to continue?

2. Security Alert

You are about to view pages over a secure connection

3. Important Message

Please enable Cookies in your Web Browser to Continue.

(Obviously you would get similar messages using a web shop that has off-site processing)

To give an example of what typically happens when a user is on a non-secure (http) website then goes off to a secure (https) website, just click on this following link from this UKBF non secure (http) page to this external secure (https) page: Google Adwords site (https://adwords.google.com/select/KeywordToolExternal)

[nigelburke]

I spoke to an EKM sales representative yesterday who suggested that, following more negotiations, EKM is likely to re-instate the services to its customers allowing them to take card details 'as long as they delete the data after processing.'

I am letting my EKM account run another month (as explained I don't have a working ekm shop) just to see what they say!

Thanks to all for suggestions on more hands-off and less liability-strewn payment systems.

[matt.chatterley]

I spoke to an EKM sales representative yesterday who suggested that, following more negotiations, EKM is likely to re-instate the services to its customers allowing them to take card details 'as long as they delete the data after processing.'

I am letting my EKM account run another month (as explained I don't have a working ekm shop) just to see what they say!

Thanks to all for suggestions on more hands-off and less liability-strewn payment systems.

Blimey, this seems a lot of hassle to have gone through, just to do an about face!

To be fair, NOT offering this method of payment is reasonable in my view - although I wouldn't say the same for the manner in which it was (allegedly) withdrawn.

Card details should not be stored. This has never (ever) been a good idea. Even if they are deleted after.

Reinstating would seem a bit daft - if it's because of perceived "damage" - that damage is already done.. apologise, alter procedures so it doesn't happen again, and move on!

[openmind]

I agree. They are still leaving merchants who "forget" to delete card details open to fines. Completely irresponsible imho...

[ICEY]

I am shocked that this method is being kept tbh, because it so obviously is flawed. I've completely removed it from the one shop it was on. But given anyone has access to that information be it web designer or office junior who may print off orders for dispatch, I think it is an incredibly flawed service.

I am not knocking EKM as a platform, as they have suited my purposes very well and I have invested very heavily in my stores and have yielded great results for me, however, there are a number of areas that I think could have potential security risk threats.

EKM have put in place more security measures but whilst they are certainly better than they were, I don't think they go far enough. As mentioned earlier there ought to be different levels of access, it bothers me greatly that web desigers through to temps have access to customer details. There are other security issues throughout the site however we live in fear of our sites being deleted with no notice and therefore right now that is all I will say but will write in due course to EKM explaining the other areas I think need looking at.

[spiritadventures]

Yeah there is a shocking amount of confusion. I wrote a blog recently on PCI confusion & myths. Seriously most level 3 & level 4 merchants can get it done in an afternoon. It is actually an exercise we recommend all merchants go through sooner rather than later.

Take 5 minutes and have a read : http://internetpaymentgateway.blogspot.com/


Hi - I have just read your blog and found it quite scary that you have posted that every merchant should be PCI compliant. I am in the Level 4 merchant category and use Worldpay for all my payments.
Looking at Worldpay, Visa and Mastercard advice, all of them suggest that any PCI compliance I need to take is recommended and not required:

http://www.mastercard.com/uk/merchant/en/security/what_can_do/SDP/merchant/levels.html

http://www.visaeurope.com/documents/ais/Merchant_levels_and_AIS_compliance_validation.pdf

https://crm.rbsworldpay.com/cgi-bin/rbsworldpay.cfg/php/enduser/std_adp.php?p_faqid=916&p_created=1236010237&p_sid=ctyqzwzj&p_accessibility=&p_redirect=&p_lva=774&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX 3Jvd19jbnQ9NSw1JnBfcHJvZHM9JnBfY2F0cz0mcF9wdj0mcF9 jdj0mcF9wYWdlPTEmcF9zZWFyY2hfdGV4dD1QQ0kgY29tcGxpY W5jZQ**&p_li=&p_topview=1

With respect, I ask you where you got your evidence that ALL merchants need to be validated.

I do not ask this to be critical or argumentative, I just want to get my facts clear.

Thank you!

[IridiumCorp]

I really do not think you can use that as a valid reason for saying onsite processing is better than offsite processing, because on the increasingly rare occasion when a user's browser is configured for that to happen, similar warning messages will pop up for onsite processing too.


Well actually it is a valid argument. The reason is that if you jump from domain 1 to domain 2 and at that point it either goes to an SSL page or from and SSL page to an unencrypted one you are more likely to generate the warning.

I understand your position. This is not a competition of who is right or who is wrong. We have had years of feedback from merchants who use hosted forms method asking why their consumers are getting these messages and even many developers asking why they are getting them and what they can do about it.

Your test was with one browser type on one operating system so in no way thorough enough to form a rebuttal position.

Anyways we are hijacking this thread. I am writing a blog on the subject now. I suggest once posted we use that to continue our debate.

[IridiumCorp]

With respect, I ask you where you got your evidence that ALL merchants need to be validated.


I refer you to Myth 2 & 7 in the below document.

https://www.pcisecuritystandards.org/pdfs/pciscc_ten_common_myths.pdf

The confusion is that instructions to Card Scheme Members like ourselves are often not clear and contradictory. However from experience dealing with Merchants who have had a compromise it become very clear after a breach.

Basically the following statement is what to work to :

"Level 4 Merchants do not have to complete an annual PCI Self Assessment questionnaire however they must be operating according to PCI compliance."

Merchants tend to cling to notion that being a level 4 merchant means PCI does not apply to them or something they do not have to worry about. This is 100% incorrect.

If a level 4 merchant suffers a compromise and they are found to be not operating to the rules they will be sanctioned, fined, turned off etc.

If a level 4 merchant suffers a compromise and they have done their yearly questionnaire then post breach forensic analysis will identify how it happened and the Merchant will be given a remedial time to put things right.

Besides working through the questionnaire is actually a very good business procedure exercise.


I do not ask this to be critical or argumentative, I just want to get my facts clear.


No problem :mad:. The EKM situation is actually evidence that each merchant needs to be PCI compliant. If what people said about some of their Merchants getting fined is true then there you have it. I bet most of them were level 4 merchants. And if they had done the questionnaire they would have know very quickly that they were not operating in a compliant way.

[First in Retail]

I think the whole situation is another example of the card industry getting it wrong again, chip and pin was/is a dogs dinner, so is this, the whole thing will not stop fraud its just a cash machine for thoes in the know.

One of my clients is installing 150 PDQ machines to save about 35K a year in PCIDSS costs.

We use offline payments on some sites and our fraud level / chargbacks are approx £100 a month (2m turnover) thats because every order is checked, goods over a certain amount are vetted and so on, what will happen is that the client will stop doing there checks because liability will shift to the banks.

[openmind]

Sorry I disagree. Even with 3D secure and AVS checks, the retailers should still be doing their normal checks anyway and not relying on the gateway/banks to dig them out of trouble if it goes wrong.

PCI and 3D secure is designed to protect the consumer first and foremost but also to protect the merchant. If the merchant wants to carry out insecure practices then that's up to them but they cannot have it both ways...

[First in Retail]

PCI and 3D secure is designed to protect the consumer first and foremost but also to protect the merchant. If the merchant wants to carry out insecure practices then that's up to them but they cannot have it both ways...

Rubbish, all this is designed to protect the banks, don't for one second think all this is for the consumer, or the merchant. Credit card fraud is inevitable, its about the banks minimising the risk to themselves whilst passing on the costs to retailers.

What I am saying is that if the banks and aquirers are insisting on these rules and the liability is there's if you use there systems, then why should the retailer actually do MORE, actually the banks can't have it both ways.

We do what we can to protect Mr Smiths card details, if we are using the banks systems, and some of them are less secure than email, and paying for the service, then its up to the banks.

Spin it on its head and its a nighmare, I know exactly were our cards details go, I know who can see them and who has access, by name, i can touch the people involved, using a gateway, I have NO IDEA who is looking or has access to the systems involved, in theory I am allowing my customers access to systems I have no control or knowledge about !

[openmind]

I'm not going to apologise this time, it's not rubbish in the slightest and please don't for a second disregard my comment with one word, it hardly promotes a healthy debate...

Moving on...

As a merchant who is in a business that attracts fraud like bees to honey, without 3D secure I lose an immense amount of protection from MY bank.

For example, a server order comes in and I carry out all my pre-auth checks, which are numerous I might add, without 3D secure if I authorise that order and it later turns out to be fraud then I have the money dragged back off me.

However, if I carry out my pre-auth checks AND the order has been 3D secured, the liability will shift back to the bank and I am covered.

How on earth is that NOT a benefit to me as a merchant??

You said you can "touch" the people who see your card details. That's nice but what about the day little Johnny decides to download all your card details to a USB stick and go for an early lunch, in Australia...

If my staff cannot see the card details, I don't have this problem....

[awebapart.com]

Well actually it is a valid argument. The reason is that if you jump from domain 1 to domain 2 and at that point it either goes to an SSL page or from and SSL page to an unencrypted one you are more likely to generate the warning.
People typically go from non SSL pages to SSL pages even when they remain onsite for onsite card processing, as my Amazon example (http://www.ukbusinessforums.co.uk/forums/showthread.php?p=889871) demonstrated.

Your test was with one browser type on one operating system so in no way thorough enough to form a rebuttal position.
Please do not accuse me of not being thorough enough when all you have done yourself is provide a sweeping statement without any current backup evidence.

I provided an example (http://www.ukbusinessforums.co.uk/forums/showthread.php?p=889871) with just one old (but still in use) browser because I was finding it difficult to recreate the situation in your sweeping statement with other more modern browsers. I tested an onsite processing situation and an offsite processing situation and came up with similar warnings. Not only did I provide a tested example with details of how other people could recreate the test, but I also provided a separate link so that people here could quickly test the situation themselves (jumping from a non SSL page to an SSL page) on their own browsers and judge for themselves whether any warnings come up.

Whilst this is not a fully thorough rebuttal, it is far more thorough than your original sweeping statement with no current evidence, a sweeping statement which can be inaccurate, misleading, and possibly outdated. If you want to get thorough and back up your statement, please provide an example popular browser setup where warning messages appear when going from a non-SSL website to an offsite SSL website, but do not appear when going from a non-SSL website to an SSL page on that same website. If you can provide such an example, then at least we are both being thorough enough to make this issue worth discussing further.

[First in Retail]

Sorry you clearly misunderstood the point. Probably me not typing in the words in the order they are in my head....

If you are 100% watertight by implementing the banks systems including 3d secure, then why do the other checks ? the retailer EXTRA checks are only being done because of the liability aspect. Protect yourself from fraud unless the bank are doing it for you idea.

If you use the banks systems and liability is shifted to them why would most retailers do anything else ? I am not saying i agree with the idea, just that the banks can't have it both ways.

Of course this does benefit the merchant, in the fact that chargebacks are minimised, but thats not what you said, you said PCI and 3D secure are in place to protect the consumer, and merchant, yes they are and it does help the merchant (another debate on the hoops a consumer has to go through if they have not signed up to 3d, verified by, and the potential to lose that customer at the checkout) but these systems and regulations are in place to protect the bank foremost, consumer then merchant.

As for Johnny, security is what it is, All I can do is put best practice in place, of course the gateways should have sufficent security and I have no doubt that there systems are very good indeed, the point was a bit of a silly one to be honest, it was more of a "do we really know " what goes on type comment.

The whole fruad and who pays for it debate will go on until the banks take responsibility for it, I doubt in my lifetime the issue will ever be resolved....

[openmind]

I clearly did not misunderstand the point.

If you are 100% watertight by implementing the banks systems including 3d secure, then why do the other checks ? the retailer EXTRA checks are only being done because of the liability aspect. Protect yourself from fraud unless the bank are doing it for you idea.
If a merchant is relying solely on the bank to do their checks then they are placing too much emphasis on this. They should be doing the same checks with or without the banks input.

The fact that they can see if a transaction has been approved or not is the cherry on the top to give them extra security but should not be relied on to provide all the checks required.

Example, I had a customer place an order for hosting, passed CV2 and 3D no problem but our internal system flagged the order as he was on holiday at the time and his IP address was some 2,000 miles from the card address. Why he was placing orders for hosting whilst on holiday is beyond me but I digress. If our system hadn't carroed out the additional check then the account would have been setup immeadiatly.

So we still apply the same checks to 3D secured orders as we always have in the past, the difference is now if we go ahead and authorise that order then the bank will take the hit, not us.

Yes PCI, 3D et al are primarily in place to protect the banks first then the consumer and then the merchant. The problem with this being? The bank is a business just like I am and they are protecting their investment.

The consumer is the shopper and has a right to be protected against fraud, just like my clients do.

The merchant also has a right to get as much information as they can about the shopper without compromising security so they can be satisfied that the order is genuine.

Finally, merchants that are losing sales at the checkout stage because of 3D need to look at how the are handling 3D secure transactions. We haven't seen a drop in sales, quite the opposite in fact, and the fact that we can say to our shoppers we are PCI certified and we protect your information yadda, yadda, enhances our proposition instead of damaging it.

In the case of offline payments, that makes the shopper feel a damn site more secure than telling them "We will process your card details manually on our machione in the office so first it's got to get to us (storage, transfer security issues) and then Johnny is going to plug them into the machine (staff security)"

I know which method I would prefer as a shopper...

[First in Retail]

This has rattled on a bit and is now completly off topic, so appologies to the original OP.


Example, I had a customer place an order for hosting, passed CV2 and 3D no problem but our internal system flagged the order as he was on holiday at the time and his IP address was some 2,000 miles from the card address. Why he was placing orders for hosting whilst on holiday is beyond me but I digress. If our system hadn't carroed out the additional check then the account would have been setup immeadiatly.

Clearly your security is beyond that of a normal online trader, and so much better than the banks, you telling me your checking IP addresses based on location, so a card holders address must match an IP address location/country?

If he passed the banks checks and liability was now with them, whats the problem, your NEVER going to lose out ? clearly the banks could not care less where he was ordering from, do you get a big pat on the back and a compensation from the banks for catching the ones they miss ????

If I was that customer I would have cancelled the order, what has it got to do with you guys were I place the order from, I have followed the rules as a consumer and I still get my order bounced, surley that makes no sence ?

Sheeesh !

[openmind]

Right, first up I would appreciate if you didn't respond to my posts in such a condescending manner. I'm not some twelve year old who doesn't know what they are doing...
Clearly your security is beyond that of a normal online trader,
Yes because it needs to be...
and so much better than the banks,Not sure where I said that but carry on...
you telling me your checking IP addresses based on location, so a card holders address must match an IP address location/country?If it doesn't match then it will be flagged for further investigation yes. Simply because scammers will use billing details for say the UK but they are actually in Nigeria (purely as an example) placing the order. We also block orders completely from known high risk IP blocks...

A retailer would also be checking if the delivery address matches the card holder address and if they don't, they would normally find out why...

If he passed the banks checks and liability was now with them, whats the problem, your NEVER going to lose out ? clearly the banks could not care less where he was ordering from, do you get a big pat on the back and a compensation from the banks for catching the ones they miss ????
Sarcasm will get you everywhere in life. I couldn't give two hoots if the bank thinks my extra checks are required. I know that by operating in this way I have a zero chargeback record. The shopper could know the 3D authentication password or even knowingly use the card for fraudulent orders.

If I was that customer I would have cancelled the order, what has it got to do with you guys were I place the order from, I have followed the rules as a consumer and I still get my order bounced, surley that makes no sence ?

Sheeesh !See above about my point on orders from different countries to the billing address. As it happened he was pleasantly surprised when he rang and we told him the order had been flagged and the reason why. I guess he was impressed with the fact that we actually care...

We are going to have to beg to differ as clearly we are not going to agree...

[stugster]

you telling me your checking IP addresses based on location, so a card holders address must match an IP address location/country?

We do this too.

[spiritadventures]

We do this too.

I do too - yes there are certain compensations in place if an order turns out to be fraudulant and you have 3D secure for example. But why put yourself through the unnecessary worry and paperwork when a simple check to start with could have told you that the order was from Nigeria, say. As the docs all say, prevention is better than a cure!:p

[IridiumCorp]

Originally Posted by First in Retail http://www.ukbusinessforums.co.uk/forums/images/buttons/viewpost.gif (http://www.ukbusinessforums.co.uk/forums/showthread.php?p=891640#post891640)
you telling me your checking IP addresses based on location, so a card holders address must match an IP address location/country


We offer ths as a service to our merchants. It is really pretty standard.

[amv1981]

This is because their previous method was illegal!

[IridiumCorp]

Whilst this is not a fully thorough rebuttal, it is far more thorough than your original sweeping statement with no current evidence, a sweeping statement which can be inaccurate, misleading, and possibly outdated. If you want to get thorough and back up your statement, please provide an example popular browser setup where warning messages appear when going from a non-SSL website to an offsite SSL website, but do not appear when going from a non-SSL website to an SSL page on that same website. If you can provide such an example, then at least we are both being thorough enough to make this issue worth discussing further.

Awebapart,

Testing one browser over another means nothing. Its the browsers security settings that count. An Exploror 6 will behave differently from a home environment to a office network environment. The evidence I am basing my position comes from countless phone calls from merchants on the issue, development meetings trying to work out ways to reduce the impact of the issue and then transactional data from when a merchant switches from one method to another.

Okay lets say for the sake of argument that browsers operate exactly the same regardless of the method used. Then we should be hearing reports from our lin-line merchants that they to are seeing this behaviour. We are not. This would tend to lead one to hypothosize that another factor was at play. In many of your previous posts you have argued that the physchology of having a bank or institutional type name to instill trust with the consumer to make the purchase and I think we can agree that trust is pretty important. So if both browsers throw up the same messages regardless of the processing method used then its not the message itself but WHEN the message is displayed in the purchase process. What would you say the physological impact would be on a consumer if the message is displayed at the start of the checkout process rather than on the payment page?

We are obviously going to remain polar oposites on this issue. There are pros and cons to each method but at the end of the day the Merchant should be using the method they can support with business practices. We have seen time and time again increased transactional throughput when merchants go to the in-line method. There is no one specific reason but a combination of many factors.

[awebapart.com]

We are obviously going to remain polar oposites on this issue.
Indeed. On one side there is me providing example, testing and evidence which people here can reproduce themselves, and on the other side there is you just asking people to believe what you say without backing it up, so yes we are obviously going to remain polar opposites on this issue (http://www.ukbusinessforums.co.uk/forums/showthread.php?p=889871).

[IridiumCorp]

Indeed. On one side there is me providing example, testing and evidence which people here can reproduce themselves, and on the other side there is you just asking people to believe what you say without backing it up, so yes we are obviously going to remain polar opposites on this issue (http://www.ukbusinessforums.co.uk/forums/showthread.php?p=889871).

Awebapart,

I took this up again with our Dev guys and we ran some tests with various browsers. The warnings are indeed identical regardless of the method so you are correct on that element of the argument.

However there were differences that relate to when the messages are shown.

The common things we here about using a hosted forms method is consumers being shown a warning at the point when they jump to the secure processor and orders being completed on the processor end but not showing in the shopping cart, ie consumers bailing after the Tx but before the post back process. So sale is complete but merchant has to reconcile payments to their website uncompleted orders.

With in line processing the message is shown (at least on the carts we played around with ) at the beginning of the checkout process and remains secure after the transaction has completed and the payment logged on the merchants server.

Another thing we tried was going from one secure domain to a different secure domain and no warning was generated.

So although I was wrong on the actual technical cause for the variance we see from hosted to in-line the psychological effect of having a warning message appear before the page you enter your credit cards details will stop some people some people from completing a transaction. And conversely once the payment is complete getting the sale information back to the merchants website as they get another warning then.

All I can say is the logic above is sound. I can not for obvious reasons release our data that backs these trends. I stand by my initial broad and sweeping statement that merchant who use a hosted pages method that switch to a in line will see and increase in sales. This broad sweeping statement also applies to merchant who go from only offering Paypal to offering both paypal and a normal merchant account.

[awebapart.com]

I took this up again with our Dev guys and we ran some tests with various browsers. The warnings are indeed identical regardless of the method so you are correct on that element of the argument.
IridiumCorp, thanks for looking into this more closely. I know it can take time to do this as it can involve resetting different browsers to their default states, so I appreciate your effort. Since performing my test on IE6, I have also tested this on other browsers too (IE7, FF2, FF3) and the results are similar, i.e. the warning messages that appear when going from http to https pages do so regardless of whether it is on the same web site or a different website, so this alone can not be used as an argument for on-site credit card processing or as an argument against off-site credit card processing.

It was really just this particular issue (http://www.ukbusinessforums.co.uk/forums/showthread.php?p=889871), that I was taking issue with, and I'm glad we are now in agreement on this.