Unless you are using an off-the-shelf shopping cart application, chances are that you or your developer will be customizing at least some element of your payment application to meet your specific needs. Your payment application may be simple or it may be complex; either way, following right sequence of events and taking advantage of available technology will help increase customer satisfaction; reduce development costs, payment-related errors and time to market; and provide you with a more functional application.

The following article highlights key steps involved in designing, building and launching payment applications. While it is written from a developer’s perspective, it will equip merchant with information that you can use to when you are interacting with your developer throughout process. It is part of a series of articles offered by EasyPay123 to help merchants understand many facets of processing credit card payments.

Step 1: Understand User Needs

Understanding user needs is a necessary starting point for development of any payment application. Documenting how user will interact with application and all of its various features ensures that all parties can agree on what final product will look like and how it will operate. Some of questions that must be answered at this stage include:

* How will payments be accepted (online, phone-in, IVR, etc.)? * What customer data is to be captured (e.g. name, phone #, address info, etc.)? * What supplemental data will be captured (e.g. demographics, questionnaire, etc.)? * Which data fields should be made “required” on interface? * What error detection/correction or data validation scripts will be used (e.g. MOD10 credit card number validation, date/dollar format, etc.)? * Do any calculations need to be made on interface? * What will look and feel of interface be (graphics, text, colors and layout)? * Will access to application be restricted by IP address or username/password? * Will results of transactions update a database in real-time or be made accessible to a third party application/data-base at some point after transactions take place? * How will credit card data be input (keyed, swiped, touch screen, etc.)? * What content should be put on response/receipt page? * How will customer/merchant receive an email receipt (if desired)? * What will contents of emailed receipt be? * What bank(s) will be used for merchant accounts? * Where will application be hosted? * How will payment form be secured?

The answers to these questions should be captured in a specification document so that merchant can review and comment. This step will reduce development time and cost, and also increase merchant satisfaction with project.

Step 2: Design Interface

Designing user interface is always “part art/part technology” and will vary greatly depending upon application. It should be driven primarily from user needs defined above. In addition, technical considerations, such as target operating system, hosting environment and development language must be taken into account. These decisions are “meat and potatoes” of most developers’ business, so little discussion is necessary here. An interface mock-up is useful so that users can provide input and test out application (some payment gateways provide developer environments so that a transaction can be accurately simulated with application prior to “going live”).

You may want to include any number of scripts in interface to reduce errors and improve its functionality. Some that you may find useful include:

(a) MOD10 Check: Uses Luhn algorithm to determine whether credit card number is valid or not. Reduces transaction time. Could reduce merchant cost if gateway charges for failed credit card numbers. (b) Order Number Generator: Generates a unique numeric order number that can be posted with each transaction. With “reject duplicate order number” option turned on (if supported), it nearly eliminates risk of duplicate transactions being processed by gateway. (c) Required Fields: Disables ability to submit a transaction unless all required fields are completed on order form. Ensures all necessary / desired data is posted to payment gateway. (d) Double Submit Prevention: Disables ability for user to click “Submit” button again while a transaction is still processing. Reduces risk of an erroneous double submission of an order. (e) Email Validation: Ensures that an email address is in format XXXXX@YYYY.ZZZ. Reduces risk of incorrect emails being entered. (f) Complete If Left Empty: Automatically populated a specific data field if user chooses to leave it empty (e.g. inserting “not specified” into address field).Ensures that fields that are required by gateway are populated with an acceptable value. (g) Alpha / Alpha- Numeric / Numeric Only: Issues an error message if user enters wrong data format. Reduces risk of data entry errors. (h) All Caps / Lower Case: Issues an error message if user enters wrong data format. Reduces risk of data entry errors.

Step 3: Integrate to Payment Gateway

Integrating payment gateway to an application (such as a website or billing system) can vary greatly in terms of complexity involved. In general, following steps will apply: 1. Integration Method Selection

Most payment gateways have many integration methods depending on type of interface sending transaction, where that interface is hosted (i.e. operating system) and how complex integration is. For example, some implementations may use a simple form post to payment gateway, whereas more complex ones may require use of an API.

Mapping out data flows and system requirements for application against payment gateway integration methods will help determine appropriate method. Generally speaking, use of an API provided by gateway provides most flexibility, but can be more complicated to integrate and maintain.

2. Data Field Posting Configuration

In this step, you should ensure that you are passing all of required and optional fields from interface to gateway using correct syntax. Required fields are minimum ones necessary to complete transaction. Optional fields contain useful supplementary data. They must be posted to gateway using syntax dictated by your gateway provider.

3. Response File Interpretation

Merchant accounts are necessary in order to accept payments made by credit card from your customers, whether you are operating a retail store or an online business. The following article answers key questions that you may have regarding merchant accounts. It is part of a series of articles offered by EasyPay123 to help merchants understand many facets of processing credit card payments.

1. Why Do I Need a Merchant Account?

Merchant accounts provide you with ability to accept credit card payments from customers for goods and services. A merchant account establishes a relationship between your business, a bank and a credit card processor such that funds generated from credit card sales are deposited into your bank account on a regular basis, less merchant account fees (to be discussed later).

Without a merchant account, your customers will not be able to pay you using their credit card. Given that credit card payments are still dominant form of payment on Internet, this would place you at a competitive disadvantage in a highly competitive business environment.

2. What Are Different Types of Merchant Accounts?

There are two primary kinds of merchant accounts that are issued, depending upon your method of capturing credit card information at time a payment is made.

The first type of merchant account is called a “card present”, “signature-based” or “retail” merchant account. This type of account is issued to merchants whose customers will be physically present at time of payment. In such a case, you would be able to inspect card and signature on reverse of card, and would also be able to match sales receipt signature against that on back of card. Typically, these types of payments are captured by using either a card imprinter (using credit card slips) or a “card swipe” (Point of Sale) terminal.

The second type of merchant account is called a “card not present”, “non-signature-based”, or MOTO (Mail Order/Telephone Order) merchant account. This type of merchant account is issued to merchants whose customers are not physically present when they make a payment. This is typical of most Internet payments - where customers key their payment information into an online payment form - and phone-in payments - where operators key payment information into some kind of payment application.

The types of merchant accounts will be a key factor in determining your fees, since banks typically view card not present payments as higher risk (i.e. a higher risk of fraud) than card present payments.

3. Where Can I Obtain a Merchant Account?

Merchant accounts are traditionally obtained through a bank that issues merchant accounts called an “acquiring bank” or “acquirer”. Generally, there is a separate group within bank that processes merchant account applications.

When you apply for a merchant account, there is no guarantee that your application will be accepted. The merchant account risk group will assess a number of factors before approving your application, including (but not limited to):

– Your company and/or personal credit history – The type of product/service you are selling (note that it is extremely difficult to obtain merchant accounts in U.S. for certain types of “high risk” products and services such as online gambling, pornography, outbound telephone sales, prepaid phone cards, travel agencies and others. What is perceived as high risk varies by acquirer). Falsifying nature of product or service you are selling when applying for a merchant account could lead to termination of your merchant account. – Estimated dollar volume – Average order size

A good place to start is with your existing bank, since you already have a relationship with them. You may also choose to inquire about merchant accounts with other banks to compare rates and policies (in fact, we strongly recommend this). It is possible to have a merchant account with an acquiring bank that is different from one where you have your bank account, although they may encourage you to move your bank account if you obtain a merchant account from them. It is likely that you will need to open a bank account with your acquiring bank so that funds can be deposited there. Some acquiring banks will route funds to a bank account of your choice (within U.S.) if you request it, although there may be an additional fee for this service.

Note that American Express and Discover are their own acquiring banks, so if you want to accept either of these cards, you will typically complete a merchant account application directly with them.

Another option for obtaining merchant accounts is through a credit card broker or “ISO” (Independent Sales Organization). These companies have relationships with many banks, and attempt to match your credit history and type of business with a bank that will accept your application. They are typically paid a commission from acquiring bank for your business, and this is passed on to you in form of a set-up fee or a percentage of sale fee. There are many ISO’s to choose from. Be aware that not all of them are reputable, so you would be well-advised to do some research on them before “signing on dotted line”.

When you start process of investigating merchant account options, we recommend strongly that you shop around so that you can compare rates and service levels. The merchant account business is highly competitive, and it is not uncommon for rates to vary even within acquiring banks, depending upon which merchant account representative you speak with, and how valuable they perceive your business. Having said that, price should not be your sole factor in obtaining a merchant account. Service is important too. Understand acquiring bank’s policies with respect to such factors as charge-backs (when a customer refuses to pay a charge). You may wish to reevaluate your merchant account provider if their policy is to revoke your merchant account status after a small number of charge-backs.