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.

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 or Google Checkout at 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.

 

[PayVector]

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.

 

[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?

 

[PayVector]

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?

 

[Optegris]

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

 

[Optegris]

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.

 

[PayVector]

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

 

[Optegris]

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

 

[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...

 

[Optegris]

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...

 

[Optegris]

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...

 

[cmcp]

cha ching

 

[Optegris]

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

 

[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

Payment onsite or offsite?

Is onsite processing really better?

How to establish trust in ecommerce

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.

 

[PayVector]

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?

 

[Optegris]

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).

 

[PayVector]

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

 

[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

 

[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!