Goal

The goal of this document is to help developers seamlessly integrate electronic payment systems (EPS) into their applications correctly. These applications can be traditional thick client solutions or web based n-tier server solutions.

Curbstone specializes in the deployment of very thin client solutions using REMOTE TOKENIZATION for companies based o the IBM Power System running the IBM "i" Operating System.  These three solutions use a locally-run very thin client to send non-sensitive card transaction data to the Curbstone Portal.  Using three different technologies, that non-sensitive data is married with the Card Number, Expiration Date, and Security Code to perform authorizations.

The Primary goal of Curbstone was to remove ALL EXISTING COMPUTING INFRASTRUCTURE FROM THE SCOPE OF PCI REPORTING.  This means that nothing that currently exists can touch sensitive card data.  The reason is that an audit on a very isolated, purpose-built system is WAY easier than auditing the entire computing infrastructure.  The audits are quicker, easier, and more meaningful.  The points of intrusion are reduced exponentially, reducing risk of sensitive data loss.

The Secondary goal of Curbstone was to provide REAL-TIME, SEAMLESS INTEGRATION with Order Entry applications that run on the IBM i operating system.  The very thin client of Curbsotne's CorrectConnect (C3) provides the contact point on the system through which transactions are intiiated.  Since it is native on the IBM Power System, the programs there, with some very easy programming, can talk directly to it and pass the required transaction fields.  Because the client is in real-time communicatio with thC3 Portal, those transactions are processing a matter of seconds, returning the results to the client, and then the Order Entry application.

The Third goal of Curbstone is to process transctions that are well-qualified, and avoid unnecessary downgrades and vulnerability to chargebacks.  This is done by selecting the correct transaction type, populating all of the required fields correctly, and processing the authorizatio and settlement in a timely manner.  While compromises must be made for required business processes, the goal is always to PAY THE LOWEST RATE!

Regardless of the application type, the integration needs to be done in a way that meets the financial industry requirements, the business process requirements, and the needs and usability requirements of the end-user of the application. Ideally, EPS should be done in a way that is invisible to the end-user of the application while providing the merchant the lowest possible processing rates.

There sound obvious goals, but due to the convoluted nature of the payment industry and many developers’ lack of intimate understanding of the payment industry, these goals are seldom easily achieved. Developers often wish they could go back and redo an application knowing what they know after they finish. For this reason, it takes several times to get it right. Many basic, but important errors can be avoided through initial proper planning.  With Curbstone's UNLIMITED Implementation and Technical Support, we work hard to ensure the programmers are doing the correct things from the start.  With MANY hundreds of implementations, we have a mature and effective process to make this happen.

The objective of this guide is to give the developer the basic knowledge of the payment industry needed to augment the Curbstone guidance to “get it right the first time.”

Getting Started

Before developers can integrate electronic payments into their applications they need to understand the payment industry and how it relates to the business processes of the application they are writing. Integrating payments is hsitorically a complicated process that has evolved over a number of years and is quite likely to require different implementation strategies for each application and vertical market (restaurant, hospitality, e-commerce, etc…). The way a developer implements payments into applications has an important bearing on the ease-of-use and efficiency of applications are as well as the ultimate processing rate (fee) the merchant pays for each transaction.  If integration is done poorly payments may be processed, but the merchant will pay higher rates than necessary.

The first step towards a successful integration is to understand the payment process and some payment processing terms.  Listed below is an overview of how payment processing works and a number of terms that will be used in describing the payment process. Please read the terms below carefully and refer back to them as needed. These terms are important to understanding the payment processing industry, the players and the developer’s role.

Transaction Processing Today

