Error: Stripe.js token was not passed! Report this message to the site administrator.(ext ver. 1.9.1)

seajaee commented 9 years ago

@drastik I am getting this error [Stripe.js token was not passed! Report this message to the site administrator.] when using the Stripe processor with a real credit card number as well as a test credit card number on a live contribution page. Also, I don't know how to write code. :(

CiviCRM 4.4.5 Wordpress 3.9.3 Stripe Extension 1.9.1

EranSch commented 9 years ago

@drastik I suspect this is due to the issue noted on #75 -- where the stripe-payment-form class is not longer getting applied correctly.

andywozhere commented 9 years ago

Same issue for me I'm afraid.

CiviCRM 4.5.6 Wordpress 4.1.1 Stripe Extension 1.9.1

EranSch commented 9 years ago

@andywozhere Before you submit the form, do you see any errors in your browser's JS console?

If you're using Chrome, be sure to check 'Preserve Log' so the console doesn't clear out after each each page load. I'm sure there's an equivalent in all the others....

andywozhere commented 9 years ago

@Swingline0 Yes there are a few Javascript errors. It looks like it is omething to do with JQuery. Errors as follow:

Two errors on Common.js line 196 Uncaught TypeError: Cannot read property 'defaults' of undefined and (anonymous function)

// Theme classes for unattached elements
  $.fn.select2.defaults.dropdownCssClass = $.ui.dialog.prototype.options.dialogClass = 'crm-container';
us function)

(anonymous function) error on Common.js line 1077

})(jQuery, _);

Also :

Two errors on en_GB.js line 14 Uncaught TypeError: Cannot read property 'defaults' of undefined and (anonymous function)

CRM.formatMoney('init', "\u20ac 1,234.56");

(anonymous function) error on en_GB.js line 73

})(jQuery);

andywozhere commented 9 years ago

@Swingline0 Sorry those were after I submitted the form. Before I submitted the form I am told that the file at /wp-content/plugins/files/civicrm/custom_ext/com.drastikbydesign.stripe/js/civicrm_stripe.js?r=GoZZa cannot be found.

Upperholme commented 9 years ago

And presumably that file does exist on that path in your install?

andywozhere commented 9 years ago

@Upperholme yep

andywozhere commented 9 years ago

@Upperholme @Swingline0 Solved (for me anyway). Incorrect resource URL. For me the resource URL was

/wp-content/plugins/files/civicrm/custom_ext

drastik commented 9 years ago

@andywozhere Thanks for the update!

Is this where CiviCRM puts extensions by default in WP? Or is that a directory you set up?

andywozhere commented 9 years ago

@drastik You have to set it up there, but it is the folder recommended on http://wiki.civicrm.org/confluence/display/CRMDOC/Extensions. One concern I had was that the URL is written to https://domain.org//wp-content/plugins/files/civicrm/custom_ext which doesn't feel quite right... but it seems to work anyway!

drastik commented 9 years ago

@andywozhere Right, yes it gets re-written with domain name in there.

You can fix it now, (removing the extra /) I've seen some versions of Civi are doing this.

MicahStevens commented 9 years ago

I'm getting this too, trying to troubleshoot. I'm using: CiviCRM 4.6.2 Wordpress 4.1.1

No Javascript errors, I fill out the form and I see the variable being passed from the form:

------WebKitFormBoundaryAc0VWeX4HO8C4Jkw
Content-Disposition: form-data; name="stripe_token"

I don't see any XHR requests going to stripe at all, this is likely the problem. The create customer api call, or whatever this plugin is using isn't working.

I'll keep troubleshooting, I'll update here if I find out anything interesting.

MicahStevens commented 9 years ago

Did some more in depth debugging - It appears in chrome at least, if you also enable the pay by check option in your contribution form the detection of whether you're paying by credit card or not isn't working. This part in particular:

 // Handle multiple payment options and Stripe not being chosen.
      if ($form.find(".crm-section.payment_processor-section").length > 0) {
        if (!($form.find('input[name="hidden_processor"]').length > 0)) {
          return true;
        }
      }

