The Redirect Manager (available ONLY with our Linux Hosting Packages) in your Control Panel gives you the ability to seamlessly forward requests for any local folder, sub-folder or file on your website to another Domain name, URL or IP address. For example, if you want http://www.your-domain-name.com/somepath to redirect to http://www.some-other-domain.com, then you can use the Redirect Manager to define a rule for this. It is very easy-to-use, and allows you to add as many such web forwarding rules as you want.
Enabling Redirection
1. Login to your Control Panel and search for the domain name for which you have purchased this hosting package. Click here to read how >>
2. In the search results view, click on the domain name. This will take you to the order details view.
3. Click on Manage Web Hosting Service in the lower toolbar.
4. In the Website Management interface pop-up that follows, go to Manage Website -> Web Server Manager -> Redirect Manager -> Add Redirect.
5. Here, specify the following details:
6. Click on Submit.
Modifying Redirection
1. Perform steps 1-3 mentioned in the above process.
2. In the Website Management interface pop-up that follows, go to Manage Website -> Web Server Manager -> Redirect Manager -> List Redirects.
3. Click on the Redirect From link to go to the Redirect Details page for that specific redirection.
4. You can modify the Redirect To URL field value.
5. Click on Submit.
Disabling Redirection
1. Perform steps 1-2 mentioned in the above (modifying redirection) process.
2. Select the checkbox adjacent to one or more redirects, which you wish to disable.
3. Click on Delete button and confirm the action by clicking on OK.
4. Click on Delete to provide the final approval for deletion.
In order to complete the action, the Web Server needs to be restarted. Random restarts affect other services running on the Server. In order to avoid this, the Server has been scheduled to restart at intervals of 20 minutes. Hence, each one of the above mentioned actions might take upto 20 minutes to be effective.
Tags: Checkbox, Control Panel, Destination Url, Details View, Domain Address, Domain Name, Final Approval, Forward Requests, Gt 2, Gt Web, Ip Address, Linux, Manage Web Hosting Service, Management Interface, Manager, Redirect Manager, Redirect Url, Search Domain, View 3, web forwarding, Web Hosting Service, Web Redirect, Web Server, Web Server Manager, Website Management
The Website Speed Booster is a feature unique to Gossimer, and is available ONLY with the Linux Web Hosting Package. This tool automatically enhances the speed of your website by up to 20 times and more!
How does it work?
The Website Speed Booster works by compressing the content delivered to the client when it is sent across the Internet, making use of the browser’s ability to uncompress this data seamlessly. The tool does not require any changes in website code, nor does it require any additional software on the user’s end. All browsers starting from Internet Explorer 4.0, Netscape 4.06, Opera 5, Lynx 2.6 support this feature. Besides, this solution will simply not compress the data if the visitor has a non-compliant browser, so it presents no risk to your website at all.
Using this tool from your Control Panel, you can boost the speed of all of the following:
Specifying Speed Booster settings
Follow the process mentioned below to specify your Website Speed Booster settings:
1. Login to your Control Panel and search for the domain name for which you have purchased this hosting package. Click here to read how >>
2. In the search results view, click on the domain name. This will take you to the order details view.
3. Click on Manage Web Hosting Service in the lower toolbar.
4. In the Website Management interface pop-up that follows, go to Manage Website -> Web Server Manager -> Website Speed Booster.
5. On this page, select Yes from the drop-down adjacent to the type of content you wish to optimize. You can choose to boost
For disabling the feature, you need to select No from the drop-down.
6. Click on Submit.
In order to complete the action, the Web Server needs to be restarted. Random restarts affect other services running on the Server. In order to avoid this, the Server has been scheduled to restart at intervals of 20 minutes. Hence, the change might take upto 20 minutes to be effective.
Tags: Additional Software, Content Images, Css Files, Details View, Doc Pdf, Downloadable Articles, Gif Jpg, Gt 2, Gt Web, Internet Explorer, Linux, Linux Web, Manage Web Hosting Service, Management Interface, Manager Gt, Opera 5, Pdf Xls, Perl, Php, Speed Booster, View 3, Web Hosting package, Web Hosting Service, Web Server, Web Server Manager, Website Management
In order to use the Live Chat Service on your website, you need to retrieve the HTML code and put it on your website.
Follow the steps mentioned below to obtain the code:
1. Login to your Control Panel, search for the Domain Name for which you have purchased the Live Chat Service and proceed to the Order Details view page. Click here to know how >>
2. Here, click Manage Live Chat Service. This will take you to the Registered members area.
3. Here, click the code that you require from the different types of codes listed under INTEGRATION CODE section, and copy this code to your website. Click here to know about different types of codes available >>
1. If you use the code available within the LivehelpGenie Operator software, the visitors will be visible only to the Agent who copied the code.
2. The code provided in the software is different than the one provided within the control panel.
3. Ports in the range 37643 to 37648 need to be enabled/opened for the following to work:
i. Live Chat Agent software – If this software is installed on a computer that is behind a Firewall or Proxy Server, then you need to request your System Administrator to enable/open these ports for you.
If you are connected to the Internet via a Cable/DSL ISP, then you need to contact your ISP and request them to enable these for you. Typically, Dial-up Internet users do not face port blocking issues and would not have to request their ISP for enabling these ports.
ii. Live Chat code for your website – If the web server where your website is hosted (which has the LivehelpGenie Live Chat code installed) behind a Firewall, then you need to request your Web Hosting Provider to enable/open these ports for you.
Tags: Agent Software, Area 3, Cable Dsl, Chat Code, Chat Service, Control Panel, Domain Name, Firewall, Gt 2, HTML, Html Code, Integration Code, Internet Users, Isp, Live Chat, Live Chat Service, Members Area, Operator Software, Ports, Proxy Server, Registered, System Administrator, Web Hosting, Web Hosting Provider, Web Server
In order to secure your domain name on multiple servers, you need to purchase Additional License(s) for your Digital Certificate.
In order to purchase Additional License(s) for a Digital Certificate, the Digital Certificate -
- needs to be under Issued status
- should not be under Suspended status
Follow the process mentioned below to purchase Additional License(s) for your Digital Certificate:
Tags: Control Panel, Details View, Digital Certificate, Domain Name, Duration, Formalities, Lifecycle, Nbsp, Purchasing, Servers, Software Type, Suspended License, Web Server
The Scheduled Task Manager (available ONLY with our Linux Hosting Packages) in your Control Panel gives you the ability to schedule a task (cron) for your website to run on specific days and at specific times. For example, if you want to run a particular script at midnight on every Sunday, then you can use the Scheduled Task Manager to define a task for this. It is very easy-to-use, and allows you to add as many such scheduled tasks as you want.
Adding a Scheduled Task
1. Login to your Control Panel and search for the domain name for which you have purchased this hosting package. Click here to read how >>
2. In the search results view, click on the domain name. This will take you to the order details view.
3. Click on Manage Web Hosting Service in the lower toolbar.
4. In the Website Management interface pop-up that follows, go to Manage Website -> Scheduled Task Manager -> Add Scheduled Task.
5. Here, specify the following details:
6. Click on Submit.
Modifying a Scheduled Task
1. Perform steps 1-3 mentioned in the above process.
2. In the Website Management interface pop-up that follows, go to Manage Website -> Scheduled Task Manager -> List Scheduled Tasks.
3. Click on the Command link to go to the Scheduled Task Details page for that specific scheduled task.
4. Make modifications to the desired fields.
5. Click on Modify.
Deleting a Scheduled Task
1. Perform steps 1-2 mentioned in the above (modifying a scheduled task) process.
2. Select the checkbox adjacent to the scheduled task, which you wish to delete.
3. Click on Delete button and confirm the action by clicking on OK.
In order to complete the action, the Web Server needs to be restarted. Random restarts affect other services running on the Server. In order to avoid this, the Server has been scheduled to restart at intervals of 20 minutes. Hence, each one of the above mentioned actions might take upto 20 minutes to be effective.
Tags: Checkbox, Control Panel, Cron, Details View, Domain Name, Gt 2, Linux, Manage Web Hosting Service, Management Interface, Notifications, Parameters, Scheduled Task Manager, Scheduled Tasks, Task Details, Task List, Task Manager, View 3, Web Hosting Service, Web Server, Website Management
The System has the built-in ability to allow you to integrate ANY Payment Gateway to allow your Customers and Sub-Resellers to pay you. Obviously EVERY Commercial Payment Gateway has a DIFFERENT Integration Process. There is no way to build a generic module that can directly talk to ANY Payment Gateway. Instead what we have done is built a module that can pass parameters to an intermediate bridge on your server, that you can then integrate with any Payment Gateway of your choice.
The logic of the flow in this integration is quite simple -
Step 1: Any Customer/Sub-Reseller of yours needs to pay you money and selects a Payment Gateway to do so.
Step 2: We simply create a collection of messages that you will need to charge this Customer/Sub-Reseller. This set of messages would contain things like Order Information, Amount etc. We then redirect the Customer to YOUR Server with this set of messages.
Step 3: You then charge the Customer/Sub-Reseller using these messages, and your Payment Gateway.
Step 4: You then redirect the Customer BACK to our Server with a status of the transaction as to whether you have successfully charged the Customer/Sub-Reseller.
Step 5: Once this is done we Add these funds to the Customer/Sub-Reseller account, and/or process any associated Orders.
This interaction can be diagrammatically represented as follows -

