Encouraging customers to enter card details correctly

[siwalker]

Hi folks,

On our site we have a significant problem with customers being careless about entering card details. We process card transactions manually on our card terminal and see the following two problems frequently:

1. Transaction declined.
90% of the time this is because the customer enters the expiry date incorrectly.

2. Missing card details.
We can't process the transaction at all because the customer leaves the card type at the default 'Mastercard', enters a Switch/Maestro number, but then doesn't enter the required Issue Number or Valid From Date.

Has anyone had similar issues and implemented any changes to the checkout pages that have improved the situation?

Cheers,
simon

[fleetwood]

Yup, mis-entering the expiry is the number one reason for a decline.
I'd say we get more declines through this than through lack of funds in the customers account.
Its also frustrating that the credit card company response is usually a straight 'decline' rather than a more helpful "expiry date is incorrect'.

No matter what you try and do, people will always find a way of mis-interpreting a prompt.

At the checkout we have added a number of prompter notes - for the name it says "please enter your name EXACTLY as it appears on the credit card"

Why some people take this to mean "please enter your credit card number in the space labelled name" is beyond me, and creates a stupid security loophole, as the email confimation then shoots off addressed to Mr 1234 5678 9123 4560 !

It would be useful if some basic checks could be built into the software
- checksum check
- correct number of digits entered
- expiry date not left at the default (or at least request confirmation "are you sure your expiry date is 02/06"?)
- expiry is later than start (this is checked when you go the payments tab of the order, but is not checked at checkout time).

Are such checks difficult to build into the software?

Martin

I'm pretty sure there are some code tweaks that have been given on the boards for some of this, but it really is fundamental, and should be part of the inbuilt checks, along with postcode formatting, and capitalisation of address.

[Froogle]

Sign up for an account with Protx and have the transactions processed live while the customer is entering them.

This will save you time entering them, time chasing customers and will allow you to offer a faster dispatch service.

I can't understand why someone would want to manually enter them anyway. I couldn't think of anything worse !

If you worked out your man hours chasing customers, surely the 10p it costs for Protx would be money well spent ?

cheers

Yup, mis-entering the expiry is the number one reason for a decline.
I'd say we get more declines through this than through lack of funds in the customers account.
Its also frustrating that the credit card company response is usually a straight 'decline' rather than a more helpful "expiry date is incorrect'.

No matter what you try and do, people will always find a way of mis-interpreting a prompt.

At the checkout we have added a number of prompter notes - for the name it says "please enter your name EXACTLY as it appears on the credit card"

Why some people take this to mean "please enter your credit card number in the space labelled name" is beyond me, and creates a stupid security loophole, as the email confimation then shoots off addressed to Mr 1234 5678 9123 4560 !

It would be useful if some basic checks could be built into the software
- checksum check
- correct number of digits entered
- expiry date not left at the default (or at least request confirmation "are you sure your expiry date is 02/06"?)
- expiry is later than start (this is checked when you go the payments tab of the order, but is not checked at checkout time).

Are such checks difficult to build into the software?

Martin

I'm pretty sure there are some code tweaks that have been given on the boards for some of this, but it really is fundamental, and should be part of the inbuilt checks, along with postcode formatting, and capitalisation of address.

[oldhasbeen]

Oh yes - it's a pain in the proverbial and as Martin says, you'd think there would be some in built checks that actinic could easily integrate since each card type requires the same information each time.

We've found that these problems have escalated over the last couple of years primarily due to the popular of rollerballs/scroll mice - people click on a card type then scroll......off goes the menu...... click on an expiry date then scroll.....off goes the menu!

Despite posting warnings about this around the site, you know how customers don't like to read anything that might help them.

We've managed to contain the card type problem quite a bit by putting the most popularly used cards at the top of the drop down - then if they scroll, they quite often end up with the right card!! Before, it would always defalt to Mastercard at the top of the list and that's the least popular card our customers use. Still doesn't get round the people who insist on chosing the wrong card type, but has cut down errors substantially.

Also agree with Martin regarding the card issuers - not helpful at all - whether it's a wrong expiry date, issue number or other reason, you get the bog standard "not authorised". What I particularly hate is you have to ring up and there is never an option for what you need (i.e "not authorised") and if you get a referral you have to go through the whole rigmarole knowing that you need to speak to a human before they then pick up the phone!

The only *good* thing about all this is at least the customer has completed the sale and you can then contact them.

Another peeve is not having the customer's name on a single line (I've added this to the wishlist some time ago). We have a lot of Mrs Jane, Ms Susan, Mr Fred...... the irritating this is that actinic's own forms for submitting a wish list use the name on one line, but their shopping cart doesn't!

And again as martin says, no matter how iron clad you try to make prompts and no matter how low you think the bar can go, there'll always be somebody out there who manages to slip under it...... oh how we laugh

Oh the joy of it all.....

[fleetwood]

We process manually due to the need to adjust order totals prior to payment.
Our stock range is in excess of 10,000 and stock availability varies almost daily.
Its nigh on impossible to maintain 100% stock accuracy on the site.
Therefore we need the ability to adjust orders for sold out items prior to taking payment.
This also applies to postage, which sometimes needs fine tuning from the automated amount added.
If PROTX allowed payments to be adjusted & processed sometime after the order was placed (we need a 7-10 day window) then we would certainly look at going down this route, but at the moment, manual processing gives us the flexibility we need, albeit, at the cost of additional workload.

Martin

[oldhasbeen]

Froogle - this may be the ideal solution for you and for a lot of other businesses out there - doesn't necessarily provide the best solution for everybody. We've looked at taking live payments (or even pre-auth) many times over the years and ultimately it would cause us more hassle and more expense.

