Recurring payments coming into CiviCRM with wrong date (Dec 1969)

I updated a Drupal 7 site from an earlier version (5.0 I believe) to 5.3.2 last week. Things in general seemed okay, and I updated the webhook accordingly as well as updating the Stripe API version in their account. I'm told that recurring payments are not reporting back into CiviCRM -- they are charged correctly in Stripe but do not appear in the contact's CiviCRM record.

These recurring payments may have been set up years ago, as they have been using this extension for a long time. If recurring payments seem to be working okay in general, is it possible these plans are just missing some info in the database from one or another upgrade over the years? How would I start to track that down?

I notice in civicrm_stripe_subscriptions that about half of the recurring donations do not have an invoice_id value. Is that something that is required, and if so, can I copy it from their Stripe account somehow and add it directly to the database?

More info:

• One of the two contributions that this happened to was created in 2016, but the other was set up in Dec 2018 (so after they were on 5.0 for sure). The 2016 one does have a value for invoice_id but the 2018 one does not.
• Verified: a CiviCRM receipt was sent even though no transaction shows on the contact record.

Non-recurring online donations show up as expected.

I'm not sure if it makes a difference but this site has a different number for the payment processor (it's usually 1 but I suppose they've had other processors installed over the years -- although Stripe is the only one currently -- and the payment processor number on the site in question is 5). I've set up the webhook as https://example.com/civicrm/payment/ipn/5 and Stripe seems to be sending the webhook fine and receiving a 200 code back.

@laryn The only database table used by the current extension is civicrm_stripe_customers. We don't delete the other tables on upgrade (yet) in case they contain historical data useful for troubleshooting. Also note that the email field is no longer used in civicrm_stripe_customers.

You could try running both of the StripeSubscription API calls (after taking a DB backup) to see if any errors are reported or if the issues are fixed. They should be run during the extension upgrade but in the case of bad data it's possible they won't run properly - they should be safe to run multiple times.

Fundamentally I think you need to make sure that the stripe subscription ID is in the recurring contribution trxn_id on the contact record and that you have a customer linked to the contact ID in the civicrm_stripe_customers table. Look at one that doesn't work, post the anonymised details here if you like and hopefully that will identify the issue.

added support label

@mattwire Okay, I've done further digging based on that direction and things are a little different than I thought. The database table checks out for the contacts with recurring donations that have come into CiviCRM improperly (although I did see a bunch of entries in civicrm_stripe_customers with a NULL value for contact ID -- should those be deleted?).

What I've found is that the donations are actually being saved correctly, but the recurring donations that get triggered by Stripe are coming in with a date of "December 31, 1969 7:00 PM" and so I didn't see them. They went way to the bottom of the list of donations for these donors. So... completely different issue. I'll see if I can update the title of this thread.

changed title from Recurring payments not showing up after upgrade to 5.3.2 to Recurring payments coming into CiviCRM with wrong date (Dec 1969)

I'm seeing the same issue, and I'm about to dig in. The one piece of the puzzle I can currently add is that I have advanced logging on. In my case, these are all initial payments on a recurring contribution, and they have one INSERT and two UPDATE records in the log. The date is fine in the first two records, but the third record is the one that removes the date. It also sets the contribution_status_id to "Completed" and populates the trxn_id.

added bug label

mentioned in issue #51 (closed)

@JonGold Curious if you found anything that would cause this. I just tested on a separate Drupal 7 site, using Webform CiviCRM to set up a recurring series of installments for the test. I don't know if that introduces any additional variables to the test. Here's what I found:

• The payment goes through as expected, and sets up a Subscription/plan as expected in the Stripe account.
• In CiviCRM there are two completed contributions added and marked as recurring (and one recurring contribution listed in the "Recurring" tab). One of the completed payments has the correct date, and one has December 31st, 1969 7:00 PM. (NB: There is only one payment completed in the Stripe account).
• At this point I went into Stripe and refunded the payment and cancelled the Subscription.
• Now in CiviCRM, the payment with the 1969 date is marked as Refunded, and the Recurring payment is marked as cancelled. The second payment in CiviCRM (with the correct date) is still there and not marked as Refunded.

@laryn I'm afraid not - and I'm not going to get back to this for a couple of weeks. My intended strategy is to enable MySQL query logging, ID the query that causes this behavior (it should be the second UPDATE query referencing civicrm_contribution, per my earlier notes) and deduce from that query where I can get a useful backtrace from.

@JonGold Thanks, I'm going to do a little testing today. I'll let you know if I come up with anything.

I think this line (188) may be the problem:

https://lab.civicrm.org/extensions/stripe/blob/master/CRM/Core/Payment/StripeIPN.php#L188

'receive_date' => $this->receive_date,

I have it commented out on a live site that has another recurring contribution coming at the end of the week, so if nobody else verifies before then I will report back results after that...

mentioned in merge request !37 (closed)

@mattwire Can confirm that the recurring payment that came through today has a current date/time on it rather than Dec. 1969 after I commented out the line described above. I PR'ed in case that looks like the right fix to you: !37 (closed)

@laryn I assume you made this change in production against 5.3.2 and not master? The equivalent fix didn't work for me on 5.3.2, but when I updated to master, recurring donations were completely broken (I submitted two MRs that got them completing for me).

Part of the issue is that creating test contributions is also borked on 5.3.2, but not master, but master's not ready for production use. So I end up creating live contributions to test this, which isn't great.

I'll see if I can find a version between 5.3.2 and master that will allow me to submit test contributions. FWIW, the problem doesn't seem to exist on master.

@laryn @JonGold Could you confirm if this issue still exists on master?

@mattwire Looks like @JonGold solved things in a better way and you've merged -- awesome! I will try to test the latest master soon (in and out of the office for a little bit here).

@laryn I'm going to close this - please re-open if there is still a problem

closed

mentioned in issue #63 (closed)

I have written a script to back-fix all the wrong contribution dates, if anyone wants it :-)

@artfulrobot Happy to include in the extension repo if it's useful to others :-)

If anyone wants it, there's a script to fix existing Contributions here: https://lab.civicrm.org/artfulrobot/stripe/blob/issue/44/utils/fix-issue-44.php

mentioned in issue #71 (closed)