Introduction

Getting paid is an essential part of conducting business on the web, yet this aspect is often overlooked by online merchants. For a satisfactory customer experience, and financial success of the e-business initiative, it is critical to have a properly functioning payment system to collect money.

The participants in an electronic payment system include

• Payers and payees
• Banks or financial institutions to hold accounts for payers and payees
• Third party non-banking financial institutions to provide payment services
• Financial networks to interconnect banks with each other and with third-party non-bank financial institutions.

Back to top

Online Payment Processing

Credit cards are used most commonly for payment with online retail stores. The typical sequence of events in an online credit card transaction are:

1. A customer initiates the transaction by entering credit card and other information on a Web-based online order form and submits it for transmission to the merchant's Web server over the Internet. The transmission of the customer's credit card information should be secured.
2. If the merchant is set up to authorize transactions in real-time mode, the information is sent from the merchant's Web server to the acquiring bank or its third-party processor by the merchant's payment processing software, or through the outsourced gateway provider.
3. The card-issuing bank either approves or disapproves the transaction based on the status and limitations of the customer's account. If the transaction is approved, an approval code and reference number is transmitted back through the credit card network to the acquiring bank and then back to the merchant.
4. An authorization message is displayed on the payment page for the benefit of the customer.

Besides credit cards, other payment types include debit cards, stored-value cards, telephone based systems, loyalty systems, e-checks, e-cash, Automated Clearing House (ACH), Financial Electronic Data Interchange (FEDI), Electronic Funds Transfer (EFT) or wire transfer.

Back to top

Integrating payment processing into Go-ForIt

Payment processing was introduced into Go-ForIt in a user story. (Go-ForIt user stories define tasks, concepts, and terms used in the project.) The story required that users get billed US$50 when they register. There are many payment processing options available (for details on these, see this related article). Factors that influenced our decision were:

• The expected transaction volume was not too high, with a value per transaction of US$50.
• We provided a service rather than a product. Should we find fraudulent data, the service could be revoked with minimal cost to us.
• The IBM payment processing software was freely available (to us).

The combination of factors prompted us to choose the IBM WebSphere Payment Manager. Our integration efforts would be fairly limited, in that we only had to send the appropriate information to the Payment Manager and have it process the transaction.

Back to top

IBM WebSphere Payment Manager

IBM WebSphere Payment Manager provides a generic framework for managing multiple payment systems while presenting a single interface to users. Figure 1 below shows the Payment Manager architecture.

Payment Manager uses plug-in software called payment cassettes to support a single payment system. Payment Manager routes the incoming payment requests to the specific cassette, and responses are neutral to the payment system. This allows new cassettes to be added to the system with no or minimal changes to existing integration software. Cassettes can be developed by IBM or by third parties. Payment Manager includes two cassettes called CustomOffline and OnlineCard. Other cassettes available from IBM are: SET, CyberCash and BankServACH. Cassettes are described in detail in this related article).

Merchant software issues administration, payment, and query commands to the Payment Manager, consisting of keyword-value pairs. Commands are executed by issuing requests and waiting for responses. Payment Manager requests are formatted as HTTP POST messages, and responses are XML documents embedded in HTTP. Because the interface uses HTTP and XML standards, it is possible to invoke Payment Manager commands from a variety of programming languages.

For merchant software written in the Java programming language, Payment Manager has a Java client API library (CAL) that provides a Java programming interface to issue commands to, and get responses from, Payment Manager. CAL provides a wrapper that shields the merchant software developer from having to understand the details of HTTP communication and XML document parsing, making it easy to integrate merchant software with Payment Manager. CAL provides Java objects that allow a merchant program to create requests to be sent to Payment Manager, communicate with Payment Manager over a TCP or SSL connection, and process responses from Payment Manager.

Payment Manager provides a Java-based library of functions called the Cashier. Cashier is invoked by client applications, such as merchant software, to simplify the creation of Payment Manager orders and payments. The Cashier also uses the CAL to send AcceptPayment and ReceivePayment commands to Payment Manager. The Cashier uses XML documents called profiles that describe how orders should be created for a given cassette, allowing the merchant software developer to integrate with Payment Manager in a generic way rather than writing code to deal with cassette-specific information.

Through the use of realms, Payment Manager authenticates users. A realm is a registry of users and a single method of authenticating those users, which can be user's name and password. Examples of realm types include LDAP and operating system realms. A user must be defined in a realm before being granted access to resources.

Payment Manager also provides an event notification mechanism. Supported event triggers include

• Starting or stopping of Payment Manager and its cassettes
• Change in status of orders belonging to a given merchant
• Special events defined by particular cassettes.

