e-commerce Payment Solutions Implementation and Integration

(1)

e-commerce Payment Solutions

Implementation and Integration

Using IBM WebSphere Payment Manager

Bill Moore

John Fisher-Smith

Terry Hudson

Jose Novillo

Reto Sigl

Planning and installing payment

solutions

Integration with payment

protocols

Payment Manager and

WebSphere Commerce Suite

(2)

(3)

e-commerce Payment Solutions

Implementation and Integration

Using IBM WebSphere Payment Manager

October 2001

(4)

First Edition (October 2001)

This edition applies to WebSphere Payment Manager Versions 2.2 and 2.2.1 for use with Windows NT, Windows 2000 Server, AIX, and Solaris.

Comments may be addressed to:

IBM Corporation, International Technical Support Organization Dept. HZ8 Building 662

P.O. Box 12195

Research Triangle Park, NC 27709-2195

When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the

Take Note! Before using this information and the product it supports, be sure to read the

(5)

Preface

This redbook describes the requirements for implementing e-commerce payment solutions in today’s dynamic Web environment. It provides guidance for

architects and developers who will use WebSphere Payment Manager as part of a full e-commerce payment solution.

We explain the role that WebSphere Payment Manager plays in an e-commerce solution and describe how to install and configure WebSphere Payment Manager to meet different requirements. We discuss how to integrate WebSphere

Payment Manager with SET and VisaNet using the cassette features provided. Further details are provided about the full range of available cassettes that allow WebSphere Payment Manager to interact in a standard way with many different payment protocols.

We examine the way in which WebSphere Payment Manager is used in WebSphere Commerce Suite to provide an integrated payment solution.

We then provide examples to show how WebSphere Payment Manager APIs can be used to customize the product, and give details of how to develop custom cassettes so that WebSphere Payment Manager can be used with different payment protocols.

The team that wrote this redbook

This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Raleigh Center.

Bill Moore is a WebSphere Specialist at the International Technical Support

Organization, Raleigh Center. He writes extensively and teaches IBM classes on WebSphere and related topics. Before joining the ITSO, Bill was a Senior AIM Consultant at the IBM Transarc lab in Sydney, Australia. He has 16 years of application development experience on a wide range of computing platforms and using many different coding languages. He holds a Master of Arts degree in English from the University of Waikato, in Hamilton, New Zealand. His current areas of expertise include the VisualAge family of application development tools, object-oriented programming and design, and e-business application

(12)

John Fisher-Smith is from QSI Payments Inc. whose head office is in Australia.

He has 20 years of experience in the IT field, first as a hardware Field Service Engineer and lately as a software Product Implementation Specialist. He holds a degree in Internet Computing from Griffith University in Brisbane, Australia. His areas of expertise include the designing and writing of e-commerce integration software for QSI and writing their associated manuals.

Terry Hudson is a Senior IT Specialist working for IBM in the UK. He has 12

years of IT experience working at IBM. A CICS application developer for nine years, he has worked on all major releases of CICS, specializing in CICS customization, SNA, CPI-C, X.400, X.500 and SMTP technologies. He has a Mathematics for Business Honours Degree from Middlesex University in London, England. He has been involved in a technical capacity with IBM e-commerce products and services for the past three years. His current responsibilities include pre-sales technical support for the IBM WebSphere Commerce Suite portfolio of software products across Europe, the Middle East, and Africa.

Jose Novillo is an IT Specialist in Spain. He has three years of experience in the

Web application development field. He holds a degree in Physics from Complutense University, Madrid. His current areas of expertise include Web publishing and development, payment transactions, and software

implementation. Before joining IBM he wrote extensively in computer magazines about the Internet and its use.

Reto Sigl is an IT Specialist in Switzerland. He has five years of experience in

the Technology Deployment and Research field. He holds a degree in economics from the University of Zurich, Switzerland. His areas of expertise include

business transformation, Lotus Notes migration, and Web-based software distribution.

(13)

The authors: John Fisher-Smith, Jose Novillo, Bill Moore, Reto Sigl, Terry Hudson

Thanks to the following people for their contributions to this project: Lance Bader Phil Kregor Christopher Meyer Robert Perry Jennifer Ricard David Soroka Mark Wainwright IBM Raleigh Melissa Polizzotto IBM Austin Scott Esposito IBM Poughkeepsie

(14)

David Jackson IBM Columbus Juan P Ferrandiz IBM Spain Dieter Roth IBM Germany Raymond Kwok Rob Pereen Sam Wong IBM Canada Angelo Scaccabarozzi IBM Italy

Notice

This publication is intended to help administrators and developers who work with WebSphere Payment Manager to provide payment solutions for e-commerce applications. The information in this publication is not intended as the specification of any programming interfaces that are provided by WebSphere Payment Manager. See the PUBLICATIONS section of the IBM Programming Announcement for WebSphere Payment Manager V2.2 for more information about what publications are considered to be product documentation.

IBM trademarks

The following terms are trademarks of the International Business Machines Corporation in the United States and/or other countries:

e (logo)® IBM ® AIX® CICS® DB2® DB2 Universal Database™ Home Director™

IBM Consumer Wallet™ IBM Payment Gateway™ IBM Payment Registry™ MQSeries® Net.Data® OS/400® Redbooks™ Redbooks Logo ™ RS/6000® S/390® SP™ VisualAge® WebSphere® Lotus® Lotus Notes®

(15)

Comments welcome

Your comments are important to us!

We want our IBM Redbooks to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at:

ibm.com/redbooks

Send your comments in an Internet note to: [email protected]

(16)

(17)

Chapter 1.

Introduction to payments

In the early years of the Internet, a Web site providing only information content by using text and low resolution graphics was considered enough to attract

customers. Millions of companies, institutions and individuals have published Web sites in the past years following this simple method. Today’s consumers expect more from a Web site than information on store opening times or pictures of staff and family. While consumers may still accept low resolution graphics, they demand more benefit when surfing the Internet. A visitor to a Web site will not look at travel fares without the possibility to book one, will not look at scenic images of his local golf course without the possibility to sign in to play, will not buy a digital camera without previously having a database compare its