When the card-holder presents a credit card as payment for goods or services, that is only the starting point for a complex series of behind-the-scenes transactions and data transfers.  Ultimately, the result of this process is that the merchant receives a discounted payment (their customer's payment minus a processing fee) for the service or product sold to the customer. 

A transaction is initiated when a Cardholder presents the card to a Merchant in payment for goods or services.  The card can be presented physically in the case of a retail establishment - CARD PRESENT, or indirectly over the Internet by providing the card number, expiration date, and name on the card - CARD-NOT-PRESENT. 

The Merchant either "swipes" or using EMV, "inserts" the card through an electronic reader or enters the card information manually into a computer or special-purpose payment terminal (also known as a "black box").  The transaction amount can also be entered or transferred from a point-of-sale system or shopping cart.  The Electronic Payment System or EPS connects to a computer belonging to a Processor (aka Authorization Network), and transmits the card and transaction data. If the transaction is done over the Internet, the Merchant will either connect to a Processor directly or connect to a Gateway provider that formats the data and sends it to the Merchant’s Processor, typically over leased telephone lines.  In the case of Curbstone, the client software for Card-Not-Present will connect to the Curbostne C3 Portal, and from there go to the Merchant's choice of authorization network, or Processor.

Each Processor has a specific protocol for this transmission.  The Processor's computer system makes sure that the card is valid and there are sufficient funds available for credit in the cardholder's account.  The Processor then transmits an approval or denial code back to the Merchant's system, again using a protocol proprietary to that Processor.  Curbstone abstracts that so the Merchant has one abstracted interface to Curbstone that works for ALL of the supported authorization network Processors.

For certain types of industry transactions, such as in restaurants, there are actually two steps -- a pre-authorization where an estimated amount is approved, and a post-authorization where the actual amount of the transaction is recorded.  This is necessary because the amount of the tip is unknown at the time of the initial authorization.

Most merchants now use draft capture terminals, cash register systems and PCs to process payments. These systems take the transaction information and all the data necessary to capture the transaction right at the point-of-sale, thus eliminating numerous paper-intensive steps. In the case of debit cards, some banks and retailers use on-line systems for clearing purposes while others use automated clearinghouses (ACH).

Unfortunately, these merchants have their entire computing infrastructure IN SCOPE of the PCI security requirements.  Curbstone's goal is to handle payments originating on the Power System with IBM i (aka AS/400), or from any web site that does e-commerce, where the orders end up being processed on the IBM i.

At the end of each business day, the merchant account must be closed or settled.  Depending on the Processor, this can either happen automatically or require retransmission of the day’s charges.  Upon settlement or closing, the Processor notifies the Acquirer, which starts the process of moving the funds.  Curbstoe abstracts this so the settlement process is the same regardless of chosen Processor.

The pertinent data from the transaction must be transmitted to the appropriate card-issuing bank for billing of the cardholder and settling of accounts between banks. The Processor transmits the transactions to the interchange association (e.g., Visa or MasterCard), which collates the transactions and sends them to the appropriate Issuers (the banks that issued the credit cards).  For each transaction, the Acquirer (with whom the Merchant has their "Merchant Agreement") receives payment from the Issuer for the amount of the transaction less the interchange discount. This discount is standard for all members of the interchange association, although it varies depending on the type of transaction. This process is known as interchange.

Visa, MasterCard, American Express, Discover, and third-party processors have been built to facilitate authorization and merchant/cardholder accounting and have established processing and authorization centers throughout the world. The amount of this deposit is the total of the payments made by customers, discounted for the merchant fees. The merchant fees have a number of components, some of which are controllable by the Merchant.  Curbstone specializes in assisting with the completion of transctios to take advantage of the best rates offered.

Finally, the Issuer posts the transaction on the Cardholder's account.  The Cardholder either pays the full balance or treats the balance as a loan and pays it off over time.

The Players

Merchant  is a business that sells services or merchandise and accepts credit cards as payment, and the Acquirer is the bank through which the Merchant has its merchant account.  For the Cardholder to do business with the Merchant, the Issuer and Acquirer must belong to the same Interchange Association, such as Visa or MasterCard.

Cardholder  The individual consumer owning the card and responsible for paying the card account.  The Cardholder uses the card to pay for goods and services, and pays cash to the Issuer upon receipt of the card account statement.

Acquirer  The bank through which the Merchant has its merchant account. Upon settlement of a transaction, the Acquirer deposits funds in the Merchant's bank account.  This may NOT be a brick-and-mortar bank.  The Acquirer's revenue comes from the difference between the merchant discount and an interchange discount paid to the Issuer.  The Acquirer is at risk if the Merchant defaults on refunds or chargebacks.  Most major banks act in an Acquirer role.  The Acquirer holds the formal "Merchant Agreement" with the merchant, and is also responsible for enforcing PCI Security mandates.

Issuer  The bank that issues the credit card to the Cardholder, pays the Acquirer for the discounted amount of any transactions on the card, and collects payment from the Cardholder.  The Issuer's revenue comes from the interchange discount plus any fees and interest paid by the Cardholder.  The Issuer is at risk if the Cardholder fails to pay their balance.  Most banks are set up as Issuers; Citibank is perhaps the largest issuer in the United States.

Interchange Association  The association of banks that allows any Merchant customer of a member-acquiring bank to accept a credit card from any Cardholder customer of a member-issuing bank.  Visa and MasterCard are the dominant interchange associations worldwide.  The interchange associations provide brand support as well as facilities for performing the actual transaction interchange.  In the case of American Express and Discover, one company plays the role of both Issuer and Interchange Association (a closed system).

Processor  Also called an Authorizatio Network.  This may be a division of the Acquirer, or a contracted vendor who provides the communication and transaction handling services.  A third party company, also known as a processing network that accepts electronic credit card transactions from Merchants and processes them for an Acquirer.  The processor handles notifying the Acquirer of the transactions (so that funds can be deposited in the Merchant's account) as well as transmitting the transactions to the Interchange Association.  An Acquirer is typically associated with just one Processor, and pays that Processor for its services.  Each Processor has a different protocol for receiving transaction information from Merchants. Third party Processors are primarily used in the United States, where the multitude of smaller banks allows them to offer economies of scale.  Outside the United States, each country typically has a very small number of banks, so each bank handles its own transaction processing.  The largest Processors in the U.S. include First Data Corporation (FDC), TSYS, and Chase Paymentech.  Curbstone is formally certified to operate with all of them.

Gateway  A third party company that accepts electronic payment transactions over the Internet and sends them directly to the Processor for processing.  There are two types of gateway companies, companies that develop their own software such as Paypal, CyberSource and Authorize.net and companies like CardService International that use a third party company’s software from someone like ClearCommerce and Paylinx to process the transactions. These companies are known as Commerce Service Providers or CSPs. Curbstone runs a Gateway, but does not charge the per/transaction fees that the typical gateways do, since they are just middlemen.

Application Developers The individual responsible for integrating payments into business applications, whether custom systems or vertical- market products, many have found the transaction processing protocols complicated and fast-changing, as well as inconsistent among different processing networks.  This drove demand for transaction-processing modules or components that could be easily integrated into applications without having to worry about these complexities.

Payment Terms

ACQUIRER or ACQUIRING BANK

A federally-chartered bank institution that sponsors merchants for the acceptance of credit card transactions. They provide the "Merchant Agreements".  The bank that maintains the merchant relationship and receives all settlement transactions from the merchant.

ADDRESS VERIFICATION SERVICE (AVS)

A service that verifies the cardholder's billing address in order to help combat fraud in "card not present" transactions (e.g. mail order, telephone order, internet, etc.).

AMERICAN EXPRESS OR AMEX

An organization that issues cards and acquires Transactions (unlike Visa and MasterCard, which are bank associations).

APPROVAL

A code issued by a card-issuing bank allowing a sale to be charged against a cardholder's account. Approval means that the amount is within the cardholders remaining credit limit and that the card has not been reported lost or stolen. Approvals are requested via an AUTHORIZATION.

ASSOCIATIONS

MasterCard and Visa are the existing bankcard associations. Their purpose is to establish and administer the rules and regulations governing the credit card business. Discover and American Express are similar but not technically associations since they are single companies.

AUTHORIZATION

The request to charge a cardholder. Reduces the cardholder's "Open to Buy" but does not actually charge the account. Authorization must be SETTLED in order to charge the account. If not settled within a certain time period authorizations expire or "drop off."  The expiration time period is typically 7-10 days, though authorizations can be processed as long as 30 days after approval with a higher fee.

AUTHORIZATION CODE

The numerical code sent by the card issuer, given to a Sales transaction as verification that the sale has been authorized. The authorization code is always included on the merchant sales draft.

AUTH ONLY OR PRE-AUTH

A transaction in which the merchant does not intend to charge the cardholder until a later time, if at all. See PRIOR AUTHORIZATION.

AVERAGE TICKET

The average dollar amount of merchant credit transactions.

BANKCARD

Non-profit organizations that are owned by participating financial institutions.

BASIS POINT

One one-hundredth of a percent (.0001). DISCOUNT rates are expressed as basis points.

BATCH

A collection of transactions. Usually a merchant has one batch per day or per shift.

BATCH PROCESSING

A type of data processing where related transactions are transmitted as a group for processing.

BUNDLED RATE

A discount rate that includes communications costs as well as transaction fees. Also referred to as a flat rate.

CARD ISSUING BANK

 The financial institution that issues a credit card to a  consumer. This is the financial institution that sends

 the credit card bill and is responsible for the receivables  on the card.

CAPTURE

The act of creating an electronic transaction, usually for transferring money. Captured transactions are ready for settlement.

CHARGEBACK

The act of taking back funds that have been paid to a merchant for a disputed or improper credit card transaction. This procedure is initiated by the issuer after the acquirer has begun the clearing process.

CHARGE BACK PERIOD

The number of calendar days in which a MEMBER may charge sales back to the merchant, beginning with the day after the date the record is first received by the member or agent and continuing until the end of the day on which it is dispatched as a charge back item.

CHECK GUARANTEE

A service which guarantees check payment (up to the Limit defined for the account), provided that the merchant follows correct procedures in accepting the check. The service determines whether the check writer has previously written delinquent checks.

CLEARING

The process of exchanging financial details between an ACQUIRER and an ISSUER to facilitate posting of a cardholder's account and reconciliation of a customer's settlement position.

CLOSE BATCH

The process by which transactions with authorization codes are sent to the PROCESSOR for payment to the merchant.

CREDIT or RETURN

A return of funds to a cardholder's account (crediting entry) for a sale that has already been authorized and settled.

DEBIT CARD (ON-LINE)

An ATM bankcard used to purchase goods and services and to obtain cash, which debits the cardholder's personal deposit account. Requires a PIN

(Personal Identification Number) for use.

DEBIT CARD (OFF-LINE)

A bankcard used to purchase goods and services and to obtain cash, which debits the

cardholder's personal deposit account.  Off-line debit cards do NOT require a PIN (Personal Identification Number) for use and pass through interchange just like a credit card.

DECLINE

Response to transaction request meaning that the issuing bank will not authorize the transaction.

DEPOSIT

When a merchant closes a batch and sends the transactions to the host computer for settlement. Compare to RELEASE. Batches should be closed on a daily basis to ensure the lowest discount rates.

DISCOUNT RATE

The discount rate is the rate a merchant pays their financial institution for services rendered in connection with processing of financial transactions. The discount rate is made up of several components including interchange and processing fees.

ELECTRONIC DRAFT CAPTURE

A system in which each transaction is routed to the HOST COMPUTER for processing and storage. The stored transactions are used to create settlement files and transaction reports.

ELECTRONIC FUNDS TRANSFER (EFT)

The paperless act of transmitting money through a computer network. Usually does not refer to CHECK GUARANTEE.

FLOOR LIMIT

This was a preset limit established by a PROCESSOR that allowed merchants to accept credit card sales without authorization provided the merchant check to see that the card number was not listed on a Warning Bulletin for lost or stolen cards. Floor limits are now rarely used.

FORCE

A sale TRANSACTION for which a merchant received a VOICE AUTHORIZATION. A Force is done so that the PREVIOUSLY AUTHORIZED transaction can be settled and the merchant can receive funds. Also known as POST AUTHORIZATION.

GATEWAY

A system that passes data between networks having similar function, but different implementations.

HOST CAPTURE

Type of transaction capture in which transaction information is stored on the PROCESSOR's HOST COMPUTER and not on the merchant's POS system. Compared to TERMINAL CAPTURE.  SETTLEMENT occurs at the HOST COMPUTER and may be automatic: no merchant initiation is required.

HOST COMPUTER

Refers to the computer at the PROCESSOR that is dialed

For AUTHORIZATION and SETTLEMENT.

INDEPENDENT SALES ORGANIZATION (ISO)

Term for a company that is sponsored by an ACQUIRING BANK to solicit, sell and sometimes support merchants.

INTERCHANGE

The flow of information between issuers and acquirers, e.g. transactions, retrieval requests, charge backs.

INTERCHANGE FEE

The fee paid by the ACQUIRING BANK to the ISSUING BANK for each credit card transaction. This fee is part of the DISCOUNT rate.  This fee is set by and collected by the bankcard associations.

ISSUER (CARD ISSUER)

A bank that provides credit cards to consumers.

ISSUING BANK

Same as the ISSUER. The issuer of the customer credit card.

MAGNETIC STRIPE

A stripe on the back of a bankcard that contains magnetically encoded cardholder account information. The name of the cardholder is stored on Track I and the account number and expiration date are stored on Track II. Also referred to as MAG STRIPE. See Appendix II for details.

MANUAL ENTRY

Credit card information that is entered via keypad instead of swiping the card through a card reader.

MASTERCARD

An association of banks that governs the issuing and acquiring of MasterCard credit card transactions.

MEMBER (MEMBER INSTITUTION)

A financial institution that is a member of Visa USA and/or MasterCard International. A member is licensed to issue cards to holders and/or accept merchant drafts.

MERCHANT

A retailer, or any other entity (pursuant to a Merchant Agreement), that agrees to accept credit cards, debit cards, or both, when properly presented.

MERCHANT AGREEMENT

A written agreement between a merchant and a bank - ACQUIRER - containing their respective rights, duties, and warranties with respect to acceptance of the bankcard and matters related to bankcard activity.

MERCHANT BANK

Also known as the Acquiring Financial Institution since it acquires merchant business by supplying the merchant with the means to accept credit cards for payment. It is a bank that has entered into an agreement with a merchant to accept deposits generated by bankcard transactions, also called the ACQUIRER or ACQUIRING BANK.

MERCHANT CATEGORY CODE

A code assigned by an ACQUIRER to a MERCHANT to identify the merchant's principal trade, profession, or line of business. This four digit code is also know as the SIC CODE.

MERIT

Refers to the Qualification levels for a MasterCard transaction. Merit III is the highest, followed by Merit II, Merit I, and then Standard.

MID

Refers to Merchant Identification Number. This unique number identifies a merchant to the merchant bank or processor.  Associated with it is the TID, Terminal Identification Number, to provide a unique location from which to attribute the payment.  Curbstone abstracts this into a 5 digit number representing the business unit that is perofming the charges, called a "Merchant Code".

MOTO

Refers to Mail Order/Telephone Order.

MULTI-TRANS

Multiple transaction requests and responses transmitted to the processor on the same connection.

MULTI-TRANS MODE

The HOST COMPUTER transmits additional codes to allow additional transactions on an existing connection.

NET SETTLEMENT BANK

The bank that maintains the settlement account and that executes funds transfers with member clearing banks.

NON-QUALIFIED

A broad term that describes a transaction that did not interchange at the best rate because it did not satisfy all the card association requirements for the transaction. For instance, the transaction was entered manually or it was not settled in a timely manner.

OFF-LINE

Operating mode in which the terminal is not connected to the processor. Often used when a merchant is batch processing transactions.

ON-LINE

Operating mode in which the terminal is connected to the processor via dial, lease line, etc. in order to provide

real time responses to transaction requests.

OPEN TO BUY

The amount of credit available at a given time on a card holder's account.

ORIGINAL DRAFT

The actual bank copy of the forms used in the transaction. Also referred to as the "hard copy."

PC POS APPLICATION

A computer program that integrates two or more of the following functions: cash register, inventory, accounting, and credit card authorization and settlement.

PIN

Personal Identification Number used by a cardholder to authenticate card ownership for ATM or Debit card transactions. The cardholder enters his/her PIN into a PIN Pad. Customer entry of his/her PIN is required to complete an ATM/Debit card transaction.

POINT-OF-SALE

The place and time that the transaction occurs. This term also refers to the devices or software used to process transactions.

POST-AUTH

Completion of a pre-authorized transaction.

PRE-AUTH

The process of authorizing and reserving the funds for the transaction – insuring the card is valid; the cardholder has sufficient open-to-buy funds to cover the purchase amount and reserving the funds for completion (POST-AUTH).

PRIOR AUTHORIZED SALE

A transaction for which AUTHORIZATION was obtained at an earlier time, e.g. a merchant had to call for authorization, merchant authorized card before services rendered (hotel reservation, auto rental, etc.).

PRIVATE LABEL CARD

A card that can be used only in a specific merchant's store.

PROCESSOR

A transaction processor; a large computer center that processes data from credit card transactions and settles funds to merchants.

QUALIFICATION

A level at which a transaction interchanges. The level of qualification is dependent on how well a transaction meets interchange criteria.  For example how the credit card number is entered, swiped or manual, and how quickly the transaction is settled.

RECEIPT

A hard copy description of the transaction that occurred at the point-of-sale. Minimum information contained on a receipt is: date, merchant name and location, account number, type of account used (e.g. Visa, MasterCard, AMEX, etc.), amount, reference number, and action code.

RETURN or CREDIT

A transaction that is the opposite of a sale, the return amount is credited back to the cardholder.

RECURRING TRANSACTION

A transaction, for which permission has been granted by a cardholder to a merchant, that is periodically charged to the cardholder's account.

RELEASE

When a merchant instructs their terminal to close a BATCH. Applies only to Host Capture. Cardholders are not charged (and merchant accounts credited) until a batch is released. Compare to DEPOSIT.

SALE

A transaction that authorizes and captures the transaction amount as a single step.

SETTLEMENT

The process by which TRANSACTIONS with AUTH CODES are submitted to the Processor for transfer of funds.

SUSPENSE

A state in which a batch of transactions is not released to interchange because of a problem noticed by the HOST COMPUTER. Requires human intervention to fix the problem and settle the batch.

SWIPED CARD

Credit card information that is read into a card reader directly as a result of swiping (or sliding) the credit card through a card reader. The information magnetically encoded in the magnetic stripe is transmitted. This information includes secret data that helps validate the card. Compare to MANUAL ENTRY.  This is being phased out in favor of Chip and Signature technology - EMV.

TERMINAL CAPTURE

Type of software in which transaction information is stored in the software, not at the HOST COMPUTER. Merchants using Terminal capture must initiate SETTLEMENTS at the end of each day or shift. Compare to HOST CAPTURE.

THIRD PARTY PROCESSOR

A non MEMBER agent which provides authorization, settlement and merchant services to a merchant.

TICKET ONLY OR POST-AUTH

A sale transaction for which you have received a voice authorization.

TRANSACTION

Action between a cardholder and a merchant that results in activity on a cardholder account.

TRANSACTION FEE

A "per transaction" charge incurred by merchants who are on scale pricing. This is in addition to the percentage DISCOUNT fees.

VISA

An association of banks that governs the issuing and acquiring of Visa credit card transactions.

VOICE AUTH

A transaction authorization that is provided by an operator, usually when an issuer sends a "Please Call" message to the merchant instead of an authorization number.

VOID

The reversal of a current transaction that has been authorized but not settled. Settled transactions require processing of a CREDIT in order to be reversed.

The Discount Rate

The discount rate is the rate a merchant pays their financial institution for services rendered in connection with processing of financial institution transactions. Financial Institution transactions are any transactions the financial institution facilitates.  Examples are credit card, debit card, electronic benefit transaction (EBT), and check service transactions. This rate is made up of many factors and these factors need to be taken into account in the design and implementation of electronic payment applications. An example sample rate chart is shown in Appendix V. This chart clearly shows the financial implications of the decisions the developer makes when implementing payment solutions. 

Failure to implement payments correctly result in the transaction being downgraded. When a transaction is downgraded, the transaction is still processed; however, the rate the merchant pays is increased from a preferred rate to a higher rate. There are many reasons why a transaction may be downgraded. Generally, transactions will be downgraded if they do not provide the data elements required or are not processed according to the interchange rules specified by the card issuer or issuing association i.e., Visa and MasterCard. In order to qualify for the lowest discount rate all transactions must meet the rules set by the merchant service agreement that the merchant service provider and the merchant agreed to. Developers should note that the data elements required vary depending on the card type and industry the merchant is in. We will go over these rules as they relate to the specific industries in which merchants are categorized.

The Industry is Dynamic

The card associations can and do change the rules and regulations up to twice a year. Failure to implement these changes in a timely manner will result in your once compliant application not meeting the card association’s new requirements and your merchant’s transactions being downgraded. Typically the way the industry changes the rules is that they don’t stop your existing application from working, instead they increase the discount rate the merchant is paying for the same transaction while offering a lower rate or usually what the merchant was previously paying, if they implement the new rules and regulations.

Knowing this ahead of time, the application developer can try and isolate the payment functionality as much as possible from their application. Many EPS systems are in reality an abstraction layer between the application and the Processor so that they can minimize the changes required on the application side. This approach works well as long as the change does not require additional data elements.  However, if additional data elements are required the application developer typically will need to modify the U.I. so that the additional data elements can be obtained from the merchant and/or cardholder.

Ultimately, a well designed application that uses XML holds promise to solve the dynamic issues. If one can design an application that uses an XML document to describe the required data elements and business processes the application could dynamically adapt to the industry changes. The application would read this document to define its dynamic U.I. and business processes. The application could then change dynamically based on the XML description document. Consequently, as the financial service industry changes, the binary application would not need to change; only the XML description document. Developing a complete application using this technique is beyond the scope of this guide but is something the application developer should consider.  An example using this technique is detailed in Appendix I showing how to determine valid cards and card types.

Transaction Processing Overview

This section describes the history of the industry, the players in transaction processing, then outlines the typical flow of information and funds, and finally highlights the differences in the process for other types of transactions, such as Internet transactions and debit cards.

The credit card industry has been very dynamic and quick to change as technology and consumers have brought demands and preferences to the industry. When credit cards first started merchants took the cardholder at face value that the card was good.  They manually filled out paper deposit slips and manually deposited them along with their cash deposits each day at their merchant bank.

Fraudsters quickly seized on this opportunity to steal cards and present themselves as the cardholder and make fraudulent charges. The credit card industry responded by providing lists of bad or stolen cards to merchants. Merchants were required to look up card numbers in a booklet of "bad cards", which was in a red cover and became, know as the “red book”. Because the lists changed, it was periodically update by the card associations.  As credit card usage grew, the bad card list grew unwieldy and was quickly out of date.  Merchants used an imprint machine that became know, as a “knuckle-buster” to imprint the card on a deposit slip and provide proof the card and cardholder were present at the time of purchase.

As credit cards became more popular, an additional need arose to verify that the cardholder had sufficient funds available to make a purchase. Cardholders purchasing more than their credit limit allowed resulted in over limit and delinquent accounts.

These problems led the industry to develop the telephone authorization system.  Rather than consulting a bad card list, the merchant called a toll-free number and provided the credit card number to a representative of the card association.  The representative verified in an up-to-date centralized database that the card number was good and the cardholder had a sufficient balance to make the purchase. The representative provided an authorization code to be written on the deposit slip.  This deposit slip was taken to the bank each day and deposited into the Merchant’s bank account. By the mid-1980s the representatives were augmented with touch-tone driven phone computer systems that checked the card database and provided an authorization code automatically.  Nevertheless, from the merchant's perspective, the processing was still entirely manual.

Until the 1980s, credit card transactions were processed entirely manually. This manual process slowed down the purchase process, a kiss of death in retailing.  In the late 1980's companies developed bank terminals like Redwood City, California based VeriFone, Inc., the largest vendor for accepting credit and debit cards even today. These black boxes or payment terminals provided a complete solution. They were self-contained units that could read the mag-stripe on the card and use a standard phone connection to authorize the transaction and even print out a slip for the cardholder to sign. This technology greatly reduced processing costs and sped up transaction times significantly.

The terminals were initially used for authorization only, and merchants still had to take the sales slips to the bank for deposit.  Eventually, the terminals captured the transaction information electronically as well, initiating a process that caused the funds to be automatically transferred to the merchant's bank account. This process became know as Electronic Draft Capture or EDC.  Most merchants now authorize transactions electronically, and it is estimated that over half of all electronic transactions are still processed on terminals today.

Today, the stand-alone terminal market still has plenty of life in it, but the following conditions will lead to its eventual demise, as we know it:

EMV, Card-swipe interfaces and PIN-pads have become commodities, and are now available separately as interfaces to PCs, or even integrated into the keyboards. The rise of software applications means that bank terminals are no longer a complete solution -- rather they are an expensive proprietary add-on requiring duplicated data entry and consuming valuable counter space. The relative inflexibility of hardware devices in the face of fast- changing protocols and standards makes them an inferior alternative. Mail order and Internet-based merchants, for whom hardware-based processing makes no sense, are among the fastest growing categories of merchants. Stand-alone terminals are not easily integrated into business processes and require duplicate data entry that is error prone. I believe integrated solutions offer enormous benefit for all but the smallest merchant.

In the early 1990s, PC software-based transaction processing systems began to enter the market.  These systems implemented the various processor protocols in software and used a modem for communication, and therefore did not require a separate terminal.  The growing use of personal computers by merchants, as well as the convenience and reduced cost of having an entirely software- based system, made these products an appealing alternative for certain businesses.  These solutions were basically software solutions with the functionality of terminals. One of the big advantages these solutions offered was using a technology like Microsoft’s COM, the EPS functionality could be easily and seamlessly integrated into PC applications. Integrating payments into vertical PC applications eliminated the errors associated with duplicate entry and sped up the transaction process.

PCs

Historically, proprietary systems and cash registers that require separate bank terminals and or reader / imprinters to handle credit card sales have occupied the retail Point-Of-Sale space. The opportunity for fraud and error in re-entering the purchase amounts on bank terminals, the changing banking regulations and the valuable counter space consumed by this equipment made these systems cumbersome for some merchants and unacceptable for many others.

Since 1990, the plummeting price of PC hardware, the standardization and simplicity of PC network equipment, and the desire for "open systems" which provide an easy software development environment, fueled a new trend -- PC-based applications with credit card authorization capabilities.

The expansion of PC systems into non-traditional retail markets such as Internet, catalogue sales, telephone/mail order, kiosks, small business, and healthcare and professional offices further enhanced the move to PC based applications. These are virtually cashless points-of-sale dealing mainly in credit cards and checks.

Integrating the credit/debit authorization functions using software into PCs has many benefits not offered by other solutions:

  • Customer demographics and purchasing pattern information can be easily saved and sent to a database or spreadsheet for improved inventory control and new targeted marketing programs.
  • Security against fraud or clerical error is maintained because the amount of the purchase can be automatically authorized without the sales clerk's intervention or re-entry.
  • Software is less expensive than dedicated hardware for credit/debit authorization. The initial purchase price is often lower and upgrades are simple and inexpensive. A software update rather than an expensive new piece of hardware can easily handle ever changing banking regulations.
  • Additional cost savings are realized when a merchant has multiple Points-Of-Sale because a single modem and phone line can be used for all of the credit authorization required by multiple, networked Points- Of-Sale.
  • Multiple transactions on a network are authorized faster because the software can dial out once and poll the network for new transactions.
  • Support for new technology opportunities such as commerce on the Internet is simple to provide because data security is an integral part of the product design and new security protocols are straightforward to support.
  • Compatibility between front-line Point-Of-Sale systems and back office computer systems is maximized for easy flow of data around a merchant's computer network.

However, over time problems arose that minimized the market acceptance of PC based software only solutions. These problems had to do with the following:

      - Support – PC based solutions require more support than traditional payment terminals. The PC application had to be setup and configured with the merchants financial institution‘s parameters. Unlike traditional payment terminals, which are tied into the processors and automatically download the configuration data, PC solutions required the merchant to know this information and manually enter it correctly.

      - Complex - PC based solutions are still too complex for many small businesses to use and maintain.

      - Setup  - In order for merchant services to work the account information must be setup so that it transmitted to the processor correctly. Many merchants do no know their setup information, thus making the setup process difficult.

      - Modem issues – The merchant processing businesses was built around bank terminals that use 1200-baud modems with no data compression or error correction. Most new PCs have modems design to surf the Internet, which are designed to be much faster and are sometimes very difficult to slow down to allow connection to the processing networks.

      - Total Cost of Ownership (TCO) – PC based solutions running on Microsoft Windows also had significant support issues due to a condition know as “DLL hell”. This condition was caused by the fact that Windows and most applications keep common DLL files in the system directory. When one of these files changed and did not maintain backward compatibility the result was that some applications would stop working.

      - Integration and Testing – The complex and variable nature of the payment industry required developers to make significant changes in their applications depending on whom their merchants used for payment processing. This made the process of integration difficult and time consuming.  It was also difficult for developers to test their application against the various Processors.

      - Dynamic Payment Industry – Visa and MasterCard change the rules and regulations concerning payments on a regular basis. This requires developers to constantly maintain and upgrade applications. Many of these changes are required by the merchant just to maintain existing discounts rates. Consequently, merchants that were not told about this when purchasing solutions are not willing to pay for these services. These upgrades are typically provided for free on terminals and an automated system has been put in place with terminals so that merchant’s don’t have to do anything to receive the upgrade. With PC software solutions this process is much more complicated and support intensive.

These issues when combined with the above support issues turned payments into a necessary evil rather than a profit center for many application developers.  This condition to a large extent still exists today. It is believed that the above issues have inhibited the growth of software-only solutions because the cost benefit analysis made it difficult to justify the effort involved in integrating payments.  Consequently, there are still many payment terminals and non-integrated solutions in the marketplace today.

Connectivity Methods

Initially merchants connected to the Processors via dial telephone connections. In the U.S., where a well-developed telephone infrastructure exists, this system worked quite well. It is interesting to note that these telephone connections were developed for the payment terminals that use 300 & 1200 and later 2400-baud modems. Believe it or not, this baud rate is more than sufficient since less than 256 bytes of data are exchanged in a typical authorization. The transmission and authorization typically takes about 5 seconds.  The longest step is the dial and connection time, typically 10 seconds. In fact, increasing the transmission speeds result in longer connection times while the two systems negotiate connection parameters. Consequently, it is faster to process transactions at fixed slower 300-2400 baud rates. This infrastructure still exists today to support the millions of traditional payment terminals (U.S. and Canada 1,630,335 traditional payment terminals were sold in 1999) and for the most part has not been upgraded.  This fact has created many problems for PC solutions that now come standard with higher baud rate modems designed to surf the Internet.

Larger merchants tended to implement lease line solutions with the Processors. These solutions had the added advantage of an “always on” connection, thus eliminating the dial time resulting in 5-second transactions. The disadvantage was the merchants needed to pay an additional fee for the lease line that could be as high as $1000/month. For larger high volume merchants this was a small price to pay for improved performance and reliability. Over time these lease line costs have continued to decrease. These lease line used a protocol know as X.25 and later supported TCP/IP. It is believed that low cost DSL lines will become prevalent in most businesses over the next few years. These lines will be used to connect the business to the Internet as well performing many other business functions like purchasing. It makes sense that payments will also be processed over these lines giving the merchant the same advantages larger merchants enjoy via leased line at a fraction of the cost.

Both dial and lease line solutions are considered secure and send the data in plain text, unencrypted. Unlike the Internet that sends packets of data through various open channels, dial and lease lines are direct connections between the merchant and the processor, so the risk of transactions being intercepted by criminals is considered minimal.

CyberCash

In the 1990’s the Internet started to become popular. CyberCash, a Gateway Provider, saw this as an opportunity to offer Internet connectivity between the merchant and the Processor. CyberCash built a network abstraction lawyer between their systems and the Processors.  That’s what CyberCash is, basically an Internet Gateway that takes encrypted (SSL) transactions in from merchants over an Internet connection and routs the transactions to the appropriate Processor via lease lines.

IP

The Processors eventually recognized that the Internet was here to stay and some have added the ability to allow merchants to connect directly to them via the Internet bypassing CyberCash. This process is still going on today. However, even with direct connectivity to the processor, the merchant, unless they use a third party solution, is still required to implement processor specific interfaces and certify the solutions with the processor.

Distributed Applications

In order to understand where payments are headed you must first understand where they came from.   Payment applications were originally placed inside payment terminals. Terminals are still very well suited for the small mom & pop businesses. However, as businesses grow and they perform more and more transactions a terminal becomes impractical as a stand-alone dial-up connected solution. Consequently, the terminals have become input devices and another application tier is added to process the transaction. This tier could be integrated into a cash register, point-of-sale system, in-store controller or centralized server managed via a VPN connection or over the Internet.

By using an n-tier architecture, you can isolate business logic from the user interface and database storage. This increases the flexibility and scalability of the application. Separating the application into multiple layers allows the components of one layer to be modified without affecting the other layers. For example, this allows the user interface to be changed without changing the business login or database design.

N-tier architecture also allows for more physical hardware to be used in an application. If the bottleneck of an application is in the business logic layer, additional machines can be added to scale the application. The distributed processing among machines can be load balanced using a variety of algorithms.

In an n-tier architecture, the presentation layer never access the data storage system directly. This paves the way for “thin” client application such as Web browsers to serve as the front end for an application. Thin client solutions are a requirement in today’s Internet environment, where the Web browser is becoming the universal front-end application.

The Next Generation – Web Services & Thin Client Solutions

I believe the next generation of payment solutions, for all but the largest merchants, will be thin client solutions accessed over the Internet using standard HTTP & HTTPS Internet protocols. Thin client Web Services will provide applications developed with integrated credit/debit authorization support, faster transaction processing, new technology, more and better customer data, ease of upgrade as banking requirements change, security against fraud and errors, lower cost, and cross-platform support.

The power unlocked by Web services represents an evolution in the use of the Internet. Where browsing used to be the focal point, applications can now use Web Services to create value-added solutions quickly and easily. As the integration of services occurs, the Web will rapidly become the essential fabric that ties together all computing devices.  The standards driving the next generation will be:

      - Internet – Web services connect through the Internet; a safe requirement given the high availability and low cost connectivity provided the Internet.

      - XML – eXtensible Markup language – A language like HTML but extendable through custom tags that is becoming the standard way for communication between devices, web browsers, computers, servers and applications.

      - SOAP – Simple Object Access Protocol (SOAP) - A protocol for encoding messages between servers using industry standard HTTP & HTTPS. SOAP provides a way to call other services through a common protocol.

These four principals enable businesses to connect, find, transform and transact business across systems, applications, and processes to deliver XML Web services. XML Web services are flexible technologies that bind disparate systems across different languages, unifying personal computing, enterprise computing, and the Web. As long as the fundamental communication occurs via XML Web services, each system can be independent from the others, with each “service” running on entirely different systems, even in different parts of the world.

Technologically speaking, SOAP and XML will do the most to move applications to Web Services. SOAP began as XML-RPC, a protocol designed by Dave Winer of UserLand Software. Microsoft, UserLand and Developmentor then rewrote and expanded it. With the backing by IBM and Sun, the specification is positioned to become the defacto standard for loosely coupled application interaction. Basically, it is a lightweight protocol that allows any two applications to talk over the Web, regardless of the platform they run on or the object models they support.

Future solutions will be designed so merchant service providers can configure and setup accounts remotely with a browser over the Internet

(even programmatically). This approach will provide all the advantages software-only solutions offer and eliminate all the issues that plague software only solutions. As the Internet matures and is developed to provide low cost connectivity that is secure and reliable it is reasonable to assume that the trend will be towards Web services and thin client solutions.

Barriers to Thin Client Solutions in the Physical World

Thin client solutions have become the standard for the virtual e-commerce applications. Internet shopping cart systems have used a thin client implementation for years. There is a strong division among physical world (retail) industry insiders regarding the potential retail applications to use a similar implementation. This is important since VISA estimates (2001) that between 95-97% of all credit card transactions are performed in retail. The barriers to wide spread adoption to a thin client or Web Delivery payment implementation for retail include the availability, reliability and security of high-speed Internet lines to support the application.

         - Availability -- Many believe that low-cost, high-speed Internet access such as DSL or cable modems are simply not pervasive enough yet to support a Web Delivery implementation across the country.

         - Reliability – Businesses using these high-speed connections today acknowledge that the service reliability is just not there to support mission-critical applications such as retail. In the Web Delivery environment, in communications go down so does the store.

         - Security – Many customers are just not willing to open up their retail store to the potential for hackers to gain access to the registers and data.

These are valid concerns and must be addressed before wide spread adoption will occur in retail. It is my opinion, that ultimately these issues will be addressed but it will just take longer than everyone anticipates. The fact that as of the year 2000 40% of all PC retail systems are still running DOS is an indication of how slow the industry is to change. There must be compelling value-added benefits to drive the adoption of new technology. It is my belief that this will ultimately happen, there are just too many benefits and too much money being spent on the infrastructure not to alleviate the above issues; however, early implementation will probably support bridging technologies to offer the redundancy and piece of mind for the retailer.

Bridging Solutions

Due to the above issues, I believe intermediate solutions will pave the way for all but the smallest businesses. In-store payment servers will provide this bridging technology. They will reside at the business location and provide the payment processing functionality for these businesses. For large businesses, it just does not make since to outsource their payment processing and pay additional fees for each transaction.  Instead larger businesses will pay more upfront and own the technology and maintain it in-house, so called enterprise solutions. Smaller businesses will continue using dial-up payment terminals, PC based solutions and the outsourcing of payment processing to third parties. Over time the Internet will become ubiquitous and transparent and more and more payment processing will be outsourced to the thin client model.

XML

XMLPayments is a payment syntax for payment transaction requests and associated responses in a payment-processing network based on XML. XMLPayments is an enhanced version of XMLPay proposed by Ariba, Verisign and Microsoft. XMLPayments is intended for use in both Business- to-Consumer (B2C) and Business-to-Business (B2B) payment applications. The mechanics of how the requests are passed to server processing components is left unspecified by XMLPay. XMLPaymnets uses SOAP.

XML offers an ideal syntax for processing payments. When the industry changes and new data elements are required, new tags can be easily added without breaking the system. If the new tag is not present the system processes just like it did previously. However, if the new tag is present the system can utilize it. Combining XML with a loosely coupled transport protocol like SOAP and this approach offers the best of both worlds.

It is too early to tell if this specification will become a standard.  We utilize a modified version that contains the enhancements I needed to make the API support both the physical as well as the virtual payments world. These modifications were added as optional elements to the original XMLPay specification. It is my hope that ultimately the industry will have one universal standard that works in both the physical as well as the virtual worlds

Processing Companies

Signing up merchants, selling and servicing payment devices, switching transactions from terminals to the correct card system and doing much of the processing that results in a cardholder receiving a bill are the roles, in the U.S., that are now filled by third-party Processors.  These Processors work on behalf of all the systems. You can present just about any card type and provided the merchant has chosen to accept that card the transaction will be run through the same terminal (at least in the United States).

First Data Corporation is by far the leading processor in the payment card industry and it has grown rapidly over the years by acquiring other processors. Before it was spun off by American Express in 1992, it served primarily as a third party processor for both acquirers and issuers. In 1995, First Data acquired NaBanco and Card Establishment Services, two of the largest processors in the industry making First Data the largest merchant acquire processor overnight.

Total Systems Services (TSYS) is the second largest backend Processors experiencing substantial growth as many large banks like Bank of America turned over in-house processing systems to Total. Total teamed up with Visa to form a joint venture call Vital Processing Services. Vital is a combination of Visa’s old VisaNet network and Total’s backend system to provide end- to-end electronic authorization and data capture as well as clearing, settlement processing and merchant accounting, billing and reporting functionality.  Total has bought out Visa and the network is now known as TSYS.

Processing and authorization centers have been established throughout the world by Visa, MasterCard, and third-party processors to facilitate authorizations and merchant /cardholder accounting. Processing companies require sophisticated equipment with fail-proof backup systems, because data must be retrieved in the event of a system failure. Many banks process the transactions themselves in most other countries of the world where there are only a few banks per country.  In the U.S. where there are hundreds of banks it became uneconomical for each bank to develop their own processing center. Consequently, most U.S. banks use third party processing companies to handle the authorization and interchange for which they pay a fee. Using Processors eliminates the investment associated with operating one’s own network.

These processing companies play an important role in the U.S. There are about a hundred different processing companies in the U.S. while about 10-15 of the major companies have 80-90 percent of the business. A list of the major processors in the U.S. is provided in Appendix IV. Unfortunately, from an application developer’s perspective, each processor developed their systems independently and no standards were established. In fact these differences are how the companies differentiated their services to prospective customers and increase switching costs.

The lack of standards has made it difficult and expensive for technology- based solutions to be introduced that could be marketed to the industry as a whole. Each new technology would have to be developed for each processor separately, representing an expensive and time-consuming process.

This lack of standards has inhibited the credit card processing industry from embracing new technologies until they have been proven. In effect, this lack of standards has created a barrier to entry for new products. This has resulted in domination by a few companies.

Terminals

According to Credit Card Management, it is estimated that in the U.S. and Canada 1,630,335 traditional payment terminals were sold in 1999, up 6.1% from 1998.  The major players include VeriFone –38% share, Hypercom –28.2% and IVI Checkmate--15.5% with the balance going to other niche players like Lipman U.S.A. It is estimated that terminals still provide the majority points- of-sale and perform a large percentage of the transactions.

Vertical Industries

In order to reduce the likelihood of fraud, expand the industry, and better understand the data, the bankcard associations divided up the various industry segments (called verticals) and instituted different process, procedures and data requirements for each vertical. Verticals were created to expand the industry and to handle different transactions more intelligently. The rule of thumb is when you don’t know the amount of the final transaction at the time of authorization then you have a new vertical. For example, the logic followed to process a retail transaction differs considerably from processing a restaurant or hotel transaction   In a restaurant transaction the final amount of the transaction is not known at the time the transaction is initiated. In your basic retail store, this is typically not an issue. The customer has decided what merchandise they want and the costs are all known at the time of purchase. However, in a restaurant when the merchant authorizes the card the tip amount is not known at the time of authorization.  When you check into a hotel the merchant does not know if you are going to make any additional purchases on your card like room service.  For these reasons the card associations created a number of verticals with specific rules and regulations on how the transactions need to be processed and what data needs to be sent and when it should be sent.

The bankcard associations publish specifications for “compliance” with their operating regulations. Adherence to the specifications insures the merchant qualifies for the lowest bankcard interchange rates. Application developers need to understand these rules and know how to implement them in their applications so that the merchant will receive the lowest rates possible.  The different vertical industries covered in this guide are Retail, Supermarket, Restaurants, Hotel/Lodging, Rental, Automated Fueling, Direct Marketing and Electronic Commerce.

Card Present Environments

Retail – Environment where the final transaction amounts are known and card and/or cardholder are physically present at the time of purchase.

Supermarket – A segment of retail that sells food and/or food products in large volume. This segment was created to expand card usage.

Restaurants – Establishments that serve food and where tips are applied to the total amount. Restaurants frequently use an authorization expansion factor where the pre-authorization is 120% of the actual dinning amount to accommodate the subsequent addition of the gratuity.

QSR – Quick Service Restaurants, movie theaters and parking lots are permitted to accept credit card payments for totals under $25 without an on- line authorization and signature. MasterCard put the regulations in place in

1991 but they are just starting to be embraced with the expanded usage of credit cards. This program allows the application to do what is known as “store and forward”. That is, the application stores the transaction information in a temporary file and forwards it on to the processing network at a later time.  The program provides limited chargeback protection for merchants, protecting the merchant even though they have no signature or receipt to verify the transaction.  The main application is in environments that need increased speed at the point-of-sale.

Hotel/Lodging – Merchants providing a facility for the cardholder to reside. Three customer bases are supported: Standard Customer, Preferred Customer and Prestigious Property. A Standard customer would include any typical retail transaction while a Preferred customer indicates the merchant and the cardholder have establish and are participating in a preferred relationship program. An additional Prestigious Property merchant exists with Visa where the merchant can use Visa’s status check authorization service.

Rental – Merchants providing rental products can use the auto/rental vertical. These Industries include auto, tool, and other rent and return equipment businesses.  Two customer bases are supported Standard Customer and Preferred Customer. A Standard Customer would include any typical retail transaction while a Preferred Customer indicates that the merchant and the cardholder have established and are participating in a preferred relationship program.

Automated Fueling – Transactions that occur at customer activated automated fueling systems need only perform a $1.00 pre-authorization before fueling. The authorization code obtained is then valid for up to a $50.00 dispersal of fuel. Fueling amounts in excess of $50 should occur as “over-the-counter” transactions where the card is physically present.  The transactions that occur at the automated fuel dispenser must be settled separately from the over-the-counter transactions.

A note about Receipts – Card present environments are required to print a receipt and obtain a customers signature. California Senate bill 930, which passed in August 1999 and took effect on January 1, 2001 for all new equipment, requires all companies that accept credit cards for transactions of business shall only print the last 5 digits of the credit card account number and shall not print the expiration date upon the receipt provided to the cardholder. This means the application may need to print two different receipts one for the merchant with the complete information that the cardholder signs and an abridged version for the cardholder.  Affective October, 25, 2002, the card associations (Visa & MasterCard) mandated a new regulation requiring the cardholder receipt to suppress the all but the last four digits of the cardholder account number and the entire expiration date.

Card Not Present Environments

Direct Marketing/Mail Order & Telephone Order (MOTO) – Direct Marketing or MOTO environments are classified as businesses where the card and/or cardholder are not physically present at the time of purchase.

Electronic Commerce – Environment where the card and/or cardholder are physically not present at the time of purchase and the transactions that are authorized over an open network (i.e. transactions processed over the Internet).

Visa defines an electronic commerce transaction as:

"A transaction conducted over the Internet or other network using a cardholder access device, such as a personal computer or terminal."

This definition addresses the interaction between the consumer and the merchant. The focus of the regulation is how the card data is received, NOT how it is processed. This means that regardless of how you process that transaction, if you receive the order and card data over the Internet that transaction must be flagged as an electronic commerce transaction. Note that this definition applies even if you use a dial-up terminal to process your transactions because how you process the transactions is irrelevant. All orders received over the Internet must be flagged as Electronic Commerce transactions regardless of the connection when the order was received or even if you are not connected to the Internet when you process the transactions.

All Electronic Commerce Transactions require that the Electronic Commerce Indicator (ECI) Flag is set. Your EPS Software should have a setup procedure where you can indicate that your business is “Electronic Commerce". 

Note - if a merchant has a retail and Internet presence they are required to have two merchant accounts, one classified as retail for the retail side of the business and one classified as Electronic Commerce for the Internet side of the businesses. The transactions must be kept separate and processed according to their respective industry regulations. Internet transactions need to be identified as such and the encryption level needs to be designated.

Recurring/ Installment Transactions - Recurring Transactions support recurring, authorized non-face-to-face transactions in the insurance, utility, telecommunication and cable industries. This segment was created to expand card usage. Installment transactions are reoccurring transactions with a fixed number of payments. For example, you purchase a product and pay $100 per month for the next 12 months. Both types of transactions must be flagged to indicate that they are a reoccurring transaction when sent to the Processor and installment transactions require the transaction number as well as the total number of installment payments.

In addition to the different verticals merchants may need to support different types of bankcards.

Commercial Cards - Commercial Cards come in three levels, I, II or III.

Level I cards are the standard bankcard with no additional data required. Level I cards are processed as standard credit card.

Level II Cards are identified as commercial cards and require additional data elements upon settlement (i.e. sales tax and a code provided by the purchaser to identify the transaction this code is called customer code or P.O. number) to qualify for the best discount rate. Commercial cards can be further defined as level III which requires transaction item level detail in addition to the sales tax and P.O. number. Commercial card types include Corporate, Purchasing and Business. A Corporate card is usually issued to the employees of a corporation, where the corporation assumes all liability for the card's usage. This is usually issued to larger corporations. The Purchase card is issued to corporations. It allows the corporation numerous parameters to control daily and monthly spending limits, total credit limits, and where the card may be used. Many employees may be issued the same card number. The Business card is similar to the Corporate card, but is issued to a business with a few employees and where each employee is responsible for their purchases.

Commercial Cards are authorized as standard credit cards. The card bin number or the authorization process returns an indicator that designates the card is a Commercial Card. Depending on the type of card, Level II or Level III, the appropriate additional data needs to be provided during settlement.

An important issue to understand about Commercial cards is that not all cards can be identified ahead of time by a pre-defined bin range. In order to maintain flexibility and probably poor planning, not all card issuers provide up-to-date bin ranges for all commercial cards. The way you determine if a card is a Commercial card is when performing the authorization you set a parameter requesting the Processor to return an indicator identifying whether a card is a Commercial card and what type. The implication is that you may not know whether a card is a Commercial card at the time of authorization. This means that you must provide inputs for the sales tax and customer code for every authorization and/or provide a mechanism to input this data after the authorization is performed and before the transaction is settled if the card is a Commercial card.

Private Label Cards – Private label cards are non-bankcards that are typically issued and can only be used at the authorizing businesses. For example, the Sears card.

Anatomy of a Credit Card Transaction

In order to develop a proper system you need to understand the credit card transaction flow. When a card is issued the cardholder is given a credit limit. This is the amount the cardholder can charge on their credit card. They also have a balance that is the total amount that they have previously charged.

The difference between their balance and credit limit is called their open-to- buy.  For example, a cardholder has a $5,000 credit limit and they have an out standing balance of $1000, therefore they have and open-to-buy of $4000.

There are three parts to a credit card transaction, the “Authorization”, “Capture” and the “Settlement” of the transaction. This process originates from the history of the card industry. The authorization originated from the need to verify the card was valid and the cardholder had an open balance that was within their credit limit. This is analogous to calling the system on the phone to verify this information. The system would reduce the cardholder’s

“Open-to-Buy” and return an approval code that would be placed on a deposit slip that would then need to be deposited in the bank. “Capture” is the process of finalizing the transaction and adding it to the day’s batch of transactions to be ‘Settled’. “Settling the Batch” is the process of submitting the batch to the Electronic Draft Capture (EDC) system. This is analogous to taking the deposit slip to the bank and depositing it. If you did not deposit the slip, you will not receive your funds. The same is true for credit card transactions, if you do not capture and settle the transactions; the merchant will not receive their funds. These steps are very important for the application developer to recognize and take into account when developing their application. If a transaction has been authorized but not captured the cardholder’s open-to-buy will be reduced by the authorized amount for about a week (the specific amount of time varies and is dependent on the merchant’s financial institution). Once this time threshold has been reached, the authorization goes stale and the open-to-buy is returned back to the original amount and authorization code is no longer valid. A reversal (which is explained later) is a transaction that provides this functionality manually.

The Authorization

The authorization request is the electronic message that is sent from the merchant POS system to the consumer's credit card issuing financial institution for approval of the transaction. The credit card issuer will return one of the following responses to the authorization request:

          Approval -- transaction was approved

          Decline -- transaction was not approved

          Referral -- response pending more information, call card issuer for assistance

If a transaction receives an approval, the merchant can “Capture” the sale for financial settlement.

If address information, zip code and street address, are provided during authorization, the authorization process will also return the AVS response. If the CV data is provided, the response will also indicate the CV match. An additional indicator can also be set to check if the card is a Commercial card. If this indicator is set, the authorization process will also return a code indicating whether or not the card is a Commercial card and the type of Commercial card.  If it is a Commercial card, the application developer will need to prompt for level II and/or level III data elements. These additional response values will be covered in detail later in this guide.

Capture

The action of indicating that a credit card transaction will be sent to a financial institution for settlement is called the “Capture” of the transaction. This process places that transaction into the day’s batch for Settlement.

Reversal

A reversal is a transaction that reverses the authorization – increasing the cardholder’s Open-To-Buy and invalidating the original authorization. Reversals are typically used to appease unhappy cardholders who can’t use their cards because their open-to-buy has been reduced unnecessarily.  For example, a cardholder purchases an item on back order, the system authorizes the card, and then the cardholder cancels the order. Another use of reversals is to insure the settlement amount equals the authorization amount. Failing to do so will result in a downgrade. For example, a cardholder purchases 3 items on back order and 2 show up the next day. If the system settles for the amount of 2 items when the original authorization was for 3 items the authorized and settlement amounts will not meet Visa and MasterCard’s zero tolerance requirement and the transaction will be downgraded (these requirements are covered in detail later in the guide). Consequently, the system will need to reverse the original authorization and perform a new authorization for 2 items (which should be settled upon shipment) and then perform another authorization for the 1 remaining item. Side note - the system will also need to adjust the amounts if there are any changes in shipping and handling costs. This zero tolerance limit is what complicates the MOTO/electronic commerce industries.

Batches

The payment industry’s multi-step process resulted in batches. A batch is simply a collection of transactions. Usually a merchant has one batch per day or per shift. Batches offer merchants a way of integrating payments into their business processes. For example, a business may close out their accounting books at midnight; they would close their batch at the same time to ensure the day’s transactions are in sync with their books. Other businesses close

out their registers with shift changes and they may close their batches at the same time to make reconciling easier.

Settlement

The action of submitting a credit card sale for financial settlement is called “Settlement” of the transaction. When a merchant requests or initiates the settlement of “Captured” transactions, the sale amount will be credited to the merchant's deposit account through their acquiring financial institution and posted to the cardholder's credit card account. The settlement is analogous to filling out the deposit slip and submitting it to the bank. The merchant typically does not get immediate access to funds upon settlement. Just like if you deposit a check it takes several days for the check to clear. The merchant will need to determine this time lag from their merchant service provider but it is typically in the range of 2-3 days.  However, large merchants like Wal- Mart perform multiple settlements during the day and get proprietary treatment to access of funds due to their enormous clout. Consequently, if you are developing for a large business you may want to consider the business implication of delaying settlement.

Settlement Methods

There are two main types of settlement methods, “Terminal” settlement and “Host” settlement.  The merchant's acquiring financial institution will determine which settlement method they will be required to use. Merchants with questions about which settlement method is best for them should discuss it with their acquiring financial institution.

The difference between the two settlement methods lies in where the authorized and captured transactions are stored awaiting settlement and the action that is required to settle them. Under the terminal settlement method, the authorized transactions are stored locally in a shadow file until the merchant captures them and submits them for settlement. Under the host settlement method the authorized and captured transactions are stored at the acquiring financial institutions or third party Processor's “Host” computer awaiting settlement. Host based systems typically refer to the process of settlement as closing the batch.

Host based systems can be setup to be auto close or manual close. It is important that your applications support both methods and the merchant knows how they are setup. Remember, if you don’t close your batch and settle your transactions the merchant will not receive their funds.

Many new and small merchants when they first start accepting credit cards do not understand this important settlement step. With Terminal systems they don’t settle. With Host based systems they may not realize they need to manually close their batch. In both instances, the merchant’s do not receive their funds and they become very upset. The application developer should take this into account by providing a mechanism to automate this process in the end-of-day procedure or logout procedure. Another technique is to provide and end-of-day screen which prompts and reminds them to perform this important step.

Once the batch has been adjusted and verified to be correct, the batch will be closed. In Host based systems a close message is sent to the processor. Depending on the Processor, this close message may need to indicate the total number of transactions and the amounts. In these systems if they don’t match, the batch can’t be closed and will need to be adjusted. Other Host based systems close regardless and the merchant must reconcile the batches when they get their merchant statement. In Terminal based systems, the EPS re-transmits each transaction in the batch to the processor and, if they are accepted, the batch is closed.

With regards to Settlement, Terminal based systems are typically very binary, meaning that the batch is either settled or not settled. Consequently, if there is a single bad transaction in the batch the whole batch is not settled. An example of how this could happen is a stale authorization is submitted and rejected by the Processor. The typical response of the merchant should be to record the rejected transaction information, void the transaction to remove it from the batch and resubmit the batch for settlement. Once the batch has been settled, the merchant should try and re-authorize and capture the transaction. If there is an error trying to perform this step the merchant will need to contact their merchant service provider and possibly the cardholder to get the issue resolved. Otherwise, if the transaction is authorized and captured it is recommended that the merchant then try and settle this transaction as a single item in the batch. That way it won’t pollute the next day’s batch if there is an error and if there is an error the merchant has isolated the batch and it will make it easier to resolve the issue with their merchant service provider.

A third system has been developed by First Data’s (the largest payment Processor in the US) Omaha platform, which is a hybrid Terminal, & Host based system. This system requires the EPS to send a close message with account totals and if they match the batch is closed. However, if there is a discrepancy the Processor optionally verifies each transaction with the EPS systems in an attempt to determine the discrepancy.

Once the batch is closed the information from the Processor’s system is submitted to the bankcard associations for ultimate financial settlement. This information includes the total number of transactions by card type and the amount of each transaction.

The emergence of Gateways has created a fourth option. It is what I call a virtual host. That is the gateway can create a single interface regardless of capture method and give the appearance to the application developer that all merchants are Host based. The line item transaction information is stored on the Gateway rather than locally at the POS. This approach relives the application developer the pain of storing and re-transmitting the transaction information to the Processor. If the Gateway has also been developed properly it should offer the application developer the best of all worlds; 1) The option to settle manually or automatically at a predetermined time.  2) The option to adjust batches at no additional cost prior to settlement. 3) A single simple command to settle. The Gateway will then transmit the information to the processor based on their requirements invisibly to the application developer.

In my opinion, Gateway systems provide the best of all worlds by providing a constant abstraction layer were application’s send adjustments to the Gateway regardless of Processor and the Gateways decides to make the on- line - off-line adjustment based on the merchant’s processor requirements invisible to the application developer.  The Gateway can also be designed to handle rejected batches in a way that makes life easier for the merchant. If a batch is rejected the merchant typically voids the transaction from the batch and re-submits the batch for settlement. A Gateway could do this automatically. The Gateway should get the batch to settle and provide an alert to the merchant with the rejected transaction information.

For the above reasons I believe that payments, for all but the largest merchants, will move to a thin client architecture where the Gateway acts as an abstraction layer between the application and the Processor. The adoption of this architecture minimizes the work the developer is required to implement and allow for seamless dynamic updates.

Batch Inquiry

The need to reconcile the batch with the processor has and the merchant created the batch inquiry. The batch inquiry is a request for information sent from the merchant to the processor that simply returns the total number of transactions and amounts for the designated batch. Typically batch inquires are for the current batch; however, some systems provide support for previous batches.

Typically businesses verify the transactions, how many and how much, with their local POS/accounting system against the EPS. The application then makes any adjustments, prior to closing the batch, that are necessary to get the two systems in sync. In Terminal based systems batches can be adjusted off-line by modifying the local shadow file. In Host-based system where the host computer stores the transactions the adjustments must be made on-line by contacting the host computer. For this reason terminal based systems are ideally suited for businesses that need to adjust the transaction prior to closing. For example, restaurant systems will adjust the batch with the actual tip amount prior to closing the batch.

Terminal Based Systems

Terminal-based systems authorize the transactions, but retain local files that are resubmitted to the credit card processing company when the batch is settled. When settling each transaction is resubmitted to the Processor with all the original information; including the approval number you received when the transaction was authorized.

Terminal based systems only contact the Processor to authorize transactions that are called on-line transactions and to settle the batch. Off-line transactions such as credits do not need to be handled in real time and are only added to the batch at the point-of-sale and are processed during settlement.

Host Based Systems

Host based systems capture and store transaction information in the credit card processing companies host computer. Information on each transaction is stored in the host computer. The host computer maintains a cumulative balance of all transactions for the day. Consequently, every transaction requires a contact or phone call to the host computer to update their system.

Host based systems still maintain a batch of the days transactions, but since the host computer has stored the transaction information, it does not need to be re-sent to close the batch. The process of settling the batch in a host-based system is called “closing the batch”. Host based systems offer two different methods of closing the batch:

  1. Merchant Initiated
  2. Time Initiated

Merchant Initiated closing of the batch consists of verifying that the totals on the Point-of-Sale terminal match the totals on the host computer system. Once a batch is closed, the host computer resets all transactions to zero and the next transaction begins building a new batch.

Time Initiated closes happen automatically. The host computer closes the batch at a specific predetermined time, for example 12:00 midnight every day. This guarantees the merchant a least one daily batch. The merchant still has the ability to verify the transaction totals with the host computer (a batch inquire) but is not required to issue a specific close request to the host computer.

On-Line and Off-Line Transactions

An on-line transaction is a term used to describe whether the system needs to contact the Processor to perform a transaction in real time typically by a phone call. Depending whether your Processor is Host based or Terminal based your EPS system will not contact the processor for each transaction. It is important for the merchant to understand what is expected with each transaction.  I can’t tell you the number of times new merchants would get our software and perform a Credit. They would not hear the system dial-out and would think nothing happened. Consequently, they would do it again and again….  Some would call and we would step them through the process of Voiding all the extra Credits, others would Settle and would have to perform Sales to counter all the Credits and everything would be all messed up. So it is important that new merchants are educated as to what to expect for each transaction.

Implementation Considerations

When and how to capture the transaction is extremely important and needs to be thought through the business process.  The application developer will typically place the settlement step at the close out of the register or the end of day posting. Once the transactions have been settled the money can be posted to the accounting totals for the day.

Advantages of Terminal Based Systems VS Host Based Systems

The fact that off-line transactions are not processed in real time can reduce costs for merchants who perform many off-line transactions. The merchant is charged for each phone call and by reducing the number of phone calls the merchant can save money.

Terminal based systems are ideally situated for merchants who don't know the true transaction amount at the time of authorization. An example would be a restaurant. What restaurants do is estimate the tip amount, and add that to the bill to get an authorization for that amount. This sets aside the authorized amount from the cardholder’s open to buy. This type of transaction is called an authorization or pre-auth. After the receipt is signed the merchant enters the tip amount to adjust the final amount to the batch. This transaction type is called an authorization completion or post-auth.  As long as the tip amount is within the amount tolerances the authorization number is good and can be settled.

Disadvantages of Terminal Based Systems VS Host Based Systems

Perhaps the biggest disadvantage is that settlements must be performed every day. It is very easy to forget. If a merchant forgets to settle their batch they lose the use or float of the money until they settle and their transactions will be downgraded.

Terminal based systems retransmit all the transaction information to the credit card processing company during settlement. This process can be very time consuming if the merchant has a lot of transactions in their batch. Every night the merchant must stop what he/she is doing and tie the system up while settling their batch. Each transaction will take about 1-3 seconds to re- send to the credit card processing company. If it is a large merchant that has

1000 transactions this could tie up the computer system for up to 50 minutes. Another problem is the batch is either settled or its not. Off-line transactions are validated; during settlement and if invalid information is entered it will not show up until the batch is settled. If invalid information is found, the whole batch is rejected. The invalid transaction will need to be corrected and the batch will need to be re-submitted. This is a very real problem because it is very easy to enter invalid information during the post-auth, such as a typo in the original authorization number. This results in the whole batch being rejected. The merchant with 1000 transactions who has an invalid last transaction is not very happy watching the batch settle for 50 minutes only to have it rejected on the last transaction. They must correct the problem and then resubmit the whole batch all over again.

Advantages of Host Based Systems VS Terminal Based Systems

The major advantage is that your account can be setup to have your batch closed automatically and it is one less thing the merchant needs to do every day. Even if you want to manually close your batch, it is very fast because you don't have to retransmit each transaction back to the host computer, because it is already stored there. The batch close happens very fast (15 seconds). This can be a big time saver for large merchants.

Tip: Because host based systems can automatically close the merchant batch, time initiated close eliminates the float loss caused by merchants who might otherwise forget to close the batch at the end of day. By automating the balancing and close procedures, time initiated close reduces the cost because there are no charges for on-line balancing and batch corrections. However, there may be errors in the batch, possibly resulting in incorrect items being out cleared to the merchant. Therefore, a time initiated merchant should perform a batch inquire to the host at the end of the day to verify that the host totals match the merchant records. Otherwise, the merchant will need to reconcile the batch after the fact.

Disadvantages of Host Based Systems VS Terminal Based Systems

The main disadvantage is that, because the host computer stores every transaction, it must be notified of every transaction and that requires a phone call. If you are charged for each call you make you will incur additional expenses if you perform many transactions that could be performed off-line in a terminal based system. For example, the restaurant which pre-auths the estimated transaction amount and then post-auths the true transaction amount would require two separate phone calls. If the merchant is being charged for each phone call they would be incurring additional expenses verses a terminal based system.

Payment Service Programs - Vertical Industries

As mentioned previously, each of the card associations created Payment Service Programs to support the various vertical industries. Electronic payment systems (EPS) must comply with various industry regulations, such as Visa’s CPS, and MasterCard ICP programs.  In order to achieve the most favorable discount rates, the authorization and capture system must be able to reliably transport any addition data elements required such as tax amount data from card authorization responses to the eventual settlement.

Integrated POS systems implementing the interface described by either the CPS or ICP interface must take responsibility for transport of Payment Service data; in addition to this data requirement, transactions must have the following characteristics to qualify for best-case retail interchange rates:

2000 INTERCHANGE CRITERIA

The information in this section is to provide you with the guidelines and criteria used for qualifying transactions for the different rates as designated by Visa and MasterCard.

Card Present Environments

RETAIL / RESTAURANT

Qualified Transaction Conditions: (Visa: CPS Retail/ MasterCard ICP

(Retail): Merit III, Corporate Face to Face, International Electronic) Integrated POS systems implementing the interface described by this interface must take responsibility for transport of Payment Service data; in addition to this data requirement, transactions must have the following characteristics to qualify for best-case retail interchange rates:

•    Card is present, full magnetic stripe is read by the terminal and signature is obtained.

•    If the magnetic strip cannot be read the merchant must key in the transaction information including AVS data – cardholder’s billing zip code and street address.

•    If the magnetic strip cannot be read the merchant must key in the transaction information including CV data – card’s CV data.

•    Retail transactions must be conducted using a swipe card reader when possible. The contents of the Entire swipe or Track 1 or Tack II data must be delivered to the processors unaltered. This swipe data cannot be stored for future transactions.

•    The authorization must be accomplished electronically either the same day, or the day before the transaction settlement date.

•    A single authorization must support the settled transaction.

•    One electronic authorization request is made per transaction and transaction/purchase date is equal to the authorization date; authorization response must be included in settled transaction

•    Authorized transaction amount must match settled (deposit) transaction amount, except for restaurants, where transaction amount must be within 20% of original authorized amount

•    Additional data (sales tax and customer code) is required in the settled transaction on all Commercial cards at non-Travel & Entertainment (T&E) locations (see Commercial Card section)

•    Transaction must be authorized and settled under a standard retail industry code

•    Transaction electronically deposited (batch transmitted) no later than 1 day from transaction/purchase date

Partially Qualified Transaction Conditions:

(Visa: CPS Retail 2 (Developing Markets), CPS Card Not Present, EIRF/ MasterCard: Key Entered, Merit I, Electronic Commerce, Corporate Data Rates II & III, International Corporate Purchasing - Data Rate II)

•    One or more of the Qualified conditions were not met, or

•    Transactions electronically deposited (batch transmitted) greater than 1 day but within 2 days of transaction/purchase date

Non Qualified Transaction Conditions:

(Visa: Standard, Commercial Electronic & Standard, Signature Electronic & Standard, Infinite Electronic & Standard/ MasterCard: Standard, International Standard, Corporate Data Rate I, Corporate T&E Rate I & II, Corporate Standard, International Corporate, International Corporate Purchasing, World MasterCard)

•    One or more of the Qualified or Partially Qualified conditions were not met, or

•    Transaction electronically deposited (batch transmitted) greater than 2 days from authorization date, or

•    Commercial card, World MasterCard, Visa Signature card accepted at a T&E location, or

•    Commercial card at a non-T&E location without the required additional data (see Commercial card section), or

•    Visa Infinite card accepted, or

•    Transaction was not electronically authorized or authorization response data was not included in settled transaction, or

•    Transaction was deposited via paper draft

Card Not Present Environments DIRECT MARKETING/MOTO

Qualified Transaction Conditions:

(Visa: CPS Card Not Present/ MasterCard: Merit I, Electronic Commerce, Corporate Data Rates II & III, International Corporate Purchasing - Data Rate II)

•    One electronic authorization request is made per transaction and transaction date is equal to the shipping date. Authorization response must be included in the settled transaction

• Authorization request message must include Address Verification

(AVS) & CV information

•    Transaction/Shipping date must be within 7 calendar days of authorization date

• Settled transaction amount must equal authorized amount

•    Settled transaction must include customer service telephone number, order number, and total authorized amount

•    Additional data (sales tax and customer code) is required in the settled transaction on all Commercial cards at non-Travel & Entertainment (T&E) locations (see Commercial Card section)

•    Transaction electronically deposited (batch transmitted) on or 1 day after transaction/shipping date

Partially Qualified Transaction Conditions:

(Visa: EIRF)

• One or more of the Qualified conditions were not met, or

• Transaction electronically deposited (batch transmitted) greater than

1 day but within 2 days of transaction/shipping date

Non Qualified Transaction Conditions:

(Visa: Standard, Commercial Electronic & Standard, Signature Electronic & Standard, Infinite Electronic & Standard/ MasterCard: Standard, International Standard, Corporate Data Rate I, Corporate T&E Rate I & II, Corporate Standard, International Corporate, International Corporate Purchasing, World MasterCard)

•    One or more of the Qualified or Partially Qualified conditions were not met, or

• Transaction electronically deposited (batch transmitted) greater than

2 days from transaction/shipping date, or

•    Commercial card, World MasterCard or Visa Signature card accepted at a T&E location, or

•    Commercial card at a non-T&E location without the required additional data (see Commercial Card section), or

• Visa Infinite card accepted, or

•    Transaction was not electronically authorized or authorization response data was not included in settled transaction, or

• Transaction was deposited via paper draft

Direct Marketing/Mail Order & Telephone Order (MOTO):

In order to qualify for the best possible interchange rates, a merchant is required to perform Address Verification System (AVS) (U.S. only for now but will soon be international) to assist in determining the authenticity of the transaction request. AVS requires the zip code and optionally the street address of the cardholder’s billing address. AVS runs a verification process during the transaction and verifies that address provided matches the cardholder’s billing address. AVS information is required when performing the transaction but match information is returned for informational purposes only. Meaning that the merchant is only required to perform AVS but the authorization will still take place and the merchant has the option to still proceed with the transaction even if the address does not match.

To request address verification in a card-not-present situation, enter the AVS

information as follows:

1. Enter the street address, including apartment number. For example:

549 Jones St Apt 3

enter as:

549  3

If the address had no numbers in it, just enter the street name. For example:

Park Plaza Central

             Enter as:

Park Plaza Central

If the address is a P.O. Box, enter the P.O. Box information. For example:

P.O. Box 912

             Enter as:

912

2. Enter the 5 or 9 digit ZIP Code. For example:

94109

or

941092133

The AVS Response Codes are as follows:

1. Y – Exact Match – Street address and 5-9 digit Zip code match.

2. A – Partial Match – Street address matches, Zip code does not.

3. Z – Partial Match – Zip Code matches, street address does not.

4. N – No Match – Street address and Zip Code do not match.

5. U – Unavailable – Address information is unavailable for that account number, or the card issuer does not support AVS.

6. R – Retry – Issuer authorization system is unavailable, retry later.

Effective April 2001 Direct Marketing merchants must also provide a new card verification code that is on all bankcards. This code is called CVV2 for Visa, CVVC for MasterCard and CID for American Expresses. For Visa and MasterCard, this is a three-digit code that appears at the end of the account number on the back of the card. These codes do not appear on the front of the card and will not be on the imprint or show up on receipts. For American Express, the CID is a four-digit code that appears on the front of the card above the account number. Merchants cannot store CV data in their database.

Card Verification Value - Card Verification Value is built around two distinct processes:

1.  The first is modeled around AVS where the merchants are predominately liable for all transactions like Direct Marketing/MOTO businesses. Merchants are given as much information about the transaction as possible but it is up to the merchant to decide whether or not to accept the transaction. The Card Verification match Value is returned along with the approved or declined message.  This model essentially leaves the decision to the merchant.

2.  The second is modeled after CVV. The issue evaluates the Card Verification match Value along with other account information. If the account is declined due to the Card Verification Value not matching the decline message will indicate the transaction was declined for CVV2 failure; thus allowing merchants to know why the transaction was declined so they can validate the transaction information manually if they choose.  This model essentially takes the decision out of the merchants hands by default.

Each transaction needs to indicate:

1. CVV is intentionally not provided.

2. CVV is present.

3. CVV is present but illegible.

4. Cardholder states that no CVV value is on the card.

The Card Verification Value Response will be:

1. CVV Match.

2. CVV no Match.

3. Not Processed.

4. Merchant has indicated that CVV is not on card.

5. Card Issuer is not certified and/or on the system.

Will a card not present merchant pay a higher rate if they don’t enter a CV Number ? The answer is maybe – To qualify for preferred rates the merchant must do AVS. If the customer’s AVS did not match what is on record for the cardholder – the transactions will qualify at a higher interchange rate typically around 0.67 basis points + transaction fee above the merchant’s standard interchange. However, having the CV Number can offset the higher interchange rate (if AVS is not an exact match) and better qualify the transaction. The bottom line is AVS will provide you the basis for reduced rates and CV provides add insurance. However, it is not recommend that e- commerce merchants require CV numbers at this time for rate reduction purposes but require AVS instead and use CV numbers for additional fraud control purposes. For example, a high risk merchant that has high incidents of fraud may require CV numbers for fraud protection recognizing that they may discourage legitimate customers who are not familiar with CV numbers. Direct Marketing/Mail Order & Telephone and Electronic Commerce businesses can only bill cardholders for the amount of the items shipped that day. Amount tolerances between auth and clearing are 0%. Consequently, if an item turns out to be out of stock this item amount must be sent as a partial reversal.

In 1994, MasterCard began checking Merchant Category Codes both at auth and Settlement.  This prevents transactions from being 'consolidated' into a single batch at large establishments.  It is possible that this requirement will directly conflict with other card issuers who require that transactions be consolidated under one industry umbrella.  For example, a large hotel property may contain a restaurant, a gift shop, a lounge and the hotel property.  Visa and MasterCard require that all transactions be deposited in the same industry format as they were originally authorized.   American Express requires that all industries be converted to the Lodging format and deposited under the umbrella of the parent hotel.  For this reason it is recommended your EPS software have the ability to split batch deposits by card type and/or industry to ensure transactions receive the best interchange rates and do not reject at settlement.  It is permissible to mix industries within the same batch if desired.

American Express

For all non-retail industries Amex requires processing in the Terminal Capture format and all industry specific data elements must be present.  In the example above of a large hotel property, all transactions must be consolidated under the parent lodging format and merchant number.  An alternative to this would be to obtain separate Amex merchant numbers (SE#) for each establishment on the property.  The Visa/MasterCard and Amex could then be deposited together.

COMMERCIAL CARD ADDITIONAL DATA REQUIREMENTS Visa Purchasing cards - Sales Tax and Customer Code (supplied by cardholder at point-of-sale) Corporate and Business cards - Sales Tax (Sales Tax prompt must be enabled on all Visa transactions) MasterCard Corporate Data Rate II (Purchasing cards) - Sales Tax and Customer Code (supplied by cardholder at point-of-sale) Corporate Data Rate II (Business and Corporate cards) - Sales Tax International Corporate Purchasing Data Rate II - Sales Tax and Customer Code (supplied by cardholder at point-of-sale) The following information must also be provided: Merchant's Federal Tax I.D., Merchant Type, Merchant Incorporation Status, and Owner's full name if merchant is a sole proprietor.

Visa CPS/Retail & MasterCard ICP (Commercial Card)

Support for Commercial Card requirements recently defined by Visa and MasterCard, mandated to complete certification, require that tax and related information be included with settlement (capture) to qualify for best-case interchange rates.  Because tax information is not necessarily available at the point-of-sale, and all credit cards are not commercial cards, there are two root concepts in dealing with these requirements; which is followed often depends on the business model followed by the merchant in question:

Real-Time Auth:  As part of the original authorization, a flag is sent to the host, requesting Commercial Card status of the card number submitted.  The auth response will indicate that type (or not); the POS system can then prompt for tax amount data only when appropriate.

Blanket  If the POS system stores or otherwise manages tax amount data, it is recommended that the tax amount data be included with all settlement detail, regardless of card type - the host will determine import of that data, and pass on where appropriate.  (Thus relieving the user of keying tax amounts on-demand.)

CPS/Hotel  - CPS/Auto Rental  - CPS/Direct Marketing

For those POS systems processing auto rental, lodging or mail order transactions, that wish to qualify for these programs (CPS/94), management of Payment Service data is required. In addition, POS systems must support the following capabilities to qualify for CPS/94:

         - Duration:  (Hotel and Auto Rental)  The first authorization related to an eventual transaction, regardless of whether the card is actually swiped or not, must include a Duration value, indicating the number of days until the transaction will be settled.

         - Payment Service Data:This data must be stored and retrievable for later incremental authorizations, reversals, and eventual settlement.

         - Incremental Authorizations:  (Hotel and Auto Rental only; not allowed under Direct Marketing)  Used to increase the total amount authorized from the original (or latest prior incremental) authorization.  Must contain Payment Service data from original authorization response, as well as incremental amount and duration required.  The POS system must retain both the original, and revised total, amounts authorized.

         - Partial Reversals:  Used to decrease the total amount thus far authorized.  As with a Incremental Authorization, this transaction must contain Payment Service data from original authorization response, downward revised amount, as well as original, and revised total, amounts authorized.

         - Settled Amount Tolerance:  With Hotels and Card Rental program, the final amount must be within 15% of the total (or net) authorized amount. With CPS/Direct Marketing, the final amount must match the net

         - amount authorized exactly to the penny.

         - Address Verification:  (Direct Marketing Only)  The initial authorization must include address verification data.

NOTE:  Even though these programs currently apply only to Visa and/or

MasterCard transactions, the developer should perform this logic regardless of credit card type, since MasterCard and others will likely follow suit in the near future.

Retail

Detailed steps involved in a normal retail credit card transaction:

         - Merchant point-of-sale system calculates the amount of purchase and asks buyer for payment.

         - The payment device is either merchant initiated or customer initiated.

         - Customer initiated devices typically sit out on the counter and allow the customer to swipe the card while the transaction is still being calculated by the point-of-sale system.

         - Buyer presents merchant with a credit card.

         - Merchant runs credit card through the point-of-sale unit. The amount of the sale is either hand-entered or transmitted by the point-of-sale system. The card should be swiped in retail and the card information is manually entered if the card is not present or if the swipe device did not work. If the card cannot be swiped the merchant should perform AVS & CV checking and needs to indicate that the swipe was attempted and not readable.

         - Merchant transmits the credit card data and sales amount with a request for authorization of the sale to their acquiring bank.  In retail, where the customer walks out with the merchandise, point-of-sale units are usually set to request authorization at the time of sale.

         - The acquiring bank that processes the transaction routes the authorization request to the card-issuing bank. The credit card number identifies type of card, issuing bank, and the cardholder's account.

         - If the cardholder has enough credit in their account to cover the sale the issuing bank authorizes the transaction and generates an authorization code. This code is sent back to the acquiring bank.

         - The issuing bank puts a hold on the cardholder's account for the amount of the sale. Note that the cardholder's account has not been actually charged yet.

         - The acquiring bank processing the transaction then sends the approval or denial code to the merchant's point-of-sale unit. Each point-of-sale device has a separate merchant and terminal ID for credit card processors to be able to route data back to that particular unit.

         - In retail, a sale draft, or slip, is printed out by the point-of-sale unit or cash register. The merchant asks the buyer to sign the sale draft, which obligates them to reimburse the card-issuing bank for the amount of the sale.

         - At a later time, probably that night when the store is closing up, the merchant reviews all the authorizations stored in the point-of-sale unit against the signed sales drafts. When all the credit card authorizations have been verified to match the actual sales drafts, the merchant will capture, or transmit, the data on each authorized credit card transaction to the acquiring bank for deposit. This is in lieu of depositing the actual signed paper drafts with the bank.

         - The acquiring bank performs what is called an interchange for each sales draft, with the appropriate card-issuing bank. The card-issuing bank transfers the amount of the sales draft, minus an interchange fee to the acquiring bank.

         - The acquiring bank then deposits the amount of the all the sales drafts submitted by the merchant, less a discount fee, into the merchant's bank account.

         - The cardholder's bank bills the customer.

Detailed steps involved in a normal retail debit card transaction:

         - Merchant’s POS system determines amount of transaction.

         - Customer opts to use a debit or check card.

         - Customer or merchant swipes the card and if it is an on-line debit the customer enters their PIN into a pin-pad.

         - The POS system formats a message to be sent to the processor that includes the transaction total, the raw swiped data from the card, and the pin that is received by querying the pin-pad.  NOTE: the pin received from the pin-pad is an encrypted block of data.  The pin- pad is loaded with an encryption key by the processor and the pin-pad encrypts the pin the customer enters.  A pin-pad therefore will only work for a single processor and only after it is loaded with the encryption key. Depending on the Processor a working key or key pointer value returned from the pin-pad may also need to be sent to the Processor.

         - The POS system sends the message to the debit processor, which may or may not be the same as the credit card processor.

         - The debit processor submits the transaction to the appropriate ATM network and receives an approval or denial, which it passes back to the POS system.

         - The Processor sends the result to the POS system and depending on the Processor and card type the POS system may need to record and update the pin-pad with a new working key or key pointer.

         - If approved, money is transferred out of the customer’s bank account into the merchants account usually within 48 hours.  Note: Debit / Check card transactions are generally a per transaction fee to the merchant rather than a percentage of the transaction total. Therefore, they are much less expensive from the merchant’s perspective.

Steps involved in a normal retail check conversion transaction:

In electronic check conversion, the paper check written by the consumer to the merchant is run through the check-reading device, which captures information about the check including the financial institution, the consumer’s checking account and the check serial number. Simultaneously the transaction amount needs to be entered. This data is then transmitted to an authorization service. Once authorization is received, the merchant prints the receipt, which the customer signs, thereby approving the conversion process. The merchant voids the paper check and returns it to the customers along with a copy of the receipt. The merchant needs digital image of the check for future reference. Later, an electronic file containing data from all the checks processed that day; the batch is submitted to the check conversion company for settlement. The check Conversion Company submits the check information to the Automated Clearing House (ACH) system, where transactions are cleared and settled electronically, usually in 48 to 72 hours.

Detailed steps involved in a normal restaurant credit card transaction:

         - When the bill is presented to a customer and a credit card is proffered for payment, a pre-auth is run for the actual total check amount plus either a set expansion amount (expressed as a percentage) or a manually entered expected tip amount.  If authorization is approved:

         - A sales slip is generated with a spot for the customer to write in the tip amount.

         - Customer adds the tip, signs the sales slip, and leaves.

         - At the end of the business day, prior to the batch being closed, the total plus actual tip amount is added together to form the actual total for the transaction. The authorized amount is edited to reflect the true total amount.

         - If the tip is within the preset Authorization Tolerance (10-15% of total bill), no additional authorization code is needed.

         - If the tip amount does exceed the Authorization Tolerance, an additional authorization  (incremental) must be obtained prior to settlement.

         - All transactions in the open batch are transmitted to the processor for clearing.

Detailed steps involved in a normal card not present (Mail/Telephone/Internet) credit card transaction:

1.   The customer is informed of the amount total for the transaction.

2.   The customer relays the credit card number, expiration date, and CV number from the back of the card as well as their cardholder billing address.

3.   Optional - Check the cardholder's billing address (Address Verification System). If the address passes go to the next step. If the address fails then return to the customer for more information or stop.

4.   The POS system formats and sends an authorization request message to the credit card processor.  This request could be for the entire amount of the transaction or for just what will ship within 24 hours.  Some on-line merchants prefer to just do a pre-auth transaction for $1 in addition to the CV and AVS checks.  The idea is that to comply with MOTO / e-Commerce regulations, merchants can not settle any transaction amounts unless the good or service is sent within 24 hours.

5.   If the entire amount was requested and an approval response is returned from the processor, the merchant will settle the open batch at the end of the business day.

6.   If something less than the entire amount was requested and the product is ready to ship, a second authorization request is generated. If the second request is approved, the goods are shipped and the open batch is closed.  In other words, the application developer must realize that only the dollar amount in payment for a good that is shipped can be charged to a customer’s credit card account.  The particulars of the transaction can be accomplished many ways depending on the particular merchant or industry situation.

7.   If the authorization is done for the total amount and it turns out and adjustment needs to be made – items out of stock, new items added, final shipping charges are different than estimated, the authorization and settlement amounts need to synchronized.

a.    If the final amount is less than the total authorized amount a reversal can be performed to reduce the authorized amount to the shipping amount. Now that the authorized and settled amounts are the same the transaction can be settled. If the transaction is being broken into two, due to a backorder, where you are shipping half the order now and will ship the remaining order when the backorder item come in stock, you need to reverse the transaction amount to the amount being shipped and perform a second authorization for the back ordered amount.

b.   If the final amount is greater than the authorized amount you should capture and settle the original amount and perform an additional authorization for the difference.

How one major book e-tailer does it

1) New customer signs up but does not order books -> $1 pre auth on the first card they enter, nothing is done with subsequent cards.

2) New customer signs up and orders a book -> $1 pre auth  -> when book is scheduled to be picked, the actual auth is done -> rules fraud check  -> ship.

3) Old customer (one who has purchased in the past -> NO pre auth -> when book is scheduled to be picked, the actual auth is done -> rules fraud check -> ship.

If an existing customer enters a new card number, NO $1 pre auth is done.

Net/net - they auth within 48 hours of shipping.

Now that you understand the rules you understand why they are doing what they are doing.

         - $0 auth to verify the card number is valid, AVS, CV values match and additional fraud rules are checked. This process is not repeated unless something changes. This minimizes the cost of the transaction while verifying the card is valid. If it does not pass the test, they can let the customer know while they are still on-line.

         - Order the merchandise.

         - Once they receive the merchandise and know they will be able to pick it and ship it that day. They calculate the shipping cost and process the transactions as a sale using AVS & CV values. This way they know the final value of the transaction when they ship. They also have the flexibility, if not all the merchandise comes in on the same day, they don’t have to modify the original auth with reversals and re-auths to get the amount tolerances between the auth and settlement to zero. They also settle the same day they processed the auth so they are in compliance with the rule that they transaction/Shipping date must be within 7 calendar days of authorization date.

         - If the sale does not authorize, they will not ship the merchandise and will contact the customer via an automated e-mail letting them know about the issue. Worst case, they hold the merchandise and use it to fulfill another customers order or return the merchandise to the manufacture.

Most business people I speak with want to do the full authorization at the time of order. In some cases this makes since. In other cases you may not want to do an authorization at all. One of the great things about Internet or MOTO businesses is you control the time of shipment.  Some business may want to just use the Internet to take the order and process they transaction as an offline transaction using a standalone PC application. Others may want to check the card like the above e-trailer. However the business decides to process the order they need to take the industry rules into account to minimize their cost and insure their transactions are compliant.

Transaction Types

Credit card processing terminals collect transaction information at the point- of-sale and transmit this information to the credit card processing company in real time on-line mode or in an off-line batch-processing mode. The transaction information is submitted to the credit card processing company and authorized and captured by their system.

The basic transaction types available by all credit card processing companies include:

Pre-Auth or Authorization - Sometimes called an auth-only or ticket- only, is a transaction where the merchant verifies the cardholder has the funds available and sets those funds aside and receives an approval code freezing those funds. A Pre-Auth typically sets these funds aside for 7-10 business days and will drop off after this period. The specific time the funds are set aside varies with the card issuing bank and the credit card processing company.

Post-Auth or Force - A Post-Auth is used to enter a sale after an authorization has been done and you are ready to complete the sale. A Post- Auth may be used when you weren't able to complete the sale because a referral message was received, there was a temporary interruption in service and a voice authorization was received, or the final amount of the transaction was not known and the original authorization was done for an estimated amount.

Sale - A Sale is the most common type of transaction performed. This transaction is used for the electronic authorization and purchase. In reality a sale is actually a Pre-Auth and Post-Auth transaction in one.

Void - A Void transaction reverses a sale transaction in the current batch. It reverses the entire amount of the sale. A void must be done on the same business day as the original transaction and will not show up on the customer’s statement.

Note: To reverse a sale transaction that is part of the current batch use the Void transaction. You should always Void a transaction rather than Credit (explained below) a transaction if possible. If you void a transaction, depending on your merchant services agreement, you should not be charged the full discount fee you should only be charged for the authorization because the transaction never went through interchange.

Tip: In terminal based systems have the option of flagging a transaction in the batch as a Void or purging the transaction from the open batch so that it will not be transmitted to the Processor. The end result from the Merchant & Processor perspective is the same; the transaction is thrown on the floor. However, from an implementation perspective the Processor can reject corrupt data even in a voided transaction. Consequently, it is recommended that the EPS systems purge Voided transactions and do not transmit them to the Processor with the voided flag indicator set. It is very frustrating for the merchant to have a bath rejected because of an invalid or corrupt voided transaction.

Credit - A Credit transaction is used to adjust or reverse a previously entered Sale transaction. You use a Credit transaction to:

-          Adjust a Sale transaction in the current batch.

-          Reverse a Sale transaction from a previously closed or settled batch.

A Credit transaction gives the money back to the cardholder. Because the original transaction has already been completed the cardholder will receive a statement with the original sale and then the credit. The merchant will also have to pay the full discount rates as well because the transaction was processed through the system.

Note: If you want to reverse a transaction from a previous batch or reverse only part of a transaction you must issue a credit.

Transaction Example

You go to the store to by something. The store has a POS system with a card reader. The card reader takes data off the magnetic strip on the back of the card.  It combines this information with information about the merchant and the dollar value of the sale and creates an electronic message. The POS system transmits this information to the merchant’s acquirer. The POS system may transmit this information via traditional telephone lines and dial up the acquirer or use VPN or Internet connection to connect to the acquirer. Once connected this message is sent to the acquirer’s computer in a specific format dictated by the acquirer. The acquirer’s system reads the message and determines the card issuer. It then transmits the information to the card issuer, Visa if it’s a Visa card, MasterCard if it’s a MasterCard, etc.

If it’s a bankcard:

The issuer’s system then reads the message and knows to check which bank actually issued the card. The banks system makes sure there is enough open balance to complete the transaction and either authorizes or declines the transaction.  The banks system sends the result to the card issuer who then sends the result to the store’s POS system. The POS system displays the result and prints out a receipt for the cardholder to sign if the transaction has been approved. The purpose of the receipt is to help resolve disputes if the processor issues a chargeback because a cardholder is disputing the transaction. The authorization usually takes only a couple of seconds depending on the communication mechanism.

The store then submits a request for payment to the acquire that then in-turn sends the request to the card issuer. The card issuer sends the request to the issuing bank, which post the transaction to the cardholders account. The card issuer then consolidates all the transactions for the day for all the merchants and posts them among the various banks. For this the issuer bank pays the acquire, who then pays the store. This process typically takes between 2-3 days. Debit cards also work in a similar way but rather than the issuing bank sending the cardholder a bill for the purchase the funds are electronically deducted from the cardholders bank account.

If it’s a Non-bankcard:

If it is an independent card system like American Express or Discover:

The merchant’s POS system may have a direct line to American Express or Discover. In this case the message is sent directly to American Express’ or Discover’s computer system. Their system authorizes or declines the transaction and sends the results back directly to the POS system. In this instance, American Express or Discover takes on the role of the both merchant acquire and issuer, thereby cutting out the merchant’s processor. If the merchant does not have a POS system that is capable of communicating directly with American Express or Discover the message will be processed just like a bankcard transaction.

Receipts & Signature Capture

Retail merchants are required to obtain signatures from cardholders that they agree to the transaction. The merchant must print out a receipt and get the cardholder’s signature approving the transaction. The typical receipt should contain the transaction information including the date, time, card identification information, the amount and a place for the cardholder’s signature. Underneath the signature there should be a statement like the following:

"Signature X.............................…….."

"I Agree to Pay Above Total Amount"

"(Merchant Agreement if Credit Voucher)"

A note about Receipts – Card present environments are required to print a receipt and obtain a customer’s signature. California Senate bill 930, which pass in August 1999 and took effect on January 1, 2001 for all new equipment requires all companies that accept credit cards for transactions of business shall only print the last 5 digits of the credit card account number and shall not print the expiration date upon the receipt provided to the cardholder. This means the application will need to print two different receipts one for the merchant with the complete information where the cardholder signs and an abridged version for the cardholder. Washington State has enacted similar legislation effective for all terminals as of July 1, 2001. While this law is currently in effect in CA and WA at this time, Arizona and Pennsylvania have introduced comparable bills and it is expected that other states will follow.

Signature capture systems have evolved to help the merchant store and retrieve receipts. The merchant is then required to store this information for up to six months. If the cardholder disputes the charge (a chargeback) for any reason the merchant is required to provide a legible copy of the receipt as proof of purchase. If the receipt is not legible and/or the merchant can not provide the recipe the merchant will loose the dispute and the money will be automatically withdrawn from their account and they will be assed a chargeback fee typically $15-25. The merchant will have no recourse except through the legal system.

The above requirement is the reason why card-not-present transactions are deemed as higher risk, because the merchant cannot provide a signature as proof. Card-not-present transactions are MOTO and Internet. My experience is that in every instance where a transaction is disputed and the merchant does not have a credit card receipt with the above verbiage the merchant will loose the dispute. Even UPS signatures for the receipt of the merchandise are not good enough.  This rule clearly places the liability on the side of the merchant and has resulted in the proliferation of anti-fraud systems from companies like CyberSource, HNC and homegrown rule based systems. The risk associated with these systems is the what’s know as “false positives” that is the transaction is a legitimate transaction but is rejected for mistakes or errors like the cardholder typed their home address rather than their billing address and so the AVS check and fraud system rejected the transaction. It will be interesting to see if the new signature law adds more protection for the card-not-present merchant.

The requirement to store and retrieve receipts places and enormous burden on the merchant to store and retrieve this information. The reality is many merchants don’t have the facilities and/or resources to provide this information in a timely manner and loose these disputes.  Many don’t even try; they just right them off as a cost of doing business. The other problem is that the receipts are sent via fax and the signatures become illegible at the other end and so the merchant must send a hard copy via carrier or they lose the dispute even though they have the receipt.  Consequently, signature capture systems are becoming more popular because they can automate this process. Once again Internet based systems offer advantages of higher bandwidth at lower cost over traditional dial-up solutions at 1200 baud.

Visa and MasterCard have just released new authentication solution for securing credit and debit payments between cardholders, online merchants and members, to address the issue of cardholder authentication. The solutions require an extra step during the on-line purchase process where cardholders are redirected to the card-issuing bank to authenticate themselves. The card issuer associations have stated that when you can truly authenticate on-line purchases they may be willing to reduce interchange for authenticated transactions. It will be interesting to see if they follow-through. Historically, they never reduce rates but rather keep them the same if you utilize the new requirements and raise them if you don’t.

Other Transaction Types

Credit card transactions make up the majority of the unit and dollar volume of electronic commerce transactions.  However, other types of transactions, such as debit cards, check solutions, smart cards and ACH transactions are becoming increasingly important.

The overall flow of transaction processing remains in place for Internet transactions as well.  The primary differences are:

         - The Merchant is just a computer system.  It is a computerized point-of- sale system operating without human intervention.

         - The Cardholder sends the card and transaction information over the Internet, rather than in person or over the telephone.  This information is encrypted.

         - The Merchant can in some cases transmit the transaction to a Processor over the Internet (in encrypted form) rather than using a dialup or leased line.

There are two types of debit cards: On-line debit which requires the cardholder to enter a pin number and off-line which are processed as credit cards with no pin entry. For both types the Issuer debits the Cardholder's bank account directly vs. credit cards where the cardholder is billed for the transactions at the end of the billing cycle. The merchant also pays a significant discount rate difference. On-line debit typically costs the merchant between $0.25 - $0.75 regardless of the transaction amount while off-line debit costs the same as credit cards typically 2-3% of the transaction amount. To process On-line debit, a merchant must have a terminal or PIN pad. The PIN pad allows the customers to enter their PIN numbers in a secure device that encrypts the number, returns an encrypted pin block that is sent to the financial institution to be verified.

Merchants to reduce the risk associated with bad checks increasingly use verification and guarantee procedures.  At the time of sale, the information on the check, including the amount, is transmitted to a check guarantee firm’s computer, which compares the information against a “bad list” and indicates whether the check should be accepted.  By approving the check, the verification/guarantee firm receives a fixed fee or in the case of guarantees a percentage of the transaction in payment and accepts liability for the full amount of the transaction if the check bounces.  The cost of this guarantee service is roughly 2%, comparable to credit card discount rates.  Since the check guarantee firm handles both the data processing and the financial aspects of the service, the downstream aspects of the process are much simpler than for credit cards.  From the perspective of a merchant transaction processing system, however, the process is virtually the same as credit cards, differing only in the specifics of the transaction information.  Major check guarantee firms include Equifax, Telecheck, and CrossCheck and all can be easily supported.

A new initiative has emerged to automated the processing and clearing of the check. This process called Truncation and/or Conversion is an attempt to take the paper out of the check system.  This initiative processes the check in a similar manner to credit cards. The check is approved/guaranteed as checks are today but they are then settled in a manner similar to credit cards. The retailer approves the check and stamps the check approved at the point-of- sale, handing it back to the consumer. The consumer signs a receipt authorizing the merchant to electronically withdraw the funds from their bank account. This process eliminates the paper and offers tremendous benefits to merchants and banks by automating the processes. Companies like CrossCheck, TeleCheck, Certgy (formally Equifax) , Intell-A-Check, Global eTelecom & eFunds provide this type of service.

Smart cards (also called “stored value” cards) have only recently begun to gain some ground in the United States.  A large trial was conducted during Atlanta’s 1996 Summer Olympic Games. Smart cards have been used in Europe, particularly France, for mass transit and other specialized purposes for a few years.  Although there are currently no standard formats or protocols for stored value cards, they all have the feature that the funds are stored directly on the card in electronic form.  Performance of a transaction consists of removing some value from the card and simultaneously transferring it to the merchant’s computer system.  Eventually these transactions are transmitted to a clearinghouse for deposit in the merchant’s account.

For the consumer, these cards have most of the same properties as cash, such as risk of loss and the holding of un-invested funds.  Thus I anticipate that they will tend to be used like (and substituted for) cash, primarily in smaller transactions.  Because of the consumer advantages of credit cards regarding lost cards, chargebacks, and use of funds, I do not expect smart cards to displace credit cards in any significant degree.  Visa, MasterCard and

AMEX all have major smart card initiatives and are all interested in smart cards as a way to reduce risk.

The Card Number Details

Credit card numbers have specific meaning and are broken up into groups.

Sample Credit Card: 1234 567 890 123

1234 - Group 4

567   - Group 3

890   - Group 2

123   - Group 1

Within the first group of numbers from the left (called Group 4) the Bank name and branch are contained. These numbers contains which bank issued the card, and which branch of the bank the actual cardholder banks at. The Second, Third, and Fourth digits of Group 4, tell which bank issued the card. A sample list:

VISA Examples

Group 4        Bank Name Examples

  4019    Bank of America

  4024    Bank of America

  4052    First Cincinnati

  4060    Navy Federal Credit Union

  4128    Citibank

  4131    State Street Bank

  4215    Marine Midland

  4225    Chase Manhattan

  4231    Chase Lincoln First Classic

  4232    Chase Lincoln First Classic

  4241    Nat. Westminester Bank

  4250    First Chicago Bank

  4271    Citibank Preferred

  4302    H.S.B.C.

  4310    Imperial Savings

  4317    Gold Dome

  4387    Bank One

  4428    Bank of Hoven

  4811    Bank of Hawaii

  4897    Village bank of Cincinnati

MasterCard Examples

 Group 4        Bank Name Examples

  5215    Marine Midland

  5217    Manufacturers Hanover Trust

  5233    Huntington Bank

  5242    Chevy Chase Federal Savings

  5254    Bank of America

  5263    Chemical Bank

  5273    Bank of America

  5286    Chase Lincoln First

  5317    Norwest

  5323    Bank of New York

  5329    Maryland Bank NA (MBNA)

  5410    Citibank Preferred

  5411    1st Fin. bank of Omaha

  5414    Nat. Westminester Bank

  5415    Colonial National Bank

  5424    Citibank

  5465    Chase Manhattan

  5678    Marine Midland

Group 3

Group 3, or the second group on a credit card in from the left, contains information on the Maximum Expiration Date and the Maximum Credit Limit.  The ACTUAL expiration date and ACTUAL credit limit are not in this group but represents this group. What it means is this: When the different Credit Card Companies issue Credit Cards to the consumer, they have a credit limit. And when the Companies formulate credit cards, they create certain groups for certain customers. That is, certain "groups" contain all the credit cards for people with a credit limit between $x and $y. The same thing goes with the expiration dates. Everyone whose card expires after m1/y1 and before m2/y2 has their credit card in a certain group formulated by the company. For example: My name is John Doe. My Visa credit card expires in January of the year 2005. My credit limit on this card is $7,000. My credit card number (CCN) will probably be in the same group as my brother-in-law Jack Koff whose card expires in December of 2004 and whose credit limit is $6,000. BUT, our cards will be in different groups entirely than my boss' whose card expires in June of 2001 and whose credit limit is $40,000.

Group 2 & Group 1

These two groups contain the Identification codes. The only purpose that these two groups serve is to differentiate cards between customers. If the first two groups of two cards are the same and the last two groups of two cards are different, the two cards were issued by the same bank and probably have similar credit limits, but are of course issued to different people.

###