1. Unzip Kartris to a folder on your desktop. Using FTP, upload the files to your web site.
2. Make sure your hosting is set to run as ASP.NET 4.0.
   
3. Call up the site in your web browser, and the setup routine should run.
4. When you get to the stage to setup the database connection, you will probably need to use the database address (or IP), name, username and password given to you by your web host. The install routine will try to rewrite your web.config file with these connection details, but if the permissions do not allow this, you can download it from the setup routine and then upload to the root of your site with FTP instead.
5. If you get problems running the database setup and want to create the database first through MS SQL's Management Studio interface, the .sql file is located here:
   
   Uploads/Resources/kartrisSQL_MainData.sql
   
   When you run the setup routine again, it should notice that you already have a Kartris database populated.
6. Once setup and logged in to the back end, you can go to the front end by clicking the Kartris logo link in the top left of the page.
   

• Configuration permissions - user can change config values, shipping, tax, countries and other setup details
• Product permissions - user can view/edit categories, products and versions
• Orders permissions - user can view/change customers, orders, affiliates and coupons
• Support permissions - user can view/change support tickets and knowledgebase articles

• EU
  
• US
  
• Canada
• SIMPLE

• Product ID
• Product Name
• Product Creation Date
• Product Last Modified Date
• Product Category Sort

• Ascending
• Descending

Attributes are sometimes confused with 'options', but they are quite different. Options are choices that are available to a customer to select when choosing a product. Attributes on the other hand are fixed pieces of information that apply to the product and cannot be selected or deselected by a customer.

To give an example of usage, a book might have a number of attributes:

• ISBN (unique book number that all books have)

• Publisher

• Author

• Genre (thriller, romance, non-fiction, etc.)

• Format (hardback, paperback, audio book, e-book)

Once created, you can enter the information for each and every book you feature on your site (although there is no requirement to enter any attributes for any item where you don't wish to).

Go to 'Product > Product Attributes'. A list of all current attributes appears. You can click to create a new attribute, or edit an existing one.

Attribute type is fixed as 'text', but other types may be supported in future.

You can control if the attribute is displayed in the product page from the checkbox – unchecking the box means the attribute is hidden from displaying there.

If all the attributes of a product are hidden in this way, the 'product details' section on the product page will be hidden.

You can control whether an attribute is searchable too, with the 'include in search' checkbox. For example, you might not want voltage to be searchable, but you would most likely want the author attribute for a book to be searchable, or the ISBN number, as customers are very likely to use these to find particular items.

The final option is 'Show on comparison table'. This sets the circumstances under which the attribute will be displayed when comparing products.

Stock tracking does not need to be activated globally for the store. Instead, you can apply just to the items that you need to track stock for.

When creating or editing a version, check the 'stock tracking' checkbox. There are two relevant text fields: the actual stock quantity, and the warn level.

When the stock quantity reaches the warn level or below, a stock warning will appear in the 'To Do' list on the right hand side of the back end. This way, you can re-order more stock before your supplies are exhausted.

Items which are out of stock will have their 'Add' button on the front end replaced by an 'out of stock' message to prevent the items being purchased.

You can use the frontend.orders.allowpurchaseoutofstock config setting to allow out of stock items to be purchased on your store.

You can click through to a customer from any order record in the back end.

On the Customers page ('Customers > List/Find'), you can search by part of the email address, name, company or by the ID number. If you enter a number alone that matches exactly an ID number of a customer in the database, Kartris will take you directly to that customer's user record.

If you deal with certain types of customers such as retail customers, wholesale customers, preferred customers, etc. you may find it useful to group these customers so that you can easily find all similar customers or apply certain benefits, prices and restrictions to them. The customer group functionality in Kartris can be accessed by going to 'Customers > Groups').

Affiliates are organizations and individuals who refer customers to the store via a specially coded link. In return, the affiliate will be given commission based on the sales generated by those they refer.

You can disable the affiliate system on your site (so visitors cannot see it and sign up to it) with the frontend.users.myaccount.affiliates.enabled config setting.

Promotions can rapidly cause major problems when they overlap, as it creates many more possible options as to what rules should be applied.

For example, if you have a buy two 'A' and get 'B' free in a store that also has buy two 'A' and get 'C' free, you are effectively giving both B and C away when the user buys two of 'A'. Other problems can occur when one of the 'free' items (B or C) in the case of the above, also earns some promotion discount. For example, if you had another promotion buy B get D free, then the item B (which is free thanks to one of the promotions above) also results in a free item 'D'. So the purchase of two 'A' now gives B, C and D for free. Probably not was intended when each promotion was created.