functionality with others. A consumer will prefer the Web site that provides ease of use, so a company that publishes the Web content must enhance its

infrastructure and adjust its processes to fit this demand. It has to transform its Web sites into applications, store data on products and customers in databases, and personalize Web content to what the visitor expects. In order to address a worldwide customer community, with different languages and cultures, with different payment methods, with sometimes challenging network performance - the company needs assistance to build this infrastructure from a serious partner who is specialized in this area.

(18)

1.1 Our objectives

In this book we focus on how to establish and maintain a customer payment service based on WebSphere Payment Manager. Because your customer is most likely selling goods or services to its customers, we use the term merchant throughout the book. Building the infrastructure for the payment service allows the merchant to perform financial transactions between his customers and a financial institution.

1.1.1 Who should read this book

This book is designed for people who build and maintains a payment server for one or more merchants. We assume that you will use WebSphere Payment Manager as a key part of the payment solution.

After reading this book you should understand the concept of a payment server, be aware of the software that is required to establish a running environment, and have the ability to maintain the server for adding new merchants and defining administration roles. We also provide information on what other payment solutions are being offered and what kind of features are to be expected from upcoming e-commerce services.

1.1.2 How this book is structured

Each chapter of this book will introduce you to a component or related topic of WebSphere Payment Manager. It will guide you step by step through the tasks to be performed during installation or maintenance, with window where appropriate. Most chapters offer you the ability to test the merchant environment without the need to have live connectivity of a financial institution to the system. This makes it easy for you to simulate the complete merchant and bank environment, without having to use a production system.

In our installation routines we have the password set the same as the username. This is for ease of use in a test environment and should not be adopted in any production system.

(19)

1.1.3 Supported environment

Independent of what server operating system and what database products you have or prefer to run, we explain the most frequently used ones in detail: AIX, Windows NT, and Solaris at the operating system level, and DB/2 and Oracle at the database level. The book does not cover installation on Linux platforms, because WebSphere Payment Manager was not available on that operating system at the time we wrote this book.

Although some install variables are operating system dependent, the code of WebSphere Payment Manager relies on the pure Java programming language so that it operates in a similar manner on different platforms. Connectivity software used between the customer, merchant and financial institution is based on common security standards such as SSL (Secure Socket Layer) or SET (Secure Electronic Transaction).

The book provides instructions for setting up a split payment environment, where WebSphere Payment Manager runs on a different server from the database or the Web server. For merchants with large transaction volumes, this is the preferred way to build the infrastructure, because it gets the greatest performance out of the servers.

This book will not cover the aspects of installing and using WebSphere Payment Manager in an Application Service Provider (ASP) environment, where

merchants can sign up for a payment service. Although interactive signup to payment services might be the preferred way for merchants and has already been realized using WebSphere Payment Manager code, this concept is not detailed by our redbook.

1.2 Payment history

Paying for goods obtained by sell or trade is one of the oldest habits of mankind. Currency in the form of coins has been in use for more than 2000 years, and for at least 400 years ago that the value of money has been additionally measured on printed paper, known as bills.

1.2.1 Credit cards

Paying with coins and bills was not the end of currency evolution, since more than 50 years ago credit cards were introduced. Instead of having to pay with bills and coins, the customer could pay for goods and services by letting the merchant take an imprint of his card and compare the card holder’s signature on the receipt with the one on the back of the card. The money would then be

(20)

transferred from the customer’s financial account to the merchant. Today, over 200 million shops, restaurants and organizations, mostly in industrial countries, accept those credit cards as a valid payment method between the customer and the merchant.

The bank may decide which credit card brands it wants to offer to their

customers. The credit card can only be used, if there is debit on the buyer’s bank account. While in earlier days a print of the card was taken and later sent for verification to the payment institution, today’s merchants have validation machines that check the customer’s liquidity over phone lines before the purchase is being accepted. Signing the receipt for every payment and having the merchant compare it with the signature on the back of the card is still the commonly used verification method. Nevertheless some banks now print a picture of the card holder on the credit card as an additional verification method.

1.2.2 Internet payment

As the Internet became more and more popular in the major industrial countries for connecting companies and governments to each other within a permanent worldwide communication network, it was extended to allow individuals at home to use the network for their convenience. For some, the Internet had the image of the open and free world, when everything was available for free and Web sites were mainly used to publicize companies and products.

Early adopters of the Internet were often financially well off, and companies soon realized that there was money to be made on the Web. The Internet began to be used as a carrier for performing financial transactions. Customers could pay for goods and services through the Internet, and they did not have to leave their home or office in order to complete their purchases. Customers can purchase more goods in less time. Web sites are online 24 hours and accessible through a Web browser from all over the world, and customers can pay for goods whenever and wherever they want.

As more financial transactions were performed online, payment methods were required and credit cards seemed to be the best solution to authenticate a customer and check his or her bank balance. Instead of presenting the credit card to a sales person in a shop, the customer provided a credit card number and expiration date to a Web site. The buyer’s payment capability is then either checked automatically and confirmed by the financial institution, or can be validated at a later time. By 2003, 10% of the overall credit card payment volume is expected to be done through the Internet.

(21)

1.3 Positioning online payment solutions

Almost every institution that sells goods and services can use the payment capabilities of the Internet as an additional or primary way of selling their products to customers.

Merchants often use the Internet to reach a wider customer community, instead of only selling their goods locally in a store. Offering their goods and services online has also had advantages for the merchants, since they don’t have to maintain office space or pay staff to take care of their sales business and financial transactions. In many cases it is cheaper to rent or buy server space and run an online shop, instead of renting office space to sell the goods.

Today, many large businesses are starting to sell their goods online. As a result, online payments made on the Web are increasing rapidly from year to year and the number of online shops on the Web is increasing at a similar rate. Large companies are finding an advantage in migrating their selling online, and small and medium businesses find that they can reach out for more customers on the Internet.

1.3.1 Payment service provider is key

For both the merchant and the customer, payment is a key element of selling and buying. A Web site can be fancy or not, the text can be in any language, the range of credit cards to be supported can be small or large, but the electronic transaction between merchant, bank, and customer must always be the same: reliant, secure and fast. So the greatest demand of merchants and buyers is having the best partner providing the payment software, which is the heart of every transaction.

1.4 Security

The primary issue of the buyer and the merchant is security. Transactions must be as secure as possible, and it is important to understand who takes the risk with Internet payments.

Credit cards are a valuable possession for many people. The card number, expiration date and the signature are the important things that control access to the buyer’s bank account.

Because the Internet still has a reputation as the open and free world,

uncertainty persists when buying goods online. The buyer does not see where the Web site is located, what people are behind the bits and bytes, or by whom

(22)

Today, well-known merchants, payment software providers, credit card companies and banks are important in establishing the trust relationship that customers demand. The goal of all involved parties is to limit the risk of misuse of online payments to a minimum. New technologies reduce the risk, but still there is no 100% secure mechanism to avoid misuse of online payments. Stolen credit cards often give thieves the ability to use the card for online payments, since the card holder’s signature is not needed and address verification is not always implemented.

Technologies for improving security

New online payment systems additionally ask for the card holder’s street address and zip code, information that is not provided on the card but can be checked during validation of the bank account with the buyer’s bank. Secure Electronic Transaction (SET) local certificates ensure that only the buyer’s computer is authorized for electronic payments on the Web. Upcoming new digital certificates on computers and mobile devices will ensure even better security. Computer mice which scan and validate your fingerprint before doing an electronic payment might also become a standard in future. While an iris scan of your eye might still be limited to high-security military and government buildings, it might become a standard for secure authentication.

1.5 IBM WebSphere Payment Manager

WebSphere Payment Manager provides merchants a secure, reliable and fast solution to perform online payments. WebSphere Payment Manager provides a: Complete Web shop solution integrated in WebSphere Commerce Suite. A stand-alone version that can be built into the merchant’s existing payment

environment of Web servers, Web shops, and database servers. An Application Service Provider environment (not covered in this book). Many banks use IBM payment solutions on their infrastructure, and merchants trust WebSphere Payment Manager because it is fully compatible and scalable with the bank’s infrastructure and can be seamlessly integrated into their financial environment without writing additional application code.

1.5.1 Content

WebSphere Payment Manager provides the payment server software, but also the following products that make it easier for you to build the merchant’s infrastructure environment:

(23)

WebSphere Application Server, Advanced Edition IBM Universal DataBase (UDB)

Cassette support for SET (Secure Electronic Transaction) and CyberCash

1.5.2 Functionality

WebSphere Payment Manager has a Web-based front end that is used for payment server administration as well as by the hosted merchants for merchant administration. The front end can be easily accessed remotely through any industry-standard browser. As the server administrator, you can define users and their roles with access to the payment server. You also have the ability to adjust the layout of the Web interface to reflect the customer’s corporate requirements. For each merchant and transaction method, administrators can define whether orders should be automatically processed by the payment server and routed to the financial institution for validation, or if each order requires manual approval from the merchant. This decision often depends on how many transactions are expected to be processed each day.

WebSphere Payment Manager can also be used by merchants who don’t need interaction with a financial institution at all, but want to use offline transaction procession capabilities. For example, a local supermarket could use offline payment methods to allow customers to choose the desired goods online, but pick them up and pay for them when visiting the local shop.

(24)

Worldwide service

WebSphere Payment Manager is designed to be used worldwide as payment server software. The interface can be translated into any language that is supported by the administrators Web browser. The payments are accepted in multiple currencies.

The transaction software called cassettes might sometimes be restricted to certain geographies or regions. Please consult your financial institution or cassette provider to assure they cover your needs.

(25)

Chapter 2.

Payment solutions

This chapter positions the many general aspects of payment processing that are being discussed in the Internet world today. We also discuss the internal

architecture of the WebSphere Payment Manager product and how the product helps in payment solutions

(26)

2.1 Future payments

A well-known IBM advertisement shows a man being filmed by security guards in a grocery store, carefully placing goods in the inside of his coat, until he has no more room to add anything else. The security guards keep an eye on his every movement. He then attempts to walk out of the store through a walkthrough system similar to the metal detectors in airport security areas. A security guard quickly chases after the man and taps him on the shoulder only to say “Sir, you have forgotten your receipt”.

Technology had managed to read the bar codes on the goods inside the man’s coat and pay for them using the payment details on his person.

While this vision of the future may seem fanciful, it does represent an example of how quickly the requirements for payment solutions are changing in order to meet the demands of new technology and new ways of doing business.

In this chapter we detail some of the requirements expected of payment solutions and position WebSphere Payment Manager in relation to these requirements.

2.1.1 Wireless payments

Payments involving initiation or confirmation of a payment transaction using a wireless device are known as wireless payments.

Imagine using your cell phone or PDA to pay for goods when and where you want. For example, you reach a drink vending machine in the street. You want to purchase a drink but you have no money on you at the time. You do, however, have your cell phone with you so you call the drink machine on your cell phone and pay for a can of drink using the information on your cell phone, either prepaid or via your own Internet bank account.

This concept of being able to buy whenever or whereever you are is fast becoming reality.

At the time of writing this book, Nokia, the world leader in Mobile communications, announced a collaboration with IBM, Luottokunta, and Radiolinja to jointly pilot secure credit card payments by using a mobile phone with a wallet application contained in the phone itself. The intention of the parties involved is to demonstrate their commitment to the mobile wallet concept and Wireless Identity Module WIM) technology. IBM WebSphere Commerce Suite and Payment Manager technology will be used in the pilot. For more information on the project, please refer to

(27)

For more information on the Nokia wallet phone, please see: http://www.nokia.com/phones/6310/wallet.html.

