search

cartalyst / stripe-laravel

Cartalyst Stripe package integration for Laravel.
BSD 3-Clause "New" or "Revised" License
335 stars 57 forks source link

Stripe API Key is not defined - Laravel #32

Closed BrunoMCTeixeira closed 6 years ago

BrunoMCTeixeira commented 6 years ago

I've installed everything according to documentation and I get this message when I try to create a card using an array. What can cause it?

ENV has STRIPE_KEY and STRIPE_SECRET

brunogaspar commented 6 years ago

If you've set it up through the environment keys, it needs to be STRIPE_API_KEY as mentioned on the documentation.

The env keys you're using are the ones Laravel expects on config/services.php, but they are not the ones that our Stripe package use.

I can add a different example to the Stripe Laravel documentation with the correct env keys though.

Hope it helps.

BrunoMCTeixeira commented 6 years ago

The services.php says STRIPE_KEY but STRIPE_API_KEY didn't work as well

brunogaspar commented 6 years ago

The services.php says STRIPE_KEY

Yes, but that's what comes by default from Laravel. It doesn't mean it should be used as is.

but STRIPE_API_KEY didn't work as well

Are you sure you're setting STRIPE_API_KEY either through the .env file or even through server environment variables?

Here's my step by step attempt to reproduce the issue:

Now doing app('stripe') works as expected.

Didn't had to touch the config/services.php file for this one.

If you want to touch the config/services.php file:

'stripe' => [
    'secret' => env('STRIPE_API_KEY'),
],

I'm afraid i can't reproduce the issue.

BrunoMCTeixeira commented 6 years ago

I've added the provider and the facade, so I'm calling Stripe::cards...

Why are you adding : before the api key?

It doeesn't work for me but you should follow your documentation to reproduce the problem, that process doesn't look at all like the documentation.

BrunoMCTeixeira commented 6 years ago

Even replacing the services ENV directly with the keys, it doesn't work. Something is broken on your release because I don't think its the API Key, its just the error that is wrong and its something else.

brunogaspar commented 6 years ago

The steps i'm using were for brevity, but either way

Let's follow the documentation, yet again (same process as i mentioned previously)

Yet again, everything is working as expected on my end by following the documentation.

So you're most likely not following the documentation correctly or you're failing to understand where the problem is coming from on your application.

moseskamau338 commented 6 years ago

Am experiencing the same issue on the current release. Followed everything to the letter but still receiving the same error.

DanielHartUK commented 5 years ago

I too am experiencing the same issue. For me, this is occurring when config caching is enabled (As recommended in the Laravel deployment documentation), when env functions aren't available.

It looks as if where the Stripe Service Provider is attempting to fetch the api key from the services config file, it cannot find them. The Stripe Config.php file then falls back to getting STRIPE_API_KEY from .env, but it cannot get it as the file is not available.

brunogaspar commented 5 years ago

@DanielHartUK Laravel defaults the environment key to STRIPE_SECRET instead of STRIPE_API_KEY.

So you need to either update your .env file and set the STRIPE_SECRET or update config/services.php file and set STRIPE_API_KEY

Either way, it's not a bug, but rather your env key not being named accordingly to what the services config file is using.

DanielHartUK commented 5 years ago

If the package was retrieving the Stripe key via the config/services.php file, as it should be, then it shouldn't make any difference what the env key name is, so long as it's properly defined in the services file. It's simple to test this, as if the STRIPE_API_KEY isn't set in .env and the key is inserted directly into config/services.php, then it should work, but it does not.

Regardless, I've followed the documentation, but the package does not work when php artisan config:cache is enabled as per Laravel's deployment documentation because the package does not retrieve the key from the config file as it should, and falls back to fetching it directly from the .env file, which it cannot do when config caching is enabled because Laravel disables it.

brunogaspar commented 5 years ago

Hello @DanielHartUK , thanks for the feedback.

You seem to have a big confusion on how the main Stripe package works and how Laravel Config works too.

The main Stripe package, only cares if you either provide the key, otherwise if not provided, it will fallback to the native PHP Function getenv('STRIPE_API_KEY'), nothing to do with Laravel or cached configs.

Both main Stripe package and the Stripe Laravel package, never loads the .env file as you say it does, Laravel is the solely responsible for doing so, not the packages.

Let's go through what you wrote to see if i can help you understand what's happening behind the scenes, in case you don't fully grasp it:

If the package was retrieving the Stripe key via the config/services.php file, as it should be, then it shouldn't make any difference what the env key name is, so long as it's properly defined in the services file.

Sorry but it does matter. If you have mismatched keys, how would the value be populated on the config file in the first place?

Example of an .env file

FOO_BAR=baz

Example of a config file called config/foo.php (doesn't matter which file it is, the principle is the same)

<?php

return [
    'bar' => env('BAR_FOO'),
];

When calling config('foo.bar') it will clearly return NULL because the environment key names doesn't match. Which is totally expected.

Therefore, i assume that this is happening on your application too because i cannot reproduce any problems on my end, being the Config cached or not.

It's simple to test this, as if the STRIPE_API_KEY isn't set in .env and the key is inserted directly into config/services.php, then it should work, but it does not.

Not sure what might be happening on your end, but works perfectly fine on my end, and other projects, regardless if i'm using the environment variables or not.

I've tested multiple times by doing config:clear and config:cache and it worked as expected everytime.

Now, the only thing i can think of is it could be that you were modifying the services.php file while the config is cached, in that case, this is a misunderstood from you, because if the config is Cached, Laravel will not load the config files either, otherwise it wouldn't make any sense to have Cache feature in the first place.

So if that's none of the above, you'll need to debug that on your own i'm afraid, since i can't reproduce it.

But will will try to explain what Laravel does:

You might have a environment variable called STRIPE_API_KEY defined on your .env file, but your Config is not cached, no problem there.

Using the example above, what's making it work is because Laravel is passing NULL from the config('services.stripe.secret') to the main Stripe Package, which in turn makes the Stripe Config to default to use the getenv() method i mentioned above which in turn can retrieve the STRIPE_API_KEY value because Laravel loaded your .env file data.

Now, when you cache, Laravel WILL NOT LOAD your .env file, so, since it's still passing NULL to the Stripe Config, Stripe itself, again will default to getenv() however, this time and since Laravel didn't loaded the .env file, the STRIPE_API_KEYwill not be there and will be NULL.

Regardless, I've followed the documentation, but the package does not work when php artisan config:cache is enabled as per Laravel's deployment documentation because the package does not retrieve the key from the config file as it should, and falls back to fetching it directly from the .env file, which it cannot do when config caching is enabled because Laravel disables it.

I don't think i need to cover this part here, considering that i've basically explained how Laravel Config works above.

So, with that said, and as i mentioned on my last message, you most likely have mismatched keys. So nothing for me to really fix at package level. This is something you need to tweak on your application or figure out where the problem might be.

Sorry for the big message, but hope it helps you a bit to understand what's happening behind the scenes and also clarify why it's not working. If it still doesn't work, try with a fresh Laravel installation, zip the project and email it to me so i can see what's wrong.