An Idiot's Guide to eCommerce Payments

It never fails to surprise me that despite it being the most critical part of any ecommerce transaction so few people within the industry really understand ecommerce payments. Yes it's true that the payment industry is extremely fragmented and notoriously disconnected - every bank has it's own way of doing things, every contract a loophole and every card scheme a set of different rules - but this is slowly beginning to change and to be quite honest in most cases ecommerce payment is the same and relatively unchanged across models. Even if you don't understand the concepts as a whole you should understand them in relation to your own business, if you don't then start, because this is in my opinion the key part of being a retailer online. If people can't pay you don't get profit- need I spell it out for you any more? (Plus card schemes fines are preeeeeettttttyyyyyyy large so you'll want to make sure all those profits aren't eaten up).

Hugest apologies if this is teaching anyone to suck eggs, but I still hear scary terminology banded around like 'ghosting' (on the list of least favourite words of all time), incorrect information being told to customers and a general lack of understanding about what things mean. I'm not a payment expert by any means and I've learned many of these things by trial and error so don't take my definitions and comments as gospel - these are merely the things I think I've managed to pick up along the way and have worked for me. The idiot in the title (as always) is me by the way....

Let's start at the beginning of the customer payment. Seems as good a place as any to start.

Card details - probably one of the most sensitive pieces of data in your business, and the one customers least like to part with. As an online business you should be aware that you cannot under any circumstances store full customer card details - your PSP must do this on your behalf (they're like Level Ninja PCI Compliant, they have 6 ft thick walls and 24 hr security in their data centres, needless to say your average retailer -  not so much) . That means both in your database, on spreadsheets, in your customer service ticketing system or in fact on a post it note on your desk. That way goes pain and destruction my friend.

CVV/CV2 - People call it by both terms, for customers on the front end I prefer "Card Security Code" as it's easiest to understand but they're all the same thing. It's the three digits on the back of your card (or four on the front just to be confusing thanks Amex). It was introduced to add additional security - in theory to prove you had the card in your possession at the time of the transaction - in reality by and large these digits are utterly worthless once you've entered them once as they're now no longer secret. However this is a mandatory check you must do when authorising with the major card schemes (I'm mainly refering to Visa, Mastercards, Maestro and Amex when I talk about card schemes here, there's various others..Diners etc who may be different). Failure to do so can result in investigation and ultimate dismissal from the scheme (though only if you had a whole pile of chargebacks to be honest but if you did, and you didn't check CV2 - well I'd think you were the idiot). Now where this gets confusing is that some types of payment don't require CV2 checking.....ah told you this was fun. So mandatory - but also not :-)

PCI compliance - oh the joys of my world. As the resident PCI person in our business I get the fun job of trying to understand PCI compliance. If I was to give you any advice it would be this 1)  Don't leave it all for tech - it's business process as well 2) Keep on eye on the standards and not just the self cert questionnaire - it's a bit 'don't ask don't tell' on that questionnaire so I'd always go over the top and implement as much of the standards as you can 3) Watch your transaction levels - Amex have a much lower jump between levels of compliance than Visa and Mastercard, it's easy to hit Level 2 with not much effort for Amex. Remember also that PCI compliant refers to the certification part - just doing things right doesn't make you PCI compliant you have to be checked (by a trained PCI auditor in Level 1 or by self cert at other levels - this has just recently changed so that you must have someone who is trained in your organisation or hire a consultant to do it for you for some of the levels - check which one you are). Normally it takes a yearly full check and quarterly scans to stay compliant.


AVS - Address verification is a simple form of security online, and it merely checks a customer billing address that they're trying to check out with, matches the one on their statement. Format tends to matter here so if on your statement you mention a house name and on your online transaction you don't use it but use number instead the AVS can fail. It's important for a site product owner to understand this as it helps customers if you design your payment form with that in mind. I'd always check AVS first but it depends on your technical setup and your PSP.

 

