" is not of type String" error in v. 1.7 (Civi 4.4.3)

[laryn]

I have a site running CiviCRM 4.4.3 with CiviCRM-Stripe 1.7, and the contribution page errors out on submission with " is not of type String". Interestingly, I think event pages that take contributions through Stripe are still functioning but I've had to put the donation page in "Pay later" mode since mid-December.

The backtrace is below. Any ideas?

[info] $backTrace = #0 /public_html/sites/all/modules/civicrm/CRM/Core/Error.php(322): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /public_html/sites/all/modules/civicrm/CRM/Core/DAO.php(999): CRM_Core_Error::fatal(" is not of type String")
#2 /public_html/sites/all/modules/civicrm/CRM/Core/DAO.php(893): CRM_Core_DAO::composeQuery("INSERT INTO civicrm_stripe_customers\n          (email, id) VALUES (%1, %2)", (Array:2), TRUE)
#3 /public_html/civi_extensions/com.drastickbydesign.stripe/CRM/Core/Payment/Stripe.php(292): CRM_Core_DAO::executeQuery("INSERT INTO civicrm_stripe_customers\n          (email, id) VALUES (%1, %2)", (Array:2))
#4 /public_html/sites/all/modules/civicrm/CRM/Contribute/BAO/Contribution/Utils.php(230): CRM_Core_Payment_Stripe->doDirectPayment((Array:72))
#5 /public_html/sites/all/modules/civicrm/CRM/Contribute/Form/Contribution/Confirm.php(972): CRM_Contribute_BAO_Contribution_Utils::processConfirm(Object(CRM_Contribute_Form_Contribution_Confirm), (Array:72), (Array:62), "36314", "1", "contribution", (Array:0))
#6 /public_html/sites/all/modules/civicrm/CRM/Core/Form.php(261): CRM_Contribute_Form_Contribution_Confirm->postProcess()
#7 /public_html/sites/all/modules/civicrm/CRM/Contribute/Form/Contribution/Main.php(1316): CRM_Core_Form->mainProcess()
#8 /public_html/sites/all/modules/civicrm/CRM/Core/Form.php(261): CRM_Contribute_Form_Contribution_Main->postProcess()
#9 /public_html/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Upload.php(151): CRM_Core_Form->mainProcess()
#10 /public_html/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Upload.php(128): CRM_Core_QuickForm_Action_Upload->realPerform(Object(CRM_Contribute_Form_Contribution_Main), "upload")
#11 /public_html/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Upload->perform(Object(CRM_Contribute_Form_Contribution_Main), "upload")
#12 /public_html/sites/all/modules/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contribute_Form_Contribution_Main), "upload")
#13 /public_html/sites/all/modules/civicrm/CRM/Core/Controller.php(345): HTML_QuickForm_Page->handle("upload")
#14 /public_html/sites/all/modules/civicrm/CRM/Core/Invoke.php(323): CRM_Core_Controller->run((Array:3), NULL)
#15 /public_html/sites/all/modules/civicrm/CRM/Core/Invoke.php(72): CRM_Core_Invoke::runItem((Array:15))
#16 /public_html/sites/all/modules/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:3))
#17 /public_html/sites/all/modules/civicrm/drupal/civicrm.module(456): CRM_Core_Invoke::invoke((Array:3))
#18 [internal function](): civicrm_invoke("contribute", "transact")
#19 /public_html/includes/menu.inc(517): call_user_func_array("civicrm_invoke", (Array:2))
#20 /public_html/index.php(21): menu_execute_active_handler()
#21 {main}

[drastik]

So it's got email coming through as an array now... sweet.

[laryn]

Actually, as I dig deeper, it looks like $stripe_customer->id is not set.

$query_params (in CRM/Core/Payment/Stripe.php(292)) comes out as follows:

Array ( [1] => Array ( [0] => test@email.org [1] => String ) [2] => Array ( [0] => [1] => String ) )

[drastik]

Hmm. I've been thinking about doing away w/ storing any of that customer info on Civi side anyway -- there's no point unless it's being used in Webhook.php.

If I had to take a wild guess, it would be that your stripe account already has a 'customer' with that email address, but it didn't come from the Civi site in question so their entry in civicrm_stripe_customers isn't present.

I think the solution is to completely do away w/ civicrm_stripe_customers, and instead call Stripe API's customer load function to check if it exists already.

[laryn]

Strangely, I am creating new dummy emails that have never been used before and I still get this.

[laryn]

