Realex Payments Resource Document. Version: v1.1

Transcription

1 Realex Payments Resource Document Version: v1.1

2 Document Information Document Name: Realex Payments Resource Document Document Version: 1.0 Release Date: 30 August 2010 Legal Statement This guide, in addition to the software described within, is under the copyright owned by Pay and Shop Limited, trading as Realex Payments, and subject to license. The included software may contain and utilise third-party software products. The guide and included software, whole or in part, cannot be published, downloaded, stored, reproduced, transmitted, transferred or combined with any other material, or be used for any other purpose without prior written permission from Realex Payments. All software, trademarks, logos, designs, and websites contained within this guide remain the intellectual property of the respective individual owners and companies. Disclaimer Every effort has been made to ensure the accuracy of information published in this guide. However Realex Payments cannot accept any responsibility for any errors, inaccuracies, or omissions that may or may not be published in the guide. To the extent permitted by law, Realex Payments is not liable for loss, damage, or liability arising from errors, omissions, inaccuracies, or any misleading or out-of-date information whether published in this guide or from any link in this guide. Realex Payments reserves the right to change this guide and the included software without prior notice or consent. Company Information Pay and Shop Limited, trading as Realex Payments has its registered office at Castlecourt, Monkstown Farm, Dun Laoghaire, Co Dublin, Ireland and is registered in Ireland, company number Realex Payments. All rights reserved. This material is proprietary to Pay and Shop Ltd, trading as Realex Payments, Ireland and is not to be reproduced, disclosed, or used except in accordance with program license or other written authorization of Realex Payments. All other trademarks, service marks, and trade names referenced in this material are the property of their respective owners. 2

3 Table of Contents 1 About This Guide Purpose Audience Prerequisites Related Documents Terminology Conventions 8 2 Going Live with Realex Payments 10 3 Your Live Realex Payments Account Resetting your RealControl Password Processing your first transaction Allowing your first transaction to settle 14 4 Card Authorisation Explained What are Card-Not-Present (CNP) Transactions? What is Card Authorisation? The Card Authorisation Process What is Realex Payments Role? Responses to Card Authorisation Requests 20 5 Transaction Settlement Automatic vs Delayed Settlement Automatic Settlement Delayed Settlement How Transaction Settlement Works How Transaction Funding Works 23 6 Credit Card Fraud & Chargebacks An Overview of Card Fraud The Chargeback Process 25 7 Identifying and Managing Fraud Know Your Customer Card & Customer Data Validation Authorisation Results The Card Security Code Address Verification Service (AVS) Cardholder Authentication & 3D Secure 30 3

4 7.7 RealScore - Transaction Suitability Scoring Manually Reviewing Transactions Authorisation Details: Authentication Details Transaction Results: Customer Details Intervening in Suspicious Transactions 38 8 Appendix: Using RealControl Searching for Transactions Manually Searching for Transactions Searching using Searchable Transaction Values The Quick Search Box Advanced Search and Download Search Archives Voiding a Transaction in RealControl Rebating a Transaction in RealControl Refunding a Transaction in RealControl Processing an Offline Authorisation 53 4

5 1 About This Guide This section outlines the purpose and aim of the guide, target audience, any source materials or terminology used, and a general document description. Please note that this document is regarded as confidential and is for customer use only. It has been supplied under the conditions of your paymentprocessing contract. 1.1 Purpose The purpose of this guide is to outline information relevant to merchants new to online payment processing, including information on the authorisation and settlement of credit/debit card transactions, and identifying and managing fraudulent transactions. The document also contains some brief instructional guides for customers new to the RealControl system. 1.2 Audience The target audience for this guide is merchants new to credit/debit card authorisations 1.3 Prerequisites In order to use this guide, you should have experience with and knowledge of the following concepts: Correct use of the Realauth service, as outlined in the Realauth Developer's Guide 1.4 Related Documents In addition to this guide, you can also refer to the following documents in the Realex Payments documentation set for information about the Realauth service: Realcontrol User Guide 5

6 1.5 Terminology The terminology specific to the Realauth application is as follows: Expression Definition Acquiring bank Your bank, with which you have a merchant services contract. Transaction A transaction is a request sent to Realex Payments. Transactions can be used to authorise or refund an amount on a credit or debit card. It can also be used to void or settle an amount on a card. Authorisation /authorise The process of submitting the request to your bank in real time to authorise the payment i.e. mark the funds on the card holders account. Batches The process of collecting all valid authorisations for your account and submitting these to the bank for settlement, to be funded to your bank. Settlement When the acquiring bank (your bank) pay/move the funds to your bank account. Settled Once the transactions have been sent to the bank for settlement they are known as "settled" transactions. Pending All transactions that have not yet been settled: These may be transactions that are: waiting to be settled by Realex Payments automatically (occurs at 12 every night), need to be manually settled by you or have failed or are voided(cancelled) and will not be settled Delayed A delayed transaction is a transaction that will not 6

7 Expression Definition be settled automatically by Realex Payments. This transaction must be manually settled within 30 days on the Realex systems. Please note that you may incur exception charges from your bank depending on how long you take to settle the transaction. Check with your acquiring bank for these terms and conditions when using delayed settlement. Void If a transaction is still pending i.e. not yet settled then it is possible to void it. A void means that the transaction will be cancelled and therefore not settled. A transaction can only be voided when it is pending. Note that the funds are still marked on the card-holders account but will not be debited. Rebate A transaction that refunds monies to the cardholder and will debit your account. A rebate depends on the original authorisation that was processed, and so you do not need the card number to refund the money onto the card. You can rebate up to 115% of the original amount. You can rebate a transaction for up to 90 days from when the original transaction took place. Refund Similar to a rebate, the refund is a transaction that refunds monies to the cardholder and will debit your account. A refund is not dependent on an original transaction and so you will need the card number to process the refund. Online Terminal A facility for processing a transaction online. A section of Realcontrol in which a merchant can process a credit card payment. Account You can have multiple sub accounts set up on your main account. By default you will be set up with a sub account called "internet". You can set 7

8 Expression Definition up further sub accounts, if you want, for example "call centre". Realscore Realex Payment's fraud scoring tool, please see the RealScore User Guide for further information. Declined This is a response that you can receive when a transaction is sent for authorisation. When an authorisation is declined, this means that the issuing bank of the card holder have decided not to allow the transaction to go ahead. Payment will not be taken from the card. Referral A This is a response that you can receive when a transaction is sent for authorisation. When an authorisation receives a Referral A the card has been marked as lost, stolen or cancelled. Payment will not be taken. Referral B This is a response that you can receive when a transaction is sent for authorisation. When an authorisation receives a Referral B, the issuing bank of the card holder will not allow the transaction to go through automatically and is requesting that you call their authorisation centre to process the payment. 1.6 Conventions Realex documentation uses the following conventions: Note: Tips or advice for the user. Caution: Important note. Potential financial impact. 8

9 The following table outlines the main formatting conventions used in this guide: Conventions Description Example Blue Italic or Plain Type Hyperlinks and cross-references For more information see Table 1.n Italics Names of other guides Realauth Developer s Guide Courier New Program code, screen messages, directory files, and file names <comments></comments> Courier New Placeholder for element names, field values, or user input card_holder_name BOLD CAPS Error and warning messages 101 / REFERRAL B 9

