Page MenuHomePhabricator

BUG: Internal fraud "reject" data does not match GC's numbers; seems too high
Closed, ResolvedPublic0 Estimated Story Points

Description

I was running the fraud numbers for IL, HU, SE, NO, and DK today. The IL Worldpay numbers looked normal, but per the data shown on the Elevate success rates doc, the fraud numbers for HU from 2/7 - 2/9 seem really high, and do not match Elevate's numbers:

https://docs.google.com/a/wikimedia.org/spreadsheets/d/1ViytZKYTJCyZel_eaBYJSxot7SKLPdW2HNFsnQpMzy8/edit#gid=1739184085 (see cells J31 - J33)

I used the following query to get the data:

mysql fredge -B -e "select * from payments_initial where gateway = 'globalcollect' AND country = 'HU' AND date > TIMESTAMPADD(DAY, -5, NOW())" > HU20150210.tsv

Can someone please double check my query as well as the fraud (or "reject") data we have for Hungary? We want to make sure we aren't rejecting 25-60% of all attempts!

Event Timeline

CCogdill_WMF assigned this task to atgo.
CCogdill_WMF raised the priority of this task from to Needs Triage.
CCogdill_WMF updated the task description. (Show Details)

Ooh I wonder if this is related to T87810

I'm not sure, @atgo! It's strange that the numbers from 2/2 - 2/6 look
normal, and then jump on 2/7.

atgo raised the priority of this task from High to Unbreak Now!.

Yeah that is strange @CCogdill_WMF.

atgo moved this task from In Analysis to Dev Ready on the § Fundraising Sprint Devo board.
atgo set Security to None.
atgo edited a custom field.

@Ejegg is this related to the email you sent about HU earlier?

This was my fault. On 2/5, I deployed a change to the payments cluster but not to the machine that runs our orphan script to check on transactions which didn't clear instantly. Because we changed the format of messages sent between machines, the orphan script repeatedly marked some valid transactions as rejected and delayed recording them in CiviCRM. On 2/17 I updated the orphan runner to the same version. It cleared up 100 donations that had been stuck in limbo, but I'm still determining whether a number of older orphan donations are still wrongly marked as rejected.

For now, you can filter out the bad rows from the orphan script by adding a clause involving the 'server' column (machine name sent via email).

Update: Katie points out that many of the spurious 'reject' lines are actually abandoned transactions.

Between the updated orphan script and the nightly audit processor, all valid transactions should have made it into CiviCRM.

Thanks, @Ejegg! I got the server info and will work on getting the data for
Pats. I think this is solved now...