drastik: what is the difference in processing a payment through an event registration vs. a contribution page? Why would one work and not the other?

Also, as I was troubleshooting, I clicked update on the Stripe API version in the Stripe account -- is the code kept up to date with the latest Stripe API?

[drastik]

Great find on the API update! I never saw that.

Might have something to do w/ why I have 0 issues and they are being reported by the truckload on github.

My API version is: 2012-07-09 With this link to what has changed: https://stripe.com/docs/upgrades?since=2012-07-09#api-changelog

I'll update and see what I can find.

[laryn]

Great, thanks! I guess another potential moving part is the Stripe PHP library: https://github.com/stripe/stripe-php

[drastik]

zzz..

So I was already doing the 'lookup customer on Stripe' that I was talking about. Their API only allows lookup by customer id (one of their crazy hashs), so that's why the table exists.

Anyway, new commit with code cleanup and a few fixes, a 'customer not found' issue I ran into, and even more Stripe API changes to fees -- now reports properly in Civi (yet again, for the 3rd time).

https://github.com/drastik/civicrm_stripe/commit/dcc56aecfeac9d7286ced46c9e947407fd590502

I need to make a note on the 1.8 branch that you must be using latest Stripe API.

[drastik]

Back to this topic though, I never saw that error in testing. Now using latest version of everything.

The only issue I'm still hung up on is it won't create new plans coming from CiviCRM.

[laryn]

Hmm... well I will let you know after I have tested whether it ends up solving this issue as well. You don't recommend testing with this current commit on a live server?

[drastik]

It will create new subscription plans in stripe if you submit recurring donation. New plan id format to utilize Stripe's ability for frequency intervals. On Jan 13, 2014 12:36 PM, "laryn" notifications@github.com wrote:

Hmm... well I will let you know after I have tested whether it ends up solving this issue as well. You don't recommend testing with this current commit on a live server?

— Reply to this email directly or view it on GitHubhttps://github.com/drastik/civicrm_stripe/issues/27#issuecomment-32202832 .

[mekrith]

I am having an identical issue, which persists despite ensuring everything is up-to-date as of today.

[laryn]

I updated to the latest code and unfortunately this error remains for me as well.

[drastik]

Thanks for the heads-up.

So on this issue, you are both Drupal with latest version of everything stripe (php, Stripe API, this)?

When did this start happening? After an update to something or config?

[laryn]

Yes, Drupal and updated stripe-php, stripe-API, and civicrm-stripe-extension. I believe this started happening after updating CiviCRM to 4.4.

[mekrith]

WordPress here. Going to do some debugging today, let me know if you want to see anything specific.

[mekrith]

My issue also started after updating CiviCRM to 4.4 and is specific to contribution page. Stripe works for membership purchases oddly.

[drastik]

Any other extensions installed?

Any 'beyond-the-minimum' settings or features for contributions turned on?

[eempey]

Hi I'm on Wordpress 3.8.1, CiviCRM 4.4.3, Stripe-php 1.10.1 and your current extension. I get the "Sorry but we are not able to provide this at the moment. is not of type String" error when submitting payments. A user not logged in to Wordpress got this message: "Sorry but we are not able to provide this at the moment. You cannot set 'card'to an empty string. We interpret empty strings as NULL in requests. You may set obj->card = NULL to delete the property".

I can not reproduce these errors on my local install. The Stripe test cards numbers seem to process just fine locally. There are 2 other extensions installed, but when I enabled them in the local install and disabled them in the live site I had the same results.

[eempey]

#0 /home/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php(315): CRM_Core_Error::backtrace()
#1 /home/wp-content/plugins/civicrm/civicrm/CRM/Core/DAO.php(999): CRM_Core_Error::fatal(" is not of type String")