The pre-auth period isn't long enough, the additional costs involved far outweigh the small cost of us making the occasional telephone call or zipping off a standard email (as mentioned in previous post we've cut down on errors quite a bit and it's not like you're dealing with dozens a day - may one or two a week, but the peeve is that actinic could probably stop these with a few inbuilt checks). And ditto with martin, it doesn't offer us the flexibility for our method of business - we'd have to seriously kill off or totally curtail a lot of the services we offer our customers thus resulting in a LOT of lost revenue (and a lot of our competition using PSPs never even see any of this business because they can't offer it in the first place due the limitations of their payment options).

Horses for courses, but if you've got strict security procedures in place then PSP is not always the way to go.

[fleetwood]

Another peeve is not having the customer's name on a single line. We have a lot of Mrs Jane, Ms Susan, Mr Fred...... ...

Moving off topic for a mo, but staying on the subject of formatting names, I cannot understand why names within the software are stored as they are.
I know there is a search facility, but having the orders tab arranged by name, when the customer names are formatted 'Mr Joe Bloggs' is nuts!

A fundamental of database indexing is using exclusive keys to sort on.
You would 'usually' expect to be able to sort a database of customer names by surname+firstname to serve any useful searching purpose.
Sorting names by Mr and Mrs makes no sense at all!!

Just my little rant!

Have also raised this before, and whilst I realise its unlikely to change, I'd love to know the rationale behind this.

Martin

[siwalker]

Sign up for an account with Protx and have the transactions processed live while the customer is entering them.

Not an option. As with Martin, we have a huge stock range. We do frequent back-orders. Our policy is not to charge anything until we ship; and then to only charge for the items we've shipped. We also take many orders over the phone, frequently for items we don't have available on the site. Protx et al are completely out of the question at present.

Martin - you're right that whatever is on the site, people will mis-interpret. A couple of weeks ago I had a customer who had managed to convince herself that we don't ship to the UK simply due to her interpretation of our warning that we only ship to cardholder's address for orders from outside the UK. And she was a consultant neurologist!
It would be nice to have more control over how the checkout pages work without having to delve into Perl. Simply not having a default for card type would help, as would a 'check details and confirm' page. Some of our customers think the final order confirmed page is this, and assume the transaction is not complete until they press the DONE button on that page. They then complain they can't go back to that page and print the details. Or they don't press DONE, go back and revise the order, and we end up with two slightly different orders from the same person.
I have some sympathy with this as the final 'Next' button on checkout should really say 'Complete Order' or something similar.

It might be helpful if Actinic developers spent some time with customers who have various different ways of processing orders in order to help them understand the issues. As we're learning, what is obvious to us can be completely baffling to some of our customers.

Cheers,
simon

[wjcampbe]

Simon,

Not charging until you ship, and charging only for what you ship are standard legal requirements for all on-line shops. We manage to do this using Protx Pre-auth. The whole idea of Pre-auth, is that you must visit the interface and confirm the amount to be charged to the card with a repeat or no money is deducted from the card. Protx is not only NOT out of the question, but is actually tailored to meet your requirements.

[siwalker]

Moving off topic for a mo, but staying on the subject of formatting names, I cannot understand why names within the software are stored as they are.

Don't get me started on the database design. In a previous life I was designer/developer/DBA on MS SQL Server and it's close cousin, Sybase.
I use SQL Server to attach to Actinic tables so I can write reports in a language I understand - SQL. Access SQL is just plain 'orrible and I'm more used to the interfaces to MS SQL.
So what precisely was going on with the Actinic developers to lead them to to use the following to denote exactly the same field in different tables:
"Product reference"
"ProductReference"
"sProductRef"
The completely random use or non-use of capitalisation, spaces and type identifiers is common throughout the design. Drives me insane.
</rant>

[fleetwood]

Bill
I thought there was a strict time limit as to how long a pre-auth remains valid, after which, the customer has to be contacted to re-enter their details.
Whilst we try to turn in stock orders around within 48 hours, orders containing goods that we have on order with our suppliers take longer.

Back orders (which customers are free to cancel) can be 'parked' on the system for several weeks.
Can a pre-auth still be revived after say 3 weeks?

We only take payment when ready to ship, although I believe there is some vagueness as to the legality of taking payment before despatch. I don't believe it is a cast iron legal requirement. The major computer manufacturers (Dell, Mesh) take payment at time of order, and allow around 14 days for desptach.

Martin

[george]

Some very valid points on here, hope Mr D & Co manage to see them.

Its also handy to leave a `suspect` order `on hold` for a few days too.

[siwalker]

Not charging until you ship, and charging only for what you ship are standard legal requirements for all on-line shops.

Well yes, indeed, but I wasn't aware that Protx would support part-payments.
Will it support our offline business as well? The Protx site is as clear as mud.

Cheers,
simon

[wjcampbe]

I have asked Protx if there is a limit. All I know is, I can call up transactions from the beginning of the month now, and still have a repeat button available.

I do not think there is anything vague about the requirement to only deduct payment at time of shipping, but there is a lack of enforcement. You can expect large companies to skate on the edge of legality to maximise profit. I am sure they have very well paid lawyers who tell them exactly what they can get away with and who monitor HM Government initiatives quite closely.

I would expect any enforcement action to start with the small guy who cannot afford to defend the action, giving the authorities an easy, cheap, win and the 'fat cats' time to change their practices.

[wjcampbe]

Will it support our offline business as well

There is a terminal screen provision where you can enter offline transactions and process them, so - Yes!