Online Payment Form Patterns

When designing an e-commerce site, it’s hard to avoid the payment form. For an industry barely a decade old, the payment page has a powerful mystique – associated as it is with high technology like i-frames, fraud, mysterious loss of life savings, and alien invasion.

I was thinking about this last week after reviewing some work that the mighty Ash Gupta, interaction designer of repute, had done for us last month. His design eschewed the traditional card-type drop down that seemingly all credit card forms have. He mentioned in the annotations that the system would simply detect the card type from the Bank Identification Number (BIN) – the first four digits of the number on the card. I thought this was an interesting innovation. One less form element to bother with and one less thing to go wrong – particularly as I know that you can quite happily choose a Visa credit card from the drop down on most forms only to supply the number of your Visa debit card instead. The payment fails on the round trip to the server, of course.

So I decided to see what other designers of The Union (as the newly-formed LBi International has chosen to describe itself recently) thought about the matter.

I was a little surprised by the range of replies that came back, as well as the number of them – around twenty-five in all. Nobody seemed to have considered the issue before (well, I admit it’s boring), nor did they know whether the BIN could actually be used in this way. After wading through a variety of reasons not to do it (ranging from clearly cooked-up server load issues through to dubious anti-fraud “best practise”), I agreed with the general consensus that not having a drop down for card type might cause marginally more friction for the user if they did not also see the customary array of icons indicating accepted card types before typing in their 16-digit number. Both these features are given in the only real “design pattern” I found for this.

Another thing that came out of the discussion was that the name on the card may well not be needed for verification. So, that too is a potentially extraneous bit of flotsam that could be disposed of if designers didn’t think that punters somehow expected it for (it was assumed) a warm fuzzy feeling of “protection.” In keeping with the rampantly ill-informed proceedings, somebody also rather authoritatively said that “many businesses” required the name on the card to match that of the customer placing the order. I think that may be true of some airlines wishing to conform to US anti-Muslim terrorism measures, but I’m pretty sure it’s not of most other businesses since that would preclude the use of company, spouse or other cards being used. As a final twist to that latter condition, I wondered whether asking for the name on the card was a breach of the Data Protection Act if the card holder was different from the person placing the order. The DPA stipulates that personal data must only be collected if the data controller plans to actually use it.

All this was rather revealing I thought, particularly when one reflects on the supposed use of “design patterns.” I’ve been revving up for a blog post on the subject of patterns for while since I’m rather unsure what to think of them. The debate about the credit card form seems to show that patterns may simply be best thought of as “common examples” rather than the pompous prescriptions of those who pretend to “discover” them. But I’m not sure yet. Instead I’m filing this episode under interesting material for when I finally nail why it is I think patterns are snakeoil.