To limit the chance of multiple promotions, stores may wish to limit the total number of promotions that can be triggered in a single order. The config setting frontend.promotions.maximum can be set to zero for 'no limit', or any number above to limit promotions.

When clicking the 'New' link, the promotion form comes up.

The promotion can be given a name, in multiple languages if you store supports that, and a checkbox can be set to determine if the promotion is 'live' (available) or not.

You can choose a start and finish data and you can also set the maximum number of this promotion that can be applied.

The sort value helps set the priority with which a promotion will be treated if there are multiple overlapping promotions (for example, the conditions of items in the basket triggers two different promotions).

Promotions consist of two sides – the first being what the customer must spend or purchase, and the second being what they receive as a result. We refer to these as part 'A' and part 'B' for simplicity.

On the promotions page, part 'A' is set on the left hand side, and part 'B' on the right hand side.

From the first dropdown menu of part 'A', the type of promotion can be chosen. Once a type is selected, textboxes will appear to let you specify further information. For example, if you select buy [X] of [P] (buy a certain number of a certain product), a textbox appears for the quantity (X). Enter a whole number. A second textbox also appears for the product (P). Enter the name or part of a product name here, and the filtered box will display the options. Select the appropriate one, and it will be entered to the textbox. The last step is to click the 'Add' link to add this new pattern to part 'A'. It will turn into a blue link just below the dropdown menu.

Note that you can add multiple requirements to part 'A'. So you could have a requirement to buy one product D, and spend $10, for example.

The next step is to fill out what the customer receives on part 'B'. The process is similar to that for part 'A'. Again, remember to click 'Add' to register your selection. You can create multiple received items too.

• Cyclical promotions - you should avoid cases where an item can appear on both sides of promotions, as you can have situations where buying one item earns you another for free, and having 'bought' that item then earns you another item for free, and so on. Remember that items can be included in promotions through being in a certain category, as well as by being specifically included.
  
  
• Promotions involving items with different prices - for example, let's say you have a buy one get one free promotion on a product that has four differently priced versions. If a user picks two items, you would typically want to give the cheaper one free. However, if they buy 4 items together, and you just give the 2 cheapest free, it may cost them more than if they made two separate purchases of 2 items (where they could get the cheapest and second most expensive items for free instead of the two cheapest). The logic of dealing with such promotions in the fairest way possible is highly complex and dependent on a number of factors; what seems fair in one situation may well not seem fair in another. It is far simpler to have buy one get one free type promotions only on items of the same price.

We are often asked why we don't add promotional items automatically to the basket, rather than require customers to do this.

There are several reasons. Firstly, a promotion may not give a free item. It may be buy A get 50% off B. In such cases, the user has to decide whether they want the additional item at that reduced price, or not. We cannot automatically decide for them.

Secondly, the promotion may be buy A get B free, but this 'B' might be a product with several versions or be an options product. So we have no way to know which version a user wants, or what options they might want even if we know the item will be free and so they'll almost certainly want one.

In some cases, a promotion may 'gift' a specific version for free, so there is no doubt that a user would benefit from having this item. But for consistency, we don't add it in such cases. The page where the item is, as well as the basket will highlight the promotions that are available on these items, but the ultimate decision to add items to the basket is for the customer, just as it would be in a regular supermarket. If an item is buy one, get one free, a nice cashier (if you can still find a human) might let you know about it if you only have one in your basket. But it's still up to you to go get it - they won't keep them under the till in order to add it for you.

For reference, these are the types of promotion components available:

Part 'A':

Buy [X] of version [V] – e.g. buy 2 barbecue beans, small size

Buy [X] of items from category [C] – e.g. buy 5 items from 'books'

Buy [X] of product [P] – e.g. 1 barbecue beans (any size)

Spend [£][X]

Part 'B':

Get [X] of [V] for free – e.g. get 1 barbecue beans (small size) free

Get [X]% off [V] – e.g. get 10% off barbecue beans (small size)

Get [£][X] off – e.g. get £5 off

Get [X] of [P] for free – e.g. get 1 floor mat (any colour) free

Get [X]% off [P] – e.g. get 5% off 1 floor mat (any colour)

Get [X]% off items from category [C] – e.g. get 15% off any book

Key:

[X] = a whole number

[V] = a specific version of a product

[P] = a product (any version)

[C] = a category

[£] = the default currency (£, $, etc. depending on your store)

Related product links are one-way in that if you create a link from product 'A' to product 'B', there will be no link from product 'B' to product 'A' (unless you create this separately of course). The logic is probably obvious – in the case above regarding batteries, you would not want to visit the battery page and see links to every single electronic item that links to this type of battery.

