Blog homeI have a business problem with our tour operator reservation system and we are not quite sure what to do (yet). I had a chat with my colleague earlier (over a beer, after the TTI / Yahoo event) and decided that it may be interesting to throw the question out to you all to help advise us.
The key question comes down to what extent should we (as the system provider) police our customers?
Should we let them do what they like or should we, because our system is involved, limit their behaviour to behaviour we deem is suitable?
The three key dilemmas are:
- Sending email (including spam)
- Screen-scraping
- Credit card data (PCI Compliance) (The main one we need help with today)
Our system is web based – and centrally managed – hence I expect the answer is slightly different to what would happen if each customer had their own installation of the code on their own infrastructure. i.e. we sell a service – not software and it is our hardware that runs the service.
Sending email (including spam)
Due to the complexities of mass email sending we made an early decision not to directly support mass emailing in our software. Instead we support the export of the required data (that can be imported into mass-emailing software). However the system does send emails such as notifications to customers, staff and suppliers…. but these are low in volume.
I am confident we have called this one correctly – certainly no customer has suggested they are unhappy about the status. No policing required, thankfully.
Screen scraping
Our system does not undertake any screen scraping hence the ethics of screen scraping have not arisen. I know a few reservation system providers who do sell screen scraping technology to their tour operator clients – and their view is that if this is what their clients want then they must provide it.
Anyway, we have had the screen scraping debate earlier in the year – no need to go over that again!
Status: Not arisen for us…. but other system providers have decided not to police their customers with respect to screen scraping. I *think* I disagree with their approach – but I haven’t had to decide between losing a customer and implementing screen scraping functionality that I don’t agree with…. so perhaps it is easy for me to give an idealistic answer.
Credit card data (PCI compliance)
This old chestnut. Basically tour operator customers (in our situation) should be using a payment gateway in order to be PCI compliant. Payment gateways (WorldPay, CyberSource etc) handle all (or most) of the PCI compliant aspects for us – however it means that the credit card data is never in the hands of the tour operator (or us actually).
Not having the data means
- Can’t use for offline credit card processing
- Can’t be sent to 3rd parties (such as sub-suppliers including hotels) who want the customers’ credit card details in order to be handled via their own offline processing system
I know that actually you shouldn’t collect credit card data online for offline processing. It will be against PCI standards, against the Terms & Conditions of the credit card merchant account etc. Lots of reasons not to do it - so we haven’t got this in our system.
However some of our customers have now implemented this functionality (that they have developed independently of our system) which basically does exactly that. In addition, we get at least a request a month for this functionality – more than for nearly any other new development. People are genuinely surprised when I say that our system can’t do it and they shouldn’t do it….. this is losing us customers.
Personally I am not keen at all on developing something that by its very nature makes it impossible to be PCI compliant…. but some of our customers are in various developing countries where they suggest that PCI compliance is not an issue or they are prepared to take the risk….
Thats the dilemma – should we build some functionality (that increases our own data risk) and we know is wholly against any of the standards that are out there (but keep our customers happy) – or should we continue to lose potential customers but sleep happy that we are correct?
This is a first so – er – if you think this is interesting – please help me by commenting below and I may pose more questions to everyone in the future…….. even if you don’t have an answer – but you like the idea of us posing our dilemmas on this blog – just say that!
If you want to be notified next time something is published sign up for email alerts, subscribe to the RSS feed or say hello via Twitter @alexbainbridge. Thank you for reading!
Good question Alex. We faced the same issue when we developed the on-line payment component of the system. We have been developing e-commerce system for retail for about as long as we have for travel/tourism. Traditional e-commerce systems have been supporting off-line processing for a long time, primarily because in many markets (like the U.S. for example) you cannot charge a person’s credit card until the item has shipped which means that only a pre-authorization happens when the purchase is made. The challenge is that, if the item is no longer available, the order has to be changed, or a portion of the order is back-ordered, then the pre-authorization has to voided and a new pre-authorization for the new amount has to be made. This can only occur if the the merchant has the credit card information on file, or they have to call the customer and get the cc number over the phone. The standard practice is to store the card until the order has been fulfilled at which point the system destroys the card number.
In travel, it gets even more complicated. Hotels, airlines, etc. all require the credit card for reservation purposes but don’t charge the card until fulfillment, which means that the card information is potentially distributed across multiple suppliers. In the case of a single tour or activity provider however, it becomes a little bit simpler. In order to support a variety of payment methods, we allow the supplier to capture credit card for off-line processing but give them the ability to destroy the card details once the payment has been processed (similar to regular e-commerce). Since they are not using a payment gateway to handle their online payments at all, they are technically NOT PCI compliant and therefore cannot claim to be PCI compliant.
The reason why we added this feature was because we found some suppliers adding custom form fields to capture credit card information on their booking forms (a less than ideal workaround). Given the number of potential suppliers using the system, it is almost impossible to prevent them from using this workaround. By providing the off-line cc fields, we can properly encrypt the credit card data and properly secure the administration system.
As an added note, if a supplier is using an online payment gateway, they do not have the ability to use the off-line processing method because this not PCI compliant.
Alex,
You are asking two different questions. Your first is:
To what extent should we (as the system provider) police our customers?
The answer to this is not at all. You are providing a software, and a service and a platform, and whatever your customers do with that platform, what every workarounds they develop, as long as it does not compromise the security of your system should be of no concern to you.
However, when you ask:
Should we build some functionality (that increases our own data risk) and we know is wholly against any of the standards that are out there (but keep our customers happy) – or should we continue to lose potential customers but sleep happy that we are correct?
That’s a whole different question. You should not feel it necessary to build anything into your software that increases your risk or doesn’t let you sleep happy. That is a choice only you can make, and then your customers can choose their actions accordingly.
So build as you see fit, but don’t police.
Why not take a cue from the credit card companies. V/MC and AXP all request there merchants sign a contract stating they will comply with various rules about how they use / encrypt the data. But in my experience they very rarely take any steps to audit compliance and to enforce non-compliance, because they might lose profitable business. Ultimately they will track a merchant’s fraud rate and if it is getting out of hand get in touch, figure out what is going wrong and demand some changes.
So basically get your clients to sign something to say they won’t do it, and that they will indemnify you for any issues arising.
@ Stephen – yep – clients adding custom fields using our software already – hence why we are having to react to it! There was a time when I knew who our customers were and what they are doing – but now I have lost track due to volume….
@ Michael – would be fine if it weren’t on our hardware…. (for reasons I won’t spell out)
@ Ben….. don’t worry – I will just send everyone to this blog post if anyone asks!
Sounds like you already know what you want to do Alex. From the way you phrase the question my instinct is don’t build it, but be upfront to the point of bullish about why you haven’t.
Not really my area, but enjoyed the post and comments.
I’m a little late to the party on this one but wanted to say that I found the post really interesting. We currently experience a very similar problem (and actually exactly the same in terms of people wanting the credit card details).
Many websites (even some of the bigger boys – which I was shocked to find out) still fax through card details to people to process card payments. Very unsafe and difficult to track. We have people that want to do the same with our system. It’s a security risk and we simply cannot do this.
As part of the more general discussion of “if they use and pay for the system, should the be able to use it however they want” I really am undecided. It’s a difficult one.
In general terms I like the saying “listen to everyone, take advice from no-one”. I like to think I made that up, but I’m sure I really didn’t. But it rings true with taking feedback. As the people behind the software, I think we have to be the ones that collect all of the feedback and external factors to come to a decision. Otherwise we would end up with completely bloated software and ways of doing things that really make no sense to the big picture.