3D Secure (The 3D stands for 3 domain  for those who wish to know)- if this isn't the bane of your checkout life then I don't know what is. Users hate it, Product owners hate it...banks love it, and it has reduced online fraud significantly since it was introduced.  It's important because it represents a liability shift - the bank authenticates the transaction so the liability for a chargeback (fraud ones anyway) lies with them and not the retailer. It's an optional check (notably John Lewis don't have it on their site) but again if you get a load of chargebacks and you don't have it the schemes are going to start getting pissy with you. Remember you can only use it on your online site - if you take transactions over the phone you have to skip 3DS as you can't ask a customer for their passwords. Like your PIN number it's just not done to share it. 3DS also isn't yet officially compatible with mobiles (the pesky iFrame sometimes loads but not much else).  The simplest way to describe it as online chip and PIN - the liability shift works in the same way. When you complete a  transaction online your payment services provider (psp) sends out a message to your bank to ask if you're enrolled in a 3DS scheme (Verified by Visa or Mastercard Secure Code - Amex have their own and I forget what it's called...SafeKey that's it) -  most cards now are so if you're not enrolled you'll be asked to do so there and then. If you are you'll have to enter your password or PIN (depending on the scheme) in the little box. The box is ALWAYS produced and hosted by your bank -hence the multiple domains bit - however it often looks what we call in the North " a right clip" (banks not being online usability/design gurus in general) and it's not the most reliable of things. This weekend we had a customer who actually thought it was a phishing scam, that's how shit it looked....Anyway, sometimes the 3DS box will flash in front of your eyes and then go away without asking for your password...that's a new shade of fun called.....


Adaptive authentication - which was introduced a while ago (with a fairly massive failure to communicate) by some of the card schemes who realised that 3DS was causing a usability and dropout issue (you'd hope they did anyway......maybe they just fancied a change?). Essentially what it means is that it's no longer the case that a 3DS enrolled card will ALWAYS request 3DS authentication. The bank can decide - based on a number of things like whether you've shopped at that site before, the value of your transaction etc - that you're a safe bet, so it doesn't ask. In these cases liability is with the banks still and not with the retailer so happy days. Annoyingly it's a tad inconsistent and customers have zero clue what is going on when the screen starts zipping from you to the bank and back to you in the blink of an eye.



Pre-auth/Auth. Oh here it is, the rant about the word 'ghosting' -which people sometimes use to describe authorisation. I always try to stick to the real words for these things  - partly because you'll just find life easier when talking to third parties and I also find it adds huge confusion when people start assuming things are what they aren't. Most online transactions are made up of three major parts; auth (or pre-auth depending on your view), settlement and capture. In massively simplified terms auth is when you check the money is there, settlement is when you ask for it from the bank and capture is when it lands in your bank account. Settlement and capture and pretty close buddies. Auth tends to happen a larger time before the other two. As far as I'm aware it's rare than you would do a settlement and capture straight away - you have things like fraud checking that get in the way - though I'm sure that there are people who do, and it's called an automatic settlement when that happens, though like I say I wouldn't recommend it when you have fraud to be checking. What normally happens is that you check that the customer has the required amount of funds on their card and you auth for that amount - so the checkout is £200 - you let the customer's bank know that you'll be needing £200 thankyou very much. A couple of days later you may request settlement and capture from the bank once the order is dispatched, or confirmed or fraud has been checked (different companies do it differently), and then you take your £200. Now in order to make sure you get your £200 most banks will 'reserve' those funds in the customer's account. Now they don't go anywhere, it never shows as a transaction and the only time your customer will know it is when they look at their 'available balance' on internet banking (or more often when they run out of available balance :-) ). This is what can be called 'ghosting'. Auth tokens tend to expire - all banks are of course different (you know it!) so this an be anything from 48, or 72 hours to 10 days, to 28 days. You can try to reverse an auth but it's not massively relaible for the same reason. In exceptional circumstances where the auth lasts too long then the customer can notice and get annoyed, other times the auth could expire and you can't then take the funds based on that auth - and you can end up with a failed settlement. There is no real way around either of these, it's the nature of the beast.

1- Click Checkout - For a start this drives me insane because every C level exec I've ever worked for has asked me to do this. I shall repeat here for posterity what I say to them 1) It's proprietary Amazon terminology and functionality so no you can't and 2) it's a per item basis and not per basket so only really works if your site sells things people buy in 1's.

Express checkout on the other hand, or quick checkout, or whatever shade of grey you want to call it - that is OK. You can't store CV2 remember or any card details yourself so this is a bit of an invisible trickery whereby you auth the card the first time, store a token which links to that auth detail and then subqequently you say to yourself  'ah they were fine that last time, let's let them through again'. Typically for the payment industry this is technically a different type of transaction and therefore has a different rate structure. Sometimes your PSP will charge you for the storage of the card details so it sometimes adds a bit of cost there too. However it is one of the best ways to reduce dropoff and add convenience for customers.

Note that if you're "storing" card details for customers in their accounts you're not actually storing them - you're storing the last four digits, an expiry date and probably the name of the card. For this reason there is no such thing as 'Edit card details' - you have to delete them and re-add them. Drives me nuts when people say 'Edit' - what am I editing? Thin air?


Amazon - note this when dealing with payments, do not go and look and what they do and then copy it. Amazon are their own acquirer - basically they created their own bank, they're massive and probably own a fairly sizeable chunk of Visa and Mastercard's business - so they can get away with anything. You can't. Go elsewhere for your ideas.


Chargebacks - oooh nasty nasty, these are not your friend. A chargeback is what happens when a customer gets in touch with their bank and has any number of issues - it can range from their card has a fraudulent payment on it to the fact their item never arrived. Usually if it's fraud and you can prove you did the 3DS check and that you have a fraud checking process in place you can usually have the money re-credited (so the bank pays). There are however multiple reasons for chargebacks including products not being fit for purpose (Quality), refunds not being issued correctly (Clerical), or an incorrect amount being taken (Technical)  so it's important to check the code when assembling your case. You can see them all here and in various lists all over the internet. Some retailers choose to pay all chargebacks, some dispute them all-  it depends on various factors how your business deals with them. Most acquirers will penalise you for having a chargeback raised so in the main it's about doing all the checks up front to minimise them. As mentioned before - a large number of chargebacks will give you some unwanted attention from a number of payment organisations who are involved with your business so it's hugely in your interest to avoid them.


OK well that's my brain dumped out into a blog post. I really hope that's been helpful to someone, somewhere. Let me know in the comments if so (or if not indeed and I'll go back to writing fluff about how people are idiots :-) ), and of course feel free to correct me.



Useful Links

PCI DSS Standards
Visa Chargeback Codes
Wikipedia on AVS checks
Fraud Practice - some useful white papers etc