Single direction links gives you more control and choice than bi-directional links; you can always achieve bi-directional links by adding relationships on both items, if you wish.

Navigate to a product page and click the 'Related Products' tab.

In the text box, start to type the name, or part of the name of the product you wish to create a link to.

A list of products will appear – select the correct one. Then click 'Add New' and it will appear below. You can repeat the same process to relate more products with this one.

You can delete any relationships from the list too.

Don't forget to click 'Save' to store the changes.

Navigate to 'Miscellaneous > Coupons' – you will see a list of previously created coupons (if any), and a link to create new ones.

You can choose the value of coupon discount (fixed amount or percentage), or you can select to link the coupon to any non-live promotion, which will be available only to customers who use the coupon (see @5.2.6. Linking promotions with a coupon for more details). You can also specify the start and finish date of the coupon, and whether the coupon is reusable or not. Coupons that are not reusable will expire when used.

The 'coupon code' checkbox lets you choose whether to enter the coupon code yourself. This way, you can choose something short, memorable and easy to type. This is useful if you create multiple use coupon codes to publish in and advertisement for example.

If you want to create multiple coupons of the same kind in one go, then the store will name them with pseudo-random codes.

You can disable and re-enable any coupons from the listing.

You can delete coupons only if they have not been used. Any coupon that was used for an order is protected from deletion, so the record of it will always remain.

There are 4 stages for orders to move through. These are indicated by 'Order Status' checkboxes when viewing an order in the back end.

• The order has been sent to the store owner – this box is checked when an order is successfully placed. Sometimes we refer to this simply as 'sent'.

• An invoice for payment has been issued – this box is checked manually in the admin section to record that an invoice has been issued to the customer for payment.

• Payment has been received – this box indicates that payment for the order was successfully received. In the case of an online payment, the callback process normally triggers this box to be checked automatically when a successful payment is made.

• The order has been dispatched – this typically signifies that the order process is complete where payment was received via the web site. It is checked manually by the store owner once the order has been shipped. For orders that have been invoiced, this is of course not the end of the order process as payment is still awaited.

• The order has been cancelled (Kartris v2.0+) – checking this box retains the order in the database, but cancels it from order totals and releases any stock items back to the store.
  

In the most common scenario where a customer makes an online payment for the items in their basket, the first three boxes will typically be checked, leaving only the dispatch of goods to be manually changed on the order.

The 'Order Progress' box is normally updated automatically for online payments just to confirm the payment, but the admin user can add extra comments and choose whether to send the status update to the customer by email. This is a useful way of notifying the customers of shipping delays or any other issues that might affect their order. These comments can be viewed from the 'My Account's section if the customer logs in to check the order progress.

There is an 'Issue Invoice' link from each order. This can be used to view a print version of the invoice for printing if you require a customer be sent a print copy with their order, or by post to request payment. Note that viewing or printing this invoice does not automatically check the 'An invoice for payment has been issued' box. That box must be checked manually by the admin user to confirm that the invoice was sent to the customer.

Customers may view invoices from within their 'My Account' section in a print-ready format so some stores may decide to use this as the primary delivery method for invoices and receipts.

• The SKU (version code) for every item must be unique. You cannot have two items in Kartris with the same SKU; if Kartris finds duplicate SKUs, it will either ignore or replace the existing item with the same SKU (depending on settings).
  

• All products must have unique names, because products don't have any SKU (these belong to versions). It is possible to have a product with multiple versions, therefore each line in this case will repeat the product name, but have a different SKU and version name. The Data Tool will assume that any row with a repeated product name is the same product.
  

• All categories must have unique names - the reasoning is similar to the point above regarding products.
  

• Add imported data to existing data and ignore duplicates - do this if your site database data is the 'master' version, and you've made corrections and changes to it, or are just confident existing data is already perfect
  
  
• Add imported data to existing data and update duplicates - in this case, any duplicates in the destination will be updated from the source data
  
  
• Reset database and import - this will clear existing data, and then import the data so you retain no previous data

You can set the Kartris defaults for the meta-tags using the following language strings:

ContentText_DefaultMetaDescription

ContentText_DefaultMetaKeywords

In places where no other data is available, Kartris will fall back on the values here. But in most cases, it will find more page-specific data to use if possible. As mentioned earlier, the meta-keywords tag is not read by Google and most major search engines, so is probably best left blank so as not to increase page sizes unnecessarily.

Kartris will do a fairly good job of filling meta-tags and page title for pages automatically. For example, on a product page, it will use the product name in the title tag, and fill the description with a truncated section of text from the product description. The keywords will generally use the ContentText_DefaultMetaKeywords value.

But you can override these default values in many cases.

For example, when creating or editing a product, category, knowledgebase article or custom page, you can open extra fields with the [+]SEO link. This allows you to override the default values that Kartris will insert, and specify the exact text you want to appear.

This can be useful if you want to keep the product or category name short and concise, but have the page title itself longer and with more keywords to help improve page indexing.

Kartris can format 'friendly' URLs. You may wish to optimize the text/name part of the URL for products and categories using the URL Name box. This allows you to replace the default value (normally the item name) with whatever text you prefer to use.

You should only enter keywords or text here, not full URLs. The values entered are used for the text part of the URL. But the numeric part and file extension are required and cannot be removed.

301-redirects were commonly used as a method of getting the preferred URL indexed by search engines prior to the canonical tag being introduced. The problem with using 301-redirects is that it loses 'location awareness' in a URL. For example, a product 'laptop' can be in multiple categories, and the folder hierarchy in the URL will be different for the same item depending on the route you use to navigate to it.

Using 301-redirects means that end users, as well as search engines, only get to see a single URL, and therefore lose location awareness through the hierarchy and breadcrumb trail.

Using the canonical tag is better because it allows us to pass location specific information through the URL, giving users a clear idea of where the product lies within the category structure, while at the same time notifying search engines that it is a single page, with a preferred URL.

You can turn friendly URLs on or off from the general.seofriendlyurls.enabled config setting.

1. Go to Configuration > Payment and Shipping Gateways and click to edit 2Checkout.
2. For 'friendly name', you can enter '2Checkout', or just simply 'Credit Card'. This is just the name of the payment method that customers will get to choose on the web site during checkout if you have multiple payment methods.
3. Change the status from 'OFF' to 'ON' (for live orders) or 'TEST' or 'FAKE' for testing. 'TEST' invokes a demo order, allowing you to test the full integration and pass multiple orders at zero cost without needing to do refunds. 'FAKE' means that Kartris will skip the 2Checkout site and instead format a post back itself to the callback page of Kartris. This is useful for testing that the callback process works, triggers the appropriate emails and so on without keep having to keep going through the 2Checkout payment process.
4. Set your 'SID', which is the vendor number assigned to you by 2Checkout.

In order to ensure that 2Checkout calls back your Kartris site to notify it that a payment for a particular order was made so that confirmation mails can be sent and the order can be tagged as 'paid', you need to set up a few things within your 2Checkout account.

1. Login to 2Checkout and go to Account > Site Management.
2. The 'Approved URL' will be http://www.mysite.xyz/Callback-2checkout.aspx and the 'Direct Return' should be set to 'Immediately return to my web site'.

2Checkout should now be set up and working. We would advise that you always test a site in live mode when you first open it (status = 'ON') even if all the test modes checked out ok. This confirms that everything is working with Kartris and that your account with 2Checkout is live and working. The best way is to create a low value product of a dollar which you can purchase.

1. Go to Configuration > Payment and Shipping Gateways and click to edit AuthorizeNet AIM.
2. For the 'friendly name', enter the name you want this payment system to be referred to on the front of your site where customers select it, for example 'Pay by credit card with AuthorizeNet'.
3. Change the status from 'OFF' to 'ON' (for live orders) or 'TEST' or 'FAKE' for testing. 'TEST' means that a test order will be passed, allowing you to test the full integration and pass multiple orders and no cost without needed to do refunds. 'FAKE' means that Kartris will skip the AuthorizeNet payment process and instead format a post back itself to the callback page of Kartris. This is useful for testing that the callback process works, triggers the appropriate emails and so on without keep having to keep going through the test payment process.
4. ProcessCurrency - Typically AuthorizeNet accounts are single-currency, so you should enter this as a three-letter ISO code, for example 'USD'.
5. Test URL - (for test orders) should be:
   https://test.authorize.net/gateway/transact.dll
6. Post URL - (for live orders) should be:
   https://secure.authorize.net/gateway/transact.dll
7. TransactionKey - This is the transaction key which is generated on the AuthorizeNet back end system. It is used in the generation of the MD5 hash. If this does not match the one on the back end of AuthorizeNet, transactions will not be accepted by AuthorizeNet.
8. LoginID - Should be provided to you with your AuthorizeNet account details.
9. TransactionType - One of the following (see AuthorizeNet documentation for further details): AUTH_CAPTURE, AUTH_ONLY, PRIOR_AUTH_CAPTURE, CAPTURE_ONLY, CREDIT, VOID
   