The following URL is an IBM white paper on wireless payments, which discusses the concept and reality of wireless payments in more detail:

http://www.ibm.com/pvc/tech/pdf/Pvwee02.pdf

2.2 Emerging payment challenges

As electronic commerce becomes more prevalent in all types of industries, the payments model for electronic commerce becomes more complex. Challenges in supporting payments in the Business-to-Business(B2B) model will require payment processing for methods other than credit or debit cards. In addition, as the Business-to-Consumer (B2C) commerce model progresses, further complex requirements will be made on the payments software of the future. The following sections outline real-life payments scenarios that will inevitably require electronic payments solutions in any payment system of the future.

Purchase orders

Almost all businesses in the worldwide marketplace use purchase orders in some fashion. Purchase orders are a complex area when dealing with authorization for payment. They frequently have a total amount restriction per order, in addition to the same restriction over a period of time (for example, a customer may be allowed to purchase only 2000 units of currency over six months). In addition to limit restrictions, purchase orders often require some kind of sign-off/signature by, for example, the manager of a group. These features of purchase orders bring new challenges when the ideas are placed in the electronic commerce world. For example:

The payment processor would be required to keep track of the organizations’ orders and enforce the time/amount restrictions of the purchase orders. Some way of documenting the signature would be required (maybe through

assigning certificates to a purchase order for instance).

Decisions would have to be made whether these features were supported in a payments architecture or whether these features should be dealt with by an accounting system and have that system link closely with a payments system.

(28)

Manufacturers’ coupons

As retail shopping, especially large supermarket grocery shopping, becomes more widely used on the Internet, consumers buying their grocery goods over the Web will demand the same features offered to them in the store. At most supermarket stores you can use manufacturers’’ coupons to discount the amount you pay, provided that you have purchased the manufacturers’ goods. The coupons often have an expiration date.

Support of these features implies that the payment system will be required to be have knowledge of the contents of the shopping basket being processed so that the coupons can be authorized and redeemed for payment.

Deferred credit

Buy-now, pay-later offers are widely seen throughout the retail sector. There is no reason why merchants/manufacturers wouldn’t also want to offer this kind of feature with Internet-based purchases. Details of credit or debit cards, and direct debits would need to be collected by the commerce store, and a method of indicating to the payment system that the purchase is a deferred credit purchase would be required. Decisions on where the order would lie dormant (until the deferred credit period had expired) would need to made. Would the e-commerce system hold the information? Probably not, since the merchant would require some form of authorization check on the consumer’s payment details before the goods were released to the customer. Other options are the merchant payment system (most likely to be given the responsibility) or the back-end financial institution.

Multiple payments installments

Again, most retail stores offer some kind of multi-payment features to their consumers, for example buy this washing machine in three installments. The feature is sometimes given some kind of price premium reflecting any interest charges. The consumer also usually has the choice of when the regular amount is drawn from their accounts. On occasions where interest-free payments are offered, these can also sometimes incur additional charges if the final amount is not deposited to the merchant by a given time.

The challenge here for the payment system will be similar to that raised for deferred payments: how does the payment system keep track of the regular payments and notify the merchant/consumer of any failures?

(29)

2.3 Payment Manager solutions

Chapter 8, “Customization using the payment API” on page 211 discusses the details on how WebSphere Commerce Suite V5.1 integrates with WebSphere Payment Manager V2.2.

WebSphere Payment Manager 2.2 also integrates into the WebSphere

Commerce Suite, Marketplace Edition. A white paper is available on the Web that discusses the details of how to do this. It can be found at:

http://www-4.ibm.com/software/webservers/commerce/epit/reports.html

2.3.1 Integration considerations when using Payment Manager

You can also integrate Payment Manager into any front-end system that requires a generic payments framework.

One example is the process of collecting registration or subscription fees via users credit card details.

Note: This does necessarily imply that you would need an e-commerce

application to create a shopping basket. In this case, Payment Manager could be integrated into a set of static HTML pages using the Payment Manager API . The user could enter any user-specific information on pages prior to the pay/buy or checkout page.

At the checkout page your application could:

Show the amount to be paid and a description of the goods to be purchased. Detail any taxes that are relevant for the purchase.

Collect credit card information:

– Brand - You will need to limit the credit card brands you show to only those that are authorized within the Payment Manager cassette accounts. – Number - Simple verification checking on the value entered in this field is

also advisable, for example:

• Does what is specified by the consumer in this field contain (only) numeric values?

• Does the numeric value specified contain the required number of digits for the corresponding credit card brand?

(30)

The luhn check is a standard method of verifying credit card details when you only know the credit card brand and the supplied number. The check is based on an algorithm that determines if the credit card is valid without going to any back-end financial institution for further verification. If you decide to code the luhn check into your payment application, you can more readily reject credit cards that are invalid right away without incurring any possible charges associated with an approval attempt and subsequent rejection. Successful luhn checking of the number passed in the credit card field means that the number passed looks like a credit card (since all credit card numbers pass the check). However, it does not mean that the number is a valid credit card and is credit worthy. Only the card issuer can check this by Payment Manager passing the details on to the back-end financial institution. The full luhn check is derived from ISO 7812:1987(E) standard, Annex B. For more information on how to perform a luhn check, it is advisable to review the specification and check the Internet for already defined luhn validation algorithms. Since this is a common algorithm, you will find that lots of people have made the code for their luhn checking algorithms available on the Web.

– Expiration date - Verify the values before passing this information on to Payment Manager, for example:

• Is the month value numeric and between 1 and 12?

• Is the combination of month and year specified in the future? Collect the consumer’s e-mail address and validate. Simple user@domain

checking would probably suffice. Traditionally this information is used to inform the purchaser of the status of their order (successful or otherwise). The owner may also choose to display their logo and any terms and

conditions that may be associated with the purchase.

If the owner has decided to support SET as a payment protocol you may also want to provide the following:

