Hello, once again!
I've now managed to get some clarification on the payment processing side of things and I've got my head straight. If you are reading this blog because you intend to set up a web-shop as a serious business for money-making, I recommend that if you haven't already checked out Business Link (which is a government quango created to help people setting up a business), then you better get on the case, sharpish! Top marks go out to this site for clarity and quality of info.
As I mentioned before, if you own a corner shop (a physical business) and you want to take card payments, you have to have the 'interface with the banks' that allows you to process transactions. It transpires that this is done through what they call a 'merchant account' that you have to set up with a bank. You would have to supply business history, turnover forecast, average transaction values, transaction frequency, suppler details etc etc. Furthermore, you would have to pay either a flat rate fee to the bank, or pay the bank a percentage of each transaction. We all know about banks; their services are not cheap, they like to milk you, properly.
Now think about our online store, it's very similar really. Let's compare the purchase processes of the online store and the cornershop:
Corner Shop:
1) Customer browses products on shelves.
2) Customer chooses items and puts them in basket.
3) Customer brings basket to checkout (therefore confirming his order in full).
4) Customers card info is sent to external processing (via the bank merchant account).
5) Transaction goes through.
6) Customer walks off with goods.
Online Store:
1) Customer browses products in gallery.
2) Customer chooses items and adds them to basket.
3) Customer reviews basket (therefore confirming his order in full).
4) Customers card info is sent to external processing (via a Google Checkout merchant account).
5) Transaction goes through.
6) We are ready to post the goods to the customer.
If I design the system from scratch and opt to handle processing myself, it will actually be less effective. I'd have to design the system so that is displays the cart contents to the customer for confirmation. Once confirmed, I would have to hold the cart contents in the computer's memory while I present the customer with another form, for his card details and delivery address details. I would then need to use these card details to clear the payment using my bank merchant account.
If I use Google Checkout, or a similar online merchant account service, it's basically the same but there are key differences. Like I've stated before, the Google name is recognised, therefore customers will feel more at ease using a Google service than they would using my basic, hand made form (although, saying that, I would make it very pro-looking). Also, Google Checkout also only charges a very small amount per transaction, 1-2%, as opposed to the banks, which I am informed charge 2-6%.
With Google Checkout, the customer never actually has to trust me with their card details at all. They register their card with Google and they simply use their existing username and password to pay at ANY online shop that uses Google Checkout as a processing option. I hope all that made sense.
All I have to worry about is how I communicate the contents of the user's virtual shopping basket to Google.
For more details on the bank-based system, please read 'Accepting Debit And Credit Cards' on BusinessLink. For more on Google Checkout, do some research here.
That's all for now. It's gonna get better from here, I promise.
Implementation is coming up shortly. YESSSS... THATS WHAT WE LIKE!
Phil ;)
Thursday, 25 October 2007
A Massive Change Of Plan
Things have got a little bit dodgy now and I think I'm going to have to change the plans. I'm getting a little bit scared due to the complexities of developing my own checkout system from scratch.
You have to understand that there are two halves to an e-commerce system. First of all, you have the actual checkout itself: This includes the methods for allowing the visitor to compile a list of products they want to buy, and then calculate a final price. That is stage one.
THEN you have stage two - the payment processing. This is the bit when you get the customers card details and actually charge their bank account. This is the bit that scares me and this is the bit that I think it going to cost me. If I go for a fully 'from scratch' e-commerce system, as planned, I'm going to have to find some way of handling the payment processing. I don't know whether that involves having some kind of agreement with the banks or what.
As far as I know, if you own a physical business, such as a corner shop, if you want to take credit card payments you have to have some kind of agreement with an external payment processing company. You take the customer's card, they enter their PIN for verification, the transaction details are sent via a telephone line to a payment processing company (the banks probably offer this as a business service), that processing company must then sort out the transfer with the customer's bank, then 'ok' the transaction and send confirmation to the shopkeeper that it was a success. (Phew, that took some typing).
With my proposed online system, the customer will use my custom-built shopping cart system to create an order (a list of products they wish to buy) and calculate the amount due. That is where 'I get off', that's the end of my involvement. I then must have the ability to send the 'amount due' information along with the customer's card details to the external payment processor. Damn, I can't believe I never took that into consideration.
The first thing that I'm thinking of now, is that must be another advantage to using Google checkout - Google has the capability to take part of the payment processing. It's a massive organisation that must have the bank-end all sorted.
This means that, at least for now, I would be stupid not to use Google Checkout or something very similar, in my project. If I create the system up to the point when the transaction is ready to be paid for, I will then hand the transaction over to Google, or whoever, for the actual payment processing.
My next task is to explore Google Checkout and it's rivals, analyse their pros and cons against each other and see how they integrate into a pre-built website. I'm sure there will be a whole host of limitations that will effect the project, but I'm very optimistic now that I have an idea of where we are going.
Peace. Out
Phil
You have to understand that there are two halves to an e-commerce system. First of all, you have the actual checkout itself: This includes the methods for allowing the visitor to compile a list of products they want to buy, and then calculate a final price. That is stage one.
THEN you have stage two - the payment processing. This is the bit when you get the customers card details and actually charge their bank account. This is the bit that scares me and this is the bit that I think it going to cost me. If I go for a fully 'from scratch' e-commerce system, as planned, I'm going to have to find some way of handling the payment processing. I don't know whether that involves having some kind of agreement with the banks or what.
As far as I know, if you own a physical business, such as a corner shop, if you want to take credit card payments you have to have some kind of agreement with an external payment processing company. You take the customer's card, they enter their PIN for verification, the transaction details are sent via a telephone line to a payment processing company (the banks probably offer this as a business service), that processing company must then sort out the transfer with the customer's bank, then 'ok' the transaction and send confirmation to the shopkeeper that it was a success. (Phew, that took some typing).
With my proposed online system, the customer will use my custom-built shopping cart system to create an order (a list of products they wish to buy) and calculate the amount due. That is where 'I get off', that's the end of my involvement. I then must have the ability to send the 'amount due' information along with the customer's card details to the external payment processor. Damn, I can't believe I never took that into consideration.
The first thing that I'm thinking of now, is that must be another advantage to using Google checkout - Google has the capability to take part of the payment processing. It's a massive organisation that must have the bank-end all sorted.
This means that, at least for now, I would be stupid not to use Google Checkout or something very similar, in my project. If I create the system up to the point when the transaction is ready to be paid for, I will then hand the transaction over to Google, or whoever, for the actual payment processing.
My next task is to explore Google Checkout and it's rivals, analyse their pros and cons against each other and see how they integrate into a pre-built website. I'm sure there will be a whole host of limitations that will effect the project, but I'm very optimistic now that I have an idea of where we are going.
Peace. Out
Phil
Wednesday, 24 October 2007
A Working Demonstration
Before we go any further with the project, I just want to double-check that we know exactly what we're going for here. I've had a quick browse around the web and have come across a site that displays exactly what we're aiming for. http://www.chargrilled.co.uk/. (warning: some mildly offensive slogans on the site)
It's a UK-based t-shirt shop that had a very nice online purchasing system. It's quick and easy to use and the process-flow is easy to follow. What I mean to say is that even if you've not ordered online before, it's obvious what the buttons do and where they are to be found.
For the benefit of you lot, my loyal readership, I'm going to clarify the main elements. If you have a look at this little comparison graphic, you can see this important parts of the chargrilled.com shopping system and see how our online painting shop follows the same principles:
We've got a thumbnail image with a 'more info' button underneath it - so have they.
We've got an 'add to cart' button on our item info page - so have they.
We've got the ability to 'view basket' at any time from any page - so have they.
If you care to have a poke about on their website (and they sell some very cool little products), you will see how amazingly functional their design is.
Click on a shirt or a 'more info' button and see how you get transported to a page from which you can select options, view details and add to cart if you wish. It's better to have all this info on a seperate page for each item for a few reasons. The main reason is that on the initial gallery page you don't want to swamp the visitor with superfluous detail, you want to display as many products as you can at once, because only if the visitor sees a product he or she likes will they go on to buy it - the more products on display then the better the chances are that one will catch their eye.
I hate information overload; imagine if you tried to display the thumbnails, prices, size choices, colour choices, postage information, etc etc, all at once. It just wouldn't work. Futhermore, what if one item had more selectable options than all the rest? It would upset the symmetry that the gallery page creates. Not good! Another advantage that springs to mind is that if you wanted to change the pricing or size options for one particular item, you could just go to that items dedicated product page and change your HTML there with no risk of accidently messing up anything else, plus it would be easier that shifting through a fairly complex gallery grid trying to find that product.
Once you've added a shirt to your cart, chargrilled.co.uk confirms that you have done so. This is good not just because it's polite but because it's positive feedback that tells the user it had worked, they know where they are. It's terrible to have clicked a button and then not know if it's still processing or if it's failed. I want our painting shop to be equally as professional.
After confirmation, their system actually forwards the user on to view their cart. This is a nice touch but to be honest I'm not sure it's the best choice. It does guide the person logically forward with the purchase and therefore start handing the money over, but isn't the idea of business to get as MUCH money as possible out of the customer? It is in my books. I think a better option would be just to take them back to the gallery they were just looking at when they selected the product. This is a case of whatever suits you I suppose. I think all things considered, I'll give our users the option to either go back to gallery or view the cart, in that order, without any automatic forwarding. Perhaps I'm putting too much thought into small details at this stage, who knows, I'm just speaking my mind!
If you care to carry on their shopping cart - wow! It's very, very nice in my opinion. It's cluttered, it shows me what I need to know and nothing else and it is neat and tidy - Just what I'm after! You get a little pic of the items you've selected, the name of the item and it's particulars, the unit price, the quantity (which can be changed), the total price (unit price multiplied by the quantity), and a method for deleted an item from your order. You get a grand total at the bottom which is nice and clear.
You then get the options:
1) Continue Shopping - which takes you back to a product gallery
2) Checkout
3) Google Checkout
Option 1's function should be pretty bloody obvious by now, but options 2 and 3 are more interesting. Why the hell would you have two checkout options? What's the difference? Obviously you only need one, but luckilly I'm experienced enough with online shopping to be able to explain a bit about all this.
The first checkout option is chargrilled.co.uk's own bespoke ecommerce system. This has either been custom-designed by a developer that they have hired, or it's an out-of-the-box all-in-one solution that they have bought and paid for and designed their website around. The benefit for them is that once they have paid the one-off fees of getting this sorted, they will not have to pay anything to process each transaction.
Google Checkout on the other hand is different - Chargrilled will have to pay a fee every single time a user pays through the Google system. Why on earth would they want to implement this? In my opinion - the Google name. Google is massive, everything it touches turns to gold and it is a well-known and trusted brand. In a buyer's eyes Google means security. I also happen to know that in a nutshell, Google charges less for advertising if you use it's checkout service on your website - a major bonus for chargrilled. Good tactic by Google.
These are a few things to think about. Sorry if the post rambled on a bit. In my next post I'm gonna actually have a crack at exploring these two checkout options and looking at which one would be most suitable for our project.
Take it easy.
Phil :)
Monday, 22 October 2007
The Essentials - Gallery and Item Info
As I said when I began this project, the plan is to sort out a mock up of the fully functional site before I start messing about with the presentation. Therefore, I decided to prepare the bare minimum of the site by picking a two-coloumn CSS/HTML template from Free CSS Templates. (I don't consider this cheating by the way, as if I did the CSS myself it would have turned out the same anyway). A header with horizontal navigation, main content in large left coloumn, space for extra links etc in right coloumn. Nice.
I then began to produce a sample gallery page, as planned. Using the nifty little gallery layout idea I stumbled across in my last post, it didn't take long for me to come up with a basic gallery. I then cooked up a simple thumbnail image, had a VERY quick play with the image size, then integrated the Lightbox JS idea (mentioned in last post). This is about all I need to do for the gallery for now.
So to recap, we have the gallery page:
You can see I've whacked in a working title and header, 'Images of Oxfordshire' and a nice little tagline underneath, 'Original canvas paintings from South Oxfordshire.
Next is the navigation bar, which is CSS styled and text based. This type of navigation is quicker to load that pure image-based navigation. The text labels can also be read by screen reading software, which is a key concept when designing with accessability in mind. Furthermore, search engines can read the text, which is always a bonus.
The gallery thumnails can be seen in a tidy little grid. Under each image is the text 'Details Buy'. Regardless of whether you click 'Details' or 'Buy', you are taken to an Item Info page, which will display details and a buy button.
It's worth noting that the options on the navigation are just initial ideas, no thought has gone into them other than the last one - 'View Basket'. If you look back at the sketch I did on paper at the start of the project, you'll see that once a user has added a painting to their basket, I want the app to return to the gallery they came from in order to continue browsing. If they decide then, or at any point, to finish their purchase, the checkout must be easy to get to. In fact, this is so important that as I type this I'm thinking about having that button on the right of the nav-bar and making it a few pixels larger in font size, to make it stand out. Hmmmmm, that idea may need some playing with. At the end of the day, this is only a mock-up and the styling of the whole navigation system is subject to change as the project moves on.
If a user clicks on a thumbnail, the Lightbox JS system will present a nice big version of the pic overlayed onto the gallery. It's pretty damn sweet and it goes a little something like this:
I love this effect. Personally, out of all the ideas I've seen for galleries, I think it's the nicest. In terms of raw presentability it's unbeatable, but it's also quick to load, easy to implement, CSS-stylable, cross-browser compatible, the list goes on.
I have seen good alternatives, such as pop-up image containers on mouseover, but that's not for me.
Note - the photo was nothing to do with me, it's a pic that comes with the lightbox as a demo.
Finally, I have constructed a basic Item Info page. It shows the painting's title and artist's name, plus the year of the work. It shows a nice, to scale, bigger version of the painting. I have left room under the image for further details, such as dimensions, medium used, what drugs the artist was on at the time etc etc.
Most importantly, on the right hand side, I have made 'Buy This Canvas' button - It's CSS-styled and stands out. Remember, a text based button is better for accessability. Also being CSS-styled, if I want to change the way my buy buttons look later, I can do it by making one change to the CSS master file. I have left room for a price under the buy button. There is also of course, a link to navigate back to the gallery the user came from:
That's all for now :)
Phil
Wednesday, 17 October 2007
Initial Image Preview Idea
I've had a little browse around online and have come across some very interesting articles that may be of some use to my project...
First of all was MaxDesign's Floatutorial, a lovely little tutorial on using CSS for a wicked thumbnail display. I will have a little play with this and try and find the optimum size for my thumbnails. The tutorial includes captions underneath each thumb which is really handy, as I have imagined having an 'info' link underneath each thumb, which will then take the user to a page from where they can read a bit about the painting.
The second little gem was actually something I've seen before but never managed to get working. Lokesh Dhakar's Lightbox JS is a really cool little script. Basically, you click a thumbnail and the full size pic will appear over the top of the page while the background is simultaneously dimmed. When you close the lightbox you are back on the gallery page. Check it out, it's easier to understand when seen. It's customisable via CSS and is quick to load.
I've sketched what I was thinking at the time, I think it's cool:
As you can see, from the main gallery page you can click a thumb to see a large version in the LightBox, or you can click the 'Info' button under the thumb which takes you to an 'item info' page - from there you can add the painting to the shopping cart. I want the application to then take the user back to the gallery with the product added to basket.
First of all was MaxDesign's Floatutorial, a lovely little tutorial on using CSS for a wicked thumbnail display. I will have a little play with this and try and find the optimum size for my thumbnails. The tutorial includes captions underneath each thumb which is really handy, as I have imagined having an 'info' link underneath each thumb, which will then take the user to a page from where they can read a bit about the painting.
The second little gem was actually something I've seen before but never managed to get working. Lokesh Dhakar's Lightbox JS is a really cool little script. Basically, you click a thumbnail and the full size pic will appear over the top of the page while the background is simultaneously dimmed. When you close the lightbox you are back on the gallery page. Check it out, it's easier to understand when seen. It's customisable via CSS and is quick to load.
I've sketched what I was thinking at the time, I think it's cool:
As you can see, from the main gallery page you can click a thumb to see a large version in the LightBox, or you can click the 'Info' button under the thumb which takes you to an 'item info' page - from there you can add the painting to the shopping cart. I want the application to then take the user back to the gallery with the product added to basket.
Embarking On an eCommerce Adventure
Hi, I'm Phil, welcome to my new blog and cheers for stopping by!
If you're reading this then one of the following statements is quite probably true:
1) I told you about my blog and you're checking it out just because I asked you to, in a feeble attempt to increase my hits, or,
2) You are actually trying to achieve exactly what I'm trying to achieve.
'Hold on, just what the hell ARE you trying to achieve?', I hear you cry. It's not that long of a story really... To sum it up, I am trying to develop a fully operational eCommerce store, myself, from scratch. At this point it's just a personal project rather than a money making enterprise, but you never know what the future may hold.
'Why the hell are you blogging about that?' - Yes, fair question, and even fairer an explanation. I'm blogging it because I intend to reveal the trade secrets, things that the pro-developers out there don't want you to know, so that they can continue charging for services that people can provide for themselves if they put their minds to it.
The Internet is packed full of downloadable eCommerce solutions, some better than others, but none of the free ones have the exact functionality I require. Almost without exception, you are asked to pay a fee to unlock the decent features. This is FAIR ENOUGH, they put the effort in so they deserve their dosh, but I'm going to do this and I'm not going to pay for it. I consider it a test, and it's going to be a fun learning curve from which I will acquire real, appliable skills.
The Project:
This test project is going to be an art gallery that sells it's paintings. Essentially it needs to display the paintings as thumbnails and allow the user to see a full scale version if they so wish. They then need to be able to add a painting to their basket, then either go back to look at more paintings or go ahead and buy what's in the basket.
They will also need to be able to view their basket at any point during their visit and remove an item if they want.
At this point, I do not intend to have stock levels controlled via a database. I am assuming the gallery will created the paintings 'to order', rather than hold stock, just for simplicities sake.
Once this level of functionality has been reached, I will need to investigate ways of processing the customer payments for the orders. Initially, I'm thinking of PayPal as I know it's easy to integrate and it quite cheap from a shop owners point of view. On the other hand, I'm a bit of a Google fanboy, so I will also consider the new GoogleCheckout system if it's cheaper and easier to integrate.
At this point, I do not know whether I will develop the eCommerce application in ASP, PHP, or whateverscript. However, there are certain (I'm a glutton for punishment) limitations.
Limitations:
Costs must be as low as possible.
The site must be coded in W3C standard compliant HTML and CSS
The site must be designed with accessibility in mind.
The Plan:
First I will knock up a few sketches on paper of what the site should roughly look like, and try and get my head round the flow of data. Then I will do a mock-up of the site, getting the functionality sorted. Finally, I will tweak it up with some fancy styles (where appropriate).
That's about it for now. I'm ready to go for it, and I'm fully prepared to tear my hair out doing it!
Take Care, Phil.
If you're reading this then one of the following statements is quite probably true:
1) I told you about my blog and you're checking it out just because I asked you to, in a feeble attempt to increase my hits, or,
2) You are actually trying to achieve exactly what I'm trying to achieve.
'Hold on, just what the hell ARE you trying to achieve?', I hear you cry. It's not that long of a story really... To sum it up, I am trying to develop a fully operational eCommerce store, myself, from scratch. At this point it's just a personal project rather than a money making enterprise, but you never know what the future may hold.
'Why the hell are you blogging about that?' - Yes, fair question, and even fairer an explanation. I'm blogging it because I intend to reveal the trade secrets, things that the pro-developers out there don't want you to know, so that they can continue charging for services that people can provide for themselves if they put their minds to it.
The Internet is packed full of downloadable eCommerce solutions, some better than others, but none of the free ones have the exact functionality I require. Almost without exception, you are asked to pay a fee to unlock the decent features. This is FAIR ENOUGH, they put the effort in so they deserve their dosh, but I'm going to do this and I'm not going to pay for it. I consider it a test, and it's going to be a fun learning curve from which I will acquire real, appliable skills.
The Project:
This test project is going to be an art gallery that sells it's paintings. Essentially it needs to display the paintings as thumbnails and allow the user to see a full scale version if they so wish. They then need to be able to add a painting to their basket, then either go back to look at more paintings or go ahead and buy what's in the basket.
They will also need to be able to view their basket at any point during their visit and remove an item if they want.
At this point, I do not intend to have stock levels controlled via a database. I am assuming the gallery will created the paintings 'to order', rather than hold stock, just for simplicities sake.
Once this level of functionality has been reached, I will need to investigate ways of processing the customer payments for the orders. Initially, I'm thinking of PayPal as I know it's easy to integrate and it quite cheap from a shop owners point of view. On the other hand, I'm a bit of a Google fanboy, so I will also consider the new GoogleCheckout system if it's cheaper and easier to integrate.
At this point, I do not know whether I will develop the eCommerce application in ASP, PHP, or whateverscript. However, there are certain (I'm a glutton for punishment) limitations.
Limitations:
Costs must be as low as possible.
The site must be coded in W3C standard compliant HTML and CSS
The site must be designed with accessibility in mind.
The Plan:
First I will knock up a few sketches on paper of what the site should roughly look like, and try and get my head round the flow of data. Then I will do a mock-up of the site, getting the functionality sorted. Finally, I will tweak it up with some fancy styles (where appropriate).
That's about it for now. I'm ready to go for it, and I'm fully prepared to tear my hair out doing it!
Take Care, Phil.
Subscribe to:
Posts (Atom)