CREDIT / DEBIT CARD PROCESSING
The main purpose 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.
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.
This sounds like an obvious goal, but due to the convoluted nature of the payment industry and many developers’ lack of intimate understanding of the payment industry, this goal is seldom 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. The objective of this guide is to give the developer the knowledge of the payment industry needed to “get it right the first time.”
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 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 easy-to-use and efficiency of applications are as well as the ultimate rate 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 consumer presents a credit card as payment for goods or services, it 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 for the service or product sold to the consumer.
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, or indirectly over the Internet by providing the card number, expiration date, and name on the card. The latter is referred to as a “card not present” transaction.
The Merchant either “swipes” 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, 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.
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.
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).
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.
If the merchant bank is the same one that issued the card used, the Processor posts the transaction amount to the cardholder’s credit account or debits their funds on deposit, depending on the agreement with the cardholder and the type of card used. If a different bank, the more common situation, issued the card then 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 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.
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.
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. 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.
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 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.
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 TPI Software’s Payment Server, CyberSource and Authorizer.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. TPI Software’s Payment Server is gateway software you can license and run in-house rather than pay a third party to host it for you.
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.
A bank that sponsors merchants for the acceptance of credit card transactions.
The bank that maintains the merchant relationship and receives all 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.).
A bank that participates in another bank’s card program, usually by turning over its applicants for bankcards to the bank administering the bankcard program and by acting as a depository for merchants.
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.
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.
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 determined by the issuing bank, typically 3-7 days.
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.
The average dollar amount of merchant credit transactions.
Non-profit organizations that are owned by participating financial institutions.
One one-hundredth of a percent (.0001). DISCOUNT rates are expressed as basis points.
A collection of transactions. Usually a merchant has one batch per day or per shift.
A type of data processing where related transactions are transmitted as a group for processing.
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.
The act of creating an electronic transaction, usually for transferring money. Captured transactions are ready for settlement.
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.
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.
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.
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.
Response to transaction request meaning that the issuing bank will not authorize the transaction.
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.
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.
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.
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.
A system that passes data between networks having similar function, but different implementations.
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.
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.
The flow of information between issuers and acquirers, e.g. transactions, retrieval requests, charge backs.
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.
Same as the ISSUER. The issuer of the customer credit card.
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.
Credit card information that is entered via keypad instead of swiping the card through a card reader.
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.
A retailer, or any other entity (pursuant to a Merchant Agreement), that agrees to accept credit cards, debit cards, or both, when properly presented.
A written agreement between a merchant and a bank containing their respective rights, duties, and warranties with respect to acceptance of the bankcard and matters related to bankcard activity.
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.
Refers to the Qualification levels for a MasterCard transaction. Merit III is the highest, followed by Merit II, Merit I, and then Standard.
The specifications for the content of a data message with respect to the size, character type, sequence, and content of its data fields.
Refers to Merchant Identification Number. This unique number identifies a merchant to the merchant bank or processor.
Refers to Mail Order/Telephone Order.
Multiple transaction requests and responses transmitted to the processor on the same connection.
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.
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.
Operating mode in which the terminal is not connected to the processor. Often used when a merchant is batch processing transactions.
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.
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.
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.
The place and time that the transaction occurs. This term also refers to the devices or software used to process transactions.
Completion of a pre-authorized transaction.
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).
A $500, $1000 or $1500 floor limit at designated hotels/resorts. Floor limit is returned as part of authorization response.
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.
A transaction processor; a large computer center that processes data from credit card transactions and settles funds to merchants.
The highest QUALIFICATION which a Visa transaction can obtain. Card must be swiped and transaction deposited within 24 hours.
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.
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.
A transaction, for which permission has been granted by a cardholder to a merchant, that is periodically charged to the cardholder’s account.
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.
A transaction that authorizes and captures the transaction amount as a single step.
The process by which TRANSACTIONS with AUTH CODES are submitted to the Processor for transfer of funds.
The lowest QUALIFICATION level at which a Visa or MasterCard transaction may INTERCHANGE. Caused when a TRANSACTION is deposited several days after the original AUTHORIZATION.
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.
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.
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.
Action between a cardholder and a merchant that results in activity on a cardholder account.
A “per transaction” charge incurred by merchants who are on scale pricing. This is in addition to the percentage DISCOUNT fees.
An association of banks that governs the issuing and acquiring of Visa credit card transactions.
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.
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:
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. My first company, GO Software (see front cover), was one of the first companies to offer such a product for personal computers. 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.
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.
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.
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.
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.
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.
– UDDI (web services discovery) – A broad industry standard, which provides a way to locate and understand Web services, provided by other companies – A kind of yellow pages on the Internet of Web services.
– 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.
The Universal Description, Discovery, and Integration (UDDI) specification, www.uddi.org , is the building block that will enable businesses to quickly, easily and dynamically find and transact business with one another using their preferred applications. The Specification creates a platform- independent, open framework for describing services, discovering businesses, and integrating business services using the Internet, as well as an operational registry that is available today. UDDI is the first truly cross- industry effort driven by all major platform and software providers, as well as marketplace operators and e-business leaders.
Before UDDI, there was no industry-wide, accepted approach for businesses to reach their customers and partners with information about their products and Web services. Nor was there a method of how to integrate into each other’s systems and processes.
- Problems UDDI helps solve:
– Making it possible for organizations to quickly discover the right business from millions currently online.
– Defining how to enable commerce to be conducted once the preferred business is discovered.
- Benefits of UDDI for businesses include:
– Reaching new customers.
– Expanding offerings.
– Extending market reach.
– Increasing access to current customers.
– Solving customer-driven need to remove barriers to allow for rapid participation in the global Internet economy.
– Describing their services and business processes programmatically in a single, open, and secure environment.
– Using a set of protocols that enable businesses to invoke services over the Internet to provide additional value to their preferred customers.
UDDI provides a programmatic yellow pages. Previously, if you wanted to integrate payments you needed to physically contact the third party, get their specification and do the work. UDDI offer the potential to do all this programmatically in real time.
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.
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.
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
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, 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 .
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. Where there are hundreds of banks it became uneconomical for each bank to develop their own processing center. Consequently, most 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.
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.
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.
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”. In addition to setting the ECI indicator, the system must identify that the terminal is an electronic commerce cardholder activated terminal (CAT) and indicated the level of security used in each electronic commerce transactions. The valid levels are:
SET encrypted, cardholder certificate not used.
SET encrypted, cardholder certificate used.
Channel encrypted, cardholder certificate not used.
No security protocol, cardholder certificate not used.
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.
These special Interchange programs are from both of the card Associations for what is being called “developing markets” or “service industries”. It is not intended for all types of merchants who may do recurring billing, but just for specific types of businesses. Here’s a brief breakdown of each.
NOTE THAT ALL PERCENTAGES ARE EXAMPLES AND ARE NOT CURRENT INTERCHANGE RATES!
Visa – CPS Retail 2 (1.43% + $.05)
Transaction must meet the requirements for CPS Card not Present (AVS, Invoice, Merchant’ Customer Service phone number, Auth date and Settle date within 7 days) or EIRF. Only available for the following businesses: Schools, Government, Utilities, Insurance Companies and Cable TV. Visa will recognize the SIC code and the CPS Retail rate will be applied. This does not necessarily have to be a recurring transaction.
MasterCard – Service Industries (1.15% + $.05)
Must be a recurring payment transaction with the recurring payment indicator in the data fields. Only available for Utility, Telecommunication, Cable TV, and Insurance Providers. Merchant must be registered with MasterCard and participate in MasterCard’s RepeatPay marketing program. Transactions must be non face-to-face, single electronic authorization and settled within 1 day of authorization. There is a certification form that must be completed and sent to MasterCard before the rate applies.
Visa also created a new program to expand usage for medical professionals. This program is called VISA Patient Easy Pay collection system. With this program the patient’s signature authorizes you to charge the balance due (up to the prearranged maximum) to his or her payment card (ex. VISA, MC, etc.). More information can be found at www.visa.com.
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 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.
When the Processor receives the authorization request one of the first things it does is determine what the card type is, i.e. Visa, MasterCard, AMEX, etc. Depending on the card type the Processor sends the transaction information to the appropriate card association for verification. Most Processors have a MIP and a VAP at their facilities. A MIP is a direct connection to MasterCard and a VAP is a direct connection to Visa. This gives the Processor very low cost high-speed connections directly to the card associations. However, if the transaction is AMEX or Discover the Processor sends the transaction to American Express or NOVUS directly for verification. American Express and NOVUS are closed systems, meaning that they issue and bill the cardholders directly. Consequently, if the card is an AMEX or Discover the Processor adds an extra unnecessary step that increases the cost and slows down the process.
For these reasons many EPS systems developed what is called a split-dial or split-auth. Many EPS systems can connect directly to AMEX and NOVUS for authorization and some even for settlement. This feature can reduce the merchant’s costs for these non-bankcards. This is especially important in industries that are heavy users of these card types such as restaurants with AMEX. This is also the procedure used with Private Label cards.
It is believed that IP connectivity will make spilt-auth even more popular. In dial systems, the EPS must physically dial and connect to the authorizer. This can create issues when systems are implementing multi-trans processing because the connection to the main processor must be ended before dialing the secondary processor. Consequently, many of the benefits of piggybacking transactions on the same call are lost. However, In IP based
systems it is a simple matter of changing a URL and/or IP address to connect to the authorizer.
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.
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.
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.
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.
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.
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
$1- 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.
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.