MyStore3™ Purchase Order Processing

Once your customer submits a purchase order to a server or host, various activities may occur depending on the script receiving the order information and the method of payment requested.

The actual information is sent as name/value pairs of form fields in the purchase order document.  (See "purchase order" under Detail Info on your right for a list of the name/value pairs.)

The server script can be in any computer language. It could be a Perl or ASP script run within the cgi-bin directory or a ColdFusion template or any number of other possibilities. The script will have to have two basic elements:  code to read the name/value pairs and code to take an action with the name/value pairs; usually, e-mail them to you.

MyStore3™ lets you be independent of any particular server. Both the text and an HTML version of the purchase order are pre-formatted while still on the customer's computer. This means that the server receives the PO already structured into human readable form. The values of the form fields, ORDERHTM and ORDERTXT, contain the corresponding documents.

This pre formatting greatly simplifies the e-mailing of the purchase order to your location. There is no need to format at the host which can be a complex task requiring special scripts. Most internet host providers will have a simple mail form script which reads name/value pairs of submitted forms and inserts them into a mail message. The SENDTO field has the value of your e-mail address and the EMAIL field has the value of your customer's e-mail address.

Having explained that, we think that you'll find it less confusing to use one of the MyStore servers for this job. We already have the necessary scripts set up and ready to go which will transparently interface with the MyStore3 system. Best of all order forwarding is a FREE service that we provide for all users of MyStore3™.

In the configuration file there is a registration parameter, 'var serverURL ='. When you register for evaluation we send you the following URL value to enter:  "http://zanadu.com/cgi-bin/litepomail.asp". This is our demo server. It already knows how to handle the order submission. When you register to purchase we send you this URL value to enter:  http://MyStore.to/Merchant/Transactions/podirect.cfm. This is the MyStore.to secure server.

The secure server script is written using ColdFusion syntax. It handles all forms of payment requests by returning an appropriate message or information input form. It mails the text formatted order to your designated e-mail address. It mails a text formatted confirmation copy of the PO to your customer. And it provides various authentication functions to prevent miss use and bogus entries.

The MyStore.to script for instance will return a secure form for gathering credit card information from your customer if you have enabled this function from your Merchant Utility pages. It returns customized "thank you" messages with the customer name, the PO number, and your store name and e-mail contact address. It returns polite custom messages if something is wrong. IE: on a bad credit card it suggests there may have been an entry error and recommends that the customer return to the PO and submit again using an alternate payment method or else try correcting the info on the credit card form.

This ability for your customer to make corrections or select alternate methods of payment is a unique feature of MyStore3 storefronts. As long as the customer's browser remains open to the store, no order information is lost nor will the order time out.

MyStore.to offers over a dozen customized response templates that can be returned to cover virtually every situation and payment option. Payments by credit card or check on-line will require that your store be equipped with server side order logs to capture and/or process the information received. MyStore.to can provide you with your own logs and credit card processing for a small monthly fee. Please visit MyStore.to and check under "Product | Pricing" for details.

The table below is a partial list of the order payment codes that are used to tell the server how to respond and/or what additional processing is needed. The codes are sent as the value of the PAYBY field.

Customer payment options and codes:

CODEDESCRIPTION
nno payment option selected, this error is trapped at the client computer
aby customer account number: In this case the account number must be entered before the order can be sent. The number is sent to the server as the value of the field ACNTNUMBER.
cconby real time credit card process: When this code is received, the server returns a secure form for entering credit card information.
ccoffby credit card for subsequent processing: This is a convenient option for merchants that already have a merchant account and do not want the added expense of real time processing. A secure form is returned for gathering the credit card information. To the customer there appears to no difference from "ccon".
ccsepby sending credit card information off-line: This is for customers that may not want to provide credit card numbers over the Internet. Instructions to fax or call in the number are on the purchase order.
ckby check to be sent: Instructions for sending the check are on the purchase order.
ckolby check on-line: A secure input form is returned for gathering the customer's checking account information.
moby money order: Instructions are on the purchase order for sending the money order.
codby cash on delivery: Information appears on the purchase order regarding this payment option.
NOTE:
We are not recommending that you use all of these payment options. You have to decide based on your particular situation. To eliminate options that the customer has available, modify the payby[ ] option array in the configuration file.

Copyright © ImagineNation 1997 - 1999
Webmaster