Getting started with ecommerce

Paul Boag

More from show 200: Drew and Rachel share their experiences of developing ecommerce websites.

Paul: Right, shall we talk about e-commerce, because I thought that might be something interesting to deal with. It follows on from the Perch conversation in a lot of ways. One of the challenges you’ve had to face surrounding commerce and working on e-commerce sites. I guess my first question is – there’s a lot of people who are wanting to sell stuff on their sites, a lot of people kind of go in from huge online retailers right the way down to someone that wants to sell their local band’s album. Where do you start when working on an e-commerce site? What are the initial things that you consider when developing an e-commerce site?

Drew: Hmmm…

Rachel: The first thing really that you need to think about is how are you actually going to take payments. Disregarding your actual shopping cart type stuff on your site, right from the outset you need to think about how you’re going to take payments. And there’s a whole bunch of options for that, and a lot of that is going to depend on the type of client and what they already have. If you’ve got someone who’s already got a physical shop, they’ve probably already got a merchant account with the bank.

Paul: Right.

Rachel: So most likely are going to want to take their payments through that merchant account, which basically is the bit that allows you to accept credit cards. If you’ve got a merchant account you’re able to accept credit cards off your own bat, you don’t need to use somebody else. The thing you should never do, and I still encounter people trying to do it, is think "Oh, it’s alright! I’ve got a PDQ machine or got some other way to take transactions, either over the phone or when people are there in the shop. I’ll just store the credit card numbers and then offline I’ll put them through my PDQ machine." And I still encounter people who think that that is OK. That is not OK. That’s not OK from your card agreement point of view because internet transactions are different, they’ve got a different level of liability and if your bank find out you’re taking internet transactions in that way, they will close your account.

So that’s really important, that people understand that dealing with taking payments online, even if they’ve already got that merchant account, that they need to speak to their bank and arrange to have that ability.

Paul: Marcus, have you got some kind of jingle going on? Because everybody in the chat room is screaming and shouting.

(Noise in the background)

Paul: Yeah. So it’s definitely that camera, OK. Right, I’m narrowing it down guys, we are getting there! We’ll start this whole conversation again.

Marcus: Don’t have to, as long as you can remember where you were.

(Audio from a few seconds ago plays in the background.)

Everyone: (Laughs)

Paul: Alright, now turn that down.

Marcus: How’ve you managed that?

Paul: I don’t know, cos I’m clever.

Rachel: I like the fact that I get a moo-ing camera, that’s excellent!

Everyone: (Laughs)

Paul: Is it back now? It is, I can see it going up and down!

Everyone: (Laughs)

Rachel: I really don’t make this noise.

Everyone: (Laughs)

Marcus: It’s gone, it’s gone, it’s gone…

Paul: Oh it’s gone! Right, so we’re now safe. Rachel, you no longer moo!

Rachel: (Laughs) Excellent!

Paul: I have no idea what happened there guys, I’m really sorry. I blame Marcus, because he’s in charge of sound.

Marcus: No, it’s Dave.

Paul: It’s Dave! It’s Dave! Dave heads out of the room and everything broke. Ok, that’s one. Someone should keep a note, that should be a first drink of the day. Every time we make a major screw-up.

Marcus: Ok, but who gets to have the..

Paul: Let’s pick Dave as the person that has to drink every time. What were we talking about?

Everyone: E-commerce!

Paul: That was it, we were talking about e-commerce. Let’s talk some more about e-commerce. Talking about the things you need to consider, and I’ve got no recollection at all to what you were saying (laughs).

Drew: Talking about people not taking…

Rachel: I think I was saying moo. (Laughs)

Drew: …about people not taking the responsibility of dealing with credit cards seriously.

Paul: Right, yes!

Drew: Because that’s something you do see a lot, I mean you see people emailing credit card numbers around.

Rachel: You see people storing them in plain text in text files in a database, it’s not as much as you used to, but it does happen. I think people don’t really understand all of the bits which go into taking payments, particularly if you’re using your own merchant account. Because you’ve got various bits; You’ve got your merchant account, so if you’ve got an account with HSBC or whatever that allows you to accept credit cards. That’s one part of the jigsaw, the other thing you then need is, because you can’t take these credit card payments actually yourself, you shouldn’t be generally storing them anywhere. Very very few circumstances should require you to store credit card numbers.

