Managing multiple currencies is probably the most complicated portion of the Billing system provided to you, and at the same time, one of the most powerful and unparallelled features of our System. The System allows you to differentiate between the currency you want your Customers/Sub-Resellers to view, and your Accounting currency and seamlessly maintains conversion and Forex issues for these currencies without any manual processes from your side.
The basic theme stems from the fact that your sales and accounts may have to happen in different currencies. For instance if your Office is in India, while your sales are Global, you may wish to display all your Selling prices and Billing in an Internationally recognised currency such as US Dollar (USD) to your Customers/Sub-Resellers. Meanwhile however, you are legally required to maintain your books of accounts in Indian Rupees (INR). The System resolves this issue by showing USD values to your Customers/Sub-Resellers and maintaining dual currency values for you. At this stage it is important to clarify that if your market is restricted to India, then your Accounting and Selling currency will be the same. In this case you will not require to understand the implications of having multiple currencies.
As you now already know, the System has two Currencies that it maintains for you -
Selling currency: This is the currency in which all your selling prices will be specified and displayed. Your Customers and Sub-Resellers will only see this Currency with respect to their dealings with you.
Accounting currency: This represents the currency in which you maintain your books of accounts in your Country.
Initial Currency Selection
It is important to understand that you can select your Currency only ONCE at the time of initial signup. You cannot change your currency once you have signed up. In fact, the only way to modify your currency after sign up is to sign up once again, and then shift all your Orders from the previous account to the newer account. It is therefore important that you make the right choice of Currency during the Signup process.
Currency Conversion
When you choose a particular Selling currency, you will then specify all your selling prices to your Customers and Sub-Resellers in that Selling currency. All transactions will therefore be added with those amounts. In order to maintain along with the Selling currency amount, an Accounting Currency amount too, the amount needs to be converted from the Selling currency to the Accounting currency. This conversion is done by the system dynamically for every transaction that is automatically added, using a conversion rate specified by you, or the system conversion rate (which is updated daily from a reliable Forex resource). For every manually added transaction you have the ability to specify both the amounts. Lets understand this with examples
For every Invoice, Receipt, Debit Note and Credit Note that the System automatically generates, it converts the Selling currency Amount to the Accounting Currency Amount using a conversion rate. We will discuss how it obtains this Conversion rate later. For instance if the System raises an Invoice for an Order of USD 100 placed by your customer, and your accounting Currency is INR, and the conversion rate from USD to INR is 50, then the System will enter the Transaction with the USD value as USD 100 and the INR value as INR 5000
For every Invoice, Receipt, Debit Note and Credit Note that you enter manually for your Customer/Sub-Reseller, you have the ability to specify both the Selling currency amount and the Accounting currency Amount. Check FAQ: Subtract Funds from your Customers/Sub-Resellers Account and FAQ: Add Funds to your Customers/Sub-Resellers Account
Currency conversion Rate
At any point in time the System needs a Conversion rate between your Selling Currency and Accounting Currency. This rate can either be specified by you, or automatically maintained by the System itself. We download daily currency exchange rates between EVERY currency in the world. These rates are downloaded from a recognized Forex resource. If you choose to let the system maintain the Conversion rate it will automatically do so on your behalf and update this rate on a daily basis. If you choose to maintain the Conversion rate yourselves, you will need to update the Conversion rate yourself.
You can select your Conversion rate preference by clicking on Settings -> Finance and Billing -> General Settings. Ideally let the System maintain the Conversion rate on your behalf. Note that despite the fact that the System maintains an automated rate, you still have the flexibility of using a Custom rate for any transaction that you MANUALLY enter. E.g. if you set the Conversion rate to be automatically updated by the system, each time you Add an Invoice/Debit Note/Receipt/Credit Note MANUALLY, you will have the ability to specify your own Conversion rate for THAT transaction. The System will however use its own conversion rate for any transactions that are automatically added
Forex Difference
If you have a separate Accounting currency and Selling currency, it leads to Foreign exchange differences in the booking of an Invoice and Receipt. The System automatically calculates this difference on your behalf and records the same. Check FAQ: Balancing (Payment) of a Pending Invoice/Debit Note explained in Detail for more details on this
Tags: Accounting, Billing System, Change Currency, Conversion Currency, Conversion Rate, Currencies, Currency Conversion, Currency Issues, Currency Rate, Currency Values, Dollar, Dual Currency, Forex, India, India Currency, Indian Rupees, Initial Signup, Inr, Manual Processes, Resellers, Respect, Seamlessly, Time One, USD
As a Reseller, you would have to assist your Sub-Resellers, if they happen to forget their Username / Password for the Login. In such cases there are 4 methods available for you. You can select any of the following methods to help your Sub-Reseller Login –
I. Forgot Password:
This method would be useful whenever your Sub-Reseller has forgotten his Password.
1. In this method you would have to ask the Sub-Reseller to go to your Store Front Page at http://manage.gossimer.biz.
2. Ask the Sub-Reseller click on the Forgot Password link there and then enter his Username (his Email Address).
This would send a mail to his Email Account, with a Temporary Password, the Login URL and the Username. The Sub-Reseller can then Login with this Password and can then change his original Password.
Please note that this Password would be effective for 3 days only. Also, during this time both the Original Password and the Temporary Password would work for Logging in.
This is another method you can use when the Sub-Reseller has forgotten his Password. This would be useful if he does not even remember his Username. In this case you can follow the below mentioned steps -
1. In your Reseller Control Panel, go to Sub-Resellers -> Search and search for the Sub-Reseller based on one of the search fields available.
2. From the list, click on the Sub-Reseller you were looking for. In the Sub-Reseller Details view that follows, you would find the Sub-Reseller Username. Click on the Send Password button available there.
This would send a mail to his Email Account, with a Temporary Password, the Login URL and the Username. The Sub-Reseller can then Login with this Password and can then change his original Password, by going to Settings -> Change Password.
Please note that this Password would be effective for 3 days only. Also, during this time both the Original Password and the Temporary Password would both work for Logging in.
This method would be useful if a Sub-Reseller who has forgotten his Password and is also unable to get the Temporary Password via email. As a last step you can change his Password. You need to follow the below mentioned steps -
1. In your Reseller Control Panel, go to Sub-Resellers -> Search and search for the Sub-Reseller based on one of the search fields available.
2. From the list, click on the Sub-Reseller you were looking for. In the Sub-Reseller Details view that follows, you would find the Sub-Reseller Username and click on the button Change Password.
Contrary to the above 2 methods, this would Change his Password permanently. Your Sub-Reseller can then Login with this Password.
IV. Generating Temporary Password:
Using the method mentioned below you can yourself Login to the Sub-Resellers Control Panel, by generating a Temporary Password for it. Just follow the simple steps mentioned below -
1. In your Reseller Control Panel, go to Sub-Resellers -> Search and search for the Sub-Reseller based on one of the search fields available.
2. From the list, click on the Sub-Reseller you were looking for. In the Sub-Reseller Details view that follows, you would find the Sub-Reseller.
Username and click on the button Generate Temporary Password. This will present you with the Login URL, Username and a Temporary Password for the Sub-Reseller.
Please note that this Password would be effective for 3 days only. Also, during this time both the Original Password and the Temporary Password would both work for Logging in.
Tags: Change Passwor, Details View, Email Account, Email Address, Front Page, Logging, Mail, Mail Account, Mail Email, Passwords, Reseller Control Panel, Reseller Details, Reseller Login, Resellers, Search Fields, Send Email, Send Mail, Url
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
Your Sub-Resellers and Customers can request a Refund from their Debit Account with you. Request Refund is a useful feature allowing your Customers and Sub-Resellers to request for withdrawing funds, that they realise they will be unable to utilise in the near-term. For instance – a Sub-Reseller signs up under you and optimistically sends you USD 2000 to add to his balance. If after a month he realises that business is slow, he can choose to request a portion of the unused funds back, to help his cash flow.
To understand how a Refund Request is processed by the system, visit Refund Requests of your Customers and Resellers
Once the system receives a Refund Request, you need to complete the formalities by following these steps-
1. Go to Customers -> Billing -> List Pending Refunds for your Customers, or Sub-Resellers -> Billing -> List Pending Refunds for your Sub-Resellers’ refund requests.
2. This page displays a list of all Refunds requested from you. Select the request in question by clicking on the Description for it.
3. In the Refund Completion Description view that follows, enter a description which will be helpful to trace, how the refund is sent to Sub-Reseller or Customer. For instance, if the payment has been done by cheque, enter here the details of the cheque, such as cheque number – which might be used as reference for this transaction in the future.
4. Click on Submit.
iii. refund only the balance amount (if any) – If there are any surplus funds remaining with the Customer/Sub-Reseller after you have processed their Chargeback, you may either request them to place another refunds request from their Control Panel or you may do so yourselves by logging into their Control Panel and accomplishing the same from My Billing -> Request Refund.
Tags: Cash Flow, Check Draft, Debit Account, Description View, Formalities, Future 4, Onus, Payment Gateway, Refund Request, Refund Requests, Request Refund, Resellers, Signs, Unused Funds, USD
As a Reseller, you need to take certain steps in order to start selling Domain name Registration and Management to your Customers and Sub-resellers; the more essential steps are detailed below.
Before you go about the setup, we recommend that you go through the Domain Registration Setup video tutorial.
If you choose to integrate the domain name registration buy process with your website using our API Kit, then you need to ensure that you display the Registrar Registrant Agreement for Domain Names Legal document within the domain name registration buy process on your website.
It is compulsory to display this document AS IS to your Customers and get them to agree to the terms mentioned therein, before buying domain names through you. You can view this agreement from within your Reseller Admin Control Panel at Help >> Legal Agreements.
Tags: Admin Control Panel, Api Kit, Default Settings, Domain Name Registration, Domain Names, Domain Registration, Legal Agreements, Legal Document, Registrant, Registrar, Resellers, Servers, Tlds, Top Level Domains
1. Login to your Control Panel
Resellers do so from http://manage.gossimer.biz/customer.
2. Once logged in to your Control Panel,
Resellers, go to Products -> Search -> Domain Forwarding Search
Customers, go to Domains -> Search -> Domain Forwarding Search
and you can search for the Domain Name which you are looking for (To list all Domain Names you have registered, leave all search parameters blank).
3. In the next page you would see a list of all Domain Names, with Domain Forwarding Service bought through Gossimer.
Tags: Control Panel, Domain Forwarding Service, Domain Name, Domain Names, Domain Search, Domain Service, Gossimer, Manage Domain, Names Domain, Resellers, Search Domain, Search Parameters, Simple Steps
Debit Notes are Transactions signifying a payment that your Sub-Reseller or Customer Owes you, just like Invoices. In fact structurally they are very much like Invoices. Though they have a different meaning. Invoices always depict Sales, while Debit Notes on the other hand are used for deducting money from your Customer’s or Sub-Reseller’s Account without a sale being made. This is akin to the definition of a Debit Note in the pure accounting sense. Lets take a few examples to understand the difference between an Invoice and a Debit Note
When a Customer buys a service and you charge him USD 100 for that service you would raise an Invoice for the same
When a Customer pays you USD 100, and by mistake you credit the Customer USD 1000 in his account, in that case you now have to subtract USD 900 from his account in order to rectify your mistake. In order to subtract this USD 900 you will raise a Debit Note
In short a Debit Note is used to deduct funds from your Customer’s account when the deduction has no relationship to an Order or any Service rendered.
First lets delve into the fields that make up a Debit Note
Transaction ID: This is a numerical integer value which uniquely identifies every transaction. The system automatically generates serial numbers for you, separately for your Customers and your Sub-Resellers, starting from 1, incrementing upwards for each additional Debit Note created.
Transaction Date: This is the date on which the Debit Note was created
Description: This is the Description of the Debit Note, describing the purpose for which the Debit Note was created
Debit Note Amount: This is the amount of the Debit Note. This is the amount your Customer or Sub-Reseller needs to pay for that Debit Note. Incase your Selling currency is different from your Accounting Currency, you will see the Debit Note Amount in both the currencies.
Pending Amount: This is the amount pending against this Debit Note. To begin with this will be same as the Debit Note Amount. For instance if the Debit Note amount is USD 200, the pending amount will also be USD 200. If the Customer now chooses to make a payment of USD 100 against this Debit Note, the Pending Amount will then be USD 100. Incase your Selling currency is different from your Accounting Currency, you will see the Pending amount in both the currencies.
Forex Gain/Loss: If your Accounting Currency is different from your Selling Currency then the System records your Forex Gain/Loss for every transaction. Each time an Debit Note is paid, the appropriate Forex Gain/Loss for that Payment is calculated and maintained by the system. This has been explained in greater detail in FAQ: Balancing (Payment) of a Pending Invoice/Debit Note explained in Detail
Other Details: A Debit Note contains several other details such as Contact Information, Tax information, etc..
It is important to note that none of the above fields can be modified once a Debit Note is created. A Debit Note can only be balanced. It can never be modified. The amounts, address information, everything remains as it is. Another important aspect to note is that an Debit Note contains even your OWN contact details. If you click on the “Print” button in a Debit Note detailed view, it will show your contact details too. These contact details are separately stored with each Debit Note. These too cannot be modified. Even if you change your company name after 1 month, it will not affect the Debit Notes already raised under the previous company name. This change will only affect newer transactions.
Incase of an unpaid Debit Note you may see the below additional field
Reminder Days: This signifies the number of days after which a reminder for Payment of the Debit Note is sent to your Customer/Sub-Reseller, by the system, automatically. To understand Reminder days in greater detail visit – Payment Collection System and Parameters explained
Lets understand the different types of actions that can be performed on a Debit Note. These actions are accessible from the toolbar in a Debit Note detailed view.
Pay:
You can pay the Debit Note using funds from your Customer’s or Sub-Reseller’s account. On clicking Pay, you will be able to directly use funds from your Customer’s or Sub-Resellers account to pay for the Debit Note. The pay button assumes that your Customer or Sub-Reseller has funds in their account. If your customer or Sub-Reseller does not have funds to cover the Debit Note, you can choose to first Add Funds in their account and then subsequently pay the Debit Note.
To understand the calculations performed by the System during the process of balancing a Debit Note visit FAQ: Balancing (Payment) of a Pending Invoice/Debit Note explained in Detail.
Cancel: You can cancel the Debit Note using the cancel button. Your Customer/Sub-Reseller will no longer have to pay for this Debit Note.
Cancel as Bad Debt: In the event that you are not able to recover either the entire Debit Note amount or a part of the Debit Note amount, even after sending payment reminders to your Customer/Sub-Reseller, you may write off (cancel) the pending Debit Note as Bad Debt. Clicking on this button, would raise a Credit Note of the amount pending in the Debit Note (that is being cancelled).
To understand the calculations performed by the System during the process of cancellation of a Debit Note visit FAQ: Cancellation of a Pending Invoice/Debit Note explained in Detail.
Print: You can use this button to obtain a Printable Copy of the Debit Note for your reference
An additional concept which is important to note with respect to Debit Notes is the maintenance of the Total Receipts figure. A Total Receipts figure is maintained for every Customer/Sub-Reseller of yours, and appropriately modified for every Debit Note added for that Customer/Sub-Reseller. This Total Receipts figure is then used to offer discounts to Sub-Resellers and Customers doing higher volumes of business. Visit FAQ: Understanding Calculation of Total Receipts for your Customers/Sub-Resellers for more details on Total Receipts calculation.
Tags: Accounting, Currencies, Currency, Debit Note, Debit Note Transaction, Different Meaning, Incrementing, Integer Value, Invoice, Invoices, Mistake, Money, pure accounting sense, Relationship, Resellers, Serial Numbers, Transaction Id, USD
Order Suspension is a useful feature available to Resellers of Gossimer. In this status, the Order remains in the database but is inactive and the functionality associated with it cannot be used. No one can make ANY modifications to this Service unless it is unsuspended.
Follow the steps below to Suspend / Unsuspend Email Forwarding Service -
1. Login to your Reseller Control Panel from http://manage.gossimer.biz/reseller.
2. Go to Products -> Search -> Mail Forwarding Search and perform a search for the Domain for which you wish to Suspend Email Forwarding.
3. In the Search Results, click on Email Forwarding for the Domain.
4. The next page is the Order Details view, where you would find the Suspend / Unsuspend Button.
- If you wish to Suspend the Service, you would have to select the Check Box for Suspension and enter the reason for Suspension and click on Update.
- to Unsuspend, unselect the Check Box and Update the same.
Tags: Biz, Email Domain, Email Forwarding Service, Email Service, Functionality, Gossimer, Mail Forwarding Service, Mail Order, Mail Search, Mail Service, Order, Reseller Control Panel, Resellers, Search Domain, Search Mail, Unsuspend Email Forwarding Service
The Gossimer Receipt Report indicates all funds manually added in your Sub-Reseller/Customer’s Debit Account by you, in any previous month.
1. Login into your Reseller Admin Control Panel from http://manage.gossimer.biz/reseller
2. Click on Tools -> Reports -> Receipt Report
3. Generate a Receipt Report based on one or more of the parameters explained below:
Select Type – You can generate a Receipt Report for either your Sub-Reseller or Customer
Select Country – You can generate a report for a particular Country, by selecting the same. You may also select only your Country or all countries except your Country.
Choose Type of Report – Through this option, you can select the Total to be either Sub-Reseller/Customer-wise or Country-wise.
Customer Ids/Sub-Reseller Ids – If you wish to generate the report for particular Customers or Sub-Resellers, you can put them here separated by commas.
Select Month And Year – The report can be generated for any previous month. This month’s report would be available the next month.
Select Column for Sum – Through this option you can choose to display the sum of one or more of the following columns (by pressing the Control key while clicking on multiple selections) – Manual Receipt Amount, manual Credit Note Amount, Credit Note added to Cancel a Debit Note.
Tags: Admin Control Panel, Cancel, Columns, Control Key, Debit Account, Debit Note, Parameters, Receipt, Reseller, Resellers, Sum Of One
Gossimer sends mails to its Customers informing them about all Domain Forwarding Service Orders that are nearing their expiration date.
Customers of Gossimer:
Customers are sent Expiring Domain Forwarding Service Orders Renewal Instruction e-mails before they actually expire, after expiry, and on deletion of the package.
The Reminders are sent to the Customer Username from 45 days prior to the Domain Forwarding Service Order’s expiry, on the 1st, 11th and 21st day of every month, until it is either Renewed or Deleted (due to non-Renewal).
This Report displays the Order ID, Domain Name, Product Category, Expiry Date, Days to Expiry and Days to Deletion, besides detailed information about how to go about renewing these orders.
Gossimer Resellers can easily view all Expiring and Expired Domain Names from the Renewal Management Interface and choose to Renew any Domain Forwarding Service Order on behalf of their Customer(s).
IMPORTANT
When a Domain Forwarding Service Order Expires,
the order is immediately Suspended. This means that you would be unable to use your order, until it is Renewed.
the Customer is sent an e-mail, informing him that he has 15 days to Renew his Domain Forwarding Service Order, post which the order is Deleted.
When the Domain Forwarding Service Order is Deleted, the Customer is sent one final e-mail informing him/her that the order is Deleted, since it was not Renewed within 15 days after Expiry.
Tags: Customer Username, Domain Forwarding Service, Domain Name, Domain Names, E Mail, Expiration Date, Expiry Date, Gossimer, Management Interface, Product Category, Renewal Management, Renewal Reminders, Resellers
Gossimer has directly integrated the PayPal API within our system, such that by mentioning a few details in your interface and your Business PayPal Account, you can safely and securely collect money from your Sub-Resellers and Customers.
When your Customer/Sub-Reseller decides to pay you through this Payment Gateway, we send all the variables via an API Call to the PayPal Server, to get the transaction authenticated. All this while your Customer/Sub-Reseller continues to remain within their OrderBox Control Panel itself.
Before you Start
You will need to verify/perform the following before you start -
Verify that you have a Business PayPal account only. You cannot integrate a Personal PayPal account with our System.
Apply for Website Payment Pro (for US Business PayPal accounts only)
You need to apply for Website Payment Pro before you can make successful API calls to services such as DirectPayment. If you have already been approved for Pro, you also need to accept the Billing Agreement. This is sometimes overlooked by merchants who think they have already accepted this by applying for Pro, but it is indeed a separate step that must be completed after approval.
a) Login to your PayPal account [must be a Business account] from https://www.paypal.com
b) Click the Merchant Tools tab
c) From the Dropdown select
d) On the bottom of the right column, under Getting Started, click on
e) Complete the 2 page form
f) Click
At this point, your account will undergo an approval process by PayPal that generally takes 2-3 days. Once you have been approved for Website Payments Pro, login back into your PayPal account and complete these steps:
i) Click the Merchant Tools tab
ii) In the top right corner, click Accept Billing Agreement
iii) Click Agree
a) Login to your PayPal account from https://www.paypal.com
b) Click on
c) Click on
d) Mention the API Account Name as
e) Enable API Access for the following calls and click on the Save button
i) RefundTransaction
ii) GetTransactionDetails
iii) TransactionSearch
iv) DoCapture
v) DoVoid
vi) DoDirectPayment
vii) DoAuthorization
Using PayPal Direct Payment API Gateway, you would be able to accept funds from only 55 countries. The complete list of these countries is available at http://www.paypal.com/cgi-bin/webscr?cmd=_display-approved-signup-countries-outside.
Adding the PayPal Direct Payment API Gateway into your account consists of the following simple steps -
1. Login into your Reseller Control Panel from http://manage.gossimer.biz/reseller
2. Click on the Settings -> Finance & Billing -> Payment Gateway -> List / Add
3. Click on the Add Payment Gateway button and then on the Add a PayPal Direct Payment API Gateway link.
4. Enter the following details and Save your changes by clicking on the Submit button
Gateway Name – This Gateway Name would be shown to your Customers/Sub-Resellers, when they are about to make Payment. You can use something like “Credit Card Payment” or “Visa/Master Card” etc.
PayPal Account Username – The Username [e-mail address] you use to login into your PayPal Business account.
Currency – PayPal allows you to charge your Customers/Sub-Resellers in 6 different currencies. However, to use the PayPal Direct Payment API Gateway, you can only select USD Currency.
Currency Exchange Rate – If your Selling Currency differs from USD, we will have to convert the Order Value to the PayPal Currency, BEFORE we send your Customer/Sub-Reseller to PayPal. For this purpose the system needs a exchange rate between the two.
You may choose to maintain this exchange rate yourselves or let us maintain it for you. We download FOREX rates on a daily basis from a recognised source and update exchange rates for you. If however you wish to update the rates yourselves then you may do so by selecting the I would like to Maintain the currency exchange rate myself checkbox AND entering your own conversion rates.
Select the types of CREDIT CARDS that your merchant account supports - You need to select the types of Credit Card that are supported by your PayPal Account. The credit card types available are – Visa, MasterCard, American Express, Discover. You can also decide the sequence in which you want your Customers / Sub-Resellers to view these Card types on the payment page.
Payment Gateway Access Level for Customers and Sub-Resellers – Click here to know more about the Payment Gateway Transaction types and Access Levels for your Customers and Sub-Resellers >>
Deciding whether a Sub-Reseller and Customer is Credited with the Gross Amount or Net – PayPal deducts a fee per transaction. There are two types of Transactions that can pass through your PayPal integration – Invoice/Debit Note Payment, and Add Funds. Click here to know more about the Payment Gateway Transaction types and Access Levels for your Customers and Sub-Resellers >>
In case of an Add Funds Transaction, you have the option of crediting your Customers/Sub-Resellers with the NET Amount that PayPal credits you with, or choose to credit them with the gross funds and bear the charges yourselves.
If you have selected to credit a Customer/Sub-Reseller with the Net Amount in an Add Funds transaction, then you must submit either a Fixed Transaction fee (greater than 0) or a Variable Transaction fee (greater than 0).
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 the PayPal 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.
1. 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 & PartnerSite Cache -> SuperSite Payment Preferences. Click here to know what is SuperSite >>
2. After you have setup the above, you must setup a PayPal Standard Checkout Gateway as well, as per the Legal guidelines mentioned by PayPal. Click here to know how >>
Tags: American Express, Api, Api Calls, Business Account, Control Panel, Gossimer, Interface, Merchant Tools, Merchants, Money, OrderBox Control Panel, Payment Gateway, Paypal, Paypal Account, Paypal Payment, Personal Account, Resellers, Tab C, Variables, Website Payments Pro, Www Paypal, www.paypal.com
The OrderBox interacts with all its users in various ways. There is an e-mail sent for EVERY kind of activity performed by you or your Sub-Resellers/Customers in order to keep you informed of all steps. Every e-mail sent to your Sub-Reseller/Customer, however, is sent transparently from YOUR e-mail address. Gossimer Name/Address is not mentioned anywhere in this process.
There are various information that you can customise to better facilitate all communication with the Sub-Reseller/Customer. Follow the steps below to customise these settings.
1. Click on Settings -> Personal Information -> Contact Information
2. Modify all the information in the form to suit your needs. All the fields in the form are explained below –
I. Billing Information
Billing Contact E-mail Address and From Name:
This e-mail address is crucial and important. This is the e-mail address where we will send all billing notifications to you. For instance, if your Funds fall below the threshold level, you will be sent an email to this e-mail address. Additionally, all correspondence to your Sub-Resellers/Customers about billing matters such as payments received from them, etc. will be sent to them from this e-mail address, using the Email Address From Name if specified. A typical billing email address could be billing@yourcompany.com and the Email Address From Name could be “YourCompany Billing Dept.”
Other Billing Contact Information (Tel./Fax):
This is information about the Person/Contact who handles all billing matters with respect to your company. This information is displayed to a Sub-Reseller/Customer, in case the Sub-Reseller/Customer needs to contact someone from your Billing Department.
c. Billing E-mail Signature:
Enter your Billing Team’s e-mail signature in this field to customise all e-mails sent to your Sub-Resellers/Customers. Any email sent to your Sub-Resellers/Customers about any billing matters will contain this signature as it is.
II. Sales Information
Sales Contact E-mail Address and From Name:
This is the e-mail address where we will send all sales notifications to you. For instance, any Sub-Reseller/Customer places an order on your website, an e-mail will be sent to this Username [e-mail address]. Additionally, all correspondence to your Sub-Resellers/Customers about sales matters such as Orders placed by them, Renewal Reminders, Transfer Authorization mails sent to Admin Contact etc. will be sent to them from this e-mail address, using the Email Address From Name if specified. A typical sales email address could be sales@yourcompany.com and the Email Address From Name could be “Your Company Sales Dept.”
Sales E-mail Signature:
Enter your Sales Team’s e-mail signature in this field to customise all e-mails sent to your Sub-Resellers/Customers. Any email sent to your Sub-Resellers/Customers about any sales matters will contain this signature as it is.
III. Support Information
Technical Support E-mail Address:
It is compulsory for you to provide your Technical Support E-mail Address, so that your Sub-Resellers and Customers can contact you in case of such issues. This email address or the Tech Support URL below is displayed to your Customers/Sub-Resellers at various places such as in the menu, in any error message, etc.
Technical Support URL:
Incase you have a Technical Support URL which you wish your Customers/Sub-Resellers to visit for any support they wish to request from you then specify this URL here. This setting overrides the Tech Support Email Address i.e. if you specify a Tech Support URL we will never display the Tech Support Email Address to your Customers/Sub-Resellers. We will only display the Tech Support URL. This can help if you have a web based support ticketing system and wish your Customers/Sub-Resellers to only use that while requesting Support.
IV. Abuse Desk Information
Abuse Desk Email Address and From Name:
It is compulsory for you to specify your Abuse Desk E-mail Address, so that all SPAM complaints regarding Domain Names Registered through your Customers can be sent to you at this Email Address. Additionally, the mails sent using the SPAM Processing Tool would be sent using this E-mail Address and From Name. Click here to read about the SPAM Processing Tool >>
Abuse Desk Signature:
Enter your Abuse Desk’s e-mail signature in this field to customise all e-mails sent to your Sub-Resellers/Customers. Any email sent to your Sub-Resellers/Customers about any Abuse Desk matters will contain this signature as it is.
The SuperSite displays your Contact Information to your Customers. 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 & PartnerSite Cache -> SuperSite & PartnerSite Reseller Branding. Click here to know what is SuperSite >>
Tags: Billing Address, Billing Department, Billing Dept, Billing Information, Billing Matters, Billing Support, Correspondence, Department C, Desk, E Mail Address, Email Address, Funds fall, Information Tel, Mail Signature, Name Address, Notifications, Orderbox, Resellers, Signat, Support Desk, Tel Fax, Threshold Level
The Reseller Control Panel comes built in with a customizable Payment Collection agent which you can use to ensure timely collection of Payments from your Customers and Sub-Resellers. It is important to understand the different financial instruments available within the Control Panel before we delve into a discussion of the Payment Collection module.
Your Customers and your Sub-Resellers in the course of their operations will owe you money for specific reasons. These reasons can be as follows
They place an Order
You enter a Debit Note in their account
A payment made by them in the past charges back
You add an Invoice in their account
There are two types of transactions which you can use to collect money from your customers and Sub-Resellers. These are Invoices and Debit Notes. You have the ability to raise Invoices and Debit Notes yourself, as well as the system will occasionally raise them for you in specific circumstances. For instance when your Customer places an Order an Invoice for that Order is automatically raised by the system.
An Invoice and Debit note are quite different transactions. An Invoice is always related to an underlying Order, and may actually have some action of the Order dependant on the Invoice. For instance an Invoice for Renewal of an Order, has the action of renewal dependant on the Invoice. A Debit Note on the other hand is not related directly to any Order. Both of them share some common characteristics with respect to Payment Collection. An Invoice however has extra and more powerful Payment collection parameters.
Reminder Days
Let us first examine the single shared Payment Collection parameter that an Invoice and Debit Note have. Both an Invoice and a Debit Note have one field in common, namely the Reminder Days. This is a simple Payment Collection parameter which allows you to send a Payment Reminder to your Customers and Sub-Resellers for their Pending Payments. Every Invoice and Debit Note has a Reminder Days value. This includes Invoices and Debit Notes that we automatically generate as well as Invoices and Debit Notes which you feed in.
Reminder Days is basically the number of days the System waits before sending the next Payment Reminder for a particular Invoice/Debit Note, to your Customers. If for instance the Reminder Days value is set to 5 days for a particular Invoice of a Customer, then the Customer will receive a reminder to pay for that Invoice EVERY 5 days, until the Invoice is FULLY Paid. The Reminder days value is irrelevant after an Invoice or Debit Note is fully paid
Default Reminder Days for Invoices
To begin with you can set a default Reminder Days value per Product, which will be used by the System when it automatically generates Invoices for that Product. This can be done from the Settings -> Finance & Billing -> Payment Collection Settings. If for instance you set the default Payment Reminder Days for Product A as 10 days, then for EVERY Invoice generated for an Order of Product A, will have a default Invoice Reminder days set to 10 days.
Default Reminder Days for Debit Notes
You cannot set a default Reminder days value for Debit Notes. This is a hard-coded value, set to 5 days, for ALL Debit Notes. Therefore any Debit Note that the system generates automatically will contain a Payment Reminder Days value of 5 days to begin with.
For any Invoice or Debit Note that you add manually you can specify the Reminder days during the creation of that Invoice or Debit Note. Simply click on Customers -> Billing -> Add Invoice / Add Debit Note or Sub-Resellers -> Billing -> Add Invoice / Add Debit Note and you can specify the Reminder days for that Invoice/Debit Note while adding it.
Reminder days can be an extremely powerful feature, and it ensures that your Customers/Sub-Resellers are constantly reminded about any pending payments until they are cleared.
IMPORTANT
The Payment Collection Reminder emails would be sent only after the request associated with the Invoice is completed while the payment is still pending. If both the payment as well as the request are pending then the Customer will not be intimated about the pending payment.
Reminder days are also the only Payment collection feature available for a Debit Note. Remaining features in the Payment Collection system are only available for Invoices. Read on to find out about these:-
Invoice Specific Payment Collection features
Apart from Reminder days there are three other fields that Invoices can have to facilitate Payment Collection. These fields are
1. Request Cancellation Date
2. Order Suspension Date
3. Order Deletion Date
Note that these fields are available only if the Invoice is unpaid. They are not available for Paid Invoices since there is no Payment Collection pending for paid Invoices.
Request Cancellation Date:
This field is available to any Fully unpaid Invoice which has a Pending Request associated with it. An Invoice associated with a Request can only be automatically generated. This field basically serves to cancel any Order or Request placed and then not paid for for several days. For instance if a dummy Customer comes to your website and Registers for a domain name. An Invoice is raised for this Domain Name. Now if the Customer does not pay for the domain name, within the Request Cancellation date then on the Request Cancellation date the Invoice and the Request for registration are both cancelled.
IMPORTANT
The Request Cancellation Date is relevant for only that Invoice which meets the following criteria:
it is system generated, and
it has a pending request, and
it is fully unpaid
If the Invoice does not have a Pending Request, OR if the Pending Request (of the Invoice) is executed without payment (Execute w/o Payment), OR if the Invoice is partly paid, then the Request Cancellation Date ceases to exist.
Lets take an example to understand this better. Lets assume a Customer of yours – Customer A, has the following Invoice
Invoice ID: 1
Invoice Description: Renewal of abcd.com for 1 years
Status of Renewal: Pending
Invoice Amount: USD 100
Pending Amount: USD 100
Invoice Date: 1st Jan, 2003
Request Cancellation Date: 10th Jan, 2003
The above Invoice would be created when Customer A requested for the renewal of abcd.com. After this the Customer would continue to get reminders to pay for this Invoice every “Reminder Days”. The following situations can now occur -
Customer pays for the Invoice. In this case the Request Cancellation Date would cease to exist. The payment does not have to be a full payment. Even if the Customer pays only USD 10, against the Invoice amount of USD 100, even then the Request Cancellation date would cease to exist.
You execute the Request without a payment. You can do this using the “Execute w/o Payment” button from your Control Panel. This would also cancel the Request Cancellation Date
In case neither of the above occurs, the Invoice and the associated Request would be automatically cancelled by the system on 10th Jan, 2003
The logic for the above is that if an Invoice is partly paid, or if you Execute the Request, then the Invoice should not be automatically cancelled by the system, because both these actions mean that the Invoice should be paid for completely. If however an Invoice is simply created and not paid for or its underlying Request not executed for a long duration, the System performs a cleanup based on the Request Cancellation Date.
Since a Request Cancellation Date appears only for those Invoices which are System generated and have an associated Request, the Request Cancellation Date is automatically set by the System, based on your default preferences. These default preferences are specified per Product under Settings -> Finance & Billing -> Payment Collection Settings.
Order Suspension Date/Order Deletion Date:
These two fields are the most powerful Payment Collection parameters allowing you to suspend or Delete an Order of your Customer or Sub-Reseller automatically within a predefined time period if they have not paid for a particular Invoice. These fields are available for System Generated (with the exception of Domain Registration Orders) as well as manually raised Invoices.
The purpose of these fields is quite explicit. Basically both these dates can be set to specific dates. When that date is reached and if the Invoice for which this date is set still continues to remain unpaid, the Order is then Suspended or Deleted as the case maybe. While these fields are powerful, use them with great care. A Suspended Order becomes immediately inactive. More importantly a Deleted Order cannot be recovered at all. Once an Order is deleted the process cannot be reversed. These fields are both optional, and their values depend on default settings you have made, as well as any specific modifications you make.
Lets take an example to understand these fields better. Lets assume a Customer of yours – Customer A, has the following Invoice
Invoice ID: 1
Invoice Description: Invoice for Web Design of abcd.com
Invoice Amount: USD 100
Pending Amount: USD 100
Invoice Date: 1st Jan, 2003
Order Suspension Date: 10th Jan, 2003
Order Deletion Date: 30th Jan, 2003
The above Invoice could have been manually created by you. At the time of creation of the Invoice you set the Order Suspension Date, and Order Deletion Date. The following situations can now occur -
Customer pays for the Invoice in full. In this case the Order Suspension and Order Deletion Dates would cease to exist. The payment however MUST be a FULL Payment. As long as the Invoice is not FULLY Paid the Order Suspension and Deletion dates will continue to exist.
In case if the above does not occur, the Order will be Suspended automatically on 10th Jan and subsequently Deleted on 30th Jan
If after the Order is suspended the Customer pays for the Invoice in full then the Order will be reactivated
You can always Unsuspend an Order which is suspended, you can however never undelete an Order. Once an Order is deleted it cannot be recovered again
As you can see these parameters take the Payment Collection load off your back. The System sends several reminders to your Customers/Sub-Resellers, clearly mentioning that the Order would be suspended/deleted if it is not paid for, and if they do not pay despite those Reminders then the System will automatically Suspend/Delete those orders. Similar mails are sent to yourself informing you about the pending payments of your Customers/Sub-Resellers.
For every Invoice you create you can specify an Order Suspension/Deletion Date at the time of creation of the Invoice. Additionally the system itself sets Order Suspension and Order Deletion dates on System Generated Invoices based on your default preferences per Product. These default preferences are specified per Product under Settings -> Finance & Billing -> Payment Collection Settings.
In Order to fully grasp the philosophy of these Payment collection parameters it is recommended that you read FAQ: Invoices.
Tags: Circumstances, Control, Customizable Payment, Debit Note, Dependant, Extra, Financial Instruments, Invoice, Invoices, Money, Order, Parameters, Payment Reminder, Reseller Control Panel, Resellers, Respect, Timely Collection, USD, Web Design
The Suggested Retail Price displayed on your PartnerSite Pricing Pages is the price at which you are selling a particular package/plan of the various Products and Services to your Customers. The Profit percentage (%) displayed to your Sub-Resellers here, represents the profit they will make if they sell at your suggested retail price.
It is always advisable to sell to your Sub-Resellers at lower prices than to your Customers, since Resellers are bound to do more volume of business than retail customers, via their own Customers and Sub-Reseller chain. Click here to know how you may configure pricing of various Products and Services >>
If however, you intend to sell to your Customers at lower prices than to your Sub-Resellers, then you would need to customize your PartnerSite Pricing page to remove the Suggested Retail Price field. Click here to learn how you may customize your PartnerSite Content and HTML Structure >>
Tags: HTML, Price Field, Profit Percentage, Reseller, Resellers, retail customers, suggested retail price
Follow the steps below to Suspend/Unsuspend the Website Builder Service for a domain name:
1. Login to your Reseller Control Panel from http://manage.gossimer.biz/reseller.
2. Go to Products -> Search -> Website Builder Search and search for the Domain name whose service you wish to suspend.
3. In the Order List view, click on the Domain name. This will take you to the Order Details view.
4. Here, click on Suspend/Unsuspend.
Tags: Biz, Builder Search, Details View, Domain Name, Domain Service, Functionality, Order, Reseller Control Panel, Resellers, Search Domain, Website Builder, Website Builder Service, Website Search
The system allows you to add funds to your Customers/Sub-Resellers Account. This is a very useful feature and you should take time to explore it and use it. Adding funds for a particular Customer/Sub-Reseller allows that Customer/Sub-Reseller to directly Execute Orders and Pay for Invoices from their Control Panel until the funds last in their Account. There are two types of Transactions you can use to Add Funds to your Customers/Sub-Resellers account – Receipts & Credit Notes. You are advised to read up Receipts & Credit Notes section before you read this section.
Typically it is good practice to feed in EVERY Payment Received from your Customer/Sub-Reseller using this Add Funds option. In order to Execute any Order placed by your Customers, it is good practice to first Add Funds to that Customer Account and then pay for the Invoice raised for that particular Order.
Follow the steps below to Add Funds to a Customers/Sub-Resellers Account:
1. Click on Customers -> Billing -> Add Funds or Sub-Resellers -> Billing -> Add Funds
2. Put in the Email Address of the Customer/Sub-Reseller you want to Add Funds for.
3. Verify on the Next page that you indeed are adding funds for the Correct Customer/Sub-Reseller. Additionally on this page we also display the last 3 Add Funds transactions you have done for this Customer/Sub-Reseller, in order for you to verify that you are not Adding Funds for the same transaction twice.
4. Fill in the Amount you want to Credit to this Customer. This is the main field that will be used to add funds to the Customer. The remaining fields are chiefly information fields. Incase your Selling Currency and Accounting currency are different, you will have to enter both the values along with a Conversion rate. If you have chosen to allow the System to maintain your Conversion Rate, this box will be pre-filled for you. You can choose to modify the conversion rate incase you require it to be different. The important aspect to note is that we actually perform a calculation by multiplying the Selling Currency Amount with the Conversion rate and comparing with the Accounting Currency Amount to ensure that you make no mistakes in the entry. If these 3 values do not match we will not allow the transaction.
IMPORTANT
Only upto 3 decimal places are permitted for any of these fields.
5. If you have received the money from your Customer/Sub-Reseller then you should choose to add this amount as a Receipt; otherwise choose Credit Note.
A Credit Note may be raised for any of the following reasons
Miscellaneous Credit
Chargeback Reversal – Raise a Credit Note under this type when you have received payments from your Customer/Sub-Reseller as a Reversal for any previous Chargeback (transaction dispute) done by him.
6. Mention an appropriate Description for the Receipt/Credit Note that will make identifying this fund’s source, amount, date, etc. clear to both yourself and your Customer/Sub-Reseller.
IMPORTANT
In case of a manually raised Receipt/Credit Note, the description of the Receipt/Credit Note can be modified at a later stage as mentioned below -
Login to your Reseller Admin Control Panel from http://manage.gossimer.biz/reseller
Go to Customers -> Billing -> List Transactions for Customers / go to Sub Resellers -> Billing -> List Transactions for Sub Resellers.
Click on the description link of the Receipt/Credit Note to view the Receipt/Credit Note Details page.
Click on Modify Description button.
Modify the content in the Description field and click on Modify to submit the change.
7. A Transaction Key is a per transaction unique set of characters or numbers or any word that would easily allow you to differentiate every instance of a manually raised Receipt or Credit Note. This key ensures that you do not add the same transaction twice into the system.
IMPORTANT
If you enter the same Transaction Key in multiple transactions, then you will receive an error message. You need to do the following when you encounter this error:
1. Depending upon whether you are adding funds for your Customer or Sub-Reseller, you need to go to either Customers -> Search or Sub-Resellers -> Search.
2. Mention the Customer/Sub-Reseller’s Email Address (as the case maybe) and click on the Search button.
3. Click on the Customer/Sub-Reseller to view their details.
4. Click on the List Transactions button to review if these funds have already been credited to your Customer/Sub-Reseller. You may also perform an advanced search by clicking on the Advanced Search button on the top of this page.
Now,
if these funds have been already added to your Customer/Sub-Reseller’s Debit Account Balance, then you should not proceed adding these funds again.
if you can not locate a transaction of the same amount and date as the one you are adding at present, then this Add Funds Transaction must be unique but the Transaction Key you are mentioning has already been associated to a previous transaction.
In this case, you should press your Web Browser’s Back button and continue this Add Funds transaction with another Transaction Key.
8. You can choose to Add this amount to the Total Receipts figure for that Customer/Sub-Reseller. Click here to find out more about the calculation of Total Receipts for your Customers and Sub-Resellers >>
9. Once you finish filling the details and move onwards you will be displayed a Confirmation page with all Customer details and Transaction details for one final confirmation before adding the Funds to the Customer/Sub-Reseller Account.
10. Clicking on Confirm Transaction will result in the Funds being added to the Customer/Sub-Reseller Account.
11. Upon finishing an Add Funds transaction, you will see a list of Pending Invoices/Debit Notes of your Customer/Sub-Reseller. You can pay off any Pending Invoices and Debit Notes from this list using the funds in that Customer/Sub-Reseller Account
Add Funds can be used to add a credit of advance funds in your Customers/Sub-Resellers account. It can additionally be used to execute any particular Order placed by your Customers. For any Order placed by your Customer an Invoice is generated in the System. You will have your own method of collecting Payment for this Invoice from your Customer. Typically the Customer may send you a cheque or some offline Payment. In Order to execute the Order it is good practice to feed in this Payment as a Receipt in the Customer account and then subsequently pay the Invoice. You can, of course, choose to Execute w/o Payment. Click here for more details about Invoices >>
Tags: Accounting, Adding Funds, Amp, Billing, Control Panel, Conversion Rate, Credit Notes, Currency, Customer Account, Information Fields, Invoice, Invoices, Receipts, Resellers, Web Browser
If you want to display a login box on your website from where your Customers and Sub-Resellers can login into their respective Control Panels, then you may integrate the following form on your website:
<Your Control Panel Branded URL> – Here you need to put your Branded URL, you can check the same from your Reseller Control Panel by going to Settings -> Storefront & Control Panel -> URL. Here you can either use the Partially Branded URL or the Fully Branded URL. Click here to learn how to Brand your Control Panel URL >>
<Your Reseller Id> - You can get your Reseller Id from your Control Panel by going to Settings -> Personal Information -> Primary Profile. Here the first field is the Reseller Id. You need to put this number in place of <Your Reseller Id>.
<role> - If you are integrating Sub-Reseller Login, then you need to put in role as “reseller” and if you want to integrate your Customer Login box, then put the role as “customer”.
Tags: Amp, Input Type Text, Lt, Quot, Reseller Control Panel, Reseller Id, Reseller Login, Resellers, Storefront, Type Password, www.foundationapi.com/servlet/AuthenticationServlet_quot