Part 2 -- Recipes.

2.1 Fast Food: Simple OMARS Payment Form

Pro:

• Only requires minimal effort and no extra knowledge to set up.
• Customizable background color and some labels.

Con:

• Cannot control appearance of order entry form.
• Customer must calcuate and enter the amount to pay.
• Minimal "extra data": just order category and Order Comments field.
• Digital (email) receipts available through ClearCommerce/OMARS.

This solution gives you a very simple and utilitarian web page that accepts and processes a credit card payment. The form was originally developed for merchants' back office point of sale applications, as a replacement for the "telephone terminal", but it also works as a public e-commerce page.

You cannot control the look and feel of this page aside from some labels and the background color. For more information, see the Point-of-Sale section of the OMARS Merchant Setup Questionnaire. This explains the options available in setting up the form.

Example

You can configure these features of the payment page:

Background color

Sets the background color of the automatically-generated Web pages. The foreground colors are all dark so choose a pale shade.

Transaction Type

The type of credit-card transaction, either PreAuth or Auth.

Charge Description

Optionally, modify the message sent to the customer on Amex transactions. This is usually not needed since the default message TUITION/FEES is appropriate, and we recommend keeping the default.

Order Classification

This optional setting lets you collect an extra piece of data with each order, a "classification" meant to indicate the purpose or description of the payment. It can be used to sort orders later in the back office. The set of classifications is fixed, set at the time your store is configured, although it can be changed later.

Order Comments

This is another optional input to associate a piece of data with the order. It can be up to 64 characters long and may contain anything. You configure whether or not this input appears on the Web form, its label and an optional line of instructions to the user.

We recommend using the Order Comments field to store a reference identifier such as a bill or invoice that lets you match the credit-card payment with an entry in your main recordkeeping system. For example, if you ask customers to pay their invoices online, collect the invoice number so you can easily find the invoice corresponding to each payment and log the amount paid.

There is also an option to add some scripting code to check the value entered in the Order Comments field. This is a script that runs in the browser (e.g. javascript) to put up a warning message if the value is missing or unacceptable. Most merchants don't bother with this option.

Shipping Address

The form may optionally be configured to include entry boxes for another mailing address, designated the "shipping" address because it is intended to be used for orders where the goods are shipped to a a different address from the credit card billing address. The input fields can be given a different label if you wish to use them for something other than shipping.

Separate Tax, Shipping amounts

Add input boxes for separate amounts for tax and shipping. Most of our merchants do not need to charge tax, so this is usually not an issue. The separate shipping box is only needed if you want to specifically track the amount charged for shipping. The tax and shipping inputs are automatically added to the subtotal entered to get the total amount charged.

We recommend leaving these input boxes turned off.

Store Name

The title at the top of the page does not need to match the name of your store, although by default it does. Configure a different store name if needed.

2.2 Blue Plate Special: OMARS with Custom HTML form

Pro:

• Relatively little effort to set up, only requires basic HTML knowledge.
• Form page is completely customized. You can hide or omit irrelevant fields.
• ChargeMIT takes care of hosting the page securely if you upload it to your Web locker (exactly the same as for sites on web.mit.edu).
• Digital (email) receipts available through ClearCommerce/OMARS.

Con:

• Customer must calcuate and enter the amount to pay.
• Minimal "extra data": just order category and Order Comments field.
• "Receipt" page is not customizable (aside from background color).

OMARS Order Entry from Custom HTML Forms.

Hosting the Page

We offer a solution to this problem. Our e-commerce server, shopmit.mit.edu, also provides access to websites in WCS (Athena) lockers, but it is configured to give encrypted https access to the public. If you change the URL to use shopmit your customers will be loading the exact same pages out of your locker, but they'll just go through the shopmit.mit.edu server instead of through the web.mit.edu server.

To derive the new URL you should advertise to your customers, start with the web.mit.edu URL you'd normally use to load the page. Then substitute "https://shopmit.mit.edu/" for "http://web.mit.edu/" at the start of the URL of the page that you offer to customers; e.g., change

        http://web.mit.edu/mylocker/www/pay-me.html

        https://shopmit.mit.edu/mylocker/www/pay-me.html

