Recurring Contribution marked as 'Pending (Incomplete Transaction)'

At least some of your issue might be addressed in #282 (closed).

@mattwire following post by @jamie, I updated to Stripe v6.6-dev and MJShared 1.0-dev

webhooks are no longer failing, but transactions remain 'Pending (incomplete transaction)' (see screenshots)
no errors in the logs What do I need to do to get the transaction status updated automatically to 'Complete' Thanks

You can use the api via the cv command.

First, list all pending transactions:

cv api Stripe.Listevents ppid=<your-payment-processor-id> filter_processed=1 limit=100 source=systemlog

Note the system log id in the output, and then re-run the notification for each unprocessed event:

cv api Stripe.Ipn ppid=<your-payment-processor-id> id=<system-log-id> suppressreceipt=1

Note - the suppressreceipt=1 part will prevent a receipt going out which is sometimes confusing to donors since it is out of sync with when they made the donation.

Thanks @jamie the first command worked, but the second produced an error

cv api Stripe.Ipn ppid=1 id=25561 suppressreceipt=1 { "is_error": 1, "error_message": "Call to undefined function bccomp()" }

Following this link https://stackoverflow.com/questions/44049812/php-call-to-undefined-function-bccomp

I was then able to install php-bcmath, then the command worked

cv api Stripe.Ipn ppid=1 id=25561 suppressreceipt=1 { "is_error": 0, "version": 3, "count": 1, "values": true }

Now the Cotnribution shows 'Completed' status

Is the advice to run this for every Contribution individually, every time there's a recurring payment?

if so then I understand this to be a workaround, whereby we could run this as a batch job assuming we can extract the system log id from the output of the first command
obviously the next question is resolving the issue so it is done automatically

Thanks

Exactly - as far as I can tell, the 6.6 release will have this problem fixed, so you won't need to run these commands at all.

For the time being, you can either run them individually as described above, or if you are feeling brave, I included a Stripe.Retryall that takes a ppid agrument and a limit argument. It will attempt to retry the most recent limit events that have not been processed.

I had tried the 6.6 release as well as the updated MJWShared however got an 'unknown error' when making payments which I couldn't troubleshoot. So I've rolled back for the present, so can't provide any further insight. Assuming the 6.6 production release is not too far away, and hopefully the error will have been resolved if found in testing. Thanks.

@MickC - did you try the latest 6.6? They are now master branch of Stripe + mjwshared and release will be soon. If you downgrade you need to change one fieldname in the civicrm_stripe_paymentintents table because it changed in 6.6.

To troubleshoot the "unknown error" start by enabling javascript debugging and see what is in the browser console (F12 on Chrome) when it goes wrong.

mentioned in issue #306 (closed)

added Waiting confirmation label

Hi Matt - the issue is persisting,

I had already tested dev versions of 6.6 but now have the official release installed
see attachments show

