System Operations - Card Integration


A variety of options are available from within Khaos Control to control how your cards are charged:

  • Payment can be taken at time of order, or at time of despatch
  • If your payment provider supports it, we can preauthorise the card at time of order, then authorise the payment at time of dispatch. This provides reassurance that the card is valid and allows invalid numbers to be caught as early as possible, while avoiding actually charging the customer until the items are ready to ship
  • Cards can be charged individually, or batch-charged from within our Invoice Manager if you wish to process groups of orders at once. The point at which the cards are charged is configurable, e.g. before orders are picked, or after picking but before printing shipping labels.
  • Refunds (e.g. due to returned goods) can be made back to the original card in a similar manner
  • We can import payment information from your website - either transaction details (if your website has already charged the card), or card details (if it has just captured the information). This may require integration work with your web developers.

We can also integrate with other providers when necessary!

Please be aware that not all payment providers will support every option (e.g. pre-authorisation), please verify this before selecting which provider to use.

Setting up Card Integration

WARNING icon
WARNING: This procedure requires you to have Admin permission.

Card integration stores various settings in the CardTransaction.ini file, which can be found in the KeystoneSoftware\Applic sub-directory on the network's shared drive (this file should not be edited directly).

To set up card integration, either go to "Authorise Payment" in the sales invoice manager and click "Authorise Payments": if this is the first time the option has been chosen, the integration setup dialog will be shown. If the option has been chosen previously, you can bring back the setup dialog by going to the System Operations menu, and selecting Edit Credit Card Integration settings.

The most important setting in the dialog is obviously the "interface method" which external package you are using to authorise your cards. The other settings are as follows:

  • Interface path : mainly for file-based solutions, this is the folder on your computer to store transaction details. It is possible you may need to choose a network drive if one computer on your network performs authorisation for the whole office. It is required for all integrations, as in test mode this folder will be used for the storage of fault finding information.
  • Merchant Name : usually the login name agreed with the card provider.
  • Merchant ID : usually the account number of your merchant account as set up with your bank.
  • Transaction Description : a piece of descriptive text that the card provider may choose to place on the credit card statement to describe your transactions " for example, you might fill in your trading or business name.
  • Testing (not live) : tick this to run in Testing mode, so no money is actually transferred. Keystone Software and the card providers normally recommend you run in testing mode for as long as necessary until you are comfortable using the card authorisation systems and have solved any issues that arise.
  • CV2 (security code checking) : tick this to pass CV2 (a.k.a. signature or security) numbers onto the provider. This is normally recommended to provide additional security.
  • AAV (address checking) : tick this to pass address information onto the card provider for additional security checks. Most providers will verify the house number and postcode against the cardholder's details to help prevent fraud.
  • Enable Refunds : tick this to allow refunds to be performed from inside Khaos Control. Note you can only refund a transaction that was originally processed using Khaos Control's integration card systems.
  • Timeout (in seconds) : some integration methods allow you to specify a "timeout", i.e. how many seconds to wait for a response from the bank before considering the authorisation failed. The default of 30 is normally safe since the bank would normally respond far quicker than that " 30 seconds would indicate a problem with your equipment or the bank's systems.

Authorising Payments

In order for card integration to work, the order(s) being paid must have a valid card entry against it. When you enter the details of the payment - from the "Payments" tab in Sales Order - you will be able to type in the card information if a card-type payment is selected. Khaos Control will validate the information as it is entered, display the card type (Visa, Delta, etc.) and draw your attention to any required information that is missing (e.g. issue number for certain card types). Once the green "Card OK" tick is displayed next to the details, the card is ready to be authorised.

Card authorisation can either be done from the sales order screen : e.g. when you take the order from the customer, or as a batch process, from the Sales Invoice manager. Where you perform authorisation from depends on how you wish to process the orders;

  • Authorising from the sales order means you could try it while the customer was still on the phone, and hence double-check card details if a problem arose. However, it would delay order entry, especially if the card authorisation systems were busy.
  • Batch authorisation later is more efficient, since orders can be entered without waiting for a response from the bank. It also allows orders to be charged for only goods being dispatched: if you are sending 8 items from an order for 10 items, you could charge only for the 8 going out. This cannot be done at time of order entry, as the exact items being dispatched may not have been determined.
  • As a compromise, you could "pre-auth" at time of order entry and batch authorise later.