Let us break down the process you need to carry out in order to complete integrating your Payment Gateway with our system
|
[i] What you will Need |
You will need the following before you begin integrating your Payment Gateway with the System
Details on the process of integrating with your Payment Gateway
Server space on your server
Download the appropriate integration kit from the below list depending on what your Server supports for the integration
ASP Integration Kit version 3.0 (last updated on 10th March, 2008)
JSP Integration Kit version 3.0 (last updated on 10th March, 2008)
PHP Integration Kit version 3.0 (last updated on 10th March, 2008)
IMPORTANT: Must Read for those UPGRADING from any older Kit
If you have downloaded any of the Payment Gateway Kits prior to 25th August, 2006, then it is recommended that you upgrade to the latest version with MD5 Checksum Algorithm, by following the two step process listed below:-
Step 1: Upgrade your Payment Gateway Integration Kit
1. ASP Integration Kit: If you have already integrated this Kit with your website, then you need to simply download the ASP Integration Kit ver 2.0 and extract the functions.asp file. Then replace the old file that you have uploaded on your server with this new functions.asp file.
2. JSP Integration Kit: If you have already integrated this Kit with your website, then you need to download the JSP Integration Kit ver 2.0 and extract the functions.jsp file. Then upload this new functions.jsp file on your server and make the following modifications to your paymentpage.jsp and postpayment.jsp:
A. Modifications to paymentpage.jsp
i. Replace the below code from your paymentpage.jsp -
<%@ page import =”java.util.zip.Adler32,
java.math.BigDecimal” %>
<%!
private boolean verifyChecksum(int paymentTypeId, String transId, int userId,
String userType, String transactionType,
String invoiceIds, String debitNoteIds,
String description, double sellingAmount,
double accountingAmount, String key, String checksum)
{
String str = paymentTypeId + “|” + transId + “|” + userId + “|” + userType+ “|” +
transactionType + “|” + invoiceIds + “|” + debitNoteIds +“|” +
description + “|” + sellingAmount + “|” + accountingAmount + “|” + key;
Adler32 adl = new Adler32();
System.out.println(“CheckSumStr: “ + str);
adl.update(str.getBytes());
long adler = adl.getValue();
return (“” + adler).equals(checksum);
}
%>
Replace the above code in your paymentpage.jsp with -
<%@ include file=“functions.jsp” %>
ii. Enclose all occurances of verifyChecksum function call within a try-catch block.
B. Modifications to postpayment.jsp
i. Replace the below code from your postpayment.jsp -
<%@ page import =“java.util.zip.*,java.io.*,java.util.*,java.math.*” %>
<%!
private String generateCheckSum(String transId, double sellingAmount, double accountingAmount, String status,
String rkey, String key)
{
String str = transId + “|” + sellingAmount + “|” + accountingAmount + “|” +
status + “|” + rkey + “|” + key;
Adler32 adl = new Adler32();
System.out.println(“CheckSumStr: “ + str);
adl.update(str.getBytes());
return String.valueOf(adl.getValue());
}
%>
Replace the above code in your postpayment.jsp with -
<%@ include file=“functions.jsp” %>
ii. Enclose all occurances of generateChecksum function call within a try-catch block.
3. PHP Integration Kit: If you have already integrated this Kit with your website, then you need to simply download the PHP Integration Kit ver 2.0 and extract the functions.php file. Then replace the old file that you have uploaded on your server with this new functions.php file.
Step 2: Select the correct Checksum Algorithm within your Reseller Control Panel
i. Login into your Reseller Control Panel from http://manage.gossimer.biz/reseller
ii. Go to Settings -> Finance and Billing -> Payment Gateway -> List / Add
iii. Click on the Custom Payment Gateway that you are upgrading.
iv. Select the Checksum Algorithm as MD5 and save your changes by clicking on Submit.
|
[ii] Adding your Payment Gateway |
Next you need to Add your Payment Gateway to our system
You can Add or Modify your current/preferred Payment Gateway within your Reseller account by following the steps given below:
1. Login into your Reseller Control Panel from http://manage.gossimer.biz/reseller
2. Go to Settings -> Finance and Billing -> Payment Gateway -> List / Add
3. Click on the Add Payment Gateway button and then on the Add any other Payment Gateway link.
4. Enter the following Details and save your changes by clicking on Submit.
Gateway Name – This is the heading for your Payment Gateway and it will be displayed to your Customers/Sub-Resellers on the Payment page within a dropdown of options. A typical heading could be VISA/MasterCard/AMEX in order to signify that your Customer/Sub-Reseller can pay using those modes if they select this particular option.
Gateway URL – This is the URL on your server to which we will redirect the Customer/Sub-Reseller. This is explained in detail further ahead. Currently simply fill in some URL. We will change this later to the correct URL.
Payment Gateway Access Level for Customers and Sub-Resellers – Click here to know more about Payment Gateway Transaction types and Access Levels for your Customers and Sub-Resellers >>
Send me a Reminder if a transaction is pending for more than x days – In case you have not yet accepted a payment sent to you via this Payment Gateway, you can get e-mail reminders sent across to you from our system, after every x number of days, until you either Approve or Decline these payments. Click here to know how to Approve / Decline Payment Gateway transactions >>
Display Position – If you plan on adding Multiple Gateways you can select the position in which you wish to display this Gateway on your Payment Page.
Checksum Algorithm – Select MD5 if you have downloaded the latest Integration Kit (version 2 or above) or have followed the upgrade instructions listed in step [i]. Select Addler 32 only if you are still using an older kit and haven’t yet upgraded.
|
[iii] Preparation on your Server |
On your own Server upload the corresponding files from the integration kit you downloaded. We will use the PHP Kit as an example in this document. You will typically have the following files
paymentpage.php – This is the page that we will redirect your Customer/Sub-Reseller to. From this page you need to collect the data we send and use the data to charge your Customer/Sub-Reseller. After you have charged the Customer/Sub-Reseller you will then redirect the Customer/Sub-Reseller to postpayment.php
postpayment.php – This page simply redirects your Customer back to our Server after you have charged him, with appropriate variables required by our Server
functions.php – This is just a functions file used by the other pages for certain calculations
Both the paymentpage.php and the postpayment.php pages contain a variable called KEY. For instance in the above two files you will find a line as follows
$key = “eF9dmG8288OFd9pzzTeHJ3mNvR26xN”; //replace ur 32 bit secure key , Get your secure key from your Reseller Control panel
You need to replace this value in both the files with the KEY we generated for you at the time of adding the Gateway. You can check it from the Settings -> Finance and Billing -> Payment Gateway -> List / Add section by clicking on the Payment Gateway that you added
If at anytime you feel that you may have compromised the security of this Key, you can regenerate a new one from this section by clicking on the Generate Key button. You will then have to replace the New Key in your code.
|
[iv] Set the Gateway URL |
You will now need to set the Gateway URL which we skipped earlier while adding the Gateway. The Gateway URL is the full http:// URL that will be used to access the paymentpage.php on your server. So a typical Gateway URL would look like “http://www.yourserver.com/paymentpage.php”
Visit the Settings -> Finance and Billing -> Payment Gateway -> List / Add section and click on the Payment Gateway you added. Click on Modify and enter the Gateway URL as described above. Make sure the URL is entered complete with the “http://” or “https://” all the way up to the name of the page. DO NOT pass any Parameters to the URL
CORRECT GATEWAY URL
http://www.yourserver.com/paymentpage.php
WRONG GATEWAY URLS
www.yourserver.com/paymentpage.php
http://www.yourserver.com/paymentpage.php?someparam=something
|
[v] Testing the Integration so far |
You are now ready to test your integration and verify that it works. Follow the steps below to Test your Integration
1. Click on Settings -> Finance and Billing -> Payment Gateway -> List / Add
2. Click on the Payment Gateway you added
3. Click on Test for Add Funds or Test for Payment, depending upon the type of transaction you wish to test.
This will popup a new window redirect you to the Gateway URL you had specified passing it the following parameters in a POST request
|
Parameter KEY |
Type |
Description |
|
paymenttypeid |
integer |
This is the Id assigned to your Payment Gateway. You can see it in the Payment Gateway Detailed View |
|
transid |
string |
This refers to a unique transaction ID which we generate for each transaction |
|
userid |
integer |
This is the ID of the Customer/Sub-Reseller who is doing this transaction |
|
usertype |
string |
This refers to the type of user performing this transaction. The possible values are Customer or Reseller |
|
transactiontype |
string |
This refers to the type of transaction taking place. This could either be ResellerAddFund, CustomerAddFund, ResellerPayment, CustomerPayment (Reference: Payment Gateway Transaction types and Access Levels for your Customers and Sub-Resellers >>) |
|
invoiceids |
string |
This refers to the Comma-Separated list of Invoice IDs which your Customer/Sub-Reseller is paying for. This will have a value only if the transactiontype is ResellerPayment or CustomerPayment |
|
debitnoteids |
string |
This refers to the Comma-Separated list of Debit Note IDs which your Customer/Sub-Reseller is paying for. This will have a value only if the transactiontype is ResellerPayment or CustomerPayment |
|
description |
string |
This refers to the delimiter-separated Text Description of the Invoices and Debit Notes which your Customer/Sub-Reseller is paying for. This will have a value only if the transactiontype is ResellerPayment or CustomerPayment |
|
sellingcurrencyamount |
numeric (up to 3 decimal points) |
This refers to the amount of transaction in your Selling Currency |
|
accountingcurrencyamount |
numeric (up to 3 decimal points) |
This refers to the amount of transaction in your Accounting Currency |
|
redirecturl |
string |
This is the URL on our server, to which you need to send the user once you have finished charging him |
|
checksum |
string |
This refers to a Random Alpha-Numeric String generated using a Mathematical Algorithm (a complex quadratic equation) to ensure that data is not tampered along the way. A checksum is calculated on all the data sent to you using your 32 bit Alpha-numeric Key. The same checksum maybe verified at your end to ensure that the data received is valid |
Besides, we also pass the following details which allow you to pre-fill the Customer’s / Sub-Reseller’s details on the Payment Gateway page –
|
Parameter KEY |
Type |
Description |
|
name |
string |
This will pass the Customers / Sub-Resellers Name |
|
company |
string |
This will pass the Customers / Sub-Resellers Company Name |
|
emailAddr |
string |
This will pass the Customers / Sub-Resellers Email Address |
|
address1 |
string |
This will be the first line of the Address |
|
address2 |
string |
This will be the second line of the Address |
|
address3 |
string |
This will be the third line of the Address |
|
city |
string |
The Customer’s / Sub-Reseller’s city |
|
state |
string |
The Customer’s / Sub-Reseller’s state |
|
country |
string |
The Customer’s / Sub-Reseller’s Country |
|
zip |
string |
The Customer’s / Sub-Reseller’s zip |
|
telNoCc |
string |
The Country code of the telephone number of the Customer / Sub-Reseller. |
|
telNo |
string |
The telephone number of the Customer / Sub-Reseller |
|
faxNoCc |
string |
The Country code of the fax number of the Customer / Sub-Reseller. |
|
faxNo |
string |
The fax number of the Customer / Sub-Reseller |
These variables can directly be accessed in the paymentpage.php. If all goes well, then on clicking the Test PG Integration button you should see the following output on your browser in a separate window
File: paymentpage.php
Checksum Verification …….. Verified
List of Variables Received as follows
paymenttypeid: 202
transid: 1120
userid: 1
usertype: Customer
transactiontype: CustomerAddFund
invoiceids:
debitnoteids:
description:
sellingcurrencyamount: 5
accountingcurrencyamount: 10
redirecturl: http://manage.gossimer.biz/servlet/TestCustomPaymentAuthCompletedServlet
address1 = 213 Main St.
company = My Solutions
address2 = null
zip = 17541
name = Customer Name
city = NYC
telNoCc = 1
country = US
telNo = 45784126
emailAddr = customer@domain.com
address3 = null
state = NY
faxNoCc = null
faxNo = null
checksum: 8cd2a658d2de2c995fc790b66a508ec3
We will stop here right now. If you get the above output in your browser window then you have perfectly followed the steps so far.
If you get any of the following results instead then you can appropriately refer back to see if you have correctly set the following data:
|
Result |
Possible Solution |
|
ERROR: Checksum Mismatch |
This can only happen if the key you used is incorrect. Open the paymentpage.php file and verify that the value of the Key is exactly the same as the Key displayed in your Payment Gateway detailed view. Make sure there are no extra spaces or any missing characters. |
|
Page Not Found/Displayed |
If no page is found or displayed then the URL could be incorrect. Verify that the URL in the browser window is the correct path to your Payment Page on your Server. Verify that the URL has been correctly set with in the Gateway URL field of your Payment Gateway. Also verify that your web server is working perfectly |
|
Other Possible Issues |
Verify that variables passed to your script through the POST method are working appropriately and your web server supports the same. |
If you do not get this output then you should revert back and check if you have properly inserted your key in the paymentpage.php file, and that the Gateway URL is properly set. Make sure you proceed ahead only after you get the above output for your specific integration kit.
Let us try and understand what we have achieved so far. Basically a set of parameters are passed from our Server to your Server, along with a checksum. If you open your corresponding paymentpage.php page you will see the following code in it
if(verifyChecksum($paymenttypeid, $transid, $userid, $usertype, $transactiontype, $sellingcurrencyamount, $accountingcurrencyamount, $key, $checksum))
{
// YOUR CODE GOES HERE
}
else
{
echo “ERROR: Checksum Mismatch”;
}
Similar code will exist in the ASP and JSP integration kits. Your goal is to simply put your code inside the braces of the Verify Checksum. Within these braces you will put in code to register these variables in a session, or put them in your local database and then proceed ahead with charging your Customer
The VerifyChecksum function simply validates that the data you have received is valid and is sent by OUR SERVER. If the VerifyChecksum function fails then you MUST NOT proceed with the transaction.
IMPORTANT
It is imperative that you test your integration so far, by clicking on both the Test for Add Funds and Test for Payment buttons, before continuing to integrate your website with your Payment Gateway provider.
|
[vi] Charging the Customer/Sub-Reseller on your Payment Gateway |
You have now successfully achieved the integration steps up to sending the Customer/Sub-Reseller to YOUR Server. You now need to charge this Customer/Sub-Reseller. At this stage you have the list of variables that were passed to you in the paymentpage.php. It is recommended that you either store these variables in some local database of yours or store them in a session, before proceeding ahead, so that you can access these variable values at the time of sending the Customer/Sub-Reseller back after charging him. Storing these is explained in the previous section. After doing so you then must charge this Customer/Sub-Reseller. In doing so the following values are important for you
|
sellingcurrencyamount |
numeric (up to 3 decimal points) |
This refers to the amount of transaction in your Selling Currency |
|
accountingcurrencyamount |
numeric (up to 3 decimal points) |
This refers to the amount of transaction in your Accounting Currency |
The above amounts are the amounts you need to charge your Customer/Sub-Reseller. If your Payment Gateway Currency is the same as any of the above you may freely use one of the above values. If on the other hand the Currency your Gateway uses is different you will need to put in code to convert the amount we send to the amount you wish to charge.
Once you have finished charging your Customer/Sub-Reseller you will need to then send the Customer/Sub-Reseller back to our Server along with the status of the transaction, in order to allow us to Add those Funds to his account and process any associated Orders.
|
[vii] Sending the Customer/Sub-Reseller back to our Server |
You have now finished the steps required to charge your Customer/Sub-Reseller. You will then send the Customer/Sub-Reseller back to our Server. You will use the redirecturl parameter that was sent to your Gateway URL for this transaction to pass the Customer/Sub-Reseller back to our server.
You will pass the following parameters to the redirecturl in a POST request
|
Parameter KEY |
Type |
Description |
|
transid |
integer |
Pass the same transid which was passed to your Gateway URL at the beginning of the transaction. |
|
status |
character |
This can be either Y or N or P. A Y signifies that the Transaction went through SUCCESSFULLY and that the amount has been collected. An N on the other hand, signifies that the Transaction FAILED. When you send us the status as P, it would indicate that this transaction is to be kept Pending until you manually review this Payment Gateway transaction from your Reseller Control Panel. |
|
rkey |
numeric |
This refers to a random numeric key that you must generate and pass when redirecting the User from your side to our Server. We have included sample code which generates this on your behalf in the postpayment.php file included in the integration kit. |
|
checksum |
string |
This refers to a Random Alpha-Numeric String generated using a Mathematical Algorithm (a complex quadratic equation) to ensure that data is not tampered along the way. A checksum is calculated on all the data that you send to us, using your 32 bit Alpha-numeric Key. The same checksum is then verified by us to ensure that the data received is valid. |
|
sellingcurrencyamount |
numeric (upto 3 decimal points) |
This value must be greater than 0 and less than or equal to the original sellingcurrencyamount we sent to your paymentpage.php. This value MUST be passed, but is only used incase the transactiontype is CustomerAddFund or ResellerAddFund. This is explained in detail below. |
|
accountingcurrencyamount |
numeric (upto 3 decimal points) |
This value must be greater than ’0′ and less than or equal to the original accountingcurrencyamount we sent to your paymentpage.php. This value MUST be passed, but is only used incase the transactiontype is CustomerAddFund or ResellerAddFund. This is explained in detail below. |
The sample code for achieving the above process successfully is shown in the postpayment.php file. You simply need to copy this code in the file in which you do your Payment Processing. This page retrieves the transid and redirecturl from the session and expects a status to be available to it in the session. A simple inspection of the code in postpayment.php will give you an idea of the right way to redirect your Customer/Sub-Reseller to our server.
Explanation of sellingcurrencyamount and accountingcurrencyamount fields
In the above table two important fields are the sellingcurrencyamount and accountingcurrencyamount. These fields MUST be passed, but are used only if the transactiontype is ‘CustomerAddFund’ or ‘ResellerAddFund’ (Reference: Payment Gateway Transaction types and Access Levels for your Customers and Sub-Resellers >>). For every transaction performed through the Payment Gateway a Receipt is created in the Customer/Sub-Reseller account.
The amount of the Receipt created incase of transactiontype CustomerAddFund or ResellerAddFund is dependant on this figure. The Receipt amount will be equivalent to the figure you send us for both these values. The reason for allowing you to send us these values is to allow you to deduct any Credit Card Processing charges for Advance Payments made by your Customers/Sub-Resellers in their account.
Lets take an example of a Add Funds transaction performed by your Sub-Reseller
Sub-Reseller A
Your Selling Currency: USD
Your Accounting Currency: INR
Conversion Rate: 50
Amount to add in USD: 100
Amount to add in INR: 5000
When this Sub-Reseller leaves our system and comes to your paymentpage.php, we will send along the two amounts i.e. USD 100, INR 5000, to allow you to charge his card with an equivalent amount. After the transaction is completed, you will send the Sub-Reseller back to our system with a sellingcurrencyamount and accountingcurrencyamount figure. We will then credit THAT amount to his account. You may choose to send the same figures we sent to you, thus crediting the Sub-Reseller with the exact amount that was charged to him/her. Alternatively you may choose to deduct a certain processing amount for Credit Card Transactions and send a reduced amount. Thus you could have the below two scenarios
Scenario 1 – Values sent by your postpayment.php page
sellingcurrencyamount: USD 100
accountingcurrencyamount: INR 5000
In this scenario we sent you USD 100 and INR 5000, and you sent the same figures back. We will therefore credit the Sub-Reseller with the same amount
Scenario 2 – Values sent by your postpayment.php page
sellingcurrencyamount: USD 95
accountingcurrencyamount: INR 4750
In this scenario we sent you USD 100 and INR 5000, and you sent back USD 95 and INR 4750 (deducting 5% processing charges). We will therefore credit the Sub-Reseller with USD 95, INR 4750
Completing the Integration process using the postpayment.php page
We have a special built-in test mechanism for testing the interaction between the postpayment.php on your Server and our Server. The steps below assume you have finished all previous instructions until this step. Follow the steps below to test your integration further
1. Click on Settings -> Finance and Billing -> Payment Gateway -> List / Add
2. Click on the Payment Gateway you added
3. Click on Test For Add Fund or Test For Payment
This should result in a page as follows
File: paymentpage.php
Checksum Verification …….. Verified
List of Variables Received as follows
paymenttypeid: 202
transid: 1120
userid: 1
usertype: Customer
transactiontype: CustomerAddFund
invoiceids:
debitnoteids:
description:
sellingcurrencyamount: 5
accountingcurrencyamount: 10
redirecturl: http://manage.gossimer.biz/servlet/TestCustomPaymentAuthCompletedServlet
address1 = 213 Main St.
company = My Solutions
address2 = null
zip = 17541
name = Customer Name
city = NYC
telNoCc = 1
country = US
telNo = 45784126
emailAddr = customer@domain.com
address3 = null
state = NY
faxNoCc = null
faxNo = null
checksum: 8cd2a658d2de2c995fc790b66a508ec3
Clicking on any of the above button submits to the same page where the value of status is set in the session and then you are redirected to postpayment.php, and you should see the below display
File: postpayment.php
redirecturl: http://manage.gossimer.biz/servlet/TestCustomPaymentAuthCompletedServlet
List of Variables to send back
transid: 1120
status: Y
rkey: 32423
checksum: 8cd2a658d2de2c995fc790b66a508ec3
Clicking on this button will redirect you to our Server and you should see the following display on our Server
Checksum Verification …….. Verified
List of Variables Received as follows
transid: 1120
status: Y
rkey: 32423
checksum: 8cd2a658d2de2c995fc790b66a508ec3
If you see the above display this means that your integration is complete. You simply now need to modify the files and put in your own code to charge your Customer/Sub-Reseller.
If you get any of the following results instead then you can appropriately refer back to see if you have correctly set the following data:
|
Result |
Possible Solution |
|
ERROR: Checksum Mismatch |
This can only happen if the key you used is incorrect. Open the postpayment.php file and verify that the value of the Key is exactly the same as the Key displayed in your Payment Gateway detailed view. Make sure there are no extra spaces or any missing characters. |
|
Other Possible Issues |
Verify that variables passed to your script through the POST method are working appropriately and your web server supports the same. |
If you do not get this output then you should revert back and check if you have properly inserted your key in the postpayment.php file. Make sure you proceed ahead only after you get the above output for your specific integration kit.
|
[viii] Finishing Steps |
We have completed the process of Sending a Customer/Sub-Reseller to your Server and then receiving the Customer/Sub-Reseller back. You now need to modify up the files on your server to process the transaction. The process that you will follow is -
1. Modify the paymentpage.php file and insert your code to charge the Customer/Sub-Reseller in the block shown below
if(verifyChecksum($paymenttypeid, $transid, $userid, $usertype, $transactiontype, $sellingcurrencyamount, $accountingcurrencyamount, $key, $checksum))
{
// YOUR CODE GOES HERE
}
The Code that you insert here may involve any or all of the following steps
Saving the variables to a local database/session
Converting the amount to the currency used by your Payment Gateway
Redirecting the Customer/Sub-Reseller to another page which will obtain input from the Customer (e.g. his Credit Card details) and charge them
2. Once you have made the above changes then after the transaction you need to redirect the Customer back to our server. This task is handled by postpayment.php. Before postpayment.php can redirect the Customer/Sub-Reseller it needs to have transid, redirecturl, and status available in the session. While transid and redirecturl will be available in the session if they have been put in by paymentpage.php, status will have to be separately put into the session. DO NOT PASS a status to the postpayment.php page. This can allow the Customer/Sub-Reseller to modify the status. You must put the status value in session and retrieve the same from the session, or directly copy the code of postpayment.php inside your payment processing page.
3. Clean up the Code in the files. We have put in test related code which you may wish to remove. You can clean up the code at this stage removing all the procedures you do not need.
|
[ix] Final Testing |
Attempt a live transaction from one of your Customer/Sub-Reseller accounts to verify everything is working fine. Make sure you try all types of Transactions – Add Funds, Payment of an Invoice, Payment of multiple Invoices/Debit Notes etc.
The SuperSite contains information about the various Payment options you offer to your Customers and also presents these options at the time of purchasing Products and Services. This data is downloaded to your SuperSite from your Control Panel and cached (stored) on the SuperSite Server. Hence, you would need to refresh the cache of your SuperSite once you have completed the above process. You can accomplish this from within your Control Panel itself by clicking on Tools -> Reload SuperSite and PartnerSite Cache -> SuperSite Payment Preferences. Click here to know what is SuperSite >>
|
[x] Managing your Transactions |
Every live transaction attempted through your Payment Gateway is recorded by the system. You can list all Transactions and search through them using the List Transactions and Search Transactions buttons in your Payment Gateway toolbar. The following fields are important with respect to each Transaction
|
Field |
Type |
Description |
|
transid |
string |
This is a unique transaction ID generated by us and sent to your Server for every Transaction attempted |
|
status |
character |
This can be either Processing, Successful or Failed. The status Processing denotes any transaction for which your Customer/Sub-Reseller has left our Server and not yet come back from your Server |
There may be occasions when your Customer/Sub-Reseller will be redirected to your Gateway but never comes back to our Server because of loss of connectivity or other issues. In this circumstance our System will not know whether the Transaction was Successful or Failed. You will have to tell that to the System yourselves. This can be easily achieved by Searching Transactions from the Payment Gateway toolbar and clicking on AuthStarted transactions. This will allow you to list all transactions which are yet processing. From here you can state whether they were Successful or Failed. Incase of a successful transaction the System will add those funds to your Customer/Sub-Reseller and process any related Orders. Incase of failed transactions the System will simply mark the transaction as failed. Click here to here to find instructions on how to Search / Approve Decline Payment Gateway Transactions >>
Tags: ASP, Asp 3, Break, Bridge, correct Checksum Algorithm, Gateway Server, Generic Module, http, Inr, Integration Kit, Interaction, Java, Jsp, Kit Version, Logic, Money, Parameters, Payment Gateway, payment processing page, Php, Redirect, Reseller Account, Resellers, Server Space, Step 2, Step 3, System Details, the POST, Transactions - Add Funds, United States, USD, Web Server, www.yourserver.com/paymentpage.php
The extension of your files indicates the type of file it is and is required by the web server to send the appropriate MIME type to the web browser. Hence it is important that you name your file with the appropriate extension.
Also, your file names have a bearing on the selection of the home (default) page, i.e. the first page that is shown to visitors on your site.
Tags: Bearing, File Names, Home Default, Mime Type, Web Browser, Web Server
This is a feature exclusive to Gossimer, and is available ONLY with our Linux Hosting Packages. Using this feature, you can have your own branded extensions for web pages on your site, and assign them to any file types. For instance, you can choose to name your Excel files with the extension .data, or your image files .picture and so on!
Assigning branded file extensions
1. Login to your Control Panel and search for the domain name for which you have purchased this hosting package. Click here to read how >>
2. In the search results view, click on the domain name. This will take you to the order details view.
3. Click on Manage Web Hosting Service in the lower toolbar.
4. In the Website Management interface pop-up that follows, go to Manage Website -> Web Server Manager -> Branded File Extensions -> Add Branded Extension.
5. Here, in the File Extension field, specify your custom file extension e.g. .brand, .mine or any other extension you wish to have for a particular Content Type.
6. Choose the appropriate content type for which you wish to apply that extension. You can either choose one from the existing types or add your own content type.
7. Once you have specified these details, click on Add Branded Extension.
Modifying branded file extensions
1. Perform steps 1-3 mentioned in the above process.
2. In the Website Management interface pop-up that follows, go to Manage Website -> Web Server Manager -> Branded File Extensions -> List Branded Extensions.
3. Click on the File Extension link to go to the Branded Extension Details page for that specific extension.
4. Modify the File Extension and/or Content Type for this extension, and click on Modify Branded Extension.
Disabling branded file extensions
1. Perform steps 1-2 mentioned in the above (modifying branded file extensions) process.
2. Select the checkbox adjacent to one or more file extensions which you wish to disable.
3. Click on Delete button and confirm the action by clicking on OK.
In order to complete the action, the Web Server needs to be restarted. Random restarts affect other services running on the Server. In order to avoid this, the Server has been scheduled to restart at intervals of 20 minutes. Hence, each one of the above mentioned actions might take upto 20 minutes to be effective.
Tags: Checkbox, Choose One, Content Type, Control Panel, Details View, Domain Name, File Extension, File Extensions, Gt 2, Gt Web, Image Files, Linux, Linux Hosting, Manage Web Hosting Service, Management Interface, Manager Gt, Mime Types, View 3, Web Hosting Service, Web Pages, Web Server, Web Server Manager, Website Management
Follow the instructions below to begin integration with the API using PHP -
Make sure you have read the General API Integration Instructions first. If you have already integrated the PHP API Kit at your end, read the Change Log first to know what has changed since.
Reference:
General API Integration Instructions >>
Change Log >>
The PHP API Kit is not compatible with version PHP5. You need to use version PHP4 in order to integrate the API Kit at your end.
Step 1. Download the API Kit
Click the link below to download the relevant API kits (updated on 6th March, 2008).
PHP_CoreKIT_v3_10.zip
PHP_DomainsKIT_v3_10.zip
PHP_HostingKIT_v3_10.zip
PHP_OtherProductsKIT_v3_10.zip
Step 2. Download the API Documentation
The complete documentation of all classes and methods available in the API can be found in the Docs below. The Docs below are javadocs, but the function names and explanations remain the same for all the platforms and the documentation is self explanatory. We recommend you download the docs and read through them completely once before you integrate your application (updated on 6th March, 2008).
Core_Docs_v3_10.zip
Domains_Docs_v3_10.zip (updated on 1st April, 2008)
Hosting_Docs_v3_10.zip
OtherProducts_Docs_v3_10.zip
Since “list” is a keyword in the PHP language, the “list()” methods in the various classes (in the PHP Kit) has been renamed to “listOrder().” However, the documentation still mentions the method name as “list” since the documentation is JAVA specific.
Instructions to pass parameters to functions using the PHP Kit
Since PHP uses typeless variables you will have to ignore the datatypes presented in the docs. But for assigning values to variable of types other than strings and integers special care will have to be taken. Below is the list of datatypes presented in the API Doc and their usage in PHP.
|
Java Data |
Types Assigning values in PHP |
| String | “firstname@secondname.com” |
| int | 123 |
| HashMap (Datatype for storing name-value pair) | array(“domain.com”=>”1″) |
| Array and Vector (Datatype for storing more than one value) | array(“ns1.domain.com”,”ns2.domain.com”) |
| boolean (Datatype for storing true or false) | true / false |
Example:
For Calling a Function which takes a String datatype and an integer datatype as its paramters
public int function1(java.lang.String userName, int parentid)
$result = $obj->function1(“firstname@secondname.com”,1);
For Calling a Function which takes a HashMap, a String Array and an integer Array as its parameters
public java.util.HashMap function2(java.util.HashMap domainHash, java.lang.String[] orderby, int[] resellerId)
and domainHash is accepting the domainname and the number of years as name value pair
$result = $obj->function2(array(“domain1.com”=>1,”domain2.com”=>2),array(“column1″,”column2″),array(22,33))
For Calling a Function which takes a Vector and a boolean as its parameters
public java.lang.String function3(java.util.Vector nameServers, boolean add)
$result = $obj->function3(array(“ns1.domain.com”,”ns2.domain.com”),true)
Step 3. Extract the files from the API Kit archive
You should get the following directory & files structure
examples/ – Pre-written examples. You can directly run these examples to test API functionality
lib/ – The PHP class files, library files and wsdl files that you need to run your application
Step 4. Run the examples
You can run the pre-written examples provided in the “examples” folder. Note the following steps to do so -
1. Upload the “examples” and “lib” folders to your web server where you run your PHP scripts. Make sure that both these folders are uploaded to the same parent folder.
2. You must have PHP 4 installed on the server
3. You must have a Demo account ready the first time. Read the General instructions if you have not yet setup your demo account. Reference: General API Integration Instructions >>
The Demo server duplicates all functionality of the live server, however all Domain Names will appear as available on the Demo Server. It does not query the live registry and therefore names which are not available on the live registry will still appear as available on the Demo Server. At times connectivity to the DEMO Registry may be down resulting in errors.
4. Make the appropriate changes to “constants.php” in the “examples” folder, by putting in the values for your “SERVICE_USERNAME”, “SERVICE_PASSWORD”, “SERVICE_PARENTID”. The remaining settings have already been made for you in this file. You may only need to change the path for the “lib” folder if you have uploaded the lib folder elsewhere
5. The URL to which the call is made is maintained in the “config.php” file inside the “lib” folder. By default all calls are made to the demo server URL using HTTP. You can make changes to this file and redirect your calls to the appropriate server
If you are using HTTPS calls you MUST have the extension for CURL installed and enabled in your PHP installation.
6. Another important parameter maintained in the “config.php” file is the variable $DEBUG. If this variable is set to “true”, then for each call you will see the entire XML Request and Response in the output. You should keep it to “true” during testing, but set it to false on the live environment.
7. Every Example file has a set of functions which you can run.
8. Once you have modified the appropriate example file, access it over your webserver by putting in your URL such as http://yourserver/examples/html and choose the required function from the links given in the left frame.
In registering/managing any domain name on the demo server always use ns1.onlyfordemo.net and ns2.onlyfordemo.net as your nameservers. ANY OTHER Nameserver will result in an INVALID NAMESERVER error.
Step 5. Understanding Errors
Make sure you have read the General API Integration Instructions to obtain links to the error format and possible error documents. Reference: General API Integration Instructions >>
Step 6. Writing your own code
After running each example above, if you simply refer to the corresponding .php file in the examples folder you will easily be able to figure out the code snippet you need to write in order to make a similar call.
Making an API call to perform any action is a matter of three steps:
(i) Include the appropriate PHP Class file as below
include($LIB_DIR.”Order.class.php”);
(ii) Obtain a pointer to the required Class. This is done by using the code below
$serviceObj = new Order($LIB_DIR . “wsdl/Order.wsdl”);
(iii) Call the required method on this object. A complete reference of all methods is available in the Docs folder. This can be achieved by using the code below
$AssociativeArray = $serviceObj->setCustomerLock($SERVICE_USERNAME, $SERVICE_PASSWORD, $SERVICE_ROLE, $SERVICE_LANGPREF, $SERVICE_PARENTID, $orderId);
You will notice above that EVERY method in the docs takes the same first 5 parameters as below
String SERVICE_USERNAME, String SERVICE_PASSWORD, String SERVICE_ROLE, String SERVICE_LANGPREF, int SERVICE_PARENTID
In the examples these parameters have been put into a single constants file from which they are accessed by including the constants file. These parameters are common no matter which method you call. These parameters mean the following:
String SERVICE_USERNAME: Your UsernameSERVICE_PASSWORD
String : Your PasswordSERVICE_ROLE
String : This will always be a string "reseller"SERVICE_LANGPREF
String : The 2 letter code of the language in which you wish to receive errors and descriptions - "en" for EnglishSERVICE_PARENTID
int : The ID of your parent which you can get from your profile section
Remember, when passing numerical data in hashtables, please ensure that the number is passed as a String.
Step 7. Change the information to Live information when you are ready
Once you have followed the steps above and got the test examples to work successfully, you can duplicate the same code in your live application and replace the Demo Server and Reseller account information with your live username and password. The URL that you make your calls to also needs to change to the LIVE Server URL. You will make this change in the “config.php” file in the “lib” folder
Once again note, if you are using the HTTPS URL you MUST have the extension for CURL installed and enabled in your PHP installation.
Tags: Api, Api Documentation, Api Guide, Api Kit, appropriate server, Datatype, Datatypes, Demo Server, Docs, Explanations, http, Integers, Integration Guide, Java, Java Data Types, Javadocs, Parameters, Php, Php Guide, PHP installation, Php Java, Php Kit, Php Language, Php4, Platforms, Reference, Step 1, Step 2, Variables, Web Server, Xml
Depending upon the Web Server software type you selected at the time of Enrolling for a Digital Certificate, thawte determines if your Digital Certificate is re-signable or non-re-signable on their system. This means that certain platforms will require a new CSR upon Renewal while others enable the existing CSR to be re-signed, in which case the new certificate, once issued, will only work on the private key file that was used to create the CSR originally submitted to thawte. Click here to find a list of Web Server Software platforms which support a re-signable CSR on Renewal >>
thawte Digital Certificates have a lifespan of 1 or 2 years, depending upon the validity period you chose at the time of purchase. You can Renew your Digital Certificate within 90 days prior to its Expiry and within 30 days post Expiry. However, thawte will issue the Digital Certificate only 32 days before your current Certificate expires. This allows you to request your Renewal Certificate timorously and prevents any warnings for your website users which would have been displayed if your existing Certificate would have Expired.
Follow the below mentioned process to Renew your Digital Certificate:
During the Digital Certificate Enrollment process for a SSL123 Certificate, you need to choose either the Corporate Contact or the Technical Contact as the Authorizing Contact for your Digital Certificate.
During the Enrollment process for a SSL123 Certificate, if you had chosen the Corporate Contact as the Authorizing Contact and had matched a pre-determined email address (email alias) with the domain name for which you were requesting the Certificate, then you will be required to provide the Corporate Contact Email Address while Renewing the Certificate.
Once you have Renewed your Digital Certificate successfully, you would be issued your new certificate. You can check the status of your Digital Certificate by clicking the Check Certificate Status button in the Order Details view of the Digital Certificate Order. Once the certificate is issued, you can retrieve the same from the above interface itself and install this renewed certificate on your web server.
Reference:
Click here to find instructions on how to check the status of your Digital Certificate and retrieve your Renewed Digital Certificate >>
Click here to find instructions on how to install your Digital Certificate >>
Tags: Csr, Current, Digital Certificate, Domain Name, Expiry, Key File, Lifespan, Nbsp, Privacy Protection, Private Key, Renew Service, Renewal Certificate, Software Platforms, Software Type, Thawte Digital Certificates, Timorously, Validity Period, Web Server, Web Server Software, Website Users, Website Visitors
The Domain Name System [DNS] is a distributed database, arranged hierarchically, containing records for domain names. The DNS system’s main aim is to match a domain name to an IP Address. In order to fulfill this role, the DNS Server contains Records [called Resource Records] in a Zone File, which contains the domain name and IP address mappings for computers contained within that Zone. All Resource Records have a TTL [Time To Live], specifying the number of seconds other DNS servers and applications are allowed to cache the record.
Most Web Hosting companies do not provide you with an interface to manage your own DNS Records and/or the ability to select multiple providers for various Services like Web Hosting, Mail Hosting, etc..
Gossimer gives you complete control over the following Resource Records by using our Managed DNS Service:
I. Address Record [A Record]
The A Record is the most basic and the most important DNS record type. They are used to translate human friendly domain names such as “www.domain.com” into IP-addresses such as 1.2.3.4 (machine friendly numbers).
When you wish to host your domain name, you will be provided with an IP address that needs to be set as an A Record for that particular domain name.
II. Mail Exchanger [MX] Record
A MX Record identifies the mail server(s) responsible for a domain name. When sending an e-mail to user@xyz.com, your mail server must first look up the MX Record for xyz.com to see which mail server actually handles mail for xyz.com (this could be mail.xyz.com – or someone else’s mail server like mail.isp.com). Then it looks up the A Record for the mail server to connect to its IP-address.
A MX Record has a Preference number indicating the order in which the mail server should be used (only relevant when multiple MX Records are defined for the same domain name). Mail servers will attempt to deliver mail to the server with the lowest preference number first, and if unsuccessful continue with the next lowest and so on.
III. Canonical Name [Alias / CNAME] Record
CNAME Records are domain name aliases. Often computers on the Internet have multiple functions such as Web Server, FTP Server, Chat Server, etc. To mask this, CNAME Records can be used, to give a single computer multiple names (aliases).
Sometimes companies register their multiple domain names for their brand-names but still wish to maintain a single website. In such cases, a CNAME Record maybe used to forward traffic to their actual website. For example, www.abc.in could be CNAMEd to www.abc.com.
The most popular use of the CNAME Record type, is to provide access to a Web Server using both the standard www.domain.com and domain.com (without the www). This is usually done by adding a CNAME-record for the www name pointing to the short name [while creating an A Record for the short name (without www)].
CNAME Records can also be used when a computer or service needs to be renamed, to temporarily allow access through both the old and new name.
IV. Authoritative Name Server [NS] Record
NS Records identify DNS servers responsible (authoritative) for a Zone. A Zone should contain one NS Record for each of its own DNS servers (primary and secondaries). This mostly is used for Zone Transfer purposes (notify). These NS Records have the same name as the Zone in which they are located.
But the most important function of the NS Record is Delegation. Delegation means that part of a domain is delegated to other DNS servers.
You can also delegate sub-domains of your own domain name (such as subdomain.yourname.com) to other DNS servers. An NS Record identifies the name of a DNS server, not the IP Address. Because of this, it is important that an A Record for the referenced DNS server exists, otherwise there may not be any way to find that DNS server and communicate with it.
If a NS Record delegates a sub-domain (subdomain.yourname.com) to a DNS Server with a name in that sub-domain (ns1.subdomain.yourname.com), an A Record for that server (ns1.subdomain.yourname.com) must exist in the Parent Zone (yourname.com). This A Record is referred to as a Glue Record, because it doesn’t really belong in the Parent Zone, but is necessary to locate the DNS Server for the delegated sub-domain.
V. Text [TXT] Record
A Text Record provides the ability to associate some text with a domain or a subdomain. This text is meant to strictly provide information and has no functionality as such. A TXT Record can store upto 255 characters of free form text. This record is generally used to convey information about the zone. Multiple TXT records are permitted but their order is not necessarily retained.
For example, you may add a TXT Record for yourname.com with the value as “This is my mail server”. Here if anybody was checking ALL or TXT records of yourname.com, they would notice the above text appearing in the TXT record.
TXT Record is also used to implement the Sender Policy Framework (SPF) and DomainKeys specifications.
Sender Policy Framework (SPF)
Sender Policy Framework is an extension to the Simple Mail Transfer Protocol (SMTP). SPF allows software to identify and reject forged addresses in the SMTP MAIL FROM (Return-Path), a typical nuisance in e-mail spam.
SPF allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain. The technology requires two sides to work in tandem -
i. the domain owner publishes this information in an TXT Record in the domain’s DNS zone, and when someone else’s mail server receives a message claiming to come from that domain, then
ii. the receiving server can check whether the message complies with the domain’s stated policy. If, for example, the message comes from an unknown server, it can be considered a fake.
DomainKeys
DomainKeys is an e-mail authentication system (developed at Yahoo!) designed to verify the authenticity of the E-mail sender and the message integrity (i.e,. the message was not altered during transit). The DomainKeys specification has adopted aspects of Identified Internet Mail to create an enhanced protocol called DomainKeys Identified Mail (DKIM).
VI. Start of Authority [SOA] Parameters
Each Zone contains one SOA Record, which holds the following parameters for the Zone -
Name of Primary DNS Server - The domain name of the Primary DNS Server for the Zone. The Zone should contain a matching NS Record.
Mailbox of the Responsible Person – The email address of the person responsible for maintenance of the Zone.
Serial Number - Used by Secondary DNS Servers to check if the Zone has changed. If the Serial Number is higher than what the Secondary Server has, a Zone Transfer will be initiated. This number is automatically increased by our Servers when changes to the Zone or its Records are made.
Refresh Interval - How often Secondary DNS Servers should check if changes are made to the zone.
Retry Interval - How often Secondary DNS Server should retry checking, if changes are made – if the first refresh fails.
Expire Interval - How long the Zone will be valid after a refresh. Secondary Servers will discard the Zone if no refresh could be made within this interval.
Minimum (Default) TTL - Used as the default TTL for new records created within the zone. Also used by other DNS Server to cache negative responses (such as record does not exist, etc.).
Tags: Complete Control, delegate, DNS, DNS system, Dns Record Type, Dns Records, Dns Server, Dns Servers, Dns Service, Domain Name System, Domain Names, Domain Owner, E Mail, Internet Mail, Ip Address, Mail Exchanger, Mail Hosting, Mail Server, Mail Servers, Mappings, Mx Record, Mx Records, Resource Records, Sending Mail, Server Mail, SOA, unknown server, Web Hosting, Web Hosting Companies, Web Mail, Web Server, www.abc.com, www.abc.in, www.domain.com, Yahoo!
In order to use your Live Chat Service, you need to download and install the Agent module software. This software connects your support Operators to the Live Help client.
1. This software requires Microsoft .NET runtime to be installed on your machine. If you do not have it, download the same from http://download.microsoft.com/download/a/a/c/aac39226-8825-44ce-90e3-bf8203e74006/dotnetfx.exe.
2. Ports in the range 37643 to 37648 need to be enabled/opened for the following to work:
i. Live Chat Agent software – If this software is installed on a computer that is behind a Firewall or Proxy Server, then you need to request your System Administrator to enable/open these ports for you.
If you are connected to the Internet via a Cable/DSL ISP, then you need to contact your ISP and request them to enable these for you. Typically, Dial-up Internet users do not face port blocking issues and would not have to request their ISP for enabling these ports.
ii. Live Chat code for your website – If the web server where your website is hosted (which has the LivehelpGenie Live Chat code installed) behind a Firewall, then you need to request your Web Hosting Provider to enable/open these ports for you.
To download the software, follow the steps mentioned below:
1. Login to your Control Panel, search for the Domain Name for which you have purchased the Live Chat Service and proceed to the Order Details view page. Click here to know how >>
2. Here, click Manage Live Chat Service. This will take you to the Registered members area.
3. On this page, in the MISCELLANEOUS section at the bottom of the left-hand side margin, click Download software.
Once the software is downloaded, install it on your (or all the Agent’s) PC. You must provide your Agent login details to connect to and use the Service.
Tags: Agent Login, Agent Software, Area 3, Cable Dsl, Chat Code, Chat Service, Client Software, Dotnetfx, Dsl Isp, Firewall, Gt 2, Internet Users, Isp, Left Hand Side, Live Chat, Live Chat Service, Live Help, Members Area, Microsoft, module software, Proxy Server, Registered, Side Margin, Support Operators, System Administrator, Web Hosting, Web Hosting Provider, Web Server
Files/directories can be easily copied/moved from one directory to another within your website or to an altogether different server via the File Manager:
Copying Files/Directories
1. Select one or more files/directories you wish to copy and click Copy.
2. You may either choose to copy Files/directories to another directory within your website or to a different web server altogether -
a. Copying files/directories to another directory within your website: Here you have two options, you may either Copy all the files/directories to a single destination or individually select different destination folder for each file/directory -
- Copying individual files/directories to different destination directories
i. Click
next to Target directory to locate the destination directory
ii. Double-click the directory to which the files/directories need to be copied and click Choose.You may also choose to rename the file by providing a new name in the Target name field.
- Copying all files/directories to a single destination directory i. Click
next to Set all target directories to locate the destination directory
ii. Double-click the directory to which the files/directories need to be copied and click Choose.b. Copying files/directories to another server: Simply provide the destination server IP Address or website URL, FTP port if different from the default port 21, and the FTP Username and Password.
3. Click
to initiate the copying of the files/directories.
Moving Files/Directories
1. Select one or more files/directories you wish to move and click Move.
2. You may either choose to move Files/directories to another directory within your website or to a different web server altogether -
a. Moving files/directories to another directory within your website: Here you have two options, you may either Move all the files/directories to a single destination or individually select different destination folder for each file/directory -
- Moving individual files/directories to different destination directories
i. Click
next to Target directory to locate the destination directory
ii. Double-click the directory to which the files/directories need to be moved and click Choose.You may also choose to rename the file by providing a new name in the Target name field.
- Moving all files/directories to a single destination directory i. Click
next to Set all target directories to locate the destination directory
ii. Double-click the directory to which the files/directories need to be moved and click Choose.b. Moving files/directories to another server: Simply provide the destination server IP Address or website URL, FTP port if different from the default port 21, and the FTP Username and Password.
3. Click
to initiate the moving of the files/directories.
Tags: Default Port, Destination Directories, Destination Directory, Destination Folder, Destination Server, Double Click, File Manager, Ftp Port, Moving, Server Ip Address, Server Manager, Target Directories, Target Name, Web Server, Website Url