Recurring donations are not sent a receipt

[henare]

It seems that recurring donations only don't get a receipt when using this payment processor (one-off donations work fine).

[drastik]

Thank you, I will look into this.

What CMS?

[henare]

Thank you, I will look into this.

Thanks! I'm assuming it's a setting on the payment processor.

What CMS?

Wordpress.

[chrisdubrow]

Hi drastik I have also noticed I am having this problem with Wordpress 4.1.1 and civicrm 4.6. Any progress in this direction - great work on this extension BTW Chris

[chrisdubrow]

Yeah still facing this issue. Running Wordpress 4.2.1 Civicrm 4.6.2

Recurring donation runs through fine - i can even get a receipt from Stripe working - but unfortunately that is not good enough because the stripe wording is terrible - and there is no way to add additional words that we need to be a tax invoice etc.

For a single contribution (donation) the civicrm receipt works fine. But when a recur is selected - Nothing is sent (same contribution form)

The only faults I can see using browser console(s) appear if recur function is turned on for the page or not..

Firefox: SyntaxError: illegal character Chrome: Uncaught SyntaxError: Unexpected token ILLEGAL line 635

if ( element.type == 'radio' && element.name == priceset ) {

Firefox: SyntaxError: illegal character Chrome: Uncaught SyntaxError: Unexpected token ILLEGAL

line 1215 if ( allowAutoRenew && cj("#auto_renew") ) {

Any help would be appreciated,

[chrisdubrow]

Ok - i can see from my post above that the error disappears from my saved post (but re-appears in edit mode) sorry if this is very nooby of me- not particularly code-minded.. But in both lines - where there is a "&&"

it reads - "& # 038 ; & # 038 ;" with no gaps

[drastik]

Are we talking about an e-mail when the recurring contribution is initially created? Or an e-mail at each charge?

Does either work in your case(s)?

[chrisdubrow]

Both these emails from civicrm do not work, (initial creation, and on the recur event) But it does work for a non-recur contribution..

[christianwach]

This could be related? https://issues.civicrm.org/jira/browse/CRM-15629

[chrisdubrow]

Hi all So we awaited with baited breath for 4.6.3 to see if the resolution of this issue https://issues.civicrm.org/jira/browse/CRM-15629 would assist with our problem Unfortunately we still have no receipts being send via civi when the recur box is being ticked on the contribution page.

[chrisdubrow]

I am not sure if this is related, but we also had a rejected credit card on a donation attempt. In civiCRM the donation is reporting as complete - but in Stripe it is (correctly) not listed

[kcristiano]

CRM-15629 was targeted at PayPal and the IPN return data. IIRC, CRM_Core_Permission_WordPress is called by the extern/ipn.php file.

When the Stripe Webhook runs for WordPress what is called and does it trigger CRM_Core_Permission_WordPress? We now bootstrap WP here to ensure proper permissions are set and the email notifications can be sent.

[laryn]

I can confirm the same on Drupal 7.36 with CivICRM 4.6.3 -- (in test mode) one-off transactions send the test receipt, but recurring transactions do not send a receipt.

In case it is helpful, the recurring transactions throw an error in the CiviCRM Log file:

May 26 15:05:39  [info] $Fatal Error Details = Array
(
    [message] => One of parameters  (value: NULL) is not of the type Integer
    [code] =>
)

May 26 15:05:39  [info] $backTrace = #0 /path/to/drupal/public_html/sites/all/modules/civicrm/CRM/Core/Error.php(363): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /path/to/drupal/public_html/sites/all/modules/civicrm/CRM/Utils/Type.php(362): CRM_Core_Error::fatal("One of parameters  (value: NULL) is not of the type Integer")
#2 /path/to/drupal/public_html/sites/all/modules/civicrm/CRM/Core/DAO.php(1247): CRM_Utils_Type::validate("NULL", "Integer")
#3 /path/to/drupal/public_html/sites/all/modules/civicrm/CRM/Core/DAO.php(1166): CRM_Core_DAO::composeQuery("INSERT INTO civicrm_contribution (\n          contact_id, financial_type_id, ...", (Array:13), TRUE)
#4 /path/to/drupal/public_html/sites/all/civicrm_extensions/com.drastikbydesign.stripe/CRM/Stripe/Page/Webhook.php(141): CRM_Core_DAO::executeQuery("INSERT INTO civicrm_contribution (\n          contact_id, financial_type_id, ...", (Array:13))
#5 /path/to/drupal/public_html/sites/all/modules/civicrm/CRM/Core/Invoke.php(312): CRM_Stripe_Page_Webhook->run((Array:3), NULL)
#6 /path/to/drupal/public_html/sites/all/modules/civicrm/CRM/Core/Invoke.php(86): CRM_Core_Invoke::runItem((Array:13))
#7 /path/to/drupal/public_html/sites/all/modules/civicrm/CRM/Core/Invoke.php(54): CRM_Core_Invoke::_invoke((Array:3))
#8 /path/to/drupal/public_html/sites/all/modules/civicrm/drupal/civicrm.module(489): CRM_Core_Invoke::invoke((Array:3))
#9 [internal function](): civicrm_invoke("stripe", "webhook")
#10 /path/to/drupal/public_html/includes/menu.inc(519): call_user_func_array("civicrm_invoke", (Array:2))
#11 /path/to/drupal/public_html/index.php(21): menu_execute_active_handler()
#12 {main}

[laryn]

Cross-referenced here: http://civicrm.stackexchange.com/questions/3284/recurring-contributions-not-sending-emails-stripe

@drastik, by any chance do you have any tips on where I can start looking to figure why email receipts aren't sending for recurring?

[deweydb]

+1 stuck on this too.

[eileenmcnaughton]

Note that in the area or dealing with recurring receipts it's important to be on the latest point version as the code dealing with this has been patched frequently (& is largely overhauled in 4.7).

Also note that Stripe processor should set 'payment_status_id' in the return array from the doDirectPayment (or doTransferPayment) to indicate if the payment is complete or not.

For support of versions prior to 4.6.5 (not yet out as of today) contribution_status_id should also be set. Check CRM-16737

(History - CiviCRM used to always assume payment was not completed in real time for recurring to reflect paypal & authorize.net behaviour - & we have been unravelling this assumption.)

[Upperholme]

I'm seeing this problem too. Just testing with Civi 4.6.8.

[Upperholme]

Just to be clear on this, is this an issue for this extension or is it a problem with CiviCRM (or maybe both)? This issue dates back over nine months now - what might be needed to help move things along?

[drastik]

Probably the extension. I hope to be doing a lot of work w/ civicrm_stripe in the next month. I think the first e-mail is sent, but no e-mail for each recurring transaction thereafter. The code in civicrm_stripe is inserting the contribution straight into the DB, where it should probably call a civicrm API function to add the Contribution instead.

[eileenmcnaughton]

Re api / processor 1) from 4.6.8 onwards setting $params['payment_status_id'] = 1 in the doDirectPayment function should be enough to ensure that a recurring contribution is acceptably completed (with receipt sent) (it's a moving target up to somewhere around about that point release). Latest LTS should also work with that.

2) Latest LTS & latest 4.6 support contribution.repeattransaction for creating subsequent contributions

[drastik]

Thanks @eileenmcnaughton,

Can you help me understand what this extension should be responsible for? I will briefly explain how Stripe works, and you can teach me your CiviCRM wizardry in exchange :)