You need what’s called a payment gateway, which is the thing which allows you to send your credit card details securely. They actually do the processing, check it’s valid and then hand that off to your bank and the money goes into your account. All of the big banks have their own, or you’re hooked up with one. So you have the NatWest Streamline and Barclays ePDQ, things like that. If you’ve got a merchant account, your bank will be able to tell you who they use. You don’t necessarily have to use your bank’s one, there are other ones. We like PayPoint, which used to be called SECPay.

Paul: I’ve never come across PayPoint.

Rachel: PayPoint are great, they’re great for developers, they’re very very good.

Marcus: I remember SECPay.

Rachel: Yes, well PayPoint are SECPay, it’s the same company. They’re great, they offer payment processing facilities and they work with all the major banks. Your bank would be very happy if you said these are who we’re going to use if you’re gonna go the whole hog and have your own merchant account, be able to accept your own credit card transactions. Of course, what a lot of people do these days is use something like PayPal, which means you can have that ability to take payment online without having to have a merchant account.

A lot of people, if you’re a new business, you might find it difficult to sign up for a merchant account anyway. You tend to sort of need to be established and things before the bank will be happy to give you one.


Paul: I mean the problem with PayPal obviously is that they seem to take an enormous slice compared to most other companies.

Drew: It depends what volume you’re doing really. For low volumes, PayPal works out cheaper. Because you’re not having to then pay for all the expense of the payment gateway, the traditional payment gateway.

Rachel: Because you have monthly charges and things, as well as your transaction charges, you normally have monthly charges for having the merchant account and a monthly charge for the payment gateway.

Paul: Yeah.

Rachel: So actually if you’re doing low amounts of transactions and not a huge amount of money, you may find actually that PayPal works out cost effectively for you.

Drew: The nice thing about PayPal is you’re paying per transaction, there’s no ongoing fee. So if you don’t make any sales, you’re not paying any fees. You’re only paying a percentage when you’re successful really.

Paul: Yep, that makes a lot of sense.

??: We paid £20 a month…

Drew: Oh yeah, if you upgrade to a bigger PayPal account with more features, then yeah, you do start paying.

Marcus: From the chat room here, "They take a big slice, take forever to process and support is awful".

Rachel: Yeah, I mean I think that’s the thing with PayPal is that people do have issues with them, and also not everyone’s clients are going to be happy to sign up with PayPal, or to even use PayPal. They’ve got a bit of bad press.

For us with Perch, most of our clients are very happy to use PayPal, they’ve already got PayPal accounts and that’s fine, but for a more traditional store that might not be the same. I think you do have to look at your customers a bit, and are they likely to be happy to do that. The nice thing about PayPal is that it gives you an easy "in" to all of this. You know, if you’re starting out, maybe you can’t get a merchant account or you want to test the water before you get a merchant account and go to all that expense, and also the expense of developing for it, PayPal gives you a really easy "in". You’ve not lost anything; If you decide it’s not working out, you haven’t got an ongoing charge, you’re not tied in for any length of time to use it. So it’s a good option, and there’s things like Google Checkout as well.

Paul: Yeah, I’ve never used Google Checkout, what’s that like?

Rachel: I’ve not actually developed for it yet. I hear tell that it’s relatively difficult to develop with, because people seem to be having problems, but I’ve not actually developed something for it.

Paul: Ahhh OK. So what are the things you need to think about from a technical perspective when you’re working on an e-commerce site? You’ve mentioned a few things, but what’s the key considerations from your point of view, as people building it?

Rachel: It depends on what you’re going for, if you’re using your payment gatewaym or with PayPal particularly, what you tend to end up with is what’s sometimes referred to as pay-page, which is where you go out to a third party site, the card details are taken on the pay-page by that third party, and then you’re transferred back to the site to finish the transaction.

Paul: Yeah

Rachel: Typically from a technical point of view, what happens then is a transaction ID is sent back so that you can do any post payment processing; Send out the download software, or passing on ready for shipping, or sending emails, or whatever it is you do after payment. The nice thing about that pay-page integration is that you never touch the credit card details. You don’t have any liability for them and they go out to the payment gateway and it’s all taken there. And of course that means you don’t have to worry about that. This is something that’s becoming a real issue because of something called the PCI DSS compliance which means that you have to comply with all sorts of things if you take credit card details, and that comes into play even if you just pass those details over and never actually write them down or store them. You still have to do all sorts of things with your server; making sure you’ve got the correct firewalls and have security scans and all kinds of hassle. So really we tend to recommend people do the pay-page thing, not do an integration where people take payment on their own site. Just because you then don’t then have that liability.

