Credit Card Processing: A Scenario

Kayla stares at her browser...

Her finger is poised over the PC's large ENTER key. She tries to picture in her mind the path that her credit card transaction will take. She hesitates to press that last key to complete the order. "Buying this book over the Internet is convenient," she thinks, "but what happens to my credit card information when I make this purchase?"

She relates this to recent events at her office. Kayla has been assigned to find an AS/400-based payment processing solution to support the whole enterprise. This includes the sales from the company's soon-to-be-launched web site. Initially, it will generate only a few transactions a day. That is how amazon.com started. Questions race through her mind. "How do I handle authorization requests from the AS/400 RPG applications and the web server simultaneously? Who are the players in that software market? What would a processing system cost? How secure is its operation? How do I interface our different programs to the payment server software? What about the other divisions who need credit card processing? How will I find time to read this book I am about to buy?"

On one hand, she is lucky. The company has used AS/400 computers for years and intends to continue to run its business software on them. This means that the financial applications that will manage the orders reside on this box of legendary reliability. The AS/400 has become the most popular midrange computer in the world. On the other hand, she can see many challenges related to processing e-payments at her company - and she's pretty sure there are even more she hasn't thought of.

The Players

Completely distracted from her online purchase, she takes stock of the situation. Her research has taught her much about payment processing. Kayla first considers the players. Her blossoming company is the "merchant," the seller of goods. The sales will result in the deposit of customers' funds into the company's account at the "merchant bank." The requests for credit card authorizations will be communicated over the "authorization network," to be verified initially with the cardholder's "issuing bank." Once authorized, the issuing bank will put a hold on the funds for a short time to ensure she will get paid.

When Kayla's company delivers the goods, the authorized transactions will be transmitted again and "settled." This can happen almost immediately or up to 30 days after the authorization, depending on when the settlement is initiated. At that time, Kayla will send the transactions to the "acquirer." The acquirer may be either the card services division of her company's bank or an independent company. The merchant and acquirer have a contractual relationship and the acquirer purchases the settled transactions from the merchant at a discount. For example, if the agreement is for a two percent discount, the acquirer pays the merchant $98 for every $100 of transactions. From this fee, the acquirer also pays the authorization network for their services.

Competition

Kayla's design goal is to provide the connections from the various applications to the authorization network currently being used by her company. The controller told her that later, when the credit card business grows, the company will take advantage of the competitive acquirer market and shop for the acquirer with the best card processing rate and service.

Of course, rate is not the only consideration they would factor into the equation when evaluating the acquirer's customer and accounting services. Each acquirer has a preferred set of authorization networks that they use. Any interface that Kayla implements had better be able to use several of the potential authorization networks, to be sure her management can always shop around for processing services. She knows that all authorization networks use the same communication protocol for dial-up access. But, the field content within the protocol packet is different for each. The leased line and frame relay connections for high-speed, high capacity authorizations each use totally different protocols.

Kayla has also decided to be sure her system connects directly to the processor of choice, rather than linking through "gateways" that add yet another level of cost and complexity to the processing chain.

Being a paragon of organization, Kayla grabs her notepad and starts a list of requirements for a payment processing system:

1. Connect directly to multiple authorization networks
2. Support any acquirer
3. Handle a choice of connection methods. Choices include dial-up, Internet and leased line/frame relay connections
4. Same application interface regardless of the acquirer/network

Throughput

The acquirer had said that if she starts with dial-up connections, she is limited to about 10 transactions per minute per line, since they are usually single-threaded. The rule of thumb is six seconds per authorization on a dial-up line. Most networks will allow the line to stay open for 2 to 30 seconds after the first authorization request, to avoid the time for dial and connect. This is great if you have the volume to keep the line open. Some networks allow multi-threading, or interleaving of the transactions. This doubles or triples the throughput to up to 2000 per hour on a single line. She ponders, "How do I size the system? Will it have the scalability to grow with our business?" "What transaction volume can we expect for our retail, call center, and other divisions?" What is our ultimate target volume considering future growth?

More notes:

