Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recurring Payment: Statuses stuck on Pending #26

Open
joetri opened this issue Dec 21, 2013 · 16 comments
Open

Recurring Payment: Statuses stuck on Pending #26

joetri opened this issue Dec 21, 2013 · 16 comments

Comments

@joetri
Copy link

joetri commented Dec 21, 2013

I've got a recurring payment set up for a membership. It runs and connects to stripe and has pulled funds correctly twice: today and a week ago. So it seems like stripe is doing its job smoothly.

My problem is that my contribution status for the membership is "Pending (Incomplete Transaction)" and membership status is shown as "Pending".

I set the membership payment to be automatically recurring. I know earlier there was an issue with the end date for the recurring payment and wonder if this might be related.

Any ideas or suggestions welcomed.
Drupal 7.17, CiviCRM 4.4.2, Civicrm_Stripe 4.4-1.7 downloaded via Civi official extension source on Dec. 3, 2013.

@drastik
Copy link
Owner

drastik commented Dec 21, 2013

No, not about the end date. Just a different status number in
Webhook.php. It's completely arbitrary.

This change will be made soon.

@joetri
Copy link
Author

joetri commented Dec 23, 2013

l think the following is the expected intuitive behavior after a recurring payment subscription has been successfully established with Stripe and the initial funds withdrawl has happened. Once you've got the first payment in a recurring series, you assume the membership is good and paid up in full (for now).

Looking for change in status possibly to 5. Extension code lists “Successful charge & more to come so set recurring contribution status to In Progress.” for the “In Progress" status code.

Changes should reflect in the following areas:

(a) Contributions pages at https://base_url/civicrm/contribute/search?_qf_Search_display=true, statuses should not be Pending.

(b) Memberships at https://base_url/civicrm/member?reset=1, statuses should not be Pending.