#2 /home/wp-content/plugins/civicrm/civicrm/CRM/Core/DAO.php(893): CRM_Core_DAO::composeQuery("INSERT INTO civicrm_stripe_customers\n          (email, id) VALUES (%1, %2)", (Array:2), TRUE)
#3 /home/wp-content/plugins/files/civicrm/extensions/com.drastikbydesign.stripe/CRM/Core/Payment/Stripe.php(300): CRM_Core_DAO::executeQuery("INSERT INTO civicrm_stripe_customers\n          (email, id) VALUES (%1, %2)", (Array:2))
#4 /home/wp-content/plugins/civicrm/civicrm/CRM/Contribute/BAO/Contribution/Utils.php(230): CRM_Core_Payment_Stripe->doDirectPayment((Array:47))
#5 /home/wp-content/plugins/civicrm/civicrm/CRM/Contribute/Form/Contribution/Confirm.php(972): CRM_Contribute_BAO_Contribution_Utils::processConfirm(Object(CRM_Contribute_Form_Contribution_Confirm), (Array:47), (Array:35), "1551", "1", "contribution", (Array:0))
#6 /home/wp-content/plugins/civicrm/civicrm/CRM/Core/Form.php(261): CRM_Contribute_Form_Contribution_Confirm->postProcess()
#7 /home/wp-content/plugins/civicrm/civicrm/CRM/Contribute/Form/Contribution/Main.php(1316): CRM_Core_Form->mainProcess()
#8 /home/wp-content/plugins/civicrm/civicrm/CRM/Core/Form.php(261): CRM_Contribute_Form_Contribution_Main->postProcess()
#9 /home/wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Upload.php(151): CRM_Core_Form->mainProcess()
#10 /home/wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Upload.php(128): CRM_Core_QuickForm_Action_Upload->realPerform(Object(CRM_Contribute_Form_Contribution_Main), "upload")
#11 /home/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Upload->perform(Object(CRM_Contribute_Form_Contribution_Main), "upload")
#12 /home/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contribute_Form_Contribution_Main), "upload")
#13 /home/wp-content/plugins/civicrm/civicrm/CRM/Core/Controller.php(345): HTML_QuickForm_Page->handle("upload")
#14 /home/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(323): CRM_Core_Controller->run((Array:3), NULL)
#15 /home/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(72): CRM_Core_Invoke::runItem((Array:15))
#16 /home/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(52): CRM_Core_Invoke::_invoke((Array:3))
#17 /home/wp-content/plugins/civicrm/civicrm.php(466): CRM_Core_Invoke::invoke((Array:3))
#18 /home/wp-content/plugins/civicrm/civicrm.php(738): CiviCRM_For_WordPress->invoke()
#19 /home/wp-content/plugins/civicrm/civicrm.php(1140): CiviCRM_For_WordPress->wp_frontend(TRUE)
#20 [internal function](): CiviCRM_For_WordPress->shortcode_handler((Array:3), "", "civicrm")
#21 /home/wp-includes/shortcodes.php(273): call_user_func((Array:2), (Array:3), "", "civicrm")
#22 [internal function](): do_shortcode_tag((Array:7))
#23 /home/wp-includes/shortcodes.php(188): preg_replace_callback("/\[(\[?)(embed|wp_caption|caption|gallery|audio|video|civicrm|login\-form|acc...", "do_shortcode_tag", "[civicrm component=\"contribution\" id=\"3\" mode=\"test\"]\n")
#24 [internal function](): do_shortcode("[civicrm component=\"contribution\" id=\"3\" mode=\"test\"]\n")
#25 /home/wp-includes/plugin.php(199): call_user_func_array("do_shortcode", (Array:1))
#26 /home/wp-includes/post-template.php(166): apply_filters("the_content", "[civicrm component=\"contribution\" id=\"3\" mode=\"test\"]")
#27 /home/wp-content/themes/discover/page.php(27): the_content()
#28 /home/wp-includes/template-loader.php(74): include("/home/wp-content/themes/discover/page.php")
#29 /home/wp-blog-header.php(16): require_once("/home/wp-includes/template-loader.php")
#30 /home/index.php(17): require("/home/wp-blog-header.php")
#31 {main}

[drastik]

Try a test with different values.

Different email address, name, card, etc.

[eempey]

I've tried with fake Visa & Mastercard, and a real credit card, testing and doing a real transaction. On the live site it fails everytime. Here is a test link: http://cope.bc.ca/test654765fh/ for stripe's test numbers.

[eempey]

I've also tried with American and Canadian addresses.

[drastik]

I'm hoping for completely unique (not tested previously w/ that Stripe account, regardless of the source whether Civi or some other software) information being tested. Were the email addresses all unique in those tests?

My theory is that customer ID is no longer being returned from Stripe if the user already exists.

By looking at the code and Stripe API, you can see that function should return id, and as @laryn pointed out, the value of $stripe_customer->id is empty in his case (and sounds like yours). https://stripe.com/docs/api/php#create_customer

Can you dump the $stripe_customer object on this line and paste the output? (You can obscure anything sensitive - in fact definitely garble the ID & url fields if you have them): https://github.com/drastik/civicrm_stripe/blob/4.4-1.8/CRM/Core/Payment/Stripe.php#L293

