Page MenuHomePhabricator

Ingenico: audit lagging on manual settled transactions?
Closed, ResolvedPublic

Description

The Ingenico donations that we manually settle seem to vary in how quickly they reach Civi.

Order ID 4001030708 Merch Ref 66010478.1 is the first instance of a new recurring donation. I
manually settled it on March 1, and it reached status 975 same day, but it is not in Civi today, March 4th.

By contrast, Order ID 4001019240 Merch Ref 65968972.1 we manually settled on Feb 28th, and it jumped up to status 975 that day, and it reached Civi on March 2nd.

Questions:

  • what is the expected timeframe for manual settles to reach Civi, given how the audit is set up currently?
  • is there any chance it may be slower for recurring donations than for one-times?

It will be helpful to be able to accurately tell these donors when to expect their TY emails.

Event Timeline

DStrine moved this task from Sprint +1 to Triage on the Fundraising-Backlog board.
DStrine moved this task from Triage to Sprint +1 on the Fundraising-Backlog board.
Ejegg triaged this task as Medium priority.

Looks like 66010478.1 came in on the audit file that was delivered March 4th, and we imported it into Civi on (UTC) March 5th at 1:40 .

We do get Ingenico WX audit files on the weekend, but they're about 1/10th the size of the weekday ones. Not sure if that's related to our donation volume, or if there's something about their reporting system that delays most of them till Monday. Monday files DO seem to be bigger than other weekdays on average.

Thanks, @Ejegg I can just factor in a bit more of a delay for manual-settles done on Fridays, it sounds like.

To follow up on T208261: Ingenico: 10/15 or 10/18 audit missing refunds?, how long is a good time period to wait before asking about refunds (or other transactions) that don't reach Civi? The ones in that task were a few weeks overdue.

Here's a recent Ingenico refund that has not migrated to Civi:
transaction ID 4001088437, reference 66225968.1 refunded on March 7th.

Aha, looks like we're not counting the refund code we get in the audit when the payment hasn't been collected yet.

From the WX format docs:

Data records succesful created refunds (all payment products) X CR
Data records refunds on collected card payments - CR

We are currently only parsing the "- CR" records.

Change 496320 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[wikimedia/fundraising/SmashPig@master] Count 'XCR' type refunds, not just '-CR'

https://gerrit.wikimedia.org/r/496320

Change 496320 merged by jenkins-bot:
[wikimedia/fundraising/SmashPig@master] Count 'XCR' type refunds, not just '-CR'

https://gerrit.wikimedia.org/r/496320

Change 496479 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[wikimedia/fundraising/SmashPig@master] Add another payment product mapping for Ingenico

https://gerrit.wikimedia.org/r/496479

Change 496479 merged by jenkins-bot:
[wikimedia/fundraising/SmashPig@master] Add another payment product mapping for Ingenico

https://gerrit.wikimedia.org/r/496479

Change 496678 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[wikimedia/fundraising/SmashPig@master] Fix audit parsing for XCR records

https://gerrit.wikimedia.org/r/496678

Change 496678 merged by jenkins-bot:
[wikimedia/fundraising/SmashPig@master] Fix audit parsing for XCR records

https://gerrit.wikimedia.org/r/496678

OK, that seems to have gotten the 66225968.1 transaction refunded.