A Serious Post About Payment

When I started this blog my very good friend and ex colleague Abi said to me “It’s good but…have you plans to make it less…funny?”…I took that as a compliment at the time.

In theory this blog WAS supposed to be serious from the start but for some reason it’s veered towards the funny/critical (how did that happen? Not like me at ALL!).  Anyway, near year new me and all that.  Cue “A Serious Post About Payment”.

When designing a checkout flow payment page is a funny beast – sometimes you can feel like you’re leading your customer through a lovely pleasant fairy-tale of ‘just browsing’ - a heady, lighthearted experience - and then they hit the payment page and all of a sudden they’re in the wicked witches clutches devoid of power , confused and disappointed. It’s a let-down which results in one of a few outcomes – you panic and run away (drop out), carry on through the pain and end up feeling slightly scarred by the experience (convert with difficulty) or you attempt to get through and end up getting turned to stone by some repeating error message or problem you just can’t get past (drop out without wanting to). Enough with the analogies – often people get checkout design wrong – and the payment page can be the epitome of the big bad wolf in a bad checkout (ENOUGH!)

Ok so in order to design a payment page (I'm calling it a page but it could easily be a form-  one page checkouts are more and more common now) where do you start?

Let's take that form as an example. Entering card details.

For me it’s first and foremost about the customer – the context of what you’re doing. What’s the driver here? Well in most cases the customer just wants to pay, - they’ll be thinking about their order and the items they’re buying and they’ll be focused on getting to the end. Some will be at work and trying to enter their card details quickly to get out of the boss’ siteline, others will be at home with phones ringing, doorbells going and kids interrupting. Some customers will want to feel reassured throughout that they’re in a secure environment, others won’t be so concerned. Woah that’s a lot of drivers. If you look at all this in isolation it looks scary-  and when things look scary the way through the wicked witches woods’ is to go SIMPLE, CLEAN and ORGANISED.

OK so the first thing I do when faced with this challenge is write down everything that needs to be on the page (or if you’re that type enter everything which could be on the page and then cross a load of stuff out). For payment forms this is usually universally the following:

Card type

Cardholder name

Card number

Expiry date

Start date

CVV/CV2/Security number

Issue Number

Security logos

Payment type logos

After crossing out the things you don’t need – or adding additional things you need for your site (card nickname if you like, a save card for later checkbox if you offer it). Then the next task is to order them into some kind of hierarchy.  I’d favour something like:

I always like to see the card number first – purely anecdotal evidence suggests to me that when entering a card customers find that they stumble here as they always want to enter their card number first so they end up with an error. I think it’s because you don’t know your long 16 digit number off by heart so you’re more likely to want to just get it onto the page before anything else. I could be wrong. So I’d end up with something like this:

Hmm but wait – something is wrong here. The types of information you’re asking a customer to enter are going to change depending on what that piece of information is.  We also have to think about our interface requirements with a PSP – they need certain information in a certain structure. So let’s restrict the format the customer can enter that information in. Let’s also make sure it’s easy for the customer to see what that format is. For a start date or expiry date we know the boundaries of what the customer will enter for example the customer sees MM/YY on their card, we should attempt to replicate that here.

Ok so next thing that’s bothering me is that the two fields at the bottom represent very shirt pieces of information. Issue number is usually a single or double digit, and the security code is 3 digits (4 for AMEX), so let’s create that expectation for the user and shorten up those fields.

But wait – Issue number and start date? I don’t have those on my cards? That’s because these are only requirements for certain types of cards (Maestro), so let’s not show them when the customer doesn’t need them.  To do this we need to know what type or card the customer is entering up front, You can do this in a number of ways, either with radio buttons and images of card types, with a dropdown – ideally I’d like it to be transparent to the user (they don’t care what the card type is) so it could detect from the number they enter into the field. Let’s for now make it a dropdown. And let’s make it clear when the information is needed.

For a non-Maestro customer here’s what I have now.

I think I could improve on the descriptive-ness of my field labels. They’re a bit techie. Let’s make sure the customer knows exactly what they should enter into the field.

Some fields may need more explanation so I’ll add some tooltips

That enter text’ is annoying isn’t it? Let’s make it useful. 

I’m quite happy with that. As discussed above customers can find security a problem when paying online so a bit of reassurance of trust logos, card schemes etc. won’t go amiss here and depending on where you add your payment types accepted (basket page is useful)  - it’s worth re-iterating again here, especially if you do/don’t take AMEX or any international card types.

This might seem incredibly simple -  and the result is pretty simple. But it’s clear from just a few minutes browsing the web that a lot of sites aren’t following the basics when dealing with transactions online.  Pret a Manger’s online top up for their Pret Card is pretty hideous- they don’t seem to know what to call things so have gone with the ‘/’ approach (FYI Pret you can just call it a ‘card’  - customers get it!). The Maestro information is shown for everyone and the expiry date is hidden to the bottom – with some badly pixelated non transparent 3D Secure scheme logos (this is how I discovered this issue – by constantly failing to fill in the expiry date and thus failing to pay)

This is from Kurt Geiger-  better isn’t it?

Lovely, clean, simple and ordered.  My favourite type of form.

Now I have my basic form I’d start looking at validation and error messages next..but that’s too much serious for one week so you’ll have to hang on for that one until next time.