[eempey]

Hmm I guess I don't know how to do that. I tried both error_log(var_dump($stripe_customer));and var_dump($stripe_customer);on line 294. I see no result either in the browser or the php_error_log. Debugging in CiviCRM is on. How do I dump an object?

[drastik]

// Plain method.
$var = print_r($stripe_customer, TRUE);
print "<h2>Stripe Customer</h2> <pre>{$var}</pre>";

// CiviCRM built-in method (should print to status message area like Drupal).
CRM_Core_Error::debug('Stripe Customer', $stripe_customer);

[drastik]

Both will print to screen.

You'll have to run a test transaction to see it. It will be on the confirmation page after doDirectPayment() has run.

[eempey]

Weird I couldn't get either of those methods to output anything on my localhost. On the live server it just outputs "Stripe Customer".

[eempey]

Hi Drastik, I'm stumped. I'm getting no output from either the $stripe_object or $query_params when I dump them. Is that what you would expect? Using completely unique names, credit cards, email addresses doesn't seem to affect my results. Also whenever I uncheck the "use confirmation page" box, I get errors when I submit a payment. This happens on my local install which works otherwise. Contributions->manage contributions->{test contribution} -> configure->Title and Settings -> Use confirmation page? Do you have any other ideas I could try for trouble shooting?

[drastik]

I'll have to test that too, but if that object is empty, that is the problem.
How to fix? I have no idea... according to their API and the code it should be solid.

[eempey]

