Select Installed > Visual Basic > Web > Previous Versions from the left hand panel.

Then choose ASP.NET Empty Web Site in the main content area, and choose a name and location for your project. The version of the framework isn't so important, as that should be set later when we pull the files in. But you must have at least .NET 4.6 installed.

Next, remove any files and folders that Visual Studio 'helpfully' adds to the web site, so it really is empty.

Select Tools > NuGet Package Manager > Manage NuGet Packages for Solution.

Click the 'Browse' link/tab, then type 'Kartris' in the search box. You should find the Kartris package.

Click to select this, then check the box to install to the project you've just set up. Click the Install button.

Visual Studio will show you a list of dependencies. Click OK to proceed with the installation. You will also need to approve some licenses for dependencies. The required Kartris files will then be downloaded to your web.

In Visual Studio, click to run the web site. You will get a warning that there were errors (this is because we don't yet have a database). Click YES to run the last successful build. You should see the setup routine in your web browser.

Follow the steps through. You will get to a step that lets you setup a database. Specify the path to your SQL Server, choose a database name and select that this is a new database, and Kartris can create and populate this for you. The checkbox to add demo data adds a few sample products and orders, which make it easier to test the basic features, and can easily be deleted later.

Installing the database can take a few minutes. Once done, you should see the admin account details that the setup routine created for you. We suggest you make a note of these now somewhere safe. You can change the password later if you wish, from within the Kartris back end.

Once you get to the end of the setup process, you should see two links, to access the front and back ends of Kartris.

The setup routine will make changes to the web.config file, to include the connection string to the new database and some other minor changs.

Our site downloads page has links to download the latest zip:

https://www.kartris.com/t-Downloads.aspx

The software itself comes as a zipped file.

If you want to obtain the very latest up-to-date code, you can go to the source repository on Github (this may contain development code, unfinished work, bugs and other issues, so the version zips on our downloads page are strongly recommended).

https://github.com/cactusoft/kartris

Nothing important here, it is just an intro screen.

For security, Kartris secures passwords for both admin and user accounts by "hashing". For a new installation, just click to proceed here and accept the new random hash salt value we've created.

For more information about Kartris's password security, see @18.4. Password security‍ .

We need to set up the connection with the database.

If the permissions are right, Kartris will connect to your database, run any setup scripts to create the database structure and stored procedures, and will generate an admin login. Copy and paste these details somewhere so you can access the store when setup is complete. You will be able to change the admin password or create other admin user accounts later.

Kartris should automatically pick up the web address you're using. You can also choose a tax regime and default currency.

The install routine will check write permissions to ensure it can operate properly. These permissions are required to ensure you can upload images, and logs of errors can be created, for example.

The install routine will show you the changes it will make to the web.config in order to set the database connection up. It will also change the resource provider (via the globalization tag) so the software will use the database for language resources rather than the file which is used by the install routine.

If Kartris cannot write/modify the web.config file, it will give provide a link for you to download the new edited file. You will then need to load this to your site, via FTP or just copying and pasting (on a local site). You may need to restart the site if the file is locked. Generally the site will restart after the web.config is updated.

If all went ok, you should see a link to the front end back ends. It may be a little slow the first time you access Kartris after it is first installed, or the server restarts. But once loaded, it should be responsive and fast.

User accounts can be restricted using the permissions checkboxes so that they can only access certain areas in the back end. The back end is divided into four broad areas:

• 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

This permissions structure serves two purposes. Firstly it allows you to prevent certain users from being able to make major changes to site settings, or products, for example, while allowing them to process orders. Secondly, it simplifies the back end somewhat by removing extraneous menus for users who do not need them.

Once you have located a config setting, you can click to edit it. Be extremely careful to ensure that you do not set config settings to an invalid value. This can cause errors in the operation of Kartris. Great care should be taken to double check values being changed before you click to submit any changes.

It is also possible to change config setting values directly in the tblKartrisConfig table of the database. However, the new setting will only take effect after the site is restarted (this is because the actual config setting values that Kartris uses are stored as application variables which are built when the application starts from the database values - updating config settings through the Kartris back end also triggers a rebuild of these values).

The possible values are:

• EU
• US
• Canada
• SIMPLE

The tax settings of your store depend to a large degree on where you are based.

To simplify matters, Kartris features a 'Regional Setup Wizard' (found within the 'Regional Setup' menu). This walks you through some simple questions and then sets up the various tax settings for you, including determining which countries/states are activated and set to have tax charged to them.

Note that the tax regime used is hardcoded in this wizard. That's because it uses the tax regime specified in the web.config file, which is generally set when the store is first set up.

See @3.5.1. Tax regime‍ for more details.

This provides an easy way to clear data related to products, orders or sessions. For each type of deletion, the system knows which tables should be cleared.

This provides an easy way to run a query against the database. You can user SELECT, INSERT, DELETE or UPDATE queries.

SELECT queries will return results in a tabular format.

This gives an overview of your database, and lets you back it up. Note that this fires the backup facility within MS SQL server. It does not enable a remote backup. You should discuss with your hosting provider about the best way to obtain an off-server back up of your MS SQL database.

The page shows the root of the current web, which can help you format the correct path to create the backup file in the correct location within your web in order to let you download it with FTP.

Kartris keeps logs of certain actions by admins such as logins and changes to config settings. This can be useful when diagnosing problems that you suspect were caused by admins changing settings.

The sort criteria for items is set at the parent. If you want certain products to show in a particular order, you must set this at the parent category of those products. First you set the criteria by which products will be sorted:

Sort Products By :

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

The last one of these should be selected if you wish to manually sort the products into exactly the order you required.

You also need to set a sort direction:

• Ascending
• Descending

For example, sorting by 'Product Last Modified Date' and sort direction 'Descending' will show the most recently edited/added products first.

Alternatively, from v2.9014 onwards, you can also drag and drop sort too.

The sorting of categories is conducted in a similar way to sorting products; subcategories sorting criteria is controlled from the parent category.

Top level categories are always manually sorted. You can click the 'view categories' toolbar button and then change the sort order of categories with the up/down buttons to the left hand side of each category.

Alternatively, from v2.9014 onwards, you can also drag and drop sort too.

On sites with fewer than 25 option groups, when you view the options tab under a product, all the options will be shown.

On sites with 25 or more option groups, only the option groups which have been selected for this product are shown, and they are collapsed by default. They can be opened to view the option values with the overlapping squares icon. Once expanded, there are two links to quickly select or deselect all the option values.

Once you have created options, you can choose to convert the options product to a combinations one. Click on the 'option combinations' tab. For more detail see @4.1.4.4. Combinations product.‍ 

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.

The object config system is a way of storing extra settings at product, version or category level, which can be edited from the item's page in the back end. These are kind of like config settings, but they apply just to a specific product or version.

Where 99 is the database ID of the product, version or category that the object config setting is for.

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.

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.

You can see and also adjust the status of any order by changing the status checkboxes and saving:

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 interface lists all the customer groups, and has special links to 'affiliates' and 'mailing list', which are special built-in customer groups.

One of the common requirements of an online store is to hide certain categories and products from all but specific customers. When editing a category, product or version, you will see a dropdown menu selection for 'Limit by group'. In this way, you can link a category, product and/or version to a specific group. In this case, only customers who are logged in to the front end and are members of the appropriate group will be able to see these items. Other customers will not see them, or be able to find them in searches.

Although you can set a % discount at customer level, you may find that this does not give you the direct control you need. You may want to individually price certain items for a specific group, so for example it might be $15.00 for retail customers, or $13.25 for wholesale clients.

Kartris has a tab under versions labelled 'Customer Group Prices' where you can override the price of any version for each customer group. Leaving the price at zero for any group will mean that the item for that group will be at normal price (and not zero!).

Of course, this functionality can enable you to have customer-specific prices too - you can create a customer group and assign just one customer to it, and then set prices for that group.

You can set a % discount for each customer if you wish. This will apply a % discount to the value of all items within the order, excluding shipping, handling and any other costs. This is in addition to any customer group discount applied so care should be taken to not give double-discounts inadvertently.

In Kartris, passwords are hashed for additional security. This means that the raw password is not stored in the database; instead, a function called a 'hash' is used to scramble the password, and this scrambled value is stored. When a customer logs in, the password they give is also scrambled and then compared to the stored scrambled password to make sure they match.

Because the raw password is not stored, the system cannot send the password to the customer as a reminder because the hash is not reversible. Similarly, you cannot find the password of a customer or an admin from the back end, or even by looking directly into the database.

Therefore if a customer loses or forgets their password, it must be reset. There are two ways to do this (1) the store owner can change any customer password from the back end (2) the customer can request a password change from the front end.

In the second case (online request to change password), the customer will be sent a link to the email address of their account that is valid for a limited period (1 hour) and that will allow them to reset their password.

There is no way for a customer to change their own email address in Kartris. The email address is assumed to be unique, and therefore we use this as the username. To avoid various issues with changing email addresses (including verification of the new account to ensure that its owner accepts the change and the problem of existing accounts), we have made changing email addresses a back-end only feature at present. If a customer needs to change their email address, then their only option is to contact the store owner so that an admin can change it for them.

The Kartris back end will check that the email address is not already in use (you cannot have two accounts with the same email), but it will not check that the owner of the new email address consents to the change (i.e. that the person making the change owns the new account), or that someone requesting the change (by telephone or email) is actually the owner of that account.

Most payment gateways have a setting 'AuthorizedOnly'. If checked, this means that only customers whose accounts have the 'Approve for special payments' box checked will see this payment option at checkout. This is most commonly used for payment methods you may want to restrict to trusted customers, such as 'PO_OfflinePayment' (where a customer can order goods without a credit card and the invoice is sent to them for payment later).

If the 'AuthorizedOnly' box for a payment method is not checked, then this payment option is available to all users.

If the 'AuthorizedOnly' box for a payment method is checked, but the user is not approved for special payments, they will not see this option at checkout.

When an account is created, Kartris will store the current language in the account record so that it can be used for any communications later. It is also useful to know the preferred language in case you need to contact a customer about something.

Kartris operates a strict 'opt-in' mailing list. This requires not just that someone sign up to the mailing list (including by clicking a link in the 'my account' section or checking a box during checkout), but also that they respond to the confirmation email that is sent automatically, by clicking the link within it.

A customer/user record can be an affiliate if two conditions are met:

1. The 'IsAffiliate' box is checked – the customer can set this by applying to become an affiliate through the 'my account – affiliate referrals' section, or you can set it manually.
   
   
2. The affiliate commission is set above 0% - this can only be done by a store admin on the back end of Kartris. In this way, each affiliate must be manually approved by an admin before their relationship with the store is confirmed and active.

One approved as an affiliate, a user can see their status change in the 'my account – affiliate referrals' section. They are presented with a link such as: http://www.demo.xyz/?af=123

The 123 is the customer/user ID number, and can be passed to the home page.

When a new customer follows an affiliates link to a store powered by Kartris, the store sees the affiliate ID and records this in the customer's session. A 'hit' is also recorded, indicating that the link resulted in a customer visiting the site.

If the new customer goes on to make a sale, two things happen.

Firstly, the new customer's record is permanently tagged as 'belonging' to the affiliate who referred them.

Secondly, the affiliate will be credited with commission for this order, which will be the % of the total value of the order minus shipping, and any discounts.

If a new customer's record was tagged as belonging to a certain affiliate as described above, then if the return at any time in the future to make further orders, the affiliate will receive commission on these too.

If an existing customer who does not belong to any affiliate follows a referral link and subsequently makes a purchase on this visit, they will from that point on 'belong to' the affiliate whose link referred them. The affiliate will receive commission for this sale and any future sales made to the same existing customer.

It is not possible for a customer to 'belong' to multiple affiliates. Therefore, a customer who 'belongs' to a certain affiliate will remain as such regardless of whether they follow any other affiliate's links in future.

The original affiliate will receive any commissions on sales to a customer who they referred originally, even if that customer has followed another affiliate link on subsequent visits.

This is to ensure that affiliates cannot be 'poached' later to deny the original affiliate credit for a customer they referred.

A store owner may have external advertising or links that contribute traffic to his or her site. Advertising networks such as Google Adsense provide fairly detailed information on click-throughs, and even conversions when coupled with Google Analytics. However, sponsored links or forums or blogs may harder to track.

It is therefore possible to use the affiliate system to track such links, but setting up each link as a separate affiliate. This will require either using bogus email addresses, or setting up multiple new addresses. But it will mean that you can then ask your partners to use a specific URL you give them, so all incoming traffic, and the sales generated can be monitored.

Affiliates can view both hits and sales that resulted from their referrals from the 'my account – affiliate referrals' section on the front end.

Store admins can view similar information by going to 'Affiliates > Affiliate Stats'.

Payment information to the affiliate can be viewed from the 'Payments' link from the customer record in the customer listing. This will show the affiliate's total commission earned, and the value of any payments made to them.

Any commissions earned that have not been paid yet will be listed. If you pay a commission (or issue a coupon for it instead, if your terms are to pay commissions as discount coupons instead of as cash), you can check the box next to the commissions paid and click the 'Set as Paid' button. A payment for the total amount will appear below, while the commission records will disappear. If you make a mistake, or cancel a coupon/payment, just select 'Mark as Unpaid', and the commissions will be unpaid again.

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.

This list is by no means exhaustive, but is a useful guide to the pitfalls and problems that can arise with promotions:

• 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 @7.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 a number of config settings relating to reviews which control how the system works.

frontend.reviews.autopostreviews
Whether to automatically set 'reviews' to live on the site. If 'n', then reviews must first be checked on the backend and set manually to live. It is highly recommended that you don't turn this feature on, in order to prevent spam or malicious postings.

frontend.reviews.dateformat
The format to use for displaying the date of a review on the front-end. You can see a full list of the formats you can use here: Microsoft Docs: Custom Date and Time

frontend.reviews.emailnotification

Whether to send the store owner an email when a new review is submitted. New reviews will show up in the 'to do list', but it can be nice to get an email alert as soon as a new review comes in if you want to ensure you can check and approve them quickly.

frontend.reviews.enabled

Site-wide change of whether to enable customer reviews - If turned on (y), this can be customized on a per-product basis.

frontend.reviews.limit

Limits the number of reviews to show on each product - e.g. 3 will only show the 3 latest reviews. Set to 0 for no limit. This is useful if your site receives a huge number of reviews, but in most cases, 0 (no limit) should work fine.

frontend.reviews.permission
Set who is allowed to add reviews to products. 'All' allows all site users to add a review; 'customersonly' only allows logged in customers; 'purchasersonly' only allows logged in customers who have purchased the product via your store.

frontend.reviews.ratings.enabled

Whether to enable customers to add rating with product reviews - 'y' to allow, 'n' to turn off, and 'r' to make them a required field (in which case there is no 'no rating' option to customers).

frontend.reviews.ratings.maxvalue

Maximum on rating scale for reviews (e.g. 5 will give the user a 1-5 selection). Unless your site is a Spinal Tap-themed amplifier store, there will be no obvious reason to change this. You should also not change this once your site has reviews, as the scores users gave will no longer make sense against a new maximum value.

frontend.reviews.title
Whether to enable customers to add a title/summary on product reviews - 'yes' to allow, 'no' to turn off titles, and 'required' for titles required (customer must enter a title).

The default web_menu.sitemap file code looks like this:

Note carefully the structure; siteMapNodes with children such as ~/Customer.aspx are not self-closing - they have a separate close tag after the children. Child nodes like ~/Wishlist.aspx are self-closing (they have a / before the closing of the tag).

The $resources refer to language strings (see @15.2. Language strings‍). If your site only uses a single language, you can add links that have hardcoded text instead of references to language strings, for example:

The Data Tool requires CSV or spreadsheet data to be suitably formatted for import. A sample spreadsheet with some correctly formatted data is included in the data tool zip, or you can download it below.

In order to import bulk data from a spreadsheet, the Data Tool needs to make some assumptions.

• 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.

The Data Tool can be used both to populate a brand new store with product data and to update an existing store. In cases where you are updating a store, there are three options as to how you handle existing data already in the store:

• 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

The original approach to providing support for mobile devices was to create a separate interface, and have the web site check the user-agent of the device requesting the page to decide which version of a page to send. But with the rise of smartphones as perhaps the most common web accessible device, and the increase in power allowing them to run full web browsers with javascript and web standards support, the responsive approach has become the norm.

A responsive web site sends exactly the same pages to all devices - mobile, tablet, laptop and desktop. It is the device itself which decides how to display the page, based on rules and code that is embedded within the page.

The advantages of this approach are:

• Single set of interface code to create and maintain
  
  
• Richer experience - full feature set (since not using a separate cut-down interface) and same styling and feel as the main site (because they are essentially the same site with some minor tweaks)
  
  
• The interface can be adjusted for a variety of devices of various sizes; for example, tablets can use the chunkier touch-enabled navigation menus while still formatting pages for the larger screen space
  
  
• Same URLs for mobile and desktop - since all clients get the same page, there are no separate URLs for the mobile site; this has search engine benefits and also benefits customers who sync bookmarks between their desktop and mobile browsers (because the same URL will work from both devices, but the pages will format appropriately for each device)

Kartris is designed to run on a single domain. If multiple domains are mapped to the same web, Kartris will 301-redirect any requests to the domain set in the general.webshopurl config setting. This helps channel page rank and links towards the preferred domain.

For example, many sites have both domain.xyz and www.domain.xyz pointing to their site. Kartris will redirect to the preferred one of these if someone uses the other one where necessary. While this has no real impact from an SEO point of view (there really aren't the duplicate content issues as we'll cover later), it does ensure that all users are using the same domain always, which is important for cookies.

For more information on config settings see @3.4. Config settings‍.

Meta-tags are three common HTML tags that appear in the 'HEAD' section of the HTML code of most pages:

The 'title' tag contains the text that will display at the very top window bar when the page is open in a browser. It is also the page title that a search engine will typically show as the main hyperlink in its search results.

The meta tag for 'description' gives a summary of what the page contains. Typically this will be the additional test just under the hyperlink in a search engine result.

The meta tag for 'keywords' contains extra keywords that are relevant to the page but is not displayed in search results, and is not read by Google and most search engines. So we tend to leave this blank.

Because Kartris forms pages around a standard template, these tags are not present in the template; instead the tags are created dynamically by Kartris for every page.

One frequent point that SEOs raise is the so-called 'duplicate content penalty'. The claim is that having a page accessible with multiple URLs will harm search engine ranking, or even (according to some SEOs) have you booted from Google for spamming.

In reality, as the official Google blog makes clear (see link below), you will not be penalized for this. In fact, Google will even do a good job of recognizing multiple URLs that point to the same page, pooling them and their page rank.

http://googlewebmastercentral.blogspot.com/2008/09/demystifying-duplicate-content-penalty.html

But in order to eliminate any doubt, Google, Microsoft (Bing) and Yahoo all now recognize the 'canonical' tag. This lets you specify within the source of a page which URL that page should be indexed as. So even if it is reachable through multiple navigation routes, you will tell Google the preferred URL to use. Kartris forms canonical links automatically within pages, so you don't need to activate anything in this regard.

Google's official position is that it takes the canonical tag as a strong hint, rather than obeying it absolutely.

On database driven applications like Kartris, a single page such as Product.aspx is used to display every single product in the store. Since extra information needs to be passed to it to tell it which product to display, the URLs (web addresses) typically contain extra parameters and values passed to the page.

For example:

http://www.demo.xyz/Product.aspx?ProductID=10

As more information is passed, the URL can become longer and messier.

To overcome this, Kartris at default creates 'friendly' URLs, which appear like static page addresses (rather than a single page with dynamic information passed to it as parameters). When properly configured, this will make the site appear (both to users and search engines) as a collection of 'static' pages in a folder hierarchy, just as if every product was on its very own page and these pages were sorted into folders.

Despite what many SEOs believe, there is little if any evidence that the format of the URL has any influence on search results (though it may well have done many years ago). Google's official blog says that it doesn't, and even goes as far as to suggest not rewriting URLs.

The format of Kartris's 'friendly' URLs still includes numbers, just before the .aspx at the end. It is not possible to remove this as the numbers are used by the system to locate the content. This is very similar to the URL format used by Amazon and the BBC, that uses numbers within a static format of URL.

Being database-driven, the Kartris language provider is very efficient. However, to improve performance even more, language strings are cached because in most cases they change very rarely. If you change a language string, you may find that the change does not appear immediately, even if you rebuild the caches with the button above the left hand category menu. In this case, you can force the language strings to be rebuilt by restarting the site. This can be done from the back end home page.

The easiest way to add a new language is to import it through the Data Tool. See @10.4. Importing language packs‍ for more information.

If you later upgrade Kartris, you may find that new English language strings were added, but that your other languages lack these records. This can be addressed through the languages page - see @15.1. Languages and email setup‍ 

Once you have 'fixed' the other languages so that they have the same number of strings, you may need to translate those new English strings into the desired language. This can be done from this section. You can choose the target langauges, and filter records to find the strings you need to translate, then enter the new values.

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 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 Opayo 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 Opayo test payment process.
4. ProcessCurrency - if your store supports some currencies that your Opayo 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://sandbox.opayo.eu.elavon.com/gateway/service/vspform-register.vsp
   
6. Post URL - (for live orders) should be:
   https://live.opayo.eu.elavon.com/gateway/service/vspform-register.vsp
   
7. VSPProtocol - Opayo 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 Opayo support is designed for 'Protocol 3.00', so you should not change this number unless your Kartris payment system is upgraded at some point in the future.
8. The other various Opayo settings required should be supplied to you by Opayo.

All the required information to process an order and direct the callback back to your store is actually posted through to Opayo with the order, so no further setup is required at their end. However, you should ensure with Opayo's support that your account is live before you start processing orders.

Go to Configuration > Payment and Shipping Gateways and click to edit PaymentSense.

Enter the various acccount details given to you by PaymentSense. You may have both test and live account details, so ensure you don't mix these up. We suggest first configuring the test details, setting the status to 'test' in Kartris (this will only show the payment option for PaymentSense at checkout if you are logged in to the site as an admin) and then running through some tests with the test card details available from PaymentSense.

In older installations (up until Kartris v2.9012), the hashmethod was hardcoded into the plugin as MD5. From v2.9013 onwards, the default is SHA1, though this is changeable through a new setting called HashMethod, within the PaymentSense settings in the Kartris back end.

The PostURL may be different depending on which processor you signed up from. This is the location of the payment form on the vendor's site where the user is redirected in order to make payment.

See PaymentSense's own documentation regarding setup within their admin area.

Make sure that the hashing type matches the Kartris plugin version you are using. You can check the version of the DLL you have by navigating to it in Windows explorer, right-clicking and choosing 'properties', then viewing the details tab. Newer versions of Kartris also show this DLL version number within the list of payment systems.

If it's the older DLL (v1.x), then you should use MD5. If it's the newer v2.x DLL (introduced in Kartris v2.9013) then use SHA1 (if using this version, your Kartris should have a 'HashMethod' setting withing the PaymentSense settings).

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' 

We advise doing this even if you're in the US or UK, as it's quite possible you'll have customers with names and/or addresses either domestically or overseas that contain non-English accented characters.

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.

See also .

In order to configure Kartris, some values will need to be obtained from QuickPay. These are

• Merchant ID (a general ID applicable to the customer's QuickPay account)
• Agreement ID (an ID for the specific agreement within the QuickPay account - a merchant may have several)
• Agreement API Key (a key used for hashing values for each agreement, for security)
• Private Key (a key used to hash values to verify the integrity of the callback from QuickPay)

These can be obtained by logging into the QuickPay account control panel as detailed below.

1. Go to Configuration > Payment and Shipping Gateways and click to edit QuickPay.
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 QuickPay'.
3. ProcessCurrency - If your QuickPay 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.
4. PostURL should be set to https://payment.quickpay.net
5. Version should be left as defaulted (most likely v10)
6. 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 QuickPay 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 QuickPay test payment process.
7. MerchantID should be the setting for this field you obtained from QuickPay in @17.17.1.1. Merchant ID‍ 
8. AgreementID and AgreementAPIKey should be the settings you obtained from QuickPay in @17.17.1.2. Agreement ID and Agreement API Key‍ 
9. PrivateKey should be set to the value obtained from QuickPay in @17.17.1.3. Private Key‍ 
10. CallbackURL should be set to [your site URL]/callback.aspx
11. ContinueURL should be set to [your site URL]/checkoutcomplex.aspx
12. CancelURL should be set to [your site URL]/basket.aspx

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 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.19.2. Setup within Secure Trading).
   

In addition to the general settings most gateways have, Stripe requires these particular ones:

To receive notifications from Stripe to your Kartris store, a webhook is required. You should configure this point to [yoursiteURL]/callback-stripe.aspx

You will have to associate at least one event. You should choose "Checkout" followed by checking the box for checkout.session.completed

A webhook endpoint secret will be generated, and you should ensure you add this into your Stripe settings in Kartris. See @17.20.1.3. WebhookEndpointSecret‍ for more details.

This will be called "Signing secret" but you will have to click to reveal it. It should begin "whsec_".

If you are developing and testing locally, Stripe provides a useful tool in the shape of the CLI (Command Line Interface). At time of writing, the latest version is here: https://github.com/stripe/stripe-cli/releases/tag/v1.13.6

Copy the Stripe.exe file to your local machine, and then use a command prompt to navigate to it. If you run your Kartris on Visual Studio's built in server, you can get Stripe's CLI to listen for webhooks and forward them to your local development site's callback page (Kartris will map requests to callback-stripe.aspx to callback.aspx?g=stripe, which tells Kartris which gateway DLL to use for processing the callback). For example, something like this:

The CLI will give you the webhook endpoint secret to use. You need to add this in your settings, see @17.20.1.3. WebhookEndpointSecret‍ 

Once this is set, you can move through your checkout process, select Stripe as payment method, and go through to pay. If you have Stripe set to TEST mode, you will see some dev info on the page before you go to Stripe, and have a checkout button to push. This way, you can view the page source if you need to see what is being posted during development. This page does not show in LIVE mode, Kartris will format the javascript silently and submit it immediately.

You should see the order details to the left, and a payment form to the right. Use the following test card details:

4242 4242 4242 4242
any name

a date in the future

any three digit security code

Stripe should show the transaction as complete and forward you back to your development site.

You should see the order showing as paid in your back end, with the event ID added as the reference code. In the CLI window, you should see some indication that the webhook was triggered and received a 200 ok response.

The full CLI reference is here: https://stripe.com/docs/cli

1. Go to Configuration > Payment and Shipping Gateways and click to edit WorldPay.
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://secure-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)
10. MD5Secret - text between 20 and 30 chars, including at least one upper case letter, one lower case letter, a number and a special character, but no spaces (despite what the WP documentation says!). This needs to match the same specified in your WorldPay account.

1. Check the 'Payment Response Enabled' box.
2. Enter the 'Payment Response URL' as http://www.yoursite.xyz/callback-worldpay.aspx
3. Check the 'Enable Shopper Response' box. This will show a text version of the order on WP.
4. Enter a callback password. This should match the one you specify in your Kartris back end.
5. MD5 secret - this should match the value entered in your WorldPay account.
6. Signature fields - enter instId:amount:currency:cartId
7. 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

If you are updating an existing Worldpay installation, you will need to do the following.

The first step is to check your web site has HTTPS enabled. To do this, simply go to the front page of your site and then edit the address in the browser so it uses HTTPS instead of HTTP. For example,

https://www.demo.xyz/

If you see an error in your browser that the site is untrusted, or that the connection was interrupted, or any other browser error, then SSL is NOT running properly on your site. You should contact the host or your developer if you believe it should be.

Only once you have verified that HTTPS support is setup and working should you attempt to activate the SSL/TLS support within Kartris.

Once logged in to the back end, find the general.security.ssl config setting. There are four possible settings ('always on' SSL was introduced in Kartris v2.7000, 'external' was introduced in Kartris v2.9008).

• 'n' = off
• 'y' = on for pages where sensitive data is transferred (login, checkout, back end, any page when user is logged in)
• 'a' = always on, SSL for all pages
• 'e' = external SSL, applied by a platform like Cloudflare, see @18.1.3. External SSL‍ 

This is the simplest way to add SSL to your web site. You register and set up your domain with Cloudflare.com (or a similar service), then set the nameservers for your domain to point to the ones Cloudflare tells you.

We'd recommend going into the Cloudflare settings and hitting 'pause' so Cloudflare will only serve DNS for the site at first. This will ensure the site continues to work as before (without SSL) until you decide to do the switch. Leave it a day or two, and check that Cloudflare has issued the required secure certificate for your site.

Once it has, you can activate Cloudflare to handle requests for your web site. We suggest for most sites using the 'flexible' SSL setting in Cloudflare, so you can run your web server with just http, which doen't require a secure certificate, and let Cloudflare add the SSL to the front end for you.

Then in the back end of Kartris, you should set the 'general.security.ssl' config setting to 'e' (for external).

Because Kartris will no longer be able to check programmatically if a page is being called with http or https (it will actually think everything is running http, because there is no SSL at the web server itself), you need to add some page rules into Cloudflare to ensure that appropriate redirection occurs. The ones shown below will redirect http requests to https, and also requests to kartris.com to www.kartris.com. The first request bypasses Cloudflare's cache for payment gateway callbacks to Kartris. This is a good precaution to avoid any unexpected behaviour on those such as redirections, which can prevent them working properly.

The first step is to ensure your server has support for TLS 1.2, outgoing, as well as incoming. If you are on a shared server, you should check with your web host. If you have your own server, you will need to check and may have to make registry changes yourself. We found that Windows Server 2008 R2, for example, even with all up-to-date patches on, does not have TLS 1.2 support by default and requires registry changes.

Check the following article for further details:

Enabling TLS 1.2 on Windows Server 2008 R2

From ASP.NET 4.6 onwards, TLS 1.2 is the default. This means if your server has been kept up to date with patches and .NET updates when they've become available, and (if required) has the necessary registry changes (see @18.2.1. Server support‍ above) then it should make outgoing secure connections using TLS 1.2 by default. The easiest way to test this is to simply try switching the web site to ASP.NET 4.6 and then test that it works. To do this, open the web.config file (in the root of the web) and find this code:

and simply change the target framework to 4.6:

Then reload the web site. It will take a few seconds as changes to the web.config will cause the web site code to rebuild. But you should see the web site load up and it should work exactly like it did before the change. If some page error appears, and you're sure the change you made above was done correctly, restore the original web.config file, as it seems your server does not have .NET 4.6.

You can try adding this (or check with your host if on a shared server), and then try the process above again. This avoids any code changes in Kartris.

If you are on a server where you cannot install the newer .NET versions, then you may be restricted to ASP.NET 4.5. This does support TLS 1.2, but it is not used by default. You can force this by adding this code within the Application_Start event in the Global.asax file in the root of the web:

If you are running older versions of Kartris that are still on the ASP.NET 2.x branch (up to 3.5), then it seems Microsoft is rolling out support to these. However, we're no longer providing all payment plugins compiled for this branch, and are not supporting these older sites with updates, so we'd strongly recommend upgrading to the latest version of Kartris.

TLS 1.2 support, including for older ASP.NET versions

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'.

The 'baseAddress' should of course contain the path to your own site's web API.

You can test if the web API is working by calling it as follows (obviously with your own domain rather than ours):

https://www.kartris.com/Protected/KartrisWebApi.svc?wsdl

Once the integration is setup, MailChimp should start recording ecommerce data. You can also set MailChimp to perform other tasks with the data.

When a customer creates an account on Kartris, we now have an extra checkbox signifying acceptance of the terms and conditions. This helps ensure that any time a record for a user is created, there is an explicit confirmation of terms and conditions.

This feature can be turned on or off using the config setting general.gdpr.enabled, though we would recommend it remains on whether you are EU based or not.

The aspect of GDPR that has perhaps been given the most publicity, is that users must explicitly opt-in to receive marketing information. It is no longer considered acceptable to imply consent because a user places an order or creates an account on a web site.

Kartris has always employed best practice with regard to adding users to mailing lists; an email confirmation is sent which the user must respond to by clicking a link, in order to confirm their addition to the mailing list. We have never considered it an acceptable practice to add users to mailing lists other that with an explicit approval, and an email verification to ensure consent is gained from the owner of the email address for this purpose. It also ensures that email addresses cannot be added to the mailing list by third parties, either maliciously, or accidentally (e.g. a typo).

The mailing list approval emails that Kartris sends are formatted using an email template, which you can find in the templates folder of a skin (see the Kartris default skin, if your own skin lacks this). Therefore, we would recommend expanding the text within this template to explain that clicking the confirmation link will give explicity consent to add your email address to the mailing list.

EU data privacy regulations have for many years given the public the right to request a copy of all the data an organization holds on them. The organization was allowed to charge a reasonable fee for this service, typically £10 in the UK or a similar amount in Euros. The nominal fee was in most cases not enough to cover the real cost of providing the data, but was at least a deterrent to spurious and unnecessary requests.

However, the GDPR requires that organizations provide the full data held on an individual free of charge, and within 28 days. This aspect may in time be the most onerous on businesses, though at present it is not getting much attention. While there will undoubtedly be an increase in legitimate, well intentioned requests, it's also possible that requesting data could also become a practice to test or inconvenience companies that consumers may have a dispute or disagreement with. Regardless, the company is compelled to respond.

To make this process as simple as possible from Kartris, we've created a data export button on the customer edit page. If a member of the public requests data, you can extract this from Kartris by simply finding the users record in Kartris with an email search, and then using the 'GDPR export' button.

This will format a plain text file containing all data linked to that email address:

• Customer data
• Street address records
• Details of all orders, including the items purchased in each
• Copies of all reviews submitted by the user
• All wishlists created by the user
• All saved baskets created by the user
• All support tickets created by the user, including full thread discussion

The data is formatted in a fairly raw state, with the database field name (in square brackets) followed by the value. This is to ensure that the user receives the full set of data and no fields are emitted.