2.3 VISA Vindaloo: cgiemail Version 1 and Custom HTML form

Pro:

• With cgiemail you can collect as many answers from the customer as you need.
• All pages are completely custom. You can hide or omit irrelevant fields from the payment page.
• ChargeMIT takes care of hosting the pages securely if you upload them to your Web locker (exactly the same as for sites on web.mit.edu).
• Digital (email) receipts available through ClearCommerce/OMARS.

Con:

• Customer still must calcuate and enter the amount to pay. (See next section on cgiemail2 for a solution to this.)
• Back office staff must match cgiemail messages with OMARS orders.
• Building this kind of site requires thorough knowledge of HTML and some time and effort learning cgiemail.
• Some features require adding the complexity of server-side includes.
• "Receipt" page is not customizable (aside from background color).

The customer is led through two web pages: the first is the cgiemail application, where he/she chooses what to order, and the second is a payment page that collects the credit card information and processes the transaction. It may seem cumbersome to break up the activity into two web forms but it is actually common for e-commerce websites to use a separate page for credit-card payments. This design also lets you offer other methods of payment by switching to different follow-on pages instead of the credit card page.

Here is how it works:

1. Customer loads the form page that drives cgiemail. Customer fills out the form, chooses "credit card" payment method, and submits it.
2. cgiemail sends an email message with the form answers.
3. cgiemail builds a response page out of the "success template" for the credit card payment page and sends it to customer's browser.
4. Customer now sees the second page of the form, pre-loaded with any applicable answers from the first page such as name and amount to charge. Customer adds credit card information and submits it.
5. This form goes to OMARS order entry service, which processes the transaction and returns a "receipt" page to the customer.
6. Customer sees confirmation page saying his transaction was approved.

One disadvantage, to the merchant, is that information about orders arrives from two separate sources: email messages with results of cgiemail forms, and orders entered into your OMARS storefront. You have to correlate order messages with their payments (or lack of payments).

For more information on building your site with cgeimail, please see the manual ChargeMIT E-Commerce with cgiemail.

Example

2.4 Mastercard Marsala: cgiemail Version 2 and Custom HTML form

Pro:

• With cgiemail2 you can collect as many answers from the customer as you need.
• All pages are completely custom. You can hide or omit irrelevant fields from the payment page.
• ChargeMIT takes care of hosting the pages securely if you upload them to your Web locker (exactly the same as for sites on web.mit.edu).
• Amount of payment can be calculated automatically.
• Server-side includes (SSIs) no longer necessary.
• Digital (email) receipts available through ClearCommerce/OMARS.

Con:

• Cgiemail2 is not supported by I/S and has not been completely tested or documented. There is some risk in using it.
• Back office staff must match cgiemail messages with OMARS orders.
• Building this kind of site requires thorough knowledge of HTML and some time and effort learning cgiemail2, which is even more complicated and subtle than the original cgiemail.
• "Receipt" page is not customizable (aside from background color).

The new features in cgiemail Version 2 are:

1. cgiemail2 has its own built-in unique identifier in the [cgiuniqueid] variable so the initial page does not need server-side includes to generate an identifier.

2. With conditionalizations you can transfer the value from a SELECT tag input in the initial page to a SELECT in the "success" template. The example uses this feature to set the billing address country field.

3. Most significantly, cgiemail2 can edit variable values, assign to variables, and perform calculations. This lets it extract prices and quantities from the purchases chosen on the first page and compute the amount to be charged automatically. Having the amount to pay appear automatically on the payment page looks much smoother and more professional than a confusing message begging the user to add it up.

cgiemail2 has a major disadvantage, however: it is not released, and is not scheduled to be released because no resources are available to properly test it. A few sites are using it anyway, at their own risk.

For more information on building your site with cgeimail2, please see the manual ChargeMIT E-Commerce with cgiemail.

Example

2.5 E-Commerce Jambalaya: FileMaker Pro forms

Pro:

