Page MenuHomePhabricator

Delay in GC transactions making it into Civi
Closed, ResolvedPublic2 Estimated Story Points


from @krobinson

I was just doing a fraud scan and there are only 703 Ingenico transactions in Civi from yesterday, 8/15, despite there seeming to be nearly 10k successful ones at the payment processor. Today's seem to normal -around 3k Japanese donations are in Civi already- but it seems like there is something amiss from yesterday. I'm not sure if it is new integration related, perhaps leading to a delay, but wanted to flag it regardless in case we need to reach out to tech on this, as there is a definite discrepancy in the numbers.

Event Timeline

Hi @krobinson! How are you looking for the donations in Civi? The Wednesday tests have been using our new integration, which codes the donations as gateway='ingenico' rather than gateway='globalcollect'. The trxn_ids for the new integration also start with 'INGENICO 0000%' rather than 'GLOBALCOLLECT %';

Looking at the counts now, I see 8,785 from the new integration and 2,024 from the old one on the 15th.

payments_fraud table numbers are a bit funny, though - the old integration only shows 757 rows from the 15th, while the new integration shows 9,044. Checking to see if the old integration donations were mostly recurring - we don't add fraud rows for the recurring installments.

OK, numbers from the old integration on the 15th check out too. 1,315 of them were recurring, so that's 709 new one-time donations, a bit under the number of payments_fraud rows.

Ha! My bad completely - I was searching GLOBALCOLLECT %. I just tested and those numbers are what I see, so apologies. I was using the wrong gateway. Sorry for the confusion!

No worries, I probably should have communicated this more clearly!

So, as long as both the integrations are active you'll have to complicate your queries with extra parentheses and an OR trxn_id like 'INGENICO %' clause.
Hope that doesn't slow things down too much!

Another option for the filter would be to join on the wmf_contribution_extra table (its entity_id column matches civicrm_contribution's id column) and use it's gateway column like so: gateway IN ('globalcollect', 'ingenico')

Thanks for the tips :)

Now I know I'll check both. Ingenico fraud scans are more Michael's territory and I just hadn't realized the new integration had a different gateway.


DStrine set the point value for this task to 2.Jun 4 2019, 3:53 AM