Hmmm. Like Laryn, I think your extension stopped working for us after upgrading CiviCRM. (I'm not sure what was the last version we had it working with).

[laryn]

After reading #31 I've followed the variables backwards farther and the customer issue is not the root cause of my error. It turns out the $params['stripe_token'] is empty.

Anything else I can dig into that might help solve this?

[drastik]

Weird -- Stripe would give a message about that before trying anything else. It checks much earlier in the code if it's there and stops everything if not: https://github.com/drastik/civicrm_stripe/blob/4.4-1.8/CRM/Core/Payment/Stripe.php#L246

Is it running through twice perhaps?

[laryn]

When I change that line as follows I do get the notice that the Stripe.js token was not passed: if (isset($params['stripe_token']) && $params['stripe_token']!='') {

[eempey]

I printed out get_defined_vars() and here's what I get:

Array
(
    [params] => Array
        (
            [qfKey] => (it printed an alphanumeric string)
            [entryURL] => (it printed the URL)
            [hidden_processor] => 1
            [billing_first_name] => Fakefirstname
            [billing_middle_name] => 
            [billing_last_name] => Fakelastname
            [billing_street_address-5] => 234 Some Street
            [billing_city-5] => Sampletown
            [billing_state_province_id-5] => 1101
            [billing_postal_code-5] => g6t4d3
            [billing_country_id-5] => 1039
            [credit_card_number] => 4242424242424242
            [cvv2] => 555
            [credit_card_exp_date] => Array
                (
                    [M] => 4
                    [Y] => 2018
                )
            [credit_card_type] => Visa
            [email-5] => faker@fakemcfakee.org
            [payment_processor] => 14
            [priceSetId] => 11
            [price_15] => 23
            [selectProduct] => 
            [MAX_FILE_SIZE] => 20971520
            [stripe_token] => 
            [billing_state_province-5] => BC
            [billing_country-5] => CA
            [year] => 2018
            [month] => 4
            [ip_address] => (it printed an ip address)
            [amount] => 23
            [currencyID] => CAD
            [payment_action] => Sale
            [is_pay_later] => 0
            [invoiceID] => (it printed an alphanumeric string)
            [description] => Online Contribution: test
            [accountingCode] => 
            [payment_processor_id] => 14
            [first_name] => Fakefirstname
            [middle_name] => 
            [last_name] => Fakelastname
            [email] => faker@fakemcfakee.org
            [street_address] => 234 Some Street
            [city] => Sampletown
            [state_province] => BC
            [postal_code] => g6t4d3
            [country] => CA
            [contributionType_name] => Donation
            [contributionType_accounting_code] => 4200
            [contributionPageID] => 3
        )
    [amount] => 2300
    [email] => faker@fakemcfakee.org
    [query_params] => Array
        (
            [1] => Array
                (
                    [0] => faker@fakemcfakee.org
                    [1] => String
                )
        )
    [customer_query] => 
    [card_details] => 
)

[drastik]

Interesting...

Would be great if that's all it is - solve many problems at once. It doesn't do this to me though so I'll have some digging to do.

[drastik]

Per #31 , try flushing Civi's caches after updating to the pseudo v1.8

[laryn]

I have already manually deleted the usual directories and pushed the 'clear caches' button but will try again... On Feb 3, 2014 7:17 PM, "Joshua Walker" notifications@github.com wrote:

Per #31 https://github.com/drastik/civicrm_stripe/issues/31 , try flushing Civi's caches after updating to the pseudo v1.8

Reply to this email directly or view it on GitHubhttps://github.com/drastik/civicrm_stripe/issues/27#issuecomment-34021147 .

[eempey]

It looks like our cronjobs are set to clear the caches daily under Administer->System settings->Scheduled Jobs unless I'm misunderstanding something.

On that page I also clicked the "run all jobs manually" button and got the following error: "Warning: array_keys() expects parameter 1 to be array, null given in /home/cope/www/www/wp-content/plugins/civicrm/civicrm/CRM/Campaign/BAO/Survey.php on line 1038

Warning: Cannot modify header information - headers already sent by (output started at /home/www/wp-content/plugins/civicrm/civicrm/CRM/Campaign/BAO/Survey.php:1038) in /home/www/wp-content/plugins/civicrm/civicrm/CRM/Utils/System.php on line 361"

I don't know if that's significant. I also went to Administer->System setting->Cleanup caches and update paths and hit the Cleanup Caches button. I didn't fix the transaction result.

[laryn]

Okay, just re-downloaded 1.8, tried the clean cache button, the scheduled job, and also manually deleted the 'templates_c' directory but am still getting the error... I will double/triple check everything else and report back.

[zesgar]

I am on Joomla 2.5.13 and Civi 4.4.3 with 4.4 v 1.8 and am getting the is not of type string. I have reinstalled several times and cleared the caches and still can't get anything to work.

[zesgar]

I can confirm that it wouldn't be a previous customer in Stripe error. We just setup Stripe and haven't ran a successful transaction yet.

[eempey]

We managed to get our install working today. We uninstalled the com.drastikbydesign.stripe extension in the CiviCRM backend, then re-installed it via the "Add new" button. This installs version 1.7. It's not perfect though, if we don't have the contribution page set to "Add a confirmation page" then the "is not of type String" error still happens.

[laryn]

Bizarre -- I turned on "Add a confirmation page" without changing the installation (still with 1.8 installed) and it seems to give an error on submission but then flips over to the confirmation page and when I submit from that page, the transaction went through (at least on the test server). The earlier error went by too quickly to read before the confirmation page loaded but it looked similar to what was coming up before -- generic language about a problem with the submission.

Any ideas on what this could mean, Joshua?

EDIT: attaching error message

EDIT2: And when I turn off the confirmation page, the same issue as before happens -- the Stripe.js token isn't passed, and the error above appears first before the page crashes in the fatal error.

[zesgar]

I have worked and worked on it and can't seem to figure out any good leads. @drastik what version of the stripe php are you testing and working with. I have 1.10.1 I noticed there is a new 1.11.1 . It seems all they added was the option for multiple subscriptions per customer....It looks like it was updated about 9 days ago..

[drastik]

Nice: "all they added... was multiple subscriptions per customer" That is like the single-most awesome feature for Stripe to add if that means what I think it does :)

I'm going to test a fresh Civi 4.4.4 installation soon. There were a lot of bugfixes in that release according to the email. Maybe we can get civicrm_stripe back on track.

[zesgar]

I am about to launch one of my sites live very soon. I am wondering what kind of time table you think it looks like to get it back up and running?

[zesgar]

I just updated all the code to the latest version on github. I cleared template c and cache I tried a run with adding a recurring contribution option to the page, submitted a one time contribution with no confirmation page or with a confirmation page. Chrome gave me a rederict loop error. After refreshing the contribution page I got this error up top. Something new: Oops! Looks like there was an error. Payment Response: Type: invalid_request_error Code: Message: You passed an empty string for 'card'. We assume empty values are an attempt to unset a parameter; however 'card' cannot be unset. You should remove 'card' from your request or supply a non-empty value

[drastik]

RE: Time

Same old story unfortunately. I have 20 other obligations and no need for this extension currently.

Since dbounty.com won't be ready for a while, I think it's time to bounty source this sucker: https://www.bountysource.com/issues/1400819

I think that would give me (or maybe someone else) the motivation to work on this.

[drastik]

I could make a blog entry, twitter post, etc- looking for supporters & bounty hunters for this project.