• Stripe's own internal system automatically debits recurring payments.
  • Then, Stripe reaches out to a user-configured endpoint to notify the site of the payment (the Webhook PHP file provided by this extension).

Now, what I am curious to know: Should our Webhook (response catcher) in civicrm_stripe create the new Contribution record for each recurring-triggered payment? Or will the features you mentioned in your last comment also make CiviCRM auto-update?

[eileenmcnaughton]

Once a payment has been made stripe should call contribute.repeattransaction which will create a copy of the original contribution, copying line items etc & make a call on sending out an email based on data on the recurring record

[drastik]

@eileenmcnaughton Awesome! Thank you very much for your insight.

[Upperholme]

For me the first email is not getting sent. Not got to the point yet where emails might be triggered on second and subsequent payments.

[BorislavZlatanov]

@drastik I would like to help getting recurring payments properly working (sending email receipts and so on). If you want to, give me a task and I will try to complete it and make a pull request.

[drastik]

@BorislavZlatanov Sure! If you are familiar with the discussion above with Eileen, we need to:

• Within CRM/Stripe/Page/Webhook.php change the manual Contribution entries via DB queries into CiviCRM API calls to "contribute.repeattransaction".
• Within Core/Payment/Stripe.php, change $params['payment_status_id'] = 1 where appropriate.

[BorislavZlatanov]

@drastik I've pretty much worked out the API calls, however I have very big issues with my localhost that are preventing me from doing development work. I'm using ngrok in order to expose my localhost to the Internet (and be able to receive Stripe's webhooks). Due to some reason, as soon as a Stripe webhook arrives, my apache rapidly starts changing ports and then crashes. I'm using XAMPP.

If I'm not able to solve this issue, another option is to use a site on a server. However, that would not allow me to run the code through a debugger (like I can on my localhost) and check that everything is happening properly in the code, line by line. So I wanted to ask how you have set up up your development environment? Did you use a debugger when you were developing the extension? How did you check that the code works exactly as intended?

[drastik]

@BorislavZlatanov I spun up a dev site on a server to test live circumstances. I don't recall having issues when using Vagrant to manage VMs (and port forwarding) though.

[BorislavZlatanov]

@drastik Just a quick update. I've successfully transitioned from XAMPP to Varying Vagrant Vagrants and a new IDE and (thanks to this awesome tutorial: https://danemacmillan.com/how-to-configure-xdebug-in-phpstorm-through-vagrant/) I've started to work on this extension.

So far I've made a few changes from SQL queries to API calls and resolved a couple of difficult (for me at least) Civi bugs along the way. The email receipt for recurring payments is now being sent. But there are at least a few broken things that I'm seeing (such as the Stripe fee not being recorded in the database, wrong or no Transaction ID, sometimes even Invoice ID is missing). Would it be better if I submit a pull request with my changes so far (in my view, the code is not ready to be used in production yet), or shall I continue to work on it for some more days and then show the result?

[drastik]

@BorislavZlatanov Hooray for recurring receipts. Now is probably a good time for a pull request, then you can rebase off the large commit I made today.

It includes required database updates that I am trying to figure out how to have the UI auto-call. I think I figured it out :shipit:

[Upperholme]

This issue looks to be closed, suggesting that the processor does now send a first and subsequent email receipts to the contact making the payment. Is that the case? If so, I need to update my installation - should I use the latest 4.6.dev release, or is there a stable production release that includes this fix. I seem to recall a different numbering scheme being used a while back.

[h-c-c]

This is good now....the api contribution.repeattransaction does this by default.