What are chargebacks?
It is a reversal or unpaid transaction in the card processing space that results in the removal of a transaction amount from the merchants’ account.
In most cases (there are exceptions), the end customer initiates the chargeback. They will ask their issuer to reverse the transaction, who will in turn instruct the acquirer to move the funds back. A merchant is then given a limited time frame to contest the chargeback and must adhere to the time frames given or he can not dispute. If the chargeback is not contested (in time) or acquirer does not accept the merchant’s contest, the acquirer will as per above, deduct the funds from the merchant’s account. In general, acquirers will err on the side of the end customer in case of disputes.
Card Schemes monitor all chargebacks that are processed and can fine or close down a merchant classified as high risk. High-risk merchants (typically >1% of transactions) can be subjected to fines for each chargeback that is received.
Note: CP merchants have chip & pin or signature which allows the merchant to sidestep liability, with CNP the merchant is always liable unless 3Dsecure is used. More about that later.
Most Common Chargeback Reasons
• The customer claims not to have authorized or does not recognize the transaction/Fraud
• The customer claims non-receipt of goods
• The goods or services were defective or not as described.
• The card has been used before the effective ‘start’ or ‘valid from’ date or after the card has expired
• A Merchant has failed to respond in time to a request for a copy of the transaction or a RFI
• The Merchant did not obtain an authorization code
• The card used in the transaction was not a valid card
• A refund was not processed or has not been credited to the same the Merchant account that was originally debited
How a Merchant can prevent chargebacks
• Use a clear DBA (Doing Business As) this is the second most common cause of chargeback after fraud
• Add the contact details to the Cardholders statement this can reduce the number of chargebacks by >60%
• Response to RFI in time with as much documentation/evidence as possible. If the window of opportunity is missed the Merchant forfeit’s their right to dispute a chargeback
• Obtain authorisation for the full amount of the sale declined transactions should not be split into smaller amounts
• Never process expired cards even though they may be authorized, likewise with Manual transactions as these cannot be contested
• Get signed proof of delivery
• Never allow a delivery to be redirected after shipment.
Transaction Authentication and Fraud Prevention
It is important to understand the difference between transaction authorisation and transaction authentication as this often creates confusion with merchants new to credit/debit card processing in a Card Not Present environment.
Transaction Authorisation is the process by which a merchant gains authorisation to debit an amount from a customer’s account from the bank that issued the customer’s credit card. This authorisation is based on the credit card number provided and the availability of funds in the customer’s account. When a transaction has been authorised, this means that authorisation has come from the customer’s bank to debit funds from account, but does not necessarily imply that the customer has authorised the transaction. The cardholder always has the right to dispute any charge that appears on their card statement, starting off the chargeback process.
In a cardholder present environment, the merchant can be reasonably assured that the customer has authorised the transaction because they are present with their card, and by having the customer sign the receipt or enter their secret pin number into a Chip & Pin terminal, they have valuable additional evidence with which to dispute any chargebacks.
Unfortunately, in a cardholder not present environment such as over the internet or phone, the situation is less secure. As such, merchants employ various transaction authentication measures to reduce their liability.
Anti -Fraud measures typically include pre-authorisation checks (know your customer, delivery address, delivery vs. payment address, 3DS, etc.), authorisation checks (CVN) and settlement checks (manual review before settlement).
A payment processor should at least offer the following:
1. Basis fraud scoring
2. 3DS
3. Card Security Code Checking – The card security code – known variously as the CVN, CV2, CVV2, CSC and a number of other acronyms – is a three or four-digit number present physically printed or embossed on the credit or debit card, but crucially, not present on the card’s magnetic strip. Because the CSC is not present on the card’s strip, it cannot be “hacked” from the card data if the card is compromised in the process known as card skimming. By providing the correct CSC with a transaction, the merchant can be reasonably assured that the customer actually holds the card in question. Some banks will decline transactions automatically on the basis of an unmatched CSC – but others do not, providing CSC checking as an advisory service only
3D Secure
3D Secure (3DS for short) is the generic name given to the authentication servcies that is developed by the card schemes. 3DS attempts to ensure that the payer is who he says he is by forcing the card holder to log onto their own bank’s website and enter a password.
In the UK 3D Secure is very widely accepted and does indeed fulfill an important role in reducing fraud. In other countries acceptance is much lower and can lead to loss of business.
It is also important to consider what your competitors do and how easy it is for a customer to switch to them.
3D Secure Scenarios and when you have liability shift
There are various outcomes, but this is the important part:
Note that Amex does NOT accept a shift in liability for the first category.
Apart from the scenarios above, there is also a category of transactions which is not completed: enrolment request was received, but actual verification never took place. In the majority of cases, this is because the customer decided to discontinue the process, for example, because they would not know their password or did not want to register for 3D Secure at the time. It is important that you will get statistics on this from your processor, broken out to as much detail as available.
Transactions are not automatically declined depending on the result. It is the choice of the merchant to either accept the risk or decline transactions. It is possible to devise a structure that would allow you to have different rules for different types of transactions, e.g. for specific countries or with higher values.
Note: It is also important that you have the ability to switch 3D Secure off altogether in case you see a sudden drop in authorisations, issues with the 3D Secure service, or big jumps in traffic.
Fraud Management Systems
If you experience a high level of fraud, it is advisable to consider implementing a specialised fraud management system.
Payment Optimisation
You should ensure you get statistics from your processor on your decline levels, broken down into as much detail as possible. Decline levels differ strongly, from 90% in general to 50% for gambling and even lower for some forms of finance products. You will also typically see higher decline levels the further away you go: highest in UK/Ireland, a bit lower in Western Europe, lower still in Eastern Europe/North America and considerably lower in Russia or Latin America.
Declines
A decline is not an error. That might sound obvious but sometimes is misinterpreted. A Payment Processor provides you with a range of error codes (available from our resource centre) for when things do go wrong. In these cases, the payment request did not get processed. Declines fall in three categories:
101 – Generic decline, which we will investigate further below.
102 – Referral; this is best described as an extra safety check by the issuer. For example, if you go on holidays to a faraway destination you are always advised to let your card issuer know; as it might otherwise require the merchant where you want to use your card to make a call before the purchase gets approved. Similarly you can call your acquirer to get an authorisation code if you receive a 102. On your website, you should treat these as 101 declines.
103 – Lost or Stolen cards. Never proceed with the order and never retry a card that received a 103 response. It will never get authorised.
101
A 101 does not always mean that the customer does not have funds in their account. You will get customers calling you to say that that they called their bank that everything is in order; there are funds, so therefore it must by you, the merchant – who is rejecting the transaction.
A Payment Processor does not reject transactions. A 101 always is a response received from the banking system, either decided by acquirer or the issuer.
Reasons
There are many. Insufficient funds are a (main) reason, but not the only one. Transactions get declined because the CVN was not or incorrectly filled in (note: an incorrect CVN will have a higher chance of rejection than a missing CVN; contrary to expectation neither will always lead to decline); incorrect expiry date (you have to submit one; again an incorrect date is no guarantee for a decline).
Issuers and acquirers can have complex decline rules. As they are managing risk, they can decline transactions for certain merchants, values, countries and or combinations of these. If you are a UK based merchant taking transactions from across the world you will find decline rates lowest in the UK, and declining the further you go (Western Europe, Eastern Europe, USA, Rest to the World).
Extra Information
A Payment Processor should provide as standard a comment with authorisation code. This information is coming directly from the issuers or acquirer and is not amended by A Payment Processor. Depending on the banks involved this information is more or less informative.
You should check if your processor offers an additional code that gives more information about the reason for the decline. It is by no means a silver bullet, but it will help identifying declines that are because of insufficient funds and will also identify a number of soft and hard declines.
Soft declines are transactions that may be successful on re-attempting. Hard declines should never be re-attempted.
Recurring Payments
If you are using recurring payments, we strongly advise you to use the same customer number for each payment relating to that customer.
It is also very important to have processes in place to keep the expiry dates up to date. Too many merchants allow the cards to expire and see their declines rates go up as a result. According to PCI, you can keep the expiry date in your system. You should contact your customer before the expiry date is reached and update it. (A Payment Processor can also provide you with reports from our tokenisation database with cards that are going to expire in the coming three months; it is also possible to update the expiry date in our database via an update message so that you do not have to create a duplicate entry).
Decline Analysis
You should periodically do a decline analysis helping you to establish decline patterns on days, times, issuing country, value, etc.