• FileMaker form lets you collect as many extra inputs and answers from the customer as you need.
• All pages are completely custom. You can hide or omit irrelevant fields from the payment page.
• Amount of payment can be calculated automatically.
• Digital (email) receipts available through ClearCommerce/OMARS.

Con:

• You are responsible for hosting and maintaining the FileMaker Pro application.
• Back office staff must match FileMaker entries with OMARS orders, although this is easy to automate once OMARS report is imported into Filemaker.
• Special FileMaker Pro training and knowledge is required, as well as some HTML skill. The ChargeMIT team can only provide limited advice and assistance, although I/S offers FileMaker training courses (follow the link and look under "Databases").
• "Receipt" page is not customizable (aside from background color).

To turn a FileMaker Pro form into an e-commerce site, have it produce another form upon a successful submission which drives the OMARS custom form order entry service.

XXX TODO: add details about generating identifier for OrderComments (or OrderId), importing reprts, etc.

Example

2.6 Angry Fruit Salad: ShopSite (catalog/shopping cart software)

Pro:

• Impressive results from little effort; ShopSite is well-documented and easy to use.
• Customer can choose multiple products and options, charge is totalled automatically.
• Complete sales reports are available from ShopSite.
• Merchant does not need to know any HTML or programming, although some HTML knowledge can be helpful.
• ShopSite is hosted and maintained by ChargeMIT.
• Credit card processing is integrated with OMARS, transactions appear on OMARS reports.

Con:

• ShopSite works well for e-commerce sites that conform to the catalog-and-shopping-cart model, but is difficult to adapt to other situations -- such as events and conferences. E.g., there is no way to "require" that every shopper purchase an the "registration" product.
• Products must all have fixed prices, although options that change the price up and down are possible.
• Many features and messages are difficult or impossible to customize. (Prospective merchant is advised to experiment with one of our demonstration stores if there are any pending questions.)
• Merchant must cover incremental cost of ShopSite license (about $325-900). (Student groups can use it for free through SAFO.)

See ShopSite's website for demonstrations and more details. We are running Release 5.0. Upgrades are unlikely because of licensing issues.

2.7 Baked Alaska: OMARS Order Entry API

It only submits new orders. It is not capable of order management (e.g. marking orders "fulfilled") or of getting reports.

Pro:

• All web pages, including receipt page, are completely custom.
• OMARS API is the only way to enter an order with multiple items into ClearCommerce, so it can be fulfilled by-item.
• Digital (email) receipts available through ClearCommerce/OMARS.

Con:

• High level of programming and Web design expertise is required.
• At least a few weeks of effort required to implement a site.
• Merchant is responsible for hosting and maintaining web server and server-side Java infrastructure.
• OMARS API can only capture a few pieces of data outside of the data directly relevant to the credit card order; the application developer is responsible for capturing, storing, and relating any extra data which does not fit in API.

Consult the ChargeMIT team for advice and documentation if you are seriously interested in using the API.

Part 3 -- Back Office Procedures

3.1 Apertif: Relevant OMARS Pages.

    http://web.mit.edu/ecommerce/www/stores/store-alchemy.html

Only the people permitted to use the service will be able to load the service page. They must be using a Web browser with their personal MIT Web certificate available.

3.2 Dessert: Tasks and Roles.

All operators must be explicitly granted the privileges to access these roles in your store. This is usually done when your store is set up. You can add and remove users from roles at any time by sending mail to chargemit-help@mit.edu.

Order Entry

Create new credit card orders, using either the back office OMARS Order Entry page or the same e-commerce interface as your customers. The orders come from customers via telephone, Web form, physical mail, written forms, etc.

Order Entry operators need to be trained to fill in the Order Entry page correctly, and which inputs are the most important. They also need to know how to react to failures and correct them. The exact instructions depend on how your store operates, possibly including:

• Choice of Auth or PreAuth transaction type.
• Choosing an order category.
• Reading the magnetic stripe on a credit card.
• Entering minimal address information for AVS (i.e. billing name, billing street number, and ZIP code, only for US addresses).
• Capturing a ship-to address.
• Entering the CVM digits from the credit card.
• Entering Order Comments field correctly.

