Researching Charge Backs
Researching Charge Backs
The attached script will pull the following information from Club Speed. All you have to do is update the last 4 (line 9 = @last4) and the date range (line 10,11 - StartDate & endDate).
- Check Number & Payment information for any transactions with a matching last 4 in the date range given
- All payments on any check with a matching payment
- There is a section commented out at the bottom that will pull the SQL logs to check for fails.
You should receive an email from Payments with some information about a Charge Back dispute. Usually, they will send the following information:
- Case Number: CB782896647001
- Name: CSP*GRAND PRIX NEW YORK
- Amount: 53.48 USD
- Last 4: 5077
- Transaction Date: 9/27/18
- Auth Code: 55869P
- Due Date: 11/1/18
- Reason: 60 / Credit Not Processed
- Reference Number: 55500368271091562000530
- CS Check #:
- Invoice #: --
- Notes: I show 2 separate transactions. Although seams like the customer wanted to purchase another race after completing 2
You will update the CS Check# and update the notes. You will pull different information based on the Reason Code given. Depending on the code, you will attach screen shots of the check & payment info from the POS and of the Racer & History for people attached.
The goal is to give the track a good starting point for them to do research of their own. They will then respond to Payments' notification email with details, evidence, and if they want to accept or dispute.
What to do:
- Based on the email from Payments, log into the server. In the above example, log into Grand Prix New York (GPNY)
- Open SQL > New Query
- Open the attached SQL Script on your PC
- Update the Last 4 (in the above example, set it to 5077)
- Update the Date Range based on the Transaction Date. In the above example set the startDate to 2018-09-24 00:00:00.000 & set endDate to 2018-09-30 23:47:31.000
- Copy & Paste the script into the Server's SQL and execute
- Note the CheckID from the top section. Update the 'CS Check#' section in your email response. If there are more than one check number/row in the top section, scroll to the right and match the Pay Amounts and/or Auth Code.
- If you need to get Logs, open the attached script 'chargeBackLogs.sql' and update the like statement (ex: like '%checkid:1234% and ...) > execute in a new query window
- Review the logs and see if you can see/understand what happened.
- In the 'Notes' section, add to the end what you think happened/what you show. For the above Example I put:This charge looks legitimate. Let us know if you want to accept or dispute. If you want us to dispute, please provide some evidence they are who they say they are (waiver, etc), used the services, and proof of purchase.
Email Payments with the updated response.
**Remember transaction day can be the day before due to the way First Data settles. So a transaction date of 9/15 could be 9/14 or 9/15. I like to do a wider window, just in case.
Reason Codes & What to look for:
- Other fraud - Card Present Environment => We need to send the track information so they can send us information proving the card holder is who they say they are (waiver signatures, pictures, histories to show they used the service [maybe even before this]). It is good practice to send Payments screen shots of the check, 1 user profile, etc for them to forward to the track with examples of what we are looking for.
- Duplicate Processing => We need to see how many charges are for the card (last 4) and send over each check number for the track to make sure they are all separate legitimate purchases. We also need to also check the logs (attached logs script) for each check to look for failed/error attempts. We should report to Payments if there are any failed attempts. If payments sends multiple Auth Codes, also search for both Auth Codes by running the attached 'chargeBackDuplicateCheck.sql' script. Just change the Authorization Code. If one is missing from the payments table, it could be legitimate. If one Auth Code isn't in Club Speed, let payments know which one and that it may be legitimate.
- Fraudulent Transaction - No Cardholder Authorization => same as 'Other Fraud' above