php PaymentProviders/Braintree/Maintenance/GetReport.php -d '2025-12-05'

Looks like the gravy console will show incomplete transactions like Paypal does, I backed out of a transaction 1c52de60-83b3-4912-8964-dff024228f77, it has status of yellow Authenticating with no PII on it

The fr-tech side of this was deployed today

We deployed this today, my test donation has the utm_key with the app_install_id value in it

@Pcoombe did the donate wiki piece today, so it will get to payments wiki

@Dbrant let's go with app_install_id

Today @EMartin requested that we up the limit for a donor that wanted to do a higher donation so we raised the maximum to 25,000

Okay got even more logging in, it looks like every ~100 or so transactions, the capture call takes 30 seconds

for dHJhbnNhY3Rpb25fZXAwbnN5d2Y

These are all our gravy venmo test transactions linking T409599: Venmo issues from first round of testing

We would also see this when manually doing test donations on recurring charges, they can also get stuck in the 23 day difference check

I think I was able to replicate this today, but the logs on our ends look good. I'm asking if the apps team have any more info on their end.

The bugfix for this has been deployed, still need to clean up the rest of the missing data donations

There's not too many of these ~100, we have their address in the logs so can backfill this data

Ah this was because the next_sched date was updated to be close to a previous charge, so it didn't pass the 23 day check. Maybe more of a feature than a bug.

Suspicious because it's my test donation, this is a gravy visa recurring

I made a new phab T410949: Change payments configuration to handle that everything is going through gravy

Have a ticket in with dlocal about setting up another account for gravy to use

From the database end I made this in metabase, it's basically a searchkit in how it's made right now but we could tie an alert to it
https://metabase.frdev.wikimedia.org/question/1179-invoice-id-dup

The fr-tech side of this has been deployed.

Finally got this deployed,

I'm guessing there was a bug but they have since fixed it and @AMJohnson was the lucky one to catch it in the wild

This was caused by the fix to the session issue, reverting the patch now https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DonationInterface/+/1205211

Looks like these donors donor_country was in lowercase letters, most are coming in uppercase

The gravy audit didn't run in this time frame by the refundfailed issue, that has been fixed and the files have been rerun. Have you ran into missing ones since? @MBeat33 @AMJohnson

@MBeat33 catching back up on this, yeah if we have fully moved off of them since August, manually marking them would be the easiest

the app isn't using anything for utm_key, we could put that data in there. It also aligns with something unique going into utm_key for other donations

Thanks for making the phab @MBeat33 this was Amber's test donation, I'll put her feedback here too

current settings

Talking to Lars and Eileen, for the first variant we are going to match the functionality to the acoustic numbers we have in civi, in that we only have them in civi if they have the consent. We can change this in the future.

This was deployed on 2025-11-05 and the emails are being sent from the recurring charge job via coworker now.

Gravy is working on a fix for the consolidated file, it's currently stuck to my user account

confirmed the test transactions are in the audit files