When the event is triggered, Payment Manager will create an HTTP POST message and send it to the specified URL. A servlet or CGI program called event listener should be written to process event notifications.

Back to top

Go-ForIt payment processing architecture

Because we were not going to establish a real-time connection with any financial networks to process our payments, we used the Offline cassette with Payment Manager. The Offline cassette enables the reading of card transaction details without being connected to a financial processing network.

The architecture and process we chose are described in Figure 2 below.

The numbers in this figure represent tasks, as follows:

1. When new users register on the Go-ForIt Web site they're taken to a form to be filled out. Users complete the form and submit it to the Go-ForIt server, which processes it. Before the form is sent through to the server, JavaScript is used to validate the credit card field (to ensure the field is the required length, type, and so on).
2. The registration process is then initiated, and the credit card information (name, card type, card number) is passed to the payment server. This passing of information is labeled as a service in Figure 2.
3. The payment server processes the request and may come back with either a success or failure. Again, the passing of this information is labeled as a service in Figure 2.
4. If the request was successful, it will continue the rest of the subprocesses to complete the registration, such as committing user information to the database. If the credit card processing fails, none of the subprocesses are attempted. Instead, we redisplay the registration page with the user input and an appropriate error message.
5. If all goes well, users are presented with the main menu page.

Our challenge was how to make the call and pass data to another independent system (IBM Payment Manager). The remote system had to execute a process and return data to the calling system. This is a typical enterprise application integration issue and there are many obvious solutions. An influencing factor, which we made up, was that the Go-ForIt.com business did not want to invest much resource in setting up a payment subsystem. Our preference would be to outsource it. For now, and for illustrative purposes, we undertook this exercise. Many retailers have the same situation -- they'd rather focus on their core competencies of selling and outsource other tasks, provided it makes economic sense.

Some of the alternatives we considered were:

• Place all the software on the same machines; local calls would make integration simpler
• Use MQSeries
• Forward users to another URL to process the transaction then return them to the Go-ForIt Web site
• Use Simple Object Access Protocol (SOAP)/Web services

The first alternative really wasn't an option for us. We could not put all the software on one machine because we had recently migrated Go-ForIt.com to WebSphere 4.0, and IBM WebSphere Payment Manager is only supported on WebSphere 3.5. MQSeries would have provided a very robust, reliable, and secure solution. The third alternative looked to be messy. For illustrative purposes, and to explore the hype around SOAP, we decided on a SOAP-based service to integrate Payment Manager and Go-ForIt.com.

Back to top

SOAP

SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is XML based, with three parts: an envelope that defines a framework for describing what is in a message and how to process it; a set of encoding rules for expressing instances of application-defined datatypes; and a convention for representing remote procedure calls and responses. SOAP had all the attributes we needed to solve our problem.

To begin, we broke the problem down into three parts. We had to:

1. Set up the IBM Payment Server and have an application that would take the parameters we passed to it and process the transaction.
2. Create a client application on the Go-ForIt.com server that would create the SOAP request and pass it to the Payment Manager.
3. Ensure all the SOAP plumbing was available inbetween to carry the request over and return a response.

Back to top

On the IBM Payment server

On the server side we had to have an application that would take the parameters we passed to it (card number, name, expiration date) and forward them to the payment server. The payment server would then process the transaction and produce a return code, which would be forwarded to the calling application. To write this application meant we needed to understand in some detail how Payment Manager worked.

Link here to the application code for our project.

We hard-coded all the static variables. (It would be better programming practice to put them in a properties file that could be read in and changed without the need to recompile the software.) Ours is a simple Java application that uses a number of the Payment Manager classes. It can be run and tested standalone from the Payment Manager server.

This application did not have to be aware that it was going to be called remotely; our architecture lets the SOAP server take care of all those details. Apart from setting up Payment Manager, configuring it, and writing this small application, we didn't have to do anything else on the Payment Manager software.

Back to top

On the Go-ForIt server

Part 13 of this DragonSlaying series described how we used command patterns to enhance performance. The command pattern lets you encapsulate the request as an object, and the resulting request object can be stored or passed around. The Go-ForIt.com application uses commands to let the UI objects make requests to the back-end without knowing the what, how, and why of the controller objects or EJBs it needs to talk to. For this reason we developed commands for all possible user functions. We identified commands by having a concrete command class for every user-level function.

Figure 3 below is the sequence diagram that is fully explained in the article about command patterns.

Because of this approach, we could plug in the call to charge the credit card without making any changes to most of the front-end components of the application.

Figure 4 below shows the existing application components in black and the additions in red.

