Hosted Payment Form

The Transaction Process

The NETbilling Gateway's robust transaction processing engine has many extras that make it more than just a simple swipe terminal. Here we'll examine some of them by looking at the process of making a payment with the Payment Form.

To begin, a customer will choose products or subscriptions to purchase from your website, or shopping cart if you have one. If you have only a few products to sell, the NETbilling Gateway's admin system includes a Button Editor (Setup -> Button Editor) that will help you generate the proper HTML code to accept a payment in a specific amount. These buttons can be put on a page on your site and clicked on by the customer to be sent to our Payment Form, where we will collect the customer's payment information. Alternatively, you can create an HTML form of your own, collecting any information from the customer that you like. If this information duplicates the information requested on the Payment Form, then you can pass it along with the customer to the Form and it will be automatically entered into the Form, or if you collect all the information requested by the Form, you can pass it all and have the Form not display at all. In either case, once the customer has filled out any information requested by your site, you use an HTML form POST to send the customer, and any information, to the NETbilling Gateway's Payment Form. You can send this information securely by encrypting it using the Order Integrity feature of the Payment Form, essentially an MD5 checksum of the transaction information. If you are unfamiliar with MD5, don't worry; the Button Editor can set it up for you automatically, and the process of setting up Order Integrity yourself is described later in this document.

At this point, if the transaction is a membership signup or subscription, the customer is first prompted by the Payment Form to choose a username and password, unless you sent one along with the transaction information. Then the Payment Form requests the customer's credit card or checking and billing information, if it was not sent along with the transaction data. If the payment fails, the customer is returned to the Payment Form to try again. The number of tries is definable in the admin system (Security -> Risk Mgmt); if you want the first failure to take the customer to a web page instead of letting them try again, you can configure that as well. It's important to note that by default, the customer is returned to the Payment Form, so if you were sending all the transaction data and expecting the form to not be displayed at all, this will not be the behavior you expect. If payment fails too many times, then the customer is sent to a URL you have selected (Setup -> Website Config -> Giveup URL), with no payment made. If payment is made successfully, then the Payment Form displays a receipt to the customer, as well as e-mailing receipts to you as the merchant and to the customer. These receipt e-mails are also completely configurable (Setup -> Website Emails), and can remind a new customer of his username and password or just provide a simple "Thank you" and receipt. The system can also be configured to post the transaction data directly back to your site (Setup -> Website Config -> Postback CGI URL), so you don't need to rely on the customer's clicking through on the receipt page.

If the transaction is a membership or subscription, the the NETbilling Gateway servers can also be configured to connect to a CGI on your system and automatically post member information to your server, such as the member username and password (Setup -> Website Config -> Control CGI URL). If configured, this CGI will also receive a nightly post from the NETbilling Gateway, telling it which memberships have expired and which are still valid. While the NETbilling Gateway provides a Perl CGI script for the purpose of receiving these posts, it usually requires some programming knowledge to implement successfully.

Finally, the customer is directed back to a specified URL on your site. Transaction data will be sent along with the customer as a form POST or GET. If you have web coding experience, you can use this information to automatically control shipping or membership activation or anything else appropriate. Otherwise, the only indication you'll have of successful payments will be in the excellent reporting tools in the admin system or the receipt e-mail sent to the merchant with each transaction.

Website Configuration

To begin, configure your website information in the NETbilling Gateway's admin system. Under Site Tools, you'll find an option for Site Tags. Typically there will be a default site already set up for your account. Some customization will be necessary to setup a smooth payment system. Click on config next to the default website, or choose a short site tag, website name, and URL, and choose Add Site. Then click config next to the new site. The Site Tag is a mnemonic for your website, and will be passed along with the transaction data for each transaction. It's possible to set up multiple websites, and you can use the site tag to differentiate between payments for each site. There is no limit on the number of sites you can have configured in the NETbilling Gateway's system.

Most of the options under the site configuration screen are self explanatory. Here are some that may not be:

1. Return URL - This is the HTML or CGI page on your site that the customer is sent to after completing payment. The customer will be sent here with a POST or a GET containing the transaction information, so if you have the ability to code a CGI to handle this data, this is where you put it's URL.
2. GiveUp URL - This is where a customer is sent if payment is unsuccessful too many times. How many attempts are allowed is definable in the admin system under Security -> Risk Management.
3. Postback CGI URL - After processing each transaction, transaction data is sent to this CGI, if you have configured it. This is done because a customer failing to click-through on the Payment Form's receipt will never get directed back to your site, and the transaction data normally sent along with the customer will never get to your site. The Postback CGI allows a way around this, but requires some knowledge of web programming.
4. Return Method - This determines whether the transaction data is sent along with the customer as a POST or a GET. We strongly recommend POST, however if you are planning to collect all the transaction data before the transaction and not have the Payment Form displayed to the customer, the customer will be returned with a GET regardless of this setting. This is due to the way redirects are handled in HTTP.
5. Payment Form - We will be devoting a section to configuring the Payment Form specifically in a moment. In the meantime, you may wish to note which Payment Form the website is currently configured to use. You can have a different Payment Form setup for each Website.
6. Cancellation URL - You can copy this link onto your website, and a customer can click on it to automatically cancel his membership. This is a good reason to use the next option -- the Control CGI. See Appendix F for more information on Self Cancellation.
7. Control CGI URL - The URL of a CGI on your site that processes usernames and passwords for memberships. The NETbilling Gateway's servers will post a list of valid and expired usernames nightly, if you are processing memberships. The sample CGI available here is a Perl script that will most likely need some modification to work properly on your website.

Once you have configured the site to your satisfaction, choose Apply. At the top of this screen you will find the option to configure e-mail; this is where you go to choose which receipts get sent under what circumstances. You can design these receipts using the Email Editor under Setup in the menu. In the meantime, choose edit pmt form to go to the Form Editor.

The Form Editor

This form has a number of options. You can define your own colors and logo to display on the Payment Form, as well as configure the names of the fields the form accepts. If you use a shopping cart, you can also choose pre-made forms to support the field names sent by that shopping cart. Remember that changing the field names may cause any old code (such as buttons made from the Button Editor) to fail until that code is updated to reflect the new field names.

You may notice that some of the fields duplicate information from the website config. If these fields are sent with the transaction, they will override what is set for the website. If you are setting up your own payment form, the field names here are the ones you will POST to the NETbilling Gateway. You will need some minor HTML coding skills to do this. If you haven't been into the NETbilling Gateway admin system before, you may want to check out and configure some of the other options available, such as the options under Security in our menu. You'll also need to define your merchant account under the Credit Cards option under Setup. Remember to choose Apply at the bottom of the screen when you are done configuring the system, or your changes will not be saved.