(c) Membership detail page (https://base_url/civicrm/contact/view/membership?reset=1&id=2&cid=6&action=view&context=dashboard&selectedChild=member&key=53a12817554ca53f8e60ea96076258c2_3193), should not show status “Pending (Incompelete Transaction)”.

(d) Initial email receipt should get sent to new member with all details pertinent to their recurring membership payments.

@DaveBagler
Copy link

Hi @drastik, just wondering if this issue has been addressed? If not, I might be able to make a patch if you can point me in the right direction.

@deweydb
Copy link

deweydb commented May 19, 2015

+1 also experiencing the same issue.

@drastik
Copy link
Owner

drastik commented May 19, 2015

Hi @DaveBagler, it just needs to assign a different number in this file:
https://github.com/drastik/com.drastikbydesign.stripe/blob/4.5-dev/CRM/Stripe/Page/Webhook.php

By @joetri's post, it looks like this number should be 5.
This line might also need updated to use status "5":
https://github.com/drastik/com.drastikbydesign.stripe/blob/4.5-dev/CRM/Core/Payment/Stripe.php#L633

@deweydb
Copy link

deweydb commented May 19, 2015

5 is what it is already set to in my copy of webhook.php:

      // Successful charge & more to come so set recurring contribution status to In Progress.
      $query_params = array(
        1 => array($invoice_id, 'String'),
      );
      if ($recur_contrib_query->contribution_status_id != 5) {
        CRM_Core_DAO::executeQuery("UPDATE civicrm_contribution_recur
          SET contribution_status_id = 5
          WHERE invoice_id = %1", $query_params);

        return;
      }

@drastik
Copy link
Owner

drastik commented May 19, 2015

Is the webhook getting triggered? Stripe successfully hitting Civi and updating/creating new contribution records?

@deweydb
Copy link

deweydb commented May 19, 2015

Yeah, i checked the database and there is a contribution record in there, with a contribution_status_id of 2. I'm actually thinking it is this part that isn't getting called:

    $first_contrib_check = CRM_Core_DAO::singleValueQuery("SELECT id
      FROM civicrm_contribution
      WHERE invoice_id = %1
      AND contribution_status_id = '2'", $query_params);

    if (!empty($first_contrib_check)) {
      $query_params = array(
        1 => array($first_contrib_check, 'Integer'),
      );
      CRM_Core_DAO::executeQuery("UPDATE civicrm_contribution
        SET contribution_status_id = '1'
        WHERE id = %1",
        $query_params);

      return;
    }

@deweydb
Copy link

deweydb commented May 19, 2015

Not sure if related, but this error shows up in my logs every time someone makes a recurring donation through stripe:

Stripe Notice: Undefined property of Stripe_Subscription instance: fee

@joetri
Copy link
Author

joetri commented May 19, 2015

Sorry, I no longer have this instance up and running. It's been a while. As I recall, all ran smoothly in Stripe and funds transferred nicely. I was going to just hack statuses (hopefully in a smooth way) so that Civi realized all was copacetic.

@deweydb
Copy link

deweydb commented Jul 3, 2015

Well i'm back at this problem again after a few months of not working on it. @drastik when you asked "Is the webhook getting triggered?" you were on the right path. I just did a test and it appears that it is not triggered. Any idea why this might be?

Ok, i'm a bloody fool. i forgot to update my stripe settings after moving domains. So the webhook was still poking the old domain.

But i have found a ton of inconsistancies between the data stripe returns and what webhook.php is expecting.

For example:
stripe sends:

[type] => charge.succeeded

but webhook checks:

switch($stripe_event_data->type) {
  // Successful recurring payment.
  case 'invoice.payment_succeeded':

Actually further down webhook.php has this bit of code:

  // One-time donation and per invoice payment.
  case 'charge.succeeded':
    // Not implemented.
    return;
    break;

But this is not a one time donation. perhaps stripe has changed how they return data.

@DaveBagler
Copy link

When I updated to the latest release it solved the problem I was having with recurring payments.

@laryn
Copy link
Contributor

laryn commented Jul 7, 2015

@DaveBagler Do you have this issue with recurring or are you not using automatic receipts? #73

@drastik
Copy link
Owner

drastik commented Jul 7, 2015

@deweydb Good find on the return statuses. It is very possible that they changed it, already in the past they introduced major changes twice that completely broke previous integrations (without a warning to implementers!).

I love their service, but I wish they gave more consideration to plugins. When they make those integration-breaking changes things work fine if you don't update your API setting within Stripe.com account, but new accounts are automatically set to the latest API (to which a plugin may not have been updated for).

@DaveBagler
Copy link

@laryn I am sending automatic receipts but they seem to be working just fine so I'm haven't run into #73.

@laryn
Copy link
Contributor

laryn commented Mar 30, 2016

@DaveBagler @drastik I am still running into this issue with a version of 4.6-dev from yesterday. Strangely, recurring donations work fine in test mode, but are stuck as Pending in live mode. I set up a test recurring donation that recurred daily, and those fired as expected, updated in CiviCRM, sent a receipt from CiviCRM. But when I try a recurring donation in live mode, it gets stuck at Pending.

Is this something specific to my installation!?

The 'invoice.payment_succeeded' webhook fires from Stripe but the response from Civi is: " A fatal error was triggered: is not of the type Boolean "

Here is the backtrace:
$backTrace = #0 /path/to/drupal/sites/all/modules/civicrm/CRM/Core/Error.php(322): CRM_Core_Error::backtrace("backTrace", TRUE) #1 /path/to/drupal/sites/all/modules/civicrm/CRM/Utils/Type.php(271): CRM_Core_Error::fatal(" is not of the type Boolean") #2 /path/to/drupal/sites/all/modules/civicrm/CRM/Contact/BAO/Query.php(5330): CRM_Utils_Type::escape(FALSE, "Boolean") #3 /path/to/drupal/sites/all/modules/civicrm/CRM/Contribute/BAO/Query.php(432): CRM_Contact_BAO_Query::buildClause("civicrm_contribution.is_test", "=", FALSE, "Boolean") #4 /path/to/drupal/sites/all/modules/civicrm/CRM/Contribute/BAO/Query.php(251): CRM_Contribute_BAO_Query::whereClauseSingle((Array:5), Object(CRM_Contact_BAO_Query)) #5 /path/to/drupal/sites/all/modules/civicrm/CRM/Core/Component.php(315): CRM_Contribute_BAO_Query::where(Object(CRM_Contact_BAO_Query)) #6 /path/to/drupal/sites/all/modules/civicrm/CRM/Contact/BAO/Query.php(1943): CRM_Core_Component::alterQuery(Object(CRM_Contact_BAO_Query), "where") #7 /path/to/drupal/sites/all/modules/civicrm/CRM/Contact/BAO/Query.php(495): CRM_Contact_BAO_Query->whereClause() #8 /path/to/drupal/sites/all/modules/civicrm/CRM/Contact/BAO/Query.php(459): CRM_Contact_BAO_Query->initialize() #9 /path/to/drupal/sites/all/modules/civicrm/api/v3/utils.php(590): CRM_Contact_BAO_Query->__construct((Array:3), (Array:1), NULL, FALSE, FALSE, 2, TRUE) #10 /path/to/drupal/sites/all/modules/civicrm/api/v3/Contribution.php(217): _civicrm_api3_get_query_object((Array:6), 2, "Contribution") #11 /path/to/drupal/sites/all/modules/civicrm/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_contribution_get((Array:6)) #12 /path/to/drupal/sites/all/modules/civicrm/Civi/API/Kernel.php(96): Civi\API\Provider\MagicFunctionProvider->invoke((Array:9)) #13 /path/to/drupal/sites/all/modules/civicrm/api/api.php(23): Civi\API\Kernel->run("Contribution", "get", (Array:6), NULL) #14 /path/to/drupal/sites/all/modules/civicrm/api/api.php(43): civicrm_api("Contribution", "get", (Array:6)) #15 /path/to/civicrm_extensions/com.drastikbydesign.stripe/CRM/Stripe/Page/Webhook.php(97): civicrm_api3("Contribution", "get", (Array:5)) #16 /path/to/drupal/sites/all/modules/civicrm/CRM/Core/Invoke.php(312): CRM_Stripe_Page_Webhook->run((Array:3), NULL) #17 /path/to/drupal/sites/all/modules/civicrm/CRM/Core/Invoke.php(86): CRM_Core_Invoke::runItem((Array:13)) #18 /path/to/drupal/sites/all/modules/civicrm/CRM/Core/Invoke.php(54): CRM_Core_Invoke::_invoke((Array:3)) #19 /path/to/drupal/sites/all/modules/civicrm/drupal/civicrm.module(489): CRM_Core_Invoke::invoke((Array:3)) #20 [internal function](): civicrm_invoke("stripe", "webhook") #21 /path/to/drupal/includes/menu.inc(527): call_user_func_array("civicrm_invoke", (Array:2)) #22 /path/to/drupal/index.php(21): menu_execute_active_handler() #23 {main}

laryn added a commit to laryn/civicrm_stripe that referenced this issue Mar 30, 2016
My installation was not processing the previous method of checking live/test mode correctly -- test mode would come back positive but live mode was empty instead of negative.

See also drastik#26 (comment)
scardinius pushed a commit to WeMoveEU/com.drastikbydesign.stripe that referenced this issue May 16, 2019
…rom payment form when changing processor
scardinius pushed a commit to WeMoveEU/com.drastikbydesign.stripe that referenced this issue May 16, 2019
Resolve drastik#26 - Make sure we clear processor specific metadata from payment form...

Closes drastik#26

See merge request extensions/stripe!16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants