Credit Card Processing

Overview

Initially most commercial banks provided credit card issuing to consumers, and credit card transaction processing services for merchants.  Such institutions are called merchant banks or acquiring banks.  Over time the industry consolidated and now only a few banks issue credit cards.  Today most banks outsource credit card issuing for their consumers to one of these banks that specializes in that such as Citibank, Chase bank, Capital One, etc.  However these cards can be imprinted with the local bank's logo and name, so a customer may not realize the credit card they got from their bank is really issued by another bank.

Few commercial banks can process credit card transactions cost effectively.  So like the issuing of credit cards, today most banks outsource credit transaction processing services for their merchants to one of a few giant payment processors.  These processors use a network of member banks to settle payments between them.

Payment Processors

Merchant banks use a payment processor as an electronic payment clearing house to settle credit card transactions between the member banks.  Processors such as VISA, ECHO or NOVA act as a third-party service providers to process the credit card transactions through the bank system for merchants.  These are sometimes called credit card [transaction] networks.

To directly use such a network you need a merchant account at a member bank.  Ultimately the choice of credit payment transaction processor may constrain your choice of bank.  If you use NOVA for example, you must have a merchant account at a NOVA member bank.  You may also need a merchant account at your bank (in addition to your business account), to allow payment transactions from your bank's merchant account to the transaction processor bank's merchant account.

The Automated Clearing House (ACH) is the name of the major electronic network for financial transactions in the United States.  The ACH processes large volumes of both credit and debit transactions which are originated in batches.  These don't require any special merchant account but can transfer funds to and from regular bank accounts.  Discover card (for example) uses the ACH network and also provides a simple web interface for merchants to use.  (Unfortunately Discover® also charges higher transaction fees than most cards, which is why fewer merchants accept that card.)

ISOs — Independent Sales Organizations

While you can open a merchant account and buy your credit card processing services from a bank, today an alternative is available.  A number of smaller companies called Independent Sales Organizations (or ISOs) resell these services to merchants.  These ISOs usually provide technical support, transaction processing (authorizing and submitting transactions to the appropriate credit card transaction network) via phone or Internet, bear the risk of chargeback (a chargeback is when a consumer requests a refund from their credit card company), and set the price of the services.  Sometimes ISOs are called Payment Gateways, payment processors (which is confusing), or payment transaction service provider.

If the ISO is small it might outsource some of those services (for example providing technical support) to a larger ISO.  Note the ISOs are still considered transaction processors; you still need an account with the ISO just like you'd need a merchant account with a commercial bank.

Using an ISO means you don't need an additional merchant account at a bank, you are not limited to just one processor (that your bank uses), and have a choice of fee structures.  There are many ISO transaction processors from which you can choose.  Authorize.Net (founded in 1996) has become synonymous in the industry with the word payment gateway.  PaySimple.com is another ISO that is popular.  (See links below for a few others.)

Selecting a Payment Processor

The first step in credit card processing is the establishment of a (merchant) account with a bank or ISO.  A merchant account may be opened at the bank that holds your business account or you can use a different bank or an ISO.  There is a great deal of competition between the credit card processing service providers, so chances are you will be able to find a good deal by shopping around.

What to look for in a credit card processing service (processor) will vary depending on the size and revenue of your business.  If you have a newly established or smaller business you will probably want to find a service that has small or no startup fees.  These merchant service firms tend to charge a higher per transaction commission.  On the other hand if you have an established company with a large client base, you should probably make the investment in startup fees and save on the per transaction charges.

Some processors charge monthly fees in addition to any transaction fees, plus other fees for additional services they optionally provide (optional, unless you need that feature).  Examples include gift card processing or bundling transaction fees (and billing you only once per month for those).  Some processors will require long-term contracts, usually one to three years, and have high early-termination fees.

Merchants sometimes charge their customers on a periodic basis for monthly services or for other reasons.  If your enterprise does this you should look for a service that offers recurring billing.  With recurring billing you provide your payment processor with the customer's billing information and tell it how often to charge the customer.

