Introduction

I was presented with the problem recently of extending an e-commerce product that my company had developed to support an arbitrary number of merchant services and transaction types with minimal changes to the client (in this case the client would be the script that is requesting a credit card transaction, not the end user of the website). The intent of this article is to walk readers through the process of outlining a flexible Object Oriented design that will facilitate the following objectives:

1. Allow for future addition of Merchant Services without affecting the client code.
   
   
2. Allow for future addition of Payment Methods without affecting the client code.
   
   
3. Allow for administrators to select different Merchant Services in real time without requiring hard coding the client.

Before continuing I would like to define a few of the terms used in these three objectives. We will define "Merchant Service" as a provider of Electronic Funds Transfers (ETF) such as Verisign, Authorizenet, and LinkPoint. We will define "Payment Method" or "Transaction Method" as a type of EFT, such as Credit Card, Electronic Debit, or Virtual Check.

This article will go through the process of creating this architecture. I will avoid providing actual code as much as possible, because the implementation of this architecture can vary independently of the design, thus providing code samples to perform "Task Y" will not be the focus of this article. Rather, we will examine some of the more important points in Object Oriented design and apply them to our set of objectives. A note before we begin, the example class definitions will be given in C++, as it's fairly neutral and has superior object constructs compared to PHP (which was the language in which this system was developed).