The following code examples show the steps that take us to the calling application. First the registration servlet calls the UserRegistersCommandBean.

	UserDataBean user = new UserDataBean();
	UserRegistersCommandBean dataCommand = new UserRegistersCommandBean();
	:
	:
	DataCommand.setUser(user);
	dataCommand.execute(); 

The UserRegistersCommandBean has a registerUser method that runs a number of checks before committing the user to the database.

	:
	try {
		_userControllerHome = getUserControllerHome();
	 	UserController	userController = _userControllerHome.create();
		userController.registerUser(_user);
		} catch (java.rmi.RemoteException e) {

		// Catch exceptions and handle appropriately
		

The CreditCard Validation method is one of the checks that the registerUser method calls.

		:
	public void registerUser(com.goforit.user.UserDataBean user) throws 
		com.goforit.exception.DuplicateUserException, 
		com.goforit.exception.CreditCardNotAuthorizedException, 
		com.goforit.exception.InvalidCreditCardNumberException, 
		java.rmi.RemoteException {

	// Validate credit card info
	CreditCardValidation.validate(user);

	try {
		_userHome.create(user);
	} catch (CreateException e) {
		throw new com.goforit.exception.DuplicateUserException();
	} catch (Exception e) {
		throw new java.rmi.RemoteException(e.toString());
	}
}		

The CreditCardValidation subsystem does a number of checks to verify the card is valid and now contains the method, chargeCC(), to charge the card.

	public static void validate(UserDataBean user)
		throws
			com.goforit.exception.CreditCardNotAuthorizedException,
			com.goforit.exception.InvalidCreditCardNumberException {
			
		String ccNumber = deBlank(user.getCcnum());
		validateNumberFormat(ccNumber);
		validatePrefixAndLength(ccNumber, user.getCctype());
		validateChecksum(ccNumber);
		authorizeTransaction(user);
		chargeCC(user);

	}	

To "construct" the SOAP envelope and make the remote call, chargeCC() has to:

• Identify, or provide a means to identify, the location of the SOAP server
• Specify the method name that is going to be called
• Provide the list of parameters
• Invoke the method
• Handle exceptions

So, all of the programming for SOAP is on the client that makes the remote method call. All the other application components are unaware that a remote call was made. The invocation of the remote method with the associated parameters is the responsibility of the infrastructure.

Back to top

Summary

Integrating Payment Manager into the GoForIt.com project required us to have an understanding of online payment systems. We described the flow of control from the user inputting data into the form to the method that makes the actual SOAP call. We also discussed the Java application required on the Payment Manager.

Back to top

Stay tuned...

The next installment of the Go-ForIt chronicles will discuss how to secure form input using SSL, and will demonstrate how to set up the SOAP infrastructure to support the integration of Payment Manager into Go-ForIt. To see the previous articles in our tale of dragonslaying, go to our overview.

Resources

• Participate in the discussion forum.
  
  
• Understand your choices for electronic payment processing.
  
  
• Learn more about IBM Payment Processing from this WebSphere Commerce site.
  
  
• Access the Payment Manager documentation.
  
  
• Find all sorts of information on all the cassettes available for WebSphere Payment Manager.
  
  
• Download WebSphere Payment Manager cassettes (no charge, but registration is required).
  
  
• Explore the Payment Manager Cassette Developer Toolkits (no charge, but registration is required).
  
  
• Find more information on SET on the Secure Electronic Transaction LLC site.
  
  
• Read Netscape's SSL specification.
  
  
• Read the Transport Layer Security (TLS) IETF Internet-Draft.
  
  

About the authors

Indran Naick is an e-business Architect for IBM Developer Relations Technical Consulting in Austin, Texas, which provides education, enablement,and consulting to IBM business partners. Indran has over 14 years of industry experience. He joined IBM in South Africa in 1990. Prior to transferring to Austin, Texas he served as a Software Solutions Architect consulting to a number of financial and government institutions. He has authored a number of publications and is a graduate of the University of the Witwatersrand in South Africa. He can be reached at indrann@us.ibm.com.

Reema Gupta is an e-business Architect for IBM Developer Relations Technical Consulting in Austin, Texas, which provides education, enablement, and consulting to IBM business partners. She has held various e-business architecture and software development positions in her 7-year career with IBM and GE Capital Information Technology Solutions. She is an IBM Certified e-business Solution Designer, IBM Certified e-business Solution Technologist, and IBM Certified Specialist -- WebSphere Commerce Suite. You can contact Reema at reema@us.ibm.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Online Payment Processing
• Integrating payment processing into Go-ForIt
• IBM WebSphere Payment Manager
• Go-ForIt payment processing architecture
• SOAP
• On the IBM Payment server
• On the Go-ForIt server
• Summary
• Stay tuned...
• Resources
• About the authors
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community