Can you tell me does anyone know if payment on your own website is better than payment going through onto Protx payment pages?
...
We were going to go ahead and set up payment on our website and just wondered if was worth it. Has anyone had any opinions on the above??
When you take into account the big issue of trust, and how confident a user feels about submitting their all-important credit card details to a particular website/company, then the use of a more trusted third party website like PayPal or WorldPay or Protx is more important (I mention PayPal, WorldPay, and Protx in that order because I think the general public are more likely to have heard of PayPal first, WorldPay second, Protx third, and even if the general public haven't heard of either WorldPay or Protx yet, WorldPay sounds better and is more meaningful as a brand IMO, to get that trust started).
For most small businesses I think off-site credit card processing is the most appropriate solution. Perhaps it is because I'm too cautious and a bit too close to the subject matter working in web development and banking IT (in a previous life). All I can say is that I'm very careful about which sites I enter my credit card details on, even larger company sites. Do I enter them on a site owned by a small business who has spent a few hundred or perhaps a few thousand pounds on their website, possibly still running their website on shared hosting where anyone can open a hosting account and run server-side code, or do I enter my credit card details on a site like PayPal or WorldPay whose owners have invested millions in their security setup, who have security professionals working fulltime to keep their site safe from hackers, and QA/auditing/procedures in place similar to a strict banking environment?
A common misconception is that plonking a SSL certificate on to a site makes that site secure. SSL - secure sockets layer - merely means that the connection between the web browser and the website is encrpyted ('secure') and there is some level of vetting of the site owner depending on what level/cost of SSL certificate is used (from £8 per year less, almost zero, vetting, to several hundred pounds per year more vetting). The important thing is that it doesn't mean a site is secure (safe from hackers trying to inject code to syphon off credit card details on the processing page) nor does it mean that the site owner has to act responsibly with that data, what happens after your credit card details arrive at the site is anyone's guess.
Flipping this issue around 180 degrees, put yourself in the hacker's shoes, trying to hack into a website to obtain credit card details. Do you target the PayPals, WorldPays and the Protxs who have invested millions in security, or do you target the small business website who has decided to take onsite payments? Even if a website is not storing credit card details, which most shouldn't, a hacker could get in and place code on the processing page to tap the data off unobtrusively when the credit card details are received by the website.
This might sound like scaremongering, and I'm sorry if it does, but I like to err on the side of caution and I honestly believe that onsite processing is not the way to go for most small businesses, and I've only mentioned a few of the reasons why here. If you are a small business that is growing more into a medium size business then onsite processing might become more appropriate. That is if you are at the stage where sales are increasing, and you can afford to seriously invest in a more secure website setup, preferably avoiding standard shared hosting and moving onto a more dedicated server solution, and you are investing in every other part of your website to ensure it looks professional to instill trust in your visitors (if a site owner hasn't taken the time to do this then how can a site owner expect people to assume they have taken the time to do other more important things like make the site secure).
There can be synchronisation issues with offsite credit card processing but these are usually due to incorrectly implemented client sites. Correctly implemented sites, which make use of offsite payment processor callbacks, and change the order status accordingly, shouldn't have these issues, e.g. see
Store is completing order before payment and
Worldpay callback not working with osCommerce threads.