the same confirmation message ('Your contribution has been submitted to Stripe for processing.'
Contribution status'Pending (incomplete trasnaction)'
Stripe successful subscription![confirmation_screen]

(/uploads/dc3f5b105f321818bcd500b0370c63df/confirmation_screen.png)

@MickC Please can you check that you have the "Process Paymentprocessor Webhooks" job enabled and running and that it is showing no errors? Also, please check the civicrm_paymentprocessor_webhooks table and see if any are "stuck" in "processing" status. If status = "processing" set status=NULL and re-run the webhook job.

Hi Matt - seems to be working now.

A complication in my setup is that it's a multisite, so the job was active for domain 2
I have inserted a copy for Domain 1
also saw the message about Access AJAX API and enabled for all users
lastly, the Webhooks seemed to need to be fixed again Not sure which of thse did the trick, but now my transaction shows Completed, with a transaction ID

Will continue to monitor and either update or close accordingly.

Thanks for your help! Cheers

I'm experiencing the same issue as the OP. Recurring subscriptions are successfully created and processed in Stripe, but the status is 'Pending (Incomplete Transaction)' in CiviCRM. See the following image:

Webhook attempts in Stripe are all successful (i.e., there are no failed webhook attempts). The following image shows the webhook attempts in Stripe for the recurring subscription in the above image.

My civicrm_paymentprocessor_webhook table shows "Success" for every single ID/transaction (none are stuck in a "processing" status).

I'm using the following: CiviCRM 5.37.2, Stripe PP 6.6, Payment Shared 0.1.0, WordPress 5.6.4

Any suggestions would be deeply appreciated.

Hi @richlivi - Did you check your ConfigAndLog for that date/time? There may be clues there. Do you have php-bcmath installed?

Also, you can manually re-run the web hook using the cv command:

cv api Stripe.Ipn ppid=$ppid evtid=$evtid suppressreceipt=1

Replace $ppid with your payment processor id and $evtid with the event id of the charge.succeeded event.

If it is successful and the status is upated in CiviCRM, well, then we don't learn much about why it failed before. But, if it fails you should get an error on the console or in ConfigAndLog that might be revealing.

Hi @jamie, thank you for responding.

There's nothing in the ConfigAndLog for that date/time.

php-bcmath is installed.

I ran the following: cv api Stripe.Ipn ppid=3 evtid=evt_3JLTRhC7LJMrzm5K08Da3K0G suppressreceipt=1

And it produced the following: { "is_error": 0, "version": 3, "count": 1, "values": true }

So there were no errors (on the console or in ConfigAndLog), and the status didn't change--i.e., still 'Pending (Incomplete Transaction)'.

Just to be certain, I created a new recurring subscription and got the same result. That is, the payment was processed and credit card successfully charged; it didn't produce any errors in CiviCRM; it didn't change the status to completed; and re-running the web hook (using the command above) produced the same result with no errors (on the console or in ConfigAndLog).

Any other suggestions?

Well, the good news is that it's reproducible :).

I should have mentioned this in my earlier post... If you go to Admninister -> CiviContribution-> Stripe Settings, you should see a setting called "Enable Stripe IPN (Webhook) debugging?". Check that box. Then try re-running the cv command and see if you get any useful output in ConfigAndLog.

Often in cases like this we can't locate the original recurring contribution or something along those lines.

If you still don't get anything useful, you may need to add some extra debugging in the StripeIPN.php file, but hopefully we'll get the cause of the problem without that.

@jamie

I already had 'Enable Stripe IPN (Webhook) debugging?' checked/enabled. But I upgraded CiviCRM and WordPress, so I'm now using CiviCRM 5.40.2 and WordPress 5.7.2 (Stripe PP 6.6 and Payment Shared 0.1.0 are the same).

I created a new recurring subscription, and the results are the same, with one minor (probably non-relevant) exception.

The payment was processed and credit card successfully charged.
No errors were produced in CiviCRM or Stripe.
The payment status is 'Pending (Incomplete Transaction)'.
Re-running the web hook using the cv command above produced the same result with no errors (on the console or in ConfigAndLog): { "is_error": 0, "version": 3, "count": 1, "values": true }

The only difference is that the ConfigAndLog shows the following warning: Aug 19 17:13:42 [warning] Deprecated join alias 'payment_processor' used in APIv4 get. Should be changed to 'payment_processor_id' Caller: Civi\Api4\Query\Api4SelectQuery::autoJoinFK Array ( [civi.tag] => deprecated )

And it looks like that warning is produced every time my cron job runs.

Yeah, unfortunately, I think that warning is a red-herring.

I'm stumped - I'm not sure what to suggest other then littering the code with \Civi::log()->debug("debug 1"); statements and running and re-running the cv command until you identify where the status is suppose to change and why it isn't changing. CRM/Core/Payment/StripeIPN.php is a good place to start, but you might need to dig into the core CiviCRM code to really understand. Maybe @mattwire has a better suggestion?

mentioned in issue #413

Recurring Contribution marked as 'Pending (Incomplete Transaction)'

Designs

Child items ...

Activity