A virtual terminal is a web form accessible to the merchant.  It allows you to enter credit card payments manually, e.g., by your customer support desk after a customer has called.  It can also be used to issue returns and void previous transactions.  Unless you completely outsource your payment handling to some ISO you will need some way to manage your customer's transactions.

It can be difficult to compare costs of different payment processors since the fee structures vary widely.  Per transaction fees may be less than 2% or more than 5% of the transaction amount.  It may depend on how the transaction was entered; qualified transactions cost less.  There may also be a per-swipe charge, usually less than 50 cents per swipe.

Although credit cards are the most popular way to pay online you may want to use a processor that allows you (the merchant) to use other payment methods such as PayPal.com or ProPay.com.

You should certainly spend some time looking into the available credit card processing services and carefully weigh the pros and cons of each.  Make sure to pick a reliable processor (should have a reputation of being up 24x7) and one that can be used with your system, using the software you've chosen and the expertise available.  (That is, if you use Java EE in your organization you want a payment processor that provides Java EE software and not Ruby Rails software.  Today most processors simply provide a web service you can use with nearly any software.)

Whichever processor you chose be sure to request a few test credit cards.  These can be used to make sure your system is working properly.  Test cards should be free for the asking.

Settlement Options

One of the decisions you will have to make when choosing a payment processor and establishing your account is how you wish to settle your transactions.  When a credit card transaction is performed (e.g. a sale transaction) funds are not actually exchanged between customer and merchant until the transaction is settled.  As a merchant you have two choices in how the settlement is to be performed:

• The first settlement option is that of automatic settlement.  As its name implies under this option all credit card transactions are settled automatically without any further action on your part.  Transactions are settled once per day at approximately 2:00 A.M. Eastern (Standard) Time.  All pending transactions for the day are settled at the same time.  At any time you may query the results of the most recent settlement to be sure that all transactions you expect to be settled are indeed settled.  Automatic settlement is the easiest method in that you can be sure your transactions will be settled every day without further intervention.  This method does however incur slightly higher fees from the transaction processor.
• The second settlement option is that of manual settlement.  In this situation no automatic settlements are ever performed; instead you must actively settle transactions.  This can be done at any time you choose.  When you perform a settlement you can settle all outstanding transactions, or you can settle only selected transactions.  Thus manual settlement gives you more control over the settlement process.  If for example you have processed a sales transaction for an item, but that item is not yet ready to be shipped, you might wait to settle that transaction until the time when the goods are shipped.

The Payment Process

After making all your decisions you need some way to (securely) send the customer's payment information to the processor.  This can be done in a variety of ways including phone calls, FAX, POS (Point Of Sale) terminals, or (in our case) on-line payment over the Internet.

For on-line transactions the processor will supply you with the software details needed: a CGI to send specified form data to, an EJB you can just add to your application (with a couple of methods that take the data as arguments), a Perl/Ruby/whatever module you can use, etc.  Today many processors provide a web service a merchant can access.  This method is very simple to use:  Your system must send the data as if it had come from an HTML form to the URL of the web service.  The reply contains the authorization information.

The data needed for the authorization request includes a credit-card number (the number automatically identifies the type of card and the issuing bank), the expiration date, the customer's name used for the card, and occasionally additional information to identify the card-holder, often card holder's address or the CVV/CVV2 code on the back of the card.

When a credit card is used for payment the following process occurs (usually in a matter of seconds!):

1. The merchant submits an Authorization Request to a processor with a point-of-sale (POS) terminal, PC software, telephone, FAX, Internet, etc.
2. The processor electronically links to the appropriate (e.g., Visa/MasterCard) network to transmit the authorization request to the issuing bank.
3. The bank verifies that the account number is valid and that the transaction amount does not exceed the cardholder's credit limit.  The authorization also puts a hold (or Preauth) for the funds on the cardholder's credit limit.  The processor then tells the merchant the payment was authorized and provides an authorization number for this transaction.  If nothing further is done the hold expires in a week and the charge never shows up in the customer's (or merchant's) account.
4. Later the merchant transmits a deposit (or Force) transaction.  Note:  If you operate face-to-face with customers and deliver the merchandise or service immediately, the authorization and deposit occur simultaneously as a sale transaction.  This step finalizes the transaction but does not settle it.  To cancel the transaction after this requires the transaction to be voided (another type of transaction).
5. Finally when the transaction is settled the processor instructs the bank that issued the credit card to deposit the net settlement amount into the merchant's bank account.  The delay between when the transation is settled and when you receive the funds in your bank account is called lag time.  The lag varies between payment processors.  Some will deposit the funds in under a day, others can take up to five days.  Long lag times are caused by processors using less efficient anti-fraud systems; also some processors delay the deposit to make money on the float (interest earned while they are holding the funds in their accounts).

