Contribution status remains pending - line item is completed
I see this with recurrings set for the 1st of the month. The charge goes thru, the line item is set correctly to completed but the overall contribution status is remains pending.
Similar issue to #260 (closed)
Activity
Great, thanks for feeding back @andyburns
It's still occurring intermittently it seems. I see an overall pattern of not updating contribution status to completed. I have a recurring that was setup on November 19th (after the latest fix #260 (closed)) and it looks kjust like https://lab.civicrm.org/extensions/stripe/uploads/fb4286591a205a5c7c43f314eb6e240d/Untitled.png
Edited by andyburns-
Hi @andyburns that seems weird - which version of civi?
5.31
I did an audit of all the recurring that ran on the 1st. A handful did not even report back that a contribution was made which is not germane to this issue but generally Stripe to Civi works pretty darn good, but not always.
Edited by andyburnsmentioned in issue #282 (closed)
I've done another audit for the recurrings that have run on 1/1/21. I have 44 erroneous pendings out of 221 recurrings.
It looks like 2 different cases (20 that have invoice and charge ID)
- Same as first report of this issue where line item is correct but contribution status is wrong.
- Nothing is right, no line item, contribution status remains pending. Clearly Stripe webhook failed, didn't try, etc. You see that this person did have his previous 2 recurring succeed. (22 that only have invoice ID)
I did an export from Stripe and did 2 Vlookups with all the pendings in Civi and matched with the ch_..." (e.g. ch_1I4jVaGUXvR5yNIIbyk1jLe4) and invoice ID respectively . That is the charge, by the way, what is the proper name for this "ch_..." id? Charge ID?
So to manually resolve this I went to import this contribution with the update contributions method. I included financial type, total amount and transaction ID. However, looking at mysql, it is storing invoice id and charge id as comma separated values in that field? The import failed because Civi then cannot do an update contribution import because it cannot match on transaction ID. Or am I doing something wrong? How can fix these without doing my hand?
Can webhooks be sent from Stripe manually? Does Stripe try additional times after failure? As we get more recurring logged thru Civi it will become a big issue to keep donor data correct.
Separately, why does the transaction ID field have different data points for completed transactions? Here is the variations:
- Only the invoice ID
- Both the invoice ID and charge ID
- Subscription ID and charge ID
On Civi 5.31, WP 5.5.3 multisite, Stripe 6.5.5, MJW Shared 0.9.9
Edited by andyburnsStripe support says:
Yeah, so just checking through our resources; We timeout after 20 seconds when sending an event. Some endpoints could have a shorter timeout at 5 seconds if they are consistently not acknowledging events from Stripe. I'm afraid the limit can't be raised, so Stripe suggests that you shouldn't do operation heavy code in your handler and should simply acknowledge reception of the event by responding quickly, and handle your own logic asynchronously instead. Here's also a piece of documentation I hope should assist: https://stripe.com/docs/webhooks/best-practices#retry-logic
Our webhook failure rate is currently 9%.
Looking under the webhook failures in Stripe, I've checked a handful and they are marked completed in CRM :/
Edited by andyburns-
It seems there are some issues on some sites but it is difficult to track down what is the cause.
To retry webhooks manually you have two choices:
- https://docs.civicrm.org/mjwshared/en/latest/api/#mjwpaymentnotificationretry - "replays" them from the CiviCRM system log.
- https://docs.civicrm.org/stripe/en/latest/api/ - Call Stripe.Ipn with the event ID from stripe and payment processor ID.
It should always be ok to re-run webhooks because the extension should detect they've already been processed and ignore them. For testing I have also deleted contributions/payments and then re-triggered the webhook (but this is more dangerous and not recommended).
Stripe will retry a few times. Are you suggesting that some webhooks may be timing out? I think you should be able to see this in the webhook/event details on the stripe dashboard if that was happening?
Separately, why does the transaction ID field have different data points for completed transactions? Here is the variations: See: https://docs.civicrm.org/stripe/en/latest/faqs/#invoices-and-charges
It gets a bit complicated with recurring contributions because we don't always have all the IDs from Stripe to start with so we have to set something and then change it. In general the extension tries to use the payment (civicrm_financial_trxn)
trxn_idfields to match contributions which may have more than one ID (eg. if there is a payment + a refund) and the contributiontrxn_idfield should not be relied on (it should end up as a comma separated list of payment transaction IDs. 
I didn't get an error but it also did not make any change. Still pending. Does that look right though?
I don't follow the exact steps to use https://docs.civicrm.org/mjwshared/en/latest/api/#mjwpaymentnotificationretry
I guess this still looks pretty manual or is there a way to reply all IPN's on a given day?
Edited by andyburnsAuditing Feb 1 recurrings:
Some notes while I do it:
- some only have an invoice ID
- some only have charge ID
If I save the contribution status to completed, the transaction ID field then populates with invoice ID. It had no line item before.
I am also seeing some recurrings where it is adding 2 contributions. One is marked completed and the other pending.
An interesting observation is a donor setup a yearly recurring on 1/6 for $25. That was successful. However, Stripe sent an erroneous webhook on 2/1 for $25. Maybe related to: #296 (closed).
Recurrings:
mentioned in issue #413