A "pre-auth" contacts your payment provider who can verify card details, but does not actually take the money from a customer's account. Therefore you can check you have entered valid details while the customer is still on the phone, but without charging the card instantly: that way, authorisation can be postponed until just before time of dispatch, allowing a more accurate payment to be taken (if orders are part-shipped, or stock availability changes and some items cannot be sent). Note that pre-auth is only available from certain card integration providers and the implementation of the Pre-Auth and the level of checking performed can also vary amongst the providers who support this option. In some cases a shadow can be left on the cardholders account after a preauth has been processed which will expire between 3-10 days after the transaction has gone through.

Authorisation Results

Exactly what Khaos Control does when the card is authorised or fails depends where the authorisation was triggered from, but essentially the effect is the same. When a payment is authorised, the payment details in the sales order turn blue and become read-only. Any invoices associated with the order up to the value of the payment will also be cleared to proceed through to Issue in the invoice manager.

Non-authorised payments mean that an invoice cannot proceed beyond Authorise Payment in the invoice manager. If the payment process was triggered from the invoice manager, successfully authorised payments will move the invoice on to the next section automatically. If the payment was completed from the sales order, the invoice will not have been moved past Authorise Payment automatically, but the system will allow the invoice to pass through the section without being held whenever that invoice is next processed in the manager.

Khaos Control considers an invoice authorised when the authorised payments against it equal or exceed the value of the goods already dispatched and still pending. For example, if a sales order had an authorised payment for £50 against it, the invoice for that order would be considered authorised (i.e. cleared to proceed through to issue) so long as the goods on the invoice were worth £50 or less. If a shipment from the same order to the value of £20 had already been made and issued, the new invoice would only be cleared if it was worth £30 or less. Non-authorised invoices are held in Authorise Payment for further attention.

Additional Options

If an order needs to be marked as cleared despite not having sufficient payments against it, the "Remainder on Account" checkbox on the [ Sales Order | Payments ] tab allows this. If it is ticked, an invoice can proceed through to Issue regardless of its payments.

The "Manual Payments" checkbox on the [ Sales Order | Payments ] tab allows payments for any value to be entered by the user.

There are also options in System Values which control sales payments. The "Take Full Payment" option controls the value credit card payments are initially created with. If "take full payment" is on, when a credit card payment is added to an order, it will be given the value to cover the full cost of the order. If the option is off, however, the payment is added with an initial value of zero when the invoice reached "Authorise Payment" and card authorisation was started, the payment value would be filled in to the value of goods being dispatched. Any further invoices shipping later would trigger additional payments against the same card, for the value of those invoices. Hence you can see that turning "Take full payment" off results in the system charging a card once for each shipment, whereas turning in on results in the card being charged once, for the entire order.

Details Required for Authorisation

Dependent upon the type of card and the card issuer, the data required for authorisation may include:

  • The Cardholder Name as it appears on the card
  • The Card Type (Visa, MasterCard, American Express etc.)
  • The full Card Number without spaces or other separators
  • The Start Date (if printed on the card)
  • The Expiry Date
  • The Issue Number (for some Switch and Solo cards only)
  • The Card Verification Value (called CVV or CV2 value. The extra three digits on the signature strip of most cards, or the 4 numbers printed on the front of an American Express card)
  • The Cardholder's Billing Address, including the Post Code (if you have not already asked for it and stored it in your database)

Notes:

  • Recently there have been a number of changes made to how credit cards are used in an attempt to make the cards more secure. These include the chip-and-pin system and the use of CCV verication. This is a number usually printed on the signature strip at the back of the card. The CCV number actually stands for Credit Card Verification or Card Code Verification number.
  • As this is a number printed directly on the card it is generally used to check that the card is physically in the possession of a person placing an order over the telephone or on the internet. It should be noted that the CCV number is sometimes referred to as the CVV or CV2 " Card Verification Value code and to complicate matters further different card issuers may call the code by a different acronym.

External links

Commidea Card Payment Processing Systems

DataCash Payments Gateway

HSBC e-payments

  • HSBC - Online debit and credit card processing - Secure ePayments

Opayo (formerly Sage Pay) secure online credit card and debit card payment solutions

Stripe

Useful Information


See Also


Did you find this article helpful?