– Instructions on how to obtain a valid certificate for the purchase. – A button to pay by using a SET wallet, in addition to a pay-now option.

This would enable the owner to collect payment information via a SET wallet as well as by entering credit card details on the Web page.

– You may also decide that you will accept SET wallet purchases without a certificate enabling the consumer to use the pre-fill function ofSET wallet software.

When collecting this type of sensitive information, the page must be displayed using the HTTPS interface.

(31)

Payment Manager also provides support for collecting the security codes usually displayed on the signature side of most credit cards. The information is not embossed, so it does not appear on credit card receipts. By collecting this information, the owner of the site would be reducing the risk of someone using the stolen credit card details from a paper receipt. If you know the security code, the chances are that you are physically holding the credit card. This does not, however, protect against a stolen card, but does give an extra measure of protection.

The designer of the checkout area may also want to look at making the area Electronic commerce modelling language (ECML) compliant.

ECML is an attempt to make filling out a checkout area easier and more uniform across the Internet. It is estimated that over a quarter of all Internet-based sales are lost because the consumer didn’t fill out the checkout area, either because they found it too hard or because of the (personal) information they had to provide. Since the owner of a site is responsible for making it easy for users to fill in the payment details, it is advisable to look into the modeling language. For more information on ECML, see:

http://www.ecml.org

Once the information has been successfully obtained, simple verification checks have been performed, and any errors resolved, the information could be passed using the Payment Manager API AcceptPayment command. You also have to decide on your policy of automatically approving orders. You

may want to set up Payment Manager so that the full amount is automatically approved by the back-end financial institution. This would give the

merchant/owner an indication that the credit card was good and credit worthy. At this stage no money would have been drawn from the user’s credit card. If you were selling merchandise that the consumer needed to obtain, for instance by shipping the merchandise, you would also have to ensure that you complied with your country’s laws. In some countries it is unlawful to collect payment for goods that the consumer (or payer) has not received. Processing of a subscription, for example, may not be bound by this type of rule, so it may be possible to also set up automatic approval of the credit card payment.

After successfully creating an order, it is common for the consumer to receive some kind of notification (for example via e-mail) that the payment was successful or to detail any error situations that were encountered as part of the payment request.

(32)

For more information on using the Payment Manager API and the tools available in Payment Manager to help build payment application, please refer to the product manual IBM WebSphere Payment Manager for Multiplatforms Programmer’s Guide and Reference Version 2.2.

For more information on how customers have used the power and flexibility of IBM WebSphere Payment Manager in real-life business situations, please refer to some case studies at the following URL:

http://www.software.ibm.com/casestudies/swcs.nsf/swgsearch?SearchView&Query=Web Sphere+Payment+Manager

2.4 The Payment Manager internal architecture

The following discusses the high-level Payment Manager architecture made available in V2.2 of the product and how it fits with the other IBM products in an e-commerce software stack.

Payment Manager is designed to run as an application under WebSphere Application Server, which supplies the Payment Manager with the environment in which to run its Java Servlets as well as the mechanism for external

communications using HTTP requests (Payment Manager gives XML responses). The infrastructure uses IBM HTTP Server as its Web server and supports various database products, including DB2 UDB and Oracle.

The high-level architecture of WebSphere Payment Manager is shown in Figure 2-1.

Note: In payment rejection situations where, for example, the credit limit

has been reached and the approval fails, the back-end financial institution may or may not give the reason for the error.

The error code may just indicate that the payment failed and it would be up to the consumer to further investigate the reason for the failure with their card issuer. Clearly if the policy of the card issuer is to give out the

granularity of error detail (such as the limit has been reached) then it would be dependent on the back-end payment cassette used for the credit card brand to pass that detail back to the front end “store” application.

This is no different from purchasing goods using the phone and being told that the payment request has been rejected, and not being told the reason why.

(33)

Figure 2-1 A high-level view of the Payment Manager architecture The infrastructure is designed to:

Support multiple merchants who are all using the system at the same time, processing orders from their respective storefronts.

Enable service providers to integrate with their already existing merchant authentication environment using plug-in support.

Enable continuous availability while still allowing for: – Adding new merchants

– Authorizing merchants to use different payment protocols (cassettes)

Merchant Application Merchant Browser Administrator Browser UI Servlet Cassette Cassette Payment Servlet Query Engine Cassette Payment Engine Cassette Cassette Cassette IBM WebSphere Payment Manager Payment Manager DB2

(34)

– Changing the configuration by, for example, supporting new protocols and adding new cassettes to the framework

Provide a programmable API for extending and customizing the WebSphere Payment Manager infrastructure. An overview of the Payment Manager API is shown in Figure 2-2.

Figure 2-2 The Payment Manager API

The Payment Manager API

The API allows for flexible integration with merchant applications. Access to Payment Manager is handled by a payment servlet, and the merchant application uses the Payment API, which provides:

(35)

Function calls for: – Payment processing – Queries

– Administration

An HTTP interface for low-level programming A Java client library (CAL)

A 128-bit SSL client

For more information on the Payment Manager API, please refer to IBM WebSphere Payment Manager for Multiplatforms Programmer’s Guide and Reference Version 2.2.

The Payment Manager user interface

The Payment Manager user interface allows interactive access to almost all payment functions and parameters that are available using the API. XML responses to Payment Manager (HTTP) requests made through the user interface are displayed through the Payment Manager Presentation Language (PSPL). The UI is available to all levels of merchant as well as to the service provider (owner of the Payment Manager). Figure 2-3 shows the Payment Manager user interface.

(36)

Figure 2-3 The Payment Manager user interface

WebSphere Commerce Suite V5.1 also uses the Payment Manager user interface to manage orders and users as part of its Commerce Accelerator function. For more information on the integration of WebSphere Payment Manager with WebSphere Commerce Suite, refer to Chapter 7, “Integration with WebSphere Commerce Suite” on page 169. It is also possible to customize the look and feel of the user interface when using Commerce Suite.

