As every organisation knows, there is a difference between taking an order and getting paid for that order. For companies selling goods or services online, the possibility of a customer saying they did not place an order – either because of a technology glitch or because of fraud – is a real problem. The reason is straightforward, but the solution is not: Proving a transaction took place when neither party was physically present can be a tough challenge. What can a company do to prove a customer placed an order if he or she says otherwise?
In the world of online shopping, all transactions have the status of 'cardholder not present'. Credit card companies and banks originally introduced the concept in response to demand for phone-based transactions, such as ticket bookings, where the cardholder was not on the merchant's premises and therefore could not sign a receipt for comparison with his or her card. Since this makes the transaction less secure, the customer only having to know the cardholder's name, and the expiry date and number of the card to make a charge to it, card companies refuse to take responsibility for fraudulent or disputed transactions. If a customer is adamant that he or she did not make the order and there is no evidence of delivery of goods to the customer, the bank or credit card company makes a 'chargeback' and obtains reimbursement from the merchant of anything paid to the merchant. Even worse, the bank or credit card company may also make an administrative charge to the merchant for the transaction.
|
While the credit card companies have now developed schemes for authenticating cardholders online that reduce the risk to merchants (see box, Credit where it’s due), these are still in the process of being rolled out and will not really tackle the problem until large numbers of customers have set up authentication information for their cards and merchants have adapted their servers to the systems. Until then, what can merchants do?
|
||
Ken Cowley, strategy director of payments technology group Etc, says that a company first needs to be clear about its procedures. "You need to be clear to the customer what constitutes a transaction. You need to say 'when you've placed an order, you'll receive an email that confirms the details'. And you need to have systems in place to notify you when emails can't be sent [so the customer can be contacted another way], for instance."
Analysts at IT market research company Aberdeen Group concur with Cowley. "Companies must think in terms of recording a 'contract' rather than the more popular, but very limited, concept of recording the 'data transaction'," says one Aberdeen analyst. It is not always enough to show that a customer placed an order: the customer can dispute terms of the agreement or pricing, so a merchant needs to show to everyone's satisfaction that the contract was entered into with everyone aware of the terms.
So the merchant should also record all aspects of the transaction and keep their details, but not just details of the sale. Web logs are a good starting point, but they only record what objects a web server sends to the customer's browser and what it receives in return. If a customer disputes that they saw a particular piece of information, it can be hard to show that the web pages they received contained the information, particularly if the pages have been redesigned since the transaction took place or are dynamic. Other products can monitor transactions and record other information that can be useful in such situations.
|
||
One such product is Web Capture from document and content processing specialist, Tower Technology. "Web Capture records everything a customer saw in the course of a transaction," explains Adrian Foots, European product marketing manager at Tower Technology. "It captures everything between web server and web browser from when you go to a specific page until you finish the transaction or the transaction is abandoned." The software captures all the HTML, graphics and other objects that are sent to the browser, records its responses and when the transaction is complete, packages the data, digitally signs it and stores it in a repository. If a customer disputes an element of a transaction, the merchant can look at the data served to the customer to see what he or she did and saw.
"The main problems that are likely to occur are in complex products like insurance policies, where there are lots of contingencies." says Steve Naylor, vice president of marketing for Europe, the Middle East and Africa at Tower Technology. "Did the customer say they had treatment for a condition in exactly the same way as they would do if they were doing it offline, for instance? The cost can be huge, because it affects pay outs and premiums. You need to be able to show that all the procedures have been followed."
|
||||||||||
Another product, Rainfinity's RainAssure, safeguards transactions in the event of infrastructure failures. At installation, the merchant simulates the various types of transactions possible on the site so that the system can understand what correct transactions should look like. John Kendall, business development director for Rainfinity in Europe, the Middle East and Africa, says the system then sits in front of the web server and monitors transactions as they come into the site and determines if there are mistakes in them by comparing them with the learned transactions. It can then correct and continue transactions if a web server fails, for example, or notify customers of failure and the status of the transaction. Since it is monitoring the transaction, it can pass it to another web server and continue it, rather than make the customer start the transaction again.
Despite the existence of products for transaction monitoring, research by Aspect Consulting suggests that even the bare minimum is being avoided in the majority of cases. While IT departments concentrate on trying to protect against the failure of their own systems, only 53% of those sampled monitor the end-to-end success or failure of a customer's online transaction. Most have no idea whether their customer's online purchase, information transfer, or trade was successful or not, leaving customers in the dark when a problem occurs. Of those that do attempt to determine transaction success, nearly 60% rely on the actual customer, rather than any management system, to alert them to a fault. And with 57% of them worried about fraud, many will be looking for more robust forms of reassurance soon.
|
|||||
|
|||