1. Go to Configuration > Payment and Shipping Gateways and click to edit AuthorizeNet SIM.
2. For the 'friendly name', enter the name you want this payment system to be referred to on the front of your site where customers select it, for example 'Pay by credit card with AuthorizeNet'.
3. Change the status from 'OFF' to 'ON' (for live orders) or 'TEST' or 'FAKE' for testing. 'TEST' means that a test order will be passed, allowing you to test the full integration and pass multiple orders and no cost without needed to do refunds. 'FAKE' means that Kartris will skip the AuthorizeNet payment process and instead format a post back itself to the callback page of Kartris. This is useful for testing that the callback process works, triggers the appropriate emails and so on without keep having to keep going through the test payment process.
4. ProcessCurrency - Typically AuthorizeNet accounts are single-currency, so you should enter this as a three-letter ISO code, for example 'USD'.
5. Test URL - (for test orders) should be:
   https://test.authorize.net/gateway/transact.dll
6. Post URL - (for live orders) should be:
   https://secure.authorize.net/gateway/transact.dll
7. TransactionKey - This is the transaction key which is generated on the AuthorizeNet back end system. It is used in the generation of the MD5 hash. If this does not match the one on the back end of AuthorizeNet, transactions will not be accepted by AuthorizeNet.
8. LoginID - Should be provided to you with your AuthorizeNet account details

Some configuration to your account must be done at Authorize.Net's Web site (Authorize.Net will have supplied you with access details). This is referred to as Authorize.Net's Merchant Management System. Login at:

https://secure.authorize.net

