1

Using 1.5.3, Civi 4.6.26 on D7. In scheduled jobs, the "iATS Payments Recurring Contributions" job is set to run daily. The logs for this event show a record for "Starting execution of iATS Payments Recurring Contributions" but no record for "Finished execution of iATS Payments Recurring Contributions". No "With Result: Success", etc. This has been happening only since February 10 when we updated CiviCRM from 4.6.19 to CiviCRM 4.6.26. Before that, the logs appear as usual with starting and finishing.

The question I am asking may be related to a question I asked last week at Why does the user not get a "transaction complete" or "success" confirmation message after submitting an online transaction? This question is still unresolved (I followed KarinG's suggestion and turned off the "send PDF with receipt", but still don't know why it isn't working properly). Probably is related.

I am assuming that iATS server is supposed to send something (IPN?) to complete the process in Civi and that either it is failing to send, or we are not receiving or CiviCRM is not interpreting what is received properly.

In any case, just to double-check, what should the url settings be in my iATS payments configuration (I have three different processors enabled: credit card, ACH and POS swipe)? I haven't changed anything recently, other than the update, but I just want to make sure the processor is still properly configured (I can't seem to find any documentation on the urls for the iats payments config).

Thank you in advance, Karin, for any help or insight you can give.

10
  • I have had similar issues with the other iATS job. See here: civicrm.stackexchange.com/questions/13127/… for reference. Are you able to complete the job if you run it from the command line (via drush or through your cron setup)? Commented Feb 21, 2017 at 18:56
  • Perhaps relevant: I also experienced an issue with the Recurring iATS job: civicrm.stackexchange.com/questions/14544/… Commented Feb 21, 2017 at 18:57
  • Were you able to resolve these using the suggestions? If so, it appears that Karin suggested using two separate server Crons to run scheduled payments and verify as opposed to the iATS "Scheduled Jobs" (turned off?) in the Civi Admin GUI. Is that correct? Commented Feb 21, 2017 at 20:07
  • Turns out there were a number of ways to come at this, but Karin's suggestions got us in the right direction. We have both jobs ENABLED in the Scheduled jobs, and we have a cron run that executes the execute function. The Recurring job is set to Daily via Scheduled jobs, and Verification is run hourly. Another kicker for us was we were often running the Recurring job when iATS was down for maintenance between 12-1am PST. We had to account for time differences in our cron run with where our server is located so we didn't run the job during maintenance hours. Commented Feb 21, 2017 at 21:22
  • /usr/bin/php /usr/bin/drush --root='SITE ROOT LOCATION ON SERVER' --uri='SITE URL' -u 1 civicrm-api job.execute auth=0 -y The time setting for this job is 7 0-7,10-23 * * *. The 7 minutes past the hour is so that other hourly jobs can finish first. The 0-7,10-23 accounts for the time difference and skips 12:07am and 1:07am (for Daylight Saving Time). If this ends up helping you in some way, I'll write it up as an answer all formal-like. :-) Commented Feb 21, 2017 at 21:28

3 Answers 3

1

a Couple of thoughts:

  • The Site URL is not the issue. Yes it has changed but I've confirmed older URLs have not been deprecated - and are fully functional.

  • I just verified on a site/project that Using 1.5.3, Civi 4.6.26 on D7 recurring job starts and finishes successfully - with a standard CiviCRM cron (set job to ON on scheduled jobs page)

  • You definitively want no PDF receipts to go out with your Email
    receipts. If you are still getting DOMPDF errors - do you have any
    other custom functionality that's trying to create/attach a PDF?

  • The recurring payments job - sends the tokens to iATSPayments -> and immediately receives a transaction ID. There is no IPN.

  • Try this: go to your Reports -> Create Reports from Templates -> and go to iATS Payments Recurring Contributions Report -> Preview Report -> do you have any next scheduled contribution dates in the past? If so then let's try trigger them manually:

  • Go to your Scheduled jobs and on the right side -> hit Execute Now. Check the log -> did it run successfully?

  • If not go to this Table: civicrm_iats_request_log and check to see which requests were made; then check the civicrm_iats_response_log for any answers from iATS.

Ok let us know what you find out.

0

Resolved. As Karin pointed out, the problem is with dompdf. I discovered that there is a setting in "Administration=>CiviContribute=>civiContribute Component Settings=>Enable Tax and Invoicing=>Automatically email invoice when user purchases online" that NEEDS TO BE OFF in order for the transactions to complete through CivCRM via the iATS Payments Recurring Contributions scheduled job. Otherwise the job starts and never finishes (it also does not send a "success alert" to the user after making a one-time contribution and does not update the "next scheduled date" field in the recurring table.) I had completely overlooked this (probably obvious culprit) when I searched for functionality that tries to create/attach PDFs to transaction emails.

Karin, you may want to test this yourself. Don't know if this conflict exists for 4.7x.

As of now, I believe that this is the only setting that was causing the problems with the job not finishing. I will gradually turn other settings back "on" to further test (right now all my custom scheduled jobs and the settings for sending attached PDFs to receipts are "OFF").

Whew! Working now. Certainly don't need "invoice" functionality at all. Thank you Karin and Allen for all your kind help!

2
  • Phew! DOMPDF has lots of memory/issues - and has already been replaced by TCPDF in Core in several places (like e.g. mailing labels generation) - but auto PDF anything is a scary idea - it's not payment processor specific. Commented Feb 23, 2017 at 18:19
  • That sounds like a feature that should not be so easy to turn on, and not in core at all if it breaks a normal install routinely without appropriate messaging or logging.
    – Alan Dixon
    Commented Feb 23, 2017 at 18:38
0

I'm curious about the observation that it only started happening after a Civi upgrade from 4.6.19 to 4.6.26. I notice that 4.6.19 came out just before 1.5.3 and 1.5.3 is still the recommended release for 4.6. In other words, if it was triggered by your civi upgrade, I suspect there is something else more subtle going on, and it's unrelated to iATS.

In any case, that job shouldn't be failing silently -- that suggests a critical error before it even gets started. I'd recommend turning on all your logging, manually triggering the job, and then seeing what comes up in your logs.

3
  • Alan, the issue is fully resolved and had nothing to do with the upgrade. See my answer above. The setting in the invoice component just happened to be enabled AT THE SAME TIME that we upgraded (I was just checking it out). A coincidence. So, I believe the failure has to do with only this setting. Take a look at the answer I posted. Like I said, don't know if the "incompatibility" (Invoice component enabled with "send invoice" and iats recurring payments scheduled job) is still a problem in 4.7, but it was a big problem for me in 4.6.26. Commented Feb 23, 2017 at 18:04
  • Ah, thanks. Just to pursue this line of thought a bit further, I would expect that if dompdf (or any other function) causes the code execution to stop, there would be some trace, somewhere, and knowing the specifics might help us prevent a recurrence. Any chance you have access perhaps to your php and/or http log? I'm still guessing it was a critical error that didn't allow the iats extension job to even do it's normal error handling to report back to you.
    – Alan Dixon
    Commented Feb 23, 2017 at 18:43
  • Yes. You are right. Something critical happened and I got no alert or error from iats logs in scheduled jobs (or anywhere else that I know of). I should have access to logs you mention. Where are they? How do I enable? If its not something I can see here I can ask the server admin. Commented Feb 23, 2017 at 18:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.