5. Support all transaction traffic, even on the busiest day
6. Support scalability to the ultimate target volume, considering future growth

One question leads to another. "What about the acquirers who use authorization networks based on the public Internet as the communication vehicle for the requests? Are they secure?" The accounting division expressed concern about authorizing over the Internet. Kayla wondered how secure those same people feel when they hand their card to a waitperson in a restaurant who disappears for five minutes into the back room? Since online authorization services use "SSL," Secure Sockets Layer, she felt comfortable with the security. Kayla was also concerned with the consistency of the response time. "Can Internet authorization provide consistent response? If we authorize over the Internet, it has to be fast and consistent." She pauses and thinks ruefully, "Well, it has to be fast and consistent no matter what method I choose!"

7. Authorization has to be fast and consistent

Points of Origin

One major complication for Kayla is that the authorization requests are going to originate from several different divisions of her company. The Call Center has operators with headsets entering orders into green-screen 5250 applications. They need credit card authorizations in real-time while the customer is on the phone line. The Mail-Order Division enters orders they receive by fax or mail and these credit card authorizations do not need to be processed in real-time.

The Fulfillment Division has recurring orders that are shipped to customers automatically every month. This automated process generates a batch of authorization requests when it runs each day. Fulfillment also creates batch requests when back-orders are released for shipment. The already-authorized transactions are flagged to be settled at that time, as well. The nightly settlement process will then include them. She writes:

8. Handle transactions from all divisions, and from all sources

Retail

The company's retail stores use cash registers that dial directly into the authorization network. This has been a real accounting challenge, since the details of each authorization are kept at the store of origin, on a cash register. Resolving disputes or tracking the transactions has to wait until the monthly upload of the transaction history from the stores.

"Maybe there is a way for the store registers to dial directly into the AS/400 and obtain their authorizations through it?" Of course, as a convenience to the retail customers, her company insists on taking debit and ATM cards. This requires the use of "PIN-pads" at each checkout register. The customer must key in a four digit PIN, which is encrypted by the PIN-pad so it is secure for its transit to the issuing bank.

9. Must support connections from stores to the AS/400 for authorizations
10. Must handle retail PIN-pads

And then there is the web site. As much as management wants to run the web server directly on the AS/400, they are also being pushed by the web site consultants to run it on a UNIX or Windows NT platform. Apparently the "webness" of the AS/400 has not yet become apparent to many web site creators. "How do we get the transactions from the external web server to the AS/400 and back, IN REAL-TIME?" "How fast is REAL-TIME authorization? Is it fast enough?"

11. Support real time authorization

Getting Captured

Kayla's accounting division has already explained to her that credit card processing comes in two basic flavors, "host-capture" processing, or "terminal-capture." Host-capture is used by businesses that settle every transaction every night. All authorizations done each day are captured by the "host," the acquirer, and settled at the end of the day automatically.

Her company has back orders and often does not ship orders for days after receipt. She knows they asked their acquirer for a terminal-capture account. This means that the terminal, the AS/400 actually, retains the authorized transactions until they are flagged to be settled when the orders are shipped. The AS/400 then sends the nightly batch to the acquirer for payment. No problem.

12. Must flag each transaction for settlement when goods are shipped

Fraud

Her thoughts turn to the fraudulent use of cards. Kayla's company is concerned about fraud and identity theft. She's already concluded she will have to send the "AVS" data with the authorization. This is the Address Verification Service data, consisting of two fields - twenty characters of the street address and up to a nine digit zip code. Both are taken from the billing address of the card. When checked by the issuing bank against the billing address, the result is sent back to the merchant. If it does not match, they have the option to refuse the card. She knows that the more rigorous her anti-fraud measures, the better rate she will receive from her acquirer.

Kayla's company will require the retail clerks to key in the three or four digit "CVV2/CVC2/CID" credit card validation number that is printed on the signature area on the back of the card, or on the front on AmEx cards. This number is there for additional security. It is not printed on receipts, so a thief doesn't have access to this number unless they possess the actual card. It will have to be passed as part of the authorization process, and if not provided, the charges for the transaction will be higher!

13. Capture and pass AVS address data and CVV2 number data

