Payment fails with: Payment Error Response: Error: The card object must have a value for 'number'.

[h-c-c]

Stripe payment fails with error message:

Payment Error Response: Error: The card object must have a value for 'number'.

[drastik]

Can you give details about your install?

• Wordpress / Drupal.
• CiviCRM version.
• civicrm_stripe version.
• Version of Stripe API active on your account.

[h-c-c]

Certainly!

Drupal 7.38 CiviCRM 4.6.5 civicrm_stripe 4.6-dev 1.9.2 Release date 2015-10-09 api version 2015-07-28

Thank you

[h-c-c]

FWIW, I put together another setup with the same versions and got the same error. Although I don't see what needs changing, after googling some, I've read that this error happens when the entire token is passed instead of just the token id.

[johnfewell]

Same thing is happening for me:

Wordpress 4.3.1 CiviCRM 4.6.9 civicrm_stripe 4.6-dev 1.9.2 Release date 2015-10-09 API Version 2015-10-01

[BorislavZlatanov]

I'm also experiencing this problem with Wordpress 4.3.1 and Civi 4.6.8. The problem is with the civicrm_stripe.js file, more specifically the "Handle multiple payment options and Stripe not being chosen" section.

In my case, I don't have any element with id of stripe-id, so the line if (!($form.find('input[name="stripe_token"]').length) || ($('#stripe-id').length && $('#stripe-id').val() != processorId)) { never evaluates to true.

Got it working with a dirty, temporary workaround. I changed the above line to if (!($form.find('input[name="stripe_token"]').length) || processorId !=10) { The id of my Stripe payment processor is 10 (if you implement this, you would replace the number with the id of your Stripe payment processor). It works, but again - very dirty. The id is hardcoded. I don't know what element on the page to check in order to find out whether Stripe or another processor is selected.

Lastly, a peculiar bug. If you are trying to fix this, use the Chrome Dev Tools. In Firefox, both the Dev Tools and Firebug were giving me false info in the javascript debugger.

Update: I have an element with id of stripe-id when I am logged in. So the original line in the civicrm_stripe.js file seems to work fine for me when logged in, but not when logged out.

[drastik]

@BorislavZlatanov You did have more than just Stripe enabled for that form when this happened right?

Very strange that logged in vs out changes this.. ugh.

[BorislavZlatanov]

@drastik Yeah, I had Stripe and Paypal enabled on the form.

[jmcclelland]

I resolved the issue by fixing a an error in the javascript script. There is an undefined variable (currentTotal - perhaps defined on contribution pages, not on event registration pages). When we hit that error, the script dies.

[jmcclelland]

Found yet another error situation. The check for currentTotal is not reliable. If you have a priceset with a default price selected, then currentTotal will be set to 0 even though it's not 0. I can try to hack together a fix, but I think all of these errors raise a pretty fundamental question: are we doing this the right way?

Using javascript to check whether or not we should submit a credit card for processing is not the standard way to implement credit card processing in CiviCRM and puts us at the mercy of any tiny change in the way CiviCRM handles forms. Is there any reason why we are submitting via javascript and not via curl via php on the back end?

Even if we somehow got all of these use cases sorted out for 4.6 - we will have to do it all over again for 4.7.

I think we either need to fundamentally change the way stripe works or build out test cases for each of these scenarios.

[jmcclelland]

I see that you even have code commented out that allows us to use Stripe without the javascript. I think we should switch to using that code or at least provide an option to use it instead.

[drastik]

Using javascript to check whether or not we should submit a credit card for processing is not the standard way to implement credit card processing in CiviCRM and puts us at the mercy of any tiny change in the way CiviCRM handles forms. Is there any reason why we are submitting via javascript and not via curl via php on the back end?

Yes. Because Stripe. If we process via PHP, the credit card details hit the server, PCI compliance requirements jump up tenfold. It is no longer as secure and doesn't truly utilize what makes Stripe special.

[drastik]

currentTotal is what core CiviCRM is using in other code to check priceset value(s); if it is not reliable in situations like default values then this is a CiviCRM core issue.

[jmcclelland]

I agree having the credit card details submitted via javascript is a nice feature of stripe and adds additional security above and beyond any of the other payment processors available to CiviCRM.

Also, the CiviCRM core team has announced that coming up with a better forms handler is a priority in their roadmap. So, maybe in a future version of CiviCRM, we might be able to build the javascript code that could reliably determine when we should be submitting a credit card to stripe.

Unfortunately, at this point - after explaining to multiple clients who are understandably pissed off because they are losing contributions due to the bugs we've been fixing, I simply can't tell them the problem is "fixed" with any confidence. I'm not even sure how to fix the currentTotal bug (or whether the bug even affects CiviCRM core) or whether we will find yet another corner case tomorrow where it fails again.

I'd like to propose a configuration option to let the user decide which method they want to use: javascript or PHP. I also think we should work on a test suite so we can ensure we don't have regressions in the future.

[drastik]

I'd like to propose a configuration option to let the user decide which method they want to use: javascript or PHP. I also think we should work on a test suite so we can ensure we don't have regressions in the future.

I like these ideas.

[jmcclelland]

I'm leaving this issue open (since we have a new use case the triggers the error that I haven't not tracked down and fixed). I have opened #113 to cover the new feature for allowing users to configure which submission method they want to use.

[laryn]

I was seeing this today with the latest version of the stripe_civicrm code, on Drupal 7 with CiviCRM 4.6.16. They had set up the contribution page with values entered (as a radio button list) with no labels, and the "allow other options" turned on. I ended up setting it up as a price set (where each option has a label) with a second "Other amount" field to type an amount manually, and the donations now go through. It's a workaround, not a solution but I'm posting here in case it helps isolate the issue.