The Payment Manager servlet is a Java servlet that runs under WebSphere Application Server, Advanced Edition V3.5 and acts as the communications layer between the Web server and the Payment Engine. Figure 2-4 shows details of the Payment Manager servlet.

(37)

Figure 2-4 The Payment Manager servlet The Payment Manager servlet:

Handles all API calls directly or through the UI servlet Interacts with Payment Engine

Interacts with the payment database though the Payment Manager Query Engine

Deals with all access control (access rights) whether through the UI or the API calls

All users have a (merchant-specific) role assigned that can be one of the following(in ascending order of authority):

(38)

– Clerk – Supervisor

– Merchant Administrator

– Payment Manager Administrator (Service provider)

Figure 2-5 The Payment Manager UI servlet

The UI servlet handles GUI access. All requests passed to the Payment servlet are passed via CAL methods.

Merchant Application Merchant Browser Administrator Browser UI Servlet Cassette Cassette Payment Servlet Query Engine Cassette Payment Engine Cassette Cassette Cassette IBM WebSphere Payment Manager Payment Manager DB2

(39)

The UI servlet, has one PSPL file with flags that points to a Java properties file that decides the look and feel of each page. This enables you to customize and brand the Payment Manager user interface according to your needs. The UI servlet is shown in Figure 2-5.

The Payment Engine

The Payment Engine is a Java-based application that provides the Payment Manager framework with the flexibility to support different protocols. It deals with the payment requests (that is the actual financial transactions) that are sent to Payment Manager for processing. The Payment Engine handles the framework interface to the cassettes and the Payment Manager database tables. Figure 2-6 shows the Payment Engine.

(40)

Figure 2-6 The Payment Engine

If you have used Payment Server V1.2, the Payment Engine can be directly accessed in compatibility mode.

For more information on the Payment Engine, please refer to the IBM

WebSphere Payment Manager for Multiplatforms Administrator’s Guide Version 2.2.

The Payment Manager Query Engine handles query API requests for viewing the database (for example Query orders). Once the information is obtained by the engine, the response is formatted into an XML document. This is shown in

(41)

Figure 2-7 The Query Engine

The Payment Manager database is a relational database that is used to store Payment Manager configuration (cassette configuration/authorization, etc.) and runtime data (that is, transactional information for example orders). Using supported JDBC drivers, it can reside on a different machine from Payment Manager if so desired. Figure 2-8 shows the database.

Merchant Application Merchant Browser Administrator Browser UI Servlet Cassette Cassette Payment Servlet Query Engine Cassette Payment Engine Cassette Cassette Cassette IBM WebSphere Payment Manager Payment Manager DB2

(42)

Figure 2-8 The Payment Manager database Merchant Application Merchant Browser Administrator Browser UI Servlet Cassette Cassette Payment Servlet Query Engine Cassette Payment Engine Cassette Cassette Cassette IBM WebSphere Payment Manager Payment Manager DB2

(43)

If you want to support multiple Payment Manager processing systems, then it is recommended that you split the ownership of merchants between the Payment Manager systems. For example, merchants from 1 to 100 are served by Payment Manager 1, 101 to 200 are served by Payment Manager 2, and so on. Figure 2-9 shows the recommended split when installing multiple Payment Managers.

Restriction: If you configure your Payment environment using multiple

servers Payment Manager V2.2 does not support the following: Two Payment Manager systems talking to one Payment Manager

database.

Two Payment Managers accepting orders from different (for example alternate) sources.

One order source (for example e-commerce system) sending to alternate Payment Managers: Order1 being sent to Payment Manager 1, Order 2 being sent to Payment Manager 2, Order 3 being sent to Payment Manager 1. This kind of flip-flop order processing is not supported in this current release.

Each Payment Manager environment requires its own database. You will see unpredictable results if more than one Payment Manager uses the same database.

(44)

Figure 2-9 Recommended Payment Manager database ownership

2.5 Capacity planning, scalability and performance

Capacity planning, scalability and performance using WebSphere Payment Manager V2.2 is discussed in a white paper available at:

http://www.ibm.com/software/webservers/commerce/payment/docs/paymgr22whitepaper .pdf 1 100 Merchants WPM1 101 200 Merchants WPM2 201 300 Merchants WPM3 DB2 PAYMAN1 DB2 PAYMAN3 DB2 PAYMAN2 DB2

(45)

Chapter 3.

Installation and

configuration

This chapter describes some common installation scenarios for WebSphere Payment Manager and discusses some optional but important tasks such as user management and SSL.

The scenarios cover the most common situations from a practical point of view. We have provided tips and critical steps for installation and configuration. We also have added checks at the end of each section.

This chapter is a complement to the official installation guides that ship with Payment Manager. It is not an exhaustive and detailed description of every possible install situation, but a source of advice and guidance.

This chapter contains the following: Installation planning and design Windows installation and configuration AIX installation and configuration

Sun Solaris installation and configuration Post-installation tasks

(46)

3.1 Installation planning and design

Planning is an important part of a successful WebSphere Payment Manager installation. Every installation should be properly planned and should consider the requirements for an installation in a development environment, a test environment and finally an implementation in the production environment. We describe our experiences while installing and configuring WebSphere Payment Manager in a number of common scenarios. We did our installations of WebSphere Payment Manager V2.2 in clean environments so we do not detail the issues involved in migration from older versions. Refer to the IBM WebSphere Payment Manager for Multiplatforms Install Guide Version 2.2. for details about migration from previous versions of the Payment Manager. Similarly if you intend to install WebSphere Commerce Suite on the same machine as Payment Manager, we suggest you refer to the IBM WebSphere Commerce Suite Installation Guide and to the WebSphere Commerce Suite V5.1 Handbook, SG24-6167.

When planning the installation of the main activities are:

1. Decide which operating system, database manager and HTTP server you are going to use. To install WebSphere Payment Manager, WebSphere

Application Server is required.

