Home arrow Practices arrow Page 4 - Developing an Object Oriented Credit Card Transaction Processor

Digging In - Practices

This article will walk readers through the process of outlining a flexible Object Oriented design that will facilitate adding Merchant Services and Payment Methods in the future without affecting the client code.

  1. Developing an Object Oriented Credit Card Transaction Processor
  2. Principles
  3. Approaching the Problem
  4. Digging In
  5. Factory Work
  6. Conclusion
By: David Fells
Rating: starstarstarstarstar / 25
September 21, 2004

print this article



Now that we have completed our introductory analysis, it's time to get to the meat and potatoes of this discussion. We need to solve for our objectives, so the first thing that should be established is a rough idea of how the client should interact with the object that will complete an ETF. Keep in mind that we want to hide implementation from the client entirely; the client should not have to perform a series of operations to have our object process an ETF on its behalf. Let's look at a rough class definition:

public class ETFTransaction {
 bool Execute();

Simple enough, right? Obviously this object will need some data to work with, so our next problem is to determine a flexible way to give that data to the ETFTransaction object. The data that the object would need could be summarized as: Customer Billing Information, Customer Shipping Information, and Information that is specific to our Payment Method. We want to be able to add Payment Methods as our system expands, so we should avoid looking at specific class implementations for any one Payment Method. Let's define the following class:

public class ETFPaymentMethod {
 string* _servicename;
 Address* ShipToAddress;
 Address* BillToAddress;

This class will act as a token of sorts. It will be created by the client and passed to the ETFTransaction when it requires an ETF. The Address class that you see in the definition is a simple object that behaves as a data container for address information. It will also contain the customer name. This class defines our interface for the ETFPaymentMethod object. We would inherit from this class to build specific Payment Methods, such as CreditCard:ETFPaymentMethod, VirtualCheck:ETFPaymentMethod, and so on. Each one would have additional data stored in the object. This data would be collected from a form in the checkout process or registration process on the client website and passed to the ETFPaymentObject.

How does the client know what Payment Methods it supports and which one to use? I do not wish to get too far into the clientside implementation of this design, but to answer that question, we could create a registry of values either in a database or a flat file that is accessed by our client script and used to populate some data structure representing the available Payment Methods and what information needs to be collected in a form. For the case in point, my choice was to create an object that built a composite data structure representing the Payment Methods that were stored in the database. This structure also represented the data that was specific to the payment method (for a credit card, for example, the card number, expiration data, and cvv2 code).

Since we have defined an object to represent our Payment Method, let's expand our definition of the ETFTransaction class:

public class ETFTransaction {
 bool Execute();
 ETFPaymentMethod* _pm;

We have now defined how the client will initiate and execute an ETF using the ETFTransaction object... but how will the ETFTransaction object process these miscellaneous Payment Methods for an arbitrary number of Merchants? And how will we let the object discover what Payment Methods are supported by which Merchants without hard coding? Read on.

>>> More Practices Articles          >>> More By David Fells

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Calculating Development Project Costs
- More Techniques for Finding Things
- Finding Things
- Finishing the System`s Outlines
- The System in So Many Words
- Basic Data Types and Calculations
- What`s the Address? Pointers
- Design with ArgoUML
- Pragmatic Guidelines: Diagrams That Work
- Five-Step UML: OOAD for Short Attention Span...
- Five-Step UML: OOAD for Short Attention Span...
- Introducing UML: Object-Oriented Analysis an...
- Class and Object Diagrams
- Class Relationships
- Classes

Developer Shed Affiliates


Dev Shed Tutorial Topics: