@MBeat33 you can refund them, that won't affect the investigation

Two issues here:

1 - Donor was able to donate 3 times in 7 seconds from the front end

2 - The audit ingestion didn't grab the third transaction (I'm guessing due to the duplicate id you saw @MBeat33 )

I'm going to rename this task to the bug itself

Thanks, @Cstone

We made 3 separate full calls to gravy:

payments-gravy-20260307.gz:Mar 6 11:09:20 payments1005 gravy_gateway: 245260402:245260402.2 Calling approvePayment on PSP reference 1ee7a916-ce2a-4522-8c7a-f706a5a30be0
payments-gravy-20260307.gz:Mar 6 11:09:22 payments1005 gravy_gateway: 245260402:245260402.2 Calling approvePayment on PSP reference c393558a-7a08-4cfa-894b-ed99dadb1423
payments-gravy-20260307.gz:Mar 6 11:09:47 payments1005 gravy_gateway: 245260402:245260402.1 Calling approvePayment on PSP reference f1479244-7cc2-4c0f-890d-56b21ef06794

fundraising-misc-20260307.gz
Mar 6 11:11:06 : SPCID-1840124194 | (corr_id-gravy-245260402.2) Processing captured Gravy payment with authorization reference '1ee7a916-ce2a-4522-8c7a-f706a5a30be0' and order ID '245260402.2'. | |
Mar 6 11:11:06 : SPCID-1840124194 | (corr_id-gravy-245260402.2) Processing captured Gravy payment with authorization reference 'c393558a-7a08-4cfa-894b-ed99dadb1423' and order ID '245260402.2'. | |
Mar 6 11:14:02 : SPCID-1768573661 | (corr_id-gravy-245260402.1) Processing captured Gravy payment with authorization reference 'f1479244-7cc2-4c0f-890d-56b21ef06794' and order ID '245260402.1'. | |

Change #1255890 had a related patch set uploaded (by Damilare Adedoyin; author: Damilare Adedoyin):

[wikimedia/fundraising/SmashPig@master] WIP: Add idempotency key to Gravy transaction requests

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

Looks like those 3 calls to gravy were in 3 different hits to https://payments.wikimedia.org/api.php , so the root cause of the extra charges seems to be client-side not server side.

The first one, 245260402.1 started at 11:09:13, got an authorization response back at 11:09:15, then logged 'Preparing to run custom filters' and nothing else till 11:09:47 'Finished running custom filters'. Maybe the minfraud query took a really long time?

I think I did get to the bottom of why the next two share an invoice id:

The second request came in at 11:09:18 and got the incremented invoice id 245260402.2. Its auth response came back at 11:09:20. But before that auth reponse came back, the third request had already come in and got the same invoice ID. This happens because we only call incrementSequenceNumber AFTER the auth response comes back. Maybe we should instead do that after building the createPayment parameters but before making the API call?

It looks like for the Gravy google pay form JS we have neither the debounce nor the form disablement that we have for other submit buttons.

Change #1256701 had a related patch set uploaded (by Ejegg; author: Ejegg):

[mediawiki/extensions/DonationInterface@master] Prevent accidental double Google Payments on Gravy

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

Change #1256701 merged by jenkins-bot:

[mediawiki/extensions/DonationInterface@master] Prevent accidental double Google Payments on Gravy

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

Change #1259241 had a related patch set uploaded (by Eileen; author: Eileen):

[wikimedia/fundraising/SmashPig@master] Bubble up Adyen Reversal Txn ID

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

Change #1259241 merged by jenkins-bot:

[wikimedia/fundraising/SmashPig@master] Bubble up Adyen Reversal Txn ID

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

It's been a month and we've rolled out a couple things to handle this, I'll move this to done and if it happens again we can make a new ticket