My quick fix was to disable pay by check, since we don't need that right away, but I'll work on a pull request to update this code to make it work.

Hope this helps!

richardsplayground commented 9 years ago

Same issue for me on :

CiviCRM 4.6.2
Drupal 7.37
Extension version 1.9.1 pulled from github on May 14ish

I get the error in two circumstances: 1) When multiple payment processors are allowed for an event. For example, PayPal and Stripe. 2) When the "pay later" option is allowed on an event registration.

No errors appear in the Javascript console.

I was testing in Chrome as well.

Thanks @MicahStevens for your suggested quick fix. I took the route of for now disabling pay later and PayPal. Long term that won't work for us unfortunately.

highfalutin commented 9 years ago

Same issue here, on:

CiviCRM 4.5.8
Drupal 7.36
Extension version 1.9.1, pulled today, May 18

I get the error on one contrib page, but not on another. The differences that I can see are:

	Error	No error
Financial type	membership	donation
Uses price set	yes	no
Confirmation page	no	yes
Start date	in the past	null
Pay later	disabled	disabled

I don't know if any of these are a clue to what's causing the problem.

No JS errors in the browser console. (Firefox)

Both pages are error-free with extension version 1.7. I was testing the newer version out of the hope that it would help us with recurring contributions, which have been a problem.

laryn commented 9 years ago

I can confirm the same on a new install from the zip file Github provides (extension 4.6-dev, listed in info.xml as v.1.9.1), on Drupal 7.36 with CiviCRM 4.6.3. (With or without the confirmation page, the same result -- only the error appears after the confirmation page is submitted if that page is enabled, otherwise immediately upon contribution page form submission).

The key factor seems to be the Pay Later option (it works if it is not enabled). I have not tested with a second payment processor option.

highfalutin commented 9 years ago

Unfortunately the Pay Later option does not seem to be the culprit in my case.

twbrooks101 commented 9 years ago

I've been having the same issue. As long as the "pay later" option is enabled, it's throwing the "Stripe.js token was not passed!" error. Once I removed that option, Stripe processed a live payment just fine.

Wordpress 4.2.2 Civicrm 4.6.2 Fruitful Theme

enricospada commented 9 years ago

I'm having the same issue as well. I turned off the Pay Later option, which prevents the error from appearing but also does not process the contribution (just refreshes the page with a blank form, or, if Confirmation Page is enabled, returns user back to the blank form).

Wordpress 4.2.2 Civicrm 4.6.3

EDIT: I managed to install the 4.6dev branch, and, after disabling both Pay Later AND any other payment processor, it worked, same as @richardsplayground and @MicahStevens.

mattwire commented 9 years ago

I get this issue, drupal 7.39, civicrm 4.6.8. No other payment processors enabled, no pay later. The following pull request fixes it for me and seems to allow other payment processors/pay later to be enabled if required: https://github.com/drastik/com.drastikbydesign.stripe/pull/95

bjendres commented 9 years ago

We had the same issues as described above, Drupal 7.39, CiviCRM 4.6.8, pay_later enabled.

Our "hotfix" https://github.com/drastik/com.drastikbydesign.stripe/pull/97 patching civicrm_stripe.js did the trick, STRIPE's working perfectly now. I am, however, not quite sure what this bit of code was intended for in the first place.

jmcclelland commented 9 years ago

Same issue - drupal 7.39, civicrm 4.6.8 pay later enabled. The pull request in #97 did not work, but disabling pay later did work.

jmcclelland commented 9 years ago

There seem to be a few different reasons why people are getting this error. For the "Pay Later" reason - I think i fixed it with this pull request: https://github.com/drastik/com.drastikbydesign.stripe/pull/99