10 2 Going Live with Realex Payments Congratulations on going live with your Realex Payments account. The world of online payments can sometimes seem confusing and indeed counterintuitive, so this document has been designed to familiarise you with the concepts relating to card authorisation and settlement, as well as providing some essential information on the management of your Realex Payments account. Selling in a card not present (CNP) environment can bring great rewards, but also carries associated risks. Identifying and managing fraud is an ongoing process which requires that you have robust procedures and policies in place. This document provides some further information on fraud, and outlines essential strategies to minimise your risk. 10

11 3 Your Live Realex Payments Account Your account with Realex Payments is now live and ready to accept transactions. There are a couple of steps that you should now take to ensure that access to your account is fully secured, and to check that your merchant ID number, as configured with your acquiring bank, is enabled and ready to process payments. These steps are outlined below. 3.1 Resetting your RealControl Password RealControl (located at is the administrative facility for your account. Using RealControl, you can view your transaction history; take payments from customers; void or settle pending transactions; process rebates and refunds; and manage all of your payments. It is important that your RealControl account is properly secured. When your account was first configured, you would have received a testing password to be used to access your account. Now that your account is live, this password should be changed to a more secure value to ensure that only authorised people can access the sensitive data pertaining to your account. The process for resetting the RealControl password is outlined in detail below. Note: Should your RealControl password have expired, or if you can t access your account, please contact the Realex Payments Integration & Support helpdesk, who should be able to assist. The Support Helpdesk can be reached via at [email protected], or by phone at (+353) To change your RealControl password: 1. Log into RealControl ( using your current password 2. In the toolbar at the top of the page, select Administration 3. The screen shown below will display by default. 11

12 4. Enter your current Password 5. Enter your new Password and confirm. To change your password successfully, you must use the following criteria: The RealControl Password must: Be at least 7 characters in length; Contain a mix of at least 3 of the following four groups o o o o upper-case letter(s) lower-case letter(s) number(s) symbol(s) You cannot use a password previously used Note: For security purposes your password will expire every 90 days. The number of days that are left before your password will expire is displayed at the top of the screen. Once your password has expired, you will be prompted to change the password to a new value to allow access to the various functions of RealControl. After a period of expiry you will no longer be given this option. Should you be unable to access your account, please contact the Realex Payments Integration & Support Helpdesk, who should be able to assist 12

13 3.2 Processing your first transaction Now that your account has been set live, a test transaction using a live credit card should be processed and allowed to settle successfully to ensure that your merchant ID number, as provided to you by your acquiring bank as part of your merchant services agreement, is fully functional. The section below outlines how a live transaction can be processed using the RealControl Online Terminal to ensure that your merchant ID number is active and correctly configured. Note: Processing a live transaction through the online terminal will allow you to confirm that your merchant ID number is active and fully functional, but will not test any of the functionality of your integration to Realex Payments. If using the Online terminal or Virtual Terminal only to accept payments, the steps outlined below should be sufficient to confirm that you are ready to take payments. However, if you have integrated a website or some other remote system into your Realex Payments account, it is important that you process a live transaction through this system also to ensure that the integration is fully functional. To process a live transaction using the Online Terminal: 1. Log into RealControl ( using your current password 2. Select the option "Online Terminal" from the main menu to display the screen below: Action given on how to proceed Change account 13

14 3. If you want to select a particular sub-account, choose the account from the dropdown list at the top of the screen. Note: The mandatory fields are marked with a star; these are required for authorisation. The rest of the fields are for your own reporting purposes 4. In the Order ID field, enter the order ID. This is a mandatory field and must be unique for every transaction 5. In the Amount field, enter the amount. This is a mandatory field. The amount field should not contain any decimal point all transaction amounts processed through the system are processed in the lowest denomination of the currency, eg 1000 for an amount of In the Name field, enter the credit card holder name. This is a mandatory field. 7. In the Security Code field, enter the three or four digit security code found on the back of the card. 8. In the Issue No field, enter the issue number (if processing a UK Domestic Maestro transaction) 9. The Autosettle box should be left ticked to ensure that the transaction settles automatically. 10. Click the Process button to complete the transaction The transaction result will be displayed in real time at the top of the screen. The expected result for a successful transaction would be Processed Successfully, highlighted green in the Result field. Note: Should your transaction be declined highlighted red in the Result field then a second, different card number should be attempted. If this transaction is also declined, then this may indicate a possible configuration issue with your merchant ID number. Should this occur, please contact the Realex Payments Integration & Support Desk for further assistance. 3.3 Allowing your first transaction to settle For testing purposes, your first transaction has been processed with automatic settlement enabled. The settlement process is outlined in further detail in Chapter 5 of this document. 14

15 Because your test transaction has now been authorised but not yet settled to the bank, it can be found in the Pending Section of RealControl. Settlement takes place at around midnight of each night, depending on the acquiring bank with which you have signed your merchant services agreement. Once the transaction has settled, the transaction will be automatically moved to the Batched section, where it will be assigned to a batch of transactions. Generally speaking, each batch corresponds to one day s worth of transactions. To ensure that the merchant ID number is fully functional, you should check to confirm that your transaction has migrated successfully to the Batched section of RealControl overnight. You should also check your bank account to ensure that you have received your funds. Funding generally takes between 3-5 working days from the initial authorisation, depending on the terms of your merchant services agreement. Note: Should the funds not appear in your bank account, or should the transaction not migrate to the Batched section of RealControl, please contact the Realex Payments Integration & Support Helpdesk for further assistance Once your transaction has settled and you have confirmed that your funds have been received, you can process a rebate on the transaction to credit the funds back to your card. Rebating transactions is outlined in further detail in the Appendix of this document. 15

16 4 Card Authorisation Explained When taking credit or debit card transactions in a Card Not Present (CNP) Environment, it is important to have a good understanding of the card authorisation process and the role that Realex Payments play in that process. A thorough understanding of that process will assist you to implement robust policies that can assist you in identifying and managing fraud where and when it arises. The Authorisation process is examined in the following sections. 4.1 What are Card-Not-Present (CNP) Transactions? When taking payments by credit or debit card, two kinds of transaction are defined by the banking industry and the card schemes: Card Present Transactions Card Not Present Transactions Most card holders will be familiar with the more traditional Card Present (CP) transactions. CP transactions are those where the cardholder is present with their physical credit or debit card. To complete the sale the card is inserted into a card terminal to read the customer s data from either the magnetic strip or the chip-and-pin device. In many countries, CP transactions require that a secret pin code be entered to authenticate the transaction, or alternatively the customer is required to sign a receipt to authenticate a transaction. The customer may be asked to produce identification to prove that they are in fact the cardholder. Due to the fact that the customer is physically present with their card and they have authenticated their transaction either by entering their pin number or signing for the transaction, the transaction is considered to be largely non-reputable, i.e. the customer cannot easily claim at a later date that they did not authorise the payment to be taken from their card. Card-Not-Present (CNP) transactions are all those transactions where the customer is not physically present with their card, and it is these kinds of transactions that Realex Payments exclusively deals with. CNP transactions can come in a variety of different forms: Internet (or E-Commerce) transactions Mail Order transactions (Known as MOTO) Telephone Order transactions (Known as MOTO) Fax Order transactions 16

17 In all of the cases described above, the customer provides their card information, but at no point is the card itself produced. Because the cardholder is not physically present with their card, it is not possible to confirm the identify of the customer using any of the means described above (although there are alternative means which can be used, and which are discussed later in the document). Merchants therefore need to be particularly careful when processing CNP transactions because in the event of the fraudulent use of a card, the legitimate cardholder can repudiate the transaction. Note: When processing in a CNP environment, the merchant is always ultimately liable for any chargebacks that result from the fraudulent use of a card. 4.2 What is Card Authorisation? Card Authorisation is the process by which the customer s card details are validated and where their account is checked to ensure that there are sufficient funds to complete the transaction. Credit card authorisation is a complex process that involves a number of stakeholders. When processing a card transaction through Realex Payments, the card details are sent first to your acquiring bank who in turn forwards the details to the customer s card issuing bank via the card schemes. Despite the complexity of each transaction, the authorisation process itself is completed in real time and takes no longer than 3 to 4 seconds to process. Note: The card authorisation process is distinct from the transaction settlement process, in which transactions are actually funded. That process is outlined in more detail in Section 5. When authorising a credit or debit card transaction, a number of key card details are used to identify the customer. These are: The Credit Card Number The Card Expiry Date The Card Security Code (the three or four digit code usually located at the back of the card) Any Address Data provided for Address Verification (where supported) The Credit Card Number itself may be any length from digits. The first six digits of the card number are known as the BIN or Bank Identification number this identifies the card type (e.g. 4 for Visa and 5 for Mastercard) and the bank that issued the card. The Card Expiry Date is always in the form MMYY. The Card Security Code (variously referred to as the CSC, CVV and CV2) is usually 17

18 three digits long and located on the back of the card. American Express cards have a four digit CSC number which is located on the front of the card. It should be noted that the only information guaranteed to be used in the authorisation of a card transaction is the Credit Card Number. The expiry date is usually, but not always, checked. The Card Security Code may be checked, but providing an incorrect Card Security Code will not always result in a card being declined. Note: While Realex Payments require that a cardholder name be entered to complete every transaction, this information is gathered for reconciliation purposes only and is not used in any way in the authorisation process itself. The name provided by the customer may not match the name present on the card itself. 4.3 The Card Authorisation Process The diagram below shows the transaction flow for a standard credit or debit card transaction, outlining each of the key stakeholders in turn. The card authorisation process is outlined below: The Cardholder makes a purchase via the Merchant s (your) website. To pay for the purchase, the Cardholder enters key card details which identify their account. 18

19 The Merchant passes the customers card details to Realex Payments for processing Realex Payments process the card details provided to your acquiring bank, the financial institution with which you have signed your merchant services agreement. The acquiring bank checks that the transaction is allowed under the conditions of that agreement The card details are processed, via the Card Schemes, to the bank that issued the customer s card, the issuing bank. The issuing bank is identified based on the BIN Range of the card number provided. The Issuing Bank is the only authority who has access to the customer s bank account details. The customer s card details are validated, and the customer s account is checked to determine if there are sufficient funds to cover the cost of the transaction. If the details are correct, and there are sufficient funds to cover the transaction, an authorisation code is returned to Realex Payments granting authority to draw down the funds at a later date. A hold is placed on the funds on the customer s card to prevent the account from being overdrawn. The Transaction Result and Authorisation Code (where applicable) are returned by Realex Payments to the merchant. The transaction is now ready to be settled and funded. 4.4 What is Realex Payments Role? Realex Payments is a Payment Gateway that provides an interface for merchants who wish to take credit or debit card payments. We connect merchants into the banking networks to allow them to seek authorisation on card transactions. There are many different banking institutions worldwide, all of whom who use different payment processing architectures to allow for the authorisation of card transactions. Realex Payments certify with acquiring banks to provide a single interface via which these payment networks can be accessed. The advantage of this to you, as a merchant, is that they you operate independent of specific bank configurations should you choose to change your bank you do not have to rebuild your systems to connect into a new bank as the technology interface would remain the same. Realex Payments also provide a suite of reconciliation and fraud management tools which give merchants total control and visibility over the transactions that are processed through your account. Realex Payments also handle the settlement of files and funds to your chosen acquiring bank, an automated process that requires no intervention from you. Settlement is discussed in more detail in the following section. Note: Realex Payments do not authorise card transactions. Transaction authorisation is provided by the bank that issued the customer s credit card in conjunction with your acquiring bank. Realex 19

20 Payments do not have access to any of the customer s personal details and have no visibility on customer s card details or credit status. Realex Payments cannot determine why a particular transaction has been authorised or declined this information can only be provided by the issuing bank to the cardholder themselves in correspondence with industry standards and the relevant data protection legislation. 4.5 Responses to Card Authorisation Requests There are a number of possible responses to a card authorisation request that are used by Realex Payments and these are outlined below. The merchant will only receive funds for successfully authorised transactions. As such, goods should only be shipped or services provided where the transaction has been confirmed as authorised. 00: Transaction Authorised Successfully. Transactions that return a result of 00 have been authorised by the bank and will be funded to the merchant once the transaction has been settled. 101: Transaction Declined. Transactions that return a result of 101 have been declined by the bank. While the most common cause of a declined transaction would be where insufficient funds exist to cover the cost of the transaction, other reasons may apply. The issuing bank cannot divulge the reasons for a declined transaction to anyone other than the cardholder themselves. No funds will be received for declined transactions. 102: Transaction Declined Pending Offline Authorisation. The transaction in question has been declined by the bank, but the merchant is given the opportunity to complete the transaction by contacting their acquiring bank s offline authorisation centre to get an authorisation code, which can be entered via RealControl to complete the transaction. No funds will be received unless this step is completed. 103: Card Reported Lost or Stolen. The transaction in question has been declined because the card number provided has been reported as lost or stolen. No funds will be received for the transaction. 200/205: Bank Communication Error. Realex Payments have been unable to connect to the bank to carry out the authorisation. This is not a reflection of the customer s credit status the transaction may be tried later and may succeed. No funds will be received for a transaction which returns a 200 or 205 error code. 20

21 5 Transaction Settlement As noted above, each card transaction is comprised of two stages. Card authorisation (a real time process) has been discussed in the previous section. Card Settlement the process by which authorised transactions are settled to the bank for funding is a distinct process which typically takes place once a day. All transactions which have been authorised and are ready for settlement will be sent to the bank at the end of each business day so that the bank can arrange for transaction funding. Note: It is important to note the distinction between settlement and funding. Settlement is the process by which Realex Payments create and send a file of transactions to your acquiring bank for funding to take place. Funding is the process by which the acquiring bank request funds from the customer s issuing bank and credits those funds to your account. Realex Payments do not handle transaction funds at any point in the process. 5.1 Automatic vs Delayed Settlement Realex Payments provide support for two settlement options automatic and delayed. When a transaction is sent to Realex Payments for authorisation, you can choose how the transaction should be settled by setting the Auto Settle Flag appropriately. For more information on how this is done, please consult the RealAuth Developer s Guide (located at The difference between the two settlement options is discussed below Automatic Settlement Automatic settlement means that the transaction, once authorised, will be automatically settled to the bank at the end of the business day, with no further intervention required from you. Realex Payments will automatically add the authorised transaction to the first open batch of transactions, or create a new batch if one is not already open. This batch file will then be processed to the bank at the end of each day. Automatic Settlement is the most popular option in use by merchant s who use Realex Payments as it requires the minimum of intervention from the merchant. An automatic settlement transaction, once authorised, can be found in the Pending Section of RealControl, under the Next Batch section. Once the transaction has settled, the transaction can be found in the Batched section of RealControl. The Batched section of RealControl will contain a 21

22 single entry for every day on which transactions were authorised. The batch itself can be explored to see the transactions that it contains Delayed Settlement Delayed Settlement means that the transaction, once authorised, will not automatically settle to the bank. Further intervention is required by you to settle the transaction, either by clicking the Settle button in RealControl or by sending a remote settlement request. Once the transaction has been manually settled it will be added to the next open batch for settlement, or a new batch will be opened if one is not open already. This option is primarily used by merchants who wish to check if a particular product is in stock before debiting funds from the customer, or where manual intervention is required before fulfilling potentially fraudulent orders. A delayed settlement transaction can be found in the Pending section of RealControl, under the Delayed Settlement section. Note: A delayed settlement transaction must be settled within 30 days of the original authorisation or else the authorisation will expire. If the authorisation expires, the card will need to be reauthorised to claim the funds. 5.2 How Transaction Settlement Works Whether a transaction has been authorised using automatic or delayed settlement, the settlement process itself remains the same. Once the transaction has been authorised (or once a manual settlement request has been processed) the authorised transaction is added to what is known as a Batch File. This is a file of all authorised transactions that have yet to be settled. Realex Payments send this batch file to your acquiring bank at the end of the business day the acquiring bank confirm the validity of its contents and then arrange with the issuing bank for funding to take place. Should any issues arise with any of the transactions contained within the batch file, the acquiring bank will inform Realex Payments, who will in turn inform you. Note: Transaction authorisation does not guarantee settlement. While in the majority of cases the merchant will receive funds for an authorised transaction, a transaction can still be rejected by the bank at settlement. 22

23 5.3 How Transaction Funding Works Transaction Funding is the process by which funds for an authorised transaction are transferred from the customer s bank account to your bank account. This is handled entirely by your acquiring bank once the batch file has been delivered, Realex Payments play no further part in this process. However, a brief overview of transaction funding is provided below to complete your understanding of the process. Understanding transaction funding is essential to understanding transaction chargebacks (discussed in more detail later in Chapter 6 of this document). A transaction carried out between a customer and a merchant using a credit or debit card is not as straightforward as it may first appear. While it is intuitive to think of the transaction as being the analogue of a cash transaction customers paying cash to a merchant in exchange for goods and services this does not reflect the reality. The transaction in fact is carried out between the merchant s acquiring bank and the customer s issuing bank. A credit card is a physical representation of an agreement between the cardholder and the bank that issued the card. The issuing bank provides a line of credit to the customer the customer undertakes to pay their bank for any funds provided to them, with interest charged at an appropriate rate. A credit card is essentially a loan. When a transaction is funded, the issuing bank pays the merchant s acquiring bank for the transaction. The acquiring bank in turn funds the merchant, while the issuing bank expects their customer to pay them back for the funds that they have provided on their behalf. Each transaction is in effect three smaller, and in many ways unrelated, transactions: Between the cardholder and their issuing bank Between the issuing bank and your acquiring bank Between your acquiring bank and you. As the cardholder owes money to their issuing bank, and not to you, the cardholder has the right to dispute any charge attributed to them. This is known as a chargeback. If the chargeback is upheld, the issuing bank will request that the funds be returned to them by your acquiring bank, who will in turn withdraw the funds from your account. 23

24 6 Credit Card Fraud & Chargebacks When selling in a customer not present environment, your business will be exposed to the risks of fraud. Each payment method and each channel brings its own level of risk and hence exposure. In order to address these risks, controls are required. With these controls additional costs can emerge, all of which should be taken into account when deciding upon your online payments strategy. Fraud is an issue that must be managed. 6.1 An Overview of Card Fraud Card Fraud is the process by which a cardholder s account details are compromised by a third party who then uses those details to pay for goods or services without the legitimate cardholder s knowledge. There are many common routes by which card details can be compromised card details may be stolen from improperly secured merchant websites, they may be harvested using sometimes sophisticated phishing scams, or they may be accidentally leaked by organisations. The compromise of card details often occurs without the knowledge of the cardholder, the merchant or the bank that issued the card, at least until the card is ultimately used in a fraudulent transaction. It is often difficult to discover the source of the compromise card details may be hoarded for weeks or months before being used fraudulently. It is not always necessary for the card details to be compromised in the first place. Card numbers can be generated programmatically based on existing card details, which can in turn be used fraudulently. If card numbers are generated in this way, the fraudster will need to test the generated numbers for validity on a soft target. This is a process known as carding and often affects merchants who do not have an in depth sign up process in place for customers to progress through before being given access to the card authorisation system itself. Charities are often particularly affected by this behaviour. Unfortunately card fraud is a reality when taking card payments and it needs to be managed. There is no silver bullet to eliminate fraud entirely however, by implementing robust policies you should be able to limit your exposure. It should be remembered that fraudsters are generally looking for a soft target, so by demonstrating a commitment to combating fraud, you can usually discourage fraudulent activity on your account. 24

25 6.2 The Chargeback Process As noted earlier, cardholders have the right to dispute charges that appear on their statement. When a charge is disputed, the chargeback process is initiated. A customer may charge back a transaction for a number of reasons for example, if the goods or services that they have received are not as described or are faulty, in line with their statutory rights. However, the most common form of chargeback arises due to fraudulent activity on the customer s account. Your acquiring bank must notify you in writing of any chargeback that has been instituted on your account. You are usually given fourteen days to dispute the chargeback. It is strongly recommended that you dispute chargebacks in every case if you do not, the funds will be withdrawn from your account without any further notice. It should be noted that customers may accidentally charge a transaction back as being fraudulent they simply may not recognise the charge on their statement. To help prevent this, you should try to highlight to a customer what the narrative that appears on their bank statement is going to read. When disputing a chargeback, you should provide as much documentation as possible to back up the legitimacy of the transaction for example, receipts, s exchanged with the customer, details of phone conversations etc. Once the card issuer has received these details they will investigate the customer s claim and rule on whether the chargeback should be upheld or not. It should be noted that the onus of proof always lies with you as the merchant if you cannot mount a sound defence of the transaction s legitimacy, the issuer can be expected to uphold the chargeback. It is important to note that if a chargeback for a fraudulent transaction is upheld against you, you must carry the ultimate liability for the transaction. This can have a serious impact on revenue, as you may have already delivered the goods or services related to the transaction this means that you effectively take a double hit, losing the value of the transaction and the goods themselves. As such, it is strongly recommended that where fraud is suspected that the transaction in question be rebated immediately. 25

26 7 Identifying and Managing Fraud Unfortunately, there is no "silver bullet" to eliminate fraud, but following some basic guidelines should allow the merchant to minimise their risk. At Realex Payments we have used the fraud funnel to help identify the controls needed at each stage. As a rule, you should: Gather as much information as possible (without compromising on the sales process); Ensure validation checks are completed on all accounts and (not just) card number data; Consider the implementation of authentication processes such as 3D Secure (Verified by Visa and MasterCard SecureCode). As well as reducing risk by way of liability shift these processes can reduce the cost of processing in terms of merchant services fees. Analyse and score all transactions for potential fraud, look through automated blacklists/white-lists, match the data (IP addresses, country of issue) and explore patterns of activity. No single check will confirm fraud but each can lead to better identification of potential fraud Always seek authorisation as this confirms funds are available and where possible include the security code (usually 3 or 4 digit) and address check (where applicable); Manually review transactions where necessary Awareness and understanding of the chargeback management processes is important. This understanding combined with an analysis of the data can help to reduce chargebacks. On an ongoing basis you should review your transactions for other patterns, study any fraud that has occurred in the 26

27 past and use this to update the rules and processes that they have in place to detect fraud in the first place fraud management is an ongoing process and not a once off implementation. 7.1 Know Your Customer It is important to know and understand your customers to assist in identifying potentially fraudulent transactions when and where they arise. A transaction which falls well outside the range of expected values, in terms of customer or transaction profile, can often be strongly indicative of attempted fraud any such transaction should be flagged for manual review and rebated immediately if deemed suspicious. It is important to understand who it is that you are selling to. For example, are you selling to businesses or consumers? What localities do you expect to do business in? Will you only ship within your own country, or internationally? Having a clear idea of your customer profile will allow you to quickly spot any anomalies that may arise. It is important to gather as much customer information as possible in the sign up process so that it can be quickly established if a new customer matches the expected customer profile if not, any transactions processed by the new customer can be flagged for review. Providing a sign in facility may also encourage repeat custom a repeat customer can generally be assumed to be less of a risk than a new one, and it is much easier to dispute a chargeback that arises where the customer has made a purchase in the past. Similarly, it is also important to understand your transaction profile. What is your expected average transaction value? What is your expected average transaction volume? Merchants who are new to CNP transaction processing can often get stung by a chargeback where the value of the transaction is much higher than the average transaction value. A good rule of thumb is that if it seems too good to be true, it probably is. 7.2 Card & Customer Data Validation Card Details are subjected to multiple levels of checks to ensure validity. Firstly, all card numbers processed through Realex Payments are subjected to what is known as a Luhn Check. The Luhn Check is a mathematical algorithm that determines the correctness of card numbers. If the card number provided does not fulfil the requirements of the Luhn check, the transaction will be automatically rejected without being sent to the bank for processing. 27

28 Similarly, Realex Payments require that a card type be provided for all transactions. If the card type provided does not match the card number provided, the transaction will be rejected without being sent to the bank. As outlined in the sections above, data associated with the card is checked by the issuing bank when authorising a transaction. The validity of the number itself is checked, and the expiry date provided is usually (though not always) confirmed against the validated card number. Finally, where supported, the issuing bank will also confirm the Card Security Code Value and Address Verification Value provided against the bank s records. More information on Security Code checking and AVS are provided in the following sections. It should be noted that all of the above information can be obtained by fraudsters, and so relying on card authorisation alone may not be sufficient to effectively identify fraudulent transactions. As such, it is important that Customer Data Validation, as well as Card Data Validation, be carried out. Key questions that should be asked include: Do the billing and shipping address provided by the customer match one another? Does the shipping/billing address match the issuing country of the card itself? Does the shipping/billing address match the IP address from which the customer made their purchase? Has the customer provided legitimate, verifiable contact details? For example, has the customer provided a landline phone number or a mobile phone number? The latter is much harder to trace and verify. Similarly, has the customer provided a free address such as those provided by Yahoo, Hotmail or Google? Does the address provided match the name provided? Free addresses are very easy to come by and almost impossible to trace. Some of the parameters above are discussed in more detail in sections 7.8 and 7.9 of this document. 7.3 Authorisation Results It is very important that orders only be fulfilled where authorisation has been provided by the cardholder s issuing bank to draw down funds to cover the transaction cost, ensuring that the merchant will be funded for their transaction. Different banks return different results indicating the success or failure of an authorisation request. Realex Payments provide a single set of result codes 28

29 and map the results returned by the bank to the appropriate code. These codes are outlined in Section 4.4 of this document. 7.4 The Card Security Code The Card Security Code (variously known as the CSC, CVV or CV2) is the three digit number printed on the back of most standard credit/debit cards (on American Express cards the CSC is a four digit number and is found printed, not embossed, on the front of the card). The Card Security Code is not encoded on the magnetic stripe which carries all other relevant card information, and the CSC cannot be digitally stored by any party other than the bank that issued the card, in accordance with card scheme rules. As such, the CSC represents a kind of digital signature it cannot be skimmed from the card itself, and so it was argued that a customer who could provide the CSC could be confirmed as being in physical possession of the card. In practice, the CSC is not as effective as a digital signature, as was initially envisaged. The CSC can easily be stolen through the use of phishing or other social engineering scams, much in the same way as any other details associated with the card. As such, the CSC is not widely used in the authorisation of card transactions, and providing an incorrect CSC will not necessarily result in the card being declined. However, even if not used to decline transactions, the issuing bank will return a result indicating whether the CSC was checked in the authorisation process, and if so, if it matches the details on record with the bank. This result will be returned to you along with the transaction response, and is stored in RealControl alongside the transaction details. A summary of the CSC check result is shown in the table below. Result Message M Security code Matched N Security code Not Matched I Security code Not checked due to problem U Security code Not checked as Issuer not certified P Security code Not Processed 29

30 7.5 Address Verification Service (AVS) In the UK, some issuing banks support validation of the billing address provided by the customer as part of the sign up process. This is known as the Address Verification Service. AVS uses the combination of the numbers from the customer s street address alongside the numbers from their post code to validate the address provided. It should be noted that an unmatched AVS check will not result in a transaction being declined. However, the result of the check will be returned to you in the transaction response and will be stored alongside the transaction details in RealControl. This information can form an important step in reviewing potentially suspicious transactions. For more information on implementing Address Verification, please see the relevant section of the RealAuth Developer s Guide located at The possible results of an AVS check are detailed in the table below. Result Message M Data Matched N Data Not Matched I Data Not Checked U Unavailable P Partial Match Note: AVS checking is currently only supported for customers in the United Kingdom. It is not supported for customers in any other country or region. 7.6 Cardholder Authentication & 3D Secure It is very important to understand the difference between Card Authorisation and Cardholder Authentication and the implications that this distinction has for fraud and chargebacks. The card authorisation process is outlined in Section 4 of this document. Card Authorisation is the process of validating card information provided by the customer during the payment process, the end result of which is the provision of authority to you, the merchant, to draw down funds from the customer s account to cover the cost of the transaction. It is very important to understand that this 30

31 authority comes from the bank that issued the card and not from the customer themselves. The customer retains the right to dispute any charge attributed to them, as outlined in Section 6, above. Cardholder Authentication is the process of authenticating an authorisation attributed to a customer, i.e. proving that the customer and the cardholder are the same person. In more traditional card present transactions, Cardholder Authentication is provided by having the customer either enter their PIN or by signing their receipt, and can be further confirmed by asking the customer to produce identification confirming them as the cardholder. This process is more difficult in Customer Not Present transactions, and so more care must be taken. Traditional methods can be used for example, delivering goods by courier and requiring the customer to sign for the delivery, or requesting a scanned copy of some identification proving that the customer is who they say they are. This information can be invaluable in successfully contesting chargebacks that may arise on your account. However, it should be remembered at this point that the cardholder name provided by the customer is not checked during the authorisation process, and so an informed fraudster can easily get around such checks. As such, it is worth considering the implementation of a cardholder authentication scheme such as 3D secure to ensure maximum protection against fraud. 3D Secure, implemented by the card schemes as Verified By Visa and Mastercard SecureCode, is a customer not present cardholder authentication scheme. Where implemented, the customer is required to authenticate their transaction by providing a secret password known only to them and their bank. By implementing 3D Secure on your account, you can fully authenticate the cardholder and avail of a shift in liability for chargebacks that arise on transactions under certain circumstances, even where the cardholder is not enrolled for 3D secure. While 3D Secure cannot and does not eliminate chargebacks entirely, it does vastly reduce the incidence of fraud on accounts where properly implemented. You can find out more information about RealMPI, Realex Payment s implementation of the 3D secure scheme, by reading the relevant documentation located on our Resource Centre at or by contacting the Integration & Support Helpdesk at [email protected] 31

32 7.7 RealScore - Transaction Suitability Scoring If you process a high volume of transactions, manually reviewing each transaction may introduce unnecessarily high administrative overheads. As such, it is worth considering the implementation of RealScore, Realex Payments proprietary Transaction Suitability Scoring tool, to automatically identify transactions which require manual review, thus streamlining the process. Transaction Suitability Scoring is the process by which each transaction is assigned a score based on transaction data, merchant defined blacklists and historical transactions. RealScore provides you with the tools to screen and sanity check the data contained within a single transaction and compare the transaction data with historical data to identify potentially suspicious transactions for manual review. For more information about RealScore, please see the relevant documentation located on our Resource Centre at or by contacting the Integration & Support Helpdesk at [email protected] 7.8 Manually Reviewing Transactions RealControl ( stores a number of details pertaining to both authorised and declined transactions which can be used to identify possible fraud on your account. You can use these features to review transactions where fraud may be suspected to assist you in your decision to fulfil the transaction. It is recommended that transactions should be rebated immediately where there is a strong suspicion of fraud to prevent a chargeback arising. Note: RealControl only captures data relating specifically to the transaction authorisation itself. Any other data, such as the customer s shipping/billing address or specifics relating to the order itself, should be captured by your own system and used in conjunction with the RealControl data to identify suspicious transactions. The details for an authorised transaction are shown in the screenshot below. 32

33 This screen is subdivided into three sections, the contents of which are examined in detail below: Authorisation Details Authentication Details (only visible where 3D secure has been implemented) Transaction Results Customer Details Authorisation Details: This section details the amount and currency of the transaction, the sub-account through which it was processed and the date and time on which it was authorised. This section also displays searchable, merchant provided data, detailed below. Customer Number: This field is a custom field containing merchant provided data which can be used to track transactions processed by customers. This is a searchable field clicking on the magnifying glass or on the number itself will show a list of all transactions processed under this customer number. This field can be used, for example, to quickly identify a repeat customer or a new customer. Product ID: Similar to the customer number, this is a custom field containing merchant provided data. This is a searchable field. 33

34 Variable Reference: Similar to the customer number, this is a custom field containing merchant provided data. This is a searchable field. Comments: The Comments fields are provided to allow you to capture data specific to a transaction which does not necessarily fit into the three categories detailed above. It should be noted that the comments fields are not searchable fields Authentication Details Where RealMPI (3D Secure) has been properly implemented on an account, the Authentication Details section will display the result of the cardholder authentication request. These fields are detailed below. Please note that this service is not implemented by default and requires configuration. It should also be noted that implementing 3D secure may required additional development work. For more information on RealMPI (3D Secure) please see the relevant documentation available at or contact the Integration & Support Helpdesk at [email protected] CAVV: The Cardholder Authentication Verification Value effectively a receipt confirming the customer s authentication status. If this value is not present, then this transaction was not authenticated and may not offer a shift in liability. XID: The Exchange Identifier a unique reference identifying the authentication request. If this value is not present, then this transaction was not authenticated and may not offer a shift in liability. ACS URL: The URL provided by the cardholder s issuing bank which was used to allow cardholder authentication. ECI: The E-Commerce Indicator a flag which confirms the authentication result and the presence of a shift in liability for the transaction. If this value is not present, then this transaction does not offer a shift in liability. 34

35 Enrolled: Confirmation of the customer s enrolment in the 3D secure scheme. Status: Confirmation of the customer s authentication status Transaction Results: This section captures the result of the transaction along with the results of any additional checks performed such as Address Verification. All fields are detailed below: Result: The transaction result, i.e. whether the transaction has been authorised or declined. Orders should only be fulfilled where transactions have been successfully authorised. Authcode: The authorisation code returned for the transaction. The authorisation code essentially represents a receipt confirming the authorisation status of the transaction. It should be noted that in certain rare cases an authorisation code may be returned by the bank for a declined transaction in these cases, the result field should always be used to confirm the status of the transaction. Message: A clear text message describing the status of the transaction authorisation. These messages vary depending on the bank that issued the card. The message is provided for information purposes only the result code should, in all cases, be used to confirm the status of the transaction. Pasref: An internal Realex Payments reference identifying this transaction in the database. Transaction ID: A second internal Realex Payments reference identifying this transaction in the database. 35

36 Suitability Score: If RealScore is implemented, the Suitability Score field will contain the overall transaction suitability score returned for this transaction. The magnifying glass icon can be clicked to view the scores for individual RealScore rules which are used to make the total score. Where RealScore is properly implemented, a low score would indicate a potentially suspicious transaction which should be investigated further. Note that RealScore is not enabled on accounts by default, and requires some configuration for further information, please contact the Integration & Support Helpdesk at [email protected]. In Batch: The batch in which this transaction was included for settlement. Clicking on the batch number will show all transactions which were settled as part of the same batch. If no batch number is displayed, this would indicate that the transaction has yet to be manually settled (where delayed settlement is used) or was declined by the bank. Security Code Result: The result of the check on the card security code. The full list of possible results is detailed in Section 7.4, above. It should be noted here again that a transaction may not be declined if the security code provided does not match that on record with the bank that issued that card. If a result of N is returned, this indicates that the customer provided the incorrect security code and that the transaction may be potentially fraudulent. AVS Postcode Result / AVS Address Result: These fields apply to cards issued in the UK only all other transactions will always have a value of U in these fields. The full list of possible AVS results is detailed in section 7.5, above. For UK cardholders, where AVS checking is properly implemented, the result of the AVS check is displayed in these fields. The bank will check both the digits from the customer s street address and the customer s post code and return an individual result for both checks. Unmatched values in these fields may be indicative of potential fraud and should be investigated further. Note that transactions will not be declined by the bank where Address Verification fails. 36

37 7.8.4 Customer Details This section contains data specifically relating to the customer and their authorisation request. This information is of particular use when identifying fraudulent transactions. Each field is explored in more detail below. Card Details Cardholder Name: The first field contains the cardholder name provided by the customer. Note that this information is gathered for reconciliation purposes only and is not used in the authorisation process. As such, the cardholder name provided may not match the name on the card. This is a searchable field click on the name itself or on the magnifying glass icon to see all related transactions (both authorised and declined) which used the same cardholder name. A strong indicator of fraud would be where the same cardholder name has been used in multiple, failed authorisation attempts using different cards this would warrant further intervention to confirm the transaction. Cardholder Details Card Number: While the card number itself is obscured for security reasons, this remains a searchable field. Click on the obscured card number or on the magnifying glass icon to show all related transactions (both authorised or declined) which used the same card number. A strong indicator of fraud would be where the same card number has been used in multiple, failed authorisation attempts of different values - this would warrant further intervention to confirm the transaction. Card Issuer: For the majority of transactions, Realex Payments can use the first six digits of the card number (the Bank Identification Number, or BIN) to identify the bank that issued the card. Note that BIN ranges are frequently updated, so it is not possible to provide this information for all transactions. Card Issuer Country: For the majority of transactions, Realex Payments can use the first six digits of the card number (the Bank Identification Number, or BIN) to identify the country in which the card was issued. Note that BIN ranges are frequently updated, so it is not possible to provide this information for 37

38 all transactions. A strong indicator of fraud would be where the card issuing country does not match the billing/shipping address provided by the customer this would warrant further intervention to confirm the transaction. Transaction Originating IP: This field displays the originating IP address of the transaction, i.e. the IP address of your servers. This is a searchable field. Customer IP Address: Where available, Realex Payments will record the IP address from where the customer initiated the transaction request. Using free tools available online, you can use this information to find out the country where the customer is located. This is a searchable field click on the IP address to show a list of all related transactions (both authorised and declined) that used the same customer IP address. A strong indicator of fraud would be where the country in which the IP address originates does not match the billing/shipping address provided by the customer or the country in which the card was issued this would warrant further intervention to confirm the transaction. 7.9 Intervening in Suspicious Transactions Where a transaction has been identified as being suspicious, it is worth intervening to see if the validity of the transaction can be confirmed. Remember, fraudsters are generally looking for a soft target by demonstrating a commitment to fraud prevention, you should be able to dissuade malicious parties from targeting your account. Manual Review and Intervention is a vital part of any robust fraud management strategy. The following strategies can be used: Send an to the address provided to confirm that it exists. Remember, free addresses, such as those provided by Google, Hotmail and Yahoo, are very easy to set up and very difficult to trace. An address linked to a company or organisation is of far more use in confirming the validity of a transaction. Contact the customer on the phone number provided to confirm the order details. Remember, prepaid mobile phone numbers are very easy to set up and very difficult to trace. A landline is 38

39 generally preferable to a mobile number for the purposes of confirming the validity of a transaction. Confirm the details of the order with the customer over the phone or by . If the customer is unsure of the details of their order or unwilling to provide any information, this may be a strong indicator of a possible fraudulent transaction. Confirm the details of the card provided with the customer over the phone (it is generally recommended that card numbers not be transmitted via ). While card numbers are obscured for security purposes in RealControl, they can be searched for to identify transactions. If the customer is unable or unwilling to confirm the details provided, this would be a strong indicator of fraud. A good strategy is to see if the customer is able to tell you what bank issued the card, or what country it was issued in. This information is available for the majority of transactions in RealControl, but may not be readily available to a fraudster. Where possible, confirm the contact details provided with an independent third party. The names and addresses to which landline numbers are registered can be checked against online phone directories, such as for customers in the Republic of Ireland, or for customers in the UK. Check the IP address from which the transaction request originated online to determine the country of origin of the address. There are a number of freely available tools online which can allow you to do so. The Customer IP Address can be found in RealControl, as described in the previous section. Remember, in cases of fraudulent transactions, ultimate liability for any chargebacks that arise lies with the merchant. With this in mind, wherever suspicion remains over a transaction, the transaction should be rebated immediately in order to prevent a possible chargeback from arising. 39

40 8 Appendix: Using RealControl The following sections detail how to carry out some of the more commonly used functions of RealControl. For a complete introduction to RealControl, please see the document RealControl User Guide available for download on the Realex Payments Resource Centre Searching for Transactions RealControl contains a record of every transaction processed successfully through your account to your acquiring bank. Note that this includes both authorised and declined transactions. Transactions that have failed due to a validation error eg 5xx errors will not be shown in RealControl There are a number of options available to allow searching of transactions in RealControl: Manually searching for transactions in the Batched and Pending sections of RealControl Searching for related transactions using searchable transaction details Using the Quick Search box to search for specific transaction data Using Advanced Search and Download to search for specific transaction data or to download ranges of transaction by date and sub-account Using the Search Archive section to search for archived transactions (applies to merchants who have been processing transactions since before 2009) Manually Searching for Transactions A transaction that has been authorised but not yet settled can be found in the Pending section of RealControl. Transactions that were declined by the bank can also be found under the Pending section, under Failed Transactions. Transactions are filtered on a per sub-account basis the selected sub-account can be chosen from the drop down menu at the top of the page. A transaction that has been authorised and settled to the bank can be found in the Batched section of RealControl. Transactions are displayed by date and Batch Number 40

41 The Pending Section of RealControl The Pending Section of RealControl is broken down into 4 distinct sections: Next Batch contains all transactions which have been authorised but not yet settled. This section will contain all transactions which have been authorised using automatic settlement, as well as all delayed settlement transactions which have been manually settled but have not yet been sent to the bank, i.e. transactions which will be settled tonight. Voided Transactions contains all transactions which have been authorised but subsequently voided - these transactions will never be settled. Failed Transactions contains all transactions which have been declined by the bank or which have otherwise not proceeded to settlement. These transactions will never be settled. Delayed Settlement contains all transactions which have been authorised using delayed settlement and have not yet been manually settled. These transactions must be settled within thirty days of authorisation or else the authorisation will no longer be valid The Batched Section of RealControl The Batched section of RealControl contains all transactions which have been authorised and settled to the bank. Once a transaction has been settled, in most cases you will receive the funds in the unlikely event of issues arising at settlement which would prevent funds from being settled, Realex Payments will notify you immediately. The Batched section of RealControl is filtered on a per sub-account basis. The visible sub-account can be selected on the left hand side of the screen in the sub-account list. The Batched section of RealControl is shown below: 41

42 An individual row is displayed, corresponding to a single batch of authorised transactions. The batch is identified by a number of values: 1. Batch ID the unique identifier for the batch of transactions 2. Date the date on which the batch was opened 3. Sales/Debits the total value of authorisations contained in the batch 4. Refunds/Credits the total value of rebates and refunds contained in the batch 5. Net Total The total value of the batch, equal to total sales minus total refunds, and the number of transactions contained therein in parentheses () Two other options are also displayed: 1. Download downloads the contents of the batch into a CSV (Comma Separated Value) file, which can be opened in Microsoft Excel or similar spreadsheet applications 2. Comments where you can enter any relevant comments pertaining to the batch Clicking on any individual batch will display the Batch Details screen below: The Batch Details screen will show the totals contained in the batch broken down by card type. The possible options are: VISA/MC - containing all Visa and Mastercard transactions 42

43 Switch containing all UK Domestic Maestro/Switch/SOLO transactions Laser - containing all Laser Debit card transactions AMEX DINERS JCB The Batch Details section shows the total amounts of transactions processed for each card type, broken down by payment channel (RealAuth or RealControl) Clicking on the card type will show the list of transactions, as in the screenshot below. Each individual order ID can be clicked to show the Detailed Transaction View 43

44 8.1.2 Searching using Searchable Transaction Values A number of transaction values can be searched against the merchants transaction history to find instances of transaction details which have been used in the past. When looking at the Detailed Transaction Screen (see below) a number of transaction values can be clicked to show a list of all transactions processed using the same values. Note that a number of fields, highlighted red above, can be searched for. These values are outlined below: Cardholder Name: Show all transactions processed using the same cardholder name Card Number: Show all transactions processed using the same card Customer Number: Show all transactions processed using the same Customer Number Product ID: Show all transactions processed using the same Product ID Variable Reference Show all transactions processed using the same Variable Reference Transaction Originating IP: Show all transactions which originated at this IP address (merchant IP address, gathered automatically) Customer IP Address: Show all transactions which originated at this IP address (customer IP address, needs to be provided by the merchant in the transaction data sent for processing) In Batch: Show all transactions included in the same batch Searching by clicking on the fields above can be a very effective way for merchants to spot otherwise hidden pockets of unusual activity (such as declined transactions or transactions reported as lost or stolen, which can be often be indicators of potentially fraudulent activity) 44

45 8.1.3 The Quick Search Box The Quick Search Box (shown below) can be used by merchants to quickly search for transactions using specific criteria. This is usually the quickest way for a merchant to find specific transactions, particularly for refunding purposes Six search criteria can be used the specific criteria should be selected from the drop down box. Credit Card Number: While all credit card numbers stored on the system are encrypted, and so not visible in RealControl, it is still possible to search for transactions processed using a specific card number. Note that the full card number is required - a partial search of card numbers is not possible. Order ID: A free text search for order Ids. A partial order ID may be provided all matching results will be displayed. Cardholder Name: A free text search for the cardholder name. A partial name may be provided all matching results will be displayed Variable Reference Customer Number Product ID Advanced Search and Download The Advanced Search and Download Section of RealControl can be used to search for transactions by specific criteria, or alternatively to find transactions processed through specific sub-accounts on specific dates. 45

46 The Advanced Search and Download Screen is shown below: The screen is split into two sections: Quick Search which works the exact same way as the standard quick search function (see above), allowing searching of transactions based on criteria such as card number, cardholder name, order ID etc. Find or Download a Range of transactions which allows searching of transactions processed through specific sub-accounts on specific dates. The Quick Search option is detailed in the appropriate section above. The second option can be used to download transactions based on date and sub-account. A From Date and To Date can be entered (maximum one calendar month) to find a range of transactions processed through specific sub-accounts. The full list of sub-accounts is displayed with tick boxes to allow the search to be refined to specific accounts. It should be noted that the search date boxes are quite strict on formatting and it is usually easier to select the from and to dates from the calendar. The calendar can be opened by clicking on either of the choose buttons. The results can be viewed in one of two ways: Search and Display will display a list of all matching transactions within RealControl 46

47 Search and Download will produce a CSV (Comma Separated Values) file of all matching transactions, which can be opened in notepad, Microsoft Excel or a similar spreadsheet application. The Search and Download option will download all raw data associated with a transaction which can be manipulated appropriately by the merchant for reporting purposes Search Archives The Search Archives section of RealControl can be used to search all archived transactions (currently any transaction process prior to 01/10/08). The Search Archives section has the exact same functionality as the Advanced Search and Download section see above for more information. 47

48 8.2 Voiding a Transaction in RealControl A transaction can be voided at any point before it has been settled to the bank. Voiding is not an active process it does not communicate the fact that the transaction has been voided to the customer s issuing bank. Instead, it prevents the transaction from being settled, meaning that no funds will ever exchange hands. An authorisation will appear on the customer s card statement, but should drop off naturally after 3 5 working days. How the transaction appears on the statement is entirely a function of the customer s issuing bank. It should be noted that Realex Payments cannot affect the appearance of an authorised transaction on the customer s statement it is entirely at the issuing bank s discretion to release the funds. As such, the void function should be used with care. 1. Login to RealControl 2. Click on Pending 3. The Pending transactions screen is shown below: 4. Click on the Red X to void the transaction. Alternatively, click on the transaction, and click the Void Button (see below): 5. Clicking either Void button will display the void screen. Comments may be entered if required. 48

49 6. To void the transaction, press the submit button. The void will be acknowledged. 8.3 Rebating a Transaction in RealControl A rebate is effectively a reversal of an existing transaction. The customer s card details are not required instead, the encrypted card details stored on the Realex Payments servers are used. A rebate is explicitly linked to the original transaction and can be viewed alongside the original transaction details in RealControl. A rebate can only be processed once the transaction has settled to the bank if the transaction has not yet been settled, the transaction should be voided instead. A rebate can be processed up to 90 days after the original transaction date after that, the stored card details are no longer available for use and a refund will need to be processed instead. A rebate can be processed for any value from 1-115% of the original transaction value. A rebated transaction will be included in the next batch of transactions and settled in the same way as a standard authorisation. Funds usually take 3-5 working days to appear back in the cardholder s bank account, but may take longer depending on the bank that issued the card A rebate password is required to process a rebate. If you have not previously processed a rebate, or cannot remember your rebate password, please contact the Integration & Support Helpdesk at [email protected] A transaction can only be rebated once by default. Should you have a requirement to perform multiple rebates on a single transaction, please contact the Integration & Support Helpdesk at [email protected] 49

50 1. Find the appropriate transaction using either the quick search function or via the Batched section of RealControl 2. On the detailed transaction view screen (headed Transaction Detail view for Order ID XXXX see below), click on the button that says Rebate This Transaction 3. The Rebate Screen is shown below: 4. Two fields need to be filled out to complete the rebate: a. Amount: The amount of the rebate in cents or pence. A rebate may be processed for anything from 1-115% of the original transaction value b. Rebate Password: The rebate password for your account 5. A number of optional fields are also provided for your reference these fields are not required to complete the rebate, but will be stored alongside the rebate details in RealControl if provided. Note that some of the fields below allow a restricted set of characters only inclusion of special characters may cause a validation error a. Comments 50

51 b. Customer Number c. Product ID d. Variable Reference 6. Once the necessary details have been entered, click Rebate This Transaction to complete the rebate the rebate will be acknowledged as below. 7. If an incorrect password has been entered, the message below will be displayed 8.4 Refunding a Transaction in RealControl A refund is an entirely new transaction crediting money to a customer s account. A refund is not linked in any way to an existing transaction. The customer s card details will be required to process a refund. A refund usually takes 3-5 working days to appear in the customer s account, but may take longer depending on the bank that issued the card Because of the risks involved in processing refunds any amount could potentially be processed back to any card refunds are disabled by default on all accounts. If you wish to enable refunds on your account, please mail the Integration & Support Helpdesk at [email protected] to request the service. To process a refund: 1. Click on Online Terminal 2. On the left hand side of the screen, click on Refund Terminal 51

52 3. The Refund terminal is shown below this screen works in the exact same way as the online terminal, but with an additional field to allow the merchant to enter their refund password. Note that the auto-settle flag is greyed out and ticked by default this is because all refunds will settle automatically as part of the next open batch 4. The fields below are required to process a refund a. Order ID: The unique order ID for the refund; the order ID should use alphanumeric characters only b. Amount: The amount, in cents or pence, to be rebated c. Currency d. Card Number: without any spaces or dashes between numbers e. Expiry Date f. Name 5. All other fields are optional a. The Security Code should be entered where possible to ensure completion of the transaction 6. Once the necessary details have been entered, click Process to complete the refund 52

53 8.5 Processing an Offline Authorisation Banks will sometimes institute a semi random check on transactions, declining the transaction with the result code 102. This result code is often accompanied with a message Referral B or Call Auth Centre. The transaction has been declined no funds will be debited from the customer s account but you do have the opportunity to process an offline authorisation to complete the transaction. To do so, you must call your acquiring bank s offline authorisation centre. The offline auth centre will request some data relating to the account such as the time of transaction, amount, and card used and if they wish to proceed, will provide you with an authorisation code over the phone. Once you have the offline authorisation code, it can be entered via RealControl to complete the transaction. To process the offline transaction: 1. Log into RealControl ( 2. Click on Pending 3. Click on Failed Transactions see below: 4. Click on the affected transaction to show the detailed transaction view 53

54 5. Click on Offline Auth 6. The offline auth screen is shown below: 7. Enter the offline authcode in the appropriate field (all other fields are optional) 54

55 8. Click OK to confirm the authorisation 9. A successful authorisation is shown below 10. A failed authorisation is shown below should you receive the error below, please contact the Integration & Support Helpdesk for further assistance. 55