How to Manage Chargeback Reason Code 83
Fraud and chargebacks are the two biggest payment processing-related issues card-not-present merchants have to deal with. If you’ve managed an e-commerce business for any length of time, I have no doubt that you are fully aware of that. Something else that I’m sure has also not escaped your notice is that the two typically come together and you only learn of the fraud when you receive the resulting chargeback.
This is exactly the case with Reason Code 83, which is used to designate chargebacks resulting from processing fraudulent card-absent transactions. In this article I will review the circumstances when issuers use this reason code, how you can respond to it and what you can do to prevent it.
What Causes Reason Code 83
Chargeback Reason Code 83 is used by issuers when they receive a complaint from one of their cardholders who claims that she neither authorized nor participated in the card-not-present transaction at issue or when it was charged to a fictitious account number for which an authorization approval was not obtained. The immediate causes for this chargeback can be one of the following:
- The merchant charged a transaction to a card account that was fraudulently used or
- The cardholder did not recognize the merchant name associated with a transaction on her statement.
Card-not-present transactions include mail order, telephone order (MO / TO), internet (e-commerce), pre-authorized health care transactions, recurring and advance payment transactions, and no-show fees.
How to Respond to Reason Code 83
Listed in the table below are the most likely circumstances you may find yourself into when considering your response to a Reason Code 83 and my suggestions on the course of action you should take:
If: |
Then: |
An authorization approval was obtained and an exact match was received to your AVS or security code query.* | Provide your processor with a copy of the transaction invoice, proof of delivery and any other information relevant to the transaction, to be used in the re-presentment. If you requested an AVS or security code verification and the card issuer responded with a “U” code (meaning that the issuer does not support AVS or security code verification or information is unavailable), you still have a re-presentment right. |
You received an authorization approval, but did not use AVS or a security code. | Provide your processor with a copy of the transaction receipt, a signed proof of delivery and any other relevant information that may be used in the re-presentment. |
The transaction was face-to-face and the card was present. | The chargeback is invalid. Provide your processor either with an authorization record proving that the magnetic stripe was read or a copy of the sales receipt displaying the card imprint and signature of the customer. |
*AVS and the security codes are fraud prevention tools developed specifically to be used in card-absent transactions. In some cases they provide merchants with a re-presentment right, but do not directly prevent chargebacks.
How to Prevent Reason Code 83
The following best credit card acceptance practices should be implemented:
- Always obtain an authorization approval. All MO / TO, e-commerce and recurring transactions must be authorized, regardless of the dollar amount.
- Read back the account number. For telephone transactions, always verify the account number with your customer to avoid errors.
- Identify the transaction as card-not-present. Use the appropriate code to identify transactions as mail order (“MO”), telephone order (“TO”) or e-commerce (“ECI”) during both the authorization and settlement process. Typically, this will be done automatically by your payment processing system, or by pressing a MO / TO indicator button.
- Use AVS and the security codes. These services are designed specifically to help prevent card-not-present fraud.
- Ensure that your billing descriptor is set up correctly. The way your business name appears on your customers’ transaction activity logs and monthly statements is managed through a tool called “billing descriptor.” Typically, it is set up to display your “doing business as” (DBA) name, although some processors may use your legal name as a default setting. Work with your processor to ensure that the billing descriptor is set up to display the name that is most familiar to your customers, as well as that all other information (e.g. city and state, phone number, internet address) is accurately identified.
Be advised that you are protected from a Reason Code 83 chargeback if the transaction has an Electronic Commerce Indicator (ECI) 5 or 6, indicating a Verified by Visa transaction, so make sure that all of your transactions are accurately identified.
The Takeaway
You cannot prevent all fraudulent transactions that can lead to a Reason Code 83 chargeback, as criminals often have access to all information needed to successfully complete a card-not-present transaction, even when best payment processing procedures are followed and available fraud prevention tools used. However, you can greatly minimize the chance of that happening, because most criminals are not all that sophisticated, nor do they always have all of the account information available to them. This is precisely the type of fraud you have full control over and preventing it should be your top priority. A success on that front will have the beneficial side effect of limiting Reason Code 83 chargebacks.
Image credit: Emailmanagement.com.au.
Hi,
Is there any kind of Visa regulation that does not allow a chargeback reason code 83 if the card holder has had an extensive history with the merchant. Let say a merchant charges a card holder 12 times over a 12 month period, in essence they are getting charged monthly. The card holder disputes one of the last transactions and says they don’t “recognize” the merchant or didn’t receive any benefit. We all know that’s BS because they’ve been doing business with the merchant for 12 months.
Thanks,
Rich,
That ultimately depends on how far back the issuer is willing to let the cardholder dispute. Domestic card issuers are usually 6 months back. International, 12-18 months, depending on the services provided. Since they’ve been paying off their credit card bill every single month for the past 12 months, there is clearly an issue with the cardholder and you can almost assume 99% that the cardholder does not actively check their bank statements via snail mail/online, etc. Since Fraud is one of the toughest battles to fight from the acquiring end, the issuer most likely will give the cardholder benefit of the doubt, which is why merchants are encouraged to implement as much fraud security tools as possible.
I would highly recommend VbV/MC SecureCode and AVS/CVV to avoid this type of activity of friendly fraud. Hope this helps.
Donald