1. Go to 'Settings and Profile' and select 'Relay Response'. Change this to the callback URL of your site, i.e. http://www.sitename.xyz.com/callback.aspx?g=authorizenetsim.
2. Click on 'Receipt page' and 'receipt method'. This sets the page on your site that a user is returned to after finishing a transaction (normally should be http://www.sitename.xyz.com/checkoutcomplete.aspx)
3. Set the receipt method to 'Link', and text to "Click here to return to the store", or something similar.
4. Go to 'Settings and Profile', under 'Security', select 'obtain transaction key'. Enter your secret answer to obtain your key. This key must be entered in the TransactionKey setting (see 7. above).

• server=1 - this turns on the JSON support in the client, so Kartris can communicate with it
• rpcport=8332 - this defines the port that will be used for remote communication
• rpcconnect=127.0.0.1 - this defines the address at which the client is running; 127.0.0.1 is the default local network address
• rpcuser=Kartris - a username (you can choose your own)
• rpcpassword=ThisShouldBeSecureAndNotThisDefaultOrYouWillGetRobbed - you should define your own password here, don't use our default!!!
• min=1 - this is not essential, it just tells the Bitcoin client to start minimized, preferably if running on your server
• minimizetotray=1 - again, not essential, but preferable as the client starts up whenever the server reboots
  

1. Go to Configuration > Payment and Shipping Gateways and click to edit Docdata.
2. For the 'friendly name', enter the name you want this payment system to be referred to on the front of your site where customers select it, for example 'Pay by credit card, bank transfer or iDeal'.
3. Change the status from 'OFF' to 'ON' (for live orders) or 'TEST' or 'FAKE' for testing. 'TEST' means that a test order will be passed, allowing you to test the full integration and pass multiple orders and no cost without needed to do refunds. 'FAKE' means that Kartris will skip the Docdata payment process and instead format a post back itself to the callback page of Kartris. This is useful for testing that the callback process works, triggers the appropriate emails and so on without keep having to keep going through the test payment process.
4. ProcessCurrency - if left blank, payments will be sent to Docdata and processed in the customer's selected currency. If you would prefer to only process Euros, you can enter EUR, and all orders will be converted to EUR at the rate set in your store at checkout before going to the payment system.
   
5. PostURL_Test - (for test orders) should be:
   https://test.docdatapayments.com/ps/com.tripledeal.paymentservice.servlets.PaymentService
6. PostURL_Live - (for live orders) should be:
   https://www.tripledeal.com/ps/com.tripledeal.paymentservice.servlets.PaymentService
7. MerchantPassword - This is the api key password, not the password you use to login to Docdata's panel.
   
8. MerchantName - The account name Docdata provide to you.
   

1. Go to Configuration > Payment and Shipping Gateways and click to edit GP Webpay.
2. Change the status from 'OFF' to 'ON' (for live orders) or 'TEST' or 'FAKE' for testing. 'TEST' means that a transaction will be sent to the alternative 'test' processing URL, which behaves the same as the main production URL but does not actually bill the card. 'FAKE' is another mode to aid setup and testing, Kartris itself formats an appropriate callback to itself, simulating what the remote side should pass back. It is useful for checking order emails, for example.
3. Most of the settings will correspond to named settings provided to you by GP Webpay.
4. The CertPFXLocalPath setting is the full local path to the .pfx file created as part of the GP Webpay account setup. If this is located on your web site somewhere, you can find the local path of the root of your Kartris installation from Database Admin > Tools. This path value should end with the name of your .pfx file.
5. The CerfPFXPassword is the password associated with this .pfx file, not your account or any other password.
6. The CertCerGPWebPayPublicLocalPath is the local path to the .cer file that contains GP Webpay's public cert. There is a production (live) cert, and one for the test server. Both files are included in the GP Webpay plugin folder for Kartris. You just need to find and enter the actual local path to the right file (muzo.signing_prod.cer for live transactions, muzo.signing_test.cer for test transactions to the test server).
   
7. The ProcessCurrency can be left blank if you want Kartris to use whatever currency the user has chosen on the web site. Alternatively, you can set a 3 letter ISO code such as GBP or USD to force orders to be converted into that currency before processing.
   

1. go to IIS Manager
2. go to the application pool instance
3. click advanced settings
4. Under Process model, set Load User Profile to true

1. Go to Configuration > Payment and Shipping Gateways and click to edit Netbanx.
2. For 'friendly name', you can enter 'Netbanx', or just simply 'Credit Card'. This is just the name of the payment method that customers will get to choose on the web site during checkout if you have multiple payment methods.
3. Change the status from 'OFF' to 'ON' (for live orders) or 'TEST' or 'FAKE' for testing. 'TEST' invokes a demo order, allowing you to test the full integration and pass multiple orders at zero cost without needing to do refunds. 'FAKE' means that Kartris will skip the Netbanx payment page and instead format a post back itself to the callback page of Kartris. This is useful for testing that the callback process works, triggers the appropriate emails and so on without keep having to keep going through the Netbanx payment process.
4. Rather than having an account ID to identify your orders to Netbanx, it has customized payment URLs that include your site or company name. There are both test and live URLs, with the format as follows:
   
   https://pay.netbanx.com/OPsite-name-upp
   https://pay.test.netbanx.com/OPsite-name-upp
   
   Kartris will decide which one to use based on the STATUS setting for this gateway.
   

1. Go to Configuration > Payment and Shipping Gateways and click to edit PayPal.
2. For the 'business', enter the email address of your Paypal account - this is effectively your PayPal user ID.
3. Change the status from 'OFF' to 'ON' (for live orders) or 'TEST' or 'FAKE' for testing. 'TEST' means that transactions will be sent to PayPal's sandbox server. 'FAKE' means that Kartris will skip the PayPal site and instead format a post back itself to the callback page of Kartris. This is useful for testing that the callback process works, triggers the appropriate emails and so on without keep having to keep going through the PayPal payment process.
4. If you have Kartris v2.9 or above, it will automatically determine whether to post to the live or sandbox Paypal server. If you have an earlier version of Kartris (or a Paypal DLL in Kartris earlier than 1.1.0.0) you will need to change the URL setting to the appropriate one for LIVE or test orders.
   
   For live orders:
   https://www.paypal.com/cgi-bin/webscr
   
   For test orders:
   https://www.sandbox.paypal.com/cgi-bin/webscr
   

In order to ensure that PayPal calls back your Kartris site, to notify it that a payment for a particular order was made so that confirmation mails can be sent and the order can be tagged as 'paid', you need to set up a few things within your PayPal account.

1. Login to PayPal and go to My Account > Profile. Then click to view My Selling Preferences (left hand side) and then a bit over half way down, click the 'update' link by 'Instant payment notifications'.
2. The Notification URL should be http://www.mysite.xyz/Callback-PayPal.aspx. The 'Receive IPN messages' radio button should be checked.
3. Back on the My Selling Preferences page, click the 'update' link by 'Website preferences'. Turn 'Auto Return' on, and enter http://www.mysite.xyz/CheckoutComplete.aspx as the 'Return URL'. This will redirect the user back to your site after they complete a payment on PayPal. But it is important to note that the order itself is called back immediately after payment by PayPal's server calling the Callback.aspx page of your site (see 2. immediately above).
4. Set 'Payment Data Transfer' off - we don't need this as we send info via the IPN step in 2. above.

You may find that orders where data submitted contains non-English characters (such as French or German accented characters) generate an INVALID response at PayPal. To fix this:

1. Log into PayPal
2. Go to My Selling Preferences (see above)
3. Click 'Paypal Button Language Encoding' link at foot of page, and then click the 'more options' button
4. Set 'Encoding' to 'UTF-8' 
5. Set 'Do you want to use the same encoding for data sent from paypal to you?' to 'Yes'.
6. Click 'Save' 

Google Analytics ecommerce tracking requires that a client side javascript is run the user's browser when they complete an order. This happens in Kartris on the CheckoutComplete.aspx page right after returning from the payment gateway (see 3. above).

It cannot be done on the callback because that is called by PayPal, not the customer's browser. Unfortunately PayPal puts in a 5-second delay after a completed payment before returning the customer to the store. This inevitably results in some customers dropping out after a successful payment but before they have been redirected back to your site, and hence not being logged by Google Analytics as completed sales. There is no workaround for this; the Google Analytics code can only run on the user's browser; it must run after the payment is complete (otherwise you will log sales as successful that don't complete payment) and PayPal apparently has no way to reduce or eliminate the 5-second delay). This is not a Kartris issue alone; it is an issue with all carts that support Google Analytics when they are set up to use PayPal Web Site Payments Standard.

1. Go to Configuration > Payment and Shipping Gateways and click to edit Realex.
2. MerchantID - supplied by Realex. This is not the merchant number supplied by your bank.
3. SharedSecret - This is supplied by Realex. It is used in the generation of the SHA1 hash. If this does not match the one on Realex, transactions will not be accepted by the gateway.
4. ProcessCurrency - You must set this config setting to the 3 letter ISO currency code of your Realex account. For example, if your account processes Euros, this setting must be set to ‘EUR’. Setting this config setting correctly ensures that all orders will be converted to Euros prior to passing over to Realex. If you don’t set this (and your store supports multiple currencies), you will pass orders in GBP or USD to the Realex gateway, but it assume these amounts are in Euros.
5. AutoSettleFlag - Used to signify whether or not you wish the transaction to be captured in the next batch or not. If '1', then all the transactions will automatically be settled in the next batch. If '0' it means that you will manually settle transactions after the goods have been shipped.
6. URL - address of the secure payment page on the Realex site.
7. ReturnTSS - Use to signify whether or not you want to use Realex’s Transaction Suitability Score. If this is '1', six additional fields will also be supplied to Realex in every transaction (shipping code, shipping country, billing code, billing country, customer id, customer email). Otherwise, set to '0'.

Before you can use Realex’s Realauth Redirect, you must first provide Realex with the URL of your callback page. This should be:

http://www.demo.xyz/Callback-Realex.aspx

(this is URL-mapped to the Callback.aspx file by Kartris)

The response URL is to be mailed to support@realexpayments.com. You can also have an HTML template uploaded to the Realex Payment servers so that the redirection should resemble the rest of the shopping experience (or else it will use Realex’s default template). You can send your template to them via same email address. For further info, check the Realex developer's guide.

In case Realauth is unable to contact your callback page, you can set a static success/failure message. This can be done at Realex's administration web site (Realex will have supplied you with access details).

1. Go to Configuration > Payment and Shipping Gateways and click to edit SagePay VSP Form.
2. For the 'friendly name', enter the name you want this payment system to be referred to on the front of your site where customers select it, for example 'Pay by credit card with SagePay'.
3. Change the status from 'OFF' to 'ON' (for live orders) or 'TEST' or 'FAKE' for testing. 'TEST' means that a test order will be passed, allowing you to test the full integration and pass multiple orders and no cost without needed to do refunds. 'FAKE' means that Kartris will skip the SagePay payment process and instead format a post back itself to the callback page of Kartris. This is useful for testing that the callback process works, triggers the appropriate emails and so on without keep having to keep going through the SagePay test payment process.
4. ProcessCurrency - if your store supports some currencies that your SagePay account cannot process, you should set this with a three-letter ISO code to convert all orders to this currency prior to sending users to the payment pages.
5. Test URL - (for test orders) should be:
   https://test.sagepay.com/Simulator/VSPFormGateway.asp
6. Post URL - (for live orders) should be:
   https://live.sagepay.com/gateway/service/vspform-register.vsp
7. VSPProtocol - SagePay uses a versioning system so that when a newer version of their system is introduced, you can continue to process orders with the older version (at least for some period). The Kartris SagePay support is designed for 'Protocol 2.23', so you should not change this number unless your Kartris payment system is upgraded at some point in the future.
8. The other various SagePay settings required should be supplied to you by SagePay.

1. Go to Configuration > Payment and Shipping Gateways and click to edit SagePayDirect.
2. For the 'friendly name', enter the name you want this payment system to be referred to on the front of your site where customers select it, for example 'Pay by credit card with SagePay'.
3. Change the status from 'OFF' to 'ON' (for live orders) or 'TEST' or 'FAKE' for testing. 'TEST' means that a test order will be passed, allowing you to test the full integration and pass multiple orders and no cost without needed to do refunds. 'FAKE' means that Kartris will skip the SagePay payment process and instead format a post back itself to the callback page of Kartris. This is useful for testing that the callback process works, triggers the appropriate emails and so on without keep having to keep going through the SagePay test payment process.
4. ProcessCurrency - if your store supports some currencies that your SagePay account cannot process, you should set this with a three-letter ISO code to convert all orders to this currency prior to sending users to the payment pages.
5. VSPProtocol - SagePay uses a versioning system so that when a newer version of their system is introduced, you can continue to process orders with the older version (at least for some period). The Kartris SagePay support is designed for 'Protocol 2.23', so you should not change this number unless your Kartris payment system is upgraded at some point in the future.
6. The other various SagePay settings required should be supplied to you by SagePay.

1. Go to Configuration > Payment and Shipping Gateways and click to edit Secure Trading.
2. For 'friendly name', you can enter 'Secure Trading', or just simply 'Credit Card'. This is just the name of the payment method that customers will get to choose on the web site during checkout if you have multiple payment methods.
3. Change the status from 'OFF' to 'ON' (for live orders) or 'TEST' or 'FAKE' for testing. 'TEST' invokes a demo order, allowing you to test the full integration and pass multiple orders at zero cost without needing to do refunds. 'FAKE' means that Kartris will skip the Secure Trading site and instead format a post back itself to the callback page of Kartris. This is useful for testing that the callback process works, triggers the appropriate emails and so on without keep having to keep going through the Secure Trading payment process.
4. 'Required Fields' should be set to 'name,email'.
5. 'CallbackID' should be set to 1 if you only have a single web site. If you use your Secure Trading account with multiple web sites, you can number each of them.
   
6. 'SiteReferenceID' should be set to the values provided by Secure Trading.
7. 'Password' is an arbitrary password you use to protect the callback process; it should match the one set up in the callback.txt file (see @17.17.2. Setup within Secure Trading).
   

1. Go to Configuration > Payment and Shipping Gateways and click to edit RBSWorldPay.
2. For the 'friendly name', enter the name you want this payment system to be referred to on the front of your site where customers select it, for example 'Pay by credit card with WorldPay'.
3. Change the status from 'OFF' to 'ON' (for live orders) or 'TEST' or 'FAKE' for testing. 'TEST' means that a test order will be passed, allowing you to test the full integration and pass multiple orders and no cost without needed to do refunds. 'FAKE' means that Kartris will skip the WorldPay payment process and instead format a post back itself to the callback page of Kartris. This is useful for testing that the callback process works, triggers the appropriate emails and so on without keep having to keep going through the WorldPay test payment process.
4. ProcessCurrency - If your WorldPay account can process orders in all the currencies you have available for customers to use on the site, then you can leave this blank to process the order in whatever currency the customer is using. If you cannot process all the currencies available, you can convert all orders to a specified currency at checkout. The total will be shown to the user in both currencies, with an explanation. For example, setting this to 'GBP' will convert all orders to British Pounds at checkout.
5. Test URL - (for test orders) should be:
   https://select-test.worldpay.com/wcc/purchase
6. Post URL - (for live orders) should be:
   https://secure.worldpay.com/wcc/purchase
7. AuthMode - This should be set to 'A' to authorize and bill transactions or 'E' to just authorize and hold funds (useful if you wish to do further fraud screening before accepting the payment). You will need to contact your WorldPay representative to set this facility up. Transactions can only be held unbilled for a few days before they lapse - see WorldPay’s documentation for further information. If you just hold transactions, you must login to your WorldPay admin area and manually choose to bill a transaction.
8. InstallID - WorldPay will give you a unique number for your installation, which needs to go here.
9. CallbackPassword - This value should match the password you set within your WorldPay account (see below)

1. Check the 'Payment Response Enabled' box.
2. Enter the 'Payment Response URL' as http://www.yoursite.xyz/Callback.aspx?g=rbsworldpay&d=off
3. Check the 'Enable Shopper Response' box. This will show a text version of the order on WP.
4. If you want to have a standard looking WorldPay confirmation page, uncheck the 'Enable Shopper Response' box. You can then customize the page returned using resultY.html and resultC.htm pages.
   http://www.worldpay.com/support/kb/bg/customisingadvanced/custa7105.html

The knowledgebase features can be turned off (so they are hidden on the front end of your site) using the frontend.knowledgebase.enabled config setting.

To access the knowledgebase features in the back end, go to 'Support > Knowledgebase'.