Visa USA has required all merchants who handle credit card information to adhere to the requirements of their Customer Information Security Program (CISP). As her acquirer told her, every software package released since mid-2001 must be compliant, but few are. Certainly, all software released before mid-2001 is suspect. Two of the most obvious requirements are that all stored credit card account numbers be encrypted with "strong" encryption, and that all accesses to the un-encrypted numbers be logged with date/time stamp and user ID. They suggested she visit http://www.visa.com/cisp for all of the details.

14. Adhere to CISP Security requirements from VISA

Not only are the AVS and CVV2 fields required, but to get the best rate from the acquirer, Kayla also has decided to send the actual invoice number with the authorization. The acquirer said that a non-repeating number is required to be sent every time, in a special invoice number field.

15. Retain and provide invoice number

Business to Business

The distribution division wants to do business-to-business sales as well as business-to-consumer. To further complicate things, they insist that their customers be able to use "purchasing" cards. These handy things, also known as "procurement" cards, provide a real advantage to the companies or government agencies using them.

At settlement, the Level II purchasing card requires SIX additional fields of data be sent to the acquirer. This additional data is then included in the cardholder's statement. Included is the purchase order number, the tax amount, and up to four fields of up to forty characters of line item detail on the purchase. Phew! In the Level III specification, up to 99 line items are returned at settlement. The purchasing card user receives credit card statements electronically and can reconcile the purchases programmatically.

16. Provide tax amount, PO number, and line items

Types of Transactions

Kayla's been told by the acquirer that she would be using a "book" transaction to authorize and then a "ship" transaction to settle. She is thankful that she's not in the hotel, car rental, fuel, or restaurant business. The acquirer explained that all those businesses have additional requirements for the specific sets of transactions that are unique to their industries.

Ideally, the software would store the transactions in AS/400 physical files and update them as they are processed. The format of the physical files should be simple enough to allow any RPG program, or even Query, to extract information. The software would also have a full slate of standard reports to break down the activity by division, card type, and settlement. An audit log of the activity should be readily available to identify who is initiating any part of the payment process.

17. Excellent data retention and audit trail with strong management support capabilities

Support

Kayla thinks back to the last time she had to access Technical Support, and the problems she encountered getting meaningful help. Though e-commerce never sleeps, that Fortune 100 company, claiming a presence all over the globe, was certainly scarce on that Saturday morning…

18. Standard 24x365 Technical Support - from people who know the product

By now, Kayla's mental picture is becoming clearer. Adding to her burgeoning book collection has become much less important. She needs to accommodate all of the varied requirements of her company's payment processing challenges. She looks over her list of requirements. "Well," she thinks, "that's a pretty good start!"

Joining the majority of online shoppers who abandon their shopping carts before checkout, she clicks the "Back" button on her PC. Kayla goes to her favorite Internet search engine to look for software. She keys the search phrase "AS/400 credit card" and clicks the "Search" button.

#####

Kayla's Requirements for a Payment Processing System:

1. Connect directly to multiple authorization networks
2. Support any acquirer
3. Handle a choice of connection methods.
    (Choices include dial-up, Internet and leased line/frame relay connections)
4. Same application interface regardless of the acquirer/network
5. Support all transaction traffic, even on the busiest day
6. Support scalability to the ultimate target volume, considering future growth
7. Authorization has to be fast and consistent
8. Handle transactions from all divisions, and from all sources
9. Must support connections from stores to the AS/400 for authorizations
10. Must handle retail PIN-pads
11. Support real time authorization
12. Must flag each transaction for settlement when goods are shipped
13. Capture AVS address data and CVV2 number data
14. Adhere to CISP requirements from VISA
15. Retain and provide invoice number
16. Provide tax amount, PO number, and line items
17. Excellent data retention and audit trail with strong management support capabilities
18. Standard 24x365 Unlimited Technical Support - from people who know the product

#####

Ira Chandler has been designing and programming communications software since 1981. For the past fifteen years, he has guided the development of e-transaction middleware with current emphasis on enterprise payment server software based on the IBM AS/400 platform.