CiviCRM has changed the availability of the hidden_processor field in 4.6 - so that would explain why it works in 4.5 and not in 4.6 (see https://issues.civicrm.org/jira/browse/CRM-15743)

mecachisenros commented 9 years ago

I'm having the same issue as well, I'm not quite sure on how to start debugging.

CiviCRM - 4.6.4/4.6.8 Wordpress - 4.3.1 Stripe Payment Processor 1.9.2

I've tried with the default Twenty Fifteen theme, clean Wordpress and CiviCRM install, no extra plugins or extensions. Extensions Resources URL: http://www.site.com/dev/wp-content/plugins/files/civicrm/extensions/ (seems to be correct) No additional payment processors and no 'Pay Later', trying to make payments for Events.

Result:

Sorry but we are not able to provide this at the moment. Stripe.js token was not passed! Report this message to the site administrator.

Backtrace:

#0 /var/www/site/public_html/dev/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php(360): CRM_Core_Error::backtrace()
#1 /var/www/site/public_html/dev/wp-content/plugins/files/civicrm/extensions/com.drastikbydesign.stripe-4.6-dev/CRM/Core/Payment/Stripe.php(295): CRM_Core_Error::fatal("Stripe.js token was not passed!  Report this message to the site administrator.")
#2 /var/www/site/public_html/dev/wp-content/plugins/civicrm/civicrm/CRM/Event/Form/Registration/Confirm.php(619): CRM_Core_Payment_Stripe->doDirectPayment((Array:57))
#3 /var/www/site/public_html/dev/wp-content/plugins/civicrm/civicrm/CRM/Core/Form.php(345): CRM_Event_Form_Registration_Confirm->postProcess()
#4 /var/www/site/public_html/dev/wp-content/plugins/civicrm/civicrm/CRM/Core/StateMachine.php(164): CRM_Core_Form->mainProcess()
#5 /var/www/site/public_html/dev/wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Next.php(61): CRM_Core_StateMachine->perform(Object(CRM_Event_Form_Registration_Confirm), "next", "Next")
#6 /var/www/site/public_html/dev/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Next->perform(Object(CRM_Event_Form_Registration_Confirm), "next")
#7 /var/www/site/public_html/dev/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Event_Form_Registration_Confirm), "next")
#8 /var/www/site/public_html/dev/wp-content/plugins/civicrm/civicrm/CRM/Core/Controller.php(353): HTML_QuickForm_Page->handle("next")
#9 /var/www/site/public_html/dev/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(312): CRM_Core_Controller->run((Array:3), NULL)
#10 /var/www/site/public_html/dev/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(86): CRM_Core_Invoke::runItem((Array:15))
#11 /var/www/site/public_html/dev/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(54): CRM_Core_Invoke::_invoke((Array:3))
#12 /var/www/site/public_html/dev/wp-content/plugins/civicrm/civicrm.php(1189): CRM_Core_Invoke::invoke((Array:3))
#13 /var/www/site/public_html/dev/wp-content/plugins/civicrm/includes/civicrm.basepage.php(134): CiviCRM_For_WordPress->invoke()
#14 [internal function](): CiviCRM_For_WordPress_Basepage->basepage_handler(Object(WP))
#15 /var/www/site/public_html/dev/wp-includes/plugin.php(579): call_user_func_array((Array:2), (Array:1))
#16 /var/www/site/public_html/dev/wp-includes/class-wp.php(633): do_action_ref_array("wp", (Array:1))
#17 /var/www/site/public_html/dev/wp-includes/functions.php(886): WP->main("")
#18 /var/www/site/public_html/dev/wp-blog-header.php(14): wp()
#19 /var/www/site/public_html/dev/index.php(17): require("/var/www/site/public_html/dev/wp-blog-header.php")
#20 {main}

I'm not a developer but if I could help in anyway please let me know, I have a development environment ready for testing.

mattwire commented 9 years ago

Please test the latest version. I believe it is fixed following this pull request: https://github.com/drastik/com.drastikbydesign.stripe/pull/102

mecachisenros commented 9 years ago

@mattwire I've tested the latest version, with the latest fix applied. The error above is with the latest version, tested a couple of hours ago.

jmcclelland commented 9 years ago

After a lot of trial and error I've created two reproducible ways to trigger this problem.

Setup: Event with Stripe payment processor and pay later option.

Scenario one: Fill out everything, but don't choose either the Stripe payment processor or the pay later option. Hit submit. Page reloads with CiviCRM error message about how you need to select a payment processor. Select stripe and hit submit again. Fails. Scenario two: Fill out everything except one required field. Choose Pay Later option. Hit submit. You get a CiviCRM error about missing field. Fill it in - and then change your mind and choose Stripe as the payment processor. Hit submit. Fails.

The reason both failures is the same:

When reloading the page after an error - CiviCRM does not populate the _paymentProcessors property of the form. See Contribute_Form_Contribution_Main::preProcessPaymentOptions() - when the form has _submitValues set - it will only populate _paymentProcessors with the selected payment processor. But in both scenarios, Stripe is not chosen as the selected payment processor.
stripe_civicrm_buildForm() is responsible for inserting the javascript code to create the stripe token. However, it is only triggered if _paymentProcessors is populated with a stripe payment processor.
There is a fallback - if you click on the Stripe payment processor - the civicrm_stripe.js is injected (which causes Stripe to complain about being injected more than once). However, that doesn't solve the problem - since the code we need injected is wrapped in $(document).ready(function(). Since the page is already loaded - this doesn't seem to be applied.

I'm not sure what the best approach is. Maybe some modification to the code that is injected when you click the stripe payment processor option? It could check to see if it has already been injected and not proceed if it has. However, if it hasn't been injected, perhaps it could run outside the ready() function??

@mecachisenros is stripe the default payment process on your system. I think we would similar errors to what I have experienced if do not have stripe set as the default option.

mecachisenros commented 9 years ago

@jmcclelland the tests I made, Stripe Processor was the only payment processor (also the default one), Pay Later disabled, filled in all required fields (ie Contact details from Profile, and Billing Address), no extension installed apart from Stripe. This morning I tested @systopia's fork (ref #97) which seems to fix this issue, the test was in the same environment (no extensions, no Pay later, no additional payment processor) the payment was processed successfully, couldn't process the payment in test mode though, but live payments seem to work. Tomorrow morning I will test Systopia's fix with PayPal enabled and Pay Later and I will report back. I will try having a look at their fix, but as I said, not a developer, just some basic JavaScript knowledge, willing to help though.

jmcclelland commented 9 years ago

I just tried a new pull requests to address the problems I've experienced. It involves some re-factoring to simplify the code (I hope):

https://github.com/drastik/com.drastikbydesign.stripe/pull/105

rohankatkar commented 9 years ago

Hi @drastik,

I am having issue with PayPal payment processor. I have configured the Stripe on website with PayPal and pay-later option. Stripe is configured as defualt payment processor. Pay later and stripe is working fine. But now issue is, while submitting contribution with PayPal, its giving me an error: "Error: Missing required param: number." which was getting occured previously in case of stripe.

The other scenario is, when there is none of the payment processor is set as default, then Paypal works fine and stripe gets break or is there any conflict when we configured PayPal and Stripe together?

Any idea why this is happenning?

drastik commented 9 years ago

@rohankatkar,

Yes, a few are reporting that there is an issue when using multiple payment processors including Stripe.

zeigerpuppy commented 9 years ago

I'm also having this problem with the latest version of the stripe plugin pulled from github. I have disabled other payment processors and pay later. Wordpress 4.2.2 (Debian) Stripe Payment Processor 1.9.2 CiviCRM 4.6.4

Just wanted to make sure my settings are right too: extension URL: https://mysite.com/wp-content/plugins/files/civicrm/custom_ext Stripe payment URL: https://api.stripe.com/v2 Webhook https://mysite.com/?page=CiviCRM&q=civicrm/stripe/webhook

hetclub commented 9 years ago

I have exactly the same experience as rohankatkar above. I removed the Pay Later option, and have PayPal and Stripe. When PayPal is default and Stripe is selected, I get the full screen error as above. When Paypal is selected and Stripe is default, I get the "number" error as above. It appears that which ever default is selected, triggers some behavior that CiviCRM requires the other processor to have because the error is happening at exactly the same point where they are different. With Stripe as default, it requires the entry of a card number for Paypal, when Paypal is default, Stripe is failing when you would be forwarded to Paypal's website. Is there some code that is run based on the default regardless of the payment processor? Joomla 3.4.5 Stripe 1.9.1 CiviCRM 4.6.10

hetclub commented 9 years ago

So one additional comment. If I remove any payment processor as the default, then I get the same result as if Paypal were the default - full screen error:

0 -

richardsplayground commented 8 years ago

Just got this error with a version of the stripe plugin downloaded today from GitHub on a freshly upgraded CiviCRM version 4.7.1 on Drupal. When looking at the JavaScript console during a test event registration/payment, I saw this:

Navigated to https://site/civicrm/event/register?reset=1&action=preview&id=38 register?reset=1&action=preview&id=38:1 Mixed Content: The page at 'https://site/civicrm/event/register?reset=1&action=preview&id=38' was loaded over HTTPS, but requested an insecure script 'http://site/sites/default/files/civicrm/extensions/com.drastikbydesign.stripe-4.6-dev/js/civicrm_stripe.js?r=lTa5i'. This request has been blocked; the content must be served over HTTPS.

Turns out my Resource URLs setting got munged during the CiviCRM Stripe extension upgrade and no longer pointed to https but was instead pointing to http. Going to Administer->System Settings->Resource URLs and putting in https fixed the problem.

PS: In my case the value input in the GUI is overridden by a value stored in civicrm.settings.php, so if you are trying to put in https in the GUI over and over and it won't save, check civicrm.settings.php to see if there is an override in there.

aydun commented 8 years ago

I'm also getting the 'Stripe.js token was not passed!' message on a webform. (Stripe is working in test mode from contribution pages.) This is on two different webforms: one just a contribution, the other a membership. It seems that civicrm_stripe.js is not getting loaded on the billing page.

What/when/how should cause civicrm_stripe.js to be loaded?

When the contribution page snippet is fetched, the stripe_add_stripe_js is called but there is no reference to the civicrm_stripe.js in what comes back.

This is stripe 4.6-dev latest github, webform 7.x-4.12, webform_civicrm 7.x-14, civicrm 4.6.14

jmcclelland commented 8 years ago

You might trying pulling in the commit I reference on this issue:

https://github.com/drastik/com.drastikbydesign.stripe/issues/113

Then add: ` define('STRIPE_SUBMISSION_METHOD', 'php');

`To your civicrm.settings.php file

I don't know how it will ever be possible to figure out all the corner cases in CiviCRM forms to ensure we know when to add the right javascript :(.

Maybe with CiviCRM 5.0 comes out and we have a more sane forms layer.

aydun commented 8 years ago

@jmcclelland - thanks, that's a useful option. I'd like to keep to the javscript method if possible for the security reasons you reference.

As a workaround/gross-ugly-hack, I've added a markup box on the webform to load civicrm_stripe.js Since others seems to have had success previously presumably the js must have been loaded and I hoping someone will explain how!

Also, since webform loads the billing block (which includes the stripe-pub-key) when needed, the stripe-pub-key is not present when the js is loaded, so the setPublishableKey call fails in document.ready, but moving that into the submit function works since the billing block is loaded by then. It's not extensively tested, but works so far.

laryn commented 8 years ago

@aydun I am having the same issue on a webform. Core contrib pages function.

nishant-bhorodia commented 8 years ago

Thanks @aydun, Your solutions works. But this change needs to be done manually on every webform that uses stripe. So I override the BillingBlock.tpl and added civicrm_stripe.js to it manually. which works too!!

But is overriding a template an acceptable solution ?

Many Thanks!!

aydun commented 8 years ago

Hi @nishant-bhorodia - glad to hear that works for you too, but it's hardly a 'solution'! My workaround adds civicrm_stripe.js manually to each webform but that should not be needed. I'm not clear which part of the webform/stripe combination should be loading civicrm_stripe.js. I have not looked at recent changes to this module so my comments are based on code as of March.

nishant-bhorodia commented 8 years ago

Thanks @aydun I am using the latest 4.6-dev branch and the civicrm_stripe.js issue is still there. I can think of two solutions at the moment:

Use hook_civicrm_alterContent to embed the civicrm_stripe.js in template.
Introduce a drupal module and use drupal_add_js to add the js to webform. I think webform_civicrm doesn't fetch js from the civicrm extension.

drastik commented 8 years ago

It looks like https://github.com/drastik/com.drastikbydesign.stripe/pull/159 may fix this.

Just a few notes over there before committing. Can anyone test that PR and provide feedback?

onefiftyfour commented 7 years ago

I'm confused about the activity on this issue. Has anyone confirmed that this is fixed?

adevapp commented 7 years ago

Issue still exists for me.

After debugging the issue, I found when using an alternate branch the Javascript referred to a class which was incorrect - As a result, the stripe-token form field doesn't get generated and attached to the form, and this ultimately produces the message. The latest dev branch has this fix for the class, by adds the javascript and form field using an AJAX call. This seems not work without error. So the javascript is added to the form on initial load now and this seems to solve the issue. On the confirm page, click View Source Code in your browser and check stripe-token has a value for the input field. If you're quick enough, on post you can see the javascript code post to Stripe to concert the CC into a token for use by the form.

if ($formName == "CRM_Contribute_Form_Contribution_Main") {
    CRM_Core_Resources::singleton()->addScriptFile('com.drastikbydesign.stripe', 'js/civicrm_stripe.js', 1);
    // Add some hidden fields for Stripe.
    if (!$form->elementExists('stripe_token')) {
        $stripe_token = (empty($params['stripe_token']) ? NULL : $params['stripe_token']);
        $form->setAttribute('class', $form->getAttribute('class') . ' stripe-payment-form');
        $form->addElement('hidden', 'stripe_token', $stripe_token, array('id' => 'stripe-token'));
    }
}

h-c-c commented 7 years ago

@adam-devapp is this involving webforms? If so, this commit b81d7fb should address it...and could you test?

@nishant-bhorodia I stole your idea to use hook_civicrm_alterContent...thanks!

onefiftyfour commented 7 years ago

(I'm on wordpress, I assume webforms is a Drupal thing?)

I just upgraded to the latest 4.7-dev.

With this latest version, I'm getting this error when I enable the pay later option. I don't get the error with the pay later option disabled.

(CiviCRM 4.6.26)

onefiftyfour commented 7 years ago

I want to clarify that the Pay Later box doesn't have to be checked to get the error. If the end user has the option to pay later, but does not check that box, the error will occur and no payment will be made.

If I remove the option to pay later - no error.

drastik commented 7 years ago

@onefiftyfour Yes, Webform = Drupal optional add on.

I heard in another ticket that the class of the payment form changed in CiviCRM. Rather than change our class target again to keep up, I'd like to see a much more reliable approach achieved. Originally, I used a hook to add a class to the payment form, but that also quit working...

h-c-c commented 7 years ago

Thanks for the clarification @onefiftyfour!

@drastik I agree, a more reliable way is more desirable. But until we find it, let's keep chasing, just so nobody is left out of the pay-processing fun. :-) FWIW, the class name is consistent between 4.6 and 4.7.

@onefiftyfour can you try the latest? This ab35f709d74f0fd12fa435706999ae652424d7ef should fix....although it's not the ultimate solution as mentioned.

drastik / com.drastikbydesign.stripe

Error: Stripe.js token was not passed! Report this message to the site administrator.(ext ver. 1.9.1) #76