| Card Charging |
| Enable Live Charging |
The overall setting to allow your website to process credit card payments. You should always have this set to true once you have set up your Payment Processor. |
| Run In Test Mode |
This means the IRP will mark every transaction as a test transaction. This allows you to quickly clear them out before making your website open to the public. |
| Enable Tokenisation |
This setting enables your Payment Gateway Provider's tokenisation solution, e.g. RealEx Payment's RealVault. Tokenisation means that you do not actually store credit card details in your website database. Instead, these are stored with the Payment Gateway, and you access them via 'tokens' when you want to do something with those cards e.g. process a refund, make an additional charge.
NOTE: Card details are stored against an order when the Application Setting 'Enable Live Charging' is enabled AND the Application Setting 'Enable Tokenisation' is disabled. |
| Allow Charging In Foreign Currencies |
This is the overall setting which allows the system to process payments in currencies other than your default one. Once this setting is on, for each individual currency you wish to process payments in, you need to set its setting to allow this. You will also need to consider how PayPal handles these foreign payments as these will also be processed in the foreign currency. Exchange rates are another factor. The IRP updates all of its currencies using its own web service. This in turn means your prices will vary when the currencies update. It may be worthwhile to manually manage any currency's exchange which you are charging in, to prevent these fluctuations. |
| Auto Settle All Transactions |
This setting means the site will charge for the entire order when it is placed. When this setting is off, the following rules apply:
- If the order is from your country, the website will charge for every item that is in stock on the website. If the entire order is out of stock, it will authorize the card for the ‘Amount To Authorize If Out Of Stock’ setting, to make sure the card is legitimate.
- If the order is from outside your country, the website will charge the entire order if it is in stock.
- If the order is from outside your country, and it has any item that is out of stock, it will authorize the card for the ‘Amount To Authorize If Out Of Stock’ setting, to make sure the card is legitimate.
The IRP does not offer an automatic facility to re-charge for an order once it is approved. You should only turn this off if you plan to manually manage your charging, or have another system which handles your charging for you. We strongly recommend you leave this setting on. |
| 3DSecure |
| Enable 3D Secure |
This overall setting enables 3DSecure on your website. You will also have to enable 3D Secure on each individual card type you wish to pass through 3DSecure. 3DSecure is the overall name given to Visa's 'Verified By Visa' and MasterCard's 'SecureCode' schemes. Its benefit is additional security for you that the cardholder's identity has been verified at the checkout. Enabling 3DSecure at this time is a trade-off - on one hand when customers use it, you can be greatly more confident that the transaction is not fraudulent, but on the other, there has not been widespread adoption by some of the much bigger online merchants, so it can cause confusion and result in less sales. |
| 3D Secure Order Value Threshold |
Check this box to configure the IRP to trigger 3D Secure only for orders over a certain threshold. Note that for this feature to work you must enable the overall 3D Secure functionality on your website using the ‘Enable 3DSecure’ setting and you will also have to enable 3D Secure on each individual card type you wish to pass through 3DSecure (Payment Processing > Card Types > 3D Secure Enabled).
You can also enable or disable 3D Secure for certain countries only. You do this using a setting called ‘Disable 3D Secure’ in the Shipping Countries section of IRP Admin. When you check this box against a particular country, 3D Secure authorisation will not be attempted for orders that are shipped to that country. For more details see Shipping Countries.
Note that if an order is over the '3D Secure Order Value Threshold' value it will trigger 3D Secure, however if the card used is not enrolled in 3D Secure, the 3D Secure screen will be bypassed (you will not see it).
This is also controlled at the Application Setting level with the setting called ‘Live Charging 3D Secure Order Value Threshold’) |
| Keep 3DSecure Failed Orders |
This setting means that the system will keep orders for which the customer has failed 3DSecure verification. You may want to do this when you initially turn it on, to monitor drop outs etc. However, unless you have the resource to manage these orders, we strongly recommend you leave this setting off. |
| Allow 3DSecure 'Unknown Status' Orders |
This setting allows orders to go through if the Card Processor is unable to determine the Customer's 3DSecure status (because, for example, their bank did not respond). Turning it off will dramatically reduce your sales, as, whilst 3DSecure is getting more popular, it is far from widespread. We strongly recommend you leave this setting on.
PLEASE NOTE: Even if you have turned off this, it is still possible that orders go through without Full Liability shift if their cardholder's bank has not made 3D secure a requirement. If you're in doubt about Liability Shift on orders, we recommend you check the '3D secure ECI value' line in the ‘Fraud Indication' dropdown on the order record to ensure that Liability Shift has been granted. You may also want to adjust your 'Fraud Scoring Score For 3 D Secure Eci Value' in Application Settings to allocate more points to 3D Secure orders that do not have Full liability Shift approved. |
| Disable 3D Secure for Repeat Customers |
Check this box to prevent 3D Secure occurring for repeat customers. When this is enabled, 3D Secure will be bypassed for customers who have previously placed at least one successful non-guest order. This setting does not apply to guest checkout orders.
This is also controlled at the Application Setting level with the setting called Live Charging Disable 3D Secure For Repeat Customers (in the ‘Payments - Live Charging’ grouping). |
| 3D Secure Supported / Non-Supported Countries & Card Types |
| Supported / Non-Supported Countries & Card Types |
Use the Enable and Disable buttons to select supported countries and card types for 3D Secure as shown in the following screen capture (hold Ctrl or Shift to select multiple entries):
Non-Supported Countries: The Shipping Countries that 3D Secure is disabled in on your IRP. Disabled countries will not be prompted for 3D Secure Authentication when paying by card.
Supported Countries: The Shipping Countries that 3D Secure is enabled in. Should a customer be paying by card in one of these enabled countries and their other details meet the 3DS criteria, they will be prompted to authenticate their card before their payment is accepted.
Non-Supported Card Types: The Card Types that do not support 3D Secure. Should a customer be paying by card using one of the following Card Types, they will not be asked to authenticate their card prior to being charged.
Supported Card Types: The Card Types that support 3D Secure. Should a customer be paying by card using one of the following Card Types, if the rest of their criteria matches the 3DS criteria, they will be prompted to authenticate before confirming their payment. |
| Redirect Method |
| Redirect Customers To Payment Gateway |
The setting means customers will be redirected to the Payment Gateway Provider to enter their card details. This means you will not be able to make additional charges, or process refunds through the IRP. We strongly recommend you leave this setting off.
For your information, if redirects are enabled, the redirect will happen before any card details are taken. Card details will be taken on the page which the customer is redirected to, then the customer will be redirected back to the IRP. The page the customer is redirected to is hosted by the Payment Processor (for example, Realex). |
