This is interesting, something is happening that's causing a null response and then we lose the final status. Locally stepping through on a null response it's being caught and getting a final status of failed

The latest instance of this happened even with Dami's fix deployed to SmashPig

https://civicrm.wikimedia.org/civicrm/damaged/edit?action=update&id=651456&reset=1 happened on 10/09 with payments-wiki at commit ed2d78b3 which includes SmashPig v0.8.14

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

[wikimedia/fundraising/SmashPig@master] Always set FinalStatus failed on no response status

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

Change #1079332 merged by jenkins-bot:

[wikimedia/fundraising/SmashPig@master] Always set FinalStatus failed on no response status

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

More odd stuff looking at this failed ACH from very recently: https://civicrm.wikimedia.org/civicrm/damaged/edit?action=update&id=651557&reset=1

• the PHP session ID is associated with 3 different contribution tracking IDs, so the donor definitely tried multiple times
• first attempt was authorized but rejected for fraud
• second attempt had the null stuff
• no log line with any of the ct_ids is found with the 'Outbound data' or 'Initiating cURL' at the appropriate timestamp (these should be prefixed by the SmashPig logger) but we do see two 'Initiating cURL' lines at the appropriate timestamp with NO ct_id.

Steps to replicate locally:

• try doing an ACH on Adyen with the correct test credentials (any name, any acct number, routing number 011000138 or 121000358) but force it to be fraud-rejected (I added $this->setValidationAction(ValidationAction::REJECT); in runFraudFiltersIfNeeded)
• because FinalStatus is PENDING-POKE and ValidationAction is REJECT, we clear out the whole session, including the submethod.
• red text appears above the form but form is not disabled
• click the submit button again. payment submethod is NOT re-submitted and since it's not present in the session it doesn't get sent to the SmashPig createPayment call.
• SmashPig logic depends on submethod to go down the right path. issuer_id, iban, and recurring_payment_token are also all blank, so none of the paths to actually make an Adyen API call are followed, and $rawResponse stays null: https://phabricator.wikimedia.org/diffusion/WFSP/browse/master/PaymentProviders/Adyen/BankTransferPaymentProvider.php$29

I think we need to do some more work on this. Specifically, we should send the donor to the error page when the submission fails rather then clearing out the session and letting them submit again. Moving back to 'In Progress'.

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

[mediawiki/extensions/DonationInterface@master] Send donor to fail page on Adyen fail

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

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

[wikimedia/fundraising/SmashPig@master] Log error when sending bad params to createPayment

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

OK, I think those two patches should catch the specific issue that was causing things on ACH payments.

Change #1081177 merged by jenkins-bot:

[wikimedia/fundraising/SmashPig@master] Log error when sending bad params to createPayment

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

Change #1081173 merged by jenkins-bot:

[mediawiki/extensions/DonationInterface@master] Send donor to fail page on Adyen fail

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