Drew: For a long time it was considered best practice that you keep the customer on your side the whole time, you manage the entire experience, you take the credit card details and in the background you pass those off for processing. But there’s a couple of things really, this PCI DSS is one big issue these days with the legislation that as soon as those credit cards touch your server at all, then you’re liable for all sorts of extra overheads that you really don’t want to be dealing with.

But the other thing is that there are far fewer payment gateways than there are online shops. People are likely to be more familiar with someone like WorldPay, or PayPal, or Google Checkout than they are with you, as somebody who is selling online. So the customer may well have more trust in who you’re using for processing than they do in you.

I know that from a personal point of view, when I’ve been looking for something online trying to find the cheapest price. You search around and find some odd looking store, and you don’t know anything about it, it’s just turned up in google and they’ve got the thing at a good price. If you see that they’re using a payment provider who you trust, using WorldPay or someone, you know that "Ok, they’re decent enough to get an account with (someone like WorldPay) and I can go back to WorldPay if I have any issues with this transaction". So it gives you a bit more confidence with buying from someone who’s reputation you ‘ll not necessarily be familiar with.


Paul: Absolutely…

Rachel: Clients will tend to say that, "I want control of the basket, and I want the payment to happen on my site". I think often when that’s asked, they haven’t really though through what they’re then going to have to deal with. There’s a huge amount of liability, there’s an awful lot of work that’s going to have to be done. It’s going to mean they’re going to have to have a more expensive hosting account for instance, because you’re not going to pass PCI DSS on a shared server or shared hosting account. So there’s a whole load of stuff that you’re going to have to worry about because you’ve touched those credit card details. Only in a tiny tiny way passing them on to the API.

So I think generally, we tend to try and guide people to using pay-page. Some of the providers, PayPoint, you can brand up the template so that they can look like your site. I don’t think purchasers are particularly upset by going out to a third party, they’re used to it. They’re used to going to a third party to make payment these days. As long as you can capture the output of the payment and deal with things on your side, you don’t have to destroy the experience because of that, you just need to design around it really, and make sure people know what’s going on when they go out to that third party.

Paul: Yeah, what about user considerations since you’re working on an e-commerce website, are there certain things you consider really important to think about when designing and kind of creating the front end part of all this?

Drew: Yeah, I mean for checkout processes it usually pays to be as straight forward as possible, in terms of your development techniques. Really, just in the same way as you do with design, you just strip away the distractions. It can serve you well I think to not try and be too flash. Just the process of taking payment details or whatever it is, just be straightforward, clear and reliable because you don’t want that part of your work to be the bit that’s letting you down. You don’t want people to be encountering weird JavaScript validation issues while they’re trying to sign up for an account because you want to get them through that boring process as quickly as possible. So that’s definitely a consideration, not trying to be too swish.

You need to think about, really from the outset, when you’re dealing with e-commerce stuff, the details like; How are you going to deal with delivery? How is delivery charged? And they’re the sort of thing that you not only need to communicate to the customer quite clearly but also you need to understand before you pick what sort of solution that you’re going to develop. If you’re going to use an off-the-shelf system, if you’re going to have to develop something bespoke, if you’re going to use a service like shopifyor something like that. You need to consider what your scheme is for charging for delivery; Is it that you charge by weight?, or do you charge by number of items? Does it become free after a certain value? There’s all these different ways which seem quite commonplace but you need to make sure that you can deal with them technically.

Paul: It goes back to what we were talking about earlier about thinking about things like VAT, and delivery charges as you say, discounts, refunds…

Rachel: Discounts are always an issue (laughs)

Drew: Discounts are a major major headache. If you think about all the different ways you can express a discount. Just go into a supermarket and look at the different ways they do discounts.

Marcus: Three for two.

Drew: Yeah, three for two, or buy one get one free.

Rachel: Or buy this thing and get this other thing free.

Drew: Yeah, or buy 4 of these and get this thing half price!

Everyone: Yeah.