Credit Card Transaction Types

There are five basic types of credit card transactions:

• Sale
• Credit
• Void
• Preauth
• Force

Many people are probably familiar with Sale and Credit transactions.  Void transactions are often well understood also.  A merchant must be aware that a void transaction can only be done on transactions of type Sale, Credit, or Force.  Furthermore a transaction cannot be voided after it has been settled.

Preauth and Force transactions are probably less well understood.  A Preauth is similar to a Sale except that it only places the funds on reserve in the customer's credit card account.  To actually transfer the funds a Preauth must be followed up with a Force transaction.  Funds set aside with a Preauth are only held in reserve for seven business days, after which the Preauth approval code is no longer valid.

Merchants may choose to issue a Preauth if they wish to secure funds for sale of an item that is not ready to be shipped.  Once the merchandise is ready to be shipped the charge can be finalized by processing a Force transaction (or a Sale transaction if the Preauth has expired).

Note that Preauth/Force transactions incur higher fees from the transaction processor than Sale transactions.  Therefore if you are a merchant who needs this type of capability you may wish to consider establishing your settlement type as manual.  Then instead of performing Preauths followed by Forces when goods are ready to be shipped you can simply perform a Sale that is not settled until goods are ready to be shipped.

Fraud Protection

There are two mechanisms currently in place in credit card technology that assist a merchant in minimizing credit card fraud.  Both of these are of particular benefit when processing credit card transactions anonymously as they are done online.  These two mechanisms are nicknamed AVS and CVV.  For your own protection as a merchant you are strongly encouraged to require both (or at least CVV) from your customers.

AVS stands for Address Verification Service.  This is a means by which you can determine if the address the customer provides agrees with the address associated with the credit card account.  This provides you with some measure of confidence that the person using the credit card is the person who owns it.  AVS information is not required for credit card transactions.  However, if it is provided the transaction processor issues back a response indicating how much of the address matches.  There are levels of matching: it may be the case that the street address is correct, but the postal code is wrong, etc.  It is important to note that a credit card transaction will not usually be denied if the address is wrong.  It is up to you to decide what to do if the address does not match or matches only partially.  One course of action would be to void the transaction and deny the sale but this is entirely at your discretion.

CVV stands for Card Verification Value (sometimes called CVV-2).  This is a 3 or 4 digit code that is found on Visa, MasterCard, Discover, and American Express cards.  It appears on the card but nowhere else, not even on credit card statements.  Its primary purpose is to validate that the user of the credit card actually has the card in hand.  On Visa, MasterCard, and Discover CVV data consists of the 3 or 4 digits found after the card number on the signature strip on the back of the card.  On American Express CVV data consists of 3 or 4 digits on the front of the card, to the upper left of the card number.  CVV data provides the merchant a high degree of confidence that the customer actually possesses the credit card that is being used.

Privacy Protection

Besides protecting yourself from credit card fraud it is of paramount importance that you guarantee your customers that their credit card information is protected as well.  Of course you should use encryption for you web site (HTTPS rather than HTTP for all web pages that require security).  But there are additional protections needed too.  There are at least four different times when customer credit card information is being transferred and must be protected (there may be more depending upon how your business operates):

