Authorizing Credit Cards via a Gateway Introduction Please review the basic shopping online tutorial. This tutorial is an extension of the basic shopping online tutorial and explains how to integrate a credit card gateway into the shopping basket system. Credit card payments in a default shopping basket are not authorized or charged during the shopping basket process. Rather, the payment information is collected and the order recipient is responsible for authorizing the credit card via a terminal, online terminal, phone, etc. In order to accept credit cards you must first obtain a merchant account. The merchant account gives you the ability to charge credit cards and transfer those funds to your checking account. All merchant accounts are issued by a bank. You may apply for a merchant account at your local bank or may get a recommendation from your internet service provider. Be aware that many of the largest banks in the U.S. do not grant merchant accounts to merchants with an internet only business. In addition, U.S. banks do not grant merchant accounts to merchants outside of the U.S. You may need to investigate several sources before you find a bank that meets your needs. While the merchant account allows you to accept and process credit cards, the merchant account itself does not necessarily allow you to process credit cards online. This service may be provided in conjunction with your merchant account, but can also be obtained separately through a gateway service. Using a credit card gateway service you can authorize and/or charge a shopping basket (or form) sale real-time during the shopping process. The gateway service approves or declines a credit card charge and transmits that decision to your web site for further processing. All gateway services have different requirements and transmit information via different methods. See the instructions for your specific credit card gateway for these requirements. Regardless of the service, the basic process of authorizing credit cards via a gateway is as follows: Collect customer order, payment, billing, and shipping information. You are generally required to transmit the customer's information (e.g., credit card number, etc.) to the gateway service via post or path arguments from a secure server. Therefore the customer must first provide order, payment, billing, and shipping information via the MGI shopping basket or even a simple form. Display customer information for confirmation and prepare data for the gateway service. On the order confirmation page, you can display the payment, billing, shipping and order information for the customer to review as well as prepare your data in the specific format for your gateway service (e.g., specific post argument names). Transmit data to the gateway service. On the order confirmation page, you will transmit the data to the gateway service via a FORM post, an HREF with path arguments, etc. Depending on the service you choose, the customer may view forms from the gateway service during the shopping process or all gateway processing may occur in the background through redirects such that the customer never appears to "leave" your web site. Receive response from the gateway and process order. The gateway service will either approve or decline the credit card charge. Many gateway services also "mirror" the payment, billing, and shipping information that was provided to them. The gateway service may respond to different URLs based on the outcome of the charge or may just provide the decision in a path argument or post argument which you can use in conjunction with a conditional to determine the course of action. In any case, the service will provide some response regarding the credit card charge (approve or decline). If the credit card is successfully processed, process the order. If the credit card is declined, present the use with an error and other processing options OR process the order noting the decline and contact the customer directly for resolution. If you are integrating a gateway service into an MGI shopping basket, you will need to modify your order confirmation page and customize your order email. You may also need to construct a separate error page for credit cards that are declined. The Accesspoint gateway service is used as an example below, however, you can use almost any gateway service provided that the mgiToken value is transmitted back to the order processing page. The mgiToken value is required in order to access the customer's shopping basket information. If the mgiToken value cannot be transmitted through the gateway service, you may need to save the order information in a cookie or database and access that information to process the order. MGI Tags mgiConfirmOrder mgiGet mgiIf mgiInlineToken mgiPathArgument mgiSendOrder Steps Open the confirm order page in a text editor. Prepare data for the gateway service. Save the confirm order page. Open the order processing page in a text editor. Customize the order email. Save the order processing page. FTP the confirm order and order processing pages to the web server running MGI. Configure gateway settings. Process an order in test mode. Step 1: Open the confirm order page in a text editor. Open the confirm order page in a text editing program that allows you to view and modify the HTML and code of the page. Step 2: Prepare data for the gateway service. On the confirm order page, prepare the payment, billing, shipping and order information to transmit to the gateway service.   In this example, the payment, billing, shipping and order information is submitted via hidden post arguments created by the mgiConfirmOrder tag to the Accesspoint gateway server (https://secure1.merchantmanager.com/ccgateway.asp). The post argument names are specific to Accesspoint. The post argument names may be different for other gateway services.   If your post argument names are different, create custom hidden post arguments for payment, billing, shipping and order information with embedded mgiPostArgument and mgiGet tags using information from the check out form and order totals from the mgiConfirmOrder tag. The mgiConfirmOrder tag automatically creates hidden post arguments for all post arguments posted to the confirm order page. If you use a custom check out page with form fields specific to your processor, you may not need to add custom hidden post arguments on the confirm order page.   In addition, the merchant ID, request type, and transaction type specific to Accesspoint are submitted via post arguments. The merchant ID is your specific Accesspoint ID. The request type is "ApprovalOnly" which creates a seamless transition from the confirm order page to the approved or denied URL. With the "ApprovalOnly" request type all processing is performed in the background and the customer never appears to "leave" your web site. The transaction type is "Sale" to authorize and charge the credit card, but can be set to "PreAuth" to only authorize the card. See the Accesspoint manual for additional information about request types and transaction types.   The Accesspoint gateway redirects approved and declined charge requests to specified URLs. Those URLs are included as post arguments and are appended with the mgiToken using the mgiInlineToken tag. The approved URL may be different from the denied URL, however in this example both URLs redirect to the same page and the approval message is compared in a conditional to determine the course of action.   The following is an example confirm order page with data prepared to transmit to Accesspoint. Note that the mgiConfirmOrder tag automatically creates the hidden post argument for payment, billing and shipping information. <FORM ACTION="https://secure1.merchantmanager.com/ccgateway.asp" METHOD="Post"> <mgiComment>Account Post Arguments</mgiComment> <input type="hidden" name="REQUESTTYPE" value="ApprovalOnly"> <input type="hidden" name="TRANSTYPE" value="SALE"> <input type="hidden" name="MERCHANTID" value="accountID"> <mgiComment> Approved and Denied URLs with Tokens</mgiComment> <mgiSet name="Denial"> <mgiInlineToken url="https://secure.domain.com/folder/denied.mgi"> </mgiSet> <input type="hidden" name="DENIEDURL" value={mgiGet name="Denial"}> <mgiSet name="Approval"> <mgiInlineToken url="https://secure.domain.com/folder/approved.mgi"> </mgiSet> <input type="hidden" name="APPROVEDURL" value={mgiGet name="Approval"}> <mgiComment>Confirm Order and Order Total</mgiComment> <mgiConfirmOrder handle="Default" shoppingBasketURL="http://www.domain.com/shop/"> </mgiConfirmOrder> <input type="hidden" name="AMOUNT" value={mgiGet name="mgiSBTotal"}> </FORM> Step 3: Save the confirm order page. Save the changes you have made to the confirm order page. Step 4: Open the order processing page in a text editor. Open the order processing page in a text editing program that allows you to view and modify the HTML and code of the page. Step 5: Customize the order email. In a default shopping basket, payment, billing, and shipping information is posted to the order processing page from the confirm order page and the token value is used to obtain order information from the shopping basket database. Real-time processing requires a custom order email because the payment, billing and shipping information may be transmitted from the gateway service via a different method (path arguments rather than post arguments) and the information may have different names.   In this example, Accesspoint transmits the mgiToken and approval decision, plus the order, payment, billing, and shipping information via path arguments. The approval path argument ("approved" equals "Y" or "N") is compared in a conditional statement with the mgiIf tag. If the order is approved, the order is processed with the subject "Online Order". If the credit card is declined, the order is processed with the subject "Declined Order - Followup With Customer" and the reason for the decline is included in the email. If you prefer, you can give the customer a tokenized link to the check out page to enter a different payment option or correct the payment information they entered before re-submitting the order.   The order email is customized with the payment, billing, and shipping path arguments. The credit card number is not transmitted from the gateway service in this example, but that information is available online via the gateway service administrative interface if needed. The items orderd are entered by the mgiSendOrder tag based on the mgiToken path argument.   The following is an example order processing page with information from the Accesspoint gateway. <mgiIf lhs={mgiPathArgument name="approved"} relationship="equals" rhs="Y"> <mgiSet name="Subject"> Online Order </mgiSet> <mgiElse> <mgiSet name="Subject"> Declined Order - Followup With Customer </mgiSet> </mgiIf> <mgiSendOrder handle="Default" shoppingBasketURL="http://www.domain.com/" to="orders@domain.com" from="webmaster@domain.com" mailServer="mail.domain.com" subject={mgiGet name="Subject"}> Processing Information ---------------------- Message: <mgiPathArgument name="msg"> Invoice No: <mgiPathArgument name="invoiceno"> Payment Information ------------------- Card Type: <mgiPathArgument name="CardType"> Expiration: <mgiPathArgument name="EXPMO"> <mgiPathArgument name="EXPYE"> Name: <mgiPathArgument name="CCName"> Billing Information ------------------- Name: <mgiPathArgument name="bName"> Company: <mgiPathArgument name="bCompany"> Address: <mgiPathArgument name="bAddress1"> <mgiPathArgument name="bCity"> <mgiPathArgument name="bState"> <mgiPathArgument name="bZipCode"> <mgiPathArgument name="bCountry"> Phone: <mgiPathArgument name="bPhone"> Fax: <mgiPathArgument name="bFax"> Email: <mgiPathArgument name="bEmail"> Shipping Information -------------------- Name: <mgiPathArgument name="sName"> Company: <mgiPathArgument name="sCompany"> Address: <mgiPathArgument name="sAddress1"> <mgiPathArgument name="sCity"> <mgiPathArgument name="sState"> <mgiPathArgument name="sZipCode"> <mgiPathArgument name="sCountry"> Phone: <mgiPathArgument name="sPhone"> Fax: <mgiPathArgument name="sFax"> Email: <mgiPathArgument name="sEmail"> Order Information ----------------- <!-- Begin Template --> Product ID: &mgiDBFieldProductID; Qty: &mgiDBFieldQuantity; Product: &mgiDBFieldName; Price Each: $&mgiDBFieldPrice; Item Total: $&mgiSBItemPriceTotal; <!-- End Template --> Tax: $&mgiSBTax; Total: $&mgiSBTotal; </mgiSendOrder> Step 6: Save the order processing page. Save the changes you have made to the order processing page. Step 7: FTP the confirm order and order processing pages to the web server running MGI. Upload the confirm order and order processing pages from your local computer to the web server using an FTP program. Step 8: Configure gateway settings. In order to use a gateway service, you may need to configure settings such as the URL of the confirm order page where orders originate, global approved and denied URLs, etc   For the Accesspoint gateway service, access the Transaction Manager interface. Select "Administration" then select "Remote Processing". From the Java menu or pop-up, just select "configure my remote processing options". Under "Mode", select "Test" while testing your service or select "Live" to use the service with a production web site. Under "URL of Order Form or IP address of Web Server", enter "https://" if your orders originate from a secure server or enter "http://" if you orders originate from a non-secure server. Leave all other settings as default and click the "Update" button at the bottom of the page to save the settings. Step 9: Process an order in test mode. Set the gateway options to "test" mode and process a shopping basket order.   For Accesspoint, set the "Remote Processing" mode to "Test". Use the credit card number "5111111111111111" with any other payment, billing, or shipping information to see an approved order and use the credit card number "4111111111111111" with any other payment, billing, or shipping information to see a denied order. When the real-time system is working to your satisfaction, set the "Remote Processing" mode to "Live".