<?xml version="1.0" encoding="utf-8"?>
			
			<rss version="2.0">
			<channel>
			<title>Application Generation - E-commerce</title>
			<link>http://www.pbell.com/index.cfm</link>
			<description>A series of occasional musings on architecting, securing, optimizing and generating web based applications. By Peter Bell.</description>
			<language>en-us</language>
			<pubDate>Mon, 06 Sep 2010 20:03:05 -0400</pubDate>
			<lastBuildDate>Mon, 24 Nov 2008 16:09:00 -0400</lastBuildDate>
			<generator>BlogCFC</generator>
			<docs>http://blogs.law.harvard.edu/tech/rss</docs>
			<managingEditor>pbell@systemsforge.com</managingEditor>
			<webMaster>pbell@systemsforge.com</webMaster>
			
			
			
			
			
			<item>
				<title>VAT in the UK Going to 15%</title>
				<link>http://www.pbell.com/index.cfm/2008/11/24/VAT-in-the-UK-Going-to-15</link>
				<description>
				
				I&apos;m sure this is old news for most people, but I&apos;ve been speaking to a number of people today about the new VAT rate for UK based clients. 

If you happen to have any UK clients with commerce websites that charge VAT, make sure to have a word with them about the VAT changes before next week as VAT is changing from 17.5% to 15% so you may have some edits to do before Monday!
				
				</description>
				
				<category>E-commerce</category>
				
				<pubDate>Mon, 24 Nov 2008 16:09:00 -0400</pubDate>
				<guid>http://www.pbell.com/index.cfm/2008/11/24/VAT-in-the-UK-Going-to-15</guid>
				
			</item>
			
		 	
			
			
			<item>
				<title>Know Any UK/European Credit Card Lockbox Providers?</title>
				<link>http://www.pbell.com/index.cfm/2008/4/21/Know-Any-UKEuropean-Credit-Card-Lockbox-Providers</link>
				<description>
				
				It&apos;s possible to avoid having to implement a PCI compliant solution for credit card processing providing you don&apos;t store or process the card information. One way of doing that is a lockbox provider such as &lt;a href=&quot;http://www.braintreepaymentsolutions.com/&quot;&gt;Braintree&lt;/a&gt;. 

We have a client that needs to defer the charging of credit cards until the shipping amount is known, but can&apos;t afford to implement a PCI compliant solution in-house. We&apos;re looking for a third party processor where we can seamlessly pass a card details using a form submission to their gateway to authorize (but not charge) the card, and then get an ID back that we can use to charge the card later.