2. Ensure that the software versions you plan to use have been tested together and are official supported by the WebSphere Payment Manager product. 3. Decide if you want a 1, 2 or 3-tier architecture.

4. Prepare all the software, fixes, patches and information needed for the installation.

5. You may also wish to back up your systems before beginning installation.

3.1.1 Decide operating system, database manager and HTTP server

WebSphere Payment Manager put some restrictions on these products. Payment Manager requires WebSphere Application Server so the main restrictions are imposed by the need to use components that are supported by WebSphere Application Server. Depending on which version of WebSphere Application Server will you use, you will be able to choose between different database managers, HTTP servers and operating systems.

(47)

WebSphere Payment Manager supports and has been tested with WebSphere Application Server Versions 2.0.3.x through to 3.5.4. In all the scenarios we used WebSphere Application Server, Advanced Edition 3.5.4. We recommend that you do not use older versions of WebSphere Application Server, because they will not be supported with future releases of WebSphere Payment Manager. Keep the following restrictions in mind:

The operating system must be Windows NT/2000, AIX and Sun Solaris (only english, no other languages are supported),

The database manager should be DB2 or Oracle,

The HTTP server should be IBM HTTP Server, Apache server, Microsoft Internet Information server, iPlanet Web Server, Lotus Domino or Netscape Enterprise server.

3.1.2 Find out which versions are supported by the product

The prerequisite hardware and software requirements for WebSphere Payment Manager can be found in the IBM WebSphere Payment Manager for

Multiplatforms Install Guide Version 2.2.

The prerequisites for WebSphere Application Server Supported hardware and software can be found at:

http://ibm.com/software/webservers/appserv/doc/latest/prereq.html

In our test we use WebSphere Application Server V 3.5.4. We recommend that you not use the 3.5 base version; instead apply at least patch 1. It is also necessary to apply at least Fix Pack 1 to DB2 7.1.

We did test Payment Manager with DB2 Version 7.2 on the Windows platform and it worked without problems, but we did not do any stress testing. At the time we wrote this redbook, DB2 V7.2 was not officially supported with WebSphere Application Server, Advanced Edition V3.5.x and WebSphere Payment Manager V2.2, so we do not recommend that you use this combination in a production environment, until you have checked the official hardware and software

prerequisites. We used DB2 7.1 with Fix Pack 2 or 3 for most of the testing done in this redbook.

We used IBM HTTP Server V1.3.12, which ships with WebSphere Application Server, Advanced Edition V3.5, and this gets patched to V 1.3.12.3 when upgrading to WebSphere Application Server V3.5.4.

On the Solaris platform, we installed Oracle 8.1.7 as the database and iPlanet Enterprise Server 4.1 Service Pack 7 as the HTTP server.

(48)

As the operating systems, we used Windows NT SP4, Windows 2000 Server, AIX 4.3.3.0.08 and Sun Solaris 2.7 with some fixes.

3.1.3 Decide if you want a 1, 2 or 3-tier architecture

Depending on the volume of transactions and the existing environment, each tier structure has its pros and cons.

In every case, WebSphere Payment Manager must be installed along with WebSphere Application Server, but can use a remote database and a remote HTTP server. For more information on clustering and scalability of WebSphere refer to WebSphere Scalability: WLM and Clustering Using WebSphere Application Server Advanced Edition, SG24-6153, because the scalability of Payment Manager relies on WebSphere.

The 1-tier architecture is ideal for a small to medium number of transactions. It requires a stand-alone medium machine that is used only for WebSphere Payment Manager.

The great advantage of this architecture is its low initial cost. Also it is easy to escalate to cope with more transactions.

If the machine is used only to host payment services for several merchants, the more demanding application is WebSphere Application Server, since the HTTP server is a very light process and the database is accessed locally and only from Payment Manager.

As more transactions are processed, another machine can be added with the HTTP server, WebSphere Application Server and Payment Manager installed using a remote database (2-tier). To balance the load, a network dispatcher must be installed in a separate machine or in any of the WebSphere Application Server machines as shown in Figure 3-1 on page 33. The dispatcher can be used to split wisely the requests to the less busy WebSphere Application Server and provide almost twice the performance. This way, new machines can be added as needed.

(49)

Figure 3-1 Scalability from 1-tier to 2-tier architecture

The new machines at the same time will provide higher availability, but will be relying on the first machine, which has the database installed. To further improve the availability, the database should be kept in another machine and a backup replica of the database kept on a backup machine. The replica will only be in use when the main machine is down. As you see, high availability is expensive. At least four machines are needed.

There is a way to achieve high availability with only two machines, both of which should be highly scalable so that one can assume the load of the other. The architecture is a mix between1-tier and 2-tier. The method is to configure two machines identically and have those machines use mirror disks to access the data (RAID 1), as shown in Figure 3-2 on page 34. One of the nodes will act as the application server and the other as the database server, but both are able to work independently so that if one fails, the other can take all the load. This can be achieved in AIX using HACMP mode 2 for all the software.

Application Server Node 1 WebSphere Application Server eND Application Server Node 2 WebSphere Application Server eND Application Server Node n WebSphere Application Server eND

. . .

Database

(50)

Figure 3-2 High availability database service in AIX using mode HACMP1 and RAID 1 The load on the HTTP server in an exclusive Payment Manager environment is not normally high enough to justify another machine or machines dedicated to the HTTP server.

A 2-tier architecture is more convenient when there is a central database manager installed. In this case WebSphere Payment Manager can use this remote database. The installation will benefit from the backup and availability of the central database.

As more transactions are received we can proceed as in the 1-tier architecture and balance new application server machines with a network dispatcher. A 3-tier architecture is an improvement on the 2-tier when the use of the HTTP server is not limited to the access to the administration interface of WebSphere Payment Manager and its corequisite software.

Database Server Node 1 DB2 Active Mirroring HACMP Database Server Node 2 DB2 Standby Mirroring HACMP Mode 1 Disks

(51)

Typically, a unique machine or a cluster manages all the HTTP servers using virtual hosts and dispatching techniques. Then one or more WebSphere