Rachel: And people don’t think through this, people say "I want a simple e-commerce system for my site"and you start asking the questions, and they’ll say "Oh yes, we want the ability to do special offers", then you say "But what sort of special offers?" and then they come out with "Oh well we could do this, and we could do this or we could do that" and I think particularly if you’re building custom stuff. Obviously if you’re using third party shop or cart or whatever, then your gonna be able to say "Well, you’ve chosen to use this solution and this is what it offers". If you’re developing custom e-commerce and shopping carts there are so many details, and you really do need to tie those down at the beginning because you can really get scope creep. E-commerce sites are the place where we see the most scope creep and the most of where clients come back and say "Oh, you know what would be really handy if we could just do…" y’know? There’s so many different variations in, say, things like shipping, If you’re dealing with some physical products and some electronic downloads, you don’t charge someone shipping for electronic downloads and there’s so many different things that you need to consider. They really do need speccing out very very well from the outset.

??: We had a client once, who wanted us to basically create an area in the back-end of the e-commerce site that we were building for them that would basically allow them to create rules relating to discounts. And you think like "eh uh", it’s not gonna happen.

Drew: It gets mindblowingly complex, we tend to go one of two ways. Deciding on a type of discount they can do quite easily, so they can offer a 10% discount, or a 20% discount or something like that, but not combinations of products equal… this sort of thing. Or we can go down the other route of just putting the system in place and saying "Right, when you need to do a special offer, hire an hour of our time, and we’ll write the code for that special offer and that’s going to work out an awful lot cheaper than trying to build an enormous system that will deal with any sort of discount. Just come back to us, the maths isn’t complex. We’ll just sit and write it and then that’ll be in your store" and do it that way.

You think of the complexity that must be in supermarket till systems, the ways they deal with all those discounts, it must be mindblowingly complex and you really don’t want to be taking on the burden of that level of code inside your application. Because it’s just going to be very expensive and you’re going to have to maintain that code going forward.

Paul: My wife’s just arrived! Hello Cath!

Cath looking silly

Everyone: Hello Cath!

Cath: I come bearing food…and drink.

Everyone: (cheers) Yay!!

Paul: Are you gonna set up in the other room?

Cath: Yes.

Paul: Cool.

Cath: I’ve done it already.

Paul: Oh, you’ve done it already?

Cath: Oh, and by the way the GPS doesn’t work and you don’t … (not close enough to mic to hear)

Paul: Well, you got close enough.

Cath: So I’ve spent about a quarter of an hour driving around the countryside.

Paul: Well that’s ok. I’m getting told off live on a show by my wife!

Everyone: (Laughs)

Marcus: Sorry Cath, can you do it again later? But into a mic?

Everyone: (Laughs)

Paul: We’ll get you in properly in a minute Cath.

Cath: Bye!

Paul: Bye Bye! … Ryan!

Ryan: Yes.

Paul: Sorry, didn’t mean to shout into the mic. We‚Äôve got Elliot coming on soon?

Ryan: Yes we have.

Paul: Which is great

Drew: I should just say, we’ve also been asked… I’m wording this carefully… to "please can you produce magic" by one of our clients. Those were their exact words, "We would like magic".

Paul: How would you respond to that?

Drew: This was in an email, "we would like you to create some magic".

Rachel: We get asked for the "wow factor", I’ve not quite defined what the "wow factor" is and how it relates to me as a web developer but yeah. I like definable things.. I’m a programmer, I like definable…

Drew: I think that’s where I was going, with the discounts, is outline exactly to the point, "We’d like this form of discount, this form of discount" and apply that to a particular process.

Rachel: I think it’s fine saying these things can grow organically and we can decide when we get to whenever, but I think that’s gonna make it more expensive. If you know you want to do things to a tight budget, and get it done on time, you need to have that sort of stuff specced out at the outset because there’s just so many different combinations of things.

Paul: Someone’s put in another good thing which you get sometimes. Is it "zebedee"? says "It doesn’t ‘pop’ enough".

Everyone: (Laughs)

Drew: A design that "pops".

Marcus This is where we need the HTML5 audio tag. (Laughs) just get it to go "pop" "pop".

Everyone: (Laughs)

Paul: That’ll teach ’em!

Thanks goes to Ruchard Adams for transcribing this interview.