Posting to a secure generic form on our server

This method offers several advantages over other methods. It relieves you of the need to create the receipts and does not require an SSL server for you or your client as the credit card information will all be collected once the visitor is on our secure server.

As our CGI will be generating the receipts we do need a certain amount of information to be passed to the form, such as subtotal, taxes, the name, quantity and the price of each product ordered. The order number is automatically generated by the CGI based on epoch time.

Getting Started

First and foremost, in order to begin processing payments using any of our methods you must have an Internet merchant bank account and a payment processing account with us. If you are unsure that you have these, or if you need them set up, please contact our sales department at 1-604-684-5671. If you intend to accept payment in both Canadian and US dollars, you must use separate merchant accounts and payment forms for each currency.

Once you have been assigned a merchant ID and password for the payment processing account we can begin configuring the payment form to process your payments. Our sales department will contact you to determine the exact parameters you will be using to communicate between your server and the payment system.

You can save time by determining these parameters in advance. The structure of the configuration requires the following:

Merchant Information

This is the company name/address information for receipts and for display to the customer when using the payment form and the confirmation screen. The plain text and formatted addresses can be sent to our sales department in an email message to eliminate errors in entering the information.

• Company Name - the company name that will appear on the receipts.
• Company Email - the email address of your company that copies of all receipts will be mailed to.
• Company Address (plain text) - the address of your company in plain text (no formatting) for display on the receipts.
• Company Address (formatted) - the address of your company formatted with HTML for display on screen when the user views their payment confirmation in their browser.
• Currency Unit - usually CAD (Canadian Dollars) or USD (US Dollars). This is the currency unit that is displayed on the receipt. It does not affect the currency that your transactions are processed in.

Payment Methods

Although this is determined when setting up your payment account, you still need to show your customers which payment methods are available on the payment form. Our sales department needs to know each specific payment method you will be accepting using the payment form. The current payment methods are:

• Visa
• Mastercard
• American Express
• Diners Club/Enroute
• Discover Card
• JCB

Please note: you cannot use a payment method for which you are not authorized in your payment account configuration (ie; you can't process Discover Card transactions without being authorized by your bank). For more information on processing various card brands, please contact our sales department.

Design Information

This is the look and feel of the payment page. These items allow you to completely customize the look of the payment page so that its design matches the design of your site. It is also where you specify what information is being collected from the customer on the payment form and what information will be passed to the payment form from your site. It consists of:

• the page header
• the page footer
• the submit button text - this is what the payment form's "Submit" button will actually say on it.

We wrap the page header HTML and page footer HTML around the actual payment form. The background of the payment form takes on the background specification in the header.

The best way to convey the design you want to us is to do an HTML mockup page of the payment form in the style of your site and send it to us. Any graphics or style sheets used in the page should be referenced by URLs pointing to files on our server under a directory called images/[yourstorename]/. For example, if your storename is sp123, the logo on your page would be referred to in the page as "images/sp123/logo.jpg" instead of just "/images/logo.jpg".

Customer Address Information

These items determine what fields will be shown on the payment form for data collection. They are:

• whether the customer's name/address information is passed to the form by your site or collected by the form. This determines whether or not the form displays customer information input fields.
• whether the shipping address information is passed to the form by your site, collected by the form or not collected at all.

Receipt Parameters

This describes the link displayed on the receipt which will take the user back to your site and information to be sent back to you. The parameters are:

• Include all form fields in merchant's copy of the receipt? This parameter allows you to transmit additional fields to the payment form and have them all sent back to you in your copy of the receipt. This is useful if you want to carry over information like shipping weight, user account information or anything else used in post-payment (after the payment) processing.
• Show "back to the store" link on the receipt? This parameter allows you to specify whether or not to provide a link on the receipt for the customer to use to get back to your site. If this is "Yes" then the next two parameters must be specified.
• Link URL - the complete URL (eg; http://www.mysite.com/orderfinished.html) of the page the customer will be taken to when they click on the return link.
• Link text - the text to display to the customer for the Link URL (eg; "click here to return to MySite.Com").

Background Post Information

After payment has been processed, the customer is displayed the receipt and an optional link to return to your site. There is an additional option that posts payment information to a CGI script on your server in the background (a "backpost") while displaying the receipt to the customer. This is extremely useful to developers who want to program an automatic order fulfillment or payment reconciliation system. These parameters tell the payment system how to communicate with that CGI script:

• Make a background post to merchant's server? Yes or no answer.
• Over SSL? This tells the payment system whether to prefix the URL with "HTTP" or "HTTPS".
• Merchant Server. This is the server name part of the URL for the background post CGI (eg; "www.mysite.com", "cart.shoppingsite.com", etc...).
• Merchant CGI. This is the script part of the URL (eg;"/scripts/backpost.cgi"). It must be prefixed with "/".
• Include server answer in merchant receipt? Yes or no.
• Include server answer in customer receipt? Yes or no.

The last two parameters tell the payment server what to do with the response that comes back from the background post CGI. The communication is a two-way process. Once the payment system posts it's information to your background post CGI, your script can process it however it wants and can reply with text that can be included in the receipts. This could be used for information like giving the customer an estimated date of delivery, putting special handling instructions in the merchant receipt, etc...

Note: If you anticipate using seperate development environment, please submit the data for both live and test environment from the start. Please identify each environment clearly (TEST or PRODUCTION). After development period is over, TEST environment data will be removed from our system.

Configuring Your Application

Now that the payment system is configured to begin accepting information from your server and processing your customers payments, it's time to configure your application to pass the appropriate processing parameters. The basis for all processing is the URL for the payment script, which is:

https://www.strategicprofitsinc.com/generic_form/payment_form.php

NOTE! The URL must begin with HTTPS. This initiates a Secure Socket Layer (SSL) connection between the payment form and your customer, protecting your customer's information from being intercepted. If you send the customer to the page without using HTTPS, the customer will not be presented with the payment form, but will instead be presented with a security warning message.

Getting Your Customer to the Payment Form

To get your customer to the payment script and begin payment processing, you must present your customer with a way to get to our payment form from your site. This can be accomplished by:

1. Having the user send us the information as form fields (user initiated POST method). Create a form on your site with hidden fields containing the required fields for processing. The form action must be the URL of the payment form on our server. When the user clicks on the submit button, the information will be passed to the payment form.
2. Having the user send us the information as URL parameters (user initiated GET method). Create a script on your site that contains a hyperlink to the payment form. In the link, put the parameters necessary for processing the payment (eg; https://www.strategicprofitsinc.com/generic_form/payment_form.php?merchant_storename=sp123&subtotal=123.45&taxes=12.34). When the customer clicks on the link the parameters will be passed to the payment server in the address line.
3. Redirecting the customer to the payment form URL with parameters (browser redirected GET method). This is the same as the previous method only instead of asking the customer to click on a hyperlink, a script on your site tells the browser to automatically redirect the user to the payment page URL with the parameters attached. Although this method is for more advanced developers, it simplifies the process for the customer by removing one more thing for them to click on.

Required Parameters

The minimum required parameters (fields) that you must pass to the payment system for processing a transaction are:

• merchant_storename - the merchant storename for your payment processing account(eg; sp123)
• subtotal - the subtotal of the purchase without taxes and shipping.
• taxes - total taxes on the purchase. This can be 0.00 (see product price for formatting)
• shipping - shipping charge, if there is any. Also can be 0.00.
• products - list of product items that will be displayed on the receipt.

The products list can be thought of a continuous stream of records with each record separated by the characters "||". Each field in the record is separated by the characters "::". The product record fields are:

• product name
• product price - this must be formatted as a numeric string with two places after the decimal, no commas and no currency symbol. For example "1234.00" is valid, "$1,234" is not.
• quantity

Example products list:

Left-Handed Catchers Mitt::120.00::1||Softball::7.99::5

Note that the extended price (price times quantity) is not included in the record. The extended price is automatically calculated by the payment system for display on the receipt.

Optional Parameters

If you choose to send the billing address and shipping address information to the payment system, you must use the following field names to denote the parameters

Beyond the required and optional parameters, you may send any parameters to the payment system that you want and have them returned to you through the background post CGI and receipt.

Return Values

Besides the values you send to the payment system and the values that are collected on the payment system, one more variable is sent back to you. The variable "status" returns the final status of the credit card transaction. The possible values returned in this variable are:

• APPROVED - the transaction was approved
• DECLINED - the transaction was declined. No explanation is returned to the customer.
• ERROR - an internal (bank) processing error was encountered.

Unavailable Values

The following values are never made available to merchants or customers under any circumstances:

• Credit Card Number
• Expiry Date
• Name On Card

Back