1. When the customer sends his/her credit card information to you.  When processing credit card transactions online, this step takes place over the Internet and guaranteeing security at this time is entirely your responsibility as an Internet merchant.  You must have a secure server with a valid PKI security certificate, and you must be sure to use the HTTPS protocol whenever your customers are sending private information.  (This includes the initial login page!  Many merchants forget this page must be protected too, even though it contains no credit card information.)
2. When the credit card information is sent to the transaction processor.  You do not have direct control over security at this step but you will need to be sure that the credit card transaction processing software you use is secure.  All credit card information should be securely encrypted as it is passed back and forth from your server to the credit card transaction processor.
3. When credit card information is being moved into and out of a database.  Again the security measures in place at this step will depend upon the software you are using to handle your transactions and maintain the database.  Whatever credit card transaction processing software (CCTPS) you decide to use, never store unencrypted credit card information in a database.
4. When credit card information is being viewed and handled by your staff.  Ensuring security at this step is your responsibility. Some CCTPS includes a reporting capability that will be of great use to your accounting personnel.  Since these reports include credit card information you will need to be sure to restrict access to the site that hosts the CCTPS and the DB, and to run it on your secure server.

The Payment Card Industry (PCI) has created requirements known as the PCI data security standard (or DSS) for protecting payment card information, including information in computers which process, store, or transmit (across the Internet) credit card and other payment card information.  Some non-obvious issues include data retention issues and data disposal issues.  Many commercial organizations need to handle such electronic payment information.  Merchants and payment processors need to file notices of compliance, usually created by an internal audit.  (It may be wise to hire an expert consultant for this, at least the first time.  Once you have confidence in your procedures you can use internal audits.)

In the past each type of card (Visa, Amex, ...) had security regulations for handling customer names, addresses, and other collected payment information.  (See for example usa.visa.com/merchants/risk_management/cisp_merchants.html.) Recently all the major banks have agreed to a single set of standards.  For example, under the new PCI standard an un-encrypted log file is not allowed to store a complete credit card number; but you can store the first 6 and last 4 digits.  For more information see www.pcianswers.com and www.pcisecuritystandards.org.

Privacy Assurances

Two further measures should be taken by merchants that offer on-line sales.  The merchant's site must have a privacy policy that should meet the P3P Privacy Policy standard.  (See www.w3.org/P3P).

Secondly the site should include some assurances to the user about your on-line business practices (especially data collection, retention, and handling).  This is commonly done by having a well-known third party certify your site as compliant with their policies and practices.  You include a special icon and notice of compliance on your site.  Remember that few companies are so well known that assurances are not needed.  Some common assurance providers are BizRate.com, TRUSTe.org, BBBOnLine.org, and VeriSign (seal.verisign.com).  (For example see the bottom of the welcome page at NewEgg.com.)

Sample Code:

To make payments the merchant collects payment information from the customer.  The merchant may review this information and reject the sale.  For example the merchant might require you to login with valid customer credentials before proceeding to checkout.  Then the merchant sends the order information, merchant information, and customer information to the payment processor.

In some cases the merchant collects credit card data and passes this to the processor.  In other cases the merchant just sends merchant and order information, which may include merchant graphics.  The payment processor then collects the credit card information directly.  The user may or may not realize they are no longer talking to the merchant's server, but that of the processor.

Once all the data is collected the merchant's server sends an HTTPS POST message with the data (suitably encoded) the the payment processor, and waits for a reply.  Here's some sample code showing the minimum required data a merchant must send, to use PayPal:

<form action="https://www.paypal.com/us/cgi-bin/webscr"
      method="post">
<input type="hidden" name="cmd" value="_xclick">
<input type="hidden" name="business" value="sales@example.com">
<input type="hidden" name="item_name" value="Item Name">
<input type="hidden" name="currency_code" value="USD">
<input type="hidden" name="amount" value="0.00">
<input type="image"
       src="http://www.paypal.com/en_US/i/btn/x-click-but01.gif"
       name="submit" alt="Make payments with PayPal!">
</form>

You can include much more information using optional parameters (hidden form fields).  Other payment processors (or ISOs) work similarly.  Authorize.net provides sample Java Servlet code you can use.

The response from the payment processor will typically include a result code you can easily check with your program, a human readable response code, an authorization number, a transaction number, and other information.  Your program parses this reply, updates the company database, and returns an appropriate web page to the customer.

Most payment processors have development information someplace on their website.  For example if you decide to use Google Checkout you can find the technical information on using it at code.google.com/apis/checkout/.

Links: