A click on the "Checkout" button on the shopping cart page begins a series of steps to finalize purchase of items listed in the shopping cart. Normally, the eCommerce merchant has established an account with an external credit card processing service which handles all the financial and banking transactions surrounding the order. Involvement of the eCommerce site is minimal. Although this example site does not have formal arrangements with a commercial credit card processing service, it does illustrate the typical manner of interacting with such a service.
Credit Card Processing
The typical process includes submission of order information to the processing service and awaiting return notification of the success or failure of the transaction. Thus, when a "Checkout" button is clicked, redirection takes place to the processing service's Web site. Here, through a secure connection, the customer submits credit card information and, if approved, transactions are completed to charge the customer's account and debit the merchant's account. At completion, the processing service site returns confirmation to a designated page at the merchant site where local processing continues.
Although techniques may differ slightly, the usual manner of connecting to a credit card processing service is through a form submission. Typically, four pieces of information are required to be submitted, with options to include more information depending on merchant preferences. The four minimal fields of information are,
When the credit card transaction is completed, the processing service returns confirmation information to the merchant site, specifically to the page designated in the return URL address sent to or prearranged with the service. Again, the varieties of returned information differ depending on merchant arrangements with the service, but at minimum a single data value signifying success or failure of the transaction is returned. This can be a simple "yes" or "no" response depending on the practice. More likely, the processing service collects additional information about the customer which is returned to the merchant site. This information can include shipping and billing addresses, email addresses, and other personal information that is collected through the secure connection. If this information is not collected by the processing service, then the merchant site needs to collect it in order to ship the order and otherwise correspond with the customer. For the current example, customer information is assumed to be collected by the credit card processing service and returned to the eCommerce site. This saves from having to establish a secure local connection to collect private information.
This interaction between a merchant site and a credit card processing service is simulated by the CreditCheck.aspx page. It takes on the role of the processing service, collecting customer credit card and shipping information, approving or rejecting the order, and returning confirmation to the OrderCapture.aspx page. Information returned from the CreditCheck.aspx page is used to produce an email confirmation to the customer and to save the order information to the BooksDB.mdb database. Although not illustrated here, this saved information would become input to the eCommerce site's inventory and distribution systems for picking and shipping the order, and to other local systems that manage customer sales and services.
HTML Forms
The need exists, then, to transmit order information from the ShopCart.aspx page to the CreditCheck.aspx page, and then to transmit confirmation information from the CreditCheck.aspx page to the OrderCapture.aspx page. Recall that there are various ways to pass information from one page to another. Query strings, for instance, have been used to pass data and control information between pages of the eCommerce site. In the current case, though, forms are used to pass order information between pages since form submission is a popular method of transmitting order information to and from a credit card processing services.
Under ASP.NET, the <form Runat="Server"> tag that surrounds page content causes same-page form submission. A submitted form posts back to the same page that contains the form, normally by calling subprograms coded on the page. For credit card processing, however, a form is needed that does not post back to the same eCommerce page. The form needs to be submitted to a different page, specifically to the URL of the credit card processing service (locally, the CreditCheck.aspx page).
The need, then, is to create a page containing a standard "HTML form" that can be submitted to an external site rather than to the page itself. HTML forms represent the standard, non-ASP.NET, way of submitting form information. They are contained also within <form> tags and require use of two attributes to transmit their contents.
<form name="name" action="url" method="get|post"> ... </form>
A form may require a name depending on the processing steps surrounding the form. The action attribute supplies the URL of the page to which form information is to be sent. This can be a relative URL to a local page or an absolute URL to an external site. The method attribute indicates the manner in which form information is transmitted. The post method transmits form contents in a separate data stream accompanying the URL request and is the preferred method. The get (default) method appends the contents of the form to the URL as a query string. Unless otherwise required, the post method always should be used so as not to reveal form information in a Web-visible query string.
HTML forms include standard XHTML tags as containers for data. Normally, the container is an <input> tag with attributes shown in the following general format.
<input type="text|hidden" name="name" value="value" />
An <input> tag is the HTML form equivalent of an <asp:TextBox> control. It holds a text string value given by its value attribute. Its name attribute identifies the value since, as in using query strings, a submitted form transmits a string of name=value pairs to the destination site. As many <input> tags are coded as are needed to transmit separate data values. When setting up an HTML form to pass information between Web sites, the tag's type attribute normally is set to "hidden" rather than "text". It is common practice not to display textbox values since their purpose is only to hold values for form submission.
Normally included on an HTML form is a special <input> tag to cause form submission. This tag has a type="submit" attribute that displays the tag as a button and transmits the form to its action URL when the button is clicked. Its general format is shown below.
<input type="submit" name="name" value="value" />
It is usually not necessary to assign a name to the button. Its value attribute, however, can override the default label "Submit Query" appearing on the face of the button.
eCommerce Submit Form
When working with a credit card processing service, the layout of the HTML form is dictated by the service provider. Their documentation normally gives the URL for the form's action attribute and specifies the exact names to use for <input> tags. It is often the case that you can simply copy and paste their required form directly onto your page.
Assume that the credit card processing service used by the eCommerce site requires receipt of the four common information items described above, and that they are expected to be received under the form field names ReturnURL, MerchantID, CustomerID, and OrderTotal. The transmitting page, then, needs an HTML form in the format shown below. In this case, local URLs are shown, although these would be full http addresses when performing commercial processing.
<form action="CreditCheck.aspx" method="post"> <input type="hidden" name="ReturnURL" value="OrderCapture.aspx/> <input type="hidden" name="MerchantID" value="webWarehouse.com"/> <input type="hidden" name="CustomerID" value="11111111"/> <input type="hidden" name="OrderTotal" value="123.45"/> <input type="submit" value="Submit Form"/> </form>
A click on the "Submit Form" button sends the form to the action URL where the information is extracted from the form and used as part of the credit checking and transaction processing procedure. On completion, confirmation notification is returned to the ReturnURL page.
Accessing HTML Form Information
Pages receiving HTML form information access the transmitted information in a way very similar to accessing query strings. The received information arrives as a set of name=value pairs accessible through the Request.Form collection. The names are the name attributes that are assigned to the <input> tags; the values are the data strings associated with their value attributes. Thus, the data values sent through the previous example form are accessible in a receiving script through the following references.
Request.Form("ReturnURL") Request.Form("MerchantID") Request.Form("CustomerID") Request.Form("OrderTotal")
The receiving page captures this form information and uses the submitted values to begin the credit card checkout process.
The SubmitForm.aspx Page
With this background, return attention to the ShopCart.aspx page and consider the need to react to its "Checkout" button by submitting a form to the local CreditCheck.aspx page, which simulates processing by an external credit card processing service. Immediately you see a problem. There already is a <form Runat="Server"> tag on this page, and ASP.NET pages cannot have more than one form tag. (This <form Runat="Server"> tag is coded on the eCommerce.master page that encompasses all content pages.) Obviously, the credit check submission form cannot be coded on this page. It must appear on a page that does not contain a <form Runat="Server"> tag.
The solution is relatively simple. Transfer order information to a different page—one without a <form Runat="Server"> tag but with a standard HTML form tag—and transmit order information from there. A SubmitForm.aspx page is created for just this purpose. It needs to have available four pieces of order information: a MerchantID (which can be hard-coded on the form itself), a ReturnURL (which can be hard-coded on the form), a CustomerID (the current Session("OrderNumber") can be used for this purpose), and an OrderTotal (not yet accessible by the SubmitForm.aspx page. Therefore, the ShopCart.aspx page needs to ensure that the total amount of the order is available when transfer is made to the SubmitForm.aspx page. It can do so by assigning the order amount to a Session variable.
When the "Checkout" button on the ShopCart.aspx page is clicked, subprogram Submit_Form is called. It saves the total order amount as a Session variable, and then redirects to the SubmitForm.aspx page.
Sub Submit_Form (Src As Object, Args As EventArgs) Dim OrderTotal As Label = ShopCartGrid.FooterRow.FindControl("OrderTotal") Session("OrderTotal") = OrderTotal.Text Response.Redirect("SubmitForm.aspx") End Sub
The GridView's FindControl() method locates the OrderTotal Label in the footer row as the source of the order's total amount. This value is saved as Session("OrderTotal") in order to be accessible when redirection takes place to the SubmitForm.aspx page.
Code for the SubmitForm.aspx page includes a standard HTML form with fields representing the four items of information needed for submission to the credit card processing service.
<html> <head> <title>SubmitForm</title> </head> <body onLoad="SubmitForm.submit()"> <form name="SubmitForm" action="CreditCheck.aspx" method="post"> <input type="hidden" name="ReturnURL" value="OrderCapture.aspx"/> <input type="hidden" name="MerchantID" value="webWarehouse.com"/> <input type="hidden" name="CustomerID" value="<%=Session("OrderNumber")%>"/> <input type="hidden" name="OrderTotal" value="<%=Session("OrderTotal")%>"/> </form> </body> </html>
Importantly, this is a stand-alone ASP.NET page that is not associated with the eCommerce.master page. It does not include a <form Runat="Server"> tag. Instead, it contains a standard HTML form with <input> tags named according to required field names for the credit card processing service.
As noted, the ReturnURL and MerchantID values can be hard-coded on the form since they do not change. The CustomerID and OrderTotal values are given by like-named Session variables. In-line expressions automatically supply these Session values; therefore, when the page loads the form is ready to be submitted.
Form submission needs to be automated rather than defining a submit button for manual submission. There is no reason to present the customer with this page and require another button click to submit the form. This is only a pass-through page for form submission. So, no submit button is included on the form. Rather, a JavaScript submit() method is applied to the form to immediately submit it to the CreditCheck.aspx page when the page loads. Note that the form must include a name attribute that can be referenced by the submit() method.
<body onLoad="SubmitForm.submit()">
Since loading of the form and its submission are script directed, the customer has no visual awareness that this is happening. After clicking the "Checkout" button on the shopping cart page, the very next screen displayed is the CreditCheck.aspx page. The SubmitForm.aspx page is run behind the scenes with no customer awareness.