Application Server and Payment Manager machines use the HTTP server cluster and a remote database.

Figure 3-3 Standard architecture - central HTTP server, application servers and database

This architecture has two main applications: high availability and reusing existing servers. But high availability can be achieved with a 2-tier architecture as we explained earlier and since this requires fewer machines we suggest that reuse of an installed, configured and known HTTP server is the best reason to use a 3-tier architecture with Payment Manager.

3.1.4 Prepare all the software, fixes, patches and information

The most important step in ensuring a quick installation is to prepare all the software and data required and have it on hand ready to use.

Assure that all product CDs are on hand and that you have downloaded any fixes required. Here we list useful Web sites to get fixes and information:

If you need to download an AIX maintenance level you can do so from: http://techsupport.services.ibm.com/rs6000/support/ Web Client Database Server HTTP Server Other HTTP Server or WAS WAS WPN Other Applications

(52)

If the download is too big you can ask for a CD. This window has all the instructions to check the download by size and checksum and to uncompress every file needed.

If you don’t have a gzip decompressor for your AIX system, you may find free software for the AIX operating system at:

ftp://ftp.software.ibm.com/aix/freeSoftware/

The latest Fix Packs for DB2 can be downloaded from: http://www.ibm.com/software/data/db2/udb/support.html

Along with the Fix Pack, there are detailed instructions to check for prerequisites and to install the update.

Oracle database server and its fixes can be downloaded from the Oracle Technology Network at:

http://otn.oracle.com/

This is also the main source of documentation for the Oracle products. Information and downloads for IBM HTTP Server can be found at:

http://ibm.com/software/webservers/httpservers/

The main source of information about WebSphere Payment Manager is: http://ibm.com/software/websphere/paymgr/support/index.html

You can access all the official documentation, gather contact information and download new patches from this site.

If you need to manually install or upgrade WebSphere Application Server, you can install WebSphere Application Server Version 3.5 using the CD-ROM provided with Payment Manager, or download the version for your operating system from:

http://ibm.com/software/webservers/appserv/

For migration instructions, see the WebSphere Application Server Info Center, which you can download or view directly from the Web.

Documentation for IBM DB2 Universal Database is at: http://ibm.com/software/data/pubs/index.html

Along with the fixes, download and read any related information including the installation instructions. Don’t forget to read the IBM WebSphere Payment Manager for Multiplatforms Install Guide Version 2.2 instructions for detailed and exhaustive installation scenarios. The IIBM WebSphere Payment Manager for Multiplatforms Administrator’s Guide Version 2.2 also provides information about administering and maintaining the WebSphere Payment Manager.

(53)

Always read the latest readme file, readme.framework.html, accessed through documentation links on the Payment Manager Web site:

http://ibm.com/software/websphere/paymgr/support/ and on the Payment Manager CD-ROM.

Apart from the software, you need to collect some data from your system, including the IP and host name of every machine involved in the installation.

3.1.5 Make a backup of the system

Prior to any installation we suggest that you back up the system using the common ways available for your operating system. In our case, since we were doing a new installation in a development environment, we omit this step in the detailed description of each scenario. However in a production environment we recommend that you do backups prior to any installation.

3.2 Windows installation and configuration

We have tested these scenarios:

1. Stand-alone or 1-tier: everything in the same machine, typical for a small payment hosting environment.

2. 2-tier with WebSphere Commerce Suite: includes the installation of WebSphere Commerce Suite using a remote DB2 and a local Payment Manager. This focuses on the use of WebSphere Payment Manager as a payment method for commerce instead of as a payments hosting service. 3. Using a remote HTTP server: we modified an existing installation of

WebSphere Payment Manager to use a remote HTTP server instead of the local one.

Note: When installing WebSphere Application Server, you will be asked which

database you want to use. You must use a relational database. DB2 UDB is recommended. Do not select the Quick option so the InstantDB is not used. The installation program requires a graphical display. Ensure the resolution on your display is set to 800 by 600 pixels or higher to best view the Payment Manager installation program.

The administration and configuration of Payment Manager requires a browser. It does not matter if the browser is on the same machine or on another.

e-commerce Payment Solutions Implementation and Integration

e-commerce Payment Solutions

Implementation and Integration

Using IBM WebSphere Payment Manager

Bill Moore

John Fisher-Smith

Terry Hudson

Jose Novillo

Reto Sigl

Planning and installing payment

solutions

Integration with payment

protocols

Payment Manager and

WebSphere Commerce Suite

e-commerce Payment Solutions

Implementation and Integration

Using IBM WebSphere Payment Manager

October 2001

Contents

Preface

The team that wrote this redbook

Notice

IBM trademarks

Comments welcome

Introduction to payments

1.1 Our objectives

1.1.1 Who should read this book

1.1.2 How this book is structured

1.1.3 Supported environment

1.2 Payment history

1.2.1 Credit cards

1.2.2 Internet payment

1.3 Positioning online payment solutions

1.3.1 Payment service provider is key

1.4 Security

Technologies for improving security

1.5 IBM WebSphere Payment Manager

1.5.1 Content

1.5.2 Functionality

Worldwide service

Payment solutions

2.1 Future payments

2.1.1 Wireless payments

2.2 Emerging payment challenges

Purchase orders

Manufacturers’ coupons

Deferred credit

Multiple payments installments

2.3 Payment Manager solutions

2.3.1 Integration considerations when using Payment Manager

2.4 The Payment Manager internal architecture

The Payment Manager API

The Payment Manager user interface

The Payment Engine

2.5 Capacity planning, scalability and performance

Installation and

configuration

3.1 Installation planning and design

3.1.1 Decide operating system, database manager and HTTP server

3.1.2 Find out which versions are supported by the product

3.1.3 Decide if you want a 1, 2 or 3-tier architecture

. . .

3.1.4 Prepare all the software, fixes, patches and information

3.1.5 Make a backup of the system

3.2 Windows installation and configuration