Wondering if anyone had heard of/used a solution like this?
				
				</description>
				
				<category>E-commerce</category>
				
				<pubDate>Mon, 21 Apr 2008 19:12:00 -0400</pubDate>
				<guid>http://www.pbell.com/index.cfm/2008/4/21/Know-Any-UKEuropean-Credit-Card-Lockbox-Providers</guid>
				
			</item>
			
		 	
			
			
			<item>
				<title>E-commerce – Orders and Addresses</title>
				<link>http://www.pbell.com/index.cfm/2008/4/1/Ecommerce--Orders-and-Addresses</link>
				<description>
				
				The thing I love about building even very simple e-commerce applications is that they can bring up sufficiently complex classes of design problems to make them a great testing bed for new ways of implementing web applications. Today I want to look a little at the old “orders and addresses” problem to see if it can provide any more generalized insights into Object Relational Mapping . . .
				 [More]
				</description>
				
				<category>E-commerce</category>
				
				<category>Design Patterns</category>
				
				<pubDate>Tue, 01 Apr 2008 12:37:00 -0400</pubDate>
				<guid>http://www.pbell.com/index.cfm/2008/4/1/Ecommerce--Orders-and-Addresses</guid>
				
			</item>
			
		 	
			
			
			<item>
				<title>CF Commerce - Could be Cool . . .</title>
				<link>http://www.pbell.com/index.cfm/2007/10/19/CF-Commerce--Could-be-Cool---</link>
				<description>
				
				Just wanted to do a shout out regarding the relatively new &lt;a href=&quot;http://groups.google.com/group/cfcommerce&quot;&gt;CF Commerce&lt;/a&gt; project to develop a standard open source commerce project in ColdFusion. It&apos;s got a very interesting team and if you have any interest in building e-commerce sites it is well worth checking out . . .
				
				</description>
				
				<category>E-commerce</category>
				
				<pubDate>Fri, 19 Oct 2007 11:34:00 -0400</pubDate>
				<guid>http://www.pbell.com/index.cfm/2007/10/19/CF-Commerce--Could-be-Cool---</guid>
				
			</item>
			
		 	
			
			
			<item>
				<title>Architecting E-commerce</title>
				<link>http://www.pbell.com/index.cfm/2007/9/11/Architecting-Ecommerce</link>
				<description>
				
				I have done &lt;a href=&quot;http://www.pbell.com/index.cfm/Ecommerce&quot;&gt;some posting&lt;/a&gt; on e-commerce in the past. Now I need to re-implement the checkout functionality for my &quot;standard&quot; shopping cart and need to come up with a good approach to handling shipping, taxes and payment processing. Here are some high level thoughts . . .
				 [More]
				</description>
				
				<category>E-commerce</category>
				
				<pubDate>Tue, 11 Sep 2007 11:50:00 -0400</pubDate>
				<guid>http://www.pbell.com/index.cfm/2007/9/11/Architecting-Ecommerce</guid>
				
			</item>
			
		 	
			
			
			<item>
				<title>How do you handle price breaks in e-commerce?</title>
				<link>http://www.pbell.com/index.cfm/2007/5/3/How-do-you-handle-price-breaks-in-ecommerce</link>
				<description>
				
				Believe it or not, I&apos;m implementing my first price break system ever (I know it is a common requirement, but for whatever reason I&apos;ve not had to do it before). With this system every product has a base price but also has 0..n price breaks which may or may not be unique to a given customer number.

I&apos;m trying to come up with a best practices reusable approach to this as I don&apos;t love the implementation I&apos;m being asked to do (in this system if there is a customer price, it replaces ALL quantity breaks which to me is somewhat of a special case. Also in this case there is a break price but not a range making it effectively impossible to merge customer specific and generalized pricing breaks - again fine for this use case).

It seems to me a generalized solution would include a product identifier (ID, SKU, etc.), customer identifier, min qty, max qty and price per. You could then optionally set store rules about how to merge customer specific and general pricing, and you could still cover special cases like this project by setting the range from 1 to an arbitrarily high number where you wanted a given price to override general pricing.

Also, do you come across systems where it is a numeric or percentage discount for the ranges? Perhaps instead of a price, a &quot;Number&quot; and &quot;Type&quot; (price, discount percentage or discount amount) would give a little more flexiblity?

Any thoughts from anyone who has implemented a few more of these? I understand there is never a one true way, but I&apos;m looking for a flexible data structure and algorithms with a few proeprty settings to cover the vast majority of small to mid sized business use cases.

Thoughts?
				
				</description>
				
				<category>E-commerce</category>
				
				<pubDate>Thu, 03 May 2007 07:49:00 -0400</pubDate>
				<guid>http://www.pbell.com/index.cfm/2007/5/3/How-do-you-handle-price-breaks-in-ecommerce</guid>
				
			</item>
			
		 	
			
			
			<item>
				<title>Implementing Recommendations/Cross Sells</title>
				<link>http://www.pbell.com/index.cfm/2007/5/2/Implementing-RecommendationsCross-Sells</link>
				<description>
				
				I&apos;m looking to upgrade my rather simple cross sell engine. Not looking for collaborative filtering or anything fancy right now (although if anyone can suggest a simple algorithm . . . :-&gt;) - just a nicer approach to a standard manual approach. This posting looks at my proposed implementation. Any input gratefully received! . . .
				 [More]
				</description>
				
				<category>E-commerce</category>
				
				<category>Design Patterns</category>
				
				<pubDate>Wed, 02 May 2007 08:28:00 -0400</pubDate>
				<guid>http://www.pbell.com/index.cfm/2007/5/2/Implementing-RecommendationsCross-Sells</guid>
				
			</item>
			
		 	
			
			
			<item>
				<title>Know Any Good Credit Card Processors (Gateways)?</title>
				<link>http://www.pbell.com/index.cfm/2007/2/22/Know-Any-Good-Credit-Card-Processors-Gateways</link>
				<description>
				
				We&apos;ve been using authorize.net forever, and quite honestly they&apos;re not very good!!! We are on the look out for a new provider for our clients. Below are a list of requirements - the key ones being that they have an API (so end customers can stay on our clients site when checking out) and that they have some kind of rebilling system so we don&apos;t have to store the card numbers . . .
				 [More]
				</description>
				
				<category>E-commerce</category>
				
				<pubDate>Thu, 22 Feb 2007 16:22:00 -0400</pubDate>
				<guid>http://www.pbell.com/index.cfm/2007/2/22/Know-Any-Good-Credit-Card-Processors-Gateways</guid>
				
			</item>
			
		 	
			
			
			<item>
				<title>Product Attributes</title>
				<link>http://www.pbell.com/index.cfm/2006/8/18/Product-Attributes</link>
				<description>
				
				So, what would be a good generic way to implement product attributes?  Here is how I’m currently doing it. Any better ideas or approaches would (as usual) be gratefully received!

Firstly I provide an application wide Attribute manager allowing site admins to create new attributes (color, size, Initials, etc.). Each attribute has a field type (text box, drop down, radio buttons, etc.), an optional default value, the ability to be &quot;required&quot; and (for field types that need it) a text box for entering a comma delimited list of option values.
				 [More]
				</description>
				
				<category>E-commerce</category>
				
				<pubDate>Fri, 18 Aug 2006 12:13:00 -0400</pubDate>
				<guid>http://www.pbell.com/index.cfm/2006/8/18/Product-Attributes</guid>
				
			</item>
			
		 	
			
			
			<item>
				<title>Algorithms: Good Enough for Business Purposes</title>
				<link>http://www.pbell.com/index.cfm/2006/8/18/Algorithms-Good-Enough-for-Business-Purposes</link>
				<description>
				
				The first step to solving a problem is often deciding whether it is worth solving at all! We are often involved with the first proper e-commerce store for a lot of small merchants and when we start talking about shipping, pricing and discounting rules, we’d clearly need to write a sophisticated reasoning engine just to start to approximate the way they do business. We have one end client that actually builds and weighs the order before pricing shipping using common sense to select the right combination of boxes and shipping carrier to get the best price. And this is for $100-$300 retail orders where the shipping usually runs $5 to $25!
				 [More]
				</description>
				
				<category>E-commerce</category>
				
				<pubDate>Fri, 18 Aug 2006 10:37:00 -0400</pubDate>
				<guid>http://www.pbell.com/index.cfm/2006/8/18/Algorithms-Good-Enough-for-Business-Purposes</guid>
				
			</item>
			
		 	
			
			
			<item>
				<title>E-commerce options: Product Attributes vs. Master Products</title>
				<link>http://www.pbell.com/index.cfm/2006/8/18/Ecommerce-options-Product-Attributes-vs-Master-Products</link>
				<description>
				
				I&apos;m rebuilding my e-commerce functionality as part of the CF7 OO rewrite of the application generator. As part of this I&apos;m revisiting all of the patterns used to see if there are more elegant ways of creating flexible, reusable e-commerce functionality. This morning I have to rebuild my product optioning system and I though it was a good time to write a post to make a distinction between two separate but overlapping functions: product attributes and master products.
				 [More]
				</description>
				
				<category>E-commerce</category>
				
				<pubDate>Fri, 18 Aug 2006 09:40:00 -0400</pubDate>
				<guid>http://www.pbell.com/index.cfm/2006/8/18/Ecommerce-options-Product-Attributes-vs-Master-Products</guid>
				
			</item>
			
		 	
			
			
			<item>
				<title>Persisting Carts</title>
				<link>http://www.pbell.com/index.cfm/2006/7/16/Persisting-Carts</link>
				<description>
				
				If you want to support anything more than a single page commerce form or a catalog with a &quot;buy&quot; button next to each product, the first thing you need to add to the &lt;a href=&quot;http://www.pbell.com/index.cfm/2006/7/15/A-Simple-Catalog--Four-Flexible-Screens&quot;&gt;catalog&lt;/a&gt; is a cart. I tend to use persistent carts, treating a cart as a special type of order – one that hasn&apos;t been placed yet . . .
				 [More]
				</description>
				
				<category>E-commerce</category>
				
				<category>Design Patterns</category>
				
				<pubDate>Sun, 16 Jul 2006 16:51:00 -0400</pubDate>
				<guid>http://www.pbell.com/index.cfm/2006/7/16/Persisting-Carts</guid>
				
			</item>
			
		 	
			
			
			<item>
				<title>A Simple catalog: A Minimal Data Model</title>
				<link>http://www.pbell.com/index.cfm/2006/7/16/A-Simple-catalog-A-Minimal-Data-Model</link>
				<description>
				
				So, now I&apos;ve described my &lt;a href=&quot;http://www.pbell.com/index.cfm/2006/7/15/A-Simple-Catalog--Four-Flexible-Screens&quot;&gt;catalog screens&lt;/a&gt;, and &lt;a href=&quot;http://www.pbell.com/index.cfm/2006/7/16/Controlling-the-Catalog&quot;&gt;controller&lt;/a&gt; let&apos;s take a quick look at a basic data model for a green field catalog . . .
				 [More]
				</description>
				
				<category>E-commerce</category>
				
				<pubDate>Sun, 16 Jul 2006 15:13:00 -0400</pubDate>
				<guid>http://www.pbell.com/index.cfm/2006/7/16/A-Simple-catalog-A-Minimal-Data-Model</guid>
				
			</item>
			
		 	
			
			
			<item>
				<title>Controlling the Catalog</title>
				<link>http://www.pbell.com/index.cfm/2006/7/16/Controlling-the-Catalog</link>
				<description>
				
				So, I&apos;ve described the &lt;a href=&quot;http://www.pbell.com/index.cfm/2006/7/15/A-Simple-Catalog--Four-Flexible-Screens&quot;&gt;screens&lt;/a&gt; for a basic product catalog, but what about the controller API? How do I expose those screens? 

According to &lt;a href=&quot;http://www.loudthinking.com/&quot;&gt;DHH&apos;s&lt;/a&gt; recent &lt;a href=&quot;http://www.pbell.com/index.cfm/2006/7/14/Is-Web-Design-FUCD&quot;&gt;comments&lt;/a&gt;, I should simply expose CRU and D methods (/product/view/7 or /category/view/12). But I&apos;ve already decided that &lt;a href=&quot;http://www.pbell.com/index.cfm/2006/7/14/Verb-Hunting-Four-Just-Isnt-Enough&quot;&gt;four verbs don&apos;t a controller API make&lt;/a&gt;. So my biggest question is whether to expose my service objects and verbs or whether to add a &quot;feature facade&quot; . . .
				 [More]
				</description>
				
				<category>E-commerce</category>
				
				<category>Design Patterns</category>
				
				<pubDate>Sun, 16 Jul 2006 14:45:00 -0400</pubDate>
				<guid>http://www.pbell.com/index.cfm/2006/7/16/Controlling-the-Catalog</guid>
				
			</item>
			
		 	
			
			
			<item>
				<title>A Simple Catalog - Four Flexible Screens</title>
				<link>http://www.pbell.com/index.cfm/2006/7/15/A-Simple-Catalog--Four-Flexible-Screens</link>
				<description>
				
				I often break my e-commerce applications into three core e-commerce &quot;features&quot;- a catalog, a cart and a checkout system. The catalog is responsible for displaying products and can be used on its own for non-commerce projects or projects with third party &quot;buy&quot; buttons. The cart allows a user to create a list of products – whether for purchasing, future reference, or for printing out as a &quot;pick list&quot; (perhaps along with a coupon) for in-store purchases, and the checkout handles everything from B2B purchase orders to Paypal, COD and credit card orders – including optional shipping, discounting and online gift certificates.

The simplest comprehensive model I&apos;ve been able to come up with for a catalog is four screens: category detail, product detail, search product list and cross sell product list . . .
				 [More]
				</description>
				
				<category>E-commerce</category>
				
				<pubDate>Sat, 15 Jul 2006 20:10:00 -0400</pubDate>
				<guid>http://www.pbell.com/index.cfm/2006/7/15/A-Simple-Catalog--Four-Flexible-Screens</guid>
				
			</item>
			
		 	
			</channel></rss>
	