Fulfillment

If your store uses PreAuth/PostAuth transactions, some of your staff must be able to fulfill (i.e. PostAuth) orders. You are allowed to fulfill an order when the the purchased goods are shipped or otherwise made available to the customer.

Fulfillment operators are trained to use the Order Management pages to locate and fulfill relevant orders. Using the Order Detail page they can adjust the fulfilled amount to less than the authorized amount (but not more).

An authorized transaction must be fulfilled within 30 days or it "times out" and gets voided automatically.

Void

When an order is created by mistake (e.g. a duplicate order entered through the Web ecommerce form), it can be voided if caught before it gets settled. Voiding an order cancels it and frees the hold on the customer's available credit balance. In most cases, Order Entry operators should be trained and given access to void orders as well.

Use the Order Management page to void an order.

Credit

A credit is separate transaction that sends money from your store back to a customer. Since it takes money from your store, this is a very sensitive operation. OMARS incorporates many safeguards to prevent credit transactions from being used fraudulently, but it is still best to restrict the Credit function to a few experienced and trusted staff. Credits should not be needed often anyway.

Use the Order Management pages to issue a Credit on an existing order.

Report

All of your order-processing staff need the Reporting role so they examine the history of orders and transactions. You'll also want to include accounting and business staff who need to look at credit card reports. OMARS reports do not reveal complete credit card numbers or other sensitive information, so they can be made available fairly widely.

Use the Order Management, Transaction Report, Settlement Report, and Category Report OMARS pages to get reports.

3.3 Washing Up: Reconciliation and Accounting

3.3.1. Sorting Orders.

Be aware of the different sources of orders so you can identify where each one came from and know what has to be done with it.

3.3.2. Correlating Order Information.

For example, if you have a cgiemail Web form to initiate an order which then leads to a credit-card payment form, you'll get an email message for each credit-card order. (You may also get other email messages which have no corresponding credit credit-card order because the customer chose some other payment method.)

The task is to ensure that there is an order in OMARS for each email message that should have one, and furthermore check the status of the order -- was it settled successfully? Does it need to be fulfilled? You may encounter any of the following failure modes:

• Abandoned orders: An email message was received but there is no corresponding order in OMARS. Perhaps the email is a duplicate created when the customer reloaded the Web page; check for other orders from the same customer (matching name or email address) and discard if it is a duplicate.

  If it is not a duplicate, the customer may have encountered some difficulty entering the credit card transaction and simply given up. You can ignore the email, or send a reply to ask if they need help.

• Orphaned credit-card transactions: Sometimes you may find a credit card transaction which does not have a corresponding email message. This should be very rare. The cause is probably either:
  1. Corresponding email message was lost, due to a failure on the webserver or in the mail system.
  2. Customer managed to enter a credit-card order without going through the order form first. This used to occur if they reloaded the Receipt page and aggressively clicked through warnings, but with a new method of entering cgiemail orders that should no longer be possible.

• Unpaid orders: If the orders you are correlating are paid by PreAuth/PostAuth transactions, then you need to watch out for unpaid orders. You can do this using the OMARS Order Management page; choose the "list" view and set the "Filter" choice to "Only Orders to be Fulfilled". This will only show the unfulfilled orders.

  If your store allows multiple payments on an order, e.g. an initial deposit and later payments, the problem becomes more complicated since there will be multiple OMARS orders that correspond to each message from cgiemail. The e-commerce site should have been designed to put an identifier in the OrderComments field of the OMARS orders that matches an identifier in the email message they belong to. You can then employ a simple database program, such as FileMaker Pro, to solve this problem: Get a Settlement Report from OMARS listing the amount and OrderComments field. Create a file for your order emails which also includes a column of the identifier matching the OrderComments field. Now it is a simple matter of establishing a relationship between those two tables, so you can effectively add a column to the "orders" table which represents the total amount of from all settled transactions matching the order. This shows how much has been collected from the customer for each order.

XXX TODO: accounting, DTRs, etc.