Page MenuHomePhabricator

INVALID_MESSAGE Recurring donation, but no subscription ID or recurring payment token found failmail coming from the listener on ideal
Closed, ResolvedPublic

Description

Based on the ticket https://phabricator.wikimedia.org/T307602 that we for any ideal payment method this function is not working properly :
e.g.
wfan@civi1001:/srv/org.wikimedia.civicrm/vendor/wikimedia/smash-pig$ php PaymentProviders/Adyen/Maintenance/TestGetPaymentToken.php --pcid=127384829.1

~30 happened on August 10
and since this will lead the donor will get thank you email delay, would want to email Adyen for the solution~

Event Timeline

AnnWF updated the task description. (Show Details)

We need to email adyen to see why we aren't getting the token back for ideal recurrings

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

[wikimedia/fundraising/SmashPig@master] Change API call to look up tokens

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

Change 824581 merged by jenkins-bot:

[wikimedia/fundraising/SmashPig@master] Change API call to look up tokens

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

Good news is we're getting the tokens now!

Bad news is we're getting a different failmail - looks like the queue consumer now thinks these are duplicated new recurring donations. Why aren't they just getting dropped as duplicates up front?

IMPORT_SUBSCRIPTION 8002: Found matching recurring contribution(s): 1214765

sites/all/modules/wmf_civicrm/wmf_civicrm.module(297): wmf_civicrm_message_contribution_recur_insert

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

[wikimedia/fundraising/crm@master] Set contribution_recur_id when token found

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

Ugh, we have a test that specifically says a new payment with the same token should get a new recurring record. I guess there are donors who want to use the same card for two different recurring donations. So I guess here we need to match on invoice ID too or something?

So we're doing a lot of work here to just discard the messages later when we realize the gateway_txn_id is already in the contributions table.

Maybe the answer is to move the check for an existing matching contribution up to the start of the whole process? That way we can discard these earlier and skip the recurring mess.

There were two today:

CID: 15097731
Had two iDEAL recurrings on September 1 for 2.35 and both had the same contribution tracking id: 128292393.1
HP7SNT9ZM4H6SP42 is in civi it was 2 minutes before
KW5CHGLB3BK4K472 which is not in civi and creating the failmail

CID: 15300499
Had two iDEAL recurrings on August 31 for 2.50 and both had the same contribution tracking id: 128263852.1
RNJ9SH6XXXT3MKG2 is in civi as it was 4 minutes before
GX68QFX93BK4K472 which is not in civi and creating the failmail
GX68QFX93BK4K472 was refunded on September 7 but RNJ9SH6XXXT3MKG2was refunded in Civi

https://phabricator.wikimedia.org/T243967 could possibly have helped here unless it was the situation mentioned in:

This will help if we're worried that we are charging duplicates when we get a timeout making an API call and automatically retry.

This will NOT help with donors who actually submit the form twice in short succession due to not seeing the TY page for whatever reason. For those donors, maybe we keep a map in memcache of 'email + ip address' => order id . We set that before making an API call, then if the donor tries to donate and we see it's already there, we can check the status of the payment

Looking at the failmail it looks like its been these same two all along. The duplicates have been refunded in Adyen. We will still get messages from the audit (what's causing the failmail) until they get updated from Adyen's side.

Happened again, unintended iDEAL recurrings:

CID: 56931719
Correct one in civi: B528PP5MM6MDP672
Duplicate in adyen: DW8Q3T3JT869BV62

CID: 56981862
Correct one in civi: PXGWW7QX48FVMM42
Duplicate one to refund: WZKJH7ZL495CKMG2

Current status:
Duplicate iDEALs were making the second failmail in this chain, they are true duplicates and the one not in civi can be refunded. I think its ok to be making the failmail as I am not sure we have another way to catch these.

As of 10/5 the orignial error started happening again but from a different source T320587: Back again but from donations queue consumer: INVALID_MESSAGE Recurring donation, but no subscription ID or recurring payment token found

Dwisehaupt added a subscriber: Dwisehaupt.

Confirmed as complete at standup.

Change 828094 abandoned by Ejegg:

[wikimedia/fundraising